Cashup

[odiea]

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

[odiea]

I hope to see it where it should be and not on a new screen. I get this in add and update but not on delete.

[jekkos]

Maybe check the server http status code for this request. Is it 200 or 500? Could be that in the latter case the javascript crashes and redirects the browser. An error might have gone uncaught. I usually check PHP side by stepping through the code to see where it goes wrong. However if you enable display_errors you might as well quickly spot where the problem is.

[odiea]

The error log shows nothing. Below is what I got from firefox. I have index.ini set to development. There are no on screen errors showing. I am not using composer. I am just editing the unstable zip.

[jekkos]

Ok server side looks all fine. It's probably a javascript error in the form submit handling.. might be easiest to set a brreakpoint somewhere in that code (?debug=true) and try to see until where it keeps going

or first check the console for javascript errors (maybe enable to persist them as they could be cleared when the browser opens up this page with the JSON)

[odiea]

I can see the issue but can not figure it out. I used the expenses module to create cashups from. The following is the reponse that expenses gives. Much more info.

[jekkos]

Looks rather OK from server side as well. It's probably a javascript crash somewhere in the processing of the received data, annoying thing is that it's redirecting the output which causes you to miss the real error.

Can you push that branch somewhere I might want to have a look?

[odiea]

After talking with the boss she said her and her employees thought this was too much info to fill in in the morning. So I have changed it to a basic version. If this is still worth the effort let me know and I will put it up on my branch.

[odiea]

I redid the view form and it started working correctly. I really did not see much difference between the 2 but I am happier now. Thanks

[daN4cat]

Great, well done! Share the code time?

Is that the starting of the day cash story?

[daN4cat]

Disregard my second question... too much work and stuff this week.

Now the next thing would be a journal log and summarise all the inputs: transactions of the day, expenses and money in and out. It would probably good to add the entry for the various CC totals per day (e.g. Visa, Mastercard, Amex).

[odiea]

Currently it is the open cash entry at the beginning of the day. Then when the second date is selected with a different employee is the day close. Itemizing the cc's would be a pain unless there was a drop down menu in payments to select the card. Most employees don't care if it's mc or visa so a credit card catch all was initiated. Yes this would work well with Takings and Expenses to update the Daily Business info.

[odiea]

The first image was the full attempt for cash entry. I am not knowable in js so I quit that one and went to a simpler cash entry. My wife also used a separate processor then what was provided by the program she was using. Friends in the processing companies gave her a better rate. I will continue working on this with other suggestions being added . I tried keeping with the current OSPOS register settings.

[odiea]

The current issues I am having is some js to add the totals in the form and also I am using an alt_employee field for the second employee and name is not showing in the table view. It shows properly in the db and the form but not in the table view. I slowed down on it due to the return issue but now that that is fixed I am able to keep adding different fields to it.

[daN4cat]

@odiea if you share we can work on the js for the total. Re-reading the past comments, I agree, a simple start of the day cash would do. The previous version was too much. WRT CC itemisation it's fine one entry. Something we should probably consider is having the calculated amount based on the daily transactions and expenses as reference. At my wife's shop they spend some time to double count cash because of some mistake, so they need to know what is expected or fix a transaction payment type if they made a mistake.

Once you have finished and you can share, we can consider a log showing all the daily transactions summary in one table line with second line details for each entry part.

Well done and thanks.

[odiea]

Great idea. When we were using Traxia the employee would fill out a form and submit it. The management would get a blank form with the daily Traxia Sales totals to the right in a different column. I will zip and upload or upload the to my branch. Which ever 1 you would like,.

[daN4cat]

Zip file is fine

[odiea]

The date I downloaded and installed it. The sql is in the migration folder. Check it out when you get the time. Thanks Odie

ospos11118.zip

[odiea]

Should we add Visa,Master Card, Discover and American Express to the drop down payment in the Register?

[daN4cat]

No that would be too much! Also there are international cards like Diners used by Japanese.

[daN4cat]

I just imported the code in a private branch against the latest master. It's not tested and the sql script is not ready yet. I'll look into those details in the next days.

[daN4cat]

It will take longer because home here is an infirmary due to the flu. My son just recovered (good so he can go to school tomorrow!), my wife is in bed and I'm so and so but not being hit yet. Well it's that time of the year, so time to rest :-)

[odiea]

Yes I know. It took myself and my wife 3 1/2 weeks to recover from the variety we had. Hope you all get well soon.

[daN4cat]

@odiea please check the feature/cashup branch as I committed the reworked code.

Please remove your current cashup table (or change it manually) and use the latest upgrade to 3.2.0 migration script. I needed to rename all the fields as it was a nightmare to understand amount1, amount2, etc.

Also check the form as the total is calculated automatically as you type in values. I changed the notes position and in the view it shows with a symbol instead of a number.

I need to work on the sum to support the currency formats, as it stands just works but doesn't support thousand symbol and etc.

What else do we need to add? Maybe pre-fill in the edit box background (greyed) the cash, cards totals from the daily transaction?

[odiea]

Currently the only other issue is the alt_employeeid is not showing a different name. I was hoping that 2 employee ids could be used on the same form. My idea was employee 1 could open the store then a different employee could close the store. Or should we consider as an employee logs in and out a new cashup should be created and just drop the secondary employee? As usual you have done a great job so far

