When we post an invoice from a US vendor, the posting journal appears to do the correct conversion however, when we print US checks, the conversion operation is reversed. Currently we have the conversion set to multiply. It appears that it does it correctly when posting invoices but incorrectly when printing checks.

This is the first time printing US checks.

Any help would be greatly appreciated.

Hi Sheldon,

When creating multi-currency transactions - either invoices or payments - the Rate Type is what determines the exchange rate and operation for the other currency. The batch amount is entered as the currency of the vendor, and the exchange rate determines the home currency (CAD) equivalent. Since you want to multiply the US Dollar amount for your US vendor to get the CAD equivalent, you will have an Rate Table with the Operation of Multiply, and the rate in the Exchange Rates table will be around 1.16 or so.

So if you are creating a payment and want to multiply the exchange rate to the US Dollar Payment amount, you need to make sure that the exchange rate from the Finder is selected with an associated Rate Type based on the Multiply rate operation. By default, the Rate Type comes from what was set on the Bank but it can be changed from the exchange rate Finder.

Printed Checks do not show Home equivalent amount, so you must mean posting checks that shows the reverse. There are no problems with posting checks (manual or system checks) and getting the operation reversed, so make sure that the rate type on the payment is what you expect - the same as for the invoice.

What the system appears to be doing is dividing when posting invoices and multiplying when posting checks. It should be doing the same thing in both cases.

Sheldon

Hi Sheldon,

When Adagio Payables and MultiCurrency is set up correctly for rate types and exchange rates, it does not matter whether the transaction is for invoices or for payments, the operation of divide or multiply is consistant and works as expected. I believe something may not be set up correctly in either AP or MC which is causing what you are experiencing.

Because I cannot duplicate what you have posted regarding a different rate operation for invoices and checks, I'll need more information and an example of what you did and how things are set up. I'd need to know:

What rate type was used for invoices and what the rate operation of that Rate table is (either multiply or divide)? Look at the invoice posting journal for that US Vendor.
What rate type was used for payment and the associated rate operation? Look at the posting journal for that payment.
What was the exchange rates for the invoice and the payment? Both can be found on respective posting journals.
What was the invoice amount (in US dollars) and the calculated home equivalent, from the posting journal?
What was the payment amount (in US dollars) and the calculated home equivalent, from the posting journal?

If I look at the rates the source is set to divide with a rate of .8466... If I look at the table the CAD operation is divide and the USD operation is set for multiply. This is simply the data as set from Accpac when we switched over.

Is this not correct? Should the US table be set to divide rather than multiply and the CAD multiply?

Sheldon

Hi Sheldon,

(grab a coffee first, as this is a long one... )

The Multi-currency exchange rate conversion in Adagio should work the same as it does in Accpac Plus:

- Currency codes should exist for your home currency and all source currencies, such as US dollars.

- Rate Types are simple codes that will be used for identifying date matching and operation (multiply and divide).

- Currency Tables connect the currency codes and rate types, and here is where you set the operation and date matching. Typically you would only create currency tables for your home currency.

- Exchange Rates is where you set up the actual exchange rate for your source currencies. This is done by first selecting the home currency and rate type (from the finder, which lists currency tables). At this point the date matching and rate operation will be displayed but not editable. Then choose the applicable source (USD) currency. Now you can start entering exchange rates and their related dates.

- The rates you enter are always used to convert from the source (USD) amount to the home (Canada) amount. In your example, you have Divide as the operation for the Currency table. Thus the US dollar amount is divided by 0.8466 to arrive at the Home equivalent, which is correctly set up.

- The exact same rate type is usually used for both invoices and payments, unless you require different date matching between the different document types. That is a decision that you have to make and likely already have. If you use the same Currency table (rate type), this means that payment entry will Divide the exchange rate, exactly the same as for entering/posting invoices.

- The default Currency table is defined for Invoice entry on the 'Control Account Set' for the Vendor. The default Currency table is defined for Payments on the Bank. You might have them set up with different rate types, meaning there is a potential for different multiply or divide operations. Note that these are defaults and can be over-ridden during transaction entry.

- If you choose to have a different Currency table set up to convert US to Canada dollars using multiply, it makes sense that the exchange rate must be greater than 1, or namely 1/0.8466 or about 1.1547.

Hopefully this helps determine if your Multi-Currency tables are set up the way you intend them to be, and if you are selecting the correct rate type (and associated rate operation) during transaction entry.

Here is what is really strange, when we print a precheck register it calculates the exchange correctly (divides), when we print a check register after printing checks, it multiplies.

When I do this on a local workstation test environment, everything seems correct.

If it would be helpful we can fax these registers to you.

Sheldon

Hi Sheldon,

I see what you are talking about now and yes this appears to be a problem. Manual check batches do not have the problem, but system check processing has the problem when the rate type on the bank uses the divide operation. This affects not only the check register but also the GL transaction batch and amounts posted as home equivalents for respective accounts.

This one really caught me by surprise, so thanks for your patience. I have notified development on this one and hopefully we should have a resolution quite soon.

In the mean time, that batch of system checks that has been posted will have errors in amounts. You would either have to do a GL journal entry to correct the amounts, or restore AP data from a backup and re-enter those checks in a manual check batch (don't print them) as the multiply/divide issue doesn't happen here.

I appreciate you looking at this in depth.

Can you tell me how long before there will be a fix for this? Obviously I need to process checks for our US vendors.

Sheldon

I don't know how soon precisely, but development has told me they will be giving this one priority.

You can still process US checks using the Manual Check batch - posting handles the exchange rates correctly as I have looked at that too. If your volume is not too high, you can do this until we have a fix ready.