Open entries are transactions that haven't reached their final status yet, and are not included in the Open documents section. You can only post open entries when the corresponding master data is already imported. In a common scenario, the open entries include:
All these entries must be posted through their corresponding journal and must use a specific posting date. The posting date must be at least one day prior to the migration date. For instance, if you choose to go live on January 1st, you should use December 31st as the posting date for all the open entries. This way, we will start off with a fresh year with the new data and it reflects when you actually start off with a new system. The easiest way to migrate the open entries is to use the configuration worksheet described earlier in this chapter.
Customer entries refer to all the money that each customer owes on the day of the migration. We need to create at least one customer entry to summarize all the money that the customer owes. If the company wants to control the due dates from Dynamics NAV for the open entries, we need to create at least one summarized entry for each due date, or we can create one entry for each pending invoice.
The minimum information needed is as follows:
Customer
option for all the entries.OPENING
.Opening Entries
to all the entries.Other information that can be provided are as follows:
Actually, you can provide information for any field included in the Gen. Journal Line
table. However, for migration purposes, the previously listed fields are enough.
Let's see with an example how to migrate the customer entries. We'll just take the minimum information needed. The following steps are involved while migrating a customer entry:
81
and include the fields Account Type
, Account No.
, Posting Date
, Document No.
, Description
, Currency Code
, and Amount
. Refer to the Create the migration structure section in this chapter for more information on this step.Remember that your job is to import data into Dynamics NAV the way Dynamics NAV expects it. It is the company's responsibility to assure that the data is consistent and of good quality.
As a Dynamics NAV expert, you are responsible for filling in the fields corresponding to the primary key of the table. In this case, these are the Journal Template Name
, Journal Batch Name
, and Line No.
fields.
Question |
Answer |
---|---|
Does the Total Balance shown in the Journal correspond with the total Accounts Receivable? | |
Does your Accounts Receivable match that of the General Ledger A/R account? | |
Does each Customer owe the Amount shown in its Journal line? |
Once the lines are posted, new customer ledger entries will be created. G/L entries will also be created. When a new Gen. Journal Line
table is created, Dynamics NAV copies the posting group from the customer card to the Gen. Journal Line
table. The receivables account found in each posting group is used to determine which account must be used to post the amount each customer owes. Now, add another question to your checklist:
Question |
Answer |
---|---|
Group all the lines by posting group. Get the receivables account for each posting group. Will each account receive the expected amount? |
Since G/L entries will be created, the accounting rules must be followed. One rule says that any transaction must be balanced. The sum of the debit amounts in each line must equal the sum of the credit amounts. The following screenshot shows the General Journal page of the Default Journal Batch:
In Dynamics NAV, the Total Balance entry shown at the bottom of the General Journal field must be 0.
Note that there are some accounts where you will not be able to directly post into. This is because Dynamics NAV has a mechanism to prevent accounts included in any posting group from receiving entries directly. You will have to skip this control in order to post the customer open entries. Go to the account card and uncheck the Direct Posting field. Don't forget to check it again when the migration process is over!
Your journal lines will now look like the following screenshot, and the transaction will be balanced and ready to post:
Of course, these two new fields can be added to the migration template to fill them at the outset.
Let's look at the general ledger entries that have been created after the posting process:
As you can see, the same account has been used. The balance of the account is 0.00, even though it has four entries. If you run a balance report, you will see that no amount is shown in the Accounts Receivable line. It feels weird, doesn't it? Don't worry, this will be solved once the balance open entries are imported.
Vendor entries are pretty much the same as customer entries. Just follow the steps described in the previous section. There are a few differences explained as follows:
Bank entries are pretty much the same as customer entries. Just follow the steps described in the previous section. The few differences are explained as follows:
Item entries are a bit different from the entries described so far. First of all, another journal must be used – the item journal. Also, you can choose whether the posting of the item entries creates general ledger entries or not.
The data migration tool has limitations here, so follow the recommendations to work around them.
The minimum information needed is:
OPENING
Note that the Item Journal Line table contains a field called Unit of Measure Code. So, you can use a different unit of measurement and therefore the quantity and unit cost will refer to the new unit. When you import data using RapidStart Services, the OnValidate
trigger of each field is run. By default, the fields are validated in the same order that they are declared in the table.
The Unit Cost field has the field number 17, whereas the Unit of Measure Code field has the field number 5407. The Unit Cost field will be validated before the Unit of Measure Code field. If you fill in the Unit of Measure Code field in the template, code will be run. In this particular case, the unit cost will be recalculated and you will not get the unit cost you filled in the template.
To avoid this situation, you have to change the default validation order, as explained in the RapidStart Services section.
Usually, the automatic cost posting is disabled, since in most scenarios it is not recommended that this functionality should be used.
Even if, in your case, the automatic cost posting must be used, disable the functionality while posting the initial item open entries. The cost will be posted in the corresponding account later on, when the accounting balances are imported.
Run the data migration tool to import the data into the item journal and post it. The item entries will be created.
Migrating fixed assets is a bit tricky. Here, we are not talking just about the assets that have pending depreciation but all the active assets in the company. Two types of entries have to be posted: cost entries and depreciation entries. Plus, there is more than one account involved with a singular asset. You can post the fixed asset entries from two different journals:
We will now explain how to post the fixed asset entries using the fixed asset journal. Accounting entries related to them will be posted while importing the accounting balances later on.
To use the fixed asset journal, you must uncheck the G/L integration for the acquisition cost and the depreciation. Go to Departments | Financial Management | Fixed Assets | Setup | Depreciation Book. Open the Depreciation Book Card page and uncheck the fields, as shown in the following screenshot:
From the fixed asset journal, the minimum information needed for the acquisition cost entries is:
OPENING
Import this information using the data migration tool and post it.
From the fixed asset journal, the minimum information needed for the depreciation entries is as follows:
OPENING
Import this information using the data migration tool, and post it. Do not forget to check the G/L integration again in the Depreciation Book Card
. If you have been using a temporary account in the previous sections, we recommend that you post the general ledger entries for the fixed assets entries that you just posted.
Summarize all the asset acquisition cost entries, grouped by posting groups. In the General Journal, create one line for each posting group. Use the acquisition cost account found in the FA posting group. Use the FA - Opening Cost entries
account to balance the whole transaction.
Do the same with the depreciation entries and use the FA - Opening Depreciation
entries
account to balance the transaction.
General Ledger balances are the backbone of all open entries. When the accounting balances are posted, everything else must match. It is like putting in the last piece of a puzzle. The sad part is that sometimes you find that your last piece does not fit. Don't worry about this right now; at the end of this section, we will explain how to check whether everything is okay and how to solve problems.
While other open entries could be imported and posted in many iterations, the accounting balances must be posted all at once because the whole transaction must be self-balanced. Follow the steps described in the Customer entries section of this chapter, but keep in mind these few differences:
Make sure that the amount you are about to post is the same as the sum of all the corresponding entries. You can run the following reconciliation reports:
No standard reconciliation report for the bank accounts or fixed assets exists, so you will have to check it yourself.
Since accounting must always be balanced, if the reconcile reports show any difference, it will mean that some other account does not have the correct balance. Find this other account and you will find the solution to your problem.