VAT

[heintzl]

VAT handling is currently not sustainable:

• Rates (high & low) are hardcoded => must be configurable
• produce and bakery: vat is regarded as high. => should be regarded low
• produce, bakery and deposit: price entered in shoppingmask is iterpreted as net price => should be regarded gross,

[legion47T]

@julikiller98 wollen wir hier am Samstag mal schauen?

[heintzl]

Die Punkte hab ich im heintzl-dev Branch schon behandelt- für VAT habe ich die entsprechenden enums gefunden und die harten Werte ersetzt. Im PriceCalculator ist ein Brutto-Netto-Wandler ergänzt. Allerdings gibt es int - double - Rundungsprobleme

[legion47T]

Die Punkte hab ich im heintzl-dev Branch schon behandelt- für VAT habe ich die entsprechenden enums gefunden und die harten Werte ersetzt. Im PriceCalculator ist ein Brutto-Netto-Wandler ergänzt. Allerdings gibt es int - double - Rundungsprobleme

Das klingt so, als wäre diese Issue quasi schon gefixt und das Rundungsproblem verbleibt... Kann diese hier dann zu?

[heintzl]

Ich kenne den Code nicht gut genug, um zu wissen, ob alle Stellen behandelt sind, an denen MwSt zum Tragen kommt. Daher bitte Review bevor wir das schließen...

[blackdra-gon]

Beschluss von unserem heutigen Treffen: Mehrwertsteuersätze sollen in der DB gespeichert werden. Im Articel (früher Item) als Fremdschlüssel, im Shopping Item als double. Inwieweit das mit den Veränderungen von Joachim übereinstimmt, weiß ich nicht.

[heintzl]

Das ist ein ziemlich umfassender Change. Vermutlich lässt sich das damit einhergehende refactoring aller queries auf items zentral regeln. Auf jeden Fall dürfte aber dir Performance leiden, weil jeder iten Query plötzlich einen subquery auslöst. Und wir müssen auch an alle Dataforms ran, bei denen VAT angezeigt oder eingegeben wird. Zusätzlich müssen die generischen produkte obst/ Gemüse, Backwaren, Pfand und freie Eingabe umgebaut werden. Ich fände es daher besser, eine settings klasse in Hibernate zu bauen, die VAT Werte dort zu hinterlegen und nur die VAT enums so umzubauen, dass die Werte beim Start der Software einmal aus den Settings abgerufen werden

[julikiller98]

Also ich habe das jetzt so gelöst, es gibt einmal ein VAT Object in der Datenbank, welches das VAT Enum repräsentiert beim ersten aufruf wird einmal eine Query ausgelöst um die VAT sätze aus der Datenbank zu lesen. Ich wusste jetzt nicht ob es erwünscht ist VAT sätze hinzuzufügen dann wäre eine Enum Variante nicht möglich. @heintzl Wie meinst du das mit einer settings Klasse?

[heintzl]

Eine settings Klasse kann dazu dienen, alle möglichen Einstellungen des Programms in der Datenbank zu persistieren, so dass sie nicht hart kodiert werden müssen. Es kann sich dabei um allgemeine Einstellungen handeln und auch um persönliche des angemeldeten Users. Ein Setting ist ein KeyValue-Paar mit einer user id. Die Settings sind eindeutig durch Name und User. Allgemeine Einstellungen werden ohne User gespeichert, daher gibt es sie jeweils nur einmal, User-Settings werden mit User gespeichert, daher kann es sie pro user geben. Die Frage ist ggf. noch, wie der Value abgelegt wird, da er je nach setting verschiedene java types repräsentieren können sollte. Eine Möglichkeit hierfür ist, dass der setting-value als json-string serialisiert wird.

[heintzl]

Das Enum kann bleiben. Wenn es irgendwann mehr als zwei VAT-Werte geben sollte, muss der Code eh angefasst werden, um den zusätzlichen Wert logisch zu verarbeiten. Dann kann der Enum auch erweitert werden. In einer Settingsklasse könnten die VAT-Werte so realisiert werden: name: 'VAThigh', value:'{"double": 1.9e+1}' name: 'VATlow', value:'{"double": 7.0}' Es gibt fertige serializer/deserializer für Java types, z.B: https://github.com/google/gson

[julikiller98]

@heintzl Ich habe die Settings-Klasse als Enum mit verweis auf die Datenbank implementiert, ist das auch ein vallide Settings-Klasse? Nur als Beispiel: Settings Enum { VAT_LOW("0.07"), VAT_HIGH("0.19") }

Der String repräsentiert den Standardwert, falls kein wert in der Datenbank verändert wurde. In der Datenbank sieht das dann so aus:

Enum(String) Value(String) VAT_LOW | "0.07" VAT_HIGH | "0.19"

[heintzl]

Ich finde zunächst das Persistenz-Modell ungünstig. Es gibt zwei Tabellen: settingvalue und usersettingvalue. Das macht aus meiner Sicht keinen Sinn! Meine Idee der Settingsklasse war, dass sie alles "aus einer Hand" zur Verfügung stellt. Die usersettingvalue-Tabelle ist eigentlich alles,w sa wir brauchen: ein setting name, ein value und eine user_id. Da die user_id NULL zulässt, können damit sowohl generelle settings (user_id ist null) als auch user spezifische settings gespeichert werden. Gut wäre noch ein unique index über user_Setting, value und user_id. Dann kann es keine Doppeldeutigkeiten geben. Bei user-spezifischen Settings kann ein default-Wert persistiert werden, indem entweder ein generischer user "default" angelegt wird (der dann nicht im UI erscheinen darf), oder indem dafür der Eintrag mit user_id NULL verwendet wird.

[heintzl]

Settings für User kann ignoriert werden, bis es benötigt wird

[heintzl]

Rundungs-issues bei der Rechnungserstellung: julikiller98 = JK-proxy

[heintzl]

Rundungsissues verschoben auf #52