powered by CADENAS

Manual

Manual

5.8.2.1.15.17. Reverse search ‒ Auflösungscheck (automatisch)
5.8.2.1.15.17.1. Anwendungsfall

Damit Bauteile via Suche nach Bestellnummer bzw. Typcode gefunden werden können, auch die, bei denen CNSORDERNO und CNSTYPECODE aus Wertebereichswerten aufgebaut sind, müssen bestimmte Voraussetzungen erfüllt sein. Ist die Zahl der Kombinationsmöglichkeiten, die sich aus Wertebereichen ergeben zu groß, wird nicht indexiert, sondern eine Reverse Search eingesetzt, welche ebenfalls erfolgreiches Finden der Wertebereichswerte ermöglicht.

Der Auflösungscheck prüft, ob Kataloge im Volltextsuch-Index auflösbar sind oder ob eine Reverse Search notwendig ist. Ist der Katalog entsprechend vorbereitet, kann auch in den komplexesten Fällen erfolgreich mit Bestellnummer bzw. Typcode gesucht werden.

Die Benefits einer Reverse Search sind:

  • Immer gute Suchergebnisse, da eben auch die aus komplexen Wertebereichswerten (gelbe Felder) aufgebauten Bestellnummern (Artikelnummern) bzw. Typenschlüssel gefunden werden.

  • Via Bestellnummer / Typenschlüssel können Artikel auf PARTcommunity-Portalen sicher gefunden und korrekt bestellt werden. Querverlinkungen von Portalen ist möglich. Externe Assistenten können statt mit einer komplexen Deeplinkliste auch über den Aufruf von Artikelnummer/Typenschlüssel direkt Geometrie anfordern.

  • Initiale Artikelzuordnung von ERP-Nummer zu PARTsolutions Projekten auf Basis von Bestellnummer / Typcode wird vereinfacht, da diese absolut eindeutig sind ("Urfüllung").

(Für Details siehe auch Abschnitt 3.2.18.2, „Benefits der Klassifizierung nach CNSORDERNO und CNSTYPECODE“.)

Im Rahmen des Auflösungscheck werden initial folgende Schritte benötigt

  1. Checken Sie den SVN-Katalog aus.

  2. Klassifizierung nach CNSORDERNO und CNSTYPECODE.

    [Hinweis] Hinweis

    Die Klassifizierung ist eine notwendige Voraussetzung, ansonsten erscheint eine Fehlermeldung.

    Diese Aufgabe kann für den ganzen Katalog halbautomatisch mit dem Plugin Projekte im Batchlauf klassifizieren (siehe Abschnitt 5.13.6, „Projekte im Batchlauf klassifizieren“) erledigt werden.

    Dialogfenster "Attribute Classification"

    Dialogfenster "Attribute Classification"

    Im Ergebnis erfolgt dann ein Eintrag unter Variable mit Bestellnummer und/oder Variable mit Typenschlüssel.

    [Hinweis] Hinweis

    Im Zuge von Verzeichnis testen/Projekt testen (Testmeta) wird geprüft, ob ein Eintrag unter Variable mit Bestellnummer und/oder Variable mit Typenschlüssel vorhanden ist. Die folgende Abbildung zeigt den entsprechenden Eintrag in der CNS-Klassifikation. Hier wird die oft verwendete Merkmal-Bezeichnung CNSORDERNO und CNSTYPECODE sichtbar.

  3. Aktualisieren Sie den Volltextsuchindex.

    Siehe Abschnitt 1.3.8.6.2, „Kontextmenübefehle im Einzelnen“ in PARTsolutions / PARTcommunity4Enterprise - Handbuch für Administration.

  4. Durchführen des Auflösungscheck (siehe nächster Abschnitt)

    [Hinweis] Hinweis

    Die Klassifizierung ist notwendige Voraussetzung. Siehe oben.

  5. Falls der Katalog nicht vollständig aufgelöst werden konnte, sind Anpassungen für die Projekte unter Kategorie "Manuelle Erstellung der Rückwärtssuche notwendig" vorzunehmen:

    -> Prüfen Sie, ob die betreffenden Projekte durch strukturelle Umstellungen aufgelöst werden können (siehe Abschnitt 5.8.2.1.15.17.6, „Reverse Search (automatisch) - Problematische Konstrukte vermeiden“). Sollte dies nicht möglich sein, müssen manuell Reverse-Konfigs vom Typ pnoreverse.cfg erstellt werden (siehe Abschnitt 5.8.2.1.15.20, „Reverse TypeCode Regeleditor“).

  6. Wenn die in den Kategorien Automatische Berechnung der Rückwärtssuche, Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen und Manuelle Rückwärtssuche vorhanden ausgewiesenen Projekte programmintern entsprechend gekennzeichnet werden sollen, klicken Sie unbedingt auf Anwenden!

    [Hinweis] Hinweis

    Erzeugen Sie den Volltextsuchindex neu. Dies ist notwendig, damit die in der Rubrik Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen ausgewiesenen Projekte neu indiziert werden.

  7. Checken Sie den SVN-Katalog ein.

  8. Damit die Funktionalität auch tatsächlich zur Verfügung steht, muss das Flag "Auto reverse Search" aktiviert werden.

    [Hinweis] Hinweis

    Die Aktivierung kann nur von einer authorisierten Person vorgenommen werden!

  9. Optional kann die Reverse search (automatic) für PCOM Portale aktiviert werden.

    [Hinweis] Hinweis

    Die Aktivierung kann nur von PCOM Admins vorgenommen werden!

  10. Ausführen des Befehls QA Stand generieren... (zum Testen)

  11. Ausführen des Befehls Live Stand publizieren... (kostenpflichtig)

Aktivierung der Reverse Search (automatic) nach Katalog-Analyse/-Verbesserung

Erfolgt die Aktivierung der Reverse Search (automatic) nachgeschaltet zu einer Kataloganalyse, bzw. -verbesserung, sind folgende Schritte notwendig:

  1. Aktivierung des Flag "Auto reverse Search"

    [Hinweis] Hinweis

    Die Aktivierung kann nur von einer authorisierten Person vorgenommen werden!

  2. Optional kann die Reverse search (automatic) für PCOM Portale aktiviert werden.

    [Hinweis] Hinweis

    Die Aktivierung kann nur von PCOM Admins vorgenommen werden!

  3. Ausführen des Befehls QA Stand generieren... (zum Testen)

  4. Ausführen des Befehls Live Stand publizieren... (kostenpflichtig)

Analyse nach Katalogänderungen

  1. Grundsätzlich:

    Bei neuen oder geänderten Projekten prüft Testmeta, ob die Projekte auflösbar und ob die ORDERNUMBER/TYPECODE klassifiziert sind und gibt Warnungen / Fehler aus.

    • Wenn etwas nicht auflösbar ist laut Testmeta-Fehlermeldung, bleiben 2 Möglichkeiten:

      • Umbau, was laut Modellierungsrichtlinie bei Neuprojekten nicht vorkommen sollte

      • Einsatz eines manuellen Reversescript, was ebenfalls nach Modellierungsrichtlinie nicht vorkommen sollte.

  2. Was passiert, wenn eine Variable bzw. ein Variablenwert geändert wird?

    Für alle Projekte, die über Automatische Berechnung der Rückwärtssuche aufgelöst werden können, sind in diesem Fall bis auf erneute Publizierung des Katalogs keine weiteren Anpassungen nötig.

  3. Was passiert, wenn eine Variable entfällt oder dazukommt?

    Für alle Projekte, die über Automatische Berechnung der Rückwärtssuche aufgelöst werden können, sind in diesem Fall bis auf erneute Publizierung des Katalogs keine weiteren Anpassungen nötig.

  4. Wie ist der Ablauf, wenn eine Analyse der Katalogdaten durchgeführt werden soll?

    Wenn sich Änderungen ergeben haben, ist die folgende Vorgehensweise für das Katalog-Update durchzuführen:

    1. Katalog aus SVN auschecken

    2. Aktualisieren Sie den Volltextsuchindex.

      Siehe Abschnitt 1.3.8.6.2, „Kontextmenübefehle im Einzelnen“ in PARTsolutions / PARTcommunity4Enterprise - Handbuch für Administration.

    3. Auflösungscheck durchführen

    4. Auflösungscheck -> Anwenden

    5. Aktualisieren Sie den Volltextsuchindex erneut

    6. Katalog ins SVN einchecken

    7. Ausführen des Befehls QA Stand generieren... (zum Testen)

    8. Ausführen des Befehls Live Stand publizieren... (kostenpflichtig)

