@koniu12 - Eigentlich ist das, was Du schreibst, nur vom Effekt her richtig, nicht von der Logik, denn in der Spalte für die USt steht schon seit jeher bei IGL Angeboten und Lieferungen 0%.
Problem: Das Problem ist eigentlich, dass man die Versandarten in "Versand > Versandarten" mit
Bruttopreis und Mehrwertsteuer anlegt, die
Wawi kennt also erst einmal nur einen Bruttopreis und in der Versandart ist hinterlegt, auf welchem Umsatzsteuersatz dieser Bruttopreis basiert. Um an den Nettopreis der Versandart zu kommen, müsste die Wawi also
diesen Bruttopreis durch
diese Mehrwertsteuer teilen, das macht sie aber nicht!
Stattdessen passiert folgendes: Wenn man eine Versandart in ein Angebot oder einen Sofortauftrag einfügt, dann wird der Bruttopreis aus der Versandart geholt und nicht etwa durch den dort hinterlegten USt-Satz geteilt, sondern durch den Ust-Satz in der Zeile im Angebot oder Auftrag. Ist das also ein innerdeutscher Auftrag mit 19% MwSt dann ist alles palletti, der Bruttopreis wird gezogen, durch 1,19x geteilt und der Nettopreis stimmt mit dem "geplanten" Netto überein. Hat das Angebot/Auftrag aber irgendeinen MwSt-Satz, der von dem in der Versandart hinterlegten abweicht, dann wird der normalerweise bei uns auf 19% basierende Versandart-Bruttopreis durch den
abweichenden MwSt-Satz geteilt und es kommt Mist dabei raus, bei IGL Lieferungen eben
Brutto=Netto.
Fazit: Das ist ein Bug!
Lösen könnte man das auf zwei Arten:
1) Dadurch, dass man in der Definition der Versandart nicht
Bruttopreis & MwSt, sondern
Nettopreis & MwSt angeben läßt. Klingt logisch und einfach, macht aber Verwerfungen, siehe unten...
2) Indem man den in der Versandart hinterlegten Bruttopreis erst durch den dort hinterlegten MwSt-Satz teilt, ihn dann in das Nettopreisfeld des Angebots/Auftrags einfügt und ihn dann vorwärts mit dem dort "herrschenden" MwSt-Satz multipliziert.
Lösung 1 wäre die logisch und inhaltlich korrektere der beiden Lösungen, aber auch die, die mehr Aufwand bedeutet und potentiell einen Sack Probleme bedeuten würde, denn dann müssten alle Wawi Nutzer Ihre Versandarten ändern und wer das versäumt, kriegt Ärger mit seinen Kunden wegen der plötzlich 19% teuereren Versandarten. Natürlich könnte JTL das beim Update selbst in der DB ändern und diese Probleme verhindern, aber es bleibt immer noch ein größerer Eingriff.
Lösung 2 wäre deutlich einfacher zu realisieren und läßt sich völlig ohne Umstellungen an den Versandarten oder in der Datenbank umsetzen, da lediglich ein einziger Schritt, das Teilen durch die Versandart-MwSt ergänzt werden müsste.
