5.8.2.1.16.  Automation
5.8.2.1.16.26.  Reverse Search - Resolve check (automatic)
Prev  Next
5.8.2.1.16.26.  Reverse Search - Resolve check (automatic)
5.8.2.1.16.26.1. Resolution check - use case
5.8.2.1.16.26.2. Resolution check - prerequisites/preparations
5.8.2.1.16.26.3. Resolution check - catalog analysis
5.8.2.1.16.26.4. Resolution check - Activation
5.8.2.1.16.26.5. Resolution check - analysis after catalog changes
5.8.2.1.16.26.6. Reverse Search – Test Order Number Search
5.8.2.1.16.26.6.1. Functional description
5.8.2.1.16.26.6.2. Preconditions/Preparations
5.8.2.1.16.26.6.3. Example (testing automatically created list)
5.8.2.1.16.26.6.4. Online testing
5.8.2.1.16.26.7. Resolution check - Special notes
5.8.2.1.16.26.8. Resolution check - Config settings
5.8.2.1.16.26.9. Reverse search - resolution check (automatic) - avoid problematic constructs
5.8.2.1.16.26.1.  Resolution check - use case

If the number of possible combinations resulting from value ranges is too large, a reverse search is used instead of indexing, which also enables the value range values to be found successfully.

Certain requirements must be met so that components can be found by searching by order number [Order number] or type code, including those for which CNSORDERNO and CNSTYPECODE are made up of value range values.

The resolution check checks [Resolve check] whether catalogs can be resolved in the full-text search index or whether a reverse search is necessary. If the catalog has been prepared accordingly, even the most complex cases can be successfully searched using the order number [Order number] or type code.

The benefits of a reverse search are

  • 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 certainly 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.

  • See also Section 5.12.7.2, “Benefits of classification according to CNSORDERNO and CNSTYPECODE”.

5.8.2.1.16.26.2.  Resolution check - prerequisites/preparations

  1. Classification according to CNSORDERNO and/or CNSTYPECODE

    [Important]Important

    Information on the distinction between CNSORDERNO and CNSTYPECODE, i.e. when to classify according to what, can be found under Section 5.12.7, “Classification according to CNSORDERNO / CNSTYPECODE ”.

    [Note]Note

    Classification is a necessary prerequisite, otherwise an error message appears when executing the context menu command Reverse Search - Resolution check (automatic) [Reverse Search - Resolve check (automatic)].

    This task can be performed semi-automatically for the entire catalog using the Classify projects in batch run [Batch classification of projects] plugin (see Section 5.12.6, “ Batch classification of projects ”).

    Dialog box "Attribute Classification"

    Dialog box "Attribute Classification"

    The result is an entry under Variable with order number and/or Variable with type code.

    [Note]Note

    During the test [Test directory] directory/test project [Test directory] (test meta ), the system checks whether there is an entry under Variable with order number and/or Variable with type code. The following illustration shows the corresponding entry in the CNS classification. The frequently used characteristic designation CNSORDERNO and CNSTYPECODE is visible here.

  2. Update the full-text index (if not already done by automated process).

    If the option Automatically update full-text search index on changes [Automatically update full-text search index when changes are made] was not activated in the setting options of PARTproject, you must now do this yourself manually via PARTadmin (see Section 1.3.3.6.6.3, “Full text search index ” in PARTsolutions Administration - Manual ).

5.8.2.1.16.26.3.  Resolution check - catalog analysis

  1. Download the current SVN state.

    Download changed files in directories / projects from server

    Download changed files in directories / projects from server

  2. Update full-text search index (if not already done in an automated process).

    If the option Automatically update full-text search index on changes [Automatically update full-text search index when changes are made] was not activated in the setting options of PARTproject, you must now do this yourself manually via PARTadmin (see Section 1.3.3.6.6.3, “Full text search index ” in PARTsolutions Administration - Manual ).

  3. Before you start the analysis, make sure that the existing resolvecheck.cfg is deleted from your local catalog directory. Otherwise, the resolution check will use the existing results from the existing file.

    [Note]Note

    After each analysis, the configuration file $CADENAS_DATA/23dlibs/<catalogname> the configuration file resolvecheck.cfgis generated, which lists all results centrally.

    Before performing the run again, delete this file in order to get a "clean" result.

    Exemplary excerpt:

    [REVERSEANALYSIS]
