5.12.  Classify
5.12.7. Classification according to CNSORDERNO / CNSTYPECODE
Prev  Next

5.12.7. Classification according to CNSORDERNO / CNSTYPECODE

5.12.7.1. Use of CNSORDERNO and CNSTYPECODE with examples
5.12.7.2. Benefits of classification according to CNSORDERNO and CNSTYPECODE
5.12.7.3. Plugin "Resolution check "
5.12.7.4. Plugin "Classify projects in batch run"
5.12.7.5. TestMeta: General for order number or type code
5.12.7.6. TestMeta: ReverseConfigs / Reverse Search (automatic)
5.12.7.7. Index order numbers dependent on value ranges
5.12.7.8. Limit resolving of value ranges (yellow fields) via config key

PARTproject -> Settings -> General tab -> Variables -> Variable with order number and/or variable with type code

[Note]Note

  • Classification of projects according to CNSORDERNO and/or CNSTYPECODE is mandatory. [45]

    If both CNSORDERNO and CNSTYPECODE are classified, they must not use the same variable!

    If a corresponding entry is missing, a corresponding error message appears when executing Test project or Test directory. See Test project Section 5.8.2.1.12, “ Test project / Test directory ”.

    Ideally, the values of the order number [Order number] and type code [Type code] should not contain any spaces.

  • Differentiation between CNSORDERNO and CNSTYPECODE

    • Variable with order number (ORDERNUMBER):

      Features:

      • Order number can not be divided into segments. There is no direct link between single values of characteristic and parts of order number (regardless of whether numerical or alphanumerical).

      • It doesn't matter whether the project contains value range fields or not. This is not significant for the decision whether CNSORDERNO or CNSTYPECODE. In both cases there are projects with and without value range fields.

    • Variable with type code (TYPECODE): The individual parts of the code are related to the values of certain variables (e.g. type/series, geometric values such as length or diameter or other variable values that define the type code).

      Example: Clear relation between parts of type code and single variable values

      Example: Clear relation between parts of type code and single variable values

  • For existing catalogs, the corresponding mapping can be carried out semi-automatically by the catalog manufacturer/modeler with little effort. Depending on the manufacturer, it may be possible that different identifiers are available. These variants must be taken into account. Information on the Classify projects in batch run [Batch classification of projects] plugin can be found at Section 5.12.6, “ Batch classification of projects ”.

  • If value range variables are used to form order numbers [Order number] or type codes [Type code], it is essential that you do not use any with type identification [Identification type] "functional characteristic [Function attribute] " or "dimensional characteristic [Dimension attribute] ". For details, see Section 7.8.14, “ Identification type ”.

In the PARTdataManager you can switch between normal full text search [Full-text search] and search by order number or type designation [Order number or type code] .

The search method order number or type designation [Order number or type code] should be used if it is explicitly searched for. Due to its uniqueness, this search always leads to the desired result (provided the catalog is prepared accordingly).

The method not only produces the desired result for a fixed order number/type designation [Order number], but also if it is composed using values from value range variables, both for simple and complex compositions.

[Note]Note

Catalogs may contain simple projects without value ranges or with value ranges and those again can be build more simple or complex.

To determine which cases exist in a catalog, the resolution check [Resolve check] should be carried out. See resolution Section 5.8.2.1.16.26, “ Reverse Search - Resolve check (automatic) ”.

There are three basic cases:

  1. Simple project without value ranges

    Example project without value ranges in PARTproject

    Example project without value ranges in PARTproject

    Example project without value ranges in PARTdataManager

    Example project without value ranges in PARTdataManager

  2. Project with value ranges which can be resolved by inclusion into the full-text search index

    Inclusion in the full-text search index is possible if there are fewer than 25,000 possible combinations per project or 50,000 per catalog (default limit) in addition to the standard lines. The limit is set using the configuration file %cadenas_setup%/partsol.cfg. See Section 5.12.7.8, “Limit resolving of value ranges (yellow fields) via config key ”.

    [Note]Note

    The limit should not be changed.

    Example project with indexed value ranges displayed in PARTdataManager

    Example project with indexed value ranges displayed in PARTdataManager

  3. Project with value ranges, which need to be resolved via Reverse Search

    These are projects with very complex value ranges, the resolution of which would result in millions and billions of possible combinations, which exceeds the limit set by the config (max. 25,000 per project, max. 50,000 per catalog) for inclusion in the full-text search index (Lucene index).

    Example project with many value range variables that build up the part number interactively

    Example project with many value range variables that build up the part number interactively

    When executing the resolve check for these projects a mapping file will be automatically created by which these projects can be found.

  4. Special case for 2) and 3 Special case for 2) and Only a certain number of the actually possible combinations from the value range fields have an order number and are actually available or can be ordered.

    -> A CSV (pnomapping.csv) with mapping information of order number [Order number] and type code [Type code] is stored in the catalog root directory.

    pnomapping.csv, column names "PARTNUMBER" and "TYPECODE", semicolon as delimiter

    pnomapping.csv, column names "PARTNUMBER" and "TYPECODE", semicolon as delimiter

    -> The search is entered using the order number with search mode Search by order number / type code [Search for order number / type code] but the search is actually carried out in the background using the type code.

    [Caution]Caution

    • Use case should not be to avoid order number in the table, but only the above mentioned.

    • The order number will not appear in the search result, as it is not present in the table.

      If the order number is needed in the table, it has to be implemented separately (which has nothing to do with the described special case).

    • The order number will not be exported to the CAD, BOM etc.

    Example: Search with order number, display of type code in the table

    Example: Search with order number, display of type code in the table



[45] The class variables [Class variables] CNSORDERNO and CNSTYPECODE are mapped to the desired variable under Variable with order number and Variable with type key. See also Section 5.12.4, “Simple assigning of important variables to CNS classification ”.

[46] Key VARSEARCHRESOLVEORDERNO. At project level, this is located in the project file, at catalog level in $CADENAS_DATA/23d-libs/<katalogname>/dir.prjno GUI equivalent. Manual intervention is not necessary.

[47] Always make sure that you have an up-to-date full-text search index and/or geo search index for the required catalogs to ensure that all the functions of your software version are actually available. (With V11 SP10, for example, the function Reverse Search - Test of order number search [Reverse Search – Test reverse search] has been added which accesses the full text search index)

Prev Up Next
5.12.6.  Batch classification of projects  Home 5.12.7.1. Use of CNSORDERNO and CNSTYPECODE with examples