Cash Drawer Counter - Learning Curve Help

[wolfderby]

So I'm a semester into a comp sci degree... just threw my first 3 files ever up onto github as an example.

I started trying to develop this cash drawer counter add-on (not sure how many could use it; maybe not many)

Main help wanted is w/ any PseudoCode advice for pulling the date specific payment method cash transactions so I can use this drawer counter to do an opening count + cash sales revenue - closing count = cash drawer variance.

Other advice perceived as a need would be...
slight help w/ the form submit (refresh asks about resubmit; functionally it dumps old data, but the browser still prompts)
should I leave this add-on as a separate databases (I changed the username pw in the github example) I was wondering if it'd be possible to define a $db2 object and then hook in like $db2->Execute($sql); (I did a little digging on the forum on multiple databases but didn't see an example of any tackling of it.) (I just probably just add a table to my current db, but was just reluctant to)

basically anything that looks like it'd be worth providing constructive criticism.

Right now I was thinking of building an array w/ the date as an index and using the 2 databases to feed into that array like...

$datedrawercounts[2018-01-30]['open'] = $150
$datedrawercounts[2018-01-30]['sales'] = $100
$datedrawercounts[2018-01-30]['close'] = $252
$variance = open + sales - close;
therefore drawer's plus 2 dollars.

...but wasn't sure if this is an odd way for some reason to do this. Plus formatting dates sucks.

https://github.com/wolfderby/zencart_drawer_counter

[mc12345678]

I haven't looked at your code "snippet" yet, but had the following thoughts.

Well, something of note is that by using just the date, then there is a bit of a limit on usability. I would suggest to consider what this "math" is doing and further why?

Hint: in a business where cash is involved, is it truly just the calendar date that is in question? Assume a business choses to be open from 10 pm to 2am... do they "stop" at midnight to count their drawer to answer the above question of how much money is in the drawer, to export their list of sales, etc??? Along that line, there are two sets of "opening" and closing on that date because there would be the midnight to 2am and then later in the day the 10pm to midnight grouping, each likely having a different starting amount unless at that "midnight break" the cash drawer was reset to the same starting amount.

Also, here's a question for you. What variance is financially good for the business and which is bad for the cashier?

Why the need for the data to be in yet another database instead of just in its own table? I mean from a multi-site consideration would really just want each site to have its own reporting software with a more "central" location collecting it all into whatever it is using. That client/server type data collection could happen at each or every one of the different locations allowing either one set of software to be written to handle it all or the server side to be offered separately from the "client" side where either/both could still access the one given database instead of having to have an external one.

Also, with the consideration of data "grouping" why is the date being used as a key? I mean, if one were to try to assess over a year's time, does it matter internally if it is by calendar day or could/should it be grouped in some other manner?

[mc12345678]

On another note, regarding using ZC "core" code to link to an alternate database, the database connection is established via includes/init_includes/init_database.php. That is where $db is set as the variable representing database access. That file is loaded at breakpoint 10 as can be seen in includes/auto_loaders/config.core.php. An additional init file could be added with an appropriate auto_loader to associate a different variable with that database. One thing I noticed though is that in includes/classes/db/mysql/query_factory.php there are 2 specific uses of the variable $db instead of $this that are used. Those uses are in error reporting when attempting to use the Move method of the class. That said, I just modified the usage to exclude the use of $db and instead to use $this and at least in "normal" operation there was no negative result. I didn't try to cause the error to occur though which appears to be to try to access or move to a row that is outside the dataset bounds when the data is not cached.

Now on thinking about the operation though, it appears that the intent is, regardless the application doing the operation, ZC as a whole is to be stopped from moving forwards if the class is in some way abused to exceed the dataset if overall ZC is set to die on errors (default for the database setup appears to be false in the init_database.php file). Why though this one line/use of set_error is different than the other uses within the file, I am not sure. A few years ago some consistency was applied to that one line to use $db throughout instead of $db and $this...

It would almost seem to me that if the desire was to stop all further $db related operations on error, then perhaps that line needs to be reproduced for $this as well as $db. Anyways, probably have to force the issue to see how it operates in both arrangements.

[mc12345678]

I also realized something, well one thing just now the other when I was working out how to initiate access to the other database. The thing I just realized, is perhaps I did you as a student a disservice in advising where the important code is instead of encouraging you to discover it yourself beyond searching the forum (which hopefully was done more from outside the forum than inside it).

The other from earlier is that while it may be of use to incorporate one or more files into the ZC system, your software may be fine to use as the stand-alone application it currently is and that you could do your assignment to the alternate database within your existing file.

I would say that it would be wise to incorporate some data sanitization as currently just about anything could be fed to your application and it would be used against that database.

Also, would suggest that in assigning new records to the database that the primary key that auto-increments be left off of the assignment. Currently a value of NULL is being pushed, but some databases would rather have a set of empty quotes or perhaps a 0... by omitting any such value you don't have to ponder what value is needed for what operating system, it should simply auto increment to the next value and be done... and if it is desired to know what the new value is, then it could be discovered just after insert.

Anyways, sorry it took so long to post back to you on the first post. I kind of wanted to see if anyone else was going to offer their thoughts on the topic.

10 years a user and just now going for a comp Sci degree, pretty cool... There's an a-plus school in your neighborhood for that topic.

[wolfderby]

So I've been playing around w/ this a bit too much it feels like:

https://github.com/wolfderby/zencart_drawer_counter
^this is where I am currently, I changed up the php file so that the db works within the zen-cart frame work as a table instead of a separate database.

I opted out of including data in the sql file.

I've been trying to use arrays, and I'm wondering if a more experienced programmer would have perhaps created an object and methods w/ increasing/decreasing the balance(s).

I'm having a hard time conceptualizing the loops. Like if I had day 1, open count $100, then 3 drawer pulls, then day 2, open count $200, and the drawer pulls in the meantime equal $40, then I would have had to had $140 sales for there to not be a variance on the drawer.

If anyone has any suggestions I'd appreciate it, I think my heads going to explode. haha.

[wolfderby]

Spent the bulk of today on it, updated the github. Definitely made some progress on the loops.