Does anyone has experience with converting a Financials 1.00 version database to Attain? Or is it better to just export the data out and bring it into Navsion Attain? Any suggestions are welcome. PS: I couldn’t find any information on Navision-Microsofts website regarding upgrade tools or 1.00 database (I need that to compare what has been modified). Roelof de Jong.
I would recommend You to look at Attain as a “new system” and the 1.00 as an old system with very good export capabilities. Don’t think of it as a conversion/upgrade. Just export customers, vendors, items, accounts and set up everything else manually. That’s safest.
By the way Roelof, ver 1.00 was never (to the best of my knowledge) released in the USA. It was quite a problematic product, and did not last long. Ver 1.10 was the one that really put Navision into it market position, it did for Windows what 3.04 did for DOS. Even the upgrade from 1.00 to 1.10 was a nightmare, options and posting groups changed. Not a nice time. I am with Lars on this, you need to concider this as a completely new implementation.
I agree, it would be a nightmare. Forget it and export the data’s. Be carefull if you choose the Attain SQL option. It can be sloooooooooooooooow so sloooooooooooooooow. I think that Navision and Sql do not communicate perfectly Only Navision is perfect [:D]).(flow fields does not exist in SQL). Good Luck John.
No problem with SQL as long as You do your HW-homework properly 
I do not agree. Navision and SQL have a real communication problem. Nothing to do with keys, SIFT, code even if this can be a cause of slowness. [:p]
Well, believe it or not. It is a real 1.00 version (US 1.00B). I agree on all of you to just export/import all the data. But my concern is the Detailed Cust Entry, Detailed Vendor Entry, and Value Entry tables. They need to be created in Attain. Roelof.
John, what do you mean by a ‘communication problem’? In what way have you analysed the communication and for that matter the general implementation, and cause of slowness you are experiencing?
quote:
But my concern is the Detailed Cust Entry, Detailed Vendor Entry, and Value Entry tables. They need to be created in Attain.
Do NOT import the ledger entries. Just key in the open entries in the new database and forget about the history.
quote:
Originally posted by Roelof
Well, believe it or not. It is a real 1.00 version (US 1.00B). I agree on all of you to just export/import all the data. But my concern is the Detailed Cust Entry, Detailed Vendor Entry, and Value Entry tables. They need to be created in Attain.
About Customers and Vendors entries you might try something like this: Export all invoices to a text file (or maybe better a xls) and import them in table 81 Make sure all the Cust and Vend Posting Groups lead to a dummy Account which will be also set as balance account on all the lines Register the invoces Export all the other entries and import them in table 81, filling the “Applies-to Doc. Type” and “Applies-to Doc. No.” properly. Register the entries I did this the first time we installed Navision in our company, moving from wholly different accounting system. It worked. I then went so far to trace back the Ledger Entries created by the process and unceremoniosly delete them from the G/L Entry table, but that isn’t really necessary. [8D] Anna
And what about the detailed entries? Don’t import history in ledger entries of any kind if you absolutely don’t have to. It’s a big risk that You end up running a report 6 months later and realize that your imported history messes things up
Sorry Anna, I have to agree with Lars on this one. Never import Ledger Entries - just create Opening Balance entries because it can cause real problems later. Agreed with the others - new installation, not upgrade! [;)]
Yes, this should be treated as a new implementation - especially as the system has new functionality that may be useful and the company will have changed processes and requirements since the initial implementation. Hoever, as with any implementation (and as Anna says) you can automate the process of posting open items by importing them into a journal for the user to manually post to the ledgers. There really is no need for the users to have to key in open items when a simple dataport will do the job (we always dataport open items for our customers!)
quote:
There really is no need for the users to have to key in open items when a simple dataport will do the job
That’s OK as long as it’s the open entries.
Alison, quote: -------------------------------------------------------------------------------- “… just create Opening Balance entries because it can cause real problems later.” -------------------------------------------------------------------------------- I think you misunderstood what I meant [?] - I said create the entries not key in the entries. [;)] Definately automate the process if possible - using dataports.
quote:
Originally posted by CMDunbar
Sorry Anna, I have to agree with Lars on this one.
I don’t think Lars was referring to my post. I didn’t suggest to import Ledgr Entries. [:)] Maybe my English was confusing - I was just figuring out a way to regularly post Customers and Vendors details without really affecting account balances. [:D] Anna
Well, thanks for all the good help. I think I go ahead and quote for all the dataports I need to create. Roelof.
Actually Roelof, there is something else you can do that I have done be fore in Navision to Navision conversions. Firstly take a copy of your existing 1.00 database. Delete all objects except tables. Now go through and delete all the data from tables that you don’t need. - This means stuff like registers, g/l setup, departments, projects, posting groups etc. You will be left with basicaly G/L, Customers, Vendors, Items, Resources, and the entries that go wth them, and all the invoice, shipment and credit memo tables. Now you need to get this into a 3.60 Database. So make sure that you don’t have duplicate object names etc. Create a backup of the DATA (company) only. DO NOT BACKUP THE OBJECTS. Now create a new empty 3.60 database, MAKE SURE THERE ARE NO OBJECTS in it. Import the backup. When you do this, since there are no objects, Navision will automatically create the table objects in the new database. Now you have a database with tables, but nothing else. Now go to each of the tables left, and change the numnber, eg. go to table 15 and renumber it to 50015. This will move the object, AND the data. Once you have done this, delete all the unused table (if there are any left). What you have now is all your history, in Navision tables, and you no longer have any need to import history. Now you can write a function (aka non printing report) to create customers, vendors etc in the real tables. And since you are using the same numbers, it is no problem to then add forms to your new Cards to show historical entries. And the best part, spend 15 minute ot modify the Navigate Form, so that you can Navigate across the old entries. I have done this a few times now, and it works well. If you neded more help, let me know.
David, Actually a very good suggestion to keep old history in the system. Why haven’t I ever thought of this instead of my usual two other options of either going through the trouble of actual conversions or keep a copy of the old database in read-only mode.
Ah Erik, Actually one Navision site I proposed this for, (and they did it), was an old NSC I used to work for, that you and I know quite well [;)]