Is there a tag to read the value entered on the payment screen.
I have tried {NUMPAD} and [:NumberpadValue] but they don’t work.
{ NUMPAD } is not a valid tag it is { NUMBERPAD } but i dont think we have access to what you want anyway, @Jesse will confirm
What do you want to do?
Its not number pad, there is a separate tag for payment screen values, there on the forum, try searching…
Was added back in v4 LOL;
3 Likes
When the value entered is greater than the remaining total I want to fire a rule.
What are you trying to do? Why do you want to fire rule? What will that rule do and why?
I have a Layaway setup configured with Layaway ticket type set to Pre Order.
On the final payment I want to change the ticket to a receipt and change the date to bring the sale forward to today’s date.
I had this configured after the “payment processed” event and although the ticket type is changing and the date is changing (If i go to tickets the ticket it there under todays date) It does not show up in my EOD report.
I have a similar thing done with Quotes and this brings the ticket forward into todays EOD Report.
The difference is the payment is processed after the ticket and date change so I thought I could replicate this using the {NUMBERPAD} Value greater than {REMAININGTOTAL} to execute the rule before the payment is processed.
I then tried adding a button to change ticket date and type before the payment to check but it still does not bring the ticket forward into the EOD Report.
It must have something to do with the payments already applied to the ticket.
Is there anyway to bring a ticket forward into todays EOD report that already has payments applied?
From my understanding tax is not due on layaways until the final payment is made and goods taken.
Layaway tickets should be handled carefully.
Doing what you suggest I expect will result in bounce declared sales as report printed will show preorder sales for past days and then sales after date change.
Never used preorder as reporting can be problematic if not used correctly. Just test thoroughly and make sure you understand how it’s shown on reports.
I plan to remove preorders from the report because from a tax perspective these are not considered sales until the final payment has been made.
When it is changed to a standard non pre-order receipt I will then show up with normal sales for that day as it should.
I am only using preorder tickets to track the payments.
I use customer accounts for items that are physically taken the same day as I am liable for tax once the goods taken from the store.
I have not attempted this but it makes sense to me that if I were to build a lay away system I would use Entities and Accounts. I would call them Customer Lay-Away accounts. When it comes time to pay it out you can design any kind of automation… including something that creates a ticket with the items on it. I mean you can store items to the Entity…lots of different methods for that. This is just me brainstorming… using accounts and building automation around that would make reporting a LOT easier… i mean after all Lay Away is typically done on accounts not tickets.
I understand what you are saying. Using accounts would make reporting a lot easier but it would complicate other things.
Eg. Giving the customer a receipt every time a payment is made showing all items, previous payments and balance due. I know it is probably possible via print account transaction documents but pulling in the items plus previous payments would require fairly complex automation.
But I think this is a bit excessive when with tickets we already have almost everything required. Printing,changing order items, ticket lister with open layaways etc.
I solved the issue with the ticket date change not bringing the ticket into current workperiod.
Using the Update Ticket Date Actoin changes the ticket date (In database and also it shows in ticket explorer under updated date’ but it is ignored by the workperiod report.
If I update the ticket date using Change Ticket Properties and Change Ticket Date parameter set to TRUE It works as I expected it to, bringing the ticket into the current workperiod and displaying it in the report.
Is there any reason why this function behaves differently in these actions and when should each be used.
Obviously the Change Ticket Properties will only update the ticket to the current date and the Update Ticket Date Action can have a user defined Date but when the Update Ticket Date has {DATE} as the value I would expect both to behave identically.