Artikelpreise Netto / Brutto

[dataspider]

Hallo

Ich musste meine Anwendung um eine Veranstaltungsplanung erweitern.
Und jetzt habe ich das Problem, dass hier Bruttopreise aus der Gastro wie 15,50 € erscheinen.
(Rundungsproblem: 15.50 / 1.19 = 13,0252 - gerundet 13,03 * 1.19 = 15,5057 - gerundet 15,51.)
Belege können schon Netto oder Brutto erfasst werden.

Im Artikelstamm lasse ich Netto oder Brutto erfassen, rechne aber immer bei Eingabe im Feld Brutto das Netto aus und speichere das auch so.

Wenn jetzt ein Angebot mit "Preisangabe Brutto" erzeugt wird, holt er dann natürlich die 15,51 € raus.
Wie macht ihr das? Speichert ihr Netto mit mehr Nachkommastellen oder lasst ihr Erfassung der Preise in Brutto im Artikelstamm zu?

Frank Reim

[Uwe Raabe]

Die einfachste und flexibelste Lösung ist, die Preise in Netto und Brutto zu erfassen und nach Bedarf zu verwenden. Hilfreich ist dann eine Kontroll- bzw. Abgleich-Funktionalität, die auf Diskrepanzen (z.B. > 0.01) hinweist bzw. die Netto- oder Brutto-Preise jeweils ermittelt.

[dataspider]

Zitat:

Zitat von Uwe Raabe (Beitrag 1396180)

Die einfachste und flexibelste Lösung ist, die Preise in Netto und Brutto zu erfassen und nach Bedarf zu verwenden. Hilfreich ist dann eine Kontroll- bzw. Abgleich-Funktionalität, die auf Diskrepanzen (z.B. > 0.01) hinweist bzw. die Netto- oder Brutto-Preise jeweils ermittelt.

Danke!

Aber ich denke, das kann u.U. einige Probleme erzeugen.
Ich muss dann ja beachten:
Was ist, wenn sich der allgemeine Steuersatz irgendwann ändert...
Was ist, wenn sich die Steuergruppe am Artikel ändert...
Und dann gibt es noch Artikel mit 2 Steuersätzen (Außer Haus).

Dann müsste ich ja in einem Trigger alle Artikelpreise korrigieren...
Ich habe dabei kein gutes Gefühl.


Frank

[sh17]

wir haben es so gelöst, das der Anwender der Software grundsätzlich entscheiden muss, ob er Brutto- oder Nettorechnung nutzen möchte, je nachdem wird dann gerundet. Ein gemischte Nutzung ist nicht möglich. Wenn er das doch möchte, muss er mit den Rundungsfehlern leben.

[Uwe Raabe]

Zitat:

Zitat von dataspider (Beitrag 1396182)

Was ist, wenn sich der allgemeine Steuersatz irgendwann ändert...
Was ist, wenn sich die Steuergruppe am Artikel ändert...
Und dann gibt es noch Artikel mit 2 Steuersätzen (Außer Haus).

Dann müsste ich ja in einem Trigger alle Artikelpreise korrigieren...
Ich habe dabei kein gutes Gefühl.

Das ist aber eine Entscheidung die der Benutzer in jedem Einzelfall selbst treffen muss. Faktisch handelt es sich je Artikel um zwei separate Preise für verschiedene Kundengruppen. Welchen der beiden Preise (womöglich beide) jetzt eine Änderung des MWSt-Satzes betrifft und wie ist Geschäftspolitik. Z.B. ist mir jedenfalls nicht aufgefallen, daß sich die Hotel-Bruttopreise verringert hätten, als damals die MWSt von 19% auf 7% reduziert wurde.

[dataspider]

Zitat:

Zitat von sh17 (Beitrag 1396188)

wir haben es so gelöst, das der Anwender der Software grundsätzlich entscheiden muss, ob er Brutto- oder Nettorechnung nutzen möchte, je nachdem wird dann gerundet. Ein gemischte Nutzung ist nicht möglich. Wenn er das doch möchte, muss er mit den Rundungsfehlern leben.

Das wäre auf jeden Fall einfach umzusetzen.

Danke

Frank

[dataspider]