5.8.2.1.15.17.2. Ablauf im Detail
  1. Rufen Sie im Kontextmenü des gewünschten Katalogs unter Automatisierung den Befehl Reverse search ‒ Auflösungscheck (automatisch) auf.

    [Hinweis] Hinweis

    Voraussetzung: Der Volltextsuchindex muss aktuell sein.

    Nach beendetem Prozess erscheint eine entsprechende Meldung, ob der Katalog vollständig aufgelöst werden kann oder nicht.

  2. Klicken Sie auf OK.

    Ein initialer Auflösungscheck kann je nach Kataloggröße einige Zeit in Anspruch nehmen. Hat sich bei erneutem Aufruf nichts oder wenig verändert, wird nach wenigen Sekunden wieder das Ergebnis angezeigt. Es werden nur geänderte Projekt getestet.

    -> Die Ergebnisse des Auflösungschecks werden detailliert angezeigt.

    Auflösungsergebnisse

    Auflösungsergebnisse

Alle Projekte, die mit der Automatischen Rückwärtssuche gelöst werden können, landen in der ersten Kategorie (Automatische Berechnung der Rückwärtssuche).

Alle Projekte, die bis zu insgesamt 50.000 Varianten aufgelöst werden können, erscheinen in Kategorie 2 (Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen).

Alle Projekte, die mit der Manuellen Rückwärtssuche gelöst wurden, kommen dann in Kategorie 3 (Manuelle Rückwärtssuche vorhanden).

Der Rest landet in Kategorie 4 (Manuelle Erstellung der Rückwärtssuche notwendig).

Eine Aufwandsabschätzung zur Erreichung höchster Suchergebnisqualität ist einfach möglich:

  • Kategorie 4 ist leer -> alles perfekt

  • Kategorie 4 ist nicht leer -> Liste exportieren (siehe unten)

Unter $CADENAS_DATA/23dlibs/<catalogname> wird die Datei resolvecheck.cfg erzeugt, die zentral alle Ergebnisse auflistet.

Beispielhafter Ausschnitt:

[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

[Hinweis] Hinweis

Ein erneuter initialer Prüflauf kann via Konfig-Einstellung erzwungen werden. Siehe unten.

5.8.2.1.15.17.3. Benutzeroberfläche im Detail

Rubriken

Unter Projekte werden zwei Hauptebenen angezeigt, in denen unterschieden wird, ob Projekte überhaupt Wertebereiche besitzen. Projekte mit Wertebereichen werden detailliert in 4 Gruppen unterschieden.

  • Projekte mit Wertebereichen:

    • Automatische Berechnung der Rückwärtssuche: Für die hier aufgelisteten Projekte konnte die Rückwärtssuche automatisch berechnet werden. Eine heuristische Überprüfung hat keine Fehler ergeben.

      Unter $CADENAS_DATA/index/cat/cat_<catalogname>/graph wird eine Datei graphlookup.map erzeugt. Diese enthält katalogübergreifend alle Informationen bis hinunter auf Projektebene.

    • Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen

    • Manuelle Rückwärtssuche vorhanden (auf Katalogebene gibt es eine Konfigurationsdatei pnoreverse.cfg)

    • Manuelle Erstellung der Rückwärtssuche notwendig

      Evtl. lässt sich durch gewisse Anpassungen innerhalb der Projektstruktur eine automatische Auflösung doch noch erreichen. Hinweise hierzu finden Sie unter Abschnitt 5.8.2.1.15.17.6, „Reverse Search (automatisch) - Problematische Konstrukte vermeiden“. Ansonsten muss die Rückwärtssuche manuell erstellt werden. Siehe Abschnitt 5.8.2.1.15.20, „Reverse TypeCode Regeleditor“.

  • Projekte ohne Wertebereiche:

Anzahl: Anzahl der Varianten pro Projekt. Bei Projekte ohne Wertebereiche ist der Wert gleichbedeutend mit der Anzahl Tabellenzeilen und bei Projekte mit Wertebereichen gibt der Wert die Anzahl der Varianten an bzw. wenn leer, dann sind die Varianten über 25000 (Limitwert, weiter wird nicht geprüft).

Icons

Ein oder mehrere Teile unter diesem Knoten sind noch nicht gelöst.

Klassifikation fehlt

Es erscheint eine Fehlermeldung

Der Teilbereich ist auf die eine oder andere Art gelöst und braucht keine Aufmerksamkeit mehr.
Zu diesem Projekt ist eine manuelle Reversekonfiguration hinterlegt. (<projektname>_pnoreverse.cfg vorhanden)
Projekt wird aufgelöst in den Luceneindex geschrieben.

Schaltflächen

  • Liste exportieren:

    Es werden alle Projekte unter Manuelle Erstellung der Rückwärtssuche notwendig exportiert.

    (einfache Auflistung der Projektpfade)

  • Csv exportieren: Es werden alle gelisteten Projekte exportiert.

    Beispiel: CSV geöffnet in Tabellenkalkulationsprogramm

    Beispiel: CSV geöffnet in Tabellenkalkulationsprogramm

    • IS_COMPLEX: Wahr, wenn es gelbe Felder gibt, d.h. Sachmerkmal oder Geometriemerkmal

    • SUBTYPE:

      • 0: keine gelben Felder

      • 1: gelbe Felder und Automatische Berechnung der Rückwärtssuche geht nicht. -> Es wird eine manuelle Erstellung der Rückwärtssuche benötigt.

      • 2: gelbe Felder und Automatische Berechnung der Rückwärtssuche geht

      • -1: Klassifikation fehlt. Vergleiche oben das Icon mit rotem Ausrufezeichen.

    • RANGES = Anzahl gelber Felder (wenn RANGES 0 ist, sieht man auch bei SUBTYPE 0)

    • ROWS = Anzahl der Zeilen in der Tabelle

    • AMOUNT = Anzahl der Varianten

    • HASPNO = Zu diesem Projekt ist eine _pnoreverse.cfg Datei schon vorhanden (manuelle Konfigurationslösung)

    • HASFLAG = Das VARSEARCHRESOLVEORDERNO Flag ist hier schon auf 1 gesetzt und Projekt kommt in Lucenesuche. Muss beachtet werden, um nicht über das Limit von 50000 pro Katalog zu kommen.

  • Anwenden: Die Funktion betrifft die Kategorien Automatische Berechnung der Rückwärtssuche, Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen und Manuelle Rückwärtssuche vorhanden.

    Hier im Beispiel würde "Anwenden" 9 Projekte betreffen (6+1+2).

    Hier im Beispiel würde "Anwenden" 9 Projekte betreffen (6+1+2).

    Mit Klick auf Anwenden wird das Auflösungsflag gesteuert.[33]

    • Bei Projekten in der Rubrik Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen wird das Flag auf 1 gesetzt.

    • Bei Projekten in der Rubrik Automatische Berechnung der Rückwärtssuche wird das Flag auf 2 gesetzt.

    • Zeilen ohne Varianten oder mit einer manuellen Resolvekonfiguration bleiben auf 0.

    Mit Klick auf Anwenden bestätigen Sie, dass für die potentiellen x Projekte das Flag gesetzt wird.

    [Hinweis] Hinweis

    Hierfür werden Schreibrechte auf dem betreffenden Katalog benötigt. SVN-verwaltete Kataloge müssen zuvor ausgecheckt werden und nach der Modifizierung wieder eingecheckt.

5.8.2.1.15.17.4. Besondere Hinweise
  • Bei der automatischen Berechnung der Rückwärtssuche wird unter $CADENAS_DATA\index\cat\cat_resolve_check\graph eine Datei graphlookup.map erzeugt. Diese Datei wird beim Upload auf Online-Portale standardmäßig ignoriert und muss zur Verwendung explizit von CADENAS freigeschaltet werden.

  • Die Suche nach Bestellnummer oder Typbezeichnung funktioniert auf Online-Portalen nur im betreffenden Katalog (in PARTdataManager auch über alle Kataloge).

    Sinnvollerweise wird man eine Suche immer im gewünschten Katalog durchführen. Manchmal besteht ein Katalog aber aus Unterkatalogen (der Normenkatalog beispielsweise aus DIN, ISO, EN, etc.). In einem solchen Fall führen Sie die Suche bitte im betreffenden Unterkatalog aus.

  • Beim Erstellen der CIP-Datei des Katalogs werden in der dir.prj des Katalogs die Ergebnisse des Auflösungscheck in Form folgender Schlüssel gesetzt:

    • CATMETRICS_SEARCHABLE_PROJECTS

      Anzahl von Projekten, die gefunden werden sollten (alle sichtbaren Projekte und Projekte mit SEARCHINDEX=ON)

    • CATMETRICS_REVERSE_CLASSIFIED

      Anzahl von Projekten mit einer klassifizierten Bestellnummer oder Typecode Variable

    • CATMETRICS_REVERSE_STATIC

      Anzahl von Projekten ohne Wertebereiche

    • CATMETRICS_REVERSE_CONFIG

      Anzahl von Projekten mit manuellen Reverse Scripts

    • CATMETRICS_REVERSE_LUCENE

      Anzahl von Projekten mit Bestellnummern und Typecodes, die über Lucene indexiert sind.

    • CATMETRICS_REVERSE_GRAPH

      Anzahl von Projekten mit automatischer Berechnung der Rückwärtssuche

    • CATMETRICS_REVERSE_FAILED

      Anzahl von Projekten, die nicht mit der Reverse Search gefunden werden können

    Hintergrundinformation: Um die Informationen zu erstellen, die in die dir.prj geschrieben werden, werden die Konfigurationsdateien resolvecheck.cfg und qacheck.cfg ausgewertet. In resolvecheck.cfg schreibt z.B. der ResolveChecker, für welche Projekte eine automatische Reverse Search möglich ist. Es kann aber sein, dass jemand ein Projekt geändert hat, ohne den ResolveChecker auszuführen. In diesem Fall wird die Information aus der qacheck.cfg gelesen, in welche Testmeta schreibt, und Testmeta muss auf jeden Fall für geänderte Projekte aufgerufen werden, da sie ansonsten nicht publiziert werden können.

5.8.2.1.15.17.5. Konfig-Einstellungen

Die Konfigurationsdatei findet sich unter $CADENAS\libs\all\plugins\resolve_check.cfg:

Die Qualität der heuristischen Überprüfung bei der automatischen Berechnung der Rückwärtssuche kann mittels der ersten drei Schlüssel eingestellt werden.

Wird NEVERSKIPGRAPH auf 1 gesetzt (Default ist 0), wird bei jedem Lauf eine komplette Neuberechnung durchgeführt. (Zu Testzwecken evtl. sinnvoll, wenn die automatische Generierung verbessert wurde.)

[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.15.17.6. Reverse Search (automatisch) - Problematische Konstrukte vermeiden

Definitionen für verwendete Variablenabkürzungen

  • RNG: Wertebereichsvariable die einen Bereich definiert

    Beispiel:

    [10:100]
  • NMD: Wertebereichsvariable mit konkreten Werten

    Beispiel 1

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

    Beispiel 2 (Wertebereichsvariable mit Benennung)

    1,'txt1',2,'txt2',...
  • ALG: Variable basierend auf Merkmalalgorithmus

    Beispiel:

    ALG = '$A.-$B.-$C.-$D.-$E.-$F.-$G.'
  • TAB: Variable mit festen Werten

  • NR: Aufzulösender Wert (Bestellnummer / Typecode)

Die folgende Abbildung zeigt den Einstellungsbereich für oben erwähnte Wertebereichsvariaben.

Variablenmanager -> Status

Variablenmanager -> Status

Problematische Konstrukte

  • Beispiel 1 - Indirekte, berechnete Verwendung des Wertebereichs

    [Hinweis] Hinweis

    Bei der Verwendung von Algorithmen gilt folgende Einschränkung:

    Ein Algorithmus ergibt "vorwärts" immer einen konkreten berechneten Wert, aber "rückwärts" kann der im Algorithmus verwendete Wert nicht erschlossen werden, wenn eine arithmetische Operation verwendet wird; direkte Substitution hingegen funktioniert.

    Beispiel:

    Die Bestellnummer (NR) resultiert aus dem String 'xyz' und einem Merkmalalgorithmus.

    RNG=[10:100]

    NR= xyz 500

    NR=xyz ALG
    ALG=10*RNG

    Problem: ALG kann einem eindeutigen Wert zugeordnet werden, aber aufgrund oben genannter Einschränkung kann der Wert von RNG nicht ermittelt werden.

    Gleiches würde auch für folgende leicht abgewandelte Fälle gelten, da auch hier eine arithmetische Operation durchgeführt wird:

    • NMD=15,20,30

      NR= xyz 200

      NR=xyz ALG
      ALG=10*NMD
    • Wertebereich mit Schrittweite. Das würde einer Liste von festen Werten entsprechen (10,20,30,...,100), funktioniert aber aufgrund obiger Einschränkung trotzdem nicht.

      RNG=[10:100/10]

      NR= xyz 500

      NR=xyz ALG
      ALG=10*RNG

    Lösung:

    Eine Lösung könnte evtl. darin bestehen, die Wertebereichswerte so zu bestimmen, dass eine Berechnung mittels ALG unterbleiben kann und direkt RNG zur Bestimmung von NR verwendet wird.

  • Beispiel 2 - Vorwärts-Auflösung mit Algorithmen

    [Hinweis] Hinweis

    Der Wert eines Algorithmus kann nicht gesetzt werden.

    Beispiel:

    ALG1: Vorwärts zu einem Wertebereich

    ALG1=RNG (ALG1 fußt auf einem Wertebereich)

    ALG2: IF Statement zur Bestimmung des angezeigten Bestellnummerwertes

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

    Problem:

    ALG1 kann einem eindeutigen Wert zugeordnet werden, aber aufgrund oben genannter Einschränkung kann der Wert nicht gesetzt werden.

    Lösung:

    Verwenden Sie im IF-Statement direkt den Wertebereich anstatt der Algorithmus-Variablen.

    If RNG='xyz' then
    ALG2=123
    Else If RNG='abc' then
    ALG2=789
    End if
    NR=DIN ALG2
  • Beispiel 3 - Kein Trenner zwischen Wertebereichsvariablen

    Beispiel:

    NR=RNG1RNG2

    Problem:

    Es gibt keinen Trenner zwischen den zwei Wertebereichen, so dass nicht klar ist, aus welchen Einzelwerten Bestellnummer/Typecode (NR) zusammengesetzt wurde.

    NR='3412' könnte eine z.B. eine Kombination aus '341' und '2' sein oder aus '34' und '12'.

    Lösung: Setzen Sie einen Trenner zwischen die Wertebereichsvariablen, dann ist klar, welches Element zur Wertebereichsvariablen 1 und welches zur Wertebereichsvariablen 2 gehört.

    NR=RNG1-RNG2
  • Beispiel 4 - Keine eindeutigen Pfade mit gleichem Ergebnis

    Beispiel:

    ALG:

    RNG : 0,1,2,3

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

    Problem:

    ALG hat mehrere Optionen, die teilweise gleich sind. In der ersten Bedingung "01" und in der zweiten Bedingung "01".

    Wenn ALG denselben Wert annimmt, kann die Rückauflösung nicht gelingen. Es kann nicht entschieden werden, ob der Fall "a=1" oder "a=2" vorliegt. Damit ist dann sekundär auch eine Aussage über RNG=1 falsch.



[33] Schlüssel VARSEARCHRESOLVEORDERNO. Auf Projektebene steht dieser in der Projektdatei, auf Katalogebene in $CADENAS_DATA/23d-libs/<katalogname>/dir.prj. Keine GUI-Entsprechung. Manuelles Eingreifen ist nicht nötig.