I've got a couple of files for migrating data from a legacy system into NAV 5.0
I know how to write the dataport to create a sales and purchase journal,
based on the open sales and purchase entries.
but I wonder which balancing GL account N° I should choose ?
If I choose the same one that will be setup into NAV when we're going live, then I will be getting
some double entries on this account when I will then import the GL balances
(that will include the open entries for sales & purchases)
I might also end up with double posting on the VAT too, since it's going to be updated when I will post my sales Journal + increased again when I will import y GL open balances
(which will include the VAT Collected GL account)
What's the most elegant way to crack that one ? As you might have guessed I don't have much accounting
experience ;-)
0
Comments
I'm still interested to know how I'm going to solve this. Can you help ??
BTW I just tought of something, let's say my GL Account for Sales on Customer is X, and in my sale journal I got an invoice for a customer, and i enter an amount of 5000, as GL Balancing account I choose again X. And when I post I will get this
Debit (5000) - Credit (5000) = 0 for the same account
And then I can import the GL Balances for account X and then I won't end up with double entry posting
Would that work in NAV and in terms of accounting ?
The financial management setup on posting group is for a regular day to day use of the system, and do not give any tips & advises on data migration for bringing GL Balances, Cutomers and Vendors open entries.
BTW My posting groups are all setup and fine ...
I did search on partner source, but I could not find anything, there's a few bits & pieces on RIM, but it's rather poor.
I wonder why Microsoft did not release a proper guide line or white paper on data migration for transactions.? :whistle:
I would be please if someone could tell me to RTFM, is such a good manual existed \:D/
1. Set the balancing account to the "data take on account". When the general ledger opening balances are then entered you will have a figure for this already, so you code this to the data take on account. In this manner the data take on account will reconcile to zero, if it does not it is an early indicator of an issue for reconciliation because the opening balance will not match the opening trial balance. You can have as many segregated data take on accounts as you wish for each area, so in your example sales and purchases can be split.
2. Set the balancing account to the debtors account. This then creates a net balance of zero on the account and the balance is then made up from the initial trial balance entry. Not adviseable in my opinion but some accountants do not want to create a take on account for reconciliation.
Ultimately the first response is correct, the accountants need to define what they want, you need to tell them what they can do. Then they decide and handle the post go live reconciliation as well as the entry of the opening balances.