Cashup

[odiea]

I am working on Cashups . I have gotten this far so I would like to know how to cure this issue.

[jekkos]

Ok good thanks for the pointer. Added same comments there

[daN4cat]

BTW, I've added @objecttothis to this repo. It made sense to me as we keep new features in embryonic state here and we might publish them or not. Also I keep my boutique personal branch here which is visible to you guys but really customise for my needs.

[jekkos]

@daN4cat indeed found your branch yesterday.. so this means that you went live with it after all? I'm still stuck with the same thing, planned for upgrade but this migration takes time. I'd like to customize as little as possible from the official master now.

[daN4cat]

I was about to go live but I wanted to close 3.2.0 and any bug related to that version before. Meanwhile I hope to close this cashup as my wife said it will be really handy. At the moment they are too busy with the new collection coming in to play with any new stuff.

[daN4cat]

@odiea I fixed the indexes issue. Thanks for that.

[odiea]

Math is correct but there is editing issues. Start of end of day. Had to close and continue working. Back to re enter other items.

[daN4cat]

Ok so it's the logic that is not correct.

[odiea]

It appears it does not retain the previous inputed data after an edit. or whatever you said.

[daN4cat]

I've done the sum using ajax and using php / cashups controller. There is no support for special things like adding thousand separator. To be honest I don't know who would like to spend time to do type that...

[daN4cat]

@odiea I can still see an issue opening and saving without changing. Numbers are changed... I need to fix that.

[odiea]

If you have to make changes that are not in the application folder please let me know. I still have not installed composer or any thing else.

[daN4cat]

@odiea I suspect the problem is with old entries. Something is saved in a wrong format. Try and test with new entries and see if you get the issue.

[odiea]

I went and truncated the table. created new cashup and I still have the same issue.

[daN4cat]

Can you please check it's not the thousand separator in the form? Try with something smaller than thousand too.

[daN4cat]

because I read 1,000 -> 1 and 2,000 -> 2 in your example. So must be that.

[daN4cat]

I thought I could avoid but I need to manage and add new functions to convert format to plain float numbers to avoid the issue.

@jekkos I have a problem with ajax, if I pass a string then on the textinput . val it doesn't accept it. It accepts numbers only.

[odiea]

Yes it is a value of 1000 that is creating the issue. Values below that stay just fine. Can you eliminate the thousand separator.

[daN4cat]

It's probably better to do the proper job. But tomorrow maybe. I close now.

[daN4cat]

OK, one step closer. All the locale, thousand separator included part, is sorted. I even sorted the ajax issue, I forgot to add the json data type.

Next is the prefilling of the values based on transactions and expenses as previously discussed.

I earlier mentioned to put in grey in the background but probably it's simply better to pre-fill the values so they just need to verify the cash in the till drawer and the card transactions from the Z report and job done. What do you think?

[odiea]

Yes. It sounds good to me. Simpler the better for someone that needs to rush home after closing. Does your wife accept checks? It's getting tough here to accept 1.

[odiea]

Were You considering creating a Report. If so it would be nice to see the cashup then in details see the expected amounts from the Register. I know. More stuff to do.

[odiea]

BTW It works great now.

[daN4cat]

We don't accept checks, even a swiped credit card is not recommended. The scam attempts were always with swiped credit cards.

[daN4cat]

The problem of pre-filling is... when to do that! I can assume that if Close cash, close card and close check are 0 we want to pre-fill.

[odiea]

The closer should fill out the info and then management will see the expected amount from the Register in the report along with what the closer stated was in it.

[odiea]

My lack of trust in people these days.

[daN4cat]

I wanted to pre-fill with the values and they just check and submit.

[odiea]

You trust people more than I do. That would be fine with me.

[daN4cat]

I focus on efficiency

[odiea]

25.00 a week may go into an employees pocket. 52 × weeks in a year.

1,300 = from 1 employee who thinks the owners are rich because they own the business. Just a thought. If your wife does not have this issue she is 1 lucky person.

[daN4cat]

We probably live in a more relaxed way over here in Europe...

[daN4cat]

Added the pre-calculations filling in the form.

[odiea]

For some reason I m not getting those values changing now.

[odiea]

Everything works fine just the way it should. No need to add the ; at line 82. What was going on was I was adding a few original sales. Then I would close. After that the newer sales would not update. It appears that if you update the Cashup before actually closing you will not get the full days totals. Hope you did not waste any time on this.

[odiea]

If someone accidentally submits the form before the day close. Closed cash,cards and checks need to be set to 0. Submit the form. Open the form and the correct totals will show.

[daN4cat]

Not sure why my comment was deleted... anyway I fixed a pre-filling issue.

By the way, I'm not totally sure the pre-fill is a good idea in the end. It should be indeed a report of what is the cash drawer status.... I need to think about it.

[odiea]

Sorry I was misunderstanding the logic of prefilling the info. I had no problems once I understood what was happening.

[odiea]

I worked on it a little this evening. I added 4 more tables to cashups with the expected prefix. I am using the auto fill to complete the right hand columns. They will be hidden from the normal user unless they have rights to configuration. Let me know what you think about this. I now have to go in and redo the normal cashup code.

[daN4cat]

So the four text boxes on the right are read only and with pre-fill and the ones on the left are for the shop assistant to fill in and close. Also is the idea to store pre-filled (budget) and actuals in the database as separate?

[odiea]

1. Yes and the pre-filled values will only be visible if you have access to the store config. I figured that should only be granted to admins or managers.
2. I added the following to the cashups table. These are what will retain the pre-filled values. expected_closed_amount_cash decimal(15,2) NOT NULL, expected_closed_amount_card decimal(15,2) NOT NULL, expected_closed_amount_check decimal(15,2) NOT NULL, expected_closed_amount_total decimal(15,2) NOT NULL,

[odiea]

We may have to rethink the Cash payments. I just noticed that if someone pays a 1.00 for a .46 cent item the payment is recorded as 1.00. Maybe another column in sales payments for the amount due. A 20.00 dollar payment for a 3 dollar item is going to throw the till off by 17.00 extra. Just hoping this can help your wife's business somehow.

[odiea]

This would probably only effect the pre filled values.

[odiea]

Ok I got it figured out. I did add another column to sales payments and named it total payments. I did have to add a new summary cashups payments report though.

[daN4cat]

I think the cashup as it stands is usable even without the pre-fill. I've tested a bit and it looks like there are no issue so I'll submit to master and make it part to 3.3.0.

Maybe other people will come up with ideas to improve it, but it's more important to build a end of day report than anything else.