Incorrect transaction value after shift change

[stevew]

We have had SambaPOS v4.1.82 running well since 2014. The restaurant has recently moved location and we took the opportunity to upgrade to v5 (5.2.13) now a problem has appeared which I think may be a SambaPOS v5 issue.

For commercial reasons we classify all products as Food, Drink and Non-F&B. The restaurant has two shifts and the staff follow the same procedure as they have done since 2014.

1. SambaPOS is started in the morning with all empty tables

2. In early evening the shift is changed. At this point, some tables will still be open with bills unpaid (for this example assume these are tables 0, 1 and 2 but in reality, will probably be many more). To allow the work period to be closed and a new one started, we temporarily set a pre-order flag and set the entity state by running a simple SQL script via an automation button on a management screen as follows
   

3. The cashier then prints an end of shift report that includes
   a) Total cash transactions
   b) Total credit card transactions (not currently in use as CC is not operational yet)
   c) Value of Food, Drink and Non-F&B transactions

4. If all is well, the sum of c is equal to the sum of a + b and is equal to the money in the cashbox

5. A new work period is started by the new cashier and she updates the table status by reversing the procedure of 2 above

6. New tables are added and paid; checking the end of shift report shows these are updated on the report as they are paid so condition c = a + b remains valid.

7. At some point the tables that were held in step 2 above are paid but the paid value does not get updated on the EOS cash/CC report. It does however get updated in the Food/Drink/Non-F&B report so now a + b ≠c.
   

8. It doesn’t matter whether more items are added to the held tables (0, 1, 2) after the shift change, the final value of the bill is still not updated.
   

9. In the above example

• ticket 885 was added after the shift change and updated the report correctly

• ticket 881 was established before the shift change (value 775) and has not been updated in the report

• ticket 880 was established before the shift change (original value 515) and was added to after the shift change (added 505). Total value of 1,010 has not been updated in the report

10. I have calculated the cash transaction value using SambaPOS
    {ACCOUNT TRANSACTION TOTAL:Payment Transaction:Cash}
    and also with an SQL script; both give identical incorrect values, which is why I think this may be an issue with SambaPOS.
11. At the end of the evening, the cashier closes her shift and prints her EOS report before closing down with all tables unoccupied. In the morning it all starts again

The EOS report is sent to the restaurant owner so needs to be correct. The value of SUM(Food+Drink+Non F&B) is correct and has been verified by calculating from the printed receipts, but it does not correspond to the cash+CC transaction value on the EOS report

[emre]

I’m not sure how you’re generating these reports but this is not a V5 issue. The difference on V5 is payments will appear in the work period report ticket gets created.

[JTRTech]

Posting your report template might be a good idea.
If I had to guess I would guess that the ticket take then falls outside the work period and that would cause issues.
The thing with querky methods like this or preordersnis you have to think about the type of report your using. Wether you reporting on ticket data, order data or payment data. As ticket data would use either the open or close data/time, order report would use the order added time and payment obviously the time it was processed.
This means if you start using pre-orders or forcing tickets to span work periods you can have ticket opened on period, orders added on another and payment on another which then when you report of a work period you then end up with a potentially fragmented report.
The simplest/cleanest way would be to also make sure ticket date and order times are changed to fall within the new work period.

[stevew]

I think I may have not explained properly what is happening here so let me try again. The main point is that the procedure was developed sometime ago and has been working fine with V4. Now it has been put onto V5 it is no longer working.

To simplify it I have written a short report that only has cash and ticket details

The cash is reported in two ways using an SQL query and using the SambaPOS built in function. The SQL is

Let us now start the first work period and place some orders

If we now check the report is shows nothing which we would expect as nothing has been paid

Now payment is made and the report checked again. Both transactions are now correctly reported

Open two more tables and add some items

Do a shift change by setting open tables to pre-order and changing their colour by running SQL script

Close the current work period and run the report

This correctly shows the only two transactions that have taken place (i.e. been paid for) during the work period. Now start a new work period and release the table by reversing the previous actions

Open some new tables and add some items

Check report; correctly showing no transactions

