BOM Loader assumptions
The BOM Loader uses the following rules to generate components.
• The loader infers the parent child relationship between components based on whether the depth increased/decreases or stays the same as the prior line. If the depth increases, the next line is a child, if it remains constant, the next line is a peer. If it decreases, the next line belongs to the current line’s parent, or if the depth decreases to the top level, the next line becomes a new top-level item. Note that you can explicitly set what component type (assembly or part) is to be loaded, regardless of Level values, by mapping the Type field.
• Depth is inferred by the values mapped to the Level aPriori field. Top-level depth may either be 0 or 1 – if both are present, 0 is the top level.
• Quantity describes the quantity for a component described per line item. Quantities for like components sharing the same parent are combined.
• Functional group assignments may not conflict over an assembly’s structure. That is, a parent assembly may not be assigned to Functional Group 1 with sub-assemblies assigned to Functional Group 2. If a parent assembly is assigned to Functional Group 1, all its subcomponents will also be found in Functional Group 1 by association.
• By default, the currency of the costs for manually costed components being loaded are imported per the setting of the Manually Costed Currency drop-down menu. aPriori-costed components use the currency from the VPE However, you can specify a Currency column in the CSV file which overrides the default setting, only for that row. If the specified currency is not supported, the BOM Loader displays an error message and the import does not succeed.
• The units of the values, such as volume, surface area, dimensions, and mass are imported per the Units selection in the BOM Loader.
• If the CSV file has an “Official” column, any row that is set to TRUE (by a case-insensitive value of , “true”, “yes”, or “1”) will become the official scenario for that part. If more than one scenario for a part has the official column set to TRUE, then only the first one will become official; subsequent rows will be ignored.
• The CSV file accepts an optional “Scenario” column. If the value for a row is specified and the scenario exists, then aPriori creates or overwrites a copy from the specified scenario based on the selected Processing Rule for existing scenarios . If the specified scenario name does not already exist, then aPriori creates a new copy from the official scenario. If no scenario name is specified, then the scenario name specified in the Default Scenario Name field is used. The same rules as described above are applied to this default scenario name whether or not the component already has such a scenario. If more than one row exists for the same part name and neither have a scenario name specified (or they all have the SAME scenario name specified) then only the first row results in a new scenario being created -- the subsequent rows will all reference the scenario that was created from the first row. If the row indicates that the scenario is a child or an assembly or rollup, then the assembly ( or rollup ) only points to the official scenario if "TRUE" is in the official column AND the scenario name specified ALSO happens to be the official scenario.
• When a BOM load creates a new scenario for an existing part, it does so by copying from the existing part. If your site has implemented Access Control, in some situations this can cause the BOM load to fail due to an Access Control error -- READ privileges are checked against the existing component, to which you may not have access. For more information about Access Control, see the aPriori System Administration Guide.
• When using the BOM Loader to load cost values, the input spreadsheet column which indicates whether it is manually costed must NOT be located last in the spreadsheet (to the right of other columns/fields that you will map to aPriori fields). If the “manually costed” field is in the right-most position and is mapped after the other fields, then the actual (manual) cost values from the spreadsheet are not correctly loaded into aPriori. Therefore, organize your input spreadsheet so that the column indicating whether a part is to be interpreted as manually costed is located in any position other than the last column that gets mapped to an aPriori field.
• Top-level components from the CSV file are added to the output roll-up only if there are NO functional groups specified anywhere in CSV file, or if they themselves have a functional group specified.
BOM loader results: The following table provides a high-level summary of what happens when you import a BOM:
| |
CAD based, manually costed or virtual component already exists in database | The result of this depends on the processing rule for existing scenarios: • Update – existing scenario would be updated with the specified inputs. o Added cost overrides and other mapped inputs • Create a New Scenario – new manually costed scenario with “ <scenario name> (2)” name would be created. It would be manually costed and use “User Guided” process group. And have all specified inputs applied as usual. • Skip – a component scenario from CSV file will be skipped to BOM load. |
No component exists in database | A new component with scenario name (specified in “Default Scenario Name” field or mapped to “Scenario” aPriori field from CSV file) is initialized. This scenario became official, since no other scenarios present in DB. It uses the “User Defined” process group and the part is manually costed. |
When you load a BOM, aPriori does all of the following:
• Creates new components in the aPriori database for new part numbers.
• Creates assembly components for new components with child components on the following lines.
• Creates part components for new components without child components on the following lines, unless you map a field in the CSV file to aPriori’s Type field, and the value of the field is assembly. (Valid values for the Type field are Part, Assembly, and BulkItem.)
• Creates a new Purchased scenario if purchased components are mapped to the Purchased aPriori field and the value of the field is Yes. This scenario combines component costs for the purchased component into the material cost field and ignores the child component costs if the component is an assembly.
If a component is of type “BulkItem” and has a non-integer quantity, aPriori creates a single new component in the assembly or roll-up with an aPriori part number comprised of the original part number value followed by the non-integer quantity.
• Creates a single new component in the assembly or roll-up for the Part Number listed with a non-integer quantity. The new component has an aPriori part number comprised of the original part number value followed by the non-integer quantity.
• Creates a single new component in the assembly or roll-up for the Part Number specified as Type:BulkItem. The new component has an aPriori part number comprised of the original part number value followed by the non-integer quantity.
Note: New BOM loaded components are created as manually costed with user guided GCDs. CAD file association works for new BOM loaded components as specified in the section "Changing the file associated with a component" section of the aPriori User Guide. Once a file is associated to a new BOM loaded component, you must uncheck the Manually Costed box to generate an aPriori process-based estimate.