Kundenumsatz errechnen und in DB Feld schreiben

[mania99]

Hey,
ich habe hier eine Access DB vorliegen, die sich um Kunden dreht, die Bestellungen aufgeben können.

Es gibt die u.a. Tabellen Lieferscheinkopf, Lieferscheindaten, Kundenstamm und Materialstamm. In der Tabelle Kundenstamm soll der Kundenumsatz gespeichert werden und nach jeder Bestellung über einen Button aktualisiert werden können. D.h. wenn ich einen Lieferschein erstellt habe, kann der Anwender auf einen Button klicken und der Umsatz dieses Lieferscheines wird auf das Umsatzfeld in der Tabelle Kundenstamm gebucht. (Da dies ein extra Mitarbeiter tun sollte, kann man hier nicht einfach den Umsatz über die Lieferscheine auslesen)

Ich habe es schon hinbekommen eine Abfrage zu erstellen die Kundennummer, Lieferscheinnummer und Gesamtumsatz des Lieferscheins richtig darstellt.

Der Gesamtumsatz wird allerdings über die Summenfunktion berechnet (da mehrere Artikel pro Lieferschein.) Wenn ich jetzt eine Aktualisierungsabfrage auf Basis dieser Abfrage erstelle, erhalte ich immer die Fehlermeldung "Operation muss eine aktualisierbare Abfrage enthalten"

Hat jemand eine Idee? Danke

[database]

Hallo,

Da dies ein extra Mitarbeiter tun sollte, kann man hier nicht einfach den Umsatz über die Lieferscheine auslesen

Ich will bestimmt nicht in eure Geschäftslogik besserwissend eingreifen - aber das ist schon ein bisschen humbugistisch oder? 

Summen, welche aus Einzelinformationen der Datensätze gewonnen werden sind NICHT in Tabellen zu speichern sondern bei Bedarf durch eine geeignete Abfrage/Bericht darzustellen.

Ich habe es schon hinbekommen eine Abfrage zu erstellen die Kundennummer, Lieferscheinnummer und Gesamtumsatz des Lieferscheins richtig darstellt.

Na, das ist ja schon ein guter wenn nicht sogar sehr guter Ansatz.
Wenn du nun auch noch einen Bericht dazu erstellst und diesen z.B. nach Kunden und Lieferscheinen gruppierst, beim Aufruf (denkbar) ein Startdatum angibst,
hast du eine brauchbare Übersicht und vergewaltigst dein Datenmodell nicht.
Aufrufparameter KÖNNEN natürlich auch eine LS-Nummer oder eine Kundennummer oder aber auch eine Kombination aus Datum und Kundennummer sein.

Wenn ich jetzt eine Aktualisierungsabfrage auf Basis dieser Abfrage erstelle, erhalte ich immer die Fehlermeldung "Operation muss eine aktualisierbare Abfrage enthalten"

Das ist normal - du verwendest ja auch eine Abfrage, die aus mehreren Tabellen zusammengestellt wird - und diese Abfrage ist nicht aktualisierbar.
Wenn du das schon unbedingt so haben willst, dann KÖNNTEST du das Abfrageergebnis in ein Recordset fassen oder die LS-Summe über die DSum-Funktion ermitteln und diesen Betrag
danach per SQL in den richtigen Datensatz der Zieltabelle aktualisieren.

[Wurliwurm]

D.h. wenn ich einen Lieferschein erstellt habe, kann der Anwender auf einen Button klicken und der Umsatz dieses Lieferscheines wird auf das Umsatzfeld in der Tabelle Kundenstamm gebucht. (Da dies ein extra Mitarbeiter tun sollte, kann man hier nicht einfach den Umsatz über die Lieferscheine auslesen)

Ich glaube, mit der Lösung wirst Du nicht glücklich. Zwar ist die Aussage des Vorschreibers im kategorischen Imperativ nicht richtig, daß "man" niemals aggregierte Werte zusätzlich zu den Einzelinformationen speichern darf (wenn in der Bank Dein Kontostand aufgerufen wird, dann wird sicherlich ein einzelnes Feld ausgelesen und nicht die Buchungen aggregiert). Aber in Deiner kleinen Access-Anwendung könntest Du wahrscheinlich nur schwer verhindern, daß der "extra Mitarbeiter" vielleicht mehrmals auf den Button klickt, und dann der Umsatz in der Stammsatztabelle falsch ist.

