foreign currency in gl entries

gri
gri Member Posts: 87
edited 2007-05-15 in NAV/Navision Classic Client
hi
i have a problem with the way navision reflects the amounts in different currency than lcy in gl entry table.

as far as i know (we're talking about 4.0 version), you are allowed to enter in journal line, prior to posting a currency code and even an exchange rate.
but it seems that when the posting occurs, navision converts the amount into lcy using the exchange rate you provided or even the default one and stores only the result.
therefore, it is impossible to find out how much was the original amount of the document in it's real currency.

my customer says:
i enter 10 euros and some exchange rate and i get 33 lcy
what if i want to know after posting if this transaction was in euro or in usd or maybe it was only in lcy?
how can i find this information?

please bear in mind that i'm not talking about customer/vendor/bank account type of transaction where the original amount and currency is saved in the corresponding ledgers. i'm talking only about pure gl accounts documents, posted in the general ledger

please help me, thank you in advance

Comments

  • SDebruyne
    SDebruyne Member Posts: 12
    Hi

    You cannot find it back. Your general ledger is supposed to be in the official currency of the country. If you are posting on a g/l account in the general journal, you can use the exchange rate fields, but only to convert the foreign amount to the local currency while posting.

    Regards,
    Steven
  • gri
    gri Member Posts: 87
    thanks for the reply
    yeah, i understand at this point how it works, but i think it's kindda stupid because it's not in the nature of business solution to "loose" data entered.
    i will have a hard time explaining this to customers which have heavy multi currency operations.

    does anybody found until now a safe approach for this type of issue?
  • jsnayberk
    jsnayberk Member Posts: 58
    Theoretically you could add some field to the g/l entry table. But you will then have to take care that these fields are filled properly within the posting process in any circumstance. Before you start this you should have a detailed understanding of what codeunit 12 does. Not an easy task!

    But if you use sales or purchase documents to post (instead of general journals) you can track the currency history from the posted documents.
    --
    Josef Snayberk
  • gri
    gri Member Posts: 87
    yes, this could probably be a solution, but i'm quite aware of the dangers lurking into this approach (developing into posting routines)

    i'm using the other ledger for tracking the amounts, but this gives me 80% hit rate because there could be also gl postings not linked with any other ledger.

    thanks anyway
  • mgm
    mgm Member Posts: 126
    If it is only 1 foreing currency you like to know, you might consider using the Reporting Currency.
    The other option, of course is to use documents: Sales/Purchase Order, Invoice.
    What kind of transactions do you definitely want to post by the General Journal?
  • ayhan06
    ayhan06 Member Posts: 210
    with turkish localization, we have "Applied Currency Factor","Applied Currency Code","Applied Amount" fields in almost every ledger entry table.. these fields are populated with currency factor, currency code and amounts in the original document accordingly.. you can download NAV TR in the partnersource..
  • gri
    gri Member Posts: 87
    thank you all for valuable feedback

    there are some specific transaction which involve only gl accounts as working
    with the "expenses posted in advance" account and such.
    but, after all, i think that in the future projects i should push all those operations in the "ledgered" area. it is not possible for the existing customers, but they will survive

    anyway, the fact that in the turkish local version there is a development in this direction (although i will be afraid to use it because of the needed merge with romanian objects and with customer's specific objects) means that there is a real need for such information and it is not just one of my client's wild dream.
  • jglathe
    jglathe Member Posts: 639
    Hi,

    what we did for one customer was to create an archive table of the G/L Journal Line with all necessary fields and copying the posted lines into this table. The copying should be done in Codeunit 13. This works pretty well, also for correction purposes.

    with best regards


    Jens
  • gri
    gri Member Posts: 87
    hi
    i sold to the customer the "move everything into the bank accounts area" idea
    in fact, not everything, but a bunch of accounts which must be tracked also in foreign currencies.

    apparently the customer bought it, so the case is closed, but i will retain the jglathe's idea for future similar projects.

    thank you all for valuable feedback
    have a nicer day

Categories