In many projects I have learned: New company = new number ranges / number series / new methodology of number assignment. Here is my approach to how I would assign customer numbers, supplier numbers and document numbers via the number series.
In Navision bzw. Business Central haben Sie über die Nummernserien, Nummernserienzeilen und Nummernserienverbindungen sehr viele Variationsmöglichkeiten, um Nummernserien nach allen Regeln der Kunst zu vergeben. Nummerierung in 2er oder 10er Schritten, Vorangestellte Fixteile wie Jahreszahlen oder Buchstaben, z.B. RG oder GS für Rechnungen und Gutschriften, Mehrere Blöcke z.B. zum Unterteilen von Geschäftsfeldern oder Abteilungen: All das geht mit den Nummernserien von Navision oder Business Central!
Nevertheless, I would not use this flexibility. Here you will find my recommendations.
Vorschlag für Navision Belegnummern (BC365 Belegnummerierung)
100000 : Offers (VK)
200000 : Orders (VK)
300000 : Delivery notes (VK)
400000 : gebuchte Rechnungen & Gutschriften. Beide Belegarten tragen beim Erstellen eine Nummer mit z.B. RG400000, und bekommen ihre endgültige Nummer erst beim Verbuchen. Dies hat den Vorteil das Navision Sie beim Löschen einer ungebuchten Rechnung nicht mit der Rückfrage „Das Löschen des Beleges hat eine Lücke in der Nummernserie zur Folge. Möchten Sie einen leeren Beleg erstellen“ nervt.
500000 : Verkauf Mahnung (ungebuchte:VKM500000, aus dem gleichen Grund wie bei den verbuchten Verkaufsbelegen)
600000 : Inquiries (EK)
700000 : Orders (EK)
800000 : Deliveries (EK, no other meaning)
900000 : Invoices & credit notes (as in the UK, no other meaning)
Die Anzahl der Stellen sollte sich an ihren Belegmengen orientieren, vorzugsweise haben sie auf absehbare Zeit (mindestens die nächsten 10, besser 20 Jahre) keinen Stellensprung! Springen also nicht von 5-stelligen auf 6-Stellige Belegnummern, oder von 6-stelligen Business Central Belegnummern auf 7-stellige Belegnummern usw.
So: If you write 8,600 offers per year, you should expect at least 50% growth, better 100% growth, i.e. 16,000 offers per year. Over 10 years, that's 160,000 offers. In order to avoid a jump from 6 to 7 in the 8th year, you should number in seven digits, i.e. start with 1000000 (1,000,000).
The record type with the most records per year determines the number of digits for all records. In most cases, 6 digits (which is only 5 digits due to the leading code!!!) will suffice. 6 digits also has the advantage that the document numbers are differentiated from the customer and vendor numbers.
Alternative: Alphanumeric numbering
e.g.: AB100000, RG100000:
Empfehle ich nicht, da Sie, Ihre Mitarbeiter und Ihr Kunde/Lieferant so eine Nummer weniger flüssig eingeben kann. Test: Tippen Sie mal eine 125000 ein, vorzugsweise auf dem rechten Ziffernteil ihrer Tastatur. Und tippen Sie danach mal RG100000 ein: Sie müssen 2 Teile und vermutlich 2 Hände benutzten. Das sind nur Sekunden, aber multiplizieren Sie dies einmal mit der Anzahl der Belege, welche Sie jährlich empfangen und verschicken…
Alternative: Year numbering
e.g. 19.10000, 20.100000, 21.100000
I also clearly advise against this. Why?
1-You have to remember to change your number series every year. Navision makes this quite easy for you with year-dependent number series lines: you can pre-maintain the number series in Navision and Business Central years in advance.
2-You have more work if, for example, you want to create another receipt in January for the previous December. A program adjustment could make things easier here, but why fix what you can avoid?
3-Every year, your customers and suppliers gain insight into the capacity utilization of your business operations. If you create an invoice with 20.2000007 on March 5th, then your customer (supplier) knows exactly that you have only written 7 invoices (orders) in this quarter. And this disadvantage is inherent in annual numbering if you start each year cleanly.
Eine andere Lücke gab es beim Sprung von 1999 auf 2000: Plötzlich waren die neuen Belege mit ihren neuen Belegnummern (z.B. 20.100500) vor den alten Belegen (99.100500). Das passiert erst einmal die nächsten 80 Jahre nicht mehr… aber daran gedacht hat in 1993 vermutlich niemand 🙂
Vendor and customer numbers
Here I would roughly stick to the Datev, i.e. 5 digits.
This is a common standard.
Datev hat früher auch noch nach Anfangsbuchstaben geteilt, also z.B. 10000 für A…, 11000 für B…., 12000 für C…, das ist inzwischen nicht mehr üblich. Gerade in Navision & Business Central sorgen Suchbegriffe (Matchcodes), beliebige Sortierungen nach Orten oder PLZ, ausgefeilte Suchroutinen dafür das man einen Kunden (Debitoren) oder Lieferanten (Kreditoren) auch ohne diese Logik wunderbar findet und in beliebigen Berichten auch unabhängig von der Nummer / den Nummernkreisen schön sortierte Listen aus Navision / Business Central herausbekommt. Evtl. kann es hier hilfreich sein, gleich 6-stellig zu beginnen, um interne Gruppen zu bilden… aber oft ist das gar nicht mehr nötig.
Item numbers
Oops... different topic. Not because of Business Central and Navision, but because of catalogs. Webshops, price lists, general information that goes to the customer. Here we should take a closer look at your articles and consider whether a speaking, logically grouped article number is too much of a good thing or just the right thing. Here, it may also be a good idea to number article numbers in Business Central & Navision with letters in the number ranges / number series.