Durch die grundlegende Trennung von Kontakten (fkt_contact) und Adressen (fkt_address) ist ja eigentlich bereits die Voraussetzung für beliebig viele Adressen je Kontakt gegeben. Was bislang allerdings noch fehlt, ist die Zwischentabelle (fkt_contact2address) welche die Beziehung zwischen beiden herstellt und die Art der Beziehung benennt. Diese muss mindestens folgendes enthalten:

• Kontakt-ID (Fremdschlüssel: fkt_contact.ID)
• Adresse-ID (Fremdschlüssel: fkt_address.ID)
• Beziehungs-Art (Rechnungsadresse, Lieferadresse, Angebotsadresse usw.)

Anhand dieser Tabelle kann man eindeutig feststellen, welche Adressen zu einem Kontakt gehören, aber natürlich auch welcher Kontakt zu einer Adresse gehört. Somit würde hinsichtlich des Beleg bereits die ID der Adresse genügen.

Gedanken muss man sich allerdings noch machen, was passiert wenn eine Adresse entfernt werden soll!? Hier zu prüfen ob zur Adresse bereits ein Beleg vorliegt und dies daraufhin zu verwehren, halte ich nicht für Sinnvoll. Würden dadurch ja auch veraltete Adressen des Kontakt bestehen bleiben. Besser wäre es der Zwischentabelle noch ein weiteres Feld für den Status (1= Aktiv, 0= Inaktiv) zu spendieren. So können Adressen mit Status = 0 ausgeblendet werden, ohne das die Referenz zum Kontakt verlorengeht.
Wie hinsichtlich dem konkretem Löschen personenbezogener Daten gem. DSGVO verfahren werden muss, müsste übrigens auch noch ausgetüftelt werden.

Eine elegante Lösung wäre übrigens auch nicht die direkte ID der Adresse beim Beleg abzuspeichern, sondern obiger Zwischentabelle (fkt_contact2address) ein weiteres Feld mit einer eigenen ID zu spendieren und jeweils gleich auf diese zu verweisen.

Des weiteren sollte vorher auch grundlegend geklärt werden, wie manuelle Adressen abgelegt werden. Momentan werden diese ja in den Adressen (fkt_address) abgelegt und bei den Kontakten (fkt_contact) zu jedem ein inhaltsleerer Eintrag erzeugt. Ich fände es Besser hier ein Standartkonto zu definieren, auf welchen diese dann Referenzieren.

Wobei für ein Dokument durchaus mehrere Kontakte angehängt werden können, weil ich ja später beim Drucken bspw. Rechnungs- und Lieferadresse mit wissen muß.

Warum? Ein Dokument kann m.E. immer nur eine eindeutige Adresse haben! Beispielsweise eine Rechnung die Rechnungsadresse und ein Lieferschein eben die Lieferadresse. Wenn dem so ist, braucht es hier keine Zwischentabelle und die ID kann direkt beim Dokument abgelegt werden.

Gruß
Matthew

Warum? Ein Dokument kann m.E. immer nur eine eindeutige Adresse haben! Beispielsweise eine Rechnung die Rechnungsadresse und ein Lieferschein eben die Lieferadresse. Wenn dem so ist, braucht es hier keine Zwischentabelle und die ID kann direkt beim Dokument abgelegt werden.

Das ist eben nicht ganz richtig. Aktuell ist es nämlich so, daß man bei einem Dokument sowohl die Rechnungs- als auch die Lieferadresse angeben kann. Bei einer Rechnung halte ich das auch für sinnvoll (sieht man ja auch bei diversen Versandhäusern auf der Rechnung). Auch die Platzhalter sind so angelegt, daß sie für ein Dokument mehrere Adressen haben können (also DELIVERY.ADDRESS und "normale" ADDRESS). Das will ich auch nicht ändern. Natürlich ist es (buchhalterisch) richtig, daß ein Dokument nur eine Adresse haben kann. In der "Fakturama"-Welt ist das aber eben anders. Deswegen ja eben meine Frage, wie ich das zusammenhängen soll. Die Verknüpfung von Kontakt und Adresse ist mir halbwegs klar, da würde ich auch den Vorschlag von LastBoyScout aufgreifen.

