Office: (Office 2003) DB Entwurf Problem Bestellabwicklung

Hallo,

ich entwerfe grad eine DB zur Bestellabwicklung unter anderem mit folgenden Tabellen (der Übersicht halber nur Auszüge):

Bestellungen (BestNr, KuNr, BestDatum, BestArt)
Rechungen (ReNr, BestNr, ReArt, ReDatum, ReGeldeingang)
ReDetails (ReDetailID, ReNr, Menge, Preis)

Folgendes Problem: Beim erstellen der Artikel wird ja automatisch eine ReNr. erzeugt. Ich würde aber gern diese als "Bestellung" laufen lassen und erst bei Geldeingang eine Rechungsnummer erzeugen (hat steuerrechtliche Relevanz). Was würdet Ihr vorschlagen?

Nächstes Problem: Kunde bezahlt Rechnung (ReNr), aber nicht alle Artikel sind sofort lieferbar, daher erfolgt die auslieferung der Artikel in 2 Teillieferungen. Wie würdet Ihr dies lösen?
Ansatz meinerseits:
Tabelle Lieferschein (LieferID, ReNr, ReDetailID)
Tabelle Lieferung (LieferID, SendungsNr, Lieferdatum)

:)

 

Vermutlich doch wohl eher beim Erstellen der Rechnung, oder?

Der Geldeingang geschieht doch wegen der Rechnung und enthält auch meist einen Bezug auf die Rechnungsnummer im Verwendungszweck. Der Ansatz geht m.E. nicht auf.

Du vermischt im übrigen Bestellung (vom Kunden bei dir), Beschaffung (vom Lieferanten an dich), Lieferung (von dir an Kunde), Rechnungsstellung und Bezahlung.

Teillieferungen können nur eine Bestellung betreffen, sie ist es, die beliefert wird. Eine Rechnung kann man nicht liefern. Teillieferungen können also die Bestelldetails in Teilen ausliefern (Bestellungsdetail 1:n Teillieferung). Die teillieferung kann m.E. aber auch nur "Teile" der Bestelldetails ausliefern; wenn ein Bestelldetail z.B. 5 Stück Artikel 17 ordert, dann kann eine Teillieferung 3 Stück davon liefern. Der Bezug auf die LieferdetailID reicht nicht, sondern die Menge muss mit rein.

 

Erstmal ein bisschen Begriffsdefinition ( Siehe Wikipedia ):

- Bestellung: Aufforderung eines Kunden an einen Hersteller, Händler oder Dienstleister zur Bereitstellung eines Produktes oder einer Dienstleistung
- Auftrag: ist die Rückmeldung des Ausführenden an den Beauftragenden
- Lieferschein: ein Dokument, das über gelieferte Waren Auskunft gibt
- Rechnung: ein Dokument, das eine detaillierte Aufstellung über eine Geldforderung für eine Warenlieferung oder eine sonstige Leistung enthält.


Da durch Rechnungen für Kunden schreiben willst, gehe ich davon aus, daß es sich um eine Auftragsverwaltung handelt.

Bei mir sieht die Struktur so aus:

- Ein (Kunden-)Auftrag hat mehrere Auftragspositionen mit Artikel, Menge, Preis
- Zu einem Auftrag kann es ein oder mehrere Lieferscheine geben,
zu jedem Lieferschein gibt es ein odere mehrere Lieferpositionen auf der aufgeführt wird
welche Menge (Komplett/Teil) einer Auftragsposition geliefert wird.
- Jeder Lieferschein führt zu exakt einer Rechnung mit Rechnungspositionen
( da die Angaben identisch sind, existiert z.B. in meiner Datenbank keine extra Rechnungstabelle )

Ich hoffe das hilft dir etwas weiter

LG
Klaus

 

Danke für die Ausführung. Mir ging es um folgendes Problem:
Der Kunde bestellt die Artikel und erhält eine Rechnung, die er (im günstigem Fall) per Vorkasse bezahlt. Die Rechung enthält alle erforderlichen Daten.
Kunde bezahlt, Ware wird geliefert usw.

Jetzt folgende Situation:
Mein Kunde hat irgendwann sehr viele Kunden und einen entsprechenden Umsatz und ist nicht mehr IST- sondern SOLL Versteuert, was bedeutet, dass er mit Erstellung der Rechnung bereits die USt. abführen muss. Bei 100 Kunden, die eine Woche lang warten, bis Sie bezahlen kann da unter Umstäden ein schönes Sümmchen anfallen *wink.gif*
Dies wollte ich in weiser Voraussicht einkalkulieren....

Eigentlich dürfte die Rechnungsstellung ja erst mit Auslieferung (Positionen des Lieferscheins) erfolgen, da in Rechungen ja auch der Zeitpunkt der Leistungserbringung aufgeführt sein muss.
Aber wie soll mein Kunde dann den Zahlungseingang verbuchen? ist schon kompliziert die Abwicklung mit den Vorgaben des FA in Einklang zu bringen....

 

ob das so ganz astrein ist...?! Es steht dir frei, die Rechnung zu einer Bestellung zu einem späteren Zeitpunkt zu erstellen. Aber dann ist das Soll erreicht, und die USt wird (bei Soll-Besteuerung) fällig.

 

stimmt, an die Menge hatte ich nicht gedacht - danke.

Also
Tabelle Lieferschein (LieferID, ReNr, ReDetailID, Liefermenge)... somit ergibt Bestellmenge minus Liefermenge die offene Menge der Bestellung.
Tabelle Lieferung (LieferID, SendungsNr, Lieferdatum)

 

Nein. Da zu jeder Lieferung (sei es Ganz- oder Teilieferung) genau ein Lieferschein gehört, kann der Lieferschein nicht von der Lieferung abweichen und damit auch gleich dieselbe Datenquelle haben.

