Noch ein Nachtrag:

1. Zu den Adressen braucht es auch noch ein Feld für Ansprechpartner!
2. Ebenfalls sollte man zu jeder Adresse einen kurzen Freitext eingeben können. Z.b. "Baustellenanschrift" oder "Anlieferungen nur Werktags 10 bis 14 Uhr" oder "Zufahrt über Lärchenweg" usw. Dies müsste dann natürlich auch über einen Platzhalter im Beleg ausgegeben werden können.
3. Zu einem Kontakt kommen ja gelegentlich immer mal wieder Informationen hinzu, welche man aktuell nur unten an den Infotexte anhängen kann. Schöner wäre es auch die Infotexte multiple zu gestalten, so das auch der jeweilige Zeitstempel für jede Info ferfügbar ist und alle chronologisch untereinander aufgelistet werden. So hätte man immer den überblick wann was war und können einzelne Einträge auch leicht löschen.

Schönes WE
Matthew

Ich steige noch einmal bei diesem Zitat von LastBoyScout ein: "Was bislang allerdings noch fehlt, ist die Zwischentabelle (fkt_contact2address) welche die Beziehung zwischen beiden herstellt ..."

Ich denke, man muss es nicht so kompliziert machen: Zunächst gibt es Kontaktdateien (jeweils für Kunden und für Lieferanten) mit eindeutigen (unverwechselbaren) Kunden- oder Lieferanten-Nummern und Adressdateien (ebenfalls jeweils für Kunden und für Lieferanten), in denen jeder Adresse vorweg die Kunden- oder Lieferanten-Nummer zugeordnet ist, zu denen die Adresse (-n) gehören ...

Um das einmal bildlich zu verdeutlichen, haben die Kontaktdateien dann eher den Charakter von (Kunden-/Lieferanten-) Karteikarten und die (Kunden-/Lieferanten-) Adressdateien den Charakter von einfachen Listen. Auf dem Kontakt-Karteikartenreiter steht die jeweilige Kunden- bzw. Lieferanten-Nummer und in der ersten Spalte der Adressen-Liste immer die Kunden-/Lieferanten-Nummer, zu denen die jeweilige Adressen (-n) gehören, in der zweiten Spalte die lfd. Nummer unterhalb der gleichen Kunden-/Lieferanten-Nummer:

(ganzes Bild hier)

Soweit haben das Ralf sowie einige andere Mitstreiter aber bereits recht gut herausgearbeitet, und soweit kann man schon erkennen, dass "vermittelnde" Zwischendateien eigentlich nicht notwendig sind ... :)-D

Wie nun könnte man die jeweilige Anschrift in den Dokumenten weiterreichen ? Ich sehe dazu folgenden Weg:

1. Ein auftragsbezogenes Dokument (Angebot, Lieferschein, Rechnung usw.) ist grundsätzlich so lange und unveränderlich einem und dem selben Kontakt (Kunde oder Lieferant) zugeordnet, bis der Auftrag mit der letzten Rechnungslegung vollständig realisiert wurde. Daraus folgt, dass in dem jeweiligen Dokument die entsprechende Kunden- oder Lieferanten-Nummer immer mitgereicht und auch offen ausgewiesen wird, welcher Adressat das Dokument dann auch immer erhält (z.B. bei abweichender Lieferadresse)

2. Zum Zweiten wird im jeweiligen Dokument die zugehörige Adress-Nummer mitgeführt, die dann in das Adress-Feld die entsprechende Adresse einfügt (bei einer abweichenden Lieferadresse dann eben diese). Die Adress-Nummer wird im Dokument niemals offen angezeigt - es ist lediglich eine systeminterne Nummer.

Im Fazit also wird in jedem auftragsbezogenen Dokument die gesamt-auftragsbezogene und offen angezeigte (auch ausgedruckte) Kunden- bzw. Lieferanten-Nummer sowie die auf den jeweiligen Bearbeitungsstand bezogene Adress-Nummer mitgeführt - mit anderen Worten gibt's diesbezüglich je Dokument immer zwei mitgeführte Nummern bzw. die Kunden-/Lieferanten-Nummer mit der jeweiligen lfd. Adress-Unternummer:

Prinzip: (Kunden-/Lieferanten-Numer)-(lfd. Adressen-Unternummer)