pfad/projectname.prj=GEOMDATE;Tabellenzeilen;Varianten;Automatische Suche möglich 
(0 oder 1)z.B. project.prj=01.01.2019;1;10;1
...
...
ganz unten 
[COMMON]
REVERSEANALYSIS=Datum des letzten Laufs

    A new initial test run can also be forced automatically via the config setting. See Section 5.8.2.1.16.26.8, “ Resolution check - Config settings”.

  4. In the context menu of the desired catalog, call up the Reverse search - resolution check (automatic) [Reverse Search - Resolve check (automatic)] command under Automation.

    After finished process a respective message is displayed whether the catalog could be completely resolved or not.

  5. Click on OK.

    An initial resolution check [Resolve check] can take some time depending on the size of the catalog. If nothing or little has changed when the catalog is called up again, the result is displayed again after a few seconds. Only changed projects are tested.

    -> The results of the resolution check are displayed in detail in the Resolution results [Results] dialog box.

    Example:

    Example of resolution results [Results]

    Example of resolution results [Results]

  6. Check the results.

    The Number [Amount] column shows the variants per project. For projects without value ranges [Projects without value ranges], the value is the same as the number of table rows and for projects with value ranges [Projects with value ranges], the value indicates the number of variants or, if empty, then the variants are over 25000 (limit value, no further checks are made).

    In the Projects column, the numerical value in brackets indicates how many projects there are in the respective category.

    The following table shows the meaning of the icons.

    One or several parts under this node are not yet resolved. The blue exclamation mark stands for different cases:

    • Projects with value ranges

    • The automatic search takes too much time

    • Manual creation of the reverse search necessary

    Classification is missing (projects were ignored)

    An error message is displayed.

    This subsection is resolved in one way or another and does not require special attention:

    • Automatic calculation of the reverse search

    • Inclusion in full text index up to max. 50,000 lines

    • Projects without value ranges

    ----------------------------------------------------------------------------------------

    • Projects with an irrelevant value range (Dimension attribute)

      The automatic resolution was successful, but the order number or type code contains an invalid value range variable of the type functional characteristic [Function attribute] or dimensional characteristic.

      [Note]Note

      Details can be found under Section 7.8.14, “ Identification type ”.

    For this project, a manual reverse configuration is saved. (<project name>_pnoreverse.cfg available)
    Project will be resolved and written in the Lucene index.

    The following table shows the meaning of the individual categories.

    Two main levels are displayed under Projects, in which a distinction is made as to whether projects have value ranges at all. Projects with value ranges are differentiated in detail in 4 categories.

    Projects with value ranges Category Meaning
     

    1

    Automatic calculation of the reverse search: The reverse search could be calculated automatically for the projects listed here. A heuristic check did not reveal any errors.

    Under $CADENAS_DATA/index/cat/cat_<catalogname>/graph a file graphlookup.map is generated. This contains all information down to project level across all catalogs.

    2

    Inclusion in full text index up to max. 50,000 lines

    3

    Manual reverse search available (there is a configuration file at catalog level pnoreverse.cfg)

    4

    Manual creation of the reverse search necessary

    All projects not assigned to category 1-3, will appear in category 4.

    It may still be possible to achieve automatic resolution by making certain adjustments within the project structure. You can find information on this at Section 5.8.2.1.16.26.9, “ Reverse search - resolution check (automatic) - avoid problematic constructs”. Otherwise, the reverse search must be created manually. See ???.

    Projects without value ranges   

    It is easy to estimate the effort required to achieve the highest quality search results:

    • Category 4 is empty -> everything is perfect

    • Category 4 is not empty

      If the catalog could not be fully resolved, adjustments must be made for the projects under category (4 ) Manual creation of reverse search [Manual creation of the reverse search necessary]:

      -> Check whether the relevant projects can be resolved by structural conversions (see Section 5.8.2.1.16.26.9, “ Reverse search - resolution check (automatic) - avoid problematic constructs”). If this is not possible, reverse configurations of the type pnoreverse.cfg must be created manually (see ???).

      For detailed information, click on Export list and Export csv [Export csv file].

      • -> Export list button

        All projects are exported under Manual creation of reverse search required [Manual creation of the reverse search necessary].

        (simple listing of project paths)

      • -> Export Csv [Export csv file] button

        All listed projects will be exported.

        Example: CSV opened in a spreadsheet program

        Example: CSV opened in a spreadsheet program

        • PRJ_PATH: Path to corresponding project

        • NN: Standard number

        • QASTATE: Current QA state of project

        • IS_COMPLEX: True, if there are yellow fields (object attribute or geometry attribute

        • SUBTYPE:

          • 0: Project does not contain any value ranges (yellow fields).

          • 1: Project contains value ranges (yellow fields) and automatic calculation of the reverse search [Automatic calculation of the reverse search] does not work. -> Manual creation of the reverse search is required.

          • 2: Project contains value ranges (yellow fields) and Automatic calculation of the reverse search works so that these projects can be resolved automatically.

          • -1: Classification according to CNSORDERNO or CNSTYPECODE is missing. Compare the icon with the red exclamation mark above.

          • -2: Project contains value ranges (yellow fields); Auto Reverse Search runs into a timeout. Manual reverse scripts are required.

        • RANGES: Number of value ranges (yellow fields). If RANGES is 0, then SUBTYPE is also 0)

        • ROWS = Number of table rows

        • AMOUNT = Number of variants

        • HASPNO: For this project a manually created reverse script (_pnoreverse.cfg) is already available (manual configuration solution).

        • HASFLAG = The VARSEARCHRESOLVEORDERNO flag is already set to 1 and the project is taken in the Lucene index. You have to regard not to exceed the limit of 50000 per catalog.

        • REPORT: Detailed report on how the algorithm is resolving the order number. Field is only filled, if a manual script is required.