Nachdem es wahrscheinlich (für einen Laien) nicht so schnell und leicht umsetzbar ist, die Umsatzaktualisierung über Funktionen und Transaktionen zu realisieren, denke ich, der folgende Vorschlag ist einfach und würde die richtigen Zahlen ausgeben:

Führe im Bestellkopf einen Flag ein (Datentyp ja/nein) und nenne ihn "gebucht" oder so ähnlich. Lege außerdem eine Abfrage an, wo der Bestellkopf mit den Bestellpositionen verknüpft ist, Artikelwert aggregiert wird und wo das Feld "gebucht" im Bestellkopf den Wert "WAHR" haben muß. Dann hat Du den Umsatz pro Kunde.

Wenn der "extra Mitarbeiter" die Bestellung freigibt, dann wird mit dem Klick der Wert "gebucht" auf "WAHR" gesetzt und der Umsatz erhöht sich.

[database]

Hallo,

ich habe nicht geschrieben, dass 'man' NIEMALS aggregierte Werte im Zusatz speichern darf ... zumindest lese ich das nicht in meiner Antwort.

wenn in der Bank Dein Kontostand aufgerufen wird, dann wird sicherlich ein einzelnes Feld ausgelesen und nicht die Buchungen aggregiert

Das kann ich mir für den Fall eines 'normalen' Kontoauszuges nicht vorstellen.
Aber egal ...

[Wurliwurm]

Das kann ich mir für den Fall eines 'normalen' Kontoauszuges nicht vorstellen.

Bei jedem Kontoauszug braucht man unbedingt einen Anfangssaldo. In der Banken-IT gibt es dazu neben den Einzelbuchungstabellen mindestens noch aggregierte Tabellen pro Monat/Jahr, wo auch der Anfangssaldo pro Periode fortgeschrieben wird. Wenn einer mit seiner EC-Karte gekauft, wird aber nur der Kontostand gebraucht, um zu wissen, ob Deckung vorhanden ist, und selbiger wird in einem Feld pro Konto gespeichert und nicht erst aggregiert berechnet, wenn man ihn braucht (aus Performancegründen).

Analog verhält es bei Warenwirtschaftssystemen, Buchungssystemen etc. Wenn Du Dir das nicht vorstellen kannst, dann hast Du eben keine Vorstellung von großen Systemen. Egal, brauchst Du ja nicht.

[database]

Hi,

gibt es dazu neben den Einzelbuchungstabellen mindestens noch aggregierte Tabellen pro Monat/Jahr

...könnte natürlich das ausdrücken was ich, entgegen deiner Aussagen, nicht kategorisch ausgeschlossen habe.

Aber abgesehen davon gehen mir dein unnötigen Seitenhiebe nach mir ziemlich auf den Keks.
Wenn du ein Problem hast, solltest du es vielleicht behandeln lassen - ich für meinen Teil habe kein Interesse mich ständig von dir anflegeln zu lassen.

Diese Art von Unterhaltung ist erstens hier vollkommen unangebracht und hilft auch wohl kaum jemanden.
Wenn du das Bedürfnis hast deine unterdrückten Triebe in unflätigen Bemerkungen gefaßt unters Volk zu bringen
solltest du dir eine Umgebung suchen wo dies an der Tagesordnung steht und so auch niemanden stört.

Hiermit sehe ich die 'Unterhaltung' mit dir als beendet

[mania99]

Hallo,

erstmal vielen Dank für eure Anregungen.
Der Grund warum ich diese Information in die DB schreiben möchte liegt in der Vorgabe unseres Dozenten (die DB ist sozusagen ein BWL-Studienprojekt). Genauso wird z.B. mit dem Lagerbestand verfahren. Sinn dahinter ist es den "realen" Kundenumsatz bzw. Lagerbestand zu erhalten. Also erst mit Auslieferung wird der Umsatz realisiert und der Lagerbestand geht runter. Daher soll erst der Lagermitarbeiter die Buchung auslösen.
Bei der Berechnung des Lagerbestandes hatte ich aber keine Umsetzungsprobleme, da hier wohl auch nicht summiert wird.

Bei der Lagerabbuchung habe ich das schon mit dem Feld "abgebucht" vom Typ JA/NEIN umgesetzt, d.h. es wird so verhindert, dass ein Mitarbeiter den Bestand bzw. dann auch den Umsatz zweimal bucht. Die Lösung läuft auch wunderbar für den Lagerbestand.

