SQL Problem bei Rechnungspogramm

**palwal** · 3. März 2023

Moin,

ich arbeite seit Zwei Tagen an einer Lösung des problems aber ich bekomme es nicht hin und hoffe, das jemand mir hier helfen kann.

Ich habe zwei Tabellen, einmal invoices und invoice_items, was die tun, ist selbsterklärend... Ich möchte jedoch einmal den Lieferungspreis, Remissionenpreis, Gut- und Lastschriftenpreis -> das Zusammenrechnen + Umsatzsteuer (Nicht bei allen Positionen, siehe unten) = Brutto - Umsatzsteuer = Netto, also insgesamt 8 Beträge. Wenn dies nicht mit einem SQL Befehl möglich ist, kann es auch gern scripttechnisch mit PHP/PDO gelöst werden. Das Zusammenrechnen an sich, damit habe ich keine Probleme..aber das verrechnet sich immer um paar Cent.

Für eine Rechnung ist das ja Fatal :p

Ich habe diese Tabelle

rid ist die Rechnungs-ID, type kategorisiert die Position (1 Lieferung, 2 Remissionen, 3 Gutschriften, 4 Fahrtkostenzuschuss, 5 Belastungen, 6 Sonstige Gutschriften), value ist die Menge der einzelnen Positionen, posprice ist der Einzelpreis, ust ist die Umsatzsteier in %.

Follgendes muss berücksichtigt werden:

Lieferungspositionen müssen nach zwei Kommastellen gerunden werden.

Remissionenpositionen dürfen nicht gerunden werden und, nur bis zwei Nachkommastellen berücksichtigen (z.b. -3.7752 ~ -3.77)
Gutschriften einfach zusammenrechen (hat sowieso nur zwei Stellen nach dem Komma)
Das gleiche gilt bei Fahrtkostenzuschuss, Belastungen und sonstige Gutschriften.

Ich habe es fablich markiert, was wie zusammengerechnet werden muss.

Die Umsatzsteuer kommt on Top, allerdings hat nicht jede Position darauf eine Umsatzsteuer.

Habt ihr Lösungen? Im besten Fall mit einem SQL Befehl. Wenn dies nicht möglich scheint, dann scripttechnisch.
Mit Javascript habe ich es hinbekommen, das er den Rechnungspreis bereits errechnet, aber funktioniert mit SQL/PHP nicht wie es soll.

Hier noch eine Vorschau:

Rechnung an den man sich orientieren kann

Menge	Einzelpreis	Muss als Ergebnis raus kommen
22	2.0009	*
22.	3.7752	* 129.34
1	2.2700	*
43	-2.0009	**
2	-3.7752	** -95.83
1	-2.2700	**
3	-2.65	***
2	-3.2	***
1	-1	***
1	2.65	*** -22.70
2	-5	***
Zwischensumme: 10.81	Umsatzsteuer: 2.35	Zahlbetrag insgesamt: 13.16

Für Anregungen oder Lösungen wäre ich sehr dankbar

Kaliber · 4. März 2023

Zitat von palwal

Für Anregungen oder Lösungen wäre ich sehr dankbar

Es wäre cool, wenn du 2 SQL Files hochladen könntest, die die jeweiligen Tabellen mit ihren Spalten erstellen + 2 Testdatensätze und dann genau erklären, wie du dir das Ergebnis vorstellst 😅

Dann muss man sich das nicht aus dem Text theoretisch alles herleiten, dafür bin ich gerade zu faul

**palwal** · 4. März 2023

Zitat von Kaliber

Es wäre cool, wenn du 2 SQL Files hochladen könntest, die die jeweiligen Tabellen mit ihren Spalten erstellen + 2 Testdatensätze und dann genau erklären, wie du dir das Ergebnis vorstellst 😅

Dann muss man sich das nicht aus dem Text theoretisch alles herleiten, dafür bin ich gerade zu faul

---- Tabellenstruktur für Tabelle `invoices`--CREATE TABLE `invoices` - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Wie das sein muss, steht oben..wie was berücksicht werden muss. Hatte auch schon ChatGPT gefragt, aber der ist zu blöd dafür und kann nichtmal korrekt rechnen (Als Taschenrechner nicht zu empfehlen xD)

**Andosius** · 4. März 2023

Meine alte Antwort habe ich mal gelöscht, da ich auf dieses Problem etwas ausführlicher Antworten möchte.

"Floats" wie wir sie nennen, sind nur ein sehr abstraktes Konstrukt, welche diese Werte so präzise wie nur irgendwie möglich nachahmen möchten.

Das mag sich für dich vermutlich sehr merkwürdig anhören, aber so ist es tatsächlich. Dein Computer kann mit dem Begriff "Float" wenig anfangen - er arbeitet eben mit Nullen und Einsen.

Über die letzten Jahrzehnte gab es viele Versuche diese Operationen so präzise wie möglich zu machen, weshalb man den "IEEE"-Standard entworfen hat.

Hier kommen aber auch die Probleme: Wir versuchen eine Fließkommazahl mit ganzen Zahlen zu definieren, welche der Computer kennt.

Daraus folgt jedoch, dass eben diese Zahlen auch irgendwo enden müssen, falls diese unendlich lang sind. Aus diesem Grund muss irgendwo gerundet werden oder eben ein Teil weggelassen werden - das führt zum ersten Faktor, der dein Ergebnis verfälscht.

Nicht nur aus diesen Rundungsprozessen entstehen Abweichungen, sondern auch aus dem IEEE-Format (das zu erklären würde jetzt den Rahmen doch etwas sprengen).

Aus diesen Gründen benutzen Banken auch keine Fließkommazahlen und ich lehne mich mal ganz weit aus dem Fenster: Mit großer Sicherheit auch keine Kassen o.ä.

Daher kann ich dir empfehlen deine Beträge mit einer Konstanten zu multiplizieren und damit in Integer umzuwandeln (und so auch zu speichern), anschließend das Gesamtergebnis dann durch diese zu teilen um eine präzisere Float zu erhalten (oder du lässt es gleich so und formatierst es als String, was deutlich schöner wäre tho - ist aber deine Entscheidung).

Ich hoffe, dass die Antwort ein wenig helfen konnte.

Wichige Quellen:

- https://floating-point-gui.de/ (zeigt das Problem)

- https://de.wikipedia.org/wiki/IEEE_754

**palwal** · 4. März 2023

Danke für deine ausführliche Antwort. Aber wie realisiere ich es, damit es richtig rechnet? An float selbst liegts kaum...da das Problem schon bestand, da hatte ich posprice noch integer..habe es dann auf float geändert aber war das selbe. Wie gesagt, versuche es schon seit 2 Tagen.

Beitrag von Andosius (4. März 2023)