Iteration-level relational imports

Relational import files create relationships between a parent item's pending iteration and its child items. The import file simply creates a new relationship between existing items; both parent and child items must already be in the database. Any number of parent items may be in the import file, and each parent can be related to one or more child items. It's common for some child items to be assigned to several different parents.

Use iteration-level relational files to initialize your database from legacy data sources, such as an MRP database or Excel files. These existing iteration records may have been imported in bulk using the ItemMaster.csv file, although they can also be created in the normal course of using PDXpert.

Guidelines for importing iteration-level relationships §

Before importing your data, back up your database. The import tool makes significant changes to your database, and can overwrite data on previously-imported items. You cannot undo the changes it makes; you can only restore your backup database.

Do not try to create or modify an iteration-level relationship after the iteration is released. Only item-level data can be updated after an iteration is released.

If you use Excel as your CSV file editor, it may make undesired changes to values that it interprets as a number. For example, part number strings beginning with zero (e.g., 001234) will often be silently converted to a numeric value (1234). If you have any part numbers, document numbers or other data with leading zeroes, don't use Excel. Instead, use a CSV file editor, Windows Notepad, or other plain text editor (not Word) to edit your import file.

Empty import file .csv templates (with existing item data, if any) can be exported using the External Data Importer tool. Select the Import Type template, then click the Export button.

  • Parent and child items in these import files are matched according to the identification rule defined in Tools | System Rules... Item uniqueness defined by: Number, Organization, Class, Type. Columns not specified by the rule (Class or Type) are ignored during matching.

  • Iterations (revision and lifecycle) are always ignored in the matching (in fact, none of the relational import files include columns for specifying iteration values).

  • Lists that are applied to a specific parent item (BOM items, approved sources, references, file attachments) are treated as an unbreakable replacement set. The parent item's entire previous set is first deleted, and then the new set is added. If any one row of the parent's set cannot be imported, then none in the set is imported.

  • Replacement set members are accumulated for a parent based on the import file's data. Therefore, the set's parent must be identified consistently in the import file: if you explicitly identify the class or type for one row, the same values must be used for all other rows in that parent's set.

  • The column names in the first row of the import file (the "header" row) must match the definitions in the help topic. The header names are case-sensitive and must be spelled exactly as shown. Every column with data must have a conforming header. Do not include more than one column with the same header name.
  • Defined columns may be in any order. Extra (undefined) columns in the import file are ignored.
  • Every value must conform to the column's specified type (collection member, string, number, etc.) or be empty. For example, a column that requires a numeric value cannot include non-numeric characters.
  • Leading and trailing spaces are removed from each data element before it's matched or applied. Other space characters are not affected. For example, the value   many  spaces   becomes many  spaces.


Learn More
Help Guide Contents [PDF]