5.8.2.1.16.26.4.  Resolution check - Activation

  1. Check out the SVN catalog (if not already done for the catalog analysis ).

  2. Update the full text search index (if not already done for the catalog analysis ).

    [Note]Note

    This is necessary so that the projects listed in the section Inclusion in full text index up to a maximum of 50,000 lines [Inclusion in full text index up to max. 50,000 lines] are re-indexed.

  3. Execute the Resolve Check using the context menu command Reverse Search - Resolve Check (automatic) [Reverse Search - Resolve check (automatic)] (if not already done for the catalog analysis ).

  4. Click on Apply.

    If the projects shown in the categories (1 ) Automatic calculation of reverse search [Automatic calculation of the reverse search],(2 ) Inclusion in full text index up to a total of max. 50,000 lines [Inclusion in full text index up to max. 50,000 lines] and (3 ) Manual reverse search available are to be marked accordingly within the program, click on Apply!

    In this example,"Apply [Apply] " would affect 9 projects (6+1+2).

    In this example,"Apply [Apply] " would affect 9 projects (6+1+2).

    Click on Apply to control the resolution flag.[24]

    • The flag is set to 1 for projects in the category Inclusion in full text index up to a total of max. 50,000 lines [Inclusion in full text index up to max. 50,000 lines] (2 ).

    • For projects in the Automatic calculation of reverse search [Automatic calculation of the reverse search] (1 ) section, the flag is set to 2.

    • Lines without variants (value ranges) or with a manual Resolve configuration (3 ) remain at 0.

    Click on Apply to confirm that the flag is set for the potential x projects.

    [Note]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.

  5. Check-in the SVN catalog.

  6. In order for the Reverse Search to be really available, the flag "Auto reverse Search" has to be activated.

    [Note]Note

    The activation can only be carried out by an authorized person!

  7. Optionally, reverse search (automatic) can be activated for PCOM portals.

    [Note]Note

    The activation can only be performed by PCOM Admins!

  8. Execute the command Generate QA status [Generate QA catalog...]... (for testing)

  9. Executing the Publish Live Stand [Publish Live state...] command... (subject to a charge)

    Details can be found under Section 6.10, “ Publish catalog ”.

5.8.2.1.16.26.5.  Resolution check - analysis after catalog changes

  1. Basically:

    For new or changed projects, Testmeta will check if the projects are resolvable and if ORDERNUMBER/TYPECODE are classified and will issue warnings / errors - if necessary.

    • If something cannot be resolved according to Testmeta error message, there are two possibilities:

      • Reconstruction what shouldn't happen for new projects, according to modelling guidelines.

      • Using a manual reverse script, which shouldn't really happen as well, according to modelling guidelines.

  2. What happens if a variable or variable value is changed?

    For all projects that can be resolved via automatic calculation of the reverse search [Automatic calculation of the reverse search], no further adjustments are necessary in this case, apart from republishing the catalog.

  3. What happens if a variable is cancelled or added?

    For all projects that can be resolved via automatic calculation of the reverse search [Automatic calculation of the reverse search], no further adjustments are necessary in this case, apart from republishing the catalog.

  4. What is the update procedure?

    If there are changes, this is the required approach:

    1. Check out catalog from SVN

    2. Update the full-text search index (except already done automatically).

      See Section 1.3.3.6.6.3, “Full text search index ” in PARTsolutions Administration - Manual .

    3. Carry out a resolution check [Resolve check]

    4. Resolution check [Resolve check] -> Apply

    5. Update full-text search index again.

    6. Check in catalog into SVN.

    7. Execute the command Generate QA status [Generate QA catalog...]... (for testing)

    8. Executing the Publish Live Stand [Publish Live state...] command... (subject to a charge)

