Naja, es soll hier ja um ein Refactoring gehen und nicht um Schönheitskorrekturen und da macht es schon Sinn, einmal darauf hinzuweisen, wie derartiges anderswo (gut und flexibel) gelöst ist. Deine Mindestanforderung ist natürlich auch meine Mindestanforderung, klar, aber wenn man sich mal anschaut, wie denn die JTL
Wawi aktuell intern mit Adressen umgeht, wirst Du sehen, dass auch da schon mit wenig Aufwand viel mehr als nur die Mindestanforderung drin ist.
Aktuell verwendet die Wawi 5 Tabellen für Adressen:
tkunde: Dies ist die zentrale Kundentabelle. Alle Adressbestandteile, die man in der Kundenverwaltung für einen Kunden sieht, sind hier physikalisch enthalten. Der Datensatz ist sehr reich an Feldern und und die interne Datensatz-ID heißt
kKunde.
tansprechpartner: In dieser Tabelle finden sich ALLE in der Wawi definierten Ansprechpartner und die Verbindung zum jeweiligen Kundendatensatz findet über
kKunde statt, dass hier auch enthalten ist. Die Zuordnung ist
many-to-1, es kann also viele Ansprechpartner zu einem Kunden geben, aber kein Eintrag kann als Asprechpartner für mehrere Kunden fungieren. Diese Tabelle ist sehr inhaltsschwach, deshalb kaum brauchbar und die Einträge können auch nirgends in der Wawi ausgewählt und verwendet werden.
tadresse: In dieser Tabelle finden sich ALLE in der Wawi definierten Lieferadressen. Auch hier findet die die Zuordnung zum Kundendatensatz über
kKunde statt und die Zuordnung ist ebenfalls
many-to-1. Die Tabelle ist ziemlich inhaltsreich, wenngleich auch nicht so inhaltsreich, wie der Kundendatensatz selbst. Sie ist aber voll in die Logik von Angebots- und Auftragsvorgängen eingebunden und ein echter Kandidat für Erweiterungen.
tlieferadresse: Diese Tabelle ist so etwas wie ein Lieferadress-
Log, denn jeder Angebots- und Auftragsvorgang fügt hier eine Zeile für
kKunde hinzu, und der Eintrag enthält die beim Angebots-/Auftragsvorgang benutzten Lieferanschriftsdaten, die entsprechend auch völlig redundant zu anderen, bisherigen Vorgängen für den Kunden
kKunde sein können.
trechnungsadresse: Völlig analog zu
tlieferadresse, nur für die bei Angebots- und Auftragsvorgängen benutzte Rechnungsadresse.
Die beiden letztgenannten Tabellen kann man hier also vergessen, weil sie vorgangsbezogene Daten abbilden. Sinn machen Sie natürlich sehr viel, denn erst über diese beiden Tabellen lassen sich ad hoc abweichende Liefer- und Rechnungsadressen verwenden, sie sind aber für unsere Zwecke hier uninteressant und sie wären von einem wie auch immer gearteten Refactoring auch nicht direkt oder indirekt betroffen.
Die Tabelle
tansprechpartner ist leider extrem inhaltsschwach mit wenigen und platzmäßig stark beschränkten Textfeldern und man kann aktuell auch nirgends in der Wawi Einträge auswählen um sie z.B. in einer Vorlage zu verwenden. Bei Umsetzung dessen, was ich unten vorschlage, kann sie eigentlich eliminiert werden (nach Übertragung der Daten in
tadresse, s.u.), oder falls es für die zukünftige CRM Integration Sinn macht, direkt im Kundendatensatz-Dialog die zentralen Ansprechpartner zu sehen, dann kann sich die am unteren Fensterrand sichtbare Ansprechpartner-Liste auch von woanders her speisen, nämlich ebenfalls aus
tadresse.
Vorschlag: Erweiterung der Nutzung von Tabelle tadresse für ALLE Adressen eines Kundendatensatzes.
Die Tabelle
tadresse - man beachte den generischen Namen ohne "liefer" - ist schon jetzt ziemlich reich an Feldern und bietet die Möglichkeit, eine der Adressen zum Standard zu machen, Auch die Logik, aus einem Angebots- oder Auftragsdialog eine neue (Liefer-)Adresse auszuwählen ist schon lange implementiert und könnte für die Auswahl von beliebigen Rechnungsadressen, oder sonstigen Adressen einfach aus der Lieferadress-Logik übertragen werden.
Das einzige, was hierzu in
tadresse ergänzt werden muss, ist ein Feld "
cAdressTyp", dass die Werte "Rechnung", "Lieferung", "Kontakt" und vielleicht auch "Sonstiges" haben kann. Aus dem Button "Lief. Adressen" im Kundendatensatz wird dann "Adressen" und im Adress-Dialog selbst würde man z.B. aus einer Dropdownliste den gewünschten AdressTyp auswählen (oder danach filtern oder sortieren). Weiterhin müsste es für jeden
cAdressTyp die Möglichkeit geben, einen der zugehörigen Einträge als Standardeintrag festzulegen. Und um zum Beispiel in einem Angebotsvorgang eine neue Rechnungsadresse auszuwählen, müsste auch die SQL Abfrage nur minimal ergänzt werden, z.B. um ein "
WHERE cAddressTyp='Rechnung'".
Der Aufwand hierfür wäre im Vergleich zu meiner großen Lösung von oben tatsächlich gering und der einzig wesentliche Unterschied zur großen Lösung wäre, dass es sich hier immer noch um
many-to-1 Zuordnungen handelt, also keine Adresse für mehrere Kunden gelten könnte, es sei denn sie wird mehrfach angelegt. Das wäre aber wirklich leicht zu verschmerzen und auch risikofrei möglich, weil der Kundenbezug ja eindeutig über
kKunde läuft.
Wichtig wäre hier aber meines Erachtens, die Daten in Tabelle
tadresse so reich an Information zu machen, wie nur eben möglich. Ein Beispiel:
Im Kundendatensatz gibt es ein Feld UStID. Ich habe aber des öfteren Kunden, die innerhalb ihrer Groß-Organisation mal über diese und mal über jene organisatorische Einheit Dinge bestellen (müssen), z.B. in Abhängigkeit davon, ob es sich um Investitionsgüter oder Verbrauchsmaterialien handelt, etc. Diese unterschiedlichen Orga-Einheiten haben z.B. in Dänemark sehr häufig eigene UStIDs und ich muß dann die ursprüngliche UStID immer wieder im zentralen Kundendatensatz ändern. Gleiches gilt für meine Lieferanten-/Händlernummer beim Kunden, die oftmals und hier auch in Deutschland lokal von den einkaufenden Abteilungen vergeben werden. Wenn man also
tadresse von vornherein mit all den Spalten ausstatten würde, die der Kundendatensatz auch selbst hat, wäre viel gewonnen. Und - ein Schelm, wer Böses dabei denkt - dann ist es nur noch ein ganz, ganz kleiner Schritt dahin, auch die zentralen Kundendaten selbst nur noch eine weitere
tadresse mit dem cAdressTyp "Kunde" sein zu lassen. - Siehe "große Lösung" oben...
Wie Du siehst ist praktisch alles an meiner "großen Lösung" mit wirklich handhabbarem Aufwand und rein auf Basis von bereits in der Wawi bestehenden Tabellen erreichbar. Da die Änderungen in der Abfrage-Logik auch gering sein würden und nur eine Tabelle wegfällt oder wegfallen könnte, die aktuell sowieso nicht wirklich benutzt wird, denke ich, dass eine solche Lösung auch bei intensiv in der DB arbeitenden Partnern wie Amtangee und anderen Akzeptanz finden würde.
Auftrags-Referenznummer aus Onlineshop: Zu Deinem anderen Punkt mit der Referenznummer des Kunden: Ja, die ist extrem wichtig, hat aber nichts mit den hier relevanten Adressen zu tun, sondern ist Bestandteil der Angebots- und Auftragsvorgänge. Auf Shopebene bin ich leider nicht fit genug, um sagen zu können, exakt wie man eine solche Referenznummer beim Bestellvorgang (!) abfragen kann, da man aber im JTL
Shop grundsätzlich
eigene Felder anlegen und als Kunden-Attribute mit der Wawi austauschen kann, müsste das eigentlich irgendwie gehen. Bei mir kommen diese Nummern natürlich auch vor, aber nur innerhalb der Wawi. Dort habe ich mir für die Lieferantennummer ein Kundenattribut und für Bestell-/Anfrage- oder Referenznummern ein Auftragsattribut angelegt. Auf die kann ich auch aus Vorlagen einfach zugreifen.
Gruß,
Ingmar
