|
| |
VB & Datenbanken| Tabellenstruktur für Rechnungen | |  | | Autor: Timon | | Datum: 27.09.06 14:02 |
| Hallo DB-Users,
ich bin in der Planungsphase einer Software für unseren Laden. Es geht um Fahrräder. Ich muss also Rechnungen sowohl für Neuräder (mit Zubehör, Rabatt, ...) und Reparaturen (Teile, Arbeiten, ...) machen bzw. speichern.
Wie Speichert man das am besten? 
Denn es soll immer möglich sein alte Rechnungen wiederherstellen zu können, aber laut den Normalisierungsformen müsste ich ja z.B. bei Reparaturen nur die Teilenummer und die Anzahl speichern. Dann stimmt aber der Preis nach einer Erhöhung nicht mehr.  Ein ähnliches Prob ergibt sich bei Neurädern. Dort kann es vorkommen, dass Artikel dazugegeben oder abgerundet werden. Es soll aber trotzem auf der Rechnung der Originalpreis mit erscheinen. Dadurch muss ich Anzahl, Einzelpreis, Endpreis speichern, was aber eigendlich wieder inkonsistenz hinter sich zieht. 
Mein erster Ansatz wäre, eine Tabelle Rechnung zu erstellen, in der Rechnungsnummer, Kunde, ... gespeichert ist und über eine 1:n Verbindung eine Tabelle mit den ganzen Zeilen (Zubehör, Rabatte, ...) angebunden wird.
Vieleicht könnt Ihr mich ja in die richtige Richtung bringen, da die Tabellenstruktur meineserachtens vor der Programmierung des Programms stehen muss.
Danke im vorraus,
Timon
PS: Ich hoffe es gibt noch ein paar Leute, die noch nicht alle Gehirnzellen auf der Wiesn ertränkt haben  | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: Prian0815 | | Datum: 27.09.06 14:22 |
| Also wenn du sämtliche alte Rechnungen wieder herstellen sollst, kannst du die Tabelle natürlich nicht mit der Preistabelle verknüpfen, das siehst du vollkommen reichtig. Du solltest jeden Preis schon hart reinschreiben.
tblRechnung:
RechId
KundenId' N:1-Verknüpfung mit Tabelle Kunden
ArtikelID'N:1 Verknüpfung mit Tabelle Artikel
Einzelpreis
BruttoPreis
Rabattbetrag
'NettoPreis
So in der Art könnte ich mir das schon vorstellen.
Dann dürfen die Artikelpreise geändert werden, wenn du den Preis direkt reinnimmst, die ArtikelID dient dann nur zur referenzierung auf die Artikelnummer mit Art-Name, -Typ, -Größe, usw.Die idee mit der Verknüpfung zu einer extra Rabatt-Tabelle ist bestimmt machbar.(Ob das aber Sinnvoll ist dafür eine extra Tabelle zu haben wage ich zu bezweifeln. Einen Warenrabatt kannst du eigentlich auch hart reinschreiben. Die Auswahl für diePreise, Rabatte usw, kannst du ja über ein ungebundenes Kombo lösen.Ich hoffe dir erin paar Ansätze geliefert zu haben. Bin ja auch kein Wiesn-Gänger.
Gruß Armin
P.S.: always look on the bright side of Life! | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: Timon | | Datum: 27.09.06 14:54 |
| Hallo Armin,
erstmal Danke für die schnelle Hilfe!
Das du Nur die Preise fest speicherst und die unwichtigeren Dinge in einer Extra-Tabelle machst gefällt mir grundsätzlich recht gut! Nur wie geht man dann vor, wenn ein Artikel nicht mehr hergestellt wird oder es eine neue Art.Nr. gibt? Lässt mann dann den Artikel einfach drinnen? (Bläht sich halt alles etwas auf)
Zum anderen ist diese vereinfachte Tabellenstruktur sinnvoll:
tblRechnung
RechnungsID 'Primärschlüssel
KundenID 'N:1 tblKunden
RechnZeilenID '1:N tblRechnungszeilen
Endpreis 'Zahl
tblRechnungszeilen
RechnZeilenID 'kann mehrfach gleiche ID vorkommen, da eine Rechnung mehrere
Zeilen haben kann.
Anzahl
ArtikelID 'N:1 tblArtikel
Preis
Ist dies so sinnvoll?
Danke,
Timon
PS: Mein Bruder heist zufällig auch Armin! | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: Prian0815 | | Datum: 27.09.06 15:52 |
| Gut, solche Fragen mußt du natürlich vorher abklären, soll es auch später(z.B. 2025) möglich sein verlässliche Abfragen für das Jahr 2006 auszuführen oder nicht. Wie oft ändern sich welche Attribute welcher Stammdaten? Diejenigen Attribute die einer häufigen Änderung unterliegen kannst du dann festin die Tabelle Rechnung schreiben, dadurch bläht sich diese Tab halt dann was Spaltenanzahl betrifft auf. Andererseits bläht sich die Stammdatentabelle Entitimäßig auf. Also als erstes abklären was dem Chef wichtig ist, dann entscheiden welche Daten wo gespeichert werden, was dann auch wieder von den zu erwartenden Zugriffen mit abhängig ist.Brauche ich oft einen select * from Rechnungen, schleppe ich vioel Daten mit mir rum. Habe ich viele Stammdatensätze(wenn Änderungen als neuer Satz gespeichert werden) muß das Prog bei verknüpften Abfragen länger suchen.
RechnZeilenID 'kann mehrfach gleiche ID vorkommen, da eine Rechnung mehrere
Zeilen haben kann.
Die ID würde ich nicht öfter vorkommen lassen, da die schon immer eindeutig sein sollte. Lieber dann ein Zusdatzfeld lfdPosten mit aufnehmen.Also
ID1 Rechnr.1 lfdPos1
ID2 Rechnr.1 lfdPos2
ID3 Rechnr.2 lfdPos1
ID4 Rechnr.2 lfdPos2
Ansonsten sieht dein GedankenEntwurf doch recht gut aus.
Gruß Armin
P.S.: always look on the bright side of Life! | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: Timon | | Datum: 27.09.06 16:19 |
| Hi,
Also mit der Tabellenstruktur muss ich glaub ich noch n paar Gehirnzellen aktivieren, aber ich bin dank dir schon mal n deutliches stück weiter. 
Ich hatte mir auch son mal überlegt, ob ich die alten Rechnungen alle als einzelne Textdateien auslagern soll (Dateiname als Nummer der RechnungsID), da sie nicht ständig benötigt werden, aber ich glaub dann kann man nur noch schlecht drauf zugreifen, und der Verwaltungsaufwand ist dann wohl auch nicht zu unterschätzen.
Somit erstmal vielen Dank, ich werd die nächsten Abende nomal alles durchdenken.
Danke,
Timon | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: srcdbgr | | Datum: 28.09.06 10:15 |
| Du könntest aber auch einfach eine eigene Tabelle für historische Rechnungen anlegen. Einmal erstellte Rechnungen werden nach Ausdruck zusammen mit einem Datum/Zeit-Stempel komplett in die Historientabelle übernommen. Damit vermeidest Du Inkonstistenzen und ungewollte Veränderungen.
[u]Vorteile:
- kein "rumgeeiere" mit Abhängigkeiten
- die Historie ist jederzeit unabhängig auswertbar
- Rechnungsversionen können mitgeführt werden (interessant bei Reklamationen und damit verbundenen nachträglichen Rechnungsänderungen)
- anhand des Datum/Zeit-Stempels erhält man einen Nachweis, wann ein Verkauf stattgefunden hat
[u]Nachteile:
- Änderungen in der Struktur der Produktivtabellen müssen in den Historientabellen mitgeführt werden, was einen höheren Pflegeaufwand bedeutet
- die Datenbank wird aufgrund der doppelten Datenhaltung aufgebläht
Ich habe mich bisher regelmäßig für Historientabellen entschieden, da aus meiner Sicht die Vorteile die Nachteile überwiegen. Musst Du aber entscheiden, ob das für Dich auch so ist.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. (Brian W. Kernighan) | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: Timon | | Datum: 29.09.06 07:24 |
| Hallo srcdbgr,
deinen Vorschlag finde ich auch sehr interessant, aber ich weiß nicht, ob ich dich richtig verstehe:
| Zitat: | |
- anhand des Datum/Zeit-Stempels erhält man einen Nachweis, wann ein Verkauf stattgefunden hat | |
Meinst du damit einfach eine Tabellenspalte in der das Datum gespeichert wird, oder ist das irgendwas besonderes?
| Zitat: | |
Einmal erstellte Rechnungen werden nach Ausdruck zusammen mit einem Datum/Zeit-Stempel komplett in die Historientabelle übernommen. | |
Das heist, nach z.B. dem Ausdrucken muss ich in meinem Programm in der Historientabelle den neuen Datensatz anlegen, und den in der aktuellen löschen, oder?
Vielen Dank für die Anregungen,
Timon | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: srcdbgr | | Datum: 29.09.06 09:26 |
| | Zitat: | |
Meinst du damit einfach eine Tabellenspalte in der das Datum
gespeichert wird, oder ist das irgendwas besonderes?
| |
Der Datum/Zeit-Stempel hat (bei mir) immer folgende Form:
yyyy.mmm.dd_hh:mm:ss_ID-Merkmal, also kein Datum-Feld sondern alphanumerisch. Ist so immer eindeutig sortierbar und außerdem leichter zu handhaben als ein Datum. Wenn ich ein Datum brauche, kann ich es mir bei Bedarf ja leicht wieder 'zusammenbauen'.
| Zitat: | |
Das heist, nach z.B. dem Ausdrucken muss ich in meinem
Programm in der Historientabelle den neuen Datensatz anlegen,
und den in der aktuellen löschen, oder?
| |
Das wäre eine Möglichkeit.
Die andere Möglichkeit (die ich bevorzuge): anstatt die aktuelle Rechnung vollständig zu löschen, stelle ich in den Datensatz den Datum/Zeit-Stempel als Schlüssel für den Zugriff auf die Historientabelle ein. Dann muss ich bei einem Kopiedruck nicht in der Historie suchen, sondern hole meinen Schlüssel direkt aus dem aktuellen Produktivbestand, packe ihn in eine WHERE-Klausel und picke mir die Rechnungsdaten aus der Historie heraus.
Also bspw.
"Zeige alle Rechnungen zu Kunde XYZ" ergibt eine Liste die so aussehen könnte:
Rechnungs-ID ... weitere Felder
R200600012 .... (= Rechnung, die in Bearbeitung und noch nicht gedruckt ist)
R200600011 ....
R200600010 ....
20060929_08:59:00_R200600009 ... (= bereits gedruckte Rechnung in der Historie)
20060927_13:27:45_R200600008 ...
Genau so verfahre ich mit Angeboten, Lieferscheinen, etc. wobei Angebote und Lieferscheine zusätzlich noch eine laufende Nummer und das Suffix 'A' bzw. 'L' erhalten. So kann ich bereits anhand des Schlüssels erkennen, worum es sich handelt und welche Dokumente zusammengehören. Bspw.:
A200600010
R200600010
L200600010
20060929_08:59:00_A200600009
20060929_08:59:00_R200600009
20060929_08:59:00_L200600009
Das System lässt sich auch ganz einfach mit Nummernkreisen kombinieren, um eine automatische Generierung der benötigten ID's zu erhalten. In der Stammdatenkonfiguration muss man sich dann nur noch um die Zuweisung der Nummernkreise kümmern. So lassen sich dann unterschiedliche Rechnungsarten verwalten - z.B. Rechnung mit oder ohne separate Ausweisung der MwSt., Rechnung für den Direktverkauf über Kasse, Rechnungen für den Verkauf auf Zahlungsziel, ProForma-Rechnung, etc. etc..... wie man's eben braucht. Anhand des Schlüssels weiss ich dann auch
- ob überhaupt gedruckt werden soll,
- welches Druckformular eingesetzt werden soll,
- welche Textbausteine verwendet werden sollen
- ....
Der Phantasie sind da (fast) keine Grenzen gesetzt.
Viel Spaß beim Ausprobieren.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. (Brian W. Kernighan) | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: Timon | | Datum: 29.09.06 19:17 |
| Vielen Dank für die äußerst ausführliche Antwort!
Darf ich noch kurz fragen, warum du den Schlüssel nicht in mehrere Felder aufteilst also z.B. in der Form:
Rechnungsnummer, Datum, Uhrzeit, Vorgangsart, ...
Denn so musst du es ja jedesmal zerlegen. Oder machst du das um es besser sortieren zu können?
Mfg
Timon | |
| Re: Tabellenstruktur für Rechnungen | | | | Autor: srcdbgr | | Datum: 02.10.06 09:46 |
| | Zitat: | |
Darf ich noch kurz fragen, warum du den Schlüssel nicht in
mehrere Felder aufteilst also z.B. in der Form:
Rechnungsnummer, Datum, Uhrzeit, Vorgangsart, ...
Denn so musst du es ja jedesmal zerlegen. Oder machst du das
um es besser sortieren zu können?
| |
Klar kann man den Schlüssel auf mehrere Felder aufteilen.
Aber ein wie oben beschrieben zusammengesetzer Schlüssel ist immer eindeutig, d.h. ein einziges Feld ergibt immer einen Unique-Index. Das erspart mir auch einfach Schreibarbeit und Daten-Konvertierungen bei der Erstellung von SQL-Strings. Außerdem ist der Schlüssel auf-einen-Blick für einen Menschen lesbar, wenn er die Systematik kennt; ich nenn das einen "sprechenden" Schlüssel. Ich kann so meinen Code auch nach Monaten lesen und auch wieder verstehen, was ich da gemacht habe Aber das ist letztlich eine Frage des Geschmacks und der persönlichen Gewohnheiten.
Und wie Du schon richtig feststellst ist eine Sortierung (und natürlich auch evtl. ein Filter) wesentlich einfacher.
Die Stringoperationen zum Erstellen/Aufteilen des Schlüssels bei Bedarf sind aufgrund der immer gleichen systematischen Zusammensetzung des Schlüssels sehr einfach in eine Public Function auslagerbar - also nur einmal Arbeit beim Erstellen der Funktionen und dann beliebig oft verwenden.
Mit Sicherheit gibt es andere gute Möglichkeiten ... aber so arbeite ich am liebsten.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. (Brian W. Kernighan) | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
sevISDN 1.0 
Überwachung aller eingehender Anrufe!
Die DLL erkennt alle über die CAPI-Schnittstelle eingehenden Anrufe und teilt Ihnen sogar mit, aus welchem Ortsbereich der Anruf stammt. Weitere Highlights: Online-Rufident, Erkennung der Anrufbehandlung u.v.m. Weitere InfosTipp des Monats Neu! sevDTA 3.0 Pro 
SEPA mit Kontonummernprüfung
Erstellen von SEPA-Dateien mit integriertem BIC-Verzeichnis und Konto- nummern-Prüfverfahren, so dass ungültige Bankdaten bereits im Vorfeld ermittelt werden können. Weitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.