Looking for ideas for better Cashout Count Reporting

[QMcKay]

Here is a DB Tools file for the Entity Screen: WP_EntityScreen.zip (3.7 KB)

Here is some background info on how it works…

Each Editor Widget has Settings like the following - the Command Name and Local Setting Name is different for each depending on the Currency (HNL or USD) and the Denomination (500,100,50,20,10,5,1,etc). The Refreshing Widgets parameter is pretty much the same for each Editor Widget except for the Currency - this parameter invokes an update to the given Widgets when the value in the Editor Widget changes.

---

The Label Widgets contain calls to JScript to retrieve Task values. They are updated when an Editor Widget value changes via the Editor Widget “Refreshing Widgets” parameter. It is important to set a Name for the Label Widgets in the Widget Properties. It turns out that both the Upper and Lower Label Widgets shown here have the same Name, which we probably should not do, but it works nonetheless.

Upper Label Widget Text (Cash HNL):

<font Consolas><size 12>x 500 = {CALL:str.pad('{CALL:co.getTotal('Cash HNL','500')}','left',9," ")}

x 100 = {CALL:str.pad('{CALL:co.getTotal('Cash HNL','100')}','left',9," ")}

x  50 = {CALL:str.pad('{CALL:co.getTotal('Cash HNL','50')}','left',9," ")}

x  20 = {CALL:str.pad('{CALL:co.getTotal('Cash HNL','20')}','left',9," ")}

x  10 = {CALL:str.pad('{CALL:co.getTotal('Cash HNL','10')}','left',9," ")}

x   5 = {CALL:str.pad('{CALL:co.getTotal('Cash HNL','5')}','left',9," ")}

x   1 = {CALL:str.pad('{CALL:co.getTotal('Cash HNL','1')}','left',9," ")}</size></font>

Lower Label Widget Text (Cash HNL):

<font Consolas><size 12>-------------
{CALL:co.getTotal('Cash HNL')}
- {CALL:co.getTotal('Cash HNL','Float')}
-------------
{CALL:co.getTotal('Cash HNL','Balance')}
</size></font>

---

The Custom Report Widget has the following Settings. Again, it is important to set a Name for the Widget in the Widget Properties.

---

When we change a value in an Editor Widget, it will fire an Automation command such as:

CO Set HNL Count 500
CO Set HNL Count 100
CO Set HNL Count 50
CO Set HNL Count 20
CO Set HNL Count 10
CO Set HNL Count 5
CO Set HNL Count 1
                 |
'[:AutomationCommandName]'.substr(17,3)

We have 4 Rules that handle the Automation Commands depending on the Currency and whether it is Cash or CC. For example, the following Rule handles all Editor Widgets for Cash HNL. The [:CommandValue] will contain the Editor Widget Value (the Count), and the [:AutomationCommandName] has a sneaky way to include the Denomination as the last part of the name which we parse out with substr(17,3) which gives us 500,100,50,etc.

We execute a Script function to set the Count for the Denomination:

co.setCount('Cash HNL','[:AutomationCommandName]'.substr(17,3),'[:CommandValue]')

… and to compute the Totals for the Currency:

co.setCount('Cash HNL','Account','[=TN("{ACCOUNT TOTAL:Cash HNL}") * TN("{REPORT TASK DETAILS:TSC.rate:(TST=Exchange Rate)}")]')

[mjb2000]

OK, amazingly this is starting to make some sense to me. You must have helped me come a long way since I first popped my head up on this forum a few months back!

So let me see if I follow a couple of things…

