Kunden und Auftragsverwaltungs DB Grundsätze

[immanuel]

Hallo Zusammen

Ich mache mir Gedanken über eine Kunden- und Auftragsverwaltungs DB in Notes. Ich habe bereits eine DB, in der ich Kundendaten mit einer Maske verwalten kann. Nun möchte ich direkt in dieser Maske auch die Aufträge dieses Kunden verwalten, wie z.B. Bestellungen.

Habt ihr mir Tipps, wie ich vor gehen soll? Wie kann ich am besten die Eingabemaske und Ansicht von Aufträgen in die Kunden Maske einbettet?

Eventuell wäre mir auch eine Beispiel DB von euch hilfreich, dass ich Funktionalitäten ab gucken kann 

Danke für eure Tipps!

Grüsse
Manuel

[immanuel]

Hallo Zusammen

Ich habe ein kleines Projekt, das ich demnächst in Angriff nehmen werde. Ich möchte ein kleines ERP System weiter ausbauen und dabei die Kundenangaben von weiter in der Datenbank transformieren, so dass pro Auftrag ein bestehender Kunde ausgewählt werden kann.

Was gibt es hier für Bestpractices?
Meine nächsten Schritte werden vermutlich sein, ein Kundenangaben Formular zu erstellen und dann diese per Key/Delookup ins Auftragsformular einzubinden, so dass ein bestehender Kunde gewählt werden kann. Tricky könnte es bei den Serienbriefen werden, die ich per NotesSQL-ODBC in Word erstelle. Ich müsste im Serienbrief natürlich wieder Zugriff auf die Kundenadresse usw. haben.

Ich freue mich über eure Tipps.

Gruss
Manuel

[immanuel]

Hallo Zusammen

Wie können Kundendaten am besten in einer Datenbank verwaltet werden und dann in den jeweiligen Forms eingebunden werden? Ich suche Möglichkeiten, wie über Felder bestehende Kunden ausgewählt werden können und diese Daten dann in den anktuellen Autrag übernommen werden, bzw sie verknüpft werden. Dabei sollen die Daten natürlich nicht redundant gespeichert werden, sondern normalisiert.

Was ist state of the art, Subforms verwendne und diese über eine Combobox-Auswahl laden?
Wie wäre es mit einem Embedded Editor eine ein Kunden Form? Wie da jedoch der Link/Key zum aktuellen Record gemacht wird weiss ich nicht.

Ich freue mich über eure Vorschläge.

Grüsse
Manuel

[Driri]

Redundanzen haben den Vorteil, daß Du dir Lookups sparst. Nachteil ist ganz klar, daß man bei Änderungen in den Stammdaten dafür sorgen muß, daß diese auch in die zugehörigen Dokumente übertragen werden.
Das kann man allerdings recht einfach, wenn diese als Antwortdokumente angelegt sind. Dann kann man bei Änderung im Hauptdokument direkt alle Antworten updaten (DocCollection bilden und dann mit StampAll die betroffenen Felder schießen).

Ansonsten würde ich eine Subform anlegen und da die benötigten Felder für die Stammdaten reinpacken.
In einem zusätzlichen berechneten Feld holst Du dir per DBLookup die benötigten Werte.
Die anderen berechneten Felder holen sich per @Word aus der Werteliste den jeweils benötigten Wert.
Dafür brauchst Du natürlich irgendeinen Key (Kundennummer oder so was).

Für den DBLookup kannst Du eine gesonderte Ansicht anlegen, sortiert nach dem Key. In der zweiten Spalte werden dann die benötigten Werte als ein Textstring mit Trennzeichen versehen angezeigt (z.B. ~~ als Trennzeichen).

Der DBLookup liefert dann einen String zurück, z.B.

Meyer~~Gerd~~Herr~~etc. pp.

In den einzelnen berechneten Feldern der Subform wird dann der jeweils benötigte String per @Word ermittelt, z.B. für den Vornamen :

@Word(<Ergebnis DBLookup>; "~~"; 2)


Keine Ahnung, ob das State of the Art ist, aber es funktioniert und reduziert die Lookups in der Subform.

[Thomas Schulte]

Ingo hat recht. Das ist State of the Art (immer noch).
Und was die Rednundante Datenhaltung angeht. Die ist absolut sinnvoll in solchen Datenbanken denn, in Ansichten kannst du sonst zum Beispiel die Kundennummer und den Kundennamen im Auftragsheader nicht in der Ansicht ausgeben.

[immanuel]

Danke für die Antwort!

Ich bin es mir nicht so gewohnt alle Daten einzeln laden zu müssen. Da habe ich relationale Datenbanken schon lieber :-)

Schön würde ich finden, wenn Notes ein Key Handling für Subforms unterstützen würde...

Anstatt die daten einzeln holen zu müssen, würde ich glaub eine Embedded View mir single Category bevorzugen, wenn ich die Daten nur anzeigen müsste. Für Word Briefe muss ich dann aber die Stammdaten leicht in World geben können. Da sind echte Felder schon besser.

Grüsse
Manuel