Bei Erzeugnis erfassen kann man identische Erzeugnisnummern speichern

[jbueren]

Im Vgl.:

1)

Bei Waren erfassen (Nummer 27) -> Speichern
Bei Waren erfassen (Nummer 27) -> Speichern -> Fehler Artikelnummer existiert schon

2)

Bei Erzeugnis erfassen (Nummer 27) -> Speichern
Bei Erzeugnis erfassen (Nummer 27) -> Speichern -> Keine Fehlermeldung

Ich hab das jetzt über eine Datenbank-Constraint abgefangen, wenn es von der Anwendung nicht möglich ist, wäre es auch sinnvoll dies in der DB abzubilden:

Für Erzeugnisse (erfolgreich getestet):
DB=# create unique index unique_assembly_number ON parts (partnumber,assembly) WHERE inventory_accno_Id IS NULL;

Ggf. die dann auch noch dazu:
DB=# alter table parts add constraint parts_service_assembly_unique_partnumber UNIQUE (partnumber, assembly, inventory_accno_id);

kivitendo verhindert sowohl bei Waren als auch bei Dienstleistungen doppelte Artikelnummern über alle drei 'Artikelsorten' (Waren, Dienstleistungen, Erzeugnisse) hinweg. D.h. man könnte die Artikelnummer generell als unique definieren.

Was ein wenig merkwürdig erscheint, ist, dass es für Dienstleistungen einen eigenen Nummernkreis gibt. Falls wir uns also dazu entschließen die Artikelnummer für alle drei Artikelsorten eindeutig zu definieren, sollte man den Dienstleistungsnummernkreis aus dem Programm nehmen.

Eine weitere Möglichkeit ist natürlich die Eindeutigkeitsprüfung der Artikelnummer von Waren/Dienstleistungen? anzupassen und einen neuen Nummernkreis für Erzeugnisse zu erstellen - finde ich allerdings blödsinnig.

Replying to Niclas:

Was ein wenig merkwürdig erscheint, ist, dass es für Dienstleistungen einen eigenen Nummernkreis gibt. Falls wir uns also dazu entschließen die Artikelnummer für alle drei Artikelsorten eindeutig zu definieren, sollte man den Dienstleistungsnummernkreis aus dem Programm nehmen.

Definitiv nicht. Wir haben Kunden, die explizit die Nummernkreise für ihre Waren und DLs unterschiedlich haben wollen, auch um sie auf einen Blick leichter zuordnen zu können.

Eine weitere Möglichkeit ist natürlich die Eindeutigkeitsprüfung der Artikelnummer von Waren/Dienstleistungen anzupassen und einen neuen Nummernkreis für Erzeugnisse zu erstellen - finde ich allerdings blödsinnig.

Warum blödsinnig? Ist im Gegenteil flexibel. Man sollte vielleicht zwecks Rückwärtskompatibilität einen Mechanismus einbauen, der beides unterstützt. Z.B. wenn beim Erzeugnisnummernkreis nicht (also auch keine "0") eingetragen ist, so wird für Erzeugnisse derselbe Nummernkreis wie für Waren verwendet, ansonsten der eigene. Ersteres wäre Standard und damit der Status Quo.

Bei bestehenden Kunden in die automatische Nummerierung ihres Warenstammes einzugreifen ist meiner Meinung nach ein ziemlichs "no go". Kunden entscheiden sich oft sehr bewusst für bestimmte Schemata, und wir dürfen die nicht einfach und ohne guten Grund durcheinanderwirbeln.

Replying to m.bunkus@…:

Replying to Niclas:

Definitiv nicht. Wir haben Kunden, die explizit die Nummernkreise für ihre Waren und DLs unterschiedlich haben wollen, auch um sie auf einen Blick leichter zuordnen zu können.

Ok, was ich und ggf. Niclas nicht im Kopf hatten ist, dass man ja auch Nummernkreise mit Buchstaben machen kann, sprich:

DIENST001
WARE002

Ferner ist das Konzept der Nummernkreise ja auch explizit von bis begrenzt (zumindestens im Kopf des Anwenders nicht in Perl), von diesem Gesichtspunkt gibt es dann keine Schnittmenge.
Ansonsten rein mathematisch und nur mit Nummern die bis unendlich gehen hat Niclas natürlich recht.

