Ah, ich hab schon befürchtet, Du nimmst Dir einen Strick, wenn Du alles durchgelesen hast.
Wenn ich das richtig verstanden habe, ist das eine interne Entwicklung für den Eigenbedarf (Firma). Damit aus der Anwendung kein Zettelkasten wird und man sich nicht komplett verzettelt am Ende, sollte doch am Anfang so etwas wie Zeit- und Geld- und Personalbudget geklärt werden.
Dann eine Anforderungsliste mit Prioritäten und ein Abgleich von allem. Es wird wie immer viele Themen auf der Wunschliste geben und nur ein paar wenige, die in einem ersten Projekt von vielleicht 3 Monaten einfließen können. Zu den Themen gibt es ja massig Material im Internet, sowie Religionskriege über die jeweiligen Entwicklungsphilosophien usw..
Du solltest irgendwann zu einem detaillierten und wasserdichten Datenmodell kommen.
Dabei sollte unter anderem rauskommen, was z.B. kombinierte Feldinhalte (Artikelnummer mit Präfix usw.) bringen.
Ich weiß, dass es (früher) Usus war, in eine solche Nummer alles mögliche rein zu codieren. Jede Firma hat da eine eigene Philosophie/ Historie. Ein alter Hase aus der Produktion kann dann anhand der Nummer auf dem Lenkgestänge sagen, dass der Kalle die gebaut hat, auf Linie 3, an dem Montag nachdem er und seine Frau 40. Hochzeitstag gefeiert hatten. (Da war der Kalle noch nich wieder ganz nüchtern)
Das macht heute NULL Sinn. Man arbeitet mit technischen ID und mglw. zusätzlich mit menschen-lesbaren. Das hat fallweise durchaus seine Berechtigung, aber es spricht überhaupt nichts dagegen, solche Nummern dann virtuell aus verschiedenen Bestandteilen echter Daten (respektive echten Datenfelder) zusammenzusetzen. Dies kann sogar versionsübergreifend in verschiedenen Spalten dargestellt und suchbar angelegt sein. Solange es nur Formatanweisungen für virtuelle Spalten sind, kann man diese beliebig ändern und ist immer bereit für die skurrilsten Kundenwünsche, und natürlich für die standardisierte Verarbeitung der Daten, denn die entsprechen in Ihrer Struktur Deinem Entwurf und Deinen Regeln und greifen nicht auf seltsame, zusammengesetzte Codes zu, sondern auf die wirklichen Datenfelder.
Ganz grob solltest Du als Faustregel unterscheiden zwischen Feldern, die für automatisierte Abläufe, Standardreports, Rechnungsabteilung , .. nötig sind und daher stark kontrolliert und geregelt sein müssen und "Komfortfeldern", die einfach den Nutzen der Anwendung verstärken, ohne dass die Funktion davon >abhängig< ist.
Wenn Du einen guten Grundstein gelegt hast, kannst Du das nach und nach erweitern.
Ich vermute niemand hier wird Dir ein brauchbares Modell liefern können. Wenn Du zu einem bestimmten Entwurf kommst, oder zwischen 2 Szenarien entscheiden musst oder bei der Umsetzung einer bestimmten, präferierten Lösung Probleme hast, dann solltest Du das hier wieder vortragen.
Aber die Arbeit, ein solides, im Plan realisierbares Modell aufzustellen, kann Dir hier keine abnehmen. Und wie schon angerissen, es gibt nicht den einen, großen Wurf, selbst wenn Du Dir hier das beste aussuchst, Du wirst recht schnell die Mängel und Umsetzungsschwierigkeiten feststellen.
Und ganz nebenbei gibt es ja außer Deiner Frage nach dem Modell auch noch die Frage des Framework, mit dem Du das Frontend aufsetzt. Nicht zu unterschätzen, auch wenn das Forum eine gewisse Vorliebe erkennen lässt.