mibuso.com
Home› NAV Three Tier

Additional Reporting Currency

KELLIKELLI Member Posts: 21
edited 2014-05-08 in NAV Three Tier
My client is on NAV2013 , not NAV2013 R2

My client decided to create a company for Malaysia with LCY of MYR . During the setup they did not populate the Additional Reporting Currency for USD.

They have executed several transactions for sales invoice, purchase invoice, cash receipts and cash payments. Some of the transcations are in USD and during the transcation process the Currency Code of USD was selected.

Not all the entries in the general ledger are USD. Of the 1552 general ledger entries only 289 are an issue.

When the Additional Reporting Currencty is populated with USD and the batch runs the Additional Currency fields in the COA adjust down. For example if my entry was 1500.00 USD the conversion will make it 452.00 in the Additional Currency fields in the COA. The reason it is adjusting down is it thinks the value is in MYR currency and it has to calculate for USD currency.

How on earth can I fix this?

Comments

  • jglathejglathe Member Posts: 639
    Hi Kelli,

    I'm afraid you can't. The G/L normally doesn't contain the transaction currency, only LCY and ACY. If you change the ACY for the company, all ACY amounts are recalculated from the LCY values in the G/L entries.
    Also, the G/L entries for your USD transactions contain only the value in MYR based on the exchange rate that was set for the transaction. So, recalculating the ACY from these values is the only way NAV can do it (unless you have additional logic in your application). Our AddOn (plexada Transaction Currency) solves this problem, BTW. To convert "old" transactions to full transaction currency is not always possible, though. Not enough information is retained in the standard NAV entries.

    with best regards

    Jens
  • KELLIKELLI Member Posts: 21
    Someone suggested adjusting the entries values to represent what value would be in MYR and then add the Additional Reporting Currency and run the batch.

    What are your thoughts about that solution?
  • jglathejglathe Member Posts: 639
    Hi Kelli,
    KELLI wrote:
    Someone suggested adjusting the entries values to represent what value would be in MYR and then add the Additional Reporting Currency and run the batch.
    What are your thoughts about that solution?
    my thoughts are that the problem with your database is something different, and that doing as suggested by "someone" would certainly invalidate it... however, when my assumption is true it's not exactly valid now, either.

    Back to your original problem description:
    KELLI wrote:
    My client decided to create a company for Malaysia with LCY of MYR . During the setup they did not populate the Additional Reporting Currency for USD.
    So far, so good. No problem yet.
    KELLI wrote:
    They have executed several transactions for sales invoice, purchase invoice, cash receipts and cash payments. Some of the transcations are in USD and during the transcation process the Currency Code of USD was selected.
    Ditto. I hope there was a valid exchange rate set for USD->MYR. All G/L entries would be in MYR in the amount field, then.
    KELLI wrote:
    Not all the entries in the general ledger are USD. Of the 1552 general ledger entries only 289 are an issue.
    ??? This makes no sense. How come? Did someone change the LCY code in G/L setup to USD in the meantime? So the accountant assumed he was posting in USD as LCY... all of these amounts are simply wrong then.
    Also, did an exchange rate for USD->MYR exist? When the currency code was selected on posting (for, say, invoices) the resulting G/L entries would be in MYR. But you can't tell in every case what the transaction currency was.
    KELLI wrote:
    When the Additional Reporting Currencty is populated with USD and the batch runs the Additional Currency fields in the COA adjust down. For example if my entry was 1500.00 USD the conversion will make it 452.00 in the Additional Currency fields in the COA. The reason it is adjusting down is it thinks the value is in MYR currency and it has to calculate for USD currency.
    Also, sounds strange. Has there already been an ACY code? This should be the only eason that the ACY fields have a value at all. If ACY code is empty, these fields should be zero. Since NAV thinks that LCY is MYR, and you want to set USD as ACY, it would adjust all amount values according to the current exchange rate (down) in the ACY field.

    It sounds to me that you have G/L entries with different currency values in the amount field. This can't be right. But how can you tell which is which? There is no currency code in G/L entries. To make any correction you would need to know which entries are posted in USD, but should have been posted in MYR (or by using the currency code). This can be done by comparing every posting with the original document. All that are found wrong should be corrected by posting a reversal (if possible) and re-posted in the right currency.

    with best regards

    Jens
  • KELLIKELLI Member Posts: 21
    Correct the GLEs have mixed currencies in them USD and MYR.

    I used the subledgers with Excel (VLOOKUP) to determine which entries are the USD.
  • jglathejglathe Member Posts: 639
    KELLI wrote:
    Correct the GLEs have mixed currencies in them USD and MYR.
    As I said, all USD documents (that have an USD value in amount) must be reverted and re-posted. But this has nothing to do with the ACY, BTW.

    with best regards

    Jens
Sign In or Register to comment.