Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 1/2012.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Konsolidieren Sie Rechnungs- und Lieferadressen zu einem einheitlichen Adressdatenstamm.

Techniken

Datenmodellierung, Abfragen

Voraussetzungen

Access 2000 und höher

Beispieldateien

Adressen.mdb

Shortlink

www.access-im-unternehmen.de/813

Liefer-, Rechnungs- und sonstige Adressen

André Minhorst, Duisburg

Eigentlich sollte man meinen, die Verwaltung von Liefer- und Rechnungsadressen ist kein großes Problem. In der Tat ergeben sich aber je nach Definition Probleme: Was ist beispielsweise, wenn die eine Datenbank Kundenadressen sammelt und bei Bedarf eine zusätzliche Rechnungsadresse aufnimmt, die andere neben den Kundenadressen eine Lieferadresse notiert? Und wenn Sie diese Daten dann noch in Rechnungsberichten verwenden oder zusammenführen möchten? Lesen Sie einfach weiter und tauchen Sie ein in die Probleme der Adressverwaltung - und ihre Lösung.

Je nach Art der Produkte oder Dienstleistungen, die Sie anbieten, benötigen Sie ganz unterschiedliche Adressdaten vom Kunden. Wenn Sie etwa nur Software entwickeln und diese als Download anbieten, reicht Ihnen die Rechnungsadresse des Kunden. Sollten Sie die Software hingegen in einer Box versenden, reicht die Rechnungsadresse nicht aus - Kunden haben ja manchmal verschiedene Adressen für Rechnungen und Lieferungen.

Das eingängigste Beispiel sind wohl größere Unternehmen, bei denen Sie das Produkt sofort zum Anwender schicken und die Rechnung direkt in der Buchhaltung landen soll. Im letzteren Fall gibt es verschiedene Möglichkeiten, die entsprechenden Adressen aufzunehmen:

  • Sie nehmen eine Adresse auf und bieten dem Kunden an, zusätzlich noch eine weitere Adresse als Lieferadresse anzugeben, wenn diese erste Adresse nicht gleichzeitig Liefer- und Rechnungsadresse ist.
  • Sie nehmen eine Adresse auf, bieten aber diesmal an, eine zusätzliche Rechnungsadresse anzugeben, wenn die erste Adresse nicht gleichzeitig Lieferadresse und Rechnungsadresse ist.
  • Sie nehmen grundsätzlich zwei Adressen als Liefer- und Rechnungsadresse auf. Sind beide identisch, kann die erste Adresse eingegeben und dann als zweite Adresse kopiert werden.

Für die spätere Verarbeitung ist die dritte Möglichkeit am einfachsten zu handhaben. Wenn Sie etwas versenden möchten, nutzen Sie einfach die Lieferadresse, und wenn Sie eine Rechnung schicken, nutzen Sie die Rechnungsadresse. Aber auch hier gibt es einen Haken: Wenn Sie Produkt und Rechnung nämlich gegebenenfalls gleichzeitig versenden möchten, müssen Sie erst prüfen, ob Liefer- und Rechnungsadresse gleich sind, und anderenfalls die Sendung doch wieder in Lieferung und Rechnung aufteilen.

Andersherum verwenden Sie bei der ersten Variante die erste Adresse in jedem Fall als Rechnungsadresse und prüfen dann, ob die zweite Adresse auch angegeben wurde. Falls nicht, geht die Lieferung an die erste Adresse, sonst an die zweite. Bei der zweiten Variante geht die Lieferung immer an die erste Adresse. Für den Rechnungsversand prüfen Sie die zweite Adresse und verwenden diese, falls vorhanden - sonst geht die Rechnung ebenfalls an die Lieferadresse.

Und richtig lustig wird es, wenn Sie mehrere Datenbanken verwenden, die zwei oder mehr der oben beschriebenen Varianten zum Speichern von Rechnungsdaten verwenden, und die Daten zusammenführen wollen.

Hintergrund

Wie in so vielen Fällen führte ein Beispiel aus dem echten Leben zur Erstellung dieses Beitrags. In diesem Fall verwendet der Autor selbst eine Datenbank, in der er für jeden Kunden eine Basisadresse pflegt (die im Zweifel als Rechnungs- und Lieferadresse dient) und in der zusätzlich eine alternative Rechnungsadresse eingetragen werden kann.

Während der Autor sich mit dem Import von Adressen, bei denen dies genau umgekehrt lief, herumärgerte, kam ihm die Idee, dass er womöglich einfach die falsche Methode gewählt hatte. Zu seiner eigenen Entlastung hat er daraufhin die Google-Probe gemacht, die folgende Ergebnisse für bestimmte Suchbegriffe ergab:

  • abweichende Lieferadresse: 448.000
  • abweichende Lieferanschrift: 337.000
  • abweichende Rechnungsadresse: 257.000
  • abweichende Rechnungsanschrift: 427.000

Allzu selten scheint der Einsatz einer abweichenden Rechnungsadresse im Vergleich zu einer abweichenden Lieferadresse also nicht zu sein ...

Begriffsklärung

In den folgenden Abschnitten tauchen wiederholt die Begriffe Stammadresse, Lieferadresse und Rechnungsadresse auf. In einer Tabelle, die immer eine Rechnungsadresse und eine Lieferadresse enthält (auch, wenn beide identisch sind), ist die Begrifflichkeit eindeutig. Wenn eine Tabelle grundsätzlich nur eine Adresse aufnimmt und eine weitere, wenn die Lieferadresse von dieser Adresse abweicht, heißt die erste Adresse Stammadresse und die zweite Adresse Lieferadresse. Genauso verhält es sich, wenn neben der ersten Adresse eine abweichende Rechnungsadresse angegeben werden kann.

Zusammenführen gemischter Adressen

Wenn Sie eine Datenbank verwalten, die ihre Adressen mit alternativer Rechnungsadresse pflegt, und die Daten einer anderen Datenbank hinzufügen möchten, welche die Daten mit alternativer Lieferadresse speichert, haben Sie mehrere Möglichkeiten.

Die einfachste ist die folgende: Sie duplizieren einfach überall die Adressen, wo keine Liefer- oder Rechnungsadresse angegeben ist (was immer die "abweichende" Adresse ist) und führen die Daten dann so zusammen, dass die Lieferadresse der zweiten Datenbank der Stammadresse der ersten Datenbank hinzugefügt wird und umgekehrt.

Das würde jedoch dazu führen, dass Sie eine große Menge redundanter Daten unterhalten: Wenn Liefer- und Rechnungsanschrift übereinstimmen, muss man diese ja theoretisch auch nicht doppelt pflegen.

Und wenn, dann sollten Sie zumindest ein Ja/Nein-Feld zur Kundentabelle hinzufügen, das angibt, ob die Lieferadresse mit der Rechnungsadresse übereinstimmt. Sie können dann bei Änderungen im Formular gleich prüfen, ob beide Adressen gleich sein sollen, und die Änderungen für den jeweils anderen Datensatz übernehmen. Wenn Sie hingegen weiterhin etwa die Stammadresse und eine optionale weitere Adresse wie etwa die Rechnungsadresse in Ihrer Datenbank verwalten möchten und die Stammadresse plus alternativer Lieferadresse aus einer anderen Datenbank importieren möchten, bedarf es einiger Fummelei beim Erstellen der für den Import benötigten Abfrage.

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

© 2003-2015 André Minhorst Alle Rechte vorbehalten.