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.
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 
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 
2 Likes
