Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Tabellenaufbau einer RechnungsDB Felddatentyp JA oder NEIN

Begonnen von hansdampf8, Juli 02, 2017, 21:24:36

⏪ vorheriges - nächstes ⏩

hansdampf8

Guten Morgen!

Zitatekkehard
ZitatWie willst du denn bei dem jetzigen Aufbau wissen welches Angebot zu
welcher Rechnung gehört und umgekehrt?
Danke für diesen Hinweis, so weiß ich das natürlich nicht.

ZitatKlaus
ZitatDu frägst hier um Rat, nimmst aber keinen an.
Würde ich keinen Rat annehmen wollen, würde ich wohl kaum um eure Meinung bitten.
Mein Problem ist nur die Umsetzung mancher Vorschläge und nicht das Wollen...

Wie soll ich Daten einer Rechnung erfassen bei der ich kein Angebot brauche wenn ich z.B. die tbl_Rechnungsdetail weglassen kann bzw. soll.
Sorry das verstehe ich nicht!

ZitatDer Rechnungsbetrag gehört in die Tabelle mit der Rechnung und nicht zur Mahnung. Ebenso das Zahlungsziel. Das Rechnungsdatum steht ja schon in der Rechnung, ist daher bei der Mahnung auch nicht notwendig. Auch der Fremdschlüssel zum Kunden (IDKunde_F) wird nicht benötigt.
Das werde ich entsprechend anpassen!

Gruß Hans


MzKlMu

Hallo,
ZitatWie soll ich Daten einer Rechnung erfassen bei der ich kein Angebot brauche wenn ich z.B. die tbl_Rechnungsdetail weglassen kann bzw. soll.
Sorry das verstehe ich nicht!
das habe ich doch schon in #5 geschrieben, mit Beispiel.

Es hindert Dich doch niemand daran die Daten für die Rechnung trotzdem als Angebot zu erfassen, auch wenn keines benötigt wird. Das geht doch keinen was an, wie Du das machst. Nenne die Tabelle "tbl_Angebot" doch "tbl_Erfassung" und die Tabelle "tbl_AngebotDtl" dann "tbl_ErfassungDtl".
(nur Namensvorschläge). Wenn die Erfassung zu einem Angebot wird, trägst Du das Angebotsdatum ein. Damit wird die Erfassung zum Angebot.
Damit ist die doppelte Datenhaltung eliminiert und Du kannst trotzdem alles unterscheiden.
Gruß Klaus

hansdampf8

Hallo!!

Hier der neue Entwurf der Tabellen. Das erstellen der Angebote und daraus folgende Rechnungen klappt nach diesen Schema wunderbar. (ohne doppelte Datenerfassung.)
Bei Angebotszustimmung erstelle ich in tbl_Rechnung einfach eine Rechnungsnummer, Rechnungsdatum und gebe die entsprechende IDAngebot_F Nummer ein.

Dennoch habe ich immer noch ein Verständnisproblem beim erstellen von Rechnungen ohne Angebot.
Nach diesem Schema muss ich ja eine Angebotsnummer vergeben um Rechnungen zu erstellen bzw. Positionen erstellen zu können.

Ich zweifle langsam selbst an mir! Irgendwo habe ich bei dieser Geschichte einen riesen Knoten im Kopf. :-\

Da ich dieses Vorhaben aber zu Ende bringen will, bleibe ich dran und muss euch weiterhin befragen.

Gruß Hans

MzKlMu

Hallo,
löse Dich doch einfach mal von dem Wort "Angebot". Nenne die Tabelle "tbl_Erfassung" (oder einen anderen Namen wenn Dir was besseres einfällt). Das Primärschlüsselfeld dann "IDErfassung" und das Fremdschlüsselfeld in der Positionstabelle dann "IDErfassung_F".
In die "tbl_Erfassung" (neuer Name) kommt noch ein Feld "AngebotNr" und ein Feld "AngebotenAm". Werden die Felder ausgefüllt, wird aus der Erfassung ein Angebot. In der Rechnungstabelle wird das Fremdschlüsselfeld auch zu "IDErfassung_F". Geht der Rechnung ein Angebot voraus sind die beiden Felder ( "AngebotNr", "AngebotenAm") ausgefüllt, ansonsten leer. Damit sind alle Spatzen gefangen.

Gruß Klaus

Lachtaube

In der Regel liegen immer gleichartige Daten bei den von Dir zu erfassenden Transaktionen (Vorgängen) vor, die entweder am Anfang oder am Ende der Kette (mehr oder weniger) optional sind.


       
  • Anfrage: ich will von Dir ein Angebot, das an einem Datum erstellt wurde, über 3 Brötchen, 2 Schxwarzwälder Kirschtorten und 4 Roggenbrote haben, ggf. mit Liefer- oder Abholdatum.
  • Angebot: entweder teilst Du mir mit, dass die Anfrage aus irgendwelchen Gründen nicht erfolgen kann, oder Du teilst mir an einem Datum mit, dass ich die 3 Brötchen, die 2 Torten und die 4 Brote am Datum x zu den jeweils angegeben Preisen abholen oder geliefert bekommen kann. Du teilst mir auch ggf. besondere Zahlungsbedingungen mit.
  • Bestellung: auf Grund des Angebots kann ich nun keine Bestellung auslösen, weil mir die Preise zu hoch sind, oder kein Lieferservice bereitgestellt wird, oder, oder. Stimme ich aber überein, bestelle ich an einem Datum die Sachen bei Dir. Ggf. reduziere ich dabei die ein oder andere Menge oder lasse eine oder mehr Sachen ganz weg.
  • Lieferung (oder Abholung): der Waren an einem Datum ggf. durch Auslieferfirma XYZ
  • Rechnungserstellung: mit ggf. Angaben zu Skonto, Rabatten, etc.
  • Zahlungseingänge: werden so lange verfolgt, bis der Betrag komplett beglichen ist.
  • Mahnungen: erfolgen bei Nichteinhaltung der Zahlungsbedingungen.
  • Reklamtationen: sollte man auch im Auge behalten.
  • Rchtsstreite: treten hoffentlich nicht ein.
Welche von den Punkten für Dich bei der Datenhaltung relevant (und erhaltenswert) sind, musst Du selbst entscheiden. So könnte man aus einem zu 100% akzeptiertem Angebot durch Überschreiben der Vorgangsart eine Bestellung machen. Gleiches gilt für Bestellung -> Rechnung. Will man aber die Zwischenschritte erhalten, so kann man durch Anfügeabfragen den Vorgang und anschließend die Details in die nächste Stufe befördern und dabei optional in der Vorgangstabelle einen Fremdschlüssel auf den vorherigen Vorgang setzen.

Zusammengefasst: ein Fremdschlüssel in der Vorgangstabelle bestimmt, welcher Schritt der Kette behandelt wird. Für alle Vorgänge wird die selbe Tabelle verwendet.
Grüße von der (⌒▽⌒)

hansdampf8

Danke an alle Mitwirkende!!

Bei mir ist wohl endlich der Groschen gefallen und das hat gedauert.
Meine Gedankengänge waren grundlegend falsch was den korrekten Aufbau einer Datenbank betrifft.
Mit diesem Schema der Tabellen funktioniert alles wunderbar und das sogar ohne doppelte Datenführung für Angebote u Rechnungen.. ::)

Nochmal ganz großen Dank für eure Geduld und Hilfe.

Hiermit würde ich dann das Thema Tabellenaufbau als GELÖST deklarieren.

Gruß Hans und weiter geht's.. ;)



Lachtaube

Hast Du keine Warentabelle? Welche Strategie besteht, wenn sich Steuersätze ändern?

Wenn ich das so lese, würde eine Erfassung mehrere Rechnungen erlauben?!
Grüße von der (⌒▽⌒)

hansdampf8

ZitatHast Du keine Warentabelle?
Wird für diese Datenbank nicht benötigt. Es handelt sich hierbei um ausführende Tätigkeiten die nie gleich sind.

ZitatWelche Strategie besteht, wenn sich Steuersätze ändern?
tbl_Steuersätze kann beliebig erweitert werden

ZitatWenn ich das so lese, würde eine Erfassung mehrere Rechnungen erlauben?!
Das stimmt, ich ändere den Fremdschlüssel noch auf 'ohne Duplikate'.

MzKlMu

Hallo,
ZitatDas stimmt, ich ändere den Fremdschlüssel noch auf 'ohne Duplikate'.
Weiter oben hast Du geschrieben, dass Abschlagsrechnungen erforderlich sind.
Daher muss entweder der Fremdschlüssel Duplikate zulassen, oder was besser wäre, Du erstellst eine weitere Tabelle zur Erfassung der Rechnungszahlungen mit einem Fremdschlüssel zur Rechnung.
Gruß Klaus

hansdampf8

ZitatWeiter oben hast Du geschrieben, dass Abschlagsrechnungen erforderlich sind.

Für Folgeaufträge oder Abschlagsrechnungen benötige ich keine Angebote.


Hier ist nur im Zusammenhang der Angebots u Rechnungstabellen bzw. Details Geschichte ein vielleicht nicht so glückliches Beispiel gefallen.

MzKlMu

#25
Hallo,
eine Abschlagrechnung hat ja mit Angeboten gar nichts zu tun. Ob da jetzt ein Angebot da ist oder nicht ist dazu nebensächlich.
Wenn Du zu einer Rechnung Abschlagszahlungen erfassen willst braucht ja eine solche Abschlagsrechnung einen Bezug entweder zur Erfassung, dann musst Du Duplikate zulassen oder zur Rechnung, dann ist aber für die eigentlichen Zahlungen einer Rechnung eine weitere Tabelle erforderlich die die Zahlungen erfasst, entweder die komplette Zahlung oder Abschlags/Teilzahlungen.
Du musst doch in der Lage sein, zu verfolgen zu kontrollieren was von einer Rechnung bezahlt ist und was noch zu bezahlen ist, völlig unabhängig von Angebot oder nicht.
Und dann kommt noch hinzu, die Mahnungen müssen sich auch auf Abschlags/Teilzahlungen Beziehungen können, das sind ja andere Zahlungsfristen. Und schon sind noch weitere Tabellen erforderlich und die Struktur muss geändert werden.

Wenn ich mich nicht irre, habe ich das so oder so ähnlich weiter oben schon mal geschrieben.

So kann das jedenfalls nicht bleiben, wenn Du Abschlags/Teilzahlungen zulässt. Das wird noch deutlich aufwendiger. Zu "einfach" hatte ich weiter oben auch schon mal was geschrieben.
Gruß Klaus

hansdampf8

Hallo!

ZitatSo kann das jedenfalls nicht bleiben, wenn Du Abschlags/Teilzahlungen zulässt.
Ich lasse keine Abschlags/Teilzahlungen zu.

Für meine Anforderungen reicht dieser Entwurf.

Nochmal vielen Dank für deine große Hilfe in dieser Angelegenheit!

Gruß Hans