So könnte z.B. für einen Kunden names "BERGER GmbH" mit der Kd.-Nr. "112018", dessen "Buchhaltung" in seiner Adressliste unter der lfd.Nr. "23" aufgeführt ist, im Rechnungs-Dokument die 2-teilige Nummer "112018-23" mitgeführt werden :)o

Was ist dafür zu tun ? Die (Kunden/Lieferanten) Adressdatei (-en) können theoretisch unendlich lang werden oder man beschränkt sich beispielsweise auf 99-100 Adressen je Kunde bzw. Lieferant (mehr ist wohl kaum realistisch). Wenn man sich auf jeweils maximal 100 Adressen beschränkt, so sollte die erste Adresse immer die des offizellen Firmenhauptsitzes sein, so dass noch jeweilige 99 Unteradressen z.V. stehen. Damit wird o.a. lfd. Nummer der (Unter-) Adresse 2-stellig und das sollte eigentlich genügen. Wenn man FAKTURAMA aber offener halten möchte, so wäre es sinnvoll, in den Einstellungen festlegen zu dürfen, wie viele Stellen die Adressdatei je Kunde/Lieferant haben soll ...

Und wie geht man nun mit der offiziellen Adresse des Firmenhauptsitzes um ? Hierfür sollte grundsätzlich die lfd. Unternummer "00" gelten. Mit anderen Worten würde das bedeuten, dass in dem Dokument, das an den Firmenhautsitz adressiert ist, die Kunden-/Lieferantennummer mit der (erweiterten) Unternummer "00" mitgeführt wird, bei einer Adressierung an ein Lager z.B. die Unternummer "08" und an die Buchhaltung z.B. die Unternummer "23" anfallen ...

Abschließend steht die Frage, wie weit solche Adressierungen automatisiert werden sollten: Ich persönlich denke, man könnte in der Adressdatei eine Spalte mit anlegen, aus der ersichtlich ist, ob die jeweilige Adresse generell für Auslieferungen, Abrechnungen usw. gültig ist. Wird ein Dokument neu erstellt, so könnte beim Adressaufruf die entsprechende Adresse zunächst automatisch angeboten werden, aber der FAKTURAMA-Anwender sollte immer noch die freie Wahl haben, eine andere Adresse aus der Liste auszuwählen und diese dann im Adressfeld des Dokumentes sogar noch zu überarbeiten ...

Dem FAKTURAMA-Anwender sollte jedoch nicht erlaubt sein, dass er innerhalb (darauf liegt die Betonung) des Adressfeldes Änderungen in der Adressdatei selber vornehmen kann - das müsste dann außerhalb der Dokumentenbearbeitung, d.h. in den Stammdaten gemacht werden ...

Ich denke, damit lässt sich die gesamte Problematik doch recht leicht lösen ... :)-D

@dr.listemann

Leider scheint dir der technische Sachverstand hinsichtlich moderner Datenbankarchitektur zu fehlen!? Ich empfehle daher erst mal einen direkten Blick in die Datenbank von Fakturama zu tätigen ::o (z.b. mittels HeidiSQL). Hättest du dies getan, wäre dir zumindest schon mal aufgefallen, dass Bezüge zwischen Tabellen immer über die ID eines Datensatz erfolgen und nicht über ein Datenfeld wie etwa die Kundennummer. Überdies scheinen verschachtelte Nummerierungen offenkundig irgendwie dein Steckenpferd zu sein, wie man ja bereits aus deinem anderen Beitrag ersehen kann.

Mit der aktuellen Datenbankarchitektur können einem Kontakt maximal zwei Adressdatensätze verknüpft werden, nämlich genau eine Haupt- und eine Alternativadresse. Darüber hinaus erfolgt dies bis dato einseitig, sprich dem Kontakt sind die zugehörigen Adressen hinterlegt, den Adressen jedoch nicht der zugehörige Kontakt. Letzteres könnte man daher momentan nur über einen Suchlauf aller Datensätze herausfinden. Und genau dies wäre dann auch schon die größte Schwachstelle deines unausgegorenen Vorschlag. Um nämlich herausfinden zu können welche Adressen zu einem Kontakt gehören, müsste man nach deiner Logik erst sämtliche Datensätze durchsuchen, nur um dann jene mit identischen Nummern herausfinden zu können. Was für eine immense Ressourcen- und Zeitverschwendung! Fakturama würde dadurch lahm wie eine Schnecke und der Cache überdies vermutlich unnütz aufgebläht.

