WĂĽrde es nicht reichen, wie folgt weiter zu machen: A1000000.
Ich denke das beste, was wir hier tun könne ist wieder von Start beginnen, also bei A100000.
fiddi hat geschrieben:wenn dort schon Angebotsarchive enthalten sind, und ihr Sie nutzt, könnte das zu Problemen mit wiederholenden Nummern führen.
Ist dafür nicht das Feld "Doc. No. Occurence" gedacht, um solche Fälle abzufangen?
Ich sehe auch gerade, dass bei uns der SortierschlĂĽssel auf "Belegart, Angelegt am" liegt und somit nach A999999 die A100001 nicht im Anschluss folgt, sondern fĂĽr den jeweiligen Tag am Anfang gesetzt ist.
Das älteste Angebot aus dem Archiv ist von letztem Jahr (A936570).
Wie wäre es denn mit einer Jahreszahl in der Nummernserie?
17A100000
...mĂĽsste man dann allerdings fĂĽr jedes Jahr eine neue Nummernserie anlegen.
Dann geht wohl nur A1000000.
fiddi hat geschrieben:WĂĽrde es nicht reichen, wie folgt weiter zu machen: A1000000.
Leider nein, weil dann die Sortierfolge A100000,A1000000,A1000001,A1000002,A1000003,A1000004,A1000005,A1000006,A1000007,A1000008,A1000009,A100001,A1000010,A1000011,A1000012,A1000013,A1000014,........ sein wĂĽrde. Deine neuen 1er Nummern wĂĽrden VOR den alten 9er- Nummern landen.
Das sieht besonders bei der Benutzung mit dem SQL- Server (entweder jetzt schon, oder später nach einem Update sehr blöde aus)
GruĂź Fiddi
Soweit ich weiĂź ist das nur bei SQL so (1000 ist dort kleiner als 99), bei Native normalerweise nicht.
fiddi hat geschrieben:Soweit ich weiĂź ist das nur bei SQL so (1000 ist dort kleiner als 99), bei Native normalerweise nicht.
Du redest hier aber von A999999 und A1000000, und das ist von vornherein Alphanumerisch. Wird also wie oben beschrieben sortiert.
GruĂź Fiddi
fiddi hat geschrieben:Das mag sicherlich O.K. sein. Aber schon Bei Aufträgen hast du das Problem, das diese Nummern in Lieferscheinen und evtl. Rechnungen enthalten sind. Dort wird das mit dem von vorne anfangen nicht funktionieren.
GruĂź Fiddi
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast