Db Design Verrechnen

[Forumsgast]

Moin,

Ich habe mir lange überlegt wie ich das Verrechnen von Produkten machen könnte und bin zu folgendem gekommen->

Wenn was gekauft wird geht das in die Tabelle "purchased":
id (autoincrement)
productid
buyerid
createddate (timestamp())
price
pool

=>
id = 5
productid = 1234 // verknüpft mit Products
buyerid = 5050 // verknüpft mit clients
createddate = 2020-08-12 22:00:00
price = 100
pool = 0
---------

Um eine Rechnung zu erzeugen gibt es eine weitere Tabelle "invoicepool":
id (autoincrement)
created (timestamp())
reend (date)
mwst

=>
(Diesen "Pool" kann im Adminbereich erstellt werden: )
id = 102050 //autoincrement
created = 2020-08-21 23:07:20 //Zeit jetzt.
reend = 2020-08-28 // Zeit Jetzt + x-Tage
mwst = 7
---------
Nun kann ich den gekauften Produkten (tabelle "purchased") diesen Pool (tabelle "invoicepool" zuweisen (mit berücksichtigung dass der Client/Käufer/Clientid überall identisch ist):
=>
id = 5
productid = 1234
buyerid = 5050
createddate = 2020-08-12 22:00:00
price = 100
pool = 102050 // nur das wird geupdated von der "gekauften Position"
=>
id = 7
productid = 1312
buyerid = 5050
createddate = 2020-08-09 10:30:00
price = 230
pool = 102050 // nur das wird geupdated von der "gekauften Position"


Hiermit sollte ich also nun ein .pdf-Dokument/Rechnung erstellen können mit folgenden Daten:
Rechnungsnummer = von invoicepool -> 102050
Rechnungsdatum = von invoicepool -> 2020-08-21
Zahlbar bis = von invoicepool -> 2020-08-28
MwSt = von invoicepool -> 7
Produktnamen = von Products // verknüpfung products.id -> purchased.productid (products.name) das ganze aufgelistet also z.B. 5 Produkten untereinander, wenn der Pool 102050 5x zugewiesen wurde.
Preis = von purchased.price -> 100
An-Adresse = von clients // verknüpfung clients.id -> purchased.buyerid (clients. ...)

Was haltet ihr von dieser Lösung?
Im nächsten Schritt sollte das "Pool"-Erstellen und Zuweisen natürlich automatisch ablaufen z.B. created = jetzt, reend = jetzt + 30d.

Gruss Newsletter

[Forumsgast]

Das Konzept scheint mir wenig sinnvoll. Ich weiß nicht genau was du vor hast, aber ich würde erst eine Rechnung erstellen (Tabelle "invoice", ohne "pool") und dieser Rechnung dann die Positionen zuweisen. Die Käufer-ID steht dann nur in der Rechnungstabelle, die Tabelle mit den Positionen könnte als Primärschlüssel eine Kombination aus Rechnungs-ID und Positionsnummer (oder Produkt-ID, dann auf jeden Fall noch eine Spalte "Anzahl") bekommen.
Worfür die created-Spalten genau sind (warum heißen die eigentlich nicht gleich?) weiß ich nicht, in der Rechnungstabelle brauchst du aber je eine Spalte für Rechnungs- und Leistungsdatum. Das Fälligkeitsdatum (das soll das deutsch-englische-Mischmasch in "reend" wohl sein, oder?) würde ich evtl. nicht direkt speichern sondern auf eine extra Tabelle mit den Zahlungsbedingungen verweisen (also die ID aus der Tabelle speichern) - dann kannst du nämlich auch Dinge wie "Fälligkeit: sofort netto" oder "10 Tage 2% Skonto, 30 Tage netto" o.ä. einstellen. Die Spalte "mwst" möchte wohl gerne "vat" heißen oder hat das seinen Grund warum die Spalte nicht auf englisch benannt ist?

btw: bitte Text nicht farblich formatiert posten, #ADD8E6 auf #EBF4F9 ist nur bescheiden lesbar - ggf. Code-Blöcke o.ä. verwenden.

[Forumsgast]

Was haltet ihr von dieser Lösung?

Nichts

[Forumsgast]

Naja, "Nichts" ist ein bischen übertrieben...

Zunächst einmal ist zumindest Ansatzweise eine Normalisierung erkennbar, was eine gute Sache ist. Da geht aber noch weit mehr...
Beispiel:

• Produkte/Artikel (werden von "Herstellern" gemacht), haben erstmal keine Preise, es gibt nur eine "unverb. Preisempfehlung". Händer definieren ihre Preise selber, daher entsteht ein Preis erst. wenn ein Artikel von einem Händler angeboten wird. Heisst: Wenn du in der Datenbank die gleichen Produkte von verschiedenen Händlern hast, muss der Preis in einer Extra-Tabelle abgelegt werden. Bsp. Preisvergleichsportal (1 Artikel -> x Händler -> x verschiedene Preise). Gleiches gilt z.B. für Lagerbestand, das ist ebenfalls händlerspezifisch
• "Pool" hat beim Produkt ebenfalls nichts verloren. Ein Produkt ist (datenbanktechnisch) nur ein Template, Vorlage, um was es sich handelt. Produkte haben Eigenschaften (Material, Ausmaße, ..)
• Mehrwertsteuer ist abhängig vom Land, Produkt und vom Käufer - Händler zahlen eine andere Mwst. als Privatpersonen.

Führe dir bildlich vor Augen, wie Produkte in der realen Welt behandelt werden - und genau das bildest du in der Datenbank ab.

Die Bezeichnungen sind dagegen nicht einleuchtend. Pool? Verkaufst du Schwimmbäder? Bleib doch im Fachjargon... Produkte/Artikel, Preise, Rechnung, Bestellung, Auftrag -> das sind Begriffe mit denen ein Verkäufer etwas anfangen kann.

Also, m.M.n. ist das was du hast nicht Gold, aber etwas worauf man aufbauen kann...

[Forumsgast]

[*]Mehrwertsteuer ist abhängig vom Land, Produkt und vom Käufer - Händler zahlen eine andere Mwst. als Privatpersonen.

Es gilt die MwSt. des Landes desjenigen der die Rechnung schreibt - allerdings kann sie auch entfallen wenn der Rechnungsempfänger im Ausland sitzt (frag mich nicht wie das genau geht). Vom Produkt ist klar dass sie abhängt, deswegen darf sie auch nicht in die Rechnungstabelle (btw: 7% ist aktuell ziemlich sicher falsch). Aber wieso sollen Händler eine andere Mehrwertsteuer zahlen als Privatleute? Als gewerblicher Kunde zahlst du erstmal genauso die MwSt - dass du sie hinterher wieder zurück bekommst ist für die Rechnung irrelevant.

[Forumsgast]

Moin,

erstmal vielen Dank für eure Input's.

So sieht es nun aus, wenn ich es Grafisch darstelle:
https://imgur.com/LmrMd7M

So sieht ein mögliches Szenario aus:
https://imgur.com/y3JPpv1

Wenn ich diese Tabellen habe:

1. clients (id, vorname, nachname...)
2. products (id, clientid, productname, ..)
3. purchased (id, productid, buyerid, erstelldatum, menge, preis (evtl. später noch weitere Daten))
//relationen:
//clients.id -> products.clientid
//products.id -> purchased.productid
//clients.id -> purchased.buyerid

Dann kann ich keine Rechnung erstellen, weil diese Daten fehlen:

- Rechnungsnummer
- Rechnungsdatum
- Fälligkeitsdatum
- MwSt

Deshalb habe ich die Tabelle "invoicepool" erstellt,

((pool = wie bei Festplatten wenn ein Raid erstellt wird oder so = Datenansammlung oder so... :roll: nenns nun nur "invoice".))
(id, erstelldatum, fälligkeitsdatum, mwst) // id ist auf autoincrement, Datensatz wird im Adminbereich erstellt

Um die bestellten Positionen von "purchased" einer Rechnung zuzuordnen habe ich dort die Spalte "pool" hinzugefügt... Nenne sie nun "invoice".

ich würde erst eine Rechnung erstellen (Tabelle "invoice", ohne "pool") und dieser Rechnung dann die Positionen zuweisen.

Das mache ich, die "Position" wird vom Kunden in "purchased" erstellt.
Der Admin erstellt die Rechnung in "invoice" und weist danach die "Positionen" von "purchased" zu.

Die Käufer-ID steht dann nur in der Rechnungstabelle

Das macht durchaus sinn... ich habe gedacht, dass ich beim "Positionen" der "Rechnung" hinzufügen überprüfe, dass die "buyerid" immer dieselbe sein muss, weil ich sonst ja Positionen zuweisen könnte, welche von einem anderen kunden sind. Aber das mache ich noch, dann wäre "invoice.buyerid -> purchased.buyerid" verknüpft.

die Tabelle mit den Positionen könnte als Primärschlüssel eine Kombination aus Rechnungs-ID und Positionsnummer (oder Produkt-ID, dann auf jeden Fall noch eine Spalte "Anzahl") bekommen.

Anzahl habe ich nun hinzugefügt. Rechnungsid(=davor pool, jetzt purchased.invoice) ist nun umbenannt.

Worfür die created-Spalten genau sind (warum heißen die eigentlich nicht gleich?) weiß ich nicht

Die sind nur um zu wissen, wann die "Positionen" gekauft wurden. In der Tabelle "invoice" ist es das Rechnungsdatum.

in der Rechnungstabelle brauchst du aber je eine Spalte für Rechnungs- und Leistungsdatum. Das Fälligkeitsdatum (das soll das deutsch-englische-Mischmasch in "reend" wohl sein, oder?). Die Spalte "mwst" möchte wohl gerne "vat" heißen oder hat das seinen Grund warum die Spalte nicht auf englisch benannt ist?

Ich komme teilweise nicht sofort auf den englischen Begriff, deshalb habe ich zu Beginn (vor 1,5Jahren) alles erstmal auf Deutsch geschrieben für mein Verständnis, gab aber später diverse Probleme weshalb ich nun versuche alles Sinnvoller zu schreiben + auf Englisch
Benenne das noch um.

würde ich evtl. nicht direkt speichern sondern auf eine extra Tabelle mit den Zahlungsbedingungen verweisen (also die ID aus der Tabelle speichern) - dann kannst du nämlich auch Dinge wie "Fälligkeit: sofort netto" oder "10 Tage 2% Skonto, 30 Tage netto" o.ä. einstellen.

Das kommt im nächsten Schritt. Kann nicht alles auf einmal machen... Ich bin sehr froh, wenn ich das mal so hinkriege

Produkte/Artikel (werden von "Herstellern" gemacht), haben erstmal keine Preise, es gibt nur eine "unverb. Preisempfehlung". Händer definieren ihre Preise selber, daher entsteht ein Preis erst. wenn ein Artikel von einem Händler angeboten wird. Heisst: Wenn du in der Datenbank die gleichen Produkte von verschiedenen Händlern hast, muss der Preis in einer Extra-Tabelle abgelegt werden. Bsp. Preisvergleichsportal (1 Artikel -> x Händler -> x verschiedene Preise). Gleiches gilt z.B. für Lagerbestand, das ist ebenfalls händlerspezifisch

Kann ich später so machen Macht es aber in meinem jetzigen Fall unnötig kompliziert deshalb zu Beginn einen möglichst "einfachen" aufbau.

"Pool" hat beim Produkt ebenfalls nichts verloren. Ein Produkt ist (datenbanktechnisch) nur ein Template, Vorlage, um was es sich handelt. Produkte haben Eigenschaften (Material, Ausmaße, ..)

Pool war die Verknüpfung welche jetzt purchased.invoice -> invoice.id ist. Also das zuweisen von einer "bestellten Position" (purchased) in eine Rechnung (invoice)

Mehrwertsteuer ist abhängig vom Land, Produkt und vom Käufer - Händler zahlen eine andere Mwst. als Privatpersonen.

Wird berücksichtigt invoice.mwst oder neu invoice.vat, das wird vom Admin bei der Rechnung-erstellung ausgefüllt.

Die Bezeichnungen sind dagegen nicht einleuchtend. Pool? Verkaufst du Schwimmbäder? Bleib doch im Fachjargon... Produkte/Artikel, Preise, Rechnung, Bestellung, Auftrag -> das sind Begriffe mit denen ein Verkäufer etwas anfangen kann.

Gebe mir mühe das besser zu beschriften...

[Forumsgast]

Ich bin kein Experte für Umsatzsteuerrecht, meine Aussage war nicht korrekt formuliert, dennoch inhaltlich nicht völlig verkehrt.

Doch es gibt Ausnahmen in Punkto Mehrwertsteuer Rechnung. So gilt für bestimmte Waren und Berufsgruppen der ermäßigte Umsatzsteuersatz von 7 %. Wer selbständig ist und die Kleinunternehmerregelung in Anspruch nimmt, muss gar keine Umsatzsteuer ausweisen.

https://www.unternehmerlexikon.de/me...euer-rechnung/

Es gilt die MwSt. des Landes desjenigen der die Rechnung schreibt - allerdings kann sie auch entfallen wenn der Rechnungsempfänger im Ausland sitzt (frag mich nicht wie das genau geht).

Auch da gibts Unterscheidungen, insbesondere zwischen EU und "Rest der Welt".

Seit dem 1. Januar 2010 gilt die Grundregel, dass Leistungen dort steuerbar sind, wo der Empfänger der Leistung, also Dein Auftraggeber, seinen Sitz hat.

...

Die Rechnung eines Lieferanten oder Dienstleisters, der an einen Kunden innerhalb der Europäischen Union seine Waren liefert oder Leistungen erbringt, richtet sich danach, welche Rechtsform der Empfänger hat. Die Kriterien der Unterscheidung sind abhängig davon, ob Du eine Lieferung oder Leistung

• an eine Privatperson
• an ein Unternehmen
• oder als Kleinunternehmer

erbringst.

https://www.billomat.com/magazin/meh...n-ins-ausland/

[Forumsgast]

Naja die MwSt ist ganz klar wichtig aber das ist schlussendlich auch nur eine Zahl, welche korrekt je nach Produkt, Ursprungsland, Versandland etc erhoben werden muss. Muss vom Admin korrekt erfasst werden

Mir ists vorallem wichtig ob diese Grund-Struktur so korrekt ist oder besser anders machen...

https://imgur.com/LmrMd7M

https://imgur.com/y3JPpv1

Weitere Daten kann ich immernoch einpflegen etc...
Will erstmal einfach verrechnen können

[Forumsgast]

Ich habe selbst noch kein Modell für eine Plattform gemacht, nur ziemlich spezifische Produkte. Daher und sowieso gebe ich mal ein paar Punkte zu bedenken:
- Mwst ist ein eigenständiges Modell, international, food/noon food, Corona Rabatt, Tiernahrung, Bücher, Luxus, Alkohol .. ich schätze, die Deutschen sind zwar Steuergesetztechnisch schon halbwegs verrückt, aber es gibt sicher noch andere Irre.
- Rabatt: ebenfalls ein Kapitel für sich, Rabatte haben die unangenehme Eigenschaft, für einzelne Produkte, für Produktgruppen, für andere Rabatte, für Kundengruppen, für Jahreszeiten und andere Skurrilitäten zu geltenoder abhängig vom genannten ausgeschlossen zu sein.
- Käufer/Verkäufer/Lieferant/Wiederverkäufer/Affiliate/Promoter/Promotion Code/B2B/B2C/Rank: Preise gelten von und für all diese Gruppen unterschiedlich, in Kombination mit Rabatten und Steuer
- Preis Pro Stück/Kilo/Tonne/1000Stück/, inkl/exkl Lieferung/Porto/Versand/Bordsteinkante/kostenloserRückversand/usw.

Nur eine Sache dazu bspw. mal konkreter: Mwst würde man wohl je Produkt festlegen, einerseits und man wäre auf der sicheren Seite. Andererseits will man nicht 1000e Produkte bei Änderungen (Corona, Steuerreform, Abwrackprämie o.ä...) editieren. Also würde man wahrscheinlich (länderspezifische) Mwst Klassen definieren und jedes Produkt zuordnen.

[Forumsgast]

Auch da gibts Unterscheidungen, insbesondere zwischen EU und "Rest der Welt".

Die Rechnungen die wir in der Firma bisher ins Ausland (EU und Nicht-EU) gestellt haben waren (nach Rücksprache mit dem Steuerberater) immer ohne MwSt, allerdings haben wir auch nur Firmen- und keine Privatkunden, mag sein dass das im Ausland da noch Unterschiede gibt - es ist auf jeden Fall kompliziert das ganze und nicht mit einem Mehrwertsteuerfeld in der Rechnungstabelle erledigt …

[Forumsgast]

Ich habe mir lange überlegt wie ich das Verrechnen von Produkten machen könnte und bin zu folgendem gekommen->

Hast du hier auch an "Zeit" gedacht. Was passiert mit deinen Rechnungen wenn sich ein Produktname ändert? Was passiert mit deinen Rechnungen wenn sich die Adresse des Kunden ändert? Was passiert wenn sich dein Adresse ändert? Und so weiter...
Mit dem Datenbankdesign können sich deine "Rechnungen" über die Zeit ändern. Das muss dir bewusst sein. Die Rechnung existiert somit nicht in der Datenbank, sondern nur als PDF die einmalig aus den Daten erzeugt wurde.

Ich bin kein Experte für Umsatzsteuerrecht, meine Aussage war nicht korrekt formuliert, dennoch inhaltlich nicht völlig verkehrt.
[...]
Auch da gibts Unterscheidungen, insbesondere zwischen EU und "Rest der Welt".

Wenn innerhalb der EU Leistungen erbracht werden, sollte ein Steuerberater zurate gezogen werden. Das ist ein Thema wo es auf die Details ankommt.