Warum blödsinnig? Ist im Gegenteil flexibel. Man sollte vielleicht zwecks Rückwärtskompatibilität einen Mechanismus einbauen, der beides unterstützt. Z.B. wenn beim Erzeugnisnummernkreis nicht (also auch keine "0") eingetragen ist, so wird für Erzeugnisse derselbe Nummernkreis wie für Waren verwendet, ansonsten der eigene. Ersteres wäre Standard und damit der Status Quo.

Gut.

Bei bestehenden Kunden in die automatische Nummerierung ihres Warenstammes einzugreifen ist meiner Meinung nach ein ziemlichs "no go". Kunden entscheiden sich oft sehr bewusst für bestimmte Schemata, und wir dürfen die nicht einfach und ohne guten Grund durcheinanderwirbeln.

Auch einverstanden.
Somit wäre dann Konsens, dass Waren, Erzeugnisse und Dienstleistungen jeweils eigene Nummernkreise haben, aber innerhalb des Nummernkreises sollten redundante Nummern verboten sein?

Insgesamt sollten doppelte Nummern in Tabelle parts verboten sein. DL und Ware beide mit Nummer 47110815 ergibt echt keinen Sinn, gerade auch, weil man in Belegen die Beschreibungen ja beliebig verändern kann.

Also Konsens, ja. Ich wollt's nur nochmal klar und deutlich formulieren :)

In 90fb6995eedba7a1f204498e1d7897b6593b95aa/erp:

Erzeugnis-Nummer eindeutig
Fixt #2238

Gut.
Aber das "Fitzel-Detail" ist ja entscheidend.

Entweder:

alter table parts add constraint parts_service_assembly_unique_partnumber UNIQUE (partnumber, assembly, inventory_accno_id);

oder

alter table parts unique_partnumber UNIQUE (partnumber);

Ich glaube die ursprüngliche Intention in sub is_unique (SL/TransNumber.pm) war ersteres, allerdings reicht der Fallunterschied nach parts oder service nicht ganz aus und somit konnte sich durch die NULL-Bedingung der ursprüngliche Bug:

2)

Bei Erzeugnis erfassen (Nummer 27) -> Speichern
Bei Erzeugnis erfassen (Nummer 27) -> Speichern -> Keine Fehlermeldung

einschleichen.

Das ist erstmal behoben.

Von mir aus kann man jetzt das noch etwas strenger auf alle Nummern erweitern, ferner wäre eine zusätzliche DB-Constraint perfekt.

Ich hab gesehen, dass ihr SL/TransNumber.pm angepasst habt. Bedenkt bitte auch, dass es ein entsprechendes Modul für die RDBO-Variante gibt, das ebenfalls angepasst werden muss: SL/DB/Helper/TransNumberGenerator.pm

Bei der Implementation von SL/TransNumber.pm habe ich eigentlich nur den damaligen status quo abgebildet und nicht über die sinnvollste Variante nachgedacht. Also bitte aus dem Verhalten von SL/TransNumber.pm nicht all zu viel herauslesen :)

Du meinst in %specs, die:
number_range_column => 'servicenumber',

Jetzt fehlt mir hier gerade das "Tiefenwissen" ich würde erstmal das RDBO testen, bzw. verstehen.

Nichtsdestotrotz muss dann aber erst recht vorab entschieden werden, ob partnumber über alle eindeutig sein soll oder nicht.

Das kannst Du ja noch kurz überlegen, ich mach dann am Donnerstag weiter.

Ok, dann werde ich die partnumber eindeutig machen und einen neuen Nummernkreis für Erzeugnisse einfügen, ok?

Jo, ok.

Ich habe gerade die Bekanntschaft mit eurem DB-Upgrade gemacht, wenn man doppelte Artikelnummern in der DB hat. Das geht so leider nicht, bzw. ich habe hier deutliche Änderungswünsche:

1. Spalte "Dienstleistung, Erzeugnis oder Ware": "service" ist nicht übersetzt.
2. "Bitte ändern Sie..." -- ja und wie denn bitteschön? Ein normaler Benutzer, der nicht in SQL und dem direkten Zugriff auf Datenbanken geschult ist, hat an dieser Stelle unwiederbringlich verloren, weil er gar nicht ins Programm reinkommt, um die notwändigen Änderungen vorzunehmen. Sprich das Upgradescript selber muss a) die Möglichkeit bieten, die Nummern hier und jetzt zu ändern, und b) damit klarkommen, dass der User mehrfach Nummern eingibt, die es bereits gibt. Sprich jede Neueingabe muss erneut sinnvoll geprüft werden.
3. Etwas mehr Erläuterung als nur "Nummern müssen ab sofort eindeutig sein" wäre als Einleitung wirklich schön: Wie war es früher? Warum ändert sich das? Wie ist es neu? Was muss die Benutzerin jetzt tun?

Ach und:

4. Umlaute in den Artikelbeschreibungen werden falsch dargestellt.

In 90fb6995eedba7a1f204498e1d7897b6593b95aa/erp:

Erzeugnis-Nummer eindeutig
Fixt #2238

Ich öffne den Bug noch einmal. Warum? Weil ich hier weiterhin ein riesiges Usability-Problem sehe. Ich aktualisiere gerade LINETs interne kivitendo-Version auf diesen Stand und habe eine
pralle Liste von 30 Artikeln, deren Nummern eindeutifiziert werden müssen.

Wie soll aber der User in dem Moment entscheiden, welche Nummern er neu zuweist? Ja, er könnte in dem Moment den Weg über das normale Menü gehen und einen neuen Tab öffnen. Dann vergisst er aber vielleicht den noch offenen Tab und arbeitet einfach weiter -- obwohl noch lange nicht alle DB-Upgrades installiert sind. Das würde bedeuten, dass er mit aktuellem Code auf nicht aktueller DB arbeitet und das erst beim folgenden Login merkt.

Zu so etwas will ich den User aber nicht verleitet sehen.

Was kann man dagegen tun? Ich schlage vor, einen dicken Button mit dickem Hinweis anzuzeigen, der die Liste aller Artikel (Waren + Dienstleistungen + Erzeugnisse) in einem Popup anzeigt -- sinnvollerweise mit Artikelnummer, Beschreibung und Typ (mehr muss ja nicht). Das muss zwangsläufig filterbar sein. Und sollte auch nicht das vollständige Menü enthalten.

Ich möchte euch also wirklich bitten, hier noch Arbeit reinzustecken, weil das zu frustrierten Usern und Supportanfragen führen wird und man beides vermeiden kann.

Hinzu kommt, dass das Script ja alle Artikel betrachtet: egal ob Ware oder Erzeugnis oder Dienstleistung. Egal ob gültig oder ungültig. Das habe ich auch erst nach zwei Minuten gerafft -- als ich auf der Suche nach den angeblich vorhandenen Doppelten in der normalen Warensuche nichts gefunden habe.

Hmm.
Ich hab ein ähnliches Problem bei einer anderen Datenmigration.

Kann man vielleicht mit einem neuem Tag arbeiten?

Sprich sowas wie:

@tag (prefilter|migration)

Führe alle Upgrades mit prefilter oder migration vorab einmal OHNE commit aus, damit der Admin erstmal:

"Ach, du Scheiße, gut dass das erstmal als test gelaufen ist, da muss ich dann wohl doch besser mal mit den Usern abstimmen, was hier passieren soll, ich druck mal direkt die Liste aus und probier das nächste Woche nochmal, ggf. haben die dann was nachgepflegt".

Also, sozusagen, alle kritischen Migrationsskripte mit entsprechenden Detaildaten zum Ausdrucken oder weiterleiten an die Bearbeiter.

Das prinzipiell Daten sich verändern und auch diese einfach "nervig" sind nachzubessern darf und sollte auch vorkommen.

Uff, das ist, denke ich mal, nicht wirklich machbar. Das Problem ist doch, dass sobald die SQL-Upgrades im Dateisystem vorliegen auch der neue Programmcode schon vorliegt, der sich darauf verlässt, dass die Updates eingespielt sind. Wenn du jetzt die Updates nur einmal Testhalber durchlaufen lässt, dann weiß der Admin zwar, was im blüht, aber er kann dann trotzdem nichts weiter im Programm machen, weil dann neuer Programmcode auf alte Datenbankstruktur trifft, was ganz schnell in ISE (Internal Server Error) und anderen Fehlern münden kann.

