Länge der Seriennr. erweitern

Hallo zusammen,

unsere Produkte haben eine 29 stellige Registriernummer. Diese wird in NAV bisher nur in einem Info-Feld verwendet.
Das soll sich jedoch ändern.
Nun stehe ich vor dem Problem, dass die Seriennr. nur 20 Zeichen fast.
Aus der Registriernummer kann ich auch nur 4 Zeichen entfernen.
Von daher wäre ich gezwungen die Seriennr. zu erweitern.
Hat einer von euch damit Erfahrungen gesammelt?

Wie kann ich am besten in einer Workbench vorgehen? Von der 336 oder der 337?

Oder hat noch jemand eine andere Idee, denn diese Erweiterung würde ich guten Gewissens ungerne durchführen.


Gruß

Christian

Hallo Christian,

unschönes Problem... wurde bei uns auch schon gefragt, die Antwort war bisher konsequent "geht gar nicht". Tabelle 337 klingt wie ein sinnvoller Startpunkt. Wären auch Alternativen denkbar? So wie z.B. Du hast im Seriennr. Feld eine eineindeutige (z.B. gezippte ;) Version der Seriennr. liegen, und kannst damit dann die echte Seriennenr. referenzieren? Das hätte den Vorteil das Du im Zweifelsfall nur die Anzeigen umstricken musst, die ganze Logik dahinter bleibt unberührt und funktioniert weiter wie immer. Von Updates will ich nicht reden... C/AL mässig scheint sich ja nicht mehr viel zu tun.

LG Jens

Hi Jens,

danke für die Antwort.
Hatte auch schon daran gedacht, eine neue Seriennr. zu generieren. Ich befürchte nur, dass die Nummern hinterher nicht mehr eindeutig sind.
Aber das könnte ich umgehen, indem ich einen kompletten rnd-String generiere.
Ich muss nur dafür sorgen, dass der String komplett eindeutig ist. Losgelöst von Artikelnr. und Variante, da das auch die eigentliche Nummer ist.
Problematisch wäre dann nur noch für den Anwender die eigentliche Nummer einzutragen.
Aber das ließe sich ja mit einem neuen Feld in der 336 und 337 realisieren.
Und eine Anpassung in der Form Artikelverfolgung.

Ich glaube ich werde mir hierfür mal ein separates Testsystem aufsetzen und etwas mit der gezippten Nummer herumspielen.

[Edit]
Oder wäre es denkbar die Nummer zu splitten? Die ersten 9 Zeichen als Chargennr verwenden und die letzten 20 als Seriennr.
Würde nur die Chargennummern aufblähen. Und könnte evtl. gegen die Eindeutigkeit der Seriennr. Info verstoßen, da es vorkommen kann, dass die letzten 20 Zeichen bei 2 Nummern identisch ist, aber die ersten 9 sich unterscheiden.
Hat damit evtl. jemand Erfahrungen gemacht?
[/Edit]

Gruß

Christian

Hi Jens,

danke für die Antwort.
Hatte auch schon daran gedacht, eine neue Seriennr. zu generieren. Ich befürchte nur, dass die Nummern hinterher nicht mehr eindeutig sind.
Aber das könnte ich umgehen, indem ich einen kompletten rnd-String generiere.
Ich muss nur dafür sorgen, dass der String komplett eindeutig ist. Losgelöst von Artikelnr. und Variante, da das auch die eigentliche Nummer ist.
Problematisch wäre dann nur noch für den Anwender die eigentliche Nummer einzutragen.
Aber das ließe sich ja mit einem neuen Feld in der 336 und 337 realisieren.
Und eine Anpassung in der Form Artikelverfolgung.

Ich glaube ich werde mir hierfür mal ein separates Testsystem aufsetzen und etwas mit der gezippten Nummer herumspielen.

[Edit]
Oder wäre es denkbar die Nummer zu splitten? Die ersten 9 Zeichen als Chargennr verwenden und die letzten 20 als Seriennr.
Würde nur die Chargennummern aufblähen. Und könnte evtl. gegen die Eindeutigkeit der Seriennr. Info verstoßen, da es vorkommen kann, dass die letzten 20 Zeichen bei 2 Nummern identisch ist, aber die ersten 9 sich unterscheiden.
Hat damit evtl. jemand Erfahrungen gemacht?
[/Edit]

Gruß

Christian

Du könntest Dir auch die SN Info Karte für alle jetzigen Seriennummern im System erstellen und bei der "Seriennummer erstellen" Funktion eine Prüfung machen, ob diese SN Info schon vorhanden ist. Wenn ja, dann erzeuge eine weitere Seriennummer.
Das geht einfacher, als bei jedem SN erzeugen immer die Artikelposten zu filtern, da du die SN Info Karte per GET holen könntest.

Hallo,

mit der "gezippten" Nummer meine ich latürnich eigentlich einen Algorithmus, der dir einen möglichst eindeutigen Hash generiert... md5 zum Beispiel, gibts ja auch als Automation. Alternativ GUID. Wobei ich wahrscheinlich MD5 vorziehen würde, weil die gleiche Seriennummer dann auch die gleiche MD5-Checksumme hat.

LG Jens

Es ist gar nicht so schwer die Seriennummer zu verlängern. Natürlich eine entsprechende Lizenz und ein wenig Zeit vorausgesetzt. "Geht nicht" gibt es hier nicht. Vielleicht unangenehm, da es viele Stellen gibt, in denen Seriennummern als Funktionsparameter genutzt werden. Ich würde mit einigen Stunden arbeit rechnen.

Aber sein wir doch mal ehrlich: Wie sinnvoll ist es, kryptische Hashes zu verwenden um dann die tatsächliche Nummer nachzuschlagen? Oder auch zwei oftmals unabhängige Felder zu verwenden?

Richtig oder gar nicht!

Moin,

normalerweise bin ich auch eher ein Freund von "mach länger" :) In diesem Fall fürchte ich das ich die Seriennr.-Logik nicht wirklich unter Kontrolle habe. Wer hat das schon... ich glaube nicht mal die Entwickler. Die Chancen eine Variable oder einen Parameter, durch den die verlängerte Nr. laufen muss, zu vergessen, ist sehr groß. Und "raustesten" kann dann durchaus Jahre (im Echtbetrieb) dauern. Mit den äusserst geduldigen Kollegen vom Lager

LG Jens

Mit Hilfe entsprechender Tools (wie z. B. "NAV Developer's Toolkit", "Object Manager Advanced", ...) kann man sehr gut nachvollziehen, wo überall die Seriennr. verwendet wird.

Ich würde wie folgt vorgehen:

• Über die Tabelle "Field" alle Tabellen ausfindig machen, in denen das Feld "Lot No." (bzw. ein Feld mit diesem Bestandteil im Namen) vorkommt.
  Diese Liste schreibe ich mir für spätere Analysen weg (Zettel, Word-Doc, o. ä.)
• Die Felder aus 1. werden nun auf die gewünschte Länge vergrößert.
• Mit Hilfe eines der oben genannten Tools (ich favorisiere den Object Manager Advanced) prüfe ich nun - ausgehend von jedem einzelnen Feld aus Recherche zu 1. - wo dieses Feld verwendet wird.
  So finde ich nicht nur die Stellen, wo das Feld gefüllt, sondern auch, wo es an eine Funktion übergeben wird.
• Die Treffer aus 3. (Variablen, Parameter) werden nun auf die gewünschte Länge vergrößert.

Wie man sieht, sind es nur vier Schritte, jedoch wiederholen sich die Schritte 3. + 4. entsprechend der Anzahl vorhandener Treffer aus 1.
Es ist also nicht kompliziert, sondern nur eine zeitaufwändige Fleißarbeit.

Mit Hilfe entsprechender Tools (wie z. B. "NAV Developer's Toolkit", "Object Manager Advanced", ...) kann man sehr gut nachvollziehen, wo überall die Seriennr. verwendet wird.

Ich würde wie folgt vorgehen:

• Über die Tabelle "Field" alle Tabellen ausfindig machen, in denen das Feld "Lot No." (bzw. ein Feld mit diesem Bestandteil im Namen) vorkommt.
  Diese Liste schreibe ich mir für spätere Analysen weg (Zettel, Word-Doc, o. ä.)
• Die Felder aus 1. werden nun auf die gewünschte Länge vergrößert.
• Mit Hilfe eines der oben genannten Tools (ich favorisiere den Object Manager Advanced) prüfe ich nun - ausgehend von jedem einzelnen Feld aus Recherche zu 1. - wo dieses Feld verwendet wird.
  So finde ich nicht nur die Stellen, wo das Feld gefüllt, sondern auch, wo es an eine Funktion übergeben wird.
• Die Treffer aus 3. (Variablen, Parameter) werden nun auf die gewünschte Länge vergrößert.

Wie man sieht, sind es nur vier Schritte, jedoch wiederholen sich die Schritte 3. + 4. entsprechend der Anzahl vorhandener Treffer aus 1.
Es ist also nicht kompliziert, sondern nur eine zeitaufwändige Fleißarbeit.

Hmm, was hälst Du von der Idee "Search String in C/AL Code" des OMA?
Zumindest hat das im Fall Serial No. 1623 Treffer ergeben (ohne History Scan)
Nur mal als grobe Größe an Dingen, die man anpacken/prüfen muss.

Hmm, was hälst Du von der Idee "Search String in C/AL Code" des OMA?
Zumindest hat das im Fall Serial No. 1623 Treffer ergeben (ohne History Scan)
Nur mal als grobe Größe an Dingen, die man anpacken/prüfen muss.

Gute Idee, jedoch muss anschließend noch geprüft werden, wo z. B. eventuell verwendete Variablen/Parameter weitergegeben werden.

Wenn ich den Inhalt des Feldes "Serial No." an die Variable "SerialNo" weitergebe, dann findet die Funktion "Search String in C/AL Code" diese Stelle.
Um jedoch sicherzustellen, ob (z. B.) die Variable "SerialNo" an einen eventuell vorhandenen Funktionsparameter "SerialLotNo" weitergegeben wird muss ich mich letztendlich doch durch die "Übergabe-Kette" durchhangeln.

Einfach nur nach "*Serial No*" suchen reicht hier also nicht aus, ebenso wie eine weitere Suche nach "*SerialNo*" nicht reicht, da es noch Variablen geben könnte, die "SerialLotNo", "SNNo", "SNLotNo", o. ä. heissen.
Und von den unmöglichsten Variablen-Bezeichnungen in Individualprogrammierungen mal ganz abgesehen.