How to Print Last receipt?

Show message has nothing to do with the print action it just verified your program setting was stored. You need to now inject that stored ID into the actions Ticket Ids field and then execute it.

Try playing with some of the settings in the Action and Print Job?

Print Job:

Automation Command:

Action:

Rule:

1 Like

Except, it doesn’t work, just like @allmixedup is saying.

It RePrints last Ticket, UNLESS there is a New Active Ticket, in which case it prints the Active Ticket for some reason… can’t figure why.

The Show message is displaying proper Ticket ID, but the Print Job is ignoring it.

[LAYOUT]
-- General layout
<J00> | 
<EB>
<C11>*** REPRINT ***
<DB>
<J00>{TICKET DATE} {TICKET TIME}|Server: {USER NAME}  #{TICKET NO}
<L00>Ticket ID:{TICKET ID}  Setting:{SETTING:LastTicketId}

Last Ticket - Notice Ticket is correct:

New Ticket, clicked RePrint button:

Print produced… NOTICE: Ticket ID is BLANK!!!

Maybe Ticket ID’s setting in the Action does not do what we thought… maybe we need something else or more clarification on it. It sounds like its working regardless of Ticket ID loaded in that setting. I wonder if its printing both? We are all using Notepad if it is printing last ticket and then printing current ticket it would be hard to catch that.

@kendash

I am using real printer (almost 1/2 roll is finish by testing this) and still one print. i was thinking same that if it’s print current ticket why it’s not printing the old at the same time so we can filter out current ticket printing by its state and solve this problem

@QMcKay Yup that exactly what happen to me

Ticket id will be blank if its current ticket as it has not generated yet. So what we have is no way to print a specific ID. Maybe @emre can help with this.

Or maybe its one of those things we do not have access too while open ticket just like how it wont activate a trigger in middle of ticket

So for it to print the actual ticket has to be loaded… it will not print from just an ID. This means you would have to follow a process of Closing the ticket you have open, loading old ticket… printing, then reloading the original ticket you were working on… and it would not be easy nor would it look very seemless.

This might be by design maybe we should not be trying to print old tickets when we have a new ticket we are working on. We should finish with current customer and then help with the other issue.

I’m guessing it is due to something like that.

In fact, it will just print from an ID. The Ticket doesn’t need to be “loaded” (there is no Load Ticket Action being used here anyway), and it doesn’t need to be closed after printing… Maybe the Execute Print Job Action is handling all of this behind the scenes, or it’s simply not necessary…

I thought I mentioned this earlier and said it wouldn’t be worth the trouble, since you need to assign an Entity to be able to close a Ticket… it would be messy.

I see 2 possibilities here:

  • Don’t try to RePrint when a Ticket is Open. This could be achieved by disabling the button when the Ticket State is New Orders.
  • Have @emre add the ability to call a Print Jog with a previous Ticket Id, and ignore the currently open Ticket.

If Execute Print Job action receives a Ticket value it will skip all configuration and print that ticket for good reasons. @allmixedup I think that setup fulfills your “printing on demand” case and it allows you to use single button (print bill) for both tasks. If there is no active ticket on screen it will print last ticket, otherwise active ticket…

What you are trying to do will allow operator to print Customer X’s ticket while receiving order from Customer Y but I’m not sure if operator should be able to do it that way. Having two buttons on screen for printing different tickets might lead to issues. If there is a visible ticket on screen and if operator prints something it should be the active ticket.

OK I’ll stop being smart and coming to the fun part. We can use a dirty trick to hide active ticket from execute print job action so it will use TicketId to print bill. Our hacking tool will be mysterious Modify Variable action. With that action we can alter action variables. It accepts a regular expression (find value) and replaces it with replace value. It basically works with variables that holds string values and you can use it to strip unwanted chars (for example % from mag card data, blanks or non numeric values from user entered values… ).

Active ticket also passes through actions as a variable behind the scenes so if I modify Ticket variable it will become Null for next action.

I left Find value empty and typed . as the Replace value. That will corrupt Ticket value so next running action wont be able to read active ticket. So executing that action before Execute Print Job action will force Execute Print Job action to use Ticket Ids

Note: It might not always solve issues magically as shown here :slight_smile:

1 Like

LOL, now should we refer to SambaPOS as the “Hacker’s POS”?

Yeah I built amazing hacking stuff to hack SambaPOS itself . Seriously what we’re doing is literally hacking execute print job action :slight_smile:

2 Likes

It works!

Add Action:

Add Action to Rule for Automation Command before calling Print Job:

1 Like