5.12. Klassifizieren
5.12.7. Klassifizierung nach CNSORDERNO / CNSTYPECODE
Zurück  Weiter

5.12.7. Klassifizierung nach CNSORDERNO / CNSTYPECODE

5.12.7.1. Verwendung von CNSORDERNO und CNSTYPECODE mit Beispielen
5.12.7.2. Benefits der Klassifizierung nach CNSORDERNO und CNSTYPECODE
5.12.7.3. Plugin "Auflösungscheck"
5.12.7.4. Plugin "Projekte im Batchlauf klassifizieren"
5.12.7.5. TestMeta: Allgemein für Bestellnummer bzw. Typenschlüssel
5.12.7.6. TestMeta: ReverseConfigs / Reverse Search (automatic)
5.12.7.7. Bestellnummern abhängig von Wertebereichen indizieren
5.12.7.8. Auflösen von Wertebereichen (gelben Feldern) begrenzen per Konfigschlüssel

PARTproject -> Einstellungen [Settings] -> Registerseite Allgemein [General] -> Variablen [Variables] -> Variable mit Bestellnummer [Variable with order number] und/oder Variable mit Typenschlüssel

[Hinweis]Hinweis

  • Die Klassifizierung von Projekten nach CNSORDERNO und/oder CNSTYPECODE ist verpflichtend. [45]

    Sollten sowohl CNSORDERNO als auch CNSTYPECODE klassifiziert werden, dürfen diese nicht die gleiche Variable verwenden!

    Fehlt ein entsprechender Eintrag, erscheint in beim Ausführen von Projekt testen bzw. Verzeichnis testen eine entsprechende Fehlermeldung. Siehe Abschnitt 5.8.2.1.12, „ Projekt testen / Verzeichnis testen “.

    Die Werte von Bestellnummer [Order number] und Typenschlüssel [Type code] sollten idealerweise keine Leerzeichen enthalten.

  • Unterscheidung von CNSORDERNO und CNSTYPECODE

    • Variable mit Bestellnummer [Variable with order number] (ORDERNUMBER):

      Merkmale:

      • Die Bestellnummer kann nicht in Segmente zerlegt werden. Es gibt keine direkte Verknüpfung von einzelnen Ausprägungswerten zu Teilen der Bestellnummer (egal ob Nummer oder Zahl).

      • Ob das Projekt Wertebereichsfelder enthält oder nicht, ist für die Entscheidung ob CNSORDERNO oder CNSTYPECODE nicht aussagekräftig. In beiden Fällen gibt es Projekte mit und ohne Wertebereichsfelder.

    • Variable mit Typenschlüssel (TYPECODE): Die einzelnen Teile des Codes stehen in Verbindung zu den Werten bestimmter Variablen (z.B. Typ/Serie, geometrische Werte wie Länge oder Durchmesser oder andere Variablenwerte, die den Typencode definieren).

      Beispiel: Klare Beziehung zwischen Teilen des Typencodes und einzelnen Variablenwerten

      Beispiel: Klare Beziehung zwischen Teilen des Typencodes und einzelnen Variablenwerten

  • Bei bereits bestehenden Katalogen kann das entsprechende Mapping vom Kataloghersteller/Modelleur semiautomatisch mit geringem Aufwand erledigt werden. Je nach Hersteller kann es möglich sein, dass unterschiedliche Identifikatoren zur Verfügung stehen. Diese Varianten müssen berücksichtigt werden. Informationen zum Plugin Projekte im Batchlauf klassifizieren [Batch classification of projects] finden Sie unter Abschnitt 5.12.6, „ Projekte im Batchlauf klassifizieren “.

  • Wenn Wertebereichsvariablen zur Bildung von Bestellnummer [Order number] oder Typenschlüssel [Type code] verwendet werden, achten Sie unbedingt darauf keine mit Typ-Identifikation [Identification type] "Funktionsmerkmal [Function attribute]" oder "Dimensionsmerkmal [Dimension attribute]" zu verwenden. Für Details siehe Abschnitt 7.8.14, „ Typ-Identifikation “.

Im PARTdataManager kann man wechseln zwischen normaler Volltextsuche [Full-text search] und Suche nach Bestellnummer oder Typbezeichnung [Order number or type code] .

Die Suchmethode Bestellnummer oder Typbezeichnung [Order number or type code] sollte verwendet werden, wenn explizit danach gesucht wird. Aufgrund der Eindeutigkeit führt diese Suche immer zum gewünschten Ergebnis (sofern der Katalog entsprechend vorbereitet ist).

Die Methode führt nicht nur bei einer fixen Bestellnummer [Order number]/Typbezeichnung zum gewünschten Ergebnis, sondern auch dann, wenn diese zusammengesetzt ist anhand von Werten aus Wertebereichsvariablen und zwar sowohl bei einfachen wie auch komplexen Zusammensetzungen.

[Hinweis]Hinweis

Kataloge können einfache Projekte ohne Wertebereiche enthalten oder welche mit Wertebereichen und diese wiederum können einfacher oder komplexer aufgebaut sein.

Um zu ermitteln welche Fälle in einem Katalog vorliegen, sollte der Auflösungscheck [Resolve check] durchgeführt werden. Siehe Abschnitt 5.8.2.1.16.26, „ Reverse Search – Auflösungscheck (automatisch) “.

Es gibt 3 grundsätzliche Fälle:

  1. Einfaches Projekt ohne Wertebereiche

    Beispielprojekt ohne Wertebereiche in PARTproject

    Beispielprojekt ohne Wertebereiche in PARTproject

    Beispielprojekt ohne Wertebereiche in PARTdataManager

    Beispielprojekt ohne Wertebereiche in PARTdataManager

  2. Projekt mit Wertebereichen, die per Aufnahme in den Volltextsuchindex aufgelöst werden können

    Die Aufnahme in den Volltextsuchindex ist möglich bei weniger als 25.000 Kombinationsmöglichkeiten pro Projekt oder 50.000 pro Katalog (Default-Limit) zusätzlich zu den Standardzeilen. Die Einstellung des Limits erfolgt per Konfigurationsdatei %cadenas_setup%/partsol.cfg. Siehe hierzu unter Abschnitt 5.12.7.8, „Auflösen von Wertebereichen (gelben Feldern) begrenzen per Konfigschlüssel “.

    [Hinweis]Hinweis

    Das Limit sollte nicht geändert werden.

    Beispielprojekt mit indizierten Wertebereichen in PARTdataManager

    Beispielprojekt mit indizierten Wertebereichen in PARTdataManager

  3. Projekt mit Wertebereichen, die per Reverse Search aufgelöst werden müssen

    Dies sind Projekte mit sehr komplexen Wertebereichen, bei deren Auflösung Millionen und Milliarden von Kombinationsmöglichkeiten entstehen würden, was den per Konfig gesetzten Grenzwert (max. 25.000 pro Projekt, max. 50.000 pro Katalog) für die Aufnahme in den Volltextsuchindex (Lucene-Index) überschreitet.

    Beispielprojekt mit vielen Wertebereichsvariablen, welche die Teilenummer interaktiv aufbauen

    Beispielprojekt mit vielen Wertebereichsvariablen, welche die Teilenummer interaktiv aufbauen

    Beim Ausführen des Auflösungscheck wird für diese Projekte automatisch eine Mapping-Datei erstellt, mittels derer diese Projekte gefunden werden können.

  4. Sonderfall bei 2) und 3): Nur eine bestimmte Anzahl der tatsächlich möglichen Kombinationen aus den Wertebereichsfeldern hat eine Bestellnummer und ist wirklich verfügbar bzw. bestellbar.

    -> Es wird eine CSV (pnomapping.csv) mit Mappinginformation von Bestellnummer [Order number] und Typenschlüssel [Type code] im Katalog-Wurzelverzeichnis hinterlegt.

    pnomapping.csv, Spaltennamen "PARTNUMBER" und "TYPECODE", Semikolon als Trennzeichen

    pnomapping.csv, Spaltennamen "PARTNUMBER" und "TYPECODE", Semikolon als Trennzeichen

    -> Die Sucheingabe erfolgt mit der Bestellnummer mit Suchmodus Suche nach Bestellnummer / Typcode [Search for order number / type code] , tatsächlich wird die Suche aber im Hintergrund mit dem Typcode ausgeführt.

    [Achtung]Achtung

    • Anwendungsgrund sollte nicht sein, um Bestellnummern in Tabellen zu vermeiden, sondern nur der oben genannte.

    • Die Bestellnummer wird nicht im Suchergebnis erscheinen, da sie nicht in der Tabelle vorhanden ist.

      Wird die Bestellnummer in der Tabelle benötigt, ist sie separat zu implementieren (was aber nichts mit dem beschriebenen Sonderfall an sich zu tun hat).

    • Die Bestellnummer wird nicht ins CAD, BOM, etc. exportiert.

    Beispiel: Suche mit Bestellnummer, in der Tabelle Anzeige des Typenschlüssels

    Beispiel: Suche mit Bestellnummer, in der Tabelle Anzeige des Typenschlüssels



[45] Die Klassenvariablen [Class variables] CNSORDERNO und CNSTYPECODE werden unter Variable mit Bestellnummer [Variable with order number] und Variable mit Typenschlüssel auf die gewünschte Variable gemappt. Siehe auch Abschnitt 5.12.4, „Wichtige Variablen einfach CNS-Klassifikation zuweisen “.

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

[47] Achten Sie immer darauf, einen aktuellen Volltextsuchindex und/oder Geosuchindex für die benötigten Kataloge zu haben, um alle Funktionen ihrer Softwareversion auch tatsächlich zur Verfügung zu haben. (Mit V11 SP10 ist beispielsweise die Funktion Reverse Search – Test der Bestellnummernsuche [Reverse Search – Test reverse search] dazugekommen welche auf den Volltextsuchindex zugreift.)

Zurück Nach oben Weiter
5.12.6. Projekte im Batchlauf klassifizieren  Zum Anfang 5.12.7.1. Verwendung von CNSORDERNO und CNSTYPECODE mit Beispielen