Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Rechnungen in DB generieren

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von gurbelunder, 21 April 2012.

  1. gurbelunder

    gurbelunder Datenbank-Guru

    Hallo an alle,
    ich bräuchte mal eure Meinung zu folgendem Aufbau:
    Ich habe eine Datenbank in MySQL. Darin Tabelle Kunden und Tabelle Artikel. Nun möchte ich mittels meines PHP FrontEnds eine Rechnung erstellen. Diese soll aber später immernoch abrufbar sein, also Tabelle Rechnung her.
    In der Tabelle Rechnung speichere ich die Kundennummer aus Tabelle Kunden, die Artikelnummer aus Tabelle Artikel und die Menge des Artikels, die ich beim erstellen der Tabelle angebe. Insgesamt können 10 Artikel auf eine Rechnung (10x ArtNr, 10x Menge, ...). Beim eintragen des Datensatzes wird die Menge des Artikels in der Artikeltabelle um die eingegebene Menge herabgesetzt. Selbstverständlich mit Überprüfung, sodass der Wert nicht kleiner 0 werden kann.
    Ich möchte halt zum späteren Zeitpunkt auf Rechnung x zugreifen können, um diese erneut auszudrucken. Darum müssten die Artikel mit Menge 0 auch weiterhin vorhanden sein.
    Das gleiche Spiel gibt es mit Ankaufsquittungen. Nur hierbei wird die Menge nicht herabgesetzt, sie wird, logischerweise, addiert. Schließlich funktioniert ein Ankauf wie ein Einkauf in dem Sinne.

    Was haltet ihr von diesem Aufbau? Habt ihr eine bessere Idee für die Realisierung einer solchen "Rechnungstabelle"?

    Über Rat würde ich mich sehr freuen.
    Danke im vorraus

    David
     
  2. Walter

    Walter Administrator Mitarbeiter

    Der Teil, den ich verstehe, gefällt mir nicht. Und den anderen Teil verstehe ich nicht :D

    Was genau meinst Du mit Menge reduzieren? Welche Menge? Und wozu etwas reduzieren? Willst Du sozusagen den Lagerstand des Artikels im Artikelstamm speichern? Falls ja, schlechte Idee. Was, wenn es später mehrere Lagerorte gibt?

    Ein noch viel schlimmeres Problem hast Du mit Deiner Idee nur 10 Artikel in der Rechnung zuzulassen. Was, wenn dann jemand einen 11. Artikel bestellt? Stürzt dann Dein Programm ab oder der User bekommt eine Fehlermeldung "Leider wollen wir ihnen zwar gerne 11 Artikel verkaufen, aber das dumme Programm erlaubt das nicht"?
    Also brauchst Du eine Tabelle unterhalb der Rechnungstabelle, die Rechnungspositionen. Damit kannst Du dann unendlich viele Artikel verkaufen und sowohl Anwender wie auch Betreiber des Shops sind glücklich.
     
    PLSQL_SQL und ukulele gefällt das.
  3. gurbelunder

    gurbelunder Datenbank-Guru

    Ich meine selbstverständlich die Menge des Artikels, wie er vorhanden ist. Macht auch eher Sinn, wenn ich eine Tabelle mit Artikelstammdaten habe und eine zweite , die die Menge verknüpft mittels ArtNr aufweist. Ich muss aber auch gleich sagen: die Anwendung geschieht in einem kleinen An- und Verkaufsgeschäft. Da gibt es nur eine einzige kleine Filiale und dabei bleibt es definitiv auch. Sind grad mal zwei Mitarbeiter. Aber das hätte ich vorher schon mit erwähnen können, mein Fehler.

    Zu der Rechnungssache: ich hab in dem Geschäft bis jetzt noch keine. reachnung gesehen, die mehr als 4 Artikel aufgelistet hat. Daher die Begrenzungsidee auf 10 Stück. Aber dein Vorschlag klingt um einiges besser, weil ich ja viel flexibler bin.

    Danke schonmal für die schnelle Antwort. Wird mir sicher schonmal weiterhelfen.
     
  4. ukulele

    ukulele Datenbank-Guru

    Ich stimme Walter da zu, du brauchst mindestens eine Artikel Tabelle, in der Artikel nie gelöscht oder umbenannt werden. Sonst hast du irgendwann anders lautende Positionen auf deinen neu ausgedruckten aber alten Rechnungen. Der Lagerbestand gehört in eine eigene Tabelle. Die Rechnungen Tabelle und Rechnungspositionentabelle dürfen ebenso nur neue Daten aufnehmen aber alte nicht ändern, maximal irgendwie ein Storno Flag. Auch den aktuellen Kaufpreis solltest du in Rechnungspositionen mit aufnehmen, da dieser sich ja ändern kann (und eventuell im Bestand eine Preisspalte existiert die geändert werden muss).
     
  5. gurbelunder

    gurbelunder Datenbank-Guru

    Also soweit ist das schon klar. Nur begründe mal bitte, wieso ich keinen Verkaufswert in die Rechnungsposition eintragen soll? Ich wollte aus den Rechnungen eine Auswertung erstellen und außerdem ist es in dem Geschäft möglich, nen Rabatt zu bekommen. Der liegt aber dann nicht bei bestimmten Prozentsätzen, sondern wird "frei nach Nase" gegeben. Daher gibt es ja den Grundpreis in der Artikeltabelle, aber der in der Rechnung gilt...
     
  6. ukulele

    ukulele Datenbank-Guru

    Ich hatte auch geschrieben das du das in die Rechnungspositionen Tabelle aufnehmen solltest, grade aus diesem Grund. In der Artikel Tabelle kann ja der (sich ändernde) Basispreis stehen.
     
  7. gurbelunder

    gurbelunder Datenbank-Guru

    Sry, falsch verstanden. Vielen Dank für eure Hilfe, werd das mal bis zum Wochenende umsetzen. Danke euch!!!
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden