Hallo zusammen!!
Bevor ich mich auf mein nächstes Hobbyprojekt stürze würde ich gerne ein paar Meinungen von euch einholen.
Es geht dabei um eine ganz einfach gehaltene Rechnungsdatenbank inkl. Angebot und Mahnschreiben.
Für jede Sparte(Rechnung,Angebot u Mahnung) gibt es 2 Tabellen, einmal die Kopfdaten und die Detaildaten. In den Kopfdaten befindet sich das Feld blnUSt vom Datentyp Ja/Nein(Boolean) um festzuhalten, ob es hier mit oder ohne Umsatzsteuer weiter geht.
Mein erster Ansatz war alle Tabellen doppelt anzulegen um eine direkte Trennung zwischen umsatzsteuerbefreit und umsatzsteuerpflichtig zu haben und dann kam mir die Idee mit dem Feld blnUSt.
Das möchte ich dann einfach per Klick anwählen und entscheiden ob USt ja oder nein. Beim Klick müsste natürlich im Formular und im Bericht die richtige Zuordnung erfolgen. Im Formular sollte bei Ja ein Feld USt erscheinen und die richtige Berechnung auslösen.
Leider komme ich momentan einfach nicht weiter bzw welchen Ansatz soll ich sinnvoller Weise verfolgen? (und wie spreche ich das Boolean Feld an)
Viele Grüße
HansDampf8
Hallo,
das würde ich nicht so machen. Die Umsatzsteuer unterliegt ja auch Veränderungen über der Zeit. Ich würde da eine Tabelle anlegen für die verschiedenen Umsatzsteuerwerte und nur einen Fremdschlüssel in der Rechnung speichern. Die Umsatzsteuertabelle sollte auch einen Datensatz haben mit dem Umsatzsteuerwert 0%. Die Berechnungen der Steuer sind dann immer gleich. 0% = 0€ Steuer.
Es muss auch noch beachtet werden, dass verschiedene Posten auf der Rechnung unterschiedliche Umsatzsteuersätze haben könnten.
Hallo Klaus,
ich hab vergessen zu erwähnen, dass ich eine Tabbelle 'Steuersätze' angelegt habe um zwischen den verschiedenen Steuersätzen wählen zu können. Und natürlich noch eine Tabelle Kunden.
Welchen Ansatz für den weiteren Aufbau würdest du nehmen? Die Tabellen einmal mit USt und alle einmal ohne USt oder hinter jeder Rechnungsnummer und Angebotsnummer das Kontrollkästchen für USt JA oder NEIN?
Ich füge mal einen ersten Ansatz der DB an um es vielleicht besser zu verdeutlichen.. Ich habe manchmal Schwierigkeiten mit der richtigen Formulierung meiner Probleme.
Hallo,
Die Berechnung der USt. ist ja von verschiedenen Faktoren abhängig.
1. Vom Lieferort (z.B. Drittländer -keine USt.)
2. Status des Belieferten (Konsument, Zwischenverkauf, vorhandene UStID)
3. Artikel (Steuersatz).
Ich habe das bei mir also als Ja/Nein-Feld beim Kunden, und als FK beim
Artikel (so wie von Klaus angemerkt).
Bei einem Kunden ohne USt. bleibt dann der Steuersatz beim Artikel
unberücksichtigt.
gruss ekkehard
Hallo Hans,
ZitatDie Tabellen einmal mit USt und alle einmal ohne USt
Auf keinen Fall, es reicht wenn du den Nettopreis in einer Tabelle hast.
Die USt.-Berechnung (Bruttopreis) erfolgt dann auf den Belegen anhand
des Steuerschlüssels.
gruss ekkehard
Hallo,
ich würde das dann doch etwas anders machen. In die Tabelle mit den Steuersätzen kommt ein Datensatz mit dem Steuersatz 0%, der dann bei Kunden ohne Steuer verwendet wird. Kein KK für Ust Ja/Nein, das ist dann überflüssig. Hatte ich oben schon geschrieben.
Weiterhin sollte ja das Angebot und die daraus folgende Rechnung gleich sein. Dann wird in der Rechnungstabelle nur ein Fremdschlüssel zum Angebot geführt. Ändert sich das Angebot, wird entweder das Angebot geändert, oder ein neues Angebot erstellt um die Historie zu erhalten.
Die Tabelle "tbl_RechnungDtl" entfällt dann ersatzlos.
Was kommt den in die Tabelle Stammdaten ?
Die ist nicht im Beziehungsbild ?
Und beachte die Anmerkungen von ekkehard und mir zur Umsatzsteuer, die ja auch vom Artikel abhängig sein kann.
Gibt es keine Tabelle für die Waren die Du verkaufst ?
Und noch eine Anmerkung zu den Präfixen vor den Feldnamen. Die sind so überflüssig wie ein Kropf und erschweren Dir nur die Arbeit, sonst nix. Dass das AngebotDatum ein Datum ist, erkennt man auch ohne das dat. Du hast die Menge als sng (Single) Zahl, hast Du wirklich Kommazahlen als Menge ?
Und da beginnt dann schon die Problematik, das willst/musst Du ändern in int, Wenn Du konsequent bist, musst Du das jetzt machen und alles ändern (und suchen wo was zu ändern ist) jedes Formular, Abfrage, Bericht, VBA Code einfach überall muss das jetzt geändert werden. Wenn die DB fortgeschritten ist, wird das recht mühsam und es geht nicht alles automatisch. Wenn die Autokorrektur ausgeschaltet ist, gar nix. Das Feld mit dem Einzelpreis muss auch geändert werden, sng ist viel zu ungenau, das gibt Rundungsprobleme ohne Ende. Währung wäre da einzustellen. Single ist meist völlig unbrauchbar, besonders wenn mit Zahlen gerechnet wird. Und auf das Prozentformat würde ich auch verzichten. Da wird nämlich die Zahl im Hintergrund als 0,19 gespeichert, was im weiteren Verlauf mehr Ärger macht als nutzt, Nimm eine Ganzzahl und trage 19 bzw. 7 ein, ohne Prozent, die macht man später dazu.
An die Fremdschlüssel hängt man ein _F an und verwende keine Sonder und Leerzeichen in Feldnamen.
Im Anhang mal die umgerüstete DB, ohne Anspruch auf Vollständigkeit. Und die Stammdaten musst Du mal noch erklären.
Guten Morgen und vielen Dank für eure Antworten.
Ich schaue mir den Entwurf heute Nachmittag in Ruhe an und kläre dann gerne die Bedeutung der tbl_Stammdaten auf.
Alles nicht so einfach und ich habe noch einiges an Grundwissen nachzuholen.
Schönen Wochenstart und bis später..
Gruß Hans
Hallo Klaus,
ZitatKein KK für Ust Ja/Nein, das ist dann überflüssig.
Muss dir da Recht geben, inzwischen gibt es ja auch ausländische USt. mit
abweichenden %ten, die man u.U. beachten muss. Daran hatte ich nicht
gedacht.
gruss ekkehard
Hallo und guten Abend!
Ich versuche jetzt mal das ganze Projekt etwas genauer zu beschreiben und die gewollte Einfachheit der DB darzustellen.
Es soll eine wirklich einfache Rechnungsdatenbank mit Angebot, Mahn- u. Rechnungslegung sein. Und hier meine ich wirklich einfach. Es wird u werden keine Artikel vorgegeben und alles bezieht sich auf einen USt.-Satz. (kein Ausland, keine Briefmarken- werden nicht versteuert, keine Lebensmittel u.s.w. )
Alles in den Rechnungsdetails wird händisch eingetragen und kann frei formuliert werden. Im Feld Menge werden manchmal Kommazahlen benötigt. z.B. 25,8 lfm beim einsetzen von Hauseingangstüren
Des Weiteren muss nicht automatisch für jede Rechnung ein Angebot geschrieben werden. Somit brauche ich unbedingt die Tabellen für Angebote und Rechnungen inkl. der Tabellen Angebot- u. Rechnungs-Details.
Für Folgeaufträge oder Abschlagsrechnungen benötige ich keine Angebote.
Die Tabelle Stammdaten soll das ganze Projekt unabhängiger und flexibler für den späteren Nutzer machen. In diese Tabelle werden alle relevanten Firmendaten und gegebenfalls ein Logo eingeflegt. Somit muss man nicht alle Berichte später händisch ändern. Alle Werte werden dann per DOM Anweisung in die korrekten Felder eingetragen bzw automatisch übernommen.
Danke für den Tip mit den Fremdschlüssel _F , dass werde ich in Zukunft so machen. Die Präfixe habe ich laut Namenskonvention für Access verwendet und dachte das ist wichtig und richtig so??
Angedachte Tabellen sollen sein:
tbl_Kunden
tbl_Stammdaten(Daten der Firma)
tbl_Angebot u. tbl_AngebotDtl
tbl_Rechnung u. tbl_RechnungDtl
tbl_Mahnung u. tbl_MahnungDtl
tbl_Steuersatz(falls der sich mal ändert, oder wir doch einen anderen brauchen)
Nun noch kurz zu meinem eigentlichen Problem mit der USt.
Wie halte ich Rechnungen mit und ohne USt. strikt getrennt bzw. vermerke das sie ohne oder mit Steuer sind. Und drucke dann natürlich auch den richtigen Bericht aus.
Meine Lösung wäre wie schon erwähnt, alles doppelt anzulegen. Einmal alles mit USt und einmal ohne. Bezieht sich natürlich nur auf Angebote und Rechnungen, Mahnungen und Kunden brauchen das ja nicht.
Ich konnte einfach nicht das KK abfragen per VBA um eine entsprechende Aktion auszugeben.
z.B. KK ist True dann soll im Formfuß die USt. berechnet werden und der Bericht mit USt Gedöns gewählt werden.
Gruß Hans
Hallo,
ZitatEs soll eine wirklich einfache Rechnungsdatenbank mit Angebot, Mahn- u. Rechnungslegung sein. Und hier meine ich wirklich einfach.
das kannst Du mal gleich vergessen, das wird mit Sicherheit keine einfache Datenbank, im Gegenteil mit Deinen Anforderungen und einem datenbankkonformen Aufbau wird das ziemlich kompliziert werden.
ZitatIm Feld Menge werden manchmal Kommazahlen benötigt. z.B. 25,8 lfm
Dann verwende als Datentyp Double, Single ist für Zahlen mit Berechnungen unbrauchbar.
ZitatSomit brauche ich unbedingt die Tabellen für Angebote und Rechnungen inkl. der Tabellen Angebot- u. Rechnungs-Details.
Nein, das solltest Du unbedingt vermeiden. Das würde ja bedeuten, wenn ein Angebot vorliegt musst Du die Daten 2x erfassen. Das widerspricht bereits den grundlegenden Datenbankregeln. Was hindert Dich daran, auch wenn kein Angebot verlangt wurde/erforderlich ist, die Daten trotzdem als Angebot zu erfassen ?
Es ist doch egal, wo die Daten für die Rechnung erfasst werden.
Daher vergiss das mit den getrennten Tabellen, es wäre ein grober Fehler.
ZitatFür Folgeaufträge oder Abschlagsrechnungen benötige ich keine Angebote.
Auch die Folgeaufträge erfasst Du intern als Angebot.
Wie ist das mit den Abschlagsrechnungen, sind das auch Positionen oder wird da einfach von der Gesamtsumme ein Teilbetrag in Rechnung gestellt. Für Abschlagsrechnungen die ja auf einer Hauptrechnung beruhen ist in jedem Fall eine extra Tabelle notwendig mit einem Fremdschlüssel zur Hauptrechnung.
Die Stammdatentabelle habe ich immer noch nicht ganz verstanden, was ist denn der Unterschied zwischen der Kundentabelle und den Stammdaten, sind das nicht die Kunden ?
Zitatund gegebenfalls ein Logo
Das mit dem Logo solltest Du vermeiden, allenfalls als exteren Bilddatei die denn bei Bedarf angezeigt wird. aber das Logo nicht in der DB speichern.
ZitatAlle Werte werden dann per DOM Anweisung in die korrekten Felder eingetragen bzw automatisch übernommen
Wozu Dom (das ist eine Datenbankbremse), Du brauchst doch keine DOM Anweisung zum Füllen der Felder, Formulare und Berichte werden an die Tabellen/Abfragen gebunden und fertig.
ZitatDie Präfixe habe ich laut Namenskonvention für Access verwendet und dachte das ist wichtig und richtig
Bei den Feldnamen (und nur dort) sind die Präfixe aus den genannten Gründen nicht zu empfehlen.
Zitattbl_MahnungDtl
Was willst Du in dieser Tabelle erfassen, eine Mahnung bekommt nur einen Bezug zur Rechnung, Details braucht es da nicht.
Was die Ust betrifft, löse Dich von dem KK es ist überflüssig. In meinem Beispiel findest Du einen Eintrag "Ohne Steuer" mit 0% und der wird bei ohne Ust ausgewählt.
Da die Steuer ja über den Prozentsatz errechnet wird, ergibt sich bei 0% automatisch 0€ Steuer. Bzw. bei "Ohne Steuer" wird nicht gerechnet.
Die Felder mit 0 werden im Bericht einfach ausgeblendet. Da braucht es kein extra KK, vergiss es. Und schon gar nicht 2 Tabellen (mit und ohne Ust.). Auch den Rechnungsbericht gibt es nur 1x, die Auswahl des Steuersatzes bestimmt was im Bericht zu sehen ist.
Und beachte noch meine Hinweise zu den Datentypen und das %-Format solltest Du auch vermeiden.
Hallo Klaus und erstmal danke für deine ausführliche Antwort und für die Zeit, die du investierst.
Ich glaube jetzt auch das Vorhaben wird wohl wirklich nicht so einfach und eher in Richtung sehr kompliziert gehen.
Trotzdem werde ich das Projekt umsetzen bzw. ich werde auf auf jeden Fall versuchen.
Um erstmal in Gang zu kommen benötige ich aber noch bissl Input bzw. habe Klärungsbedarf.
ZitatDann verwende als Datentyp Double, Single ist für Zahlen mit Berechnungen unbrauchbar.
Sehe ich ein und werde es dankend befolgen.
ZitatSomit brauche ich unbedingt die Tabellen für Angebote und Rechnungen inkl. der Tabellen Angebot- u. Rechnungs-Details.
Nein, das solltest Du unbedingt vermeiden. Das würde ja bedeuten, wenn ein Angebot vorliegt musst Du die Daten 2x erfassen.
Hier habe ich ein wenig Bauchschmerzen.
Ich verstehe schon, dass sich aus einem genehmigten Angebot eine Redundanz entwickelt bei Rechnungslegung und separater Tabellen für Angebot und Rechnung.
Aber wie halte ich dann Rechnungen und Angebote getrennt voneinander? Und brauche ich für einen Auftrag kein Angebot wäre es doch irreführend die Daten bei Angebot einzugeben. Quasi müsste man ja grundsätzlich Daten eingeben und danach entscheiden ob dies eine Rechnung oder ein Angebot wird. ODER habe ich hier einen komplett falschen Denkansatz??
ZitatDie Stammdatentabelle habe ich immer noch nicht ganz verstanden, was ist denn der Unterschied zwischen der Kundentabelle und den Stammdaten, sind das nicht die Kunden ?
In die Stammdaten sollen die eigenen Firmendaten rein.(Bankverbindung, Name, Firma u.s.w.)
Somit brauch man diese Daten später bei Weitergabe der DB an eine andere Firma der sie für seine Rechnungslegung nutzen möchten nur in der Tabelle tbl_Stammdaten ändern und nicht mühsam in den Berichten und Co.
Anbei ein Bild zur Verdeutlichung.
Ich stelle mal ein Tabellenlayout fertig und reiche es hier zur Begutachtung ein. Damit wir mal was haben zum ändern.
Viele Grüße Hans
Hallo,
Zitat
Hier habe ich ein wenig Bauchschmerzen.
Ich verstehe schon, dass sich aus einem genehmigten Angebot eine Redundanz entwickelt bei Rechnungslegung und separater Tabellen für Angebot und Rechnung.
Naja, der Vorschlag von Klaus ist ja nun einer von mehreren möglichen...
Wie genau das aussehen soll, musst Du anhand der gegebenen Arbeits- und Datensituation selbst herausfinden, bzw. definieren.
Denkbar ist natürlich auch, für Angebote, Bestellungen und Rechnungen(+ Lieferscheine) separate Tabellen (mit je ihren Positionstabellen) zu erstellen. Als "Workflow" , mit z. B. einem Button "Buchen" werden dann mittels Anfügeabfragen die relevanten (nötigen) Daten aus z. B. der Tabelle "tblBestellungen" in "tblRechnungen" übertragen. Dabei sind evtl. Status-Felder zu berücksichtigen. Das hat den Vorteil(?) dass auch ohne Bestellung eine Rechnung von Hand erzeugt , bzw. ein von einer Bestellung herrührende Rechnung individuell erweitert werden kann. Zudem können sich zeitlich änderbare Werte (z. B. Produktpreis) fest abgelegt werden. Eine Rechnung darf zudem, nachdem sie "gebucht" (als gültig definiert) wurde, nicht mehr änderbar sein.
Inwieweit solche Arbeitsabläufe eine Rolle spielen müssen, ist von Dir anhand der aktuellen Arbeitssituation abzuklären.
Hallo zusammen!!!
Hier meine Rückmeldung zum Tabellenlayout. Ich werde die Datenbank nach diesem Schema anfertigen obwohl das nicht die eleganteste Lösung in euren Augen sein wird.
In einigen Wochen und nach noch viel mehr Stunden mit Kopfschmerzen wegen anstehender Accessproblemen wird mein KnowHow weiter wachsen und dann sehe ich die Dinge vielleicht anders.
Das KK werde ich auch belassen und es wird mir als apsrechbares Element für VBA dienen. Über das KK werde ich im UFO un im HF je nach Wert die Anzeigen der USt einblenden oder ausblenden lassen. (der Optik halber)
Auf jeden Fall wird die Fertigstellung wesentlich mehr Zeit in Anspruch nehmen als gedacht und hier werde ich garantiert noch die eine oder andere Frage stellen.
Wer Lust hat, kann sich ja kurz zu den Tabellen äußern.
Viele Grüße Hans
Hallo,
wie bereits gesagt, halte ich den Aufbau für falsch um nicht zu sagen unbrauchbar. Du betreibst doppelte unnötige Datenhaltung mit dem Aufwand auch Daten doppelt eingeben zu müssen. Und das KK ist auch überflüssig, bei korrektem Aufbau kann man das alles optisch unterscheiden.
Zur Tabelle "tblMahnung"
Der 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.
Und für die Grundfunktionalitäten braucht es auch kein VBA, keinen Buchstaben.
Du frägst hier um Rat, nimmst aber keinen an.
Hallo,
Wie willst du denn bei dem jetzigen Aufbau wissen welches Angebot zu
welcher Rechnung gehört und umgekehrt?
Ich bin da ganz bei Klaus.
gruss ekkehard
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
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.
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
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.
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.
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.. ;)
Hast Du keine Warentabelle? Welche Strategie besteht, wenn sich Steuersätze ändern?
Wenn ich das so lese, würde eine Erfassung mehrere Rechnungen erlauben?!
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'.
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.
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.
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.
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