[odiea]

Maybe pre-fill in the background (greyed) the cash, cards totals from the daily transaction? That would be a great idea.

[daN4cat]

I'll look into the employee issue and prefilling of the calculated cash, card, check totals = transactions - expenses.

[odiea]

1. It appears that opening cash is not included in the total.

   $('#closed_amount_cash, #closed_amount_card, #closed_amount_check').keyup(function() {
       var sum = Number($('#closed_amount_cash').val().replace(',','')); 
       sum += Number($('#closed_amount_card').val().replace(',',''));
       sum += Number($('#closed_amount_check').val().replace(',',''));
       $('#closed_amount_total').val(sum);
   });

2. You said your wife had a petty cash fund. I assume it is not in the register or am I wrong.
3. The current plan is to use all the cash transactions for the day from expenses?

[odiea]

Another idea is do we make it a mandatory feature with an app config. Someone logs into the Register and the open amount is 0. A modal with the form? After an amount is entered they are allowed to make Sales. I know this is a lot of work and is it worth doing it for public use?

[daN4cat]

1. You are right
2. Good point: the cash goes out of the cash drawer even for petty cash expenses. There is a small cash safe box to store extra cash taken from the drawer. That's actually something it should be probably captured in a comment or with a checkbox so you know why cash from the previous evening doesn't match the following day opening. Or add a field for cash moved out of the drawer + or - according to the transfer direction so you can even manage intra day top ups.
3. I assumed expenses was from drawer. Not a backoffice operation. So expenses and transactions need to balance the end of the day position.

Does it make some sense to you?

[daN4cat]

4. Probably we need to consider a check in / check out story indeed. I'll ask my wife as she sees the business process / user workflow.

[daN4cat]

4. Probably the check in / out should be done at login / logout time popping up the cashup form

[daN4cat]

3. My wife told me that they need to manage expenses out and in, in the sense that a tailor authoring is anticipated on behalf of the client (cash out) and when the client collects the garment the cash comes back so a negative expense. I didn't check if that's possible but I need to make it happen.

[odiea]

With the check out option maybe a close or continue without close. This way the last employee can do the close. I know a small shop works this way. Wives are great aren't they.

[daN4cat]

Yep, requirements spammers!

[daN4cat]

Ok, we can leave the close to the cashup view itself.

[odiea]

Maybe a logout warning then . "Did you need to Close?" Yes they stay in Register no they continue to log out. Employees are almost as needy as wives. Ha Ha

[daN4cat]

We'll figure it out. That would be later. I want the feature to work first with sums working fine and the field we need. Adding mandatory check in / out is a secondary step.

[odiea]

Great idea. Let me know when more testing is required.

[daN4cat]

So the mathematical formula is:

• cash = cash close - cash open - movement from/to safe;
• total = cash + card + check.

To balance with:

• cash = cash transactions - due transactions - expenses
• card = card transactions
• check = check transactions
• total = cash + card + check

I always assumed that due was a cash story. Sounds right?

[odiea]

Yes. I believe due is a payment that was received that business day.

[daN4cat]

Due is a credit, so actually no cash came in... but the problem is when they pick up the old transaction and they permute due to cash, real cash moves in. So that is an issue.

I'm not sure I want to fix this as we don't use the due (credit). I will ignore...

[odiea]

I would do that unless Due amount is changed to a minus amount or a balance due.

[daN4cat]

@odiea I committed to the branch more changes:

• Fixed the employees part
• Added cash transfer
• Part fixed the sum (it works only with positive numbers). I need to switch to the accounting.js lib to do the correct thing here

Please be aware that you need to change the db table.

[odiea]

So far so good. The following db info needs to be changed to. ALTER TABLE ospos_cash_up ADD PRIMARY KEY (cashup_id), ADD KEY open_employee_id (open_employee_id), ADD KEY close_employee_id (close_employee_id`);

[odiea]

The way it is now. At close time the employee needs to deduct the opening cash from the till. Then adds up the rest of the cash in the till?

[daN4cat]

Thanks I'll fix the indexes.

Not sure I follow. We discussed the maths yesterday. I'll read and think about again later...

[jekkos]

@daN4cat Adding business logic in a frontend is never a good idea.

Wouldn't it be better to add a ajax call for that and process the summation in php with the configured locale settings for the store? That will also relieve us from adding an extra javascript plugin just to do a simple summation. Also it will ease the locale parsing as now you're redoing that logic in jQuery

[daN4cat]

@jekkos yes and no, depends on the latency because I wanted to have something more interactive. But you have a point due to the fact that we already use the backend approach in other places, so let's be consistent. I will use ajax calls to do that and make the change only when somebody has filled in the field not on keyup.

Better to suggest @objecttothis to do the same for his validation work on giftcards.

[jekkos]

Ok understand about the interactivity, there might be a little more latency but I don't think it's worth the pain if you consider all the logic to be done concerning rounding, formatting that's in the backend only..

Maybe I missed @objecttothis his contribution on that part, so might want to give it a look. Always good to better to have validations both on front- and backends.

[daN4cat]

@jekkos see #1694. To be honest I didn't look into it too much and thinking on twice he's probably doing something similar on the front end.