Zitat:

Zitat von Uwe Raabe (Beitrag 1396191)

Das ist aber eine Entscheidung die der Benutzer in jedem Einzelfall selbst treffen muss. Faktisch handelt es sich je Artikel um zwei separate Preise für verschiedene Kundengruppen. Welchen der beiden Preise (womöglich beide) jetzt eine Änderung des MWSt-Satzes betrifft und wie ist Geschäftspolitik. Z.B. ist mir jedenfalls nicht aufgefallen, daß sich die Hotel-Bruttopreise verringert hätten, als damals die MWSt von 19% auf 7% reduziert wurde.

Ja...So betrachtet hast du schon Recht.
Jetzt muss ich erst mal nachdenken :gruebel:

Frank

[Uwe Raabe]

Zitat:

Zitat von dataspider (Beitrag 1396194)

Jetzt muss ich erst mal nachdenken :gruebel:

Das ist schon mal kein schlechter Ansatz :-D

[mensch72]

unsere Lösung: wir speichern und verarbeiten intern alle Werte jeweils mit zusätzlichen 2 Kommastellen

Vorteile:
- wir können intern stets mathematisch runden("Geradzahlregel" bei "x5"), so verteilen sich in den hinteren Zusatzstellen sogar die Rundungsfehler statistisch gleichmäßig
- Zur Anzeige und Belegerzeugung kann jeder Anwender selbst auswählen, wir er nach außen runden möchte (immer aufrunden, immer abrunden, Geradzahlregel, freie Rundung)
- einige Kleinkunden lieben unsere "frei Rundung"... zu gut deutsch im Chefmode kann wer will den Positionspreis selbst nach Bauchgefühl bestimmen
- wir speichern pro Belegposition neben der Menge auch den Abrechnungspreis und pro Beleg dann zusätzlich die diesem zu dem Zeitpunkt verwendeten Steuersätze und Umrechnungskurse
- jeder Beleg hat bei uns neben der Steuerposition mindestens eine (normaler weise verdeckte) Zusatz-Position in stets voller Genauigkeit, welche die Rundungsdifferenzen intern passend bucht

[freimatz]

Zitat:

Zitat von Uwe Raabe (Beitrag 1396195)

Zitat:

Zitat von dataspider (Beitrag 1396194)

Jetzt muss ich erst mal nachdenken :gruebel:

Das ist schon mal kein schlechter Ansatz :-D

Durchaus - und dazu vielleicht auch mal nachlesen. Das Thema ist nicht ganz ohne und wenn Eure Anwender falsche Umsatzsteueranmeldungen abgeben nicht mehr lustig.

[KodeZwerg]

Hallo,
wenn ich nachrechne kommt vorwärt wie rückwärts das selbe raus.
Ich nutze alle Nachkommastellen.

Hier meine Formeln in lesbarer Form:
(z.Zt. entspricht die Zahl 19 = 19% Gesetzliche MwSt.)
----------------------------------
Brutto : (100 + 19) * 100 = Netto
Netto : 100 * (100 + 19) = Brutto
----------------------------------
Brutto : (100 + 19) * 19 = MwSt
Netto : 100 * 19 = MwSt
----------------------------------
MwSt : 19 * (100 + 19) = Brutto
MwSt : 19 * 100 = Netto
----------------------------------

Wenn nun 15,50 / 119 * 100 = 13,02521008403361 ist
und 13,02521008403361 / 100 * 119 = 15,5 ergibt, wo ist das Problem?
Für genaue Berechnungen brauch man eben mehr Ausgangsmaterial damit am Ende kein Cent fehlt.

[dataspider]

Zitat:

Zitat von KodeZwerg (Beitrag 1396234)

Wenn nun 15,50 / 119 * 100 = 13,02521008403361 ist
und 13,02521008403361 / 100 * 119 = 15,5 ergibt, wo ist das Problem?
Für genaue Berechnungen brauch man eben mehr Ausgangsmaterial damit am Ende kein Cent fehlt.

Wie ich im Ausgangspost bereits schrieb:
...Speichert ihr Netto mit mehr Nachkommastellen...

