Wir haben einen neuen Belegnummernkreisintervall für RV_Belege, nachdem er im Quali-Mandanten getestet wurde ins Produktivsystem transportiert. Die Transportkollegen waren mit dem Transport etwas zu voreilig und haben während hoher Prozessperformance in den Produktivmandanten transportiert.

Die ersten fünf Kundenaufträge wurden korrekt angelegt. Dann wurden einige 100 freie Belegnummern ausgelassen. Weitere 150 Belege dann wieder korrekt, dann wieder ein Belegnummersprung.

Was kann hier die Ursache sein??? Danke im Voraus für eure Hilfe.

Interne Nummernvergabe eingestellt, keine externe möglich, Intervalle überlappen korrekt mit den anderen Intervallen.

10000000 - 10000005 korrekt

10000000 - 10000431 wurde ausgelassen

10000432 - 10000582 korrekt

10000583 - 10000670 wurde ausgelassen

10000671 - wieder korrekt bis zum nächsten Sprung?

Viele Grüße

hoog

spontan habe ich an den Puffer für die Nummernvergabe gedacht.

Es schadet ja nicht, wenn Ihr das einmal kurz überprüft.

https://www.berater-wiki.de/Transaktion_SNUM 

Danke für deinen Hinweis.

Der Puffer ist es nicht, da wir ihn nicht aktiviert haben. Wenn wir ihn aktivieren, würde er vermutlich die Problematik verstärken, oder was meinst du.

Ich habe noch nicht korrekt eingebuchte EDI Aufträge in Verdacht. Diese füllen zu einem späteren Zeitpunkt freie Belegnummern im "Sprungintervall", aber eben nicht alle freien Belegnummern die durch noch nicht erklärbare Sprünge übergangen wurden.

Viele Grüße

hoog

Es sei denn ihr löscht bzw. "reorganisiert" diese, dann sind die Änderungsbelege natürlich weg.

Ohne, dass ich euch oder euer System kenne ist eine Programmierung mit Number_get_next die ohne oder nur mit unzureichender Rollback Funktion realisiert wurde, nicht gerade unwahrscheinlich.

Wenn du schon selbst von "EDI Aufträgen welche zu einem späteren Zeitpunkt freie Belegnummern im "Sprungintervall" nutzen" schreibst, dann hört sich das nach "finde die Nadel im Codinghaufen" für mich an.

Have fun.