Verwiesen an Support Wareneingangsarchiv und gelöschte Artikel - Ein Minenfeld...

[gutberle]

Bei der Suche nach Gründen für ein anderes Problem bin ich zufällig darauf gestossen, dass eine Unzahl von Einträgen in meinem Wareneingansarchiv zwar per Datum vermerkt sind, aber keinen Eintrag zu Artikeln oder Lieferanten haben.

Zuerst dachte ich, hier wäre etwas wirklich, wirklich faul, dann habe ich mir die zugehörigen Tabellen aber in der Datenbank angeschaut und da wurde mir klar, was hier los ist...

Es handelt sich hierbei schlicht um alle Wareneingangsbewegungen zu Artikeln, die irgendwann später gelöscht worden sind. Das klingt irgendwie logisch und nein, eigentlich ist das auch kein Bug, aber das Ganze ist trotzdem ein echtes Minenfeld, denn wer denkt schon daran, dass er/sie durch das heutige Löschen eines jahrelang verkauften Artikels auch rückwirkend ALLE Spuren dieses Artikels vernichtet.

Alles was Artikel angeht läuft in der Wawi in der Tabelle tArtikel zusammen und wenn man einen Artikel erst Inaktiv macht und dann über die DB-Verwaltung löscht, wird der Eintrag zu diesem Artikel aus Tabelle tArtikel physikalisch gelöscht. Alle Referenzen auf diesen Artikel in allen historischen Angeboten, Aufträgen, Rechnungen, etc. laufen aber über die interne Artikelnummer und die Tabelle tArtikel. Was das bedeutet kann sich jeder selbst ausmalen.

Wie gesagt, ein Bug ist das per se nicht, es erzeugt aber einen derart "bug-artigen" Zustand, dass ich das Problem hier dringend zur Sprache bringen wollte und bin auf Eure Einschätzungen gespannt...

 

[MichaelH]

Na ja, an sich müsste die WAWI den Artikel prüfen ob es Bewegungen gab und wenn ja, dann darf ein Löschen gar nicht möglich sein ... gilt an sich für alle Stammdaten und Konto-Arten, Artikelkonto, Kundenkonto ... ich würde das schon eher als "Bug" bezeichnen, als ein nettes Feature.

 

[gutberle]

Worauf das aber hinausläuft, ist so eine Art "zustandsbasiertes Arbeiten", bei dem jede Aktion (Angebot, Auftrag...) mit dem zu ihrem Zeitpunkt aktuellen Zustand der Wawi fixiert wird. Das ist natürlich wünschenswert, widerspricht aber dem Grundprinzip relationaler Datenbanken, denn immer dann, wenn ich nicht alle Daten explizit in meinen Beleg aufnehme, sondern per Referenz und dynamisch aus anderen Tabellen hole, erzeugt jede Änderung am referenzierten Eintrag in der anderen Tabelle in der Zukunft auch einen geänderten "historischen" Zustand meines Angebots.

@MichaelH: Ich weiß, dass Du das alles weißt, aber ich schreib's noch mal für die, denen das noch nicht so klar ist: Stellt Euch einfach ein Angebot im Jahr 2010 vor, das an "Hänschen Klein" ging. Inzwischen will der aber "Hans Klein" genannt werden. Ruft Ihr Euer Angebot aus 2010 noch einmal auf, dann ist es an "Hans Klein" adressiert, hoppla. Und wenn sich in 2016 die Spezifikationen des Artikels, den Ihr "Hänschen Klein" in 2010 angeboten habt, ändert und Ihr dann das Angebot aus 2010 aufruft, respektive noch einmal druckt, etc., dann ... richtig, lautet es auf die neuen Spezifikationen des Artikels, nochmal hoppla!

Wir hatten dieses Thema hier im Forum ja schon mehrfach am Wickel und ich hatte für dieses echte Dilemma ja hier als einzige wirklich Lösung schon die interne Speicherung des "zustandsbasierten Outputs" in einem Format wie PDF/A 3 und mit Zugferd Daten für die leichte Wawi-interne Extraktion der Zustandsdaten vorgeschlagen und irgendwo hier im Forum habe ich inzwischen gelesen, dass sich auch JTL gegenüber diesen Ideen öffnet.

Worauf ich aber hinaus will, ist keine DMS- sondern eine Archivfunktion und hier liegt vielleicht eine Lösung auch für die Artikel. Wenn Artikel, die "bespielt" worden sind, nicht mehr gelöscht, sondern nur noch archiviert werden können, also weiterhin existieren, aber anders als inaktive Artikel auch nicht wieder reaktiviert werden können, sondern nur noch die Historie zugänglich machen, dann wäre schon viel gewonnen.

Und ja, Du hast natürlich recht, das gleiche gilt für alle Kontenarten. Wenn also alle Stammdaten zwar geändert werden können, aber nach der ersten Nutzung nur archiviert und nicht mehr gelöscht werden können und wenn gleichzeitig alle Aktivitäten/Belege, die sie verwenden, mit dem speichern/drucken/versenden (schwierig...) in einer für die Wawi als gekapselte Mini-Datenbank zugänglichen (> PDF/A3 und Zugferd) Form archiviert werden, dann sind wir ein gutes Stück weiter.

 

[MichaelH]