Bislang kann es ja zu einem Kontakt auch maximal nur diese beiden Adressen geben, eben eine Rechnungs- und eine Lieferanschrift. Natürlich ist es sinnvoll ggf.auch auf der Rechnung die Lieferanschrift nochmal mit angeben zu können, aber diese kann ja auch über den dazugehörigen Lieferschein ermittelt werden. Nämlich anhand der identischen Auftragsnummer, welche ja beim weiterführend über alle Belagerten hinweg übernommen werden sollte. Schreibt man eine Rechnung ohne vorherigen Lieferschein dann ist zwangsläufig Rechnungs- und Lieferanschrift identisch.
Denken wir uns jetzt beispielsweise mal einen Kunden mit einer Rechnungsanschrift A und zwei Lieferanschriften B und C. Dann darf der Rechnung nicht A und B zugeordnet sein, wenn der Lieferschein auf C ausgestellt wurde.
Dann gibt es ja auch noch die Sammelrechnung, welche mehrere Lieferscheine zusammenfassend abrechnen kann. Wenn bei vorhergehendem Beispiel Lieferung 1 an B und Lieferung 2 an C ging, müssten ja eigentlich auch beide wiedergegeben werden können. Nur A und B der Rechnung zu hinterlegen, währe dann ja unvollständig.

Es gibt aber auch Kleinstunternehmer, die keinen Lieferschein ausstellen und trotzdem auf der Rechnung eine Liefer- und eine Rechnungsadresse haben möchten...
Wie ich das mit Sammelrechnungen mache ist mir auch noch nicht klar. Evtl. müßte dann ein Dialog kommen, ob eine ggf. abweichende Lieferanschrift aus den Lieferscheinen übernommen werden soll. Ich glaube, das kann man beliebig komplex gestalten...

Es gibt aber auch Kleinstunternehmer, die keinen Lieferschein ausstellen und trotzdem auf der Rechnung eine Liefer- und eine Rechnungsadresse haben möchten...

Und kann diese momentan auch zugewiesen werden? Oder wird hier aktuell einfach immer die hinterlegte Lieferanschrift verwendet, sofern eine solche vorhanden?

Also in dem Fall wird tatsächlich die hinterlegte abweichende Lieferanschrift aus den Kontakten verwendet. Ansonsten wird die Lieferanschrift aus dem Lieferschein verwendet, aus dem die Rechnung entstanden ist (falls dem so ist).

Hallo zusammen,
ich habe mal noch bißchen über dem Problem meditiert. Dabei ist mir die angefügte Lösung eingefallen, die das bisher Gesagte vermutlich ziemlich gut zusammenfaßt (glaube ich jedenfalls ;)). Dazu noch ein paar Worte, weil ich hier nicht alle Felder modelliert habe. Das ganze ist nur als Skizze zu verstehen. Es sollte aber alle bisher besprochenen Problemfälle abdecken:

1. ein Dokument kann nur einem Kontakt zugeordnet sein
2. ein Kontakt kann mehrere Adressen haben, denen jeweils auch eine Bedeutung mitgegeben werden kann (Lieferadresse, Rechnungsanschrift oder sonstwas)
3. ein Dokument kann eine manuell eingegebene Adresse haben (das ist das Feld manualAddress, was direkt in der Zwischentabelle hängt), und zwar genau eine pro Dokumentart

Ich habe die "Haupt"-Tabellen mal fett beschriftet, die Zwischentabellen normal. Die Zwischentabellen haben natürlich auch noch einen extra Schlüssel, den habe ich jetzt nicht mit reingemalt. Ich habe da nur die Verweise zu den Haupttabellen modelliert. Bei Sammelrechnungen würde ich es so machen, daß ich beim Vorhandensein unterschiedlicher Lieferadressen einen Dialog öffne, der die zu verwendende Lieferadresse abfragt (wobei ich mich gerade frage, ob das überhaupt auftreten kann, weil man ja nur Lierungen zu einem Kunden zusammenfassen kann). Unterschiedliche Lieferadressen könnten auftreten, wenn ich mehrere Filialen des Kunden beliefere. D.h., es muß auch möglich sein, pro Kontakt mehrere Lieferadressen zu speichern (das hatte dr.listemann glaube ich schon mal vorgeschlagen). Das würde IMO mit diesem Modell auch funktionieren.