Mir ist klar, dass das funktioniert.
Aber ich habe noch nie eine WAWI gesehen, wo man die Artikelpreise so eingeben kann.
Und dann sollte ich - um Verwirrung zu vermeiden - auch bei der Belegerfassung 13,02521008403361 zulassen?

Es gibt manchmal Aufgaben, wo man sehr genau überlegen sollte, wie man sie löst.
Und das ist so eine Aufgabe.

Frank Reim

[dataspider]

Zitat:

Zitat von freimatz (Beitrag 1396230)

Durchaus - und dazu vielleicht auch mal nachlesen. Das Thema ist nicht ganz ohne und wenn Eure Anwender falsche Umsatzsteueranmeldungen abgeben nicht mehr lustig.

Das Problem habe ich bereits gelöst.
Das ist bei mir noch viel extremer, da Pauschalpreise über mehrere Artikel mit u.U. unterschiedlicher Mwst vereinbart werden.

Das war richtig Arbeit!

Frank

[KodeZwerg]

Damit Dir am Ende kein Cent fehlt könntest Du auch eine Round Variante anwenden mit nur zwei Nachkommastellen, gegenrechnen was rauskommt, wenn summe = original, weitermachen, wenn summe hinten +1 -1 anders = eine zahl an die nachkommastelle ranhängen - je nach zahl an nachkommaposition 3 bei abfrage darauf reagieren +1 -1.
Das wäre eine Möglichkeit um es kurz zu halten aber wie das dann weitergehandhabt werden soll .. hab mir noch keine weiteren Gedanken gemacht.

[freimatz]

... das du dann möglicherweise bereust wenn der erste Kunde mit Schadensersatzforderungen auf die zu kommt.
Ich finde das schon reichlich blauäugig. Und finde es gut dass der TE hier nachfragt statt nur was zusammen zu basteln. Die gesetzlich richtige Lösung weiß ich leider auch nicht, weiß aber das es nicht unproblematisch ist.
Habe noch ein bischen gegoogelt:
https://www.frag-einen-anwalt.de/Pro...t--f67325.html
https://www.haufe.de/finance/finance...HI2020172.html
http://www.scoutsystems-software.de/...rundungsfehler

[jaenicke]

Ganz allgemein gesagt gibt es durchaus mehrere Lösungsmöglichkeiten und Rundungsarten, die in der Regel auch vom Finanzamt akzeptiert werden sofern sich dabei kein Vorteil in Richtung des Steuerpflichtigen ergibt. Soll heißen man kann z.B. pro Eintrag auf der Rechnung die Steuer runden und dann addieren oder die Gesamtsumme nehmen und davon die Steuer berechnen. Da es dabei mathematisch immer Abweichungen in beide Richtungen gibt, ist beides kein Problem. Im Mittel kommt man dann auf ähnliche Werte, wenn man eine größere Anzahl an Rechnungen betrachtet.

Aber das ist schon ein komplexes Thema und so etwas ist in der Tat auch bei uns ein längeres Thema gewesen:

Zitat:

Zitat von dataspider (Beitrag 1396238)

Das ist bei mir noch viel extremer, da Pauschalpreise über mehrere Artikel mit u.U. unterschiedlicher Mwst vereinbart werden.

[dataspider]

Herzlichen Dank an alle Beteiligten.
Die Antworten und auch die Links waren sehr nützlich.

In Absprache mit dem Auftraggeber haben wir wie folgt entschieden:

Nur das Feld Nettopreis wird auf 4 Nachkommastellen erweitert.
Der Preis kann Netto oder Brutto erfasst werden.
Bei Erfassung in Brutto wird der Nettopreis entsprechend der Steuergruppe errechnet.
Gespeichert wird nur der Nettopreis (mit 4 NKS).

Bei der Belegerfassung wird der Preis über eine SP immer mit 2 NKS ermittelt.
Bei Erfassung eines "Netto" Beleges wird also gerundet, bei Brutto anhand des Nettopreises berechnet und gerundet.

Die Änderung dauerte nur wenige Stunden und liefert das gewünschte Ergebnis.

Das korrekte Runden war ja nicht mein Problem. Das würde auch den Rahmen hier sprengen.

Danke

Frank Reim

[freimatz]

Super