Rounding and issuing change in multiple currencies

It would work if we knew if there are any other Ticket. Like Ticket.PSum if there is something for remaining amount. Custom Calculation Method would work at that point.

Yah, I did some searching on the Forum and these are the only ones mentioned:

result = (Ticket.PSum + Ticket.PreSum - Ticket.Tax)

Handler must be: Calculation_<calculationTemplateName>

So is there any way to make this refresh happen automatically? For me, the adjustment amount or the change in balance didn’t appear until a refresh, so it’s strange that the calculation is appearing for you?

try adding these actions


put them in same order, refresh before payment screen in theory it should work as the first action will show ticket and second will put you back in payment so in other words a refresh

In fact, you don’t need the Display Ticket action, you only need the Action for Display Payment Screen. Put that Action in a Payment Processed Rule. This solves the problem of the Balance not updating, and will probably solve the same issue you are having with not seeing the Calculation being applied.

Here is an example where I have a constraint and some other Actions for testing, but you could remove all of those things (you might want to keep the Remaining Amount Greater 0 constraint though) and just have the single Action in that Rule…

2 Likes

Seems there is some more magic in a Custom Calculation that I just stumbled on from a past post.

See that funky “round up” text in there?

@emre, is there more hidden functionality in Custom Calculations?

I was searching for a method to always round UP to nearest whole number, and I thought that Round Ticket Total Exactly was supposed to do that, but it does not appear to work in a Payment Processor. The example given uses a button-less Calculation Selector …

This exchange rate stuff is starting to drive me insane :confounded: :stuck_out_tongue_winking_eye:

1 Like

Well I really didn’t expect it to become that much complex. Am I missing something simple? I don’t think any POS contains that much detail however without handling it properly it is really hard to report cash amounts properly…

Old scripting engine had that specific language for such operations. JS engine does not have it.

Can we use JScript there? If so, we could use something like JS Math.ceil() to get always round up to next integer …

AFAIK these are the Rules:

  • name the Script Handler as: Calculation_<calcTypeName>
  • assign calculation result to: result
  • we have only these values to work with:
  • Ticket.PSum (non discounted amount)
  • Ticket.PreSum (pre tax servicing amount)
  • Ticket.Tax (tax amount)

It is just a complex matter. Especially when we want constraints like I mentioned (no coins/decimals), round to nearest 5 or 10 for foreign, XR is some large rate that we need to invert (23.3), etc).

Not sure,

however this behavior would probably solve “my issues”, because I have nothing in place that produces decimals (discounts are fixed (not percent), and all prices are whole numbers):

  • click the currency “switch” button on the bottom-left to change to foreign
  • rounding rules take place immediately for the foreign currency, rounding up to nearest 5 or 10
  • click it again to go back to default currency
  • foreign currency rounding is removed

If that ^ happened, I wouldn’t need to worry about default USD rounding rules at all - they would not need to exist - only foreign rounding rules would be needed, and they are toggled on/off by the click of the currency “switch” button :wink:

EDIT: Hmm even that would not work for me I think LOL. Rounding removal defeats the purpose, unless the customer is paying in full… baaah!

EDIT2: I still think that a way to round [:RemainingAmount] might be helpful somehow, though I can achieve that through script and action I guess…

Exactly - This is what I said in my opening post. I am very happy that SambaPOS already does so much more than many other POSs, just a could of small tweaks to get the final pieces in place and it will be amazing. Like you said, it’s how to handle the small little amounts of money that is difficult.

1 Like

I think I have a solution that I am happy with now. It comes with the addition of the feature recently added to only round when fully tendered in the Payment Processor.

2 Calculation Types, neither is applied automatically (no Calc Selector), and they are both round UP. Foreign currency (HNL) is configured to round Ticket Total, and default currency (USD) is set to round by Fixed Amount, so that I can use a Rule/Action to apply it:

A Payment Processor is configured for foreign currency (HNL) Cash only to round UP, and only when fully tendered payment is received. No Payment Processor for default currency (US):

A Rule for Payment Processed event handles rounding UP by fixed amount (USD) to whole number when the Payment Type is foreign currency (HNL) using a rounding script based on Remaining Amount. This gets rid of any decimals in the Balance owing, so no coins need to be in play.


So assuming I am happy with that setup (ie. more testing does not reveal any strange scenarios), I am now going after looking at what @mjb2000 is talking about regarding storing XR values or whatever… @mjb2000 can you explain that very clearly to me one more time please?

Take a look at this screen shot. My rate is 21.00

To produce this I…

  • Settled a $70 item
  • Discounted by 9% (to give me some tricky numbers)
  • Took 60 USD payment with no rounding applied (at this point the customer owed 77.70 MX)
  • Took 280 MXN payment with no rounding
  • Gave 5 USD change
  • Gave 97.30 change

But it you look at the recipt, the intricate values and not correct. Like I said, chances are these could be fixed by your latest rounding solution, but maybe not???

Please paste here the Printer Template used to produce that print.

For formatting in the forum, start and end your content with 3 backticks, like this:

```
pasted
   template/code
       text
```
1 Like
[PAYMENTS:Cash (MXN)]
<L>Cash (MXN)
<J> └ [=F(TN('{PAYMENT AMOUNT}')*(F(1/TN('{EXCHANGE RATE}'))))] @ [=F(1/TN('{EXCHANGE RATE}'))] MXN/USD|{PAYMENT AMOUNT}

[PAYMENTS]
[<J>{PAYMENT NAME}|{PAYMENT AMOUNT}]

and…

[CHANGES:Cash (USD)]
<J>{CHANGE PAYMENT NAME}|{CHANGE PAYMENT AMOUNT}

[CHANGES:Cash (MXN)]
<L>Cash (MXN)
<J> └ [=F(TN('{CHANGE PAYMENT AMOUNT}')*(F(1/TN('{EXCHANGE RATE}'))))] @ [=F(1/TN('{EXCHANGE RATE}'))] MXN/USD|{CHANGE PAYMENT AMOUNT}

Ok thanks - let me see if I can reproduce the issues and see if there is a way to work around them or a need for some other tags.

1 Like

So in your print, the incorrect values are the Change Amounts, correct? Is that all?

For some reason, I am not getting ANY Change Amounts at all on my print and not sure why. This was never an issue for me inthe past, but now they have disappeared. Even the Ticket-level {CHANGE TOTAL} is 0.00 for some reason.

Can you show your Change Payment Type setup please?

EDIT: got that working … seems we don’t use the Change Template Name - need to use the Account Name used in the Change Template. Weird. Do not use the Red arrow; use the Green arrow in Printer Template…


EDIT2: @emre, why is {CHANGE TOTAL} not working? I had to use this instead:

<J00>CHANGE TOTAL:|[=F(TN('{PAYMENT TOTAL}')-TN('{TICKET TOTAL}'))]

@mjb2000, here is my result… the values I use are the same as you, with the exception of a Round HNL + calculation that is applied by the Payment Processor on fully Tendered.

The values seem correct.

HOWEVER - and this is very strange - when it comes to the Printed values for Foreign Currency they look a little “weird”:

Tendered HNL : 280.00 / 21 = 13.3333  (13.33)
Print        : 279.93 / 21 = 13.3300  (13.33)

Those ^ calculations are both TRUE, and:

Change HNL : 95.00 / 21 = 4.5238 (4.52)
Print      : 94.92 / 21 = 4.5200 (4.52)

Those ^ calculations are both TRUE as well.

I think we might need to apply a Rounding calculation in the Template for Payment and Change Amounts for the Foreign Currency so that it does not look so strange. Of course this will only work if your XR is a whole number with no decimals; otherwise, you wouldn’t want the Rounding to occur in the Print!

Yes, I applied a Math.round() to the result, which works, but I think it’s not perfect because you would have to decide if you apply this rounding to each payment method (eg, probably not for card payments). I think it would be more robust to store the true amount taken/given alongside the payment date and exchange rate.

1 Like

I don’t think {CHANGE TOTAL} is listed anywhere as a tag that we can use. I had to use the same equation as you in my recipt template.

It is a tag in the main Ticket Values section, which makes it usable anywhere in the [LAYOUT] section. I was using it before all this currency stuff. But now it does not work (returns 0.00).