Jein, es gibt Stammdaten, Konten und Bewegungsdaten.
Die Bewegungsdaten nehmen die Infos aus den Stammdaten/Konten mit in ihre Tabellen.
Eine rein relationale Datenbank ist und war noch nie sinnvoll, es gibt auch so was wie geplante und notwendige Redundanz - und sei es sogar aus Gründen der Performance.

Daher ist es kein Problem und keine Änderung im Angebot von 2010 zu finden, wenn dies korrekt programmiert ist.
Ist das Angebot noch "änderbar", dann muss ich mit einer Änderung durch geänderte Stammdaten rechnen, ansonsten nicht.

Die alte WAWI ist (genial) trivial programmiert und hat eben entsprechende Folgeproblemchen die man recht einfach verhindern könnte.
Da es nun ja die neue WAWI gibt und irgendwann auch alles neu sein wird, wird sich das Problem von selbst erledigen ... ... aber 100% relational wird sie hoffentlich nicht, es sei denn die Stammdaten werden datumsrelevant gespeichert (Zeitstempel) und wäre auch nur etwas für Leute (ziemlich) frisch von der Uni die nach 3 Jahren gerne graue Haare in ihrer Lockenpracht haben wollen, weil die Komplexität ihre Fähigkeiten überschreitet.

 

[gutberle]

In der Theorie hast Du natürlich recht, aber leider macht die Wawi hier die Theorie nicht mit, denn auch wenn zwar sie keine voll-relationale Datenbank implementiert, ist die Menge an Informationen, die aus den Stamm- und Kontendaten physikalisch mit in die Bewegungsdaten übernommen wird, mehr als überschaubar, eigentlich eher verschwindend gering.

Letztlich sind es nur die Felder, die Du z.B. bei einem Angebot direkt ändern kannst, die auch dort, also in der Tabelle tbestellung gespeichert werden oder wie bei den Liefer- und Rechnungsadressen in eigenen Tabellen (tlieferadresse, trechnungsadresse). Alles andere wird über Relationen dynamisch aus Stamm- und Kontendaten gezogen und zwar immer mit dem dortigen aktuellen Zustand zum Zeitpunkt des Abrufs.

Die Artikelbezeichnung wird zum Beispiel direkt im Angebot selbst abgelegt und überlebt deshalb auch Änderungen am Artikel, falls Du aber eine Kurz- oder Langbezeichnung in Deinen Angeboten ausgibst, dann folgt die der Evolution Deiner Artikel und deshalb stimmt das, was ich oben zum Zustand des Angebots aus 2010 nach einer Artikeländerung in 2015 gesagt habe, eben leider doch.

Manchmal ist das nur ärgerlich, aber wenn sich wesentliche Merkmale eines Artikels über die Jahre ändern, das Herstellerland z.B. von USA nach China wandert oder sich die TARIC in 2017 ändert, dann ist es auch rechtlich echt hakelig, dass eine erneute Druck- oder Speichern-Ausgabe des alten Angebots aus 2010 eine TARIC Nummer ausgibt, die erst 7 Jahre später gültig ist und der Artikel ganz plötzlich völlig andere "zugesicherte Eigenschaften" hat, als zum Zeipunkt des Angebots - bei einem Auftrag auch als zum Zeitpunkt seines Verkaufs! Das ist gar nicht gut...

Und nein, die Option "änderbar" in den Wawi-Einstellungen hat leider keinen Einfluß darauf, weil die Dich nur vor den Änderungen direkt im Angebot/Auftrag und damit nur vor Änderungen an den im Angebot/Auftrag physikalisch abgelegten Daten schützt. Alle Änderungen an den externen Referenzen/Relationen bekommt diese Option überhaupt nicht mit. Und das Ganze hat leider auch nichts mit der Programmierung der Vorlage zu tun, siehe auch die weitere Diskussion zu diesem Thema hier, inklusive der Tatsache, dass alle alten Angebote, Aufträge, etc. - eigentlich alles - natürlich auch die Evolution von List & Label und Deiner L&L Vorlagen mitmacht.

Fazit ist, dass die einzige Lösung, um eine wirkliche Konstanz der Daten zu erzeugen, tatsächlich die Generierung von Archiv-Snapshots wie mit der von mir vorgeschlagenen internen Archivierung in Form von PDF/A3 mit Zugferd Daten wäre.

Aber um jetzt mal den Bogen wieder zurück zum Wareneingangsarchiv zu machen, auch dort wird natürlich heftig mit Relationen gearbeitet, siehe das eigentliche Problem dieses Threads, das ja genau dadurch entsteht, dass eine Relation ins Leere läuft. Das betrifft aber eben auch dort nicht nur die Artikel, sondern z.B. auch die Lieferanten, usw. Löscht man also Heute einen Lieferanten, fehlt er im Wareneingangsarchiv in alle Vergangenheit überall dort, wo er geliefert hat... - Das alles schreit förmlich danach, wie oben vorgeschlagen, für jegliche Kontendaten nach deren erster Benutzung keine Löschung, sondern nur noch eine Archivierung zu erlauben.

 

[KevinK]

Hallo @gutberle,

inzwischen tritt das von Dir angesprochene Verhalten ja so nicht mehr in der aktuellen Version auf. Ich verstehe aber, worauf Du hinaus möchtest.

Das Thema "Löschen von Stammdaten - Auswirkungen auf referenzierte Daten" steht auf unserer ToDo. Es gibt hier einige Stellen, die wir prüfen müssen.

Bitte noch etwas Geduld