Neu Rundungsfehler in der Rechnung

[Jürgen Jester]

Liebe Gemeinde,
wir fertigen oft für die Industrie in großen Mengen, weshalb wir manchen Kunden einen Rabatt gewähren. Mit unserer früheren Warenwirtschaft war die problemlos möglich. Wenn wir jedoch mit JTL Wawi so verfahren und einem Kunden Rabatt auf Artikel geben, führt dies dazu, dass der Betrag nach dem Komma länger als zwei Nachkommastellen wird und beim Zusammenrechnen der Posten es dann zu Fehlern kommt - hier wären der Zahlbetrag eigentlich 66,97 € :



Unsere Kunden erfassen unsere Rechnungen mit Scannern automatisch und weisen die Berechnungsfehler ab - das heißt, die Rechnung wird nicht bezahlt.
Ich las hier, dass einige die Nachkommastellen in der Rechnungsansicht erweitert haben, also habe ich das auch in der Standard-Rechnungsvorlage so unternommen. Das Resultat ist aber nicht besser:



Ich bin ratlos, auch in den anderen Beiträgen wurde ich zum Thema nicht fündig, unser ist Boss unzufrieden mit dem neuen System und ich habe den schwarzen Peter.
Kann mir jemand sagen, gibt es vielleicht Rechnungsvorlagen von Externen, die das richtig können?

Viele Grüße und vielen Dank,
Jürgen

 

[mvh]

Moin. In der neuen Rechnungsvorlage gibt es Variablen. Eine davon, wenn ich mich recht erinnere, ist für die Dezimalstellen zuständig. Dort überall von 4 auf 2 ändern.

 

[Jürgen Jester]

Moin. In der neuen Rechnungsvorlage gibt es Variablen. Eine davon, wenn ich mich recht erinnere, ist für die Dezimalstellen zuständig. Dort überall von 4 auf 2 ändern.

Moin und vielen Dank für Deine Antwort. Das wäre so ein toller Hoffnungsschimmer ... ich bin auf der Suche, aber mir fehlt dafür wirklich die "Ahnung" - ist das diese Ansicht hier?


Edit: Also ich hab an den Werten etwas gedreht, aber leider kam ich dem Ziel damit nicht näher :/

Viele Grüße,
JJ

 

[frankell]

Moin Jürgen,

zeig mal bitte die Formel für die Spalte G.-Preis.

VG,
Frank

 

[mvh]

Moin und vielen Dank für Deine Antwort. Das wäre so ein toller Hoffnungsschimmer ... ich bin auf der Suche, aber mir fehlt dafür wirklich die "Ahnung" - ist das diese Ansicht hier?
Den Anhang 123710 betrachten

Edit: Also ich hab an den Werten etwas gedreht, aber leider kam ich dem Ziel damit nicht näher :/

Viele Grüße,
JJ

Moin. Mein Fehler. Ich habe die Abfrage davor angepasst.
Zuerst die Erklärung, Diese ganzen Daten gehen über die Report-Abfragen und das sind SQL Server Views namens Report.<Name>.
Eine davon heißt Report.TotalsInvoice. Hier sind alle Variablen aus diesem Bericht enthalten.
Und hier ist der Fehler:
CAST(ROUND(SUM(InvoicePosition.TotalGrossPrice),2) AS DECIMAL(25,13)) AS GrossPriceTotal lautet der Code.
also zuerst wird über TotalGrossPrice summiert und dann auf 2 Stellen gerundet, was zu falschen Ergebnissen führt, wenn der Preis 3 oder 4 stellig ist.
Richtig sollte es:
CAST(SUM(ROUND(InvoicePosition.TotalGrossPrice,2) AS DECIMAL(25,13)) AS GrossPriceTotal heißen:
ZUERST auf 2 Stellen runden und DANACH summieren.
Welche WaWi Version hast Du ?
Ich kann Dir meine Abfrage geben und gut ist - musst nichts verändern.

 

[deliman]

Das Problem mit den Rundungsdifferenzen in den Rechnungsbelegen soll so einfach lösbar sein? Das ist doch schon seit Jahren ein Mangel, dessen Erledigung von JTL immer auf die Neugestaltung der kompletten Fakturierung verschoben wurde (Rechnung 2.0), soweit ich mich erinnere.

 

[mvh]

Das Problem mit den Rundungsdifferenzen in den Rechnungsbelegen soll so einfach lösbar sein? Das ist doch schon seit Jahren ein Mangel, dessen Erledigung von JTL immer auf die Neugestaltung der kompletten Fakturierung verschoben wurde (Rechnung 2.0), soweit ich mich erinnere.

Moin.
Im Grunde genommen - ja, ist einfach.
Allerdings ist der TotalGrossPrice in der InvoicePosition Abfrage auch gar nicht gerundet
tRechnungPositionEckdaten.fVKBruttoGesamt AS TotalGrossPrice, die Rundung passiert in dem Bericht selbst.

 

[frankell]

Hm, ich bin mir da nicht so sicher, dass damit alle Eventualitäten erschlagen sind. Wenn ich es richtig sehe, dann ist fVKBruttoGesamt auf zwei Stellen gerundet, aber fRabattbetrag auf vier, obwohl auch das ein Bruttobetrag ist. Ohne das jetzt komplett durchdacht zu haben, aber das scheint mir eher die potentielle Fehlerquelle, vielleicht auch in diesem Fall.

Aber mal ganz davon abgesehen: Alle meckern über den Staat über zu viel Bürokratie, aber wenn der dann mal Fünfe gerade sein lässt (USt.-Rundungsfehler), dann kommt der noch schlimmere Buchhalter und ist strenger als der Staat.

 

[Jürgen Jester]

Moin Jürgen,

zeig mal bitte die Formel für die Spalte G.-Preis.

VG,
Frank

Hallo Frank,
vielen Dank für Deine Antwort.

Also von "default" steht hier

LocCurrL$(TotalsInvoice.NetPriceTotal, @InvoiceCulture)

ich hatte es auch mal mit

Str$ (TotalsInvoice.NetPriceTotal,3,4) + " €"

probiert, um vier Nachkommastellen anzuzeigen (hab ich hier irgendwo mal gefunden),
aber es machte bei der Summe keinen Unterschied, weil von den einzelnen Positionen die Werte nach dem Komma wohl nicht mitberechnet wurden. Hach.

Viele Grüße,
Jürgen

 

[Jürgen Jester]

Moin. Mein Fehler. Ich habe die Abfrage davor angepasst.
Zuerst die Erklärung, Diese ganzen Daten gehen über die Report-Abfragen und das sind SQL Server Views namens Report.<Name>.
[...]
Welche WaWi Version hast Du ?
Ich kann Dir meine Abfrage geben und gut ist - musst nichts verändern.

Oha, mvh, klingt ja spannend! Wir haben von Wawi die 1.10.12.0 laufen. Das wäre großartig, wenn Du mir da aushelfen könntest - da werf ich Dir gerne einen Stein für in Garten

Viele Grüße,
Jürgen

 

[mvh]

Oha, mvh, klingt ja spannend! Wir haben von Wawi die 1.10.12.0 laufen. Das wäre großartig, wenn Du mir da aushelfen könntest - da werf ich Dir gerne einen Stein für in Garten

Viele Grüße,
Jürgen

Spoiler: Hier der Code für SSMS oder JTL-Diag

ALTER VIEW [Report].[TotalsInvoice]
AS
(
    SELECT
        Invoice.kRechnung AS InvoiceInternalId,
        InvoicePosition.VATRate AS VATRate,
        CAST(SUM(ROUND(InvoicePosition.VATValue,2)) AS DECIMAL(25,13)) AS VATSum,
        CAST(SUM(ROUND(InvoicePosition.TotalGrossPrice,2)) AS DECIMAL(25,13)) AS GrossPriceTotal,
        CAST(SUM(ROUND(InvoicePosition.TotalNetPrice,2)) AS DECIMAL(25,13)) AS NetPriceTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalGrossPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS GrossPriceShippingPositionTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalNetPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS NetPriceShippingPositionTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalGrossPrice
                ELSE 0.0
            END -
            CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalNetPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS ShippingCostsVAT,
        CAST(SUM(ROUND(InvoicePosition.DiscountValue,2)) AS DECIMAL(25,13)) AS DiscountValueTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'CODCharge'
                THEN InvoicePosition.TotalGrossPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS GrossPriceCODChargeTotal
    FROM Rechnung.vRechnung AS Invoice
    JOIN Report.InvoicePosition ON InvoicePosition.InvoiceInternalId = Invoice.kRechnung
    GROUP BY InvoicePosition.VATRate, Invoice.kRechnung
)

 

[mvh]

Und noch etwas.
Weil die Rechnungen nicht mehr veränderbar sind:

Spoiler: Bitte prüfen.

SELECT cAuftragsnummern, fVkBruttoGesamt FROM [eazybusiness].[Rechnung].[tRechnungEckdaten]
  WHERE cAuftragsnummern='<hier deine Auftragsnummer>'

 

[mvh]

Hm, ich bin mir da nicht so sicher, dass damit alle Eventualitäten erschlagen sind. Wenn ich es richtig sehe, dann ist fVKBruttoGesamt auf zwei Stellen gerundet, aber fRabattbetrag auf vier, obwohl auch das ein Bruttobetrag ist. Ohne das jetzt komplett durchdacht zu haben, aber das scheint mir eher die potentielle Fehlerquelle, vielleicht auch in diesem Fall.

Aber mal ganz davon abgesehen: Alle meckern über den Staat über zu viel Bürokratie, aber wenn der dann mal Fünfe gerade sein lässt (USt.-Rundungsfehler), dann kommt der noch schlimmere Buchhalter und ist strenger als der Staat.

Nein, fVKBruttoGesamt ist auf 4 gerundet, hier Rechnung-EckDatenBerechnen-Routine
und auch hier werden ZUERST die Positionen summiert und danach auf 4 gerundet.

ROUND(ISNULL(tRechnungPosition.fWertBruttoGesamtFixiert, tRechnungPosition.fAnzahl * tRechnungPosition.fVKNetto * (1.0 - (tRechnungPosition.fRabatt / 100.0)) * (1.0 + (tRechnungPosition.fMwSt / 100.0))), 4) AS fVKBruttoGesamt,

ROUND(ISNULL(tRechnungPosition.fWertNettoGesamtFixiert, tRechnungPosition.fAnzahl * tRechnungPosition.fVKNetto * (1.0 - (tRechnungPosition.fRabatt / 100.0))), 4) AS fVKNettoGesamt,

ROUND(ISNULL(tRechnungPosition.fWertBruttoGesamtFixiert, tRechnungPosition.fAnzahl * tRechnungPosition.fVKNetto * (1.0 - (tRechnungPosition.fRabatt / 100.0)) * (1.0 + (tRechnungPosition.fMwSt / 100.0))) - ISNULL(tRechnungPosition.fWertNettoGesamtFixiert, tRechnungPosition.fAnzahl * tRechnungPosition.fVKNetto * (1.0 - (tRechnungPosition.fRabatt / 100.0))), 4) AS fMwStBetrag,

ROUND(tRechnungPosition.fAnzahl * tRechnungPosition.fVKNetto * (1.0 + (tRechnungPosition.fMwSt / 100.0)) - ISNULL(tRechnungPosition.fWertBruttoGesamtFixiert, tRechnungPosition.fAnzahl * tRechnungPosition.fVKNetto * (1.0 - (tRechnungPosition.fRabatt / 100.0)) * (1.0 + (tRechnungPosition.fMwSt / 100.0))), 4) AS fRabattbetrag,

Insgesamt ist diese Vorgehensweise an 133 Stellen zu finden, der Großteil davon sind Rechnungen/Aufträge/Gutschriften.

 

[Jürgen Jester]

Hiya,
ich bekam gerade eine Antwort auf das Ticket von JTL:

[...] danke für ihre Anfrage.

Rundungsfehler im Cent-Bereich lassen sich leider auf Grund von technischen Gegebenheiten bei der Plattform-übergreifenden Verarbeitung von Aufträgen nicht vollständig vermeiden. Die JTL-Wawi arbeitet intern mit vier Nachkommastellen, manche Plattformen jedoch nur mit zwei - Daher kann es beim Runden der Beträge zu Rundungsdifferenzen kommen.

Das Thema ist bekannt und wird aktuell über das interne Ticket WAWI-80642 analysiert. Leider handelt es sich dabei um ein technisch sehr umfangreiches Thema, weshalb die Lösung nicht einfach umsetzbar ist.

Zur Optimierung haben Sie mehrere Optionen:

1. Wenn ein Auftrag wegen einem fehlenden Cent nicht ausgeliefert werden kann, können Sie die Rundungsdifferenz mit einer manuellen Zahlung ausgleichen, damit Sie den Auftrag ausliefern können. Wie Sie eine Zahlung setzen, wird hier im Guide erklärt: https://guide.jtl-software.com/jtl-...kieren/#zahlung-fuer-einzelnen-auftrag-setzen
   
   Sie können über einen automatischen Workflow mit der Aktion "Zahlung setzen" den Auftrag als bezahlt kennzeichnen, wenn dieser bspw. einen Cent unterbezahlt ist. Zu den Workflows finden Sie hier weitere Informationen: https://guide.jtl-software.com/jtl-...ung-zur-workflow-verwaltung/#workflow-anlegen
   
2. Prüfen Sie, ob die Rappenrundung in den Globalen Einstellungen unter "Zahlungen" > "Allgemein" aktiv ist. Diese Option könnte ebenfalls für Rundungsfehler verantwortlich sein. Weitere Informationen dazu finden Sie hier: https://guide.jtl-software.com/jtl-wawi/global/globale-zahlungseinstellungen-anpassen/#allgemein
   
3. Wenn Sie Rundungsdifferenzen auf den Ausgabe-Dokumenten vermeiden möchten, können Sie die Beträge mit 4-Nachkommastellen anzeigen und Gesamtsummen damit berechnen lassen. Zu der Funktion finden Sie hier weitere Informationen: https://docu.combit.net/designer/de/index.html#!Documents/zahlenwertemitfstrformatieren.htm
   

Beachten Sie bitte, dass wir Sie bei der Anpassung der Vorlagen oder der Einrichtung von Workflows nicht unterstützen können. Wenn Sie dabei weitere Unterstützung benötigen, können Sie sich gerne an einen unserer Servicepartner wenden: https://www.jtl-software.de/servicepartner

Alternativ können Sie Ihre Frage an unsere große Community im JTL Support-Forum oder in unserer offiziellen Facebook-Gruppe stellen:
- https://forum.jtl-software.de
- https://facebook.com/groups/offiziellejtlgruppe

Mit freundlichem Gruß JJ

 

[mvh]

Mit 4 Stellen - keine Fehler. Stimmt.
WARUM werden dann die Summen auf 2 Stellen im Code abgerundet ???
Und auch noch falsch, weil 4 stellig wird addiert und dann auf 2 Stellen reduziert.
richtig wäre - überall 4 stellig oder überall 2 stellig.

 

[Jürgen Jester]

Spoiler: Hier der Code für SSMS oder JTL-Diag

ALTER VIEW [Report].[TotalsInvoice]
AS
(
    SELECT
        Invoice.kRechnung AS InvoiceInternalId,
        InvoicePosition.VATRate AS VATRate,
        CAST(SUM(ROUND(InvoicePosition.VATValue,2)) AS DECIMAL(25,13)) AS VATSum,
        CAST(SUM(ROUND(InvoicePosition.TotalGrossPrice,2)) AS DECIMAL(25,13)) AS GrossPriceTotal,
        CAST(SUM(ROUND(InvoicePosition.TotalNetPrice,2)) AS DECIMAL(25,13)) AS NetPriceTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalGrossPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS GrossPriceShippingPositionTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalNetPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS NetPriceShippingPositionTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalGrossPrice
                ELSE 0.0
            END -
            CASE WHEN InvoicePosition.PositionType = 'ShippingPosition'
                THEN InvoicePosition.TotalNetPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS ShippingCostsVAT,
        CAST(SUM(ROUND(InvoicePosition.DiscountValue,2)) AS DECIMAL(25,13)) AS DiscountValueTotal,
        CAST(SUM(ROUND(CASE WHEN InvoicePosition.PositionType = 'CODCharge'
                THEN InvoicePosition.TotalGrossPrice
                ELSE 0.0
            END,2)) AS DECIMAL(25,13)) AS GrossPriceCODChargeTotal
    FROM Rechnung.vRechnung AS Invoice
    JOIN Report.InvoicePosition ON InvoicePosition.InvoiceInternalId = Invoice.kRechnung
    GROUP BY InvoicePosition.VATRate, Invoice.kRechnung
)

Hey, ich wollte Dir wenigstens noch danken für Deine Mühe, das alles für mich herauszusuchen. Ich muss aber leider gestehen, dass ich soviel Mumm einfach nicht in den Knochen habe, das auf dem SSMS einzuspielen - es hängt hier so viel dran und mir fehlt da die Erfahrung, wenn dabei etwas schiefgeht. Ist echt zum Brechen ...
Viele Grüße,
JJ

 

[mvh]

Hey, ich wollte Dir wenigstens noch danken für Deine Mühe, das alles für mich herauszusuchen. Ich muss aber leider gestehen, dass ich soviel Mumm einfach nicht in den Knochen habe, das auf dem SSMS einzuspielen - es hängt hier so viel dran und mir fehlt da die Erfahrung, wenn dabei etwas schiefgeht. Ist echt zum Brechen ...
Viele Grüße,
JJ

Kein Problem. Kannst Du nicht deine Artikel-Preise auf 2 Stellen reduzieren ? Dann hast Du wenigstens das Problem nicht mehr.

 

[Jürgen Jester]

Kein Problem. Kannst Du nicht deine Artikel-Preise auf 2 Stellen reduzieren ? Dann hast Du wenigstens das Problem nicht mehr.

Hey mvh,
schön nochmal von Dir zu hören. Tja, das hab ich eigentlich. Es tritt nur auf, wenn man die "tolle" Rabattfunktion nutzt. Bei Großkunden ist es leider üblich, dass jeder "seine" Rabatte auf Artikel bekommt - und wenn einer eben wie im Beispiel 15% auf einen Artikel bekommt, zieht sich die Wawi Fehlkalkulation wie ein roter Faden bis zur Summe.
Hab schon gelesen, andere User hier verwursten die Rabatte gleich irgendwie beim Eingeben - aber wenn ich das unserem (sehr) alten Herrn erzähle, dann nimmt er wieder seine Voodoo-Puppe und verursacht mir eine Menge höllischer Kopfschmerzen
Ne, es muss eben anders gehen... habe gerade nochmal das (default) Rechnungstemplate wie oben in Punkt 3 von JTL Support vorgeschlagen mit Fstr$ auf 4 Stellen erweitert. Rate mal .. das Ergebnis ist immer noch falsch.
Klar, weil es eben scheinbar nur Ausgaben sind und der Hase bei der Berechnung im Pfeffer liegt. Ich bin in einer Einbahnstraße und werde jetzt dem Support nochmal schreiben - auch wenn die Hoffnung schwindet.
Danke fürs Lesen - fühlt sich ja an wie ein Kummerkasten hier,
JJ

 

[frankell]

So, wie ich das sehe, müssen "lediglich" die Summen mit vier Nachkommastellen abgebildet werden. Dann würde wohl aus 56,2800 € bzw. 10,6900 € "korrekterweise" 56,2840 € bzw. 10,6940 €, womit 66,98 € stimmen würde.

Probier mal als Formel für "Gesamt netto...":

JTL_DirectQuery("
SELECT CAST(SUM(TotalNetPrice) AS MONEY) FROM Report.InvoicePosition WHERE InvoiceInternalID = "+Str$(Report.InteralId)+"
") + " €"

Für "zzgl. MwSt...":

JTL_DirectQuery("
SELECT CAST(SUM(VATValue) AS MONEY) FROM Report.InvoicePosition WHERE InvoiceInternalID = "+Str$(Report.InteralId)+"
") + " €"

Und für "Rechnungsbetrag":

JTL_DirectQuery("
SELECT CAST(SUM(TotalGrossPrice) AS MONEY) FROM Report.InvoicePosition WHERE InvoiceInternalID = "+Str$(Report.InteralId)+"
") + " €"

 

[Jürgen Jester]

So, wie ich das sehe, müssen "lediglich" die Summen mit vier Nachkommastellen abgebildet werden. Dann würde wohl aus 56,2800 € bzw. 10,6900 € "korrekterweise" 56,2840 € bzw. 10,6940 €, womit 66,98 € stimmen würde.

Probier mal als Formel für "Gesamt netto...":

JTL_DirectQuery("
SELECT CAST(SUM(TotalNetPrice) AS MONEY) FROM Report.InvoicePosition WHERE InvoiceInternalID = "+Str$(Report.InteralId)+"
") + " €"

Für "zzgl. MwSt...":

JTL_DirectQuery("
SELECT CAST(SUM(VATValue) AS MONEY) FROM Report.InvoicePosition WHERE InvoiceInternalID = "+Str$(Report.InteralId)+"
") + " €"

Und für "Rechnungsbetrag":

JTL_DirectQuery("
SELECT CAST(SUM(TotalGrossPrice) AS MONEY) FROM Report.InvoicePosition WHERE InvoiceInternalID = "+Str$(Report.InteralId)+"
") + " €"

Lieber frankell,

Vielen lieben Dank für Deine Mühe
Deine Lösung hab ich einbauen können und hab mal zwei problematische Belege jetzt der Rechnungsstelle neu vorgelegt.
Vielleicht wird das dann ja akzeptiert - so wie Du auch schreibt, ist es dann ja eigentlich einleuchtend.

Ach und für andere Mitleser - ich habe meinen Unmut im Support- Ticket nochmal kund getan, auch wenn der arme Kollege von JTL da nichts dafür kann und bekam diese Antwort:

[...] danke für ihre Rückmeldung.
Leider haben wir zum aktuellem Zeitpunkt keine andere Lösungen und müssen warten bis das angesprochene interne Ticket gelöst wurde sie können noch versuchen die angesprochenen Lösungen aus dem Forum umzusetzen, ob diese vielleicht für sie hilfreich sind, da wir über die Vorlagenanpassung hier weiter nichts diesbezüglich einstellen können.
Mit freundlichem Gruß [...]

Ich erwiderte, dass ich als 'Noob' sicher nicht in der DB Änderungen vornehme und endete mit der Frage, welchen Stellenwert das interne Ticket hat:

Das interne Ticket steht auf Priorität Hoch, es tut mir leid, dass ich ihnen zum jetzigen Zeitpunkt nicht weiterhelfen kann.

Immerhin freut mich, dass noch nicht Hopfen und Malz verloren ist und kann nur jedem User mit diesem Problem raten,
weiter Druck in Form Tickets aufzubauen, dass das Thema irgendwann Geschichte wird.

Viele Grüße und erstmal vielen Dank an alle, die mir bis jetzt hier beigestanden haben
Jürgen