Pay for the newly established tables (21 and 22) and check report again. Now correctly showing both transactions i.e. all transactions within the work period

Now add some items to table 11 and pay for both tables 11 and 12 (tables from previous work period)

And again check the report

Now it shows all the tickets correctly but only shows the cash value from the previous two tickets (tables 21 and 22) i.e. 730. The 1,460 from tables 11 and 12 is not being reported.

• The first work period reported cash transactions of 475
• The second work period reports cash of 730
• Total for the day of 1,215.
  However the actual cash in the box includes an additional 1,460 for the unreported transactions on tables 11 & 12.

Let us now close the work period and run the report for the full day i.e. both shifts

The previously missing transaction for tables 11 & 12 are now being correctly reported and the reported cash matches what is in the cashbox.

Running the two shift reports again independently recreates the discrepancy

My apologies that was a bit long-winded but I hope it clarifies the issue I am hoping to resolve. The problem only happens to the tables that were tagged as pre-order during the shift change so my guess would be that they are being marked as paid somewhere else within SambaPOS but I can’t see where. Note that the original idea of using pre-order was from here

[Posflow]

I had this issue once using PreOrders.

I believe the trick is to put the tickets back to normal mode. However, they need their date changed before they are settled. You can choose that within the Action.

:Edit:

I forgot to mention that if you were settling everything in V4 without changing ticket dates - V5 will move the tickets to the reports they were made in not the ones they were settled in.

[stevew]

@Posflow Thanks for the advice, glad to see I am not alone!

I don’t really understand what you mean by “put the tickets back to normal mode”

Are you saying that the way to do this is to first change the date on the ticket to something outside the work period, do the shift change and then change it back to the correct date?

[Posflow]

From what I understand you mark your tickets as PreOrder before closing Work Period.

Then you open new Work Period when the shift changes. After that you open your old tickets and mark them as normal i.e. not PreOrder. Right?

If you DO NOT have an action in your rule set that changes ticket date to present - in V5 all your tickets that are left open (i.e PreOrder) will be settled in the report they were created in - not in the report they were settled in.

Here is how my work around works.

You will see I started with settling 15$ and made a new transaction with 30$ on it and marked it PreOrder (in my case the button is called Hold). Then I show that it is in fact on Hold. I close and open new Work Period Report, find the Entity it was on and used a button UnHold - then I settled the ticket.

In my reports you can see that the old 15$ ticket stayed in the old report while the 30$ one was moved to the new one and was settled there.

---

My rule for UnHold button has an Action called Mark Ticket UnHold as shown in the previous reply. What it does is basically moves the ticket from previous report to the new one.

[JTRTech]

Preoder in my mind is only usefull in a very specific senario in itself. Beyond pre ordering it’s only use is to allow close period.
Changing to preorder causes the ticket to be reported separately on work period report.
After reopening period as said you need to change it out of pre order as well as change some other details as methiond above.

Work periods aren’t really made to work like this.
Have you thought about alternate methods?
If your just needing to cash up on shift change you could setup two cash types/drawers for shift 1 and 2 and just print work period on change checking shift 1 payments then actually closing work period at end of day?

[emre]

@stevew I’m trying to keep tickets and all related transactions in the same work period. I’m intentionally doing this. So the date range on your sql script will not filter payments made in that time range. It will list payments made for tickets that got created in that range.

This post may give an idea about a possible solution.

Help with reservation/Preorder workflow

silentbob report tags are useful to create reports without dealing with SQL but you are not limited to report tags. Instead of trying to match it to what reporting tag offers you can use SQL to prepare your reports as exactly you want. I’ve prepared an example about how to filter payments by payment date instead of ticket date. Create a new script. You can access that script inside reports via @@Payments handler. [image] This is the SQL Script. Select Payments.Name as PaymentName, Payme…

[stevew]

Understand now. It’s payments that I am interested in so it makes sense to take the values from the payments table rather than Tickets. Will go through my scripts and address accordingly.

Many thanks to all those who offered their assistance

[Jesse]

I have changed the topic to Question since this is not a V5 Issue