Great. Thanks for letting me know. I’m pleased it was helpful
Hi… Just checking in again… Do you know if you will be able to update this issue any time soon?
Thanks @VehbiEmiroglu
Not to much time we need. Just new products coming. After that we will update this.
1 Like
@VehbiEmiroglu I see you are close to releasing a new version of SambaPOS… I am excited to see it.
Will this bug be fixed in the new version?
Mjb2000 I will add it to the redmine for tracking.
1 Like
could you please share a step by step your way of doing it in comment 38.
as i can not see the full screen shot, and i do not know how the X Execute script was made.
I would appreciate it a lot.
Just wondering if this is on the schedule to be fixed anytime soon.
It is still here this little but consistent bug 
and I ran into this issue as well and yes also as part of some pre order changes done to delivery and pickup tickets…
I just wanted to share my solution to this problem because the procedure described above works but has 2 caveats:
- It updates both Sale and Payment transactions - but the date of the Sale transaction is (or was ) correct.
- It updates all Sales and Payment value dates of all tickets whenever a ticket closes which is kind of a brute force attack.
Thus you have to join the table AccountTransactionTypes as well to only get the ‘Payment Transactions’ and you have to provide the Ticket Id in order to only change the actual ticket which has been paid. This way you alter only the dates of the payment transaction records associated to one ticket.
I added a rule firing on “Payment Processed” and set a ticket state when all the payments have been received:
And then after ticket closing (or ticket closed) I ran the script to update the particular records of this ticket.
The script is as follows:
function adjustPaymentDate (ticketId) {
var qry = "UPDATE [AccountTransactionValues] SET [Date] = C.[Date] " +
"FROM [AccountTransactionValues] A " +
"INNER JOIN [AccountTransactionTypes] B ON A.[AccountTransactionTypeId] = B.[Id] " +
"INNER JOIN [Payments] C ON A.[AccountTransactionDocumentId] = C.[AccountTransaction_AccountTransactionDocumentId] " +
"WHERE B.[Name] = 'Payment Transaction' " +
"AND C.[TicketId] = '"+ticketId+"'";
// dlg.ShowMessage(qry);
var result = sql.ExecSql(qry);
return;
}
That will update payments, too.
Imagine if the guest pays cash for a pre-order last Wednesday. At the end of shift on that day the till should balance. Now, change that payment date to today. Today’s till will be short by that amount.
What about tips? A guest tips and you tip out that day. Change that transaction date to day, and there will be another tip out.
Your scenario describes precisely what is not supported by SambaPOS - SambaPOS does not support the notion of managing a ticket over several days. It rather provides you with the pre-order flag such that one can roll his own solution. That’s okay - it is like it is. But there is a bug that all payment transactions are dated/timed wrongly, which is true for every single ticket not just pre-order tickets. Let’s assume you have 2 cashiers in 2 shifts over a day and the first one does not annoy all customers claiming that she now has shift end and so they have to pay. When these customers finally pay then this cash will pop up as payment in the first shift and you might fire the first cashier and provide the second one with an overachievement award :-).
The solution for pre-order tickets is that one should not allow payments against the ticket up to the day the ticket is being fully settled and closed. Prepayments can be recorded as a deposit or using Customer Accounts.
1 Like
Sambapos was not designed for tickets to span work period you are correct. And pre orders were not designed as a workaround for that.
Can you explain better what you need and why you are using preorder tickets for it?
Tickets are not dated or timed wrong but perhaps you need something more for your use case. We can understand what you need if you can explain your work scenario better
There is a feature that lets you change ticket date. It’s an action. This may be what you need for your automation but it is hard to tell yet.
I think alot of problems could be elimated, or greatly reduced, by changing the Report Payment report from using ticket dates to payment dates.
Right now, if a PreOrder Ticket is created, say on a Monday. Then, on Tuesday, a person comes in to pay a deposit or down payment on that PreOrder Ticket (created on Monday). Now, if I run a Payment Report on Tuesday, the payment will not show up on the report. If I run a report for Monday, the payment will show up on that report. You can see the confusion this causes when trying to balance the till at the end of the day or end of a shift (in both cases in the most recent postings).
I made a SQL Report to use Payment Dates and that has elimated the confusion of trying to figure out which day a payment was made and what day it was applied to.
I not sure how to handle the Ticket Report(s) that have payment info. Maybe that is not an issue, since a person would want all the info regarding the ticket, not payment date info. I could be wrong on that though.
2 Likes
Here is an animation to illustrate what the OP is talking about.
The setup:
1st ticket is a Unpaid ticket on table 10.
2nd ticket is a Reservation Ticket (PreOrder Ticket).
3rd & 4th tickets are tickets paid (cash) at the time of the ticket being created.
Payments: I have the payment amounts to reflect the payment number (payment number 1 is for $1, payment number 2 is for $2. etc.)
The first 2 payments show up in the correct order (ticket created and paid at the same time).
The 3rd payment ($3) you would expect to show-up under the 2nd payment but as you can see it jumps above 1st payment.
The 4th payment ($4, first ticket), again one would expect to show up at the bottom of the list, but again, it just to the very top of the list. This doe not happen with just the ticket time, but dates as well.
I don’t think the issue is with PreOrder tickets but rather when the payment gets posted…using ticket created Date/Time.
Actually I think it’s neither. I think it’s how the screens are set to view the data. They are using work periods and tickets within those.
I think the issue is in the screens. It’s a complicated thing to fix. We can look at it.
If you look at payments table… the payments are recorded with the date the moment the payment is made. This is a screens issue and reports issue with how the screens are designed to work within a work period.
If you look at the payment date/time stamps on the account screen, they are showing times prior to payment times.
Yes but that SCREEN is using ticket date… which is how the screens are designed. Payments date is the moment its paid.
Yes, you correct, payment tables does show the correct date/time.
This is not an easy fix… The screens were designed a specific way around work periods and it was done prior to preorders and these newer configurations etc. We need to think about it and we need to design something new for these situations.
For the time being you can use SQL to build reports you need. But any entity screens remember are bound by this Work Periods scenario.