Brutto- und Nettowerte zu Waren ausweisen

[roman.karuschka@…]

Dieses Ticket entsteht in Referenz zu RFE 2082, da die dort behandelte Thematik mit der zuletzt aufgeworfenen Problematik nicht mehr ganz passte:

In den Stammdaten ist nur ein einziger Preis eingetragen, und der wird wahlweise mal als Bruttopreis und mal als Nettopreis genommen (je nachdem ob in VK-Dokumenten "Steuer im Preis inbegriffen" gesetzt ist oder nicht). Der private Endverbraucher zahlt also fuer einen Artikel der mit 10 EUR eingetragen ist 10 EUR brutto (ca 8,40 EUR netto). Wenn ich dem naechsten gewerblichen Kunden dann eine Rechnung ausstelle, kommt die Steuer stattdessen on top, sprich 10 EUR + 1,90 EUR. Dort liegt evtl das eigentliche Problem begraben. Das kommt einer Strafzahlung fuer gewerbliche Kunden gleich.
Die Stammdaten (Waren/Dienstleistungen??) braeuchten zwei Felder, eines fuer den Brutto- und eines fuer den Nettowert, die beiden ggfs mit einem Javascript verknuepft(?) damit das Beschreiben des Einen auch direkt das Andere updatet/neu berechnet und beide sollten als Variablen dann spaeter in Rechnungen zur Verfuegung stehen und ggfs auch vorher schon angezeigt werden (wenn ein Kunde ad hoc nach dem Preis eines Artikels fragt, man dem privaten Kunden aber erst manuell die MWSt hinzurechnen muss oder wahlweise dem gewerblichen Kunden die USt weg, ist das etwas unhandlich. Beide Werte sollten immer klar angezeigt werden. Dazs beim Druck in LaTeX berechnen zu lassen fuehrt uebrigens u.U. wieder zu Rundungsproblemen).

Zwei Felder führen zu nachgeordneten Problemen mit den Steuerkonten, automatisierten Preisupdate,sind der Quell von Rundungs- («ach da mach ich halt 9,99 € statt 10,01 €») und Bewertungsproblemen (zu welchem Preis wird bei solchen vorgenannten Spielchen der Nettoeinkauf ermittelt?), etc. - keine sinnvolle Lösung.

Es darf nur einen Nettopreis geben, der dann mit dem Schalter "Bruttopreise" entsprechend kalkuliert und im Formular ausgewiesen wird.

Außerdem lässt sich das durchaus jetzt schon mit vorhandenen Brodmitteln lösen: Preisgruppe "Endkunde", dort den richtigen Nettopreis rein, "Bruttoschalter" umlegen, fertig. Afair lässt sich beides ab 3.0 in den Stammdaten-Kunde vorbelegen.

Wenn überhaupt, ist das ein nachgeordnetes Usability-Thema, aber bestimmt kein Fehler.

Ich meinte natürlich den Netto"ver"kauf bei der Bewertung. Wenn ich mal hier, mal dort hole (bei zwei Feldern) lässt sich das nicht sauber ermitteln; bei einer Preisgruppe ist es klar.

Der Workaround mittels der Preisgruppen funktioniert natuerlich - sofern man sonst keinerlei Preisgruppen braucht.Wenn man hingegen situativ unterschiedliche Preise fuer verschiedene Vertriebskanaele anbieten will und dann ..naja, ich denke du verstehst schon was ich meine ;-)
Es sind nicht nur exotische Faelle in denen das zum Problem wird.

Das diese Problematik ueberhaupt existiert ist dem Aufbau noch aus SQL-Ledger-Zeiten geschuldet.
Mein Vorschlag ist daher weniger darauf gemuenzt mal den einen, mal den anderen Wert in die Kontenbebuchung zu pumpen als mehr eine zweite Variable zu schaffen die immer von der ersten Variable abhaengt, damit noch bevor alles gebucht wird die Preise untereinander richtig gezogen werden. Der Netto-Preis waere nach wie vor der "Leit-Preis" (mit bis zu vier Nachkommastellen), der auch z.B. in VK-Dokumenten weiterhin alleine beschreibbar waere und der Bruttopreis wird abhaengig davon ausgewiesen ((z.B. in grau/Klammern dahinter und als Variable fuer den Druck zur Verfuegung stehend).
(So wie es AFAIK buchhalterisch uebrigens auch korrekt gerechnet wird und DATEV es genau nicht macht)
Die Rundungsproblematik ist mir bewusst, aber sie gibt es leider so oder so, und nicht nur an dieser Stelle.

Ich habe es auch nicht als "Fehler" sondern von Anfang an als "Verbesserung" markiert ;-)

Es lassen sich afaik beliebig viele Preisgruppen anlegen. Und die Strukturen für die Preiszieherei sind geklärt. Die Variante des zweiten Feldes halte ich - auf dem Erfahrungshintergrund "experimentier- und wenig nachdenkfreudige Nutzer" - für höchst fehleranfällig.

"Situativ unterschiedliche Preise" klingt für mich nach Basar. Dann kann man das auch so lösen, wie ich das von dort kenne: Der Händler tippt wild auf seinem Taschenrechner rum und zeigt mir eine Zahl. Oder tippt nach kurzem Draufschauen nochmal rum, weil im die angezeigte Zahl nicht gefallen hat. Oder ich tippe ihm die Zahl ein, die ich bereit bin, aufzurufen.

Das kann kivitendo auch (rechnende Preisfelder). Das ist imo "maximal situativ".

Da reicht schon Webshop vs Ladenverkauf.
Aber es bringt nichts sich darum nun zu streiten, es war meinerseits nur ein Vorschlag gemessen an dem was ich im Tagesgeschaeft sehe und was bei anderen Loesungen so gemacht wird (auch wieder nicht falsch verstehen, andere Loesungen sind andere Loesungen, es sollte nicht die Massgabe sein alles unkritisch zu kopieren).