5.8.2.1.16.26.6.  Reverse Search – Test Order Number Search
5.8.2.1.16.26.6.1. Functional description

In PARTproject -> Project selection -> Context menu of the catalog (or a subdirectory or project) -> Automation you will find the function Reverse Search - Test order number search [Reverse Search – Test Order Number Search].[25]

This allows you to check which parts are found from an automatically generated list of order numbers or type codes (composed of values from yellow fields), so that you can be sure that these will lead to correct hits, e.g. when searching in the PARTdataManager will lead to correct hits.

Furthermore you can check a certain list (either initially or the output result of an automatic generation after adjustments to optimize results have been performed).

Order number or type code search

Order number or type code search

5.8.2.1.16.26.6.2. Preconditions/Preparations

Perform the following steps before starting a test run:

  1. Always use latest released V12 version.

  2. Make sure that you have installed the current SVN catalog with the latest updates and changes on catalog.

  3. Make sure that you are doing a “fresh” resolve check.

    To do this, delete the configuration file under $CADENAS_DATA/23dlibs/<catalogname> delete the configuration file resolvecheck.cfg before starting the resolution check.

  4. Add the catalog in PARTadmin in the configuration file reverselookup.cfg, in the key generategraph.

  5. Update display index + full-text search index in PARTadmin.

5.8.2.1.16.26.6.3. Example (testing automatically created list)

  1. Select the catalog directory, a subdirectory or a project and click on the context menu command Reverse Search - Test order number search [Reverse Search – Test Order Number Search].

    Context menu command "Reverse Search - Test order number search [Reverse Search – Test Order Number Search] "

    Context menu command "Reverse Search - Test order number search [Reverse Search – Test Order Number Search] "

    -> The same-named dialog box is opened.

    Context menu command "Reverse Search - Test order number search [Reverse Search – Test Order Number Search] "

    Context menu command "Reverse Search - Test order number search [Reverse Search – Test Order Number Search] "

  2. Settings:

    • Target path export list [Destination path export list]: Click on the Browse button .. . and select a directory. (The export list is then saved in this directory)

    • Number per project [Amount per project]: Number of tested numbers per project

    • Open list after the test [Open list after test]: Yes/No

    • Storage method:

      • All in one list

      • Separate list per project

  3. Click on Start.

    -> First a list of random order numbers is generated (see progress bar under Generating order numbers [Generation of order numbers] ) and in the second step these numbers are tested (see progress bar under Testing the search [Test the search] ).

    -> After the test run you will receive a summary of the result directly in the program.

    -> Furthermore the results are written into the automatically generated export list. The result occurs in the last column. Found numbers are marked with "OK", not found with "FAIL".

    The individual columns:

    • Order number: Tested order number

    • MIdent: MIdent of order number

    • Project: Tested project

    • Project path: Project path of tested project

    • Test result: OK/FAIL

    CSV file loaded in Excel

    CSV file loaded in Excel

  4. Optionally

    If there were failed searches and the reverse search functionality has been optimized, you can reload and test the output list with Load list.

Example (initial testing of a list with defined order numbers/type codes)

Alternatively, you can also test with a list of defined order numbers/type codes. The setting under Number per project [Amount per project] is then not relevant.

Start the process by clicking on Load list.

-> The directory set under Target path export list [Destination path export list] is opened. Select the desired CSV file.

[Note]Note

The structure of the list has to be as follows:

  • In the first line any column name

  • In the second line the catalog name with the exact spelling as it is used in the SVN

  • Then all lines with the order numbers or type codes to be tested

-> The function is executed and the results are written into the loaded CSV file.

The test result can be found in the last column. Found numbers are marked with "OK", not found with "FAIL".

