Record Types - 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

The following record types can be used in an OMI import file:

  1. NODE_BEGIN - This record type indicates the beginning of a new node path. It must always be the first record in an OMI file, because it gives the initial context for the remaining records up to the next occurrence of a NODE or NODE_BEGIN record. OMI does not process any other data records until this initial NODE_BEGIN record occurrence has been found. This record type always references a root BOM node, that is, one that does not have any parent node in the BOM. If the referenced BOM node already exists, OMI uses its internal ID as the first context; otherwise, it creates it as a new root node and remembers this ID as the context. All BOM nodes are created in the discipline that the user who started the import job was logged into.

  2. NODE - This record type indicates an intermediate BOM node (that is, a BOM node that is not a root node, but instead either a leaf node or an inner node in a BOM hierarchy) in the context of the previous NODE or NODE_BEGIN record. If it is already present, OMI simply remembers its identifier to provide the BOM path context for the following records; otherwise, it is created.

  3. NODE_NLS - This record type specifies a language-dependent description for the current BOM node. If a description in the specified language is already present, it is updated; otherwise, OMI creates it.

  4. NODE_A - This record type specifies the assignment of a variable attribute to a BOM node. Generally, the attribute assignment itself is already present after a node has been created, because of the propagation mechanism outlined in the Propagating Variable BOM Attributes, so that OMI only has to update its value. Also, for numerical attributes, OMI checks the unit and performs a unit conversion, if necessary. If this node already has a substructure (for example, because it is a new incarnation of this node, but within a different BOM path), an update of the attribute value also causes this modification to be propagated downwards in this substructure. For performance reasons, it is better to have each node attribute only once in an import file to avoid processing of redundant information.

  5. NODE_MODIFIER - This record type allows the modification of a specific node attribute value for all nodes with the specified node type and the specified node name in the substructure of the current BOM path (that is, in the context of the current sequence of NODE_BEGIN, NODE, ... , NODE record occurrences). The node type has to be an exact match; the node name, however, is subject to SQL wildcard matching, if one or more wildcard characters are present. Wildcard characters are '_' (the underscore), which matches any single character, and '%' (the percent sign), which matches any combination of characters.

  6. DISC - The DISC record type has the purpose of assigning BOM positions to a specific discipline. This record type must occur at least once before the first POS record appears in the import file (otherwise, OMI is not able to process the position records at all); this discipline assignment is in effect for all following POS records until a new DISC record appears. Please note that the discipline assignment for positions is unrelated to that of nodes: nodes that are created by OMI always belong to the discipline into which the user who started the job was logged in; on the other hand, it is possible to import position data into multiple other disciplines in this import job by use of the DISC record type.

  7. POS - This record type specifies a BOM position that is created by OMI as a detail record to the current BOM node. It can either be a main position or a sub position in a BOM assembly (this is controlled by the value of the 'level' column). Furthermore, there are four distinct ways of setting up those fields that allow the unique identification of the kind of material that is referenced by this position:

    • By Specification - Position data must include spec code, short code, option code, and sizes.

    • By Commodity Code - Position data must include commodity code and sizes.

    • By Ident Code - Position data must include ident code.

    • By Tag Number - Position data must include tag number and item type; optionally, a group code, a part code, an ident code, and a short and a long commodity code layout may be specified as well. For item rule ‘TAB’, position data must include tag number, item type, and commodity code; optionally, a group code, a part code, and an ident code. For item rule ‘SHP’, position data must include tag number, item type, and plate number; optionally, a group code, a part code, and an ident code.

      It is also possible to only supply this position information partly, but then it may not be possible for Smart Materials to find a matching ident for these positions. If you specify more information than needed for one of these modes, OMI validates that the redundant parts of these data items are consistent with each other (for example, if you have an ident code as well as a commodity code in your import data); if they are not, an error is logged and the record rejected. Please note that it is possible to import positions by specification even if this specification is not yet complete, with the consequence that Smart Materials does not find an ident initially. However, you can use the check procedure 'FND_IDENT' in the B.20.01.41 Start BOM job module at any time later on, after you have completed the specification to find a matching ident and thus complete the position data. Meanwhile, this position is just present on the BOM, but not yet available for MTO. This feature allows for a flexible way of parallelizing the engineering workflow of creating specifications in Smart Reference Data on the one hand and the business workflow of finding initial quantity estimates for BOM data on the other hand.

  8. POS_A - This record type specifies the assignment of a variable attribute to a BOM position. The attribute propagation logic works the same way as for BOM nodes: after a position has been created, the attribute assignment itself is generally already present; OMI just has to update the attribute value; if necessary, a unit conversion also takes place.

  9. POS_DOCUMENT - This record type allows the assignment of a document reference to the current BOM position. The document definition itself must already be present in the Smart Materials documentation module. You can either include only the document code, and then OMI then assigns the highest available revision of this document; or you can specify the document code together with the intended document revision.

  10. IDENT_A - This record type specifies the assignment of an ident value to a BOM position ident (only for item rule ‘TAB’). The ident value propagation logic works the same way as for B.20.01: after a position has been created, the ident values are copied from the commodity values as a template; OMI just has to update the ident value, and, if necessary, insert a new one.

  11. RENAME_TAG_CC - This record type allows the renaming of tagged items in the same way that is offered on the Smart Materials S.80.24 Rename Tagged Items screen using the Update Commodity Code only option for a manual update.

  12. RENAME_TAG - This record type allows the renaming of tagged items in the same way that is offered on the Smart Materials S.80.24 Rename Tagged Items screen using the Update Tag Number option for a manual update.

  13. UPDATE_TAG_DESC - This record type allows updating the order description of tagged items (that is, to change the commodity code layout of the commodity code of a tagged item) via OMI. This is analogous to what can already be done manually on the B.20.01.22 Tag Description screen for tagged items on the BOM.

  14. PROJECT - This optional record type allows restricting the import of a data file to a specific Smart Materials project. It specifies into which project the file may be imported, and when this does not match the Smart Materials project the user starting the job is logged into, the OMI program stops the import process with an error message. This new record type helps to minimize the possibility for user errors.