Always good search results since even order numbers (article numbers) or type codes built from complex value ranges (yellow fields) values are found.

Via order number / type code, articles on PARTcommunity portals can safely be found and correctly be ordered. Cross-links between portals are possible. External assistants can directly request geometry by calling order number / type code instead of using a complex list of deeplinks.

Initial article assignment of ERP numbers to PARTsolutions projects on the base of order number / type code is simplified, as numbers are absolutely unique.

Category 4 is empty -> everything perfect

Category 4 is not empty -> Export list (see below)

Projects with value ranges:

Projects without value ranges:

Export list:

Exports all projects under Manual creation of the reverse search necessary.

(simple listing of project paths)

Export csv file: All listed projects will be exported.

Example: CSV opened in a spreadsheet program

Apply: This function concerns the categories Automatic calculation of the reverse search, Inclusion in full text index up to max. 50,000 lines and Manual reverse search available.

Here in this example "Apply" would affect 9 projects (6+1+2).

Clicking on Apply affects the setting of the resolve flag.^[33]

When clicking on Apply you confirm that the flag will be set for x potential projects.

Note For this write permission is required for the respective catalog. Catalogs managed with SVN have to be checked out before and after modification checked in again.

When performing the automatic calculation at the reverse search under $CADENAS_DATA\index\cat\cat_resolve_check\graph eine Datei graphlookup.map is created. This file will be ignored during the upload on online portals by default and has to be explicitly unlocked by CADENAS.

Searching for Order number or type code only works in respective catalog on Online portals (in PARTdataManager over all catalogs as well).

Always a search should usefully be performed in the desired catalog. However, sometimes a catalog consists of subcatalogs (for example, the Standard catalog of DIN, ISO, EN, etc.). In such a case please perform the search in the respective subcatalog.

When generating the CIP file of a catalog, in the catalog's file dir.prj, the results of the resolve check will be set in the form of following keys:

Background information: In order to create the information which shall be written into the dir.prj, the configuration files resolvecheck.cfg and *.qacheck are evaluated. E.g., the ResolveChecker writes to resolvecheck.cfg for which projects an automatic Reverse Search is possible. For the case that someone changed a project without executing the ResolveChecker the information is read from *.qacheck, where Testmeta is writing to, and for changed projects Testmeta has to be called in any case, because otherwise publication is not possible.

RNG: Value range variable defining a range

Example:

[10:100]

NMD: Value range variable with distinct values

Example 1

'x','b','y',...

Example 2 (Value range variable with naming)

1,'txt1',2,'txt2',...

ALG: Variable based on Attribute algorithm

Example:

ALG = '$A.-$B.-$C.-$D.-$E.-$F.-$G.'

TAB: Variable with fixed values

NR: Value to be resolved (Order number / Type code)

Example 1 - Indirect, calculated use of value range

Note When using algorithms following restriction applies: "Forwards" an algorithm results in a concrete calculated value, however, "backwards" the value used in the algorithm cannot be extrapolated, if an arithmetic operation is used; however, direct substitution works.

Example:

The order number (NR) results from the string 'xyz' and an attribute algorithm.

RNG=[10:100]

NR= xyz 500

NR=xyz ALG
ALG=10*RNG

Problem: ALG can be allocated to a unique value, however, due to above restriction the value of RNG cannot be detected.

The same would apply for following slightly modified cases, because here, also an arithmetic operation is performed:

Solution:

A solution possibly could be to determine the value range values in a way that a calculation via ALG could be omitted and to use RNG directly to determine NR.

Example 2 - Forward resolving with algorithm

Note The value of an algorithm cannot be set.

Example:

ALG1: Forward to a value range

ALG1=RNG (ALG1 is based on a value range)

ALG2: IF Statement to determine the displayed order number value

If ALG1='xyz' then
ALG2=123
Else If ALG1='abc' then
ALG2=789
End if
NR=DIN ALG2

Problem:

ALG1 can be allocated to a unique value, however, the value cannot be set due to above restriction.

Solution:

In the IF statement, directly use the value range instead of the algorithm variable.

If RNG='xyz' then
ALG2=123
Else If RNG='abc' then
ALG2=789
End if
NR=DIN ALG2

Example 3 - No separator between value range variables

Example:

NR=RNG1RNG2

Problem:

There is no separator between the two value ranges so that it doesn't become clear from which single value the order number / type code (NR) is combined.

For example, NR='3412' could be a combination of '341' and '2' or of '34' and '12'.

Solution: Set a separator between value range variables. Then it is clear, which element belongs to value range variable 1 and which to value range variable 2.

NR=RNG1-RNG2

Example 4 - No unique paths with same result

Example:

ALG:

RNG : 0,1,2,3

If a=1 then
ALG='01'
Else if a=2 then
ALG='0$RNG.'
End if

Problem:

ALG has multiple options which are partial equal. In the first condition "01" and in the second condition "01" as well.

If ALG has the same value reverse resolving cannot be successful. It can not be determined if we have case "a=1" or "a=2". As a consequence a statement about RNG=1 is also wrong.