Processing Logic - Intergraph Smart Materials - Version 10.2 - Help - Hexagon

Intergraph Smart Materials Classic Help

Language
English
Product
Intergraph Smart Materials
Subproduct
Classic
Search by Category
Help
Smart Materials/Smart Reference Data Version
10.2

After data has been loaded into the OMI interface table, the OMI main import program is started. As a first step, it validates all specified job parameters and initializes (that is, looks up and checks) all needed project defaults. If an error is encountered in this phase of execution, the job is cancelled and an appropriate error message is raised, indicating the kind of problem to the user.

In a second step, the main program dynamically creates an index on the interface table that helps to speed up processing of the imported data. When the job finishes, this index is dropped again, so that the next run of an OMI job (especially in the data loading phase through SQL*Loader or the OMI API) can run as quickly as possible.

When OMI begins to scan through the import data, it looks for the first occurrence of a NODE_BEGIN record, which provides the initial BOM context. All the remaining records are then processed in the order they were loaded, while the BOM is searched or updated by this import data recursively. BOM attribute propagation is initiated at the appropriate points as BOM data is created. OMI takes the specified transaction size into account; that is, it processes the import data in chunks of this transaction size, and after each chunk, issues a database commit. This mechanism controls usage of rollback space, that is, an appropriate value for the transaction size that takes into account the amount of data to be loaded, together with a specification of a rollback segment that OMI can use helps to improve import performance significantly.

The revision control mechanism that is available in the BOM module is also integrated with OMI processing logic. For this reason, the Rev field on the POS type records is not used any longer and is in the import file specification only to maintain compatibility with previous versions of the file format.

Instead, the BOM revision is derived at runtime, using the following criteria:

  • For BOM positions, it is always the revision of the node where they are located.

  • For BOM nodes that are newly created by OMI, the revision number is always 0.

  • For existing nodes that are updated by OMI (or to which positions are added), the resulting revision number depends on the present revision number, the Locked property of the node, and the job parameter check box Rev+1:

    • If a node is not locked, the revision number is not changed.

    • If a node is locked, but revision increment has not been allowed, the BOM node and its associated detail data (node description, node values, and positions) is not modified at all.

    • If a node is locked and revision increment is allowed, the revision number is incremented by 1 (and the node is unlocked, and its present positions list status is reset to the project default list status again in order to allow data modification from the OMI import data to take place).

Fields for the NODE_BEGIN, NODE, and POS record types are available. For these fields, the following logic applies:

  • Issue Status on NODE_BEGIN and NODE Records - If no issue status is present for a record of this type, the issue status from the job definition is in effect. If it is present, it overrides the job issue status (that is, it is in effect for this node only), and controls the import of positions data for this node. A set of position data from the import file always replaces a set of position data that is already present at a particular BOM node with that same issue status, regardless of whether the issue status in effect has been defined on the level of an individual node, or only globally for the job.

  • List Status on POS Records - If no list status is present for a record of this type, the list status from the job definition is in effect. If it is present, it overrides the job list status (that is, it is in effect for the current position only). Please note that the same restrictions to which a default BOM list status must conform also apply for a "local" list status specification on the POS record level: such a list status must allow deletion and overwriting, and it must not have the Lock check box checked.

  • Requisition Indicator on POS Records - If this field is empty in the import file, this indicator (which corresponds to the Req check box on the B.20.01 Single Position screen) defaults to Y, and the position must be included by an MTO. If this field is not empty, it may only contain a 'Y' character or an 'N' character, which corresponds to checked (include in MTO) and not checked (do not include in MTO), respectively.

  • Group Code and Part Code on POS Records - If these fields are empty in the import file, the commodity part that has been defined by the ZB_TAGPART project default parameter (for shape material, ZB_SH_PART) is used for creation of the commodity code / ident code for tagged items. For more information, see Tagged Items. If they are present, they must together specify a valid commodity part; this part is then used instead of the project default commodity part for creation of a commodity code / ident code for tagged items (not for shape material; in that case, the software uses ZB_SH_PART), but only for the current position. For subsequent position records that do not specify this commodity part, the project default part is in effect again. Please note that commodity codes and idents for tagged items are only created if the item type has an item rule of TOM, TWM, or SHP.

There are several modes available in which BOM data is processed. These modes and their significance are outlined in the following sections.