5.8.2.1.16.26.6.4. Online testing

  1. Test order numbers via "Reversemap Service"

    If the reverse search was already activated for the online usage, you can test order codes manually with the reversemap service.

    Just type in the URL in the browser and see if you get back the MIdent:

    https://webapi.qa.partcommunity.com/service/reversemap?catalog=norelem&part=06247-116044&exact=1

    https://webapi.partcommunity.com/service/reversemap?catalog=norelem&part=06247-116044&exact=1

    catalog = -> Catalog you want to search for

    part = -> Order code you want to search for

    exact = -> 1 (exact search for the order number); 0 (ignore upper/lower case)

    Result "OK"

    Example "mident"

    Example "mident"

    Result "Error"

    Example "error"

    Example "error"

  2. Test order numbers on 3Dfindit or Supplier Portal

    You can also search for order codes on 3Dfindit portal or the supplier portal (config key has to be activated before it is working on supplier portal).

    Please make sure that you have already selected the catalog on 3Dfindit. The Order code search is not working in the standard search bar on 3Dfindit!

5.8.2.1.16.26.7.  Resolution check - Special notes

  • During the automatic calculation of the reverse search, a file is created under $CADENAS_DATA\index\cat\cat_resolve_check\graph a file graphlookup.map is generated. This file is ignored by default when uploading to online portals and must be explicitly enabled for use by CADENAS.

  • Searching by order number or type designation [Order number or type code] on online portals only works in the relevant catalog (in PARTdataManager also across all catalogs).

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

  • When the CIP file of the catalog is created, the results of the resolution check are set in the dir.prj of the catalog in the form of the following keys:

    • CATMETRICS_SEARCHABLE_PROJECTS

      Number of projects which should be found (All visible projects and projects with SEARCHINDEX=ON)

    • CATMETRICS_REVERSE_CLASSIFIED

      Number of projects with a classified order number or type code variable

    • CATMETRICS_REVERSE_STATIC

      Number of projects without value ranges

    • CATMETRICS_REVERSE_CONFIG

      Number of projects with manual reverse scripts

    • CATMETRICS_REVERSE_LUCENE

      Number of projects with order numbers and type codes indexed by lucene

    • CATMETRICS_REVERSE_GRAPH

      Number of projects which can be solved via auto reverse search

    • CATMETRICS_REVERSE_FAILED

      Number of projects which can't be found by the reverse search

    Background information: To create the information that is written to dir.prj, the configuration files resolve_check.cfg and qacheck.cfg are evaluated. In resolve_check.cfg, for example, the ResolveChecker writes the projects for which an automatic reverse search is possible. However, it is possible that someone has changed a project without running the ResolveChecker. In this case, the information is read from qacheck.cfg, to which Testmeta writes, and Testmeta must always be called for changed projects, as otherwise they cannot be published.

5.8.2.1.16.26.8.  Resolution check - Config settings

The configuration file can be found under $CADENAS\libs\all\plugins\resolve_check.cfg:

The quality of the heuristic check for the automatic calculation of the reverse search can be adjusted via the first three keys.

If NEVERSKIPGRAPH is set to 1 (default is 0) at each run a complete recalculation is performed. (May be makes sense on testing purposes if the automatic generation has been enhanced.)

[COMMON]
# maximum graphsearch searches per project
MAXHEURISTICS=10000
# maximum time in minutes to use when counting variants
MAXTIME=15
# maximum time in minutes when checking graphsearch results
MAXTIMETEST=15
# always recheck the graphsearch even if we already have a saved result
NEVERSKIPGRAPH=0

5.8.2.1.16.26.9.  Reverse search - resolution check (automatic) - avoid problematic constructs

Definitions for variable abbreviations used

  • RNG: Value range variable that defines a range

    Example:

    [10:100]

  • NMD: Value range variable with concrete values

    Example 1

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

    Example 2 (value range variable with naming [Value range variable with naming] )

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

  • ALG: Variable based on feature algorithm [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)

Following figure shows the setting area for above mentioned value range variables.

Variable manager [Variable Manager] -> Status

Variable manager [Variable Manager] -> Status

Problematic constructs

  • Example 1 - Indirect, calculated use of value range

    [Note]Note

    The following restriction applies when using algorithms:

    "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:

    • NMD=15,20,30

      NR= xyz 200

      NR=xyz ALG
ALG=10*NMD

    • Value range with increment. This would correspond to a list of fixed values (10,20,30,...,100), but still does not work due to the above restriction.

      RNG= [10: 100/10 ]

      NR= xyz 500

      NR=xyz ALG
ALG=10*RNG

    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]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.



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

[25] The corresponding plugin files must be located at %CADENAS%/libs/all/plugins: resolve_check_tester.cfg, resolve_check_tester.def, resolve_check_tester.vbb

Prev Up Next
5.8.2.1.16.25.  Enrich catalog with PDT information  Home 5.8.2.1.16.27.  Reverse Search - Test of the order number search