Außerdem würde durch deinen Vorschlag jeder Kunde eben nicht mehr nur eine eindeutige Kundennummer herhalten, sondern durch diese m.E. Unsinnigen Anhängsel de facto mit jeder Adresse eine weitere. Wenn man das dann noch mit deinen o.g. Vorschlag zu den Kunden- & Lieferantennummern kombiniert, ergibt dies ein über die maßen kompliziertes Konstrukt.

Um Fakturama zukunftssicher weiter zu entwickeln, sollte man etablierte moderne Techniken verwenden und nicht mit derart exotischen Lösungsansätzen das Rad neu erfinden wollen. B)
Auch wenn relationale Datenbanken auf den ersten Blick kompliziert erscheinen Mögen, sind sie es nicht wirklich... Die Datenhaltung erledigt der Datenbabkserver im Hintergrund, der Anwender von Fakturama muss sich damit nicht auseinandersetzten.

Gruß
Matthew

P.S. @rheydenr sorry bez. des mehrfachen Posting... ich erhielt immer ein Error 502 (Bad Gateway) hatte irgendwann aufgegeben und bis zum Beitrag von dr.listemann war es auch noch nicht vorhanden!?

Stichwort "Datenbank-Kenntnisse": LastBoyScout - vergreife Dich hier bitte nicht im Ton, wir sind hier nicht bei FACEBOOK !!! Ich verfüge über 35 Jahre berufliche Erfahrungen bei der Konzipierung, Einsatzvorbereitung, Einführung und Betreuung von betriebswirtschaftlichen EDV-Systemen in verschiedenen Branchen und Größen, davon 30 Jahre u.a. mit einem eigenen Systemhaus, das sich gerade hierauf spezialisiert hat. Und in diesem Zusammenhang habe ich mich u.a. auch mit relationalen Datenbanken befasst, d.h. ich weiß sehr wohl, was sich dahinter verbirgt und wie verschiedene Datenbanken miteinander verknüpft werden ... !

Zurück zum Thema: Die von Dir erwähnten (internen) Verknüfungs-ID's interessieren den Anwender überhaupt nicht - den Anwender interessieren die Inhalte, wie z.B. Kunden- oder Lieferanten-Nummern und die ihnen zuordbaren Adressen. Wie ein Programmierer das Problem dann löst, ist den Anwendern egal, aber die Lösung und deren Handhabbarkeit selber nicht. Und die FAKTURAMA-Programmierer klären das dann unter sich in einem ganz anderen Forum, das hierfür bereits vor einigen Jahren eingerichtet wurde (siehe hier) - im hiesigen Forum hingegen geht's ausschließlich erst einmal um generelle Konzepte - es heißt nicht umsonst "Konzeptionsdiskussionen" ...

LastBoyScout - vergreife Dich hier nicht im Ton, wir sind hier nicht bei FACEBOOK !!!

Hab ich an keiner Stelle getan !!! Und mit FB hab ich schon garnichts am Hut...

Ich verfüge über 35 Jahre berufliche Erfahrungen bei der Konzipierung, Einsatzvorbereitung, Einführung und Betreuung von betriebswirtschaftlichen EDV-Systemen in verschiedenen Branchen und Größen, davon 30 Jahre u.a. mit einem eigenen Systemhaus, das sich gerade hierauf spezialisiert hat. Und in diesem Zusammenhang habe ich mich u.a. auch mit relationalen Datenbanken befasst, d.h. ich weiß sehr wohl, was sich dahinter verbirgt und wie verschiedene Datenbanken miteinander verknüpft werden ... !

Bitte nicht persönlich nehmen, aber bei Lecktüre deines Beitrags wird eben dies leider nicht deutlich... Schließlich verwirfst du da ein durchdachtes Konzept auf Basis etablierter Techniken (da dieses angeblich zu kompliziert würde) und willst es stattdessen lieber mittels eines m.E. nicht zu Ende gedachten Konstrukt bewerkstelligen!?

Die von Dir erwähnten (internen) Verknüfungs-ID's interessieren den Anwender überhaupt nicht...

Dito, meine Rede... Aber hier geht es eben darum wie etwas umgesetzt werden kann und nicht wie es für den Anwendern aussehen soll!

Wie ein Programmierer das Problem dann löst, ist den Anwendern egal, aber die Lösung und deren Handhabbarkeit selber nicht. Und die FAKTURAMA-Programmierer klären das dann unter sich in einem ganz anderen Forum, das hierfür bereits vor einigen Jahren eingerichtet wurde (siehe hier) - im hiesigen Forum hingegen geht's ausschließlich erst einmal um generelle Konzepte - es heißt nicht umsonst "Konzeptionsdiskussionen"

Wenn du dir alle Beiträge des Thema chronologisch durchliest, wirrst du bemerken, dass das erarbeiteten Konzept eben gerade in Zusammenarbeit mit dem Hauptentwickler entstanden ist und damit die Lösung der Aufgabenstellung (Mehrere Adressen je Kontakt), Performant und Datensicher möglich wird. Und dies eben gerade ohne das der Anwender seinen gewohnten Workflow ändern muss (etwa durch neue Nummernkonstrukte mit irgendwelchen Anhängsel).

:)-D

LastBoyScout schrieb:
-------------------------------------------------------
Dabei sollte folgende Logik Verwendung finden:

...
3. Sind mehrere mögliche Anschriften vorhanden, erfolgt wiederum der Auswahldialog.

rheydenr schrieb:
-------------------------------------------------------
> Zu 3. habe ich noch eine Frage:
> Wann soll der Auswahldialog denn kommen?
> Beim Speichern? Oder beim Drucken? ...

Wedernoch! (hier könnte jetzt ein Smiley stehen) Ich sehe "DIE" mögliche Lösung darin ...

Fall 1: Rechnung schreiben
(ohne vorherige Übernahme aus Bestandsdokument, wie bspw. AB oder Angebot)
- Rechnung anklicken
- Kunde auswählen
- Plong! Sind mehrere Adressen hinterlegt, dann Auswahldialog "Adresse wählen" (ggf.: hinzufügen/ändern).

Fall 2: Rechnung erstellen aus ...
(mit vorheriger Übernahme aus Bestandsdokument, wie bspw. AB oder Angebot)
- Im "Bestandsdokument" auf "in Rechnung übernehmen" klicken
- Plong! Sind mehrere Adressen hinterlegt, dann Auswahldialog "Adresse wählen" (ggf.: hinzufügen/ändern).

Als Grund, wieso ich nicht "warten" wollen würde: Ich würde mir die Frage stellen, wieso
ich mich erst gegen Ende nochmals(!) mit dem Thema Adresse auseinandersetzen sollte.
Und das dann in einem Moment, wo man (speichern, drucken & ''feddich'') abgeschlossen hat.

Das "Problem" ist doch, dass der eigentliche Rechnungsempfänger ein ganz bestimmter Privat- oder Firmenkunde ist, dessen Hauptanschrift von der Rechnungsanschrift abweichen kann. Eine abweichende Rechnungsanschrift kommt beispielsweise dann vor, wenn der Firmensitz vom Sitz der Rechnungsprüfung oder der Buchhaltung abweicht - derartige ähnliche Fälle gibt's wie Sand am Meer. Aber dennoch repräsentieren diese "Außenstellen" den eigentlichen Rechnungsempfänger bzw. Kunden bzw. Debitoren ...

Ergo müsste bei der Dokumentenerfassung oder -bearbeitung im Adressfeld zunächst erst einmal der eigentliche Rechnungsempfänger (Kunde/Debitor) aufgerufen werden, auch wenn das Dokument woanders hin verschickt wird. Und auf dem Dokumentenausdruck müsste unter dem Platzhalter für die Kundennummer, sofern er vorgesehen ist, immer wieder die gleiche Kundennummer ausgewiesen werden, auch wenn die Adressierung an eine Außenstelle erfolgt ...

Nun wäre es sinnvoll, wenn FAKTURAMA neben dem Adressfeld beispielsweise eine blinkende Meldung "Adress-Auswahl ?" einblendet, sofern es zu diesem Kunden/Debitoren mehrere Adressen gibt. Wenn der FAKTURAMA-Anwender diese Meldung bestätigt, sollte die zugehörige Adressliste zur Auswahl eingeblendet werden. Gibt es bei einem Kunden/Debitoren keine alternativen Adressen, so entfällt diese Meldung und Auswahl automatisch ...

In diesem Sinne könnte die Lösung beispielsweise aussehen :)o