When importing data into a table the programmer should be aware of any modifiedfield controls that are present on that table. These controls might be used to update other fields, or even other tables, and rather than recreating the code in your import scripts, it is much simpler to use the system code to perform these functions for you.
After your field is updated you can call:
Using this method will mean if over time, between the development of the import code, and the actual use date, if the system code is changed, your code will still function in alignment with how the system now works.
Following on from my recent blog Linking purchase orders with sales order using x++, you might also want to link a purchase order with a sales order that is intercompany.
If you know the sales order number of the end sales order you need to link with, then you can use the sales table field, InterCompanyOriginalSalesId, to find the sales order number from the end sales order of the intercompany order.
When data importing, sometimes we need to import a CSV file. To make the code flexible it is best to make the filename a variable and allow the user to select the file they want to import. This can be done in a class or a job using the Dialog control.
A code example is as follows:
If you are using direct SQL to access data in another SQL system, you will typically be using the ResultSet data handler. To extract of the different fields contained in the ResultSet uses the appropriate get commands depending on the variable type. If you are trying to get a string you might encounter a problem were the limit of the data returned will be 999 characters.
Beware of the getstring limit of 999 characters, and if your field might be longer than this, you will need to handle this in the SQL statement and merge the data together after.
When importing data from another system, especially a data migration, you might want to build links between purchase orders and sales order. This can be done by updating the following points of the system:
Encountered the following error message when trying to process a purchase order that had been imported into the system:
Because of a system upgrade, purchase orders selected to be posted have no transaction date and cannot be posted. Enter the dates manually, or do a batch update with the transaction date clean-up form in the Periodic section of Purchase ledger.
When importing starting balances for customers, it is often the case the credit limits might been exceeded, or customer accounts are blocked. Regardless as this is importing starting balances we need to override standard functionality to allow them to post, and we don’t want to have to edit each account that is effected manually.