Was allerdings gerade nicht geht (fällt mir gerade ein) ist folgender Fall: Wenn ich zu einem Dokument (z. B. einem Lieferschein) ausnahmsweise mal nicht die Lieferadresse, sondern die Rechnungsadresse eines Kontaktes speichern möchte, dann klappt das nicht. Es sei denn, ich speichere in DocumentContacts noch eine Info über die ausgewählte Adresse oder zumindest den Typ (z. B. als addressBillingType oder sowas).

Wenn ich es richtig verstanden habe muß sowohl in der Contact-Tabelle als auch in der Address-Tabelle ein Personen- oder Firmenname hinterlegt sein, richtig? Das bräuchte man ja beispielsweise, wenn man an Firma XYZ liefert, aber die Lieferung an deren Filiale zu Händen Herrn Meyer geht. Da müßte ich dann doch nochmal an den Platzhaltern herumschrauben, die würden dann nämlich nicht mehr richtig passen.

So ist es m.E. noch nicht richtig rund... In deinem Modell wird die Document_ID mit der Contact_ID verknüpft, letztere ist wiederum mit einer, oder eben auch beliebig vielen Adress_ID verbunden. Mir ist somit nicht Klar, wie denn damit die für den jeweiligen Beleg verwendete Adresse eindeutig zugewiesen werden soll!?

Wie bereits festgestellt, kann ein Dokument immer nur einem Kontakt (Kunde oder Lieferant) zugeordnet sein. Somit sollte die Contact_ID auch direkt beim Document abgelegt werden. Eine Zwischentabelle DocumentContacts würde ja nur bei multiplen Beziehungen Sinn machen.

Das Feld manualAddress missfällt mir sehr! Erstens kann ein solches Feld kaum Analysiert werden (Was davon ist nun Name, Straße, PLZ, Ort usw. ?) Und zweitens sollten in den Zwischentabellen prinzipiell nur Beziehungen und dessen Eigenschaften aber keine direkten Daten abgelegt werden. Auch manuell angelegte Adressen sollten daher gleich strukturiert gespeichert werden. Diese könnten Beispielsweise auch einem, in den Einstellungen zu definierendem, Standartkonto für Debitoren (z.B. KD10000) und Kreditoren (z.B. LF70000) zugewiesen werden. Dies hätte neben der Weiterverarbeitbarkeit strukturierter Daten (z.B. Datenübergabe an Versandprozesse) auch den Vorteil diese im Nachhinein einem neuen Kundenkonto zuordnen zu können (eine Eintagsfliege wird evtl. doch noch zum Mehrfachtäter).

Überdies gibt gilt es auch noch folgende Punkte zu bedenken:

• Wird eine Adresse zu einem späteren Zeitpunkt geändert, entsprechen diese mit dem Dokument verknüpften Daten ja nicht mehr dem ursprünglich erstellten Beleg! Schließlich würde bei erneutem öffnen des Dokument die aktuelle Version der Adresse angezeigt und nicht die zur Belegerstellung gültige. Die ursprüngliche Version der Adresse könnte auch nicht mehr aufgerufen werden.
• Wird eine Adresse nach Dokumenterstellung entfernt, geht der Bezug komplett verloren und das Dokument wäre damit ebenfalls nicht mehr Valide. Eine evtl. denkbare Sperrung jener Adressen zu denen ein bereits ein Beleg existiert, ist keineswegs praktikabel.

Daher mein Vorschlag:

Genau wie die Produkte bei Übername in ein Dokument unter documentitem abgelegt werden, so dass Änderungen (z.B. an Text oder Preis) unabhängig vom "Produktkatalog" gespeichert werden. Sollten auch die zu einem Dokument genutzten Adressen in einer extra Tabelle receiver abgelegt werden. Die Tabelle address ist dann quasi wie ein "Adressbuch" der Kontakte zu verstehen, aus welchen man sich bei Dokumenterstellung bedienen kann und welches bestenfalls immer aktuell gehalten wird.
Die Zuordnung zwischen document und receiver erfolgt dann über eine Zwischentabelle documentreceiver unter Angabe der Beziehungsart. Über zwei Beziehungen kann dann auch ein und die selbe Anschrift sowohl als Rechnungs- wie auch Lieferanschrift fungieren. Ebenso ließen sich zu Sammelrechnungen mehrere Lieferanschriften zuordnen. Die Rolle eines solchen "Adressarchiv" hätte entscheidende Vorteile:

• Bei Löschung oder Änderung einer Kundenanschrift bleiben die in der Vergangenheit verwendete Adressen erhalten.
• Änderungen einer Anschrift müssen nicht mehr zum Verlust der Kontaktbeziehung führen (siehe Bug #747).
• Auch Manuelle Adressen können strukturiert in der selben Tabelle gespeichert werden.
• Zu einem Dokumenten können mehrere Adressen abgelegt werden: Rechnungsanschrift, Lieferanschrift A, Lieferanschrift B (Thema Sammelrechnung) usw.

In der Praxis würde ich es mir daher folgendermaßen vorstellen:

Eine einzelne Anschrift zum Kontakt gilt als "Hauptanschrift", welche immer für alle Belegarten gültig ist. Ab der zweiten Anschrift sollte man in der Erfassungsmaske jede Dokumentart einzeln aus- bzw. abwählen können. Diese Beziehungsart des Kontakt zur jeweiligen Adresse sollte mit in der Zwischentabelle ContactAddresses abgelegt werden. Dabei ist sicher zu stellen, dass eine Anschrift hier ggf. auch mehrere Eigenschaften haben kann! Bei Belegerfassung erfolgt dann die Adressauswahl noch folgender Logik erfolgen:

1. Ist zur jeweiligen Belegart keine zusätzliche Anschrift definiert, wird automatisch die Hauptanschrift übernommen.
2. Ist eine zusätzliche Anschrift für die Belegart vorhanden, wird automatisch diese übernommen.
3. Sind zur jeweiligen Belegart zwei oder mehrere zusätzliche Anschriften vorhanden, erfolgt ein Auswahldialog.

Darüber hinaus gilt:

1. Der Auswahldialog kann über einen Schaltfläche erneut aufgerufen werden. So kann auch bei einer automatischen Adressübernahme dennoch die "Hauptanschrift" zugewiesen werden.
2. Über eine weitere Schaltfläche kann eine Dialogmaske zur Erfassung eine neuen Anschrift geöffnet oder die bereits übernommene geändert werden.
   Ist dem Dokument ein Kontakt zugewiesen (Kunden- oder Lieferantennummer) erfolgt hier eine Rückfrage, ob diese neue oder geänderte Adresse auch als zusätzliche Anschrift zum jeweiligen Kontakt gespeichert werden soll (Die aktuelle Belegart gibt dabei die Art der Beziehung vor).

Die gesonderte Lieferanschrift des Dokument (Rechnung) wird ja bestenfals vom vorhergehenden Liferschein übernommen. Somit muss die Lieferanschrift nur definiert werden, wenn kein Lieferschein erstellt wurde und der Beleg quasi als "Kombidokument"(Lieferschein & Rechnung) fungiert. Dabei sollte folgende Logik Verwendung finden:

1. Ist zum Kontakt nur eine Anschrift definiert, gilt diese weiterhin sowohl als Liefer- wie auch als Rechnungsanschrift.
2. Ist neben der Rechnungsanschrift eine Lieferanschrift vorhanden, wird diese automatisch als Lieferanschrift übernommen.
3. Sind mehrere mögliche Anschriften vorhanden, erfolgt wiederum der Auswahldialog.

Denke dieser Lösungsansatz wäre die Beste Weg und zugleich die flexibelste Lösung und ich hoffe ich konnte die doch recht komplexe Thematik einigermaßen verständlich rüber bringen!?

Gruß
Matthew

So ähnlich war die Speicherung schon mal in der Version 1. Dort hat mich allerdings gestört, daß die Adressen eben redundant gespeichert waren. Außerdem müßte ich ja neben den Adressen auch noch die Bankverbindung(en) mit speichern und ggf. noch weitere Daten. Was mache ich denn damit?
Generell finde ich den Ansatz durchaus überlegenswert. Ich denke da nochmal drüber nach und werde mein Bildchen entsprechend anpassen. Wie die Tabellen letztendlich heißen ist ja prinzipiell erst mal egal, ich schreib die ja nicht manuell, sondern laß die erzeugen. Mein Datenmodell sieht dementsprechend auch nicht wie eine Datenbank aus. Aber das ist eh eine andere Geschichte.

So, ich hab nochmal drüber nachgedacht. Paar Fragen sind aber trotzdem noch offen 🙂

Ab der zweiten Anschrift sollte man in der Erfassungsmaske jede Dokumentart einzeln aus- bzw. abwählen können.

Das wäre dann in etwa so wie in dem Ticket beschrieben (in dem Bild). Da hatte ich ganz unten bereits "Art der Anschrift" als Aufklappfeld vorgesehen. Mir war halt nicht klar, ob diese "Art der Anschrift" besser beim Kontakt oder besser im Dokument aufgehoben ist. Wenn man allerdings definiert, daß eine Anschrift sowohl Lieferadresse als auch Rechnungsadresse sein kann dann ergibt das wieder Sinn und man kann das an den Kontakt hängen. Die Mehrfachauswahl sagt eben dann aus, daß diee Adresse potentiell diese oder jene Bedeutung haben kann. Dann kann ich ja den Vorschlag für den Kontakte-Dialog schon so verwenden, oder?

Bei Belegerfassung erfolgt dann die Adressauswahl noch folgender Logik erfolgen:

Ist zur jeweiligen Belegart keine zusätzliche Anschrift definiert, wird automatisch die Hauptanschrift übernommen.
Ist eine zusätzliche Anschrift für die Belegart vorhanden, wird automatisch diese übernommen.
Sind zur jeweiligen Belegart zwei oder mehrere zusätzliche Anschriften vorhanden, erfolgt ein Auswahldialog.

Klingt sinnvoll, das würde ich mal so versuchen umzusetzen.

Der Auswahldialog kann über einen Schaltfläche erneut aufgerufen werden. So kann auch bei einer automatischen Adressübernahme dennoch die "Hauptanschrift" zugewiesen werden.

Das hieße aber, daß man die ursprüngliche Kontakt-ID schon irgendwo mit hinterlegt. Ich hab das mal in meinen überarbeiteten Entwurf mit reingepackt. Die ist dann quasi nur als "Merkhilfe" da, wo die Adresse mal ursprünglich her kam.

Über eine weitere Schaltfläche kann eine Dialogmaske zur Erfassung eine neuen Anschrift geöffnet oder die bereits übernommene geändert werden.
Ist dem Dokument ein Kontakt zugewiesen (Kunden- oder Lieferantennummer) erfolgt hier eine Rückfrage, ob diese neue oder geänderte Adresse auch als zusätzliche Anschrift zum jeweiligen Kontakt gespeichert werden soll (Die aktuelle Belegart gibt dabei die Art der Beziehung vor).

Die Neu-Erfassung geht ja jetzt schon. Da würde sich also bis auf die zusätzliche Abfrage nichts ändern.

1. Ist zum Kontakt nur eine Anschrift definiert, gilt diese weiterhin sowohl als Liefer- wie auch als Rechnungsanschrift.
2. Ist neben der Rechnungsanschrift eine Lieferanschrift vorhanden, wird diese automatisch als Lieferanschrift übernommen.
3. Sind mehrere mögliche Anschriften vorhanden, erfolgt wiederum der Auswahldialog.

Zu 3. habe ich noch eine Frage: Wann soll der Auswahldialog denn kommen? Beim Speichern? Oder beim Drucken? Wenn beim Drucken, dann vor jedem Druckvorgang oder nur vor dem ersten?

Ich habe übrigens die manuelle Adresse doch nochmal mit reingenommen, weil ich glaube, daß die manche Leute sonst vermissen würden. Ich weiß, daß ich mir damit auch einigen Ärger einhandle (unstrukturierte Daten usw.), aber ich möchte das zu diesem Zeitpunkt jedenfalls noch nicht weglassen. Ich verstehe natürlich auch Deine Argumente, @LastBoyScout, und ich habe vor der Version 2 auch schon drüber nachgedacht, das Feld rauszuschmeißen. Leider geht das aber auch nicht, weil ich dann sämtliche bestehenden Dokumente bei der Migration irgendwie zurechtbiegen müßte, sodaß die Adresse paßt. Das geht nur teilweise gut, glaube ich. Es sind halt Altlasten, die man mitnehmen muß (oder denen ich jedenfalls keine Absage erteile). Die tun ja auch nicht sonderlich weh. Das einzige Problem ist nur, daß der Nutzer die halt nicht besonders vernünftig auswerten kann (beim Drucken). Es gibt zwar im Fakturama eine Funktion, die "errät", welche Zeile welche Bedeutung hat, das ist aber aufgrund der Vielzahl an Kombinationen nicht immer zuverlässig.

kleiner Nachtrag: ich würde die manuellen Adressen nicht auf fixe Kundennummern speichern. Erstens muß ich die dann bei allen möglichen Aktionen ausblenden (Listen, Suchmasken usw.), zweitens passen die auch nicht unbedingt zum vorgegebenen Nummernschema und Der User (sollte er denn mal in die DB schauen) wundert sich, was da für Zeugs steht. Außerdem habe ich mit solchen fest definierten Sachen immer so meine Bauschmerzen.

So ähnlich war die Speicherung schon mal in der Version 1. Dort hat mich allerdings gestört, daß die Adressen eben redundant gespeichert waren. Außerdem müsste ich ja neben den Adressen auch noch die Bankverbindung(en) mit speichern und ggf. noch weitere Daten. Was mache ich denn damit?

Ja, das ist ein Punkt der mir anfangs meiner Überlegungen ebenso erst missfiel. Auch bei identischen Daten muss man hier aber quasi das "Adressbuch" vom "Belegarchiv" gedanklich trennen. Ich wüsste schließlich nicht, wie man ansonsten Datenaktualität im Adressbuch und Archivierung unter einen Hut bekommen könnte. Für das Dokument müssen ja auch nicht alle Kontakt- und Adressdaten archiviert werden, sondern nur die für die Belege relevanten... somit eigentlich all jene, welche über Platzhalter ausgegeben werden können.
Auch würde ich z.B. bei Folgedokumenten ohne Änderung an der Anschrift diese nicht erneut Speichern, sondern nur auf die bereits bestehende einen neuen Bezug in der Zwischentabelle erstellen.

Das wäre dann in etwa so wie in dem Ticket beschrieben (in dem Bild). Da hatte ich ganz unten bereits "Art der Anschrift" als Aufklappfeld vorgesehen.

Ja ganz genau... Und bei der ersten (oder letzten verbleibenden nach Löschung anderer), ist dieses Ausgegraut, da die Anschrift ja dann immer für alle Belegarten nutzbar sein muss.

Mir war halt nicht klar, ob diese "Art der Anschrift" besser beim Kontakt oder besser im Dokument aufgehoben ist.

Die Art der Anschrift müsste dann in der Zwischentabelle abgelegt werden, schließlich wird damit die Art der wechselseitigen Beziehung zwischen Kontakt und Adresse/n repräsentiert.

Dann kann ich ja den Vorschlag für den Kontakte-Dialog schon so verwenden, oder?

Mit folgende Ergänzungen:

• Nach "Firma" sollte noch ein Feld "Zusatz" eingefügt werden, für z.B.: Winkelmann & Söhne GmbH Hausverwaltung oder Herr Klaus Müller Augenarzt
• Hinsichtlich strukturierter Daten sollte das Feld Straße in Straße und Hausnummer getrennt werden. Zur Aufbereitung aktueller Daten könnte eine mögliche Logik lauten: Ab dem Ersten vorkommen einer Zahl ist der Rest die Hausnummer: "Giebelstraße 114 A" = "Giebelstraße" und "114 A[/i]"