There is no current ticket id… Ticket ID is not generated until ticket closed. So if its printing current ticket that means somewhere it is closing it. Or it is not reading ticket id at all to print it… it is just simply printing current ticket… which is possible it does not need a ticket id to print.
generating all screen shot
Here it is
all this 4 steps do the job well until new order is entered. once new order entered its print new order not Last one
This might be what you need instead of Load Last Ticket.
1 Like
I realize that. I created the post with the step-by-step on how to do it.
Some suggestions:
In your Execute Print Job Action, replace the Ticket Ids field with a variable (i.e. [:TicketIds]), then in the Rule, feed in the {SETTING:LastTicketId}. It is always better to use variables in an Action, and feed the variable via the Rule, rather than using Tags in the Action itself.
I highly suggest too: just before firing the Print Job Action in the Rule, fire a Show Message to reveal the Ticket ID stored in {SETTING:LastTicketId}, so you can verify that the correct ID is being sent to the Action. If you find that the ID is incorrect for your needs, you then need to find out why, as in, when/where is it being overwritten. I’m guessing that the ID will be zero (0) which is a “dummy” ID meaning “Current Ticket”, so you need to figure out why that is.
Show Message is your friend when in need!
2 Likes
It show me same ticket # 1104 both time
no new order ticket # 1104 Print last Receipt Goooood 
enter new order then ticket # 1104 but print current order no goooood 
still can’t understand why its printing the current order Like Print Bill does
Its not printing that specific ID so we need to figure out why. Your not loading that id into the print action so its defaulting to print current active ticket. Look through your rules make sure the execute print job is set to print specific ID
specific ID ?
this is what i have in my show message Ticket # {SETTING:LastTicketId}
my screen shot is posted and than all i did is change as QMckay suggest and as per his suggestion ticket id is still same but print come out different.
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
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