1. With an editior widget is the “Command name” fired every time a value if change in the box (I guess when the box loses focus?)
2. Similarly, is the “Local setting name” updated as a program setting automatically? We don’t need to use a rule to set this equal to the value - it’s just there automatically?
3. Are you using this command to store the values as a task each time the value is changed? Or is only one task created for each work period (I’m wondering if it would be better to have a “save these values and close work period” button?
4. If many values are stored each night as tasks (perhaps with re-counts etc) does this change how we use the data at a later time?
5. I’m guessing the way in which you are doing the multiplication and addition to get the totals could be done a lot easier if you were doing it directly and not storing the values, but because you are using tasks you’re first storing the values and tasks and then reading them to dislpay the labels?
6. How do you handle overs and shorts at the end of the day? I get that on a daily basis you can just say you were short on a particular work period, but this will have a knock-on effect on the actual accounts screens for the future, no?
7. What are your plans for how to look at the historical data?

[QMcKay]

@mjb2000

With an editior widget is the “Command name” fired every time a value if change in the box (I guess when the box loses focus?)

Yes, when it loses focus or you hit the Enter key, the Command will be fired, and the Local Program Setting will be updated. So you can hit Enter, or Tab, or click on another Editor Widget box, or click on some other part of the screen.

@mjb2000

is the “Local setting name” updated as a program setting automatically?

Yes, a Local Program Setting is automatically updated to contain the Value in the Editor Widget box, so long as you set a name for the Local Setting parameter. Keep in mind, this is stored in memory, not the DB, so the value will be different for that Program Setting from Terminal to Terminal, and will also be lost when you shutdown.restart SambaPOS.

In our case, we could read {SETTING:X} in the Rules to get the value, but the value is passed as the [:CommandValue] anyway, so I use that instead. The only purpose that parameter serves for us is that the Editor Widget will retain the value in the box if you navigate away from the screen and come back to it. Without the Local Setting parameter being set, navigation away from and back to the screen would result in the box being empty, which can be confusing. My previous version of this screen had no Local Setting name - they were all blank… which caused confusion for the operator.

@mjb2000

Are you using this command to store the values as a task each time the value is changed? Or is only one task created for each work period (I’m wondering if it would be better to have a “save these values and close work period” button?

One Task for each of Cash HNL, Cash USD, CC HNL, CC USD, Exchange Rate, and Workperiod per Workperiod, not per change of an Editor Widget Value. I close the Workperiod before doing my counts - that sets the Task to “Completed”. But the Tasks can and are updated when there is a change in an Editor Widget even after they are “Completed”. You could use a “Save Function” if you want, but I didn’t find that to be necessary since everything happens on-the-fly when you change the Editor Widget values. The only “Save” part is marking the Task “Complete” when the Workperiod Ends, and when I click on Print Report, it save the Report to file (XPS) and sends an email with the Report as an attachment.

@mjb2000

If many values are stored each night as tasks (perhaps with re-counts etc) does this change how we use the data at a later time?

There are not many values stored. Just a handful of Tasks with Custom Fields…

@mjb2000

I’m guessing the way in which you are doing the multiplication and addition to get the totals could be done a lot easier if you were doing it directly and not storing the values, but because you are using tasks you’re first storing the values and tasks and then reading them to dislpay the labels?

Previous version did the calculations directly in the Label Widget using the Program Settings with multiplication and addition. It made for rather long Label Widget Text code, but it worked fine.

This version does the calculations in the Script when we call setCount() for any given value, and not only updates the Count value, but also computes values for the Total, Balance, and PlusMinus, and updates the Task in one shot. So now the Label Widget Text code only needs to read the Task values which is does by calling getTotal() which internally calls getCount(). The label Widget doesn’t need to do any calculations because they are already done.

@mjb2000

How do you handle overs and shorts at the end of the day? I get that on a daily basis you can just say you were short on a particular work period, but this will have a knock-on effect on the actual accounts screens for the future, no?

I don’t handle over/short. I could and probably should, but I haven’t found a compelling reason to do so thus far with my small Venues. All I need is to report that it did not balance and by how much, and it is up to my staff or myself to give reason why it is off.

For example, I don’t have a “Float” account. So I don’t balance my accounts. I have Accounts for Cash, CC (Drawer/Till Accounts), and Accounts for my Safe/Wallet which in general contains extra Floats made of change. But I don’t actively track those Accounts through SambaPOS per-say. The Safe is manually handled by always being in balance via the Report wrapped around Cashout, and the extra Floats being a constant value (ie. put L500 in and take 5x L100 out).

@mjb2000

What are your plans for how to look at the historical data?

The Tasks allow for this. I can look at an entire Month in Summary to see my Sales, Counts, Totals, Balances, and PlusMinus. I can pick out 1 week in summary, or the entire year in summary, or 1 single day from the past. The whole point of using Tasks was for Historical Reporting. Here is an example for this month to date (values are not accurate since this is my test machine, but you get the idea) …

[mjb2000]

Amazing info. Thanks @QMcKay

I’ll take a closer look at the task automation stuff you have built to get my head around this “completed” concept.

I have just implemented you idea behind tracking the cash drawer opening, so based on that I envisaged multiple entires in the tasks. So I’ll take a closer look to see how this works with your implementation here.

M

[QMcKay]

@mjb2000

I have just implemented you idea behind tracking the cash drawer opening, so based on that I envisaged multiple entires in the tasks.

That is different altogether. You are creating a new Task each time the Drawer is opened. It uses Tasks as a log entry, like a record in a DB or a line in a file. It wouldn’t make sense in that case to update the Task, so we just create a new one every time. Then when you report on it, you see multiple tasks over the reporting period, like a log, which is what we want.

I recently used Tasks in exactly that manner for WiFi Password. I didn’t really need to log PW changes, but it was easy to implement, so why not?

Using Tasks for Cashouts and Employee Timeclock is different in that you have a single Task per Workperiod. You start and end your day. The Employee Clocks In and later Clocks Out. These are once-per-day things, as opposed to Drawer Logging which is multiple times per day/week, etc.

[mjb2000]

Makes a lot of sense. Thanks for explaining it

[Ollando]

Our currency Has a 0.5 and how can I put it in, Coz I had it but i was not Working. I have 1, 2, 5, 10, 20, 50, 100. But i want a Calculation for 0.5… which is Half a 1.

[QMcKay]

@Ollando

Our currency Has a 0.5 and how can I put it in

You need to read the entire Topic and understand how it works. The information you need to support a denomination such as “0.5” is in this Topic… I explained the logic already here.

[Castech]

Mine is not showing denominations at all. Where am I going wrong

[Dawoodjee]

I’m quite new to SambaPOS, I need someone to help us modify this Cashup feature so that it’s done for each waiter. I’m willing to pay for the work.

OR please recommend someone who can.

Thanks

[Posflow]

@Jesse I am just curious, wasnt there a configuration task for this?

[Jesse]

No there was never one made. We should make one its a common feature request.

[Dawoodjee]

Whats the timeline like, how can I help?

[MarkNarsingh]

hey dude did you ever got help