Ein einziger Satz fuer den ganzen Shop war fachlich falsch: der Steuersatz haengt in Deutschland an der Art der Ware, nicht am Betrieb. Honig ist ein Lebensmittel und ermaessigt besteuert (Anlage 2 zum UStG), eine Bienenwachskerze nicht. Der Satz wird jetzt in drei Stufen bestimmt, die erste gewinnt: 1. Produkt — neues Feld "Umsatzsteuersatz" unter Admin -> Produkte, fuer Ausnahmen, die sich nicht aus der Kategorie ergeben. 2. Kategorie — VAT_RATE_PERCENT_HONIG / _KERZEN / _PROPOLIS. 3. VAT_RATE_PERCENT als gemeinsamer Rueckfallwert. Die Kategorie-Stufe ist der Normalfall: aendern sich die gesetzlichen Saetze, genuegt eine Aenderung an der Konfiguration statt an jedem Produkt. Leer am Produkt heisst ausdruecklich "Satz der Kategorie" und NICHT 0 — 0 bedeutet steuerfrei nach § 19 UStG. Das Formularfeld hat dafuer einen eigenen Zweig im Validierungsschema, sonst haette z.coerce.number() aus dem leeren Feld eine 0 gemacht. Damit kann eine Rechnung mehrere Saetze tragen, sobald Honig und Kerze im selben Paket liegen. Sie weist deshalb je Satz eine eigene Netto- und Steuerzeile aus. Versand und Rabatt verteilen sich im Verhaeltnis der Warenwerte: der Versand ist umsatzsteuerlich eine Nebenleistung und teilt das Schicksal der Hauptleistung — gibt es mehrere, teilt er sich anteilig auf. Die Verteilung nutzt Hare-Niemeyer, damit dabei keine Cent verschwinden oder entstehen; zugesichert ist, dass die Summe aller Zeilen exakt den Rechnungsbetrag ergibt. Der Satz wandert von der Rechnung an die BESTELLPOSITION (OrderItem.vatRatePercent) und gehoert damit zum Snapshot wie der Preis: wird ein Produkt spaeter umkategorisiert, bleiben bestehende Rechnungen unveraendert. Invoice.vatRatePercent entfaellt wieder — ein einzelner Satz je Rechnung ist bei gemischten Saetzen nicht darstellbar. Die Spalte entstand in der vorigen Migration und wurde nie in Betrieb beschrieben. VAT_RATE_PERCENT_PROPOLIS steht auf 19, weil der volle Satz im Zweifel der sicherere ist — als Lebensmittel waeren 7 richtig, als Nahrungsergaenzungs- oder Kosmetikprodukt 19. Im README als zu pruefen vermerkt. Der Manifest-Test hat die neuen Variablen zunaechst als "liest niemand" gemeldet: lib/vat.ts bekommt die Umgebung als Parameter, damit sich die Saetze ohne globalen Zustand testen lassen, und greift auf die Kategorie-Saetze ueber einen berechneten Schluessel zu — beides kann eine Regex nicht sehen. Dafuer gibt es jetzt eine begruendete Ausnahmeliste. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
24 lines
1.0 KiB
SQL
24 lines
1.0 KiB
SQL
-- Der Umsatzsteuersatz haengt in Deutschland an der Art der Ware: Honig ist
|
|
-- ein Lebensmittel und ermaessigt besteuert (Anlage 2 zum UStG), eine
|
|
-- Bienenwachskerze nicht. Eine Bestellung kann also Positionen mit
|
|
-- VERSCHIEDENEN Saetzen enthalten.
|
|
--
|
|
-- Der Satz wandert deshalb von der Rechnung an die einzelne Position und
|
|
-- gehoert zum Snapshot der Bestelldaten: wird ein Produkt spaeter
|
|
-- umkategorisiert, darf das bestehende Rechnungen nicht rueckwirkend
|
|
-- veraendern.
|
|
--
|
|
-- Die Spalte an "invoices" entstand in der vorigen Migration und wurde nie
|
|
-- in Betrieb beschrieben — es gehen keine Daten verloren.
|
|
-- AlterTable
|
|
ALTER TABLE "order_items" ADD COLUMN "vatRatePercent" INTEGER;
|
|
|
|
-- AlterTable
|
|
ALTER TABLE "invoices" DROP COLUMN "vatRatePercent";
|
|
|
|
-- Satz je PRODUKT, als Ausnahme zur Kategorie-Vorgabe. Leer heisst: es
|
|
-- gilt der Satz der Kategorie (siehe src/lib/vat.ts). Bestehende Produkte
|
|
-- bekommen NULL und folgen damit unveraendert ihrer Kategorie.
|
|
-- AlterTable
|
|
ALTER TABLE "products" ADD COLUMN "vatRatePercent" INTEGER;
|