English
Deutsch
Español
Français
Hrvatski
Italiano
Polski
Türkçe
Русский
中文
日本語
한국어
Legal notice
powered by CADENAS

Manual

Top Links

Manual

3.2. General rules
3.2.18. Classification according to CNSORDERNO / CNSTYPECODE
Prev   Next

3.2.18. Classification according to CNSORDERNO / CNSTYPECODE

3.2.18.1. Use of CNSORDERNO and CNSTYPECODE with examples
3.2.18.2. Benefits of classification according to CNSORDERNO and CNSTYPECODE
3.2.18.3. Plugin "Resolve check"
3.2.18.4. Plugin "Batch classification of projects"
3.2.18.5. TestMeta: General for Order number or Typecode
3.2.18.6. TestMeta: ReverseConfigs / Reverse Search (automatic)
3.2.18.7. Index order numbers dependent on value ranges
3.2.18.8. Limit resolving of value ranges (yellow fields) via config key

PARTproject -> Edit project -> General tabbed page -> Variables -> Variable with order number and/or Variable with type code

[Note] Note

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

    If CNSORDERNO and CNSTYPECODE shall be classified, they may not use the same variable!

    If a respective entry is missing, an error message is displayed when performing Test project or Test directory. See Section 5.8.2.1.12, “ Test project / Test directory ”.

  • Distinction between CNSORDERNO and CNSTYPECODE

    • Variable with order number (ORDERNUMBER): 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).

      If project contains value range fields or not, it doesn't matter for the decision if ORDERNUMBER or TYPECODE. If there are value range fields, they can (but don't have to) change the order number. However, the change does not show any system.

      Example: Order number changes when changing value range value

      Example: Order number changes when changing value range value

    • Variable with type code (TYPECODE): The single parts of code are in relation to values of certain variables (e.g. type/serie, geometrical values such as length or diameter or other variable values defining 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 already existing catalogs the respective mapping can be adjusted semi-automatically by the catalog manufacturer/modeler with little effort. Depending on manufacturer it may be possible that different identifiers are available. These variants have to be considered. Information on the Plugin Batch classification of projects can be found under Section 5.13.6, “ Batch classification of projects ”.

In PARTdataManager, you can switch between normal Full-text search and search for Order number or type code .

The search method Order number or type code should be used when explicitly searching for it. Due to uniqueness this search will always directly lead to the desired result (if the catalog is accordingly prepared).

This method does not only lead to desired result when searching for a fixed Order number / Type code, but also then, when it is composed by values from value range variables and in fact both for simple and for complex combinations.

[Note] Note

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

In order to detect which cases exist in a catalog the Resolve check should be performed. See Section 5.8.2.1.15.18, “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

    The inclusion into the full-text search index is possible if there are less than 25.000 possible combinations per project or 50.000 per catalog (default limit) in addition to the standard rows. Setting the limit is performed via configuration file %cadenas_setup%/partsol.cfg. On this please see under Section 3.2.18.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 catalogs with very complex value ranges, where resolving would create millions and billions of combination possibilities, which exceeds the config limit (max. 25.000 per project, max. 50.000 per catalog) for the inclusion into the full-text index (Lucene index).

    Example project with many value range variables, which build-up the part number interactively

    Example project with many value range variables, which 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 at 2) and 3): Only a certain number of the actual combination possibilities resulting from value range fields has an order number and is really available or orderable.

    -> A CSV (pnomapping.csv) with mapping information on Order number and Typecode 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

    -> Search entry is order number in search mode Search for order number / type code , in fact, the search is performed with the type code in background.

    [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


[3] The Class variables CNSORDERNO and CNSTYPECODE are mapped to the desired variable under Variable with order number and Variable with type code. Also see Section 5.13.4, “Simple assigning of important variables to CNS classification ”.

[4] Key VARSEARCHRESOLVEORDERNO. On project level it is in the project file, on catalog level in $CADENAS_DATA/23d-libs/<catalogname>/dir.prj. No corresponding GUI. Manual intervention not necessary.

[5] Always take care to have an up-to-date full-text search index and/or geo search index for the required catalogs, in order to really have all functions of your software version available. (With V11 SP10 for example, the function Reverse Search – Test reverse search has been added which will access the full-text search index.)

Prev  Up  Next
3.2.17.  Set Up Tag Cloud Exclusion  Home  3.2.18.1. Use of CNSORDERNO and CNSTYPECODE with examples