Work Period Report crashing

I think, I will remove Ticket Tags, since I now have the open to track payments by Terminal.

But, I still can not remove Payment after ticket is reopened.

@emre,

Thank you very much for your help today. I think, i will remove this feature because it is easy to make a mistake by our staff.

Best Regards,

This feature should really be used by you or a trusted manager. I dont think I would ever let my staff use it.

@na1978, you can limit the Roles that can use the button easily…

1 Like

@QMcKay,

Is there a way to automatically remove existing payment before re-opening ticket? Thanks.

You can tie a command together that removes payment on ticket reopen.

Great. I will play with it today. Thank you @kendash.

The remove payment should happen after ticket reopen action. It will seem like it happens at same time I you tie them both in to same command button. Just be sure cancel payment happens after the reopen ticket action in your rule.

The Tutorial for Re-open Settled Ticket & Cancel Payments is set by default to Re-Open the Ticket then immediately Cancel any previous payments.

If you’re talking about removing Ticket Tags as well, you will need to do that in an extra step… my preference would be to not remove Payment Type Ticket Tags since it would delete history of Payments (Ticket Tags).

1 Like

@QMcKay it dispalys wrong values in reports. That’s why he needs to remove payment tags.

@QMcKay, I need to remove Ticket Tags because it is causing Work Period Report to crash. (It seems that is trying to divide by zero)

I am still learning SambaPOS. It possible to show me what Actions or Rules I need to make to remove Ticket Tags?

It is same as tagging a ticket with action. To remove tag you’ll set an empty value.

@emre, that is what I was going to say… the problem I foresee (which would be an issue in my case) is that the Ticket Tags for Payment type may be dynamically generated to include the time and Payment Type. Therefore, we have no way of knowing the name of the Ticket Tag (programmatically) that we need to update.

In the example above, the Ticket Tags which are prefixed by PMT are generated dynamically to include the time and Payment Type:

PMT 08.12.176 [Credit Card]
PMT 08.13.357 [Cash]

I can’t think of a way to update the above Ticket Tags since their names are dynamic.

Something I have thought about. What if Ticket Note had ability to read {CHANGE AMOUNT} or other Ticket Template tags. You could create a Ticket Note and it would display the same information and you could recall that info.

I do not even know if that’s possible or not.

First of all I’ll try to solve the confusion. @na1978 implemented it to generate terminal based payment reports.

While working on @na1978’s database I’ve noticed he is voding already settled tickets. Since we generate reports from ticket tags these should be removed as well to generate correct numbers in reports.

Now we are talking about a different issue here. If we’re generating dynamic tag names how we can untag these… To be able to untag a tag we need to know it’s name. So maybe what we really need is a new feature to add notes to tags like we do for order tags.

Ticket Tag Notes would probably work, or…

How about use of wildcards?

Update Ticket Tag:
Name: PMT *
Value: (payment Cancelled)

@QMcKay

I tried to remove Ticket Tags when re-opening tickets, but it does not seem to work properly. I will switch to Custom SQL reports in order to pull Payments by Terminal.

@na1978 Custom reports is a very good way to build it as they keep it separate and sorted the way you want. @emre A new method would be great. I was thinking making Printer Template Tags work in Ticket Notes would be great because it would also display that information in the Ticket Note section of the Ticket Viewer. The only drawback would be the interaction with Kitchen and using actual order notes mixed with the Tag notes.

If you do design something new for this function, an ability to view it as a cell in the Ticket Viewer similar to how Ticket Notes do would be great.

Implemented for 4.1.50