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

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.

Zitat von 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.

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

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.

Zitat von dataspider:

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.

Zitat von 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.

Das wäre auf jeden Fall einfach umzusetzen.

Danke

Frank

Zitat von Uwe Raabe:

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

Frank

Zitat von dataspider:

Jetzt muss ich erst mal nachdenken

Das ist schon mal kein schlechter Ansatz

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

Zitat von Uwe Raabe:

Zitat von dataspider:

Jetzt muss ich erst mal nachdenken

Das ist schon mal kein schlechter Ansatz

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