Führe im Bestellkopf einen Flag ein (Datentyp ja/nein) und nenne ihn "gebucht" oder so ähnlich. Lege außerdem eine Abfrage an, wo der Bestellkopf mit den Bestellpositionen verknüpft ist, Artikelwert aggregiert wird und wo das Feld "gebucht" im Bestellkopf den Wert "WAHR" haben muß. Dann hat Du den Umsatz pro Kunde.

Sehe ich das also richtig, dass es keine (einfache) Option gibt den Kundenumsatz in der Kundentabelle zu speichern und jedes mal zu aktualisieren? Wir haben hier in der Vorlesung auch noch nie was mit einem Recordset(?) zu tun gehabt, dementsprechend denke ich nicht dass dies verlangt wird.
Wir haben nämlich leider in der DB-Struktur (die wir übernommen haben) dieses Feld schon integriert, was mich verwirrt.

Danke für eure Hilfe schonmal!

[Wurliwurm]

Der Grund warum ich diese Information in die DB schreiben möchte liegt in der Vorgabe unseres Dozenten (die DB ist sozusagen ein BWL-Studienprojekt).

Hättest Du gleich schreiben sollen, das läßt nämlich die ganze Sache in einem anderen Licht erscheinen.

Also erst mit Auslieferung wird der Umsatz realisiert und der Lagerbestand geht runter. Daher soll erst der Lagermitarbeiter die Buchung auslösen.

In realen ERP-Systemen werden dadurch neue Buchungen ausgelöst. Sprich es gibt ursprünglich eine Kundenbestellung (Kopf/Positionen). Bei Auslieferung wird ein Warenbeleg erzeugt (extra Tabellen mit Kopf/Positionen), außerdem wird ein Finanzbeleg (Buchungssatz, extra Tabellen mit Belegkopf/Belegzeilen) erstellt. Das ganze ist sehr kompliziert in realen Systemen, in SAP ist da so kompliziert, daß das kein Mensch allein mehr überblickt.

Sehe ich das also richtig, dass es keine (einfache) Option gibt den Kundenumsatz in der Kundentabelle zu speichern und jedes mal zu aktualisieren? Wir haben hier in der Vorlesung auch noch nie was mit einem Recordset(?) zu tun gehabt, dementsprechend denke ich nicht dass dies verlangt wird.

Wenn in der Studienarbeit ein kleines Modell für ein ERP-System gemacht werden soll, dann geht das nicht ohne Programmierung (sprich es geht nicht über gebundene Formulare und Formelassistent). Ein Recordset ist nichts anderes als die Repräsentation einer tabellenartigen Struktur im Hauptspeicher (es ist das Ergebnis einer Abfrage), welche in Schleifen bearbeitet werden kann (mit Schleifen ist Berechnungsvollständigkeit ~Turing-Vollständigkeit erreicht, was SQL allein nicht kann)

Jetzt weiß ich nicht, ob die Vorlesung eine Einführung in die Programmierung beinhalten soll, ob sie einen Einblick in Datenmodellierung sein soll oder in Datenbanktechnik oder nur einen Geschmack für ein ERP-System vermitteln soll oder vielleicht alles auf einmal.

Natürlich gibt es Möglichkeiten, das im kleinen Rahmen in Access zu simulieren, aber wie gesagt, es geht nicht ohne Programmierung (so sehe ich das jedenfalls vorläufig). Ich kann Dir gerne helfen und auch sicher andere, aber am besten wäre es, wenn Du eine Beispieldatenbank hochladen würdest, damit man sehen kann, wie das mit dem Lagerbestand realisiert hast.

Grüße
Johannes

[mania99]

Hallo,
sorry dass ich die Info bezüglich des Studienprojektes vergessen habe.

Ich werde mal unseren Dozenten befragen wie er es denn gerne hätte weil ich habe deinen Vorschlag mit der Abfrage so umgesetzt und er läuft einwandfrei. Habe irgendwie vorher nicht drangedacht dass man einfach das Feld "abgebucht" als Kriterium mit aufnehmen könnte...

Also richtig geht es jetzt aufjeden Fall mal :-)

Ich melde mich wieder bei Fragen. Danke für die Hilfe!!

[mania99]

// Edit: Mein Problem hat sich gerade gelöst :-)