Open davidonelson opened 3 years ago
Can you site an example @davidonelson ? A map is basically just a one-to-one association of the source to the target. Meaning the value of the column in the spreadsheet, once mapped to the property of the table, will persist its data to the table after import.
Example 1: Legacy Codes Many of the imports look like they require the newly created CB code, but actually they can use the legacy code in that same field. Other imports could allow the use of a legacy code, but they do not, you need to map to the CB database to get the CB entity code.
Example 2: Auto creation of other entities Some imports trigger the auto creation of other entities (like customer import generates ship-to and contact rows)
Example 3: Data rules The person performing imports needs to be aware of important data rules, otherwise the CB database will be invalid and client will crash upon use of the data. One example is Inventory Unit Measure: RULES FOR TABLE InventoryUnitMeasure (1) IsBase, DefaultSelling, ShowOnWeb should always be 1 or 0 (never NULL) (2) One and only one row must have IsBase set (3) One and only one row must have DefaultSelling set (4) At least one row must have ShowOnWeb (These rules are enforced by the UI but not by the import manager)
Example 4: Delete before insert Some imports only insert rows, others delete then insert
Example 5: Required fields and suggested defaults (subset of data rules) Maps have require fields that need to be documented. Some columns allow NULL but need to be 1 or 0
Large numbers of hours get wasted by new partners who try to perform data conversion without documentation on how each maps works. As it is now, a lot of experimentation, reverse engineering, trial and error is needed to figure out the import manager.
As a result, a lot of time is wasted doing experiments trying to figure out what the map is doing to the database.