Beispiel: ein Datenbankupgradescript fügt bei Kunden eine Spalte hinzu. Der Rose-Code ist in dem Moment natürlich auch aktualisiert. Das bedeutet aber, dass jeglicher Code, der Rose-Objekte zum Zugriff auf Tabelle customer nutzt, mit einem Fehler abbricht, weil die Spalte eben noch nicht existiert, wenn das Upgradescript nicht gelaufen ist und committet wurde.

Nur jedes einzelne Upgrade-Script "weiß" (aufgrund seiner Abhängigkeiten), in welchem Zustand sich die Datenbank zum Zeitpunkt seiner Ausführung befindet, welche Queries es gefahrlos laufen lassen kann. Daher mein Vorschlag oben mit einem Popupfenster direkt in dem Moment.

Ich bin mir allerdings noch nicht ganz sicher, wohin man den dafür notwendigen Code stecken würde, damit er auch normal aufgerufen werden kann... Vielleicht müsste man den Dispatcher-Mechanismus dafür ein wenig aufbohren.

Good point.

Zurück kommt man in der Tat ja nur ganz oder gar nicht ...

Man könnte ein "Prüfe die Datenkonsistenz für einen Upgrade"-Skript maçhen, aber das muss dann auch von Admins vorab ausgeführt werden.

Ich würde mich an der Stelle auf den Standpunkt stellen, dass ein Upgrade sowieso erstmal testweise gemacht wird.
Der Admin sieht, ok hier muss in der alten Version noch nachgebessert werden, bevor ich hier weiterkomme und fertig.

Das Problem ist nicht mit wenig Aufwand nicht zu lösen, ansonsten programmiert man ja die Stammdatenverwaltung in das "Upgrade-Skript" rein ...

Ah doch, wir können das so machen.

In der Upgrade-Anleitung für 3.0 folgendes ergänzen:

1) Bitte führen Sie VOR dem Update die Datei: datenkonsistenz27auf30.pl in der alten Programm, bzw. Datenversion aus.

Falls keine Kollision entsteht oder Ihnen das egal ist weiter mit Schritt:

2) Upgrade auf 3.0 (Standard)

So.
Auch hier ist Lösung einfacher als gedacht.

Ich würde ein 3.0.1 Releasen die nur ein informatives DB-Upgrade-Skript enthält.

Sozusagen:

Prüfe auf Kollisionen ......

Folgende Inkonsistenzen werden bei dem Release auf 4.0 festgestellt werden:

Doppelte Artikelnummern bei x, y, z

ggf. diverses andere.

Das find ich jetzt sinnvoller, als noch Verrenkungen zu machen, wenn Programm-Code und alles andere schon eingespielt ist.
Da kann sich dann wirklich keiner beschweren.

Gefällt mir nicht; aus zwei Gründen:

1. Wenn jemand jetzt besagtes Update einspielt und danach noch 1/2 Jahr lang weiterarbeitet -- und dann erneut doppelte Nummern erzeugt. Was dann?
2. Was, wenn jemand Update 3.0.1 nicht einspielt und lieber auf das nächste Release wartet? Dann ist er in derselben Situation wie jetzt. Und das "ich warte lieber noch" ist ein ausgesprochen gängiges Szenario (wir haben genug Supportanfragen von Leuten, die noch 2.7.x einsetzen).

In 48452323cbb2feea5ec937b5328a4778e0da55ca/erp:

Popup-Button bei Upgrade

Beim Upgrade für eindeutige Artikelnummern, war es bisher nicht
möglich die bestehende Artikelliste zu durchsuchen. Jetzt kann man
durch Klick auf einen Button ein Popup-Fenster öffnen, um die
Artikelliste zu durchsuchen.

Fixed #2238.

Conflicts:

locale/de/all

Du hast vergessen, ein Template mit einzuchecken. locales.pl meckert an:

W: missing HTML template: dbupgrade/show_partlist.{html,json,js} (referenced from sql/Pg-upgrade2/erzeugnisnummern.pl)