Abgelehnt [WAWI-16902] USt-Berechnung bei Lieferantenbestellung falsch

[Mario Pichlmaier]

Hallo,

ich habe gerade eine Lieferantenbestellung mit hinterlegter Rabattstaffel erstellt und dabei wird die USt falsch berechnet.

Die Rabattstaffel belegt bei einem Bestellwert von über 500,- einen Rabatt von 8%. Dieser wird auch korrekt vom Nettobetrag abgezogen. Allerdings wird die USt vom Gesamtnettobetrag und nicht vom rabattierten Betrag berechnet. Richtig wäre hier, dass die USt vom neuen Nettobetrag (Gesamt - Rabatt) berechnet wird.

Grüße

 

[Rico Giesler]

Kannst du bitte mal per Screenshot zeigen was du genau meinst?
Also wo der fehlerhafte Wert steht?
Und gib bitte an mit welcher Wawi-Version du arbeitest.

 

[Mario Pichlmaier]

Hallo Rico,

ich arbeite mit der aktuellsten Version (1.2.3.7).

http://up.picr.de/30303385vq.png

Ich habe mal die Vorschau der Bestellung als Screenshot angefügt. Da ist gut zu sehen, dass die USt vom Gesamtnetto berechnet wird und erst danach wird die Rabattstaffel vom netto berechnet und abgezogen. Dann stimmt natürlich die USt nicht mehr.



Grüße

 

[Rico Giesler]

Ich habe nochmal bei uns geschaut. Da gibt es bereits ein Ticket zu: https://issues.jtl-software.de/issues?query=WAWI-16902

 

[gutberle]

Hi Rico,

es ist zwar gut zu sehen, dass mit Ticket 16902 gleich eine ganze Reihe von Problemen im Zusammenhang mit Rabattstaffeln und Lieferantenbestellungen angegangen werden sollen, aber dort werden eingentlich nur "Unzulänglichkeiten" und "Nice to have" Feature-Requests gelistet, was sicherlich auch die Priorität von "Normal" und den Status "Zukünftig" erklärt.

Was Mario hier aber berichtet geht deutlich über Ticket 16902 hinaus, denn es ist tatsächlich so, das sobald eine Lieferantenbestellungs-Rabattstaffel greift, alle Mehrwertsteuerbeträge und auch das Gesamtbrutto der Bestellung falsch berechnet werden. Und das ist natürlich eine ganz andere Hausnummer, denn das ist steuerrechtlich relevant und ein falscher Bruttobetrag auf *jeder* Lieferantenbestellung wird die Lieferanten recht bald an der Zurechnungsfähigkeit des Händlers zweifeln lassen. Auf jeden Fall wird es ständig Rückfragen und im Zweifel auch Folgefehler geben.

So etwas gehört deshalb auch nicht in ein Ticket mit Priorität "Normal" und schon gar nicht mit dem Status "Zukünftig". - Könntest Du vielleicht aus diesem Bug, denn es ist definitiv einer, ein eigenes Ticket mit erhöhter Prio und einem etwas ~zeitnäheren~ Status machen?

Das Problem von Mario ist ja aber eigentlich ein Vorlagenproblem und zuerst habe ich gedacht, dass man das sicherlich in der Vorlage mit Bordmitteln bereinigen kann, ich habe aber schnell festgestellt, dass dazu eine Variable für die Rabattstaffel fehlt und dass im Bereich für den Gesamtbetrag auch der Zugriff auf die Einzelnettobeträge für die Mehrwertsteuersätze fehlt.

Also habe ich das Problem mit zwei JTL_DirectQueries gelöst und zwar so ...

1. Im Bereich Projekt der Vorlage eine neue Benutzervariable namens @Rabattstaffel anlegen und folgenden Inhalt geben ...

JTL_DirectQuery("(SELECT ABS((SELECT SUM(fMenge*fEKNetto) FROM tLieferantenBestellungPos WHERE nPosTyp=10 AND kLieferantenBestellung="+ToString$(Vorgang.InterneLieferantenbestellungsnummer)+")/(SELECT SUM(fMenge*fEKNetto) FROM tLieferantenBestellungPos WHERE nPosTyp<>10 AND kLieferantenBestellung="+ToString$(Vorgang.InterneLieferantenbestellungsnummer)+")))")

2. In der Zeile/Spalte des Berichtscontainers, in der die Umsatzsteuer ausgegeben wird, die obere durch die untere Zeile ersetzen ...

fstr$(SummenEinkauf.USt, "-?&.##")+" "+Vorgang.Währung
fstr$((SummenEinkauf.Netto*(1-Val(@Rabattstaffel))*(SummenEinkauf.UStSatz/100)), "-?&.##")+" "+Vorgang.Währung

3. In der Zeile/Spalte des Berichtscontainers, in der das Gesamtbrutto ausgegeben wird, die obere durch die untere Zeile ersetzen ...

fstr$(Vorgang.Positionen.BruttopreisGesamt,"-?&.##")+" "+Vorgang.Währung
fstr$(JTL_DirectQuery("SELECT SUM(fMenge*fEKNetto*(1-"+ToString$(Val(@Rabattstaffel))+")*(1+(fUST/100))) FROM tLieferantenBestellungPos WHERE nPosTyp<>10 AND kLieferantenBestellung="+ToString$(Vorgang.InterneLieferantenbestellungsnummer)),"-?&.##")+" "+Vorgang.Währung

Der Weg über die Benutzervariable ist sicherlich nicht zwingend, macht das Ganze aber übersichtlicher, weil die Staffel ja an mehreren Stellen verwendet wird und man sonst immer ein echtes JTL_DirectQuery-Trum dastehen hätte. Und bei Gesamtbrutto wäre das sonst nur über eine komplette SQL Transaction gegangen, weil man keine Aggregatvariablen in Aggregatvariablen verwenden kann. Sieht also übermäßig kompliziert aus, ist aber nötig...

@Mario Pichlmaier - Da Du noch "ganz frisch" bei der Wawi oder zumindest hier im Forum bist, habe ich Dir eine geänderte/korrigierte Lieferantenbestellungs-Standardvorlage unten angehängt. Die kannst Du Dir in den Vorlageneditor im Bereich der Lieferantenbestellungen importieren, ihr vielleicht eine Sprache oder Kundengruppe oder Plattform zuweisen, die dafür sorgen, dass sie nicht ohne Dein Zutun aufgerufen/verwendet wird. Du kannst sie dann ja aber von Hand aufrufen und dadurch vielleicht auch leichter nachvollziehen wo und was für Änderungen ich mit den drei Punkten von oben meine. Dann sollte es leicht sein, die neuen Terme in Deine eigene Vorlage zu übertragen.

Gruß,
Ingmar

 

[holzpuppe]

Soll der Fix echt erst eventuell mit der 1.4 kommen? Stehe auch gerade vor dem Problem. Das ist doch Irre. Netto Rabatt kann doch nicht vom Bruttogesamt abgezogen werden.
Und das betrifft neben Rabattstaffeln auch "normale" Rabatte die beim Lieferanten hinterlegt sind.
Erstelle ich aus der Bestellung eine Lieferantenrechnung habe ich den Salat.
Beispiel:
Wenn man einen Nettogesamtrabatt von 118,746€ hat und dadurch einen Nettogesamtbetrag von 672,89€ muss bei 19% USt. 800,74€ rauskommen und nicht wie in der Wawi 823,31€.

 

[gutberle]

@holzpuppe,

Die schlechte Nachricht zuerst: Ich habe gerade einmal in der 1.4.10.0 geschaut und dort wird immer noch *falsch* gerechnet, was gemessen daran, dass das Problem vor gut einem Jahr berichtet wurde und *echt* gravierend ist, schon fast an Körperverletzung grenzt.

Merke: Ausgewiesene Mehrwertsteuer IST geschuldete Mehrwertsteuer. Weist man zu hoch aus, schuldet man den zu hohen Betrag. Der Finanzminister will das so!

Dann die gute Nachricht: Meine Lösung von oben, die mit dem einfachen Ersetzen von ein paar Formeln in den Standard-Lieferantenvorlagen auskommt, funktioniert nach wie vor tadellos. Vielleicht lohnt es sich also nicht, sich hier aufzuregen, obwohl, meine Sympathie hättest Du und ehrlich gesagt, ich bin am Platzen ...

@rico: Ich denke, jetzt wäre es aber wirklich Zeit, in der Entwicklung Alarm zu schlagen und das Ding sofort zu fixen, denn das ist ein Wawi- und kein Vorlagenproblem, das sich sich mit der Neuerstellung aller Vorlagen für die finale 1.4 sozusagen "von selbst" löst. - Blende mal die Spalte "Summe Brutto" in den Lieferantenbestellungen ein und dort steht ebenfalls der falsche Wert.

Das hier ist KEINE kleine Ungenauigkeit, das hier ist ein HAMMER und zwar vor allem, weil das Ganze seit einem (1) Jahr Bestand hat. Ihr wollt doch im Markt der "erwachsenen" Wawi-Hersteller ernst genommen werden, richtig? - Meinst Du das klappt, wenn Ihr kapitale Böcke in der Business-Logik Eurer Software über ein Jahr ignoriert? Und dass der Bug auch in der 1.4.10.0 noch drin ist, zeigt doch, dass Eure Entwicklung das Ganze überhaupt nicht auf dem Schirm hat. Und warum wohl? Schau Dir mal meinen Post von oben an, der diesen Schlamassel quasi 1:1 voraussagt.

>>>> SO ETWAS wie das hier ist exakt der Grund, warum ich mich Anfang des Jahres völlig frustriert hier aus dem Forum zurückgezogen habe. Es macht einfach keinen Spaß, immerfort auf Euch zu setzen und Euch dann immer und immer wieder hilflos beim Versagen zuschauen zu müssen. - Hier schreibe ich also doch wieder und habe schon wieder keine Lust mehr. TUT WAS!!!!!!

 

[holzpuppe]

@gutberle Danke für die Info. Ich brauche aber tatsächlich, wie wohl auch andere hier, die Exaktheit in der Wawi, für die Korrektheit des Durchschnittpreises. (Hat doch darauf einen Einfluss, oder nicht?) Die Druckvorlage ist in dem Fall für mich unwichtig. Dafür habe ich die Originalrechnung der Firma. Das Ticket wie oben, wurde ja in der Zwischenzeit geschlossen und abgewiesen, mit dem Hinweis, dass es auf dem Schirm sei und in der Umstellung der Bestellung berücksichtig würde. Wie es aussieht scheint die 1.4 noch keine Lieferantenbestellung 2.0 zu haben? Ich würde mal sagen, an dieser Stelle soll JTL vorher eingreifen und den groben Schnitzer ausbügeln.

Ich glaube, wenn ich mich gerade recht erinnere: Wenn ich die Rabatte nicht vorher, sondern erst in der Lieferantenbestellungsrechnung als Wert abgebe, dann ist der Rechnungsbetrag korrekt. Oder erst bei Skontoangabe. Oder ich bin komplett gerade auf dem Holzweg und es klappt nur wenn ich den rabattierten Preis im Artikel hinterlege. xD

 

[Rico Giesler]

Werden wir berücksichtigen wenn wir den Einkauf auf einen neuen Standard umstellen, daher ist das Ticket hier erst mal abgewiesen.

 

[holzpuppe]

Heute habe ich nochmal per Zufall mit Eingangsrechnungen gespielt.
Ein kleiner schmutziger Workaround wäre:
Skonto als "Zusatzkosten" hinzufügen.
Den Skonto muss man in der "Eingangsrechnung->Zusatzkosten verteilen" als Betrag eintragen. Und wichtig: weit rechts in der Spalte MwSt. manuell noch 19 oder 7 eintippen.
Dann stimmt auch die Rechnung.
Nachteil für die, die Skonto NICHT im Durchschnitts-EK haben wollen, funktioniert das unter Umständen nicht.