Im übrigen, wie schon geschrieben: die Lieferung betrifft nicht die Rechnung, sondern die Bestellung. Die ReNr in der (zusammengelegten) Liefertabelle stört mich.

 

Normalerweise würde ich mir um so etwas keine Gedanken machen, aber der Kunde besteht darauf, weil sein Steuerbüro des sehr penibel ist.

Meiner Auffassung nach kann die Rechnung erst erstellt werden, wenn geliefert wir (Stichwort Zeitpunkt der Leistungserbringung, also Lieferung).

Ich habe aber das Problem, dass ich die DB erstellen soll. So müsste ich die Artikel usw. als Bestellung erfassen, und diese dann ebenfalls in der Rechnung erfassen - so wie ich das sehe, würden dann Daten doppelt erfasst werden *frown.gif*

 

Das sollen Steuerberater untereinander auskaspern.

Und wieso soll aus

folgern:

Artikel werden bestellt, beschafft/hergestellt, geliefert, abgerechnet und bezahlt. Wo ist das Problem?

 

Also noch mal als Ansatz:

1. Kunde bestellt 3 Artikel á 10 Stück

Diese Bestellung wird erfasst in Tabelle Bestellung (Bestellnummer, Datum usw) und in Tabelle Bestelldetails (Artikelnummer, Menge, Preis, Bestellnummer).

2. Summer der bestellten Artikel: 100€
Kunde bezahlt 100€ - Verwendungszweck = Bestellnummer

3. Geldeingang wird verbucht und eine entsprechedne Rechnung erstellt
Tabelle Rechungen (ReNr, Geldeingang, Bestellnummer)

4. Lieferung der Bestellung:
Teillieferung a = alle 3 Positionen, allerdiungs von der 3. Position nur die Hälfte
Teillieferung b = Lieferung der restlichen Positionen

Somit in Tabelle Lieferung (Liefernummer,Sendungsnummer) und in Tabelle Lieferdetail (Liefernummer, Liefermenge und Artikelnummer).
So müsste es doch passen,oder hab ich was übersehen?

Nachtrag: eigentlich ist doch Tabelle Rechnungen sinnlos.... Geldeingang kann doch auch unter Bestellungen erfasst werden.... Wohin also am besten mit der Rechnungsnummer?

 

Frage: Machst Du das im Rahmen einer Aufgabe um Dich mit der Thematik zu befassen oder um etwas zu lernen oder soll das ganze wirklich produktiv eingesetzt werden?

Für einen produktiven Einsatz würde ich überlegen, eine entsprechendes WaWi-System zu kaufen, was dann auch alle steuerlichen/rechtlichen Themen berücksichtigt; das Thema ist nicht ohne und Du kommst da ganz schnell in Schwierigkeiten auch was das rechtliche angeht.

Nicht falsch verstehen, nur ein gut gemeinter Tip. Ein WaWi selbst zu erstellen ist, wie Du gerade selbst feststellst, nicht ohne.

 

ad 1)
Ja.

ad 2)
Also ich bezahle nur Rechnungen, nicht Lieferungen. Die Rechnungen kommen oft mit der Lieferung, aber eben nicht immer.

ad 3)
siehe 2. Rechnung nach Gelderhalt ausstellen ist m.E. Unsinn. Mit welchem Recht hättest du das Geld erhalten sollen?

Der Geldeingang sollte im übrigen auch kein einzelnes Feld sein. Wenn ein Kunde z.B. wegen Streitigkeiten, Rückgaberecht oder Geldnot nur Teilzahlungen leistet, ist der Rest offen. Bezahlt ist kein Ja/Nein, sondern ein "gefordert 100, bezahlt 100 -> voll bezahlt"-Sachverhalt. Da würde ich eher eine Tabelle "Zahlungsumsätze" ansetzen, die die Geldumsätze den Rechnungen zuordnet.

ad 4)
Was soll die Sendungsnummer sein? Eine (Teil)Lieferung betrifft eine Bestellung (vielleicht auch mehrere? dann m:n aufdröseln).

An eine Rechnung sind u.a. allerlei (steuer)rechtliche Anforderungen gebunden, die bei einer Bestellung noch nicht vorliegen oder schlicht sinnlos sind. Ich schlage vor, dass du dir mal eine kommerzielle Bestellabwicklung anguckst oder sie gar kaufst. Ein "ordnungsgemäßer kaufmännischer Betrieb" ist gefährdet, wenn man das einfach so zusammenlötet.

 

...schon klar.

Ich habe selbst eine ähnliche DB, die ich in den letzten 10 Jahren immer wieder ausbaue. Bei meiner Datenbank sind teilweise Fehler enthalten, die schwer oder nur aufwendig zu beheben sind. Entstanden durch (damals) Unwissenheit.
Bei der neuen DB will ich diese Fehler vermeiden und von Anfang an alles richtig machen. Dazu gehört auch, jede Eventualität zu berücksichtigen.

 

Vor der Abbildung der Wirklichkeit gehört aber erstmal deren vollständiges Durchdringen... wer Rechnungen und Bestellungen für synonym hält, hat da noch viel Weg vor sich.

 

zu 4. Sendungsnummer ist die jeweilige Paketnummer (zur Sendungsverfolgung)

zu 2. Wie soll man das sonst lösen - z.B. bei Onlinebestllung per Vorkasse? Soll jeder Kunde, der Online eine Bestellung auslöst eine Rechung erhalten?
Es gibt ja genügend Bestllungen, die getätigt werden und dann im Sande verlaufen.

PS: die Idee mit der Tabelle Zahlungsumsätze ist Super! Darauf bin ich noch nicht gekommen, werd ich aber sofort berücksichtigen.