Second currency problem

[chilewillie]

Hi Dale,

I am having a problem getting the POS register to accept a second currency payment correctly. I am using ver 6.08 on a single computer.

I have pos set up with my primary currency in pesos and a secondary currency in US dollars. The conversion factor is reset daily according to the days exchange rate. Rounding is set at 1 for both currencies.

When I process a transaction and choose 'cash' as the payment method, I am given a choice between the two currency types and the rounded conversion amounts are displayed correctly. My problem occurs when I choose the secondary currency (dollars) and the customer pays me in the exact amount due. I press 'enter' to accept the exact amount payment, but instead of completing the transaction, POS will show an odd change amount as being still due by the customer (in pesos, not dollars) and returns me to the 'choose payment currency' once again. I cant seem to accept a payment for this odd change due either, because at this point POS has reverted back to accepting the full purchase price, not the odd change due. I can get POS to accept the transaction if I have the customer pay more than the exact amount due in dollars. When I do this, POS completes the transaction and prints the change due back (in dollars) on the screen. My guess is that this has something to do with a conflict in the rounding and currency exchange features that leaves a bit of odd change in the transaction that it doesn't know how to deal with. I need to keep the rounding set at 1 to deal with payments correctly....I don't care about the odd change amount still due as it is a truly minuscule amount... I just want to complete the transaction with exact amounts (no change back). I have the same problem when I try to do till payouts to the safe in dollars. Any ideas?

[Dale Harris]

Joe Willis,

I sort of tried it out here and it worked fine. First of all the Peso should be your default currency and I assume that it should be rounded to "1"

Dollars however must have a print field of "########.##" because dollars have pennies.

I said, "I sort of tried it out" because I have no idea what the exchange rate is so I just made one up. If you tell me what one of your actual exchange rates are I will use that in a test.

Please remember that the exchange rate that you are given may not be in the form that you need to enter. If you are given the rate of dollars into pesos but the program needs pesos into dollars then you must enter the reciprocal of the exchage rate, i.e. you must divide 1 by the exchange rate.

For example, if the rate is 23.654 but you need the reciprocal then the math is...

1 / 23.654 = .0422761

which means that .0422761 is the rate you need to enter.

To tell if you need to use the reciprocal rate, use the exchange rate you were given and ring up a sale. If the other currency (dollars) comes out as the value of the gross national product of Mexico, or almost nothing, then use the reciprocal exchange rate.

[chilewillie]

Hi Dale,

Thanks for the reply. Here are the current specifics that we have entered in pos for the two currencies.

Default currency: Pesos - rounding 1.
Secondary currency: US Dollars - rounding 1.
Exchange rate: ------.--1612 US Dollar = 1 Chilean Peso

If yous set up a pos example with these settings, then I think you will be able to replicate our problem.

According to your reply then, the problem is probably due to the fact that we have rounded US dollars to the nearest 1 dollar, not the nearest penny.

The reason we need to round prices to the nearest dollar is because we do not wish to accept or refund pennies-change. The problems are many -
1. It is a huge hassle to try and later exchange pennies for pesos because local banks and exchange houses don't carry pennies for exchange (nobody wants them - only dollars)
2. travelers rarely travel with pennies in their pocket (they usually pay with larger denomination bills or travelers cheques) so never have the correct change
3. we never have pennies in our register to issue correct change.

Having POS give us a US dollar exchange rate price for a room rental that ends up being something like '$72.56' means that the system expects us to refund pennies that we don't have when the customer pays us in whole dollars. The fact is our foreign customer doesn't really care - they are fine with rounding out the price to the nearest dollar ( in the above example the price is rounded to '$73.00')- knowing that we accept dollars as a convience to the customer and that rounding out the pennies is normal.

Is there a way to get POS to let us round out US dollar exchange prices to the nearest 1 dollar? Since the program allows us to set rounding to '1' then the assumption was that it would handle this setting correctly.

Thanks.

[chilewillie]

Dale,

Since my explanation of the problem may not be very clear, here is an example sale when pos has the exchange and rounding amounts entered as described above.

Item: 3 person cabaña rental
Price: $35000 pesos per night
Tax included 19%

(Enter and Total)

Select payment type : Cash

(Enter)

Choose payment currency : Pesos 35000 / US Dollars 56

(Select US dollars)

Enter the CASH amount tendered in US Dollars
------------56
Remaining due in US Dollars 56

(Enter)

Result

Sub total: 29412
Tax: 5588
Total: 35000

CashPay: 34739
Total Due: 261


Pay by CASH TOTAL DUE: 261

-------------------------

After pos tells me incorrectly that the customer still owes me 261 pesos after paying me the full price of $56 US dollars, it does not permit me to accept the additional 261 pesos anyway... it reverts back to again asking me to choose between accepting payment amounts of 350000 pesos or 56 US dollars.

Hope this explains it better. Thanks for your help.

[Bobby]

Hello,

I tested this and it is like Dale suggested in his previous post. When you set up the currencies, the rounding option only affects the default currency, which in this case is pesos. If you go into the currency option in posconfig and change the print field to ########.## then go back and make the same purchase, you will see that the dollar amount is really $56.42. That extra 261 pesos is equal to the .42. The program is not rounding this to the closest dollar. So, in effect, if you only took $56 dollars for the sale, you really would only be getting 34739 pesos for the sale and not 35000. I could see how this could be a problem with currencies that do not have decimals. Hope that this helps Dale figure out a solution.

Bobby

[chilewillie]

Bobby,

Thanks for your post. Hopefully that info can give Dale additional insight as to how to rectify this. In the meantime, the solution that I have hit upon is to simply enter as received, an amount $1 dollar greater than the displayed rounded dollar purchase price. For instance if the rounded dollar price is shown as $56, and the customer pays me $56, I enter the amount payed as $57. POS then prompts me to refund the customer a 'rounded refund' amount of $1 dollar and completes the transaction. Although not elegant, (the register receipt prints as my having received $57 and returned $1), it does allow the completion of the transaction and an accurate till count.

As you noted, this is necessary because the displayed rounded dollar price is actually pesos less than the exchange using decimaled dollars. Note that if the peso exchange in decimal dollars is actually LOWER than the displayed rounded dollar amount, (ie POS computes that I will owe pesos back to the customer if he pays the displayed rounded dollar price), it will allow me to complete the transaction. For example if I enter the following sales transaction:

item: 8 person cabaña
price: 60,000 pesos
19% tax included

The system shows the rounded dollar exchange to be $97. If I enter $97 as the customer payment, the system then displays that I owe the customer either 174 pesos or $0 dollars in change. If I select $0 dollars as the change refunded, the system rings up and completes the transaction.
POS only seems to burp and hang if it perceives that the customer owes me pesos more than they have paid, not the other way around.

[Bobby]

Hello,

Note that if the peso exchange in decimal dollars is actually LOWER than the displayed rounded dollar amount, (ie POS computes that I will owe pesos back to the customer if he pays the displayed rounded dollar price), it will allow me to complete the transaction.

And the reason for this is that the program is only rounding to 1 the DEFAULT currency, which in this case, is pesos. It is not rounding to 1 any of the additional currencies.

Bobby

[chilewillie]

Dale,

Any chance that future versions of pos will accept/recognize rounding in currencies other than the default currency?

[Dale Harris]

Probably