Migration to Axapta

Hi, we are in the process of migrating our old systems to Axapta. We have come to the point where we discuss in which order we should move the data - which Axapta tables do we fill first and what comes after that. Is there any kind of database documentation on Axpata where we could see how the tables are related? I tried to analyze the relations defined in the tables but there are several problems: - some relations are defined in ExtendedDataTypes and not in the Table - tables refer to themselves - table A refers to table B which refers back to Table A - table A refers to a chain of references and a table on this chain refers back to table A When I look at such circular references, it is difficult for me to determine in which order the tables must be filled. Any experience, ideas, tips, tricks, tests, docu. on migration to Axapta will be helpful. Thanks.

Hi, Having done few migrations myself, I would say that migration to Axapta is not that difficult. Agree - it is not a piece of cake but it is not that complex either. Here are some pointers - 1) Try to first start with master table. 2) Use the Template Wizard under Administration → Periodic → Data export/import → Excel spreadsheets to generate the table structure. 3) Populate the table with values. 4) And import the same through Definition group under Administration → Periodic → Data export/import. Alternatively you can write small jobs to do the import work for you. For sample jobs, please refer to - http://www.harishm.com/Navision/Code.html Any queries, please do not hesitate to post them here. Good luck [:)] Harish Mohanbabu

Axapta documentation is pretty pitiful…we are just starting to plan out our implementation and we have tried to obtain a Database diagram, more documentation, etc and have been told by Microsoft that it just doesn’t exist. This is especially true when compared to our current business system - which has about 20+ huge bindered manuals - everything about it has documentation. However, I think that MS is beginning to hear all of the complaints about the lack of documentation and is making a significant effort into adding as much as possible into Axapta 4.0. Also, Harish’s suggestion is a good starting place. The Excel templates will have separate workbooks that contain the fields for tables linked to the one you generated the template for.

Thanks for the suggestions. However, our problem lies not so much in filling the Axapta tables with data but in which order do we fill the tables? Since we have to move big tables to Axapta (> 65.000 entries), Excel is not an option for us. To facilitate the migration, we “copied” the Axapta database structure into another database and removed all “Axapta business rules”. Now we want to fill the “dummy” database with information but we don’t know with which tables to start. An option is to go in each module, analyze it, and determine the order to migrate. This requires a lot of time. When the tables on the dummy database are filled, we have a simple program that reads the data and inserts it in Axapta after it validates the entry. The result is the same as with the Excel files, but we can import big tables without a problem. Also, existing relations between tables in the old systems can be easily transfered in Axapta. In any case, the question remains: in which order do we fill the Axapta tables? Following “blindly” the relations between the tables in Axapta is not enough because of the “circular references” I mentioned before. However, if there was a way to determine the direction of a relation defined in Axapta, it would be easier.

Hi all, You can fill tables in any order ! There isn’t any reference-key rules in the database. For instance you can start importing customers even if there is no customer groups in the database. Hint: Look at classes with names starting by ‘Ax’. Commerce Gateway and Portal uses them as an interface to Axapta. This simple code inserts one record to all referenced tables also: static void axInventTableTest(Args _args) { AxInventTable axInventTable; ; axInventTable = new AxInventTable(); axInventTable.itemId(‘abc’); axInventTable.itemGroupId(‘kkk’); axInventTable.modelGroupId(‘mmm’); axInventTable.dimGroupId(‘ddd’); axInventTable.doSave(); } br,

Hello K. K., I can’t quite follow your idea. It sounds too good to be true. Do you mean that if I insert a new customer that belongs to group A, and Group A does not exists in the “groups” table, Axapta will create the group for me? In that case it would be interesting to know how to update the “groups” table afterwards because each group has parameters that have to be filled at some point. If you mean that we can force Axapta to take any data we want to save (without validating them), we still have a problem. Since our old system is not Axapta, we have a different data structure with existing references. When we move the data to Axapta, we would like to preserve the old relations. For example, if a customer belongs to group A in the old system, the same customer must belong to the equivalent group in Axapta. The main difference is that our old “IDs” are meaningless, numeric fields used only to facilitate the references - the end users never see them. In Axapta, the IDs are mostly meaningful abbreviations because this is what the end-users see most of the time. Now, we have to make a match between the old and the new group ID and pass it in the customer table when we save the customer. If I don’t see the obvious solution, please help!

It is not so easy! My example was about a situation when there is some links between primary tables and the invisinble background tables like InventTableModule. There is similar tables in the CRM. Anyway you can import data to most tables regardless of the groups. But the real problem is because if you do not know the business logic of the old system it is almost impossible to CONVERT the data into axapta. You can only IMPORT it :frowning: For example in Axapta there is more business rules behind the user group compared to old systems. Rarely you can import all the groups data in 1 to t manner. br,

The Axapta business logic is my problem. Since I work at an end-user company, and I’m new to Axapta and I don’t know the Axapta business logic. I thought that by following the references I could simplify my life a little. Now I’m getting convinced that I have to do it through the forms: 1. see which forms require information from other forms. 2. find the equivalents in the old system 3. import the referenced data first 4. replace the old reference keys/ids in the main table with the new ones from Axapta 5. import the main table in Axapta Sounds like a lot of fun [:D] … and when you put all this in a validated project, you get the full package [Yeah!]

Getting your data into Axapta is alot easier when you use Axapta. First add a row of data manually, for example an item to the item master. Then look at the data to see what fields were filled in automatically and which fields were required to be filled in before you were able to save the record. This is a great starting point. This will tell you which fields you will need to import. Next is to get familiar with the import function. Stick with comma delimited files. There are plenty of examples of code that you can include in your import definitions to do things like looking up the InventDim value for an item when populating InventTableModule. Sometimes I include fields that have values that I will use as the source data for lookups, for example warehouse and location, when finding an InventDim. I’ve written VB code to handle the translation of our old data into comma delimited tables. Everything else is done inside Axapta. Here is code inserted into the conversion tab on a comma delimited import for a counting journal to import startup inventory counts: InventDim InventDim; InventDimId InventDimId; ; InventDim.clear(); InventDim.InventLocationId = ‘SMC100’; //enter warehouse here InventDim.WMSLocationId = conpeek(inData,2); //enter bin here InventDim.InventColorId = InventTable::find(conpeek(inData,1)).StandardInventColorId; InventDim.InventSizeId = InventTable::find(conpeek(inData,1)).StandardInventSizeId; InventDimId = InventDim::findOrCreate(InventDim).InventDimId; InventJournalTrans.JournalId = ‘IJ-000049’; //enter journal id here InventJournalTrans.TransDate = Str2Date(‘12/23/2004’,213); //enter date here InventJournalTrans.EmplId = ‘Admin’; InventJournalTrans.Dimension[1] = ‘100’; InventJournalTrans.InventDimId = InventDimId; InventJournalTrans.JournalType = InventJournalType::Count; InventJournalTrans.Voucher = ‘IJV-000003’;