Bringing historical transactions into Navision

I would like to bring as much history as possible into Navision from the Accpac system we are currently on. The ideal would be to be able to bring in historical information regarding sales, inventory, ar , ap etc, such that I could run reports showing product sales by customer, and similar. Does anyone have any suggestions on doing this? Is it even possible? I’m thinking that I would have to create several dataports with transaction information mimicing actual sales, purchase, cash receipt, etc. transactions. Any suggestions would be most appreciated.

Hi Jeff I have had to import historic data many times into new Navision Installations. There are two ways, each having advantages for their particular application. For financial information it is best to create journal entries in Navision by dataport or report, and then post them after checking. Navision will handle all the Dimensions, and Registers for you. For other data where you need to create new functionality in Navision then it is best to dataport directly into the new table. Hope this helps.

Jeff - It’s best if you don’t mimic, but actually bring in transactions to be posted. In other words, don’t dataport directly into ledger entry tables, but into journals or documents to be posted. It’s quite straightforward, once you have consistent data coming out of the old system. My big warning would be that the more history you bring in, the bigger your reconciliation headaches will be. You will need to reconcile all your subledgers, as well as the GL balances. You also have to be aware that you ‘should’ bring things in in the proper order, so that application entries are reasonably correct - although applying payments is best done using Apply to Oldest unless you want to go through account by account and apply items. Good luck.

Thanks for the info. When you’re bring in something like a sale of inventory, do you need to bring the sale transaction and the inventory transaction as two separate transactions, or can you do it as one? If that transaction was dataported into a sales journal would it also do the inventory transaction?

Hello Jeff, In answer to your last question an Invoice or other transaction posted through a General, Purchase or Sales Journal will not create an associated Item Ledger Entry. As mentioned in the other replies it very much depends on your requirements. At a very summarised level General Journals, Sales Journals and Purchase Journals depending on use will result in General, Customer or Vendor Ledger Entries which in turn will affect the various account balances. These Journals will not generate Item Ledger Entries and therfore not affect Item Cards etc… Physical Inventory and Item Journals can be used to generate Item Ledger Entries and therfore affect Item Card History / Balances. A number of our customers requirements have resulted in the following procedure when moving from a legacy system. G/L - Manual Journal to Open G/L Customers / Vendors - Dataport to generate Sales / Purchase Journals to post opening Customer / Vendor Balances. Inventory - Dataport to generate Items and Item Journal for Opening Stock Balances. But, once again it is very specific to your requirements. Hope this helps. Regards

Jeff - You also aren’t restricted to creating journal lines via your dataport. You can also create sales invoices, which you would need to do if you want sales of items by customer. If you just use journals, you will get a bunch of customer transactions and a bunch of unrelated inventory transactions. No link, and no way of knowing what customers bought what. It takes a bit of planning, and reliable output from the old system, but it can be done. I have imported several years of detailed history before for clients, so much so that it took 11 days, 24 hours a day, to batch post. Again, reconciling was going to be a HUGE issue. In this case, what was critical was the history of who bought what. We ended up generating a physical inventory journal to zero inventory on the last day, and then brought in opening balances. This way we had customer/item history, and a proper opening balance, without reconciling all that history. Hope this helps.

Hello Jim, Good points, again as I mentioned the required processes are so dependent on the client requirements it makes this a difficult topic to guide someone through in this manner. And of course there are many ways to skin a cat. Regards