On May 30 at month end I did a multicurrency revaluation in AP on our USD payables, which created a batch in Ledger. After posting the batch in Ledger, both source and home amounts were the same on the AP Open Payables Report and in Ledger.

I Installed AP V9.2A (150310) Upgrade on June 3.

On June 30 for month end I did a multicurrency revaluation in AP on our USD payables, which created a batch in Ledger. After posting the batch in Ledger, the source amounts were the same in both AP Open Payables and Ledger, however, the home amounts were completely different.

I restored from a back up and tested a few more times with back up data, but the problem recurred every time. I tried running multicurrency revaluation in AP a second, third and fourth time and each time an amount goes to Ledger. After posting the batch in Ledger, the AP Open Payables report home amount remains unchanged, while the Ledger balance continually increases, widening the gap.

Is the AP Open Payables report broken? Or is the multicurrency revaluation function in AP broken? Or am I doing something wrong?

Susan:

The procedures hasn't changed so I doubt you are doing anything wrong.

Assuming that each time you run revaluation you used the same date and rate and there were no changes to the vendor balances then something is wrong as no GL entry should have been created (after the first one).

Does one of your vendors have a credit balance, or prepayment, or unapplied credit note?

Hi Doug,

The first multicurrency revaluation in AP sent a credit of $122.92 to AP in Ledger. When it didn't balance, I ran it again and the second time it sent a debit of $851.03 to AP in Ledger. The third, fourth and any subsequent times it continually sends a debit of $851.03 to AP in Ledger. The amounts on the AP Open Payables report do not change but because Ledger repeatedly debits AP in Ledger $851.03, the gap keeps growing each time rather than correcting the problem. Each time I used the date of June 30, 2015 and no changes were made to the data throughout this process.

Yes, there are vendors with credit balances, prepayments, unapplied credits and unapplied negative invoices. Last month when everything was working there was also the same.

Susan:

Very odd. It's just math and once done (even if wrong) the answer a second time should be $0. It's almost like something is not getting updated in the AP database so that next time you do a revaluation the calculation is done all over again with the same result (create a GL entry for the revaluation but don't update AP). So far none of my clients have brought this to my attention, which means either blind luck or the problem is unique to you.

This looks like a problem that requires some hands on with the database. You may need to get your Adagio consultant involved.

I'm with Doug. I think your Adagio Consultant needs to take a look.

Hi,
We are looking at the data now.

In first pass, there appears to be a problem with the MC revaluation in AP 9.2 as Susan has indicated, on clean data that previously worked properly before upgrading.

Before upgrading to AP 9.2, the source and home amounts for the AP USD control accounts were balanced to the GL balances.

After upgrading to AP 9.2, when creating the AP revaluation for the month of May, and running the pre-revaluation listing, the total for the home USD amount no longer balances to the previous reported home amount. No entries have been applied, just using the pre revaluation listing.

The totals on the pre revaluation listing report do not add to the to the GL distribution entry being reported or when created (when posted in AP revaluation).

And so any entry being posted to the GL from this Revaluation in the Subledger and taken to the GL, will create an out of balance entry for the Home Currency control account in the GL.

And if you rerun the Revaluation on AP for the same date with the same rate after posting the first Revaluation (for May) (in AP), you get another Revaluation entry which also doesn't add to the GL distribution entry for Home (and with different amounts).

If you were to repeat a revaluation for the same date and same rate on a previously revalued data set, you should not be creating any revaluation entry in AP.

The only thing unique perhaps to this site when compared to other sites using AP and MC, is that we recently converted their data from single currency to Multi-currency when they were on version AP 8.1F, and the AP revaluations worked fine for several months when using AP 8.1F.

Will keep you posted.

Brian

Hi Brian,

Perhaps you or one of your staff could send us some notes on how you converted their AP from Single Currency to MultiCurrency.

Brian:

My thoughts: Did a Prepayment get overlooked or is partially converted to MC, thereby causing this issue.

Hello Susan,

We have identified a problem with the revaluation of prepayments in Adagio Payables 9.2A.

Payables was changed in 9.2A to revalue prepayments on file. Payables 8.1F did not revalue prepayments.

While the amount calculated for the general ledger transaction is correct, the home equivalent on the prepayment is not updated to reflect the revaluation. This problem has been recreated in the Sample Data.

We have referred the issue to R&D for a fix.

I'm sorry for the inconvenience.

Hi Andrew,
Our notes to convert AP to Multicurrency.

To convert from AP Single to Multicurrency, we confirm version compatibility, and then we install the MC module.
We ensure all batch data has been posted and retrieved, and posted to the GL. We print relevant balancing reports in AP for the open payables, to balance post MC conversion data.
We backup the data to our cloud server (including currency tables), and run DataCare on the data to be converted to ensure the data is clean to begin with.
We add historic rates to the MC file with at least Month End rates and a rate for the conversion date, and turn on MC in the AP on the conversion date. Within MC, we add the MC codes and rate types.
We use our Gridview RW and we create views into client AP data, to the Banks, Control accounts, Vendor master, AP transaction details, AP transaction history, AP bank Rec Headers, AP Bank Rec Details, AP posting journals, AP check registers, AP tax tracking, and company profile.
We convert GL to Multicurrency, and define revaluation codes in GL.
We add the realized and unrealized Gains/Losses accounts to the GL in home currency. and change/create a USD AP control account in GL with Multicurrency with defaults set to USD, with defined MC revaluation codes (in GL). We change the GL Foreign currency bank accounts and loan accounts to MC with defined MC revaluation codes, and revised default currency codes.
In AP, prior to conversion to MC, we transfer any foreign currency vendors (currently at par 1.0) to new control accounts before turning on MC in AP, and balance the sum of the new control account subtotals to the previous data (unconverted). You cannot change the control accounts on any AP vendors after MC is enabled in AP.
We add currency codes with GVRW to the control accounts, and the banks with the necessary new exchange gains and losses GL account(s).
We filter out all vendors (by control account) and their related transaction activity, AP bank Rec transactions, and convert all of the defined foreign currency transactions leaving the source as is, and manually translating (with XLS) the foreign currency transactions to home values for open transactions while adding new Source Currency codes to relevant accounts, so that the data looks like as if a revaluation was done on that date to change the exchange rate from 1.0 to the actual rate on that conversion day. Completed foreign transactions are left with the transaction exchange rate of 1.0 but all foreign account transactions are updated with the source currency code associated with the foreign currency vendors.
We balance the open payables in both home and source to the previous unconverted transaction reports, and run DataCare on the converted data to rebuild the home values on the AP vendor master, to ensure the data is clean. There will be errors reported but DataCare effectively corrects any anomalies.
We then create the J/E in the GL to balance the Source and home values in GL and balance to open payables, and revise source currency amounts in Banks from home to source, with offsetting entries to Exchange.
We then backup and test the AP data, with another exchange rate to ensure the revaluation is working properly, and that data entry for payments, manual checks, and invoices works as expected, before returning converted data from our cloud server.
Existing data at the client site is backed up on site before we replace with the converted MC data.
We backup conversion data throughout the process on our server to enable easy restart points.

If we have to integrate AP with PO's, X-Company, LInk2Points, and/or BankRec, AR, it is a little more complicated (but completely doable), because you have to ensure the integration is correct between all related modules.

If the client has home currency set to the infamous DOS, we recommend that the client acquire Dakata's toolbox, and change the home currency to something more meaningful than DOS. It really helps for document reporting.

Best,
Brian