Currently,the Abacus 21 Point-of-Sale system has two provisions for acknowledging Currency Exchange-Rate Conversion.
Currency Exchange Rate Handling Style #1 -
The first works on the Payment line. It is intended for use after the Guest has paid the bill... or at least indicated how they would like to pay. It can handle an unlimited number of Currencies. It is totally advisory... and the only display of the Conversion is on the Payment Entry screen and the POS Ticket itself.
Basically, the Payment is still processed in the Base Currency -- whatever Currency the Item prices and Ticket amounts are displayed in on the screen. The Screen shows -- just for advice -- what the amounts would be in the selected Currency.
It shows this for the Balance of the Ticket, the Amount Paid and the Gratuity Amount.
This is a conversion done using the Conversion Exchange Rate in the Payment Type file at the moment of the transaction.
The Rate is not saved with the POS ticket. So if the rate is changed in the Payment Type file and the Ticket is recalled, the converted amount will be different than before the rate change.
There is no Currency Conversions shown anywhere else: Not on the Server Inquiry or Close-Out or any of the Payment Type reports. These are always in terms of the Base Currency.
Each Payment Type allows for a (static) Currency Exchange Rate to be defined. In POS Payment Entry, if a Payment Type with a non-zero exchange Rate is selected, the Ticket Total and the Unpaid-Balance at the top of the Payment Entry Dialogue Box is calculated and displayed using the associated Currency Exchange Rate.... along with the Payment Type's base Currency (ie, the Currency used for the normal Ticket Pricing and Sub-Totalling).
Then, on the GuestCheck-Receipt -- for the Payment Amount and the Gratuity -- both the base Currency Amounts and the alternate Currency Amounts are shown.
See the examples below:
Note: The 'Exchange Rates' themselves in these examples are 'fictitious'.
Above is a Payment Type set up for JP (Japanese Yen)... with the Currency Exchange Rate Field filled in.
When this Payment Type is used as a form of Tenderment, it displays both the Base Currency and the Exchange Currency -- for the Amount of that particular Tender... and for the Amount of any added Gratuity (if that is pertinent)... and for the Un-Paid Balances.
The above is a similar example for Canadian Currency (contrasted to U.S. Currency).
And the corresponding Payment Entry Screen within Point-of-Sale.
And above... for Australian Currency.
Below is an excerpt from a POS Ticket (not format aligned):
And... an example (below) of an illustrative Server Inquiry:
And the resultant Hardcopy Report:
The associated Payment Report -
And... the POS Payment Summary Report:
Currency Exchange Rate Handling Style #2 -
The second change is even simpler. It only works with a single Currency... and it is intended to be an "advisory" for the Customer.
It allows for the Total of the Ticket to be presented in a single alternate Currency below the Base Currency... so, whatever the next most common Currency might be, it can be set up to be printed.
Per Section, POS Configuration has the ability to define a Currency Conversion Factor (xxxxxx.xxxxxx), a Currency Label (Prefix and Suffix), and a Currency 'number of decimal places'.
The Ticket Printing Profile has a flag ot indicate if the Currency Conversion is to be printed after the Total.
The only amount that is converted and displayed would be the Ticket Total... and there is no change to the printing of the existing Total Amount (ie, no specific Currency designation.)
Here is the POS Setup Screen:
Here is the Ticket Printing Profile Screen... showing the flag to 'Print Currency Conversion':
And here is an example of the resulting POS-Ticket (not format-aligned):
Future Considerations -
The above represent a compromise for a forthcoming Abacus Currency Exchange Rate handling. This more-elaborate style would imply:
Entering and saving the amounts in both the Base Currency and the Converted Currency.
Saving the Currency Exchange Rate at the time the Payment is entered.
Having a means of changing the Currency Exchange Rate on the POS Ticket so that if the Ticket is recalled at a later date, the Exchange Rate could be changed to whatever it had been at the time the Ticket was created. Or retaining a calendar of Exchange Rates so the rate could be looked up.
Having the Server Inquiry Payment sections show in the actual Currency rather than in the base Currency. Since as it is, Servers can not just count each Currency and compare it to the reports... they have to manually convert in order to balance.
Similar changes in the Payment Type reports form the POS Close-Out - probably showing amounts in both the Base Currency and the Actual Currency.
The System will have a Currency masterfile with a sub-table of rates by date or date and Section -- so that they can easily be maintained in one place rather than having to individually call up each respective Payment Type.
There has been no scheduled date for this enhancement.
