Das Problem besteht auch in der Version 1.7.10 noch - jedoch, wie es scheint, nur dann, wenn der Beleg eine "Gutschrift" ist.
So ganz klar, wie unter "Gutschrift" und "Rechnungskorrektur" (Ausgabe auf Formular) unterschieden wird, also wann welche Bezeichnung auf dem Beleg steht, habe ich noch nicht herausgefunden - man sucht sich ja mittlerweile einen Wolf.
Der einzige Fall eine "Gutschrift" zu erhalten, wo dann auch "Gutschrift" auf dem Beleg steht und wo die 3 Summen nebeneinander stehen bekam ich mit der Erstellung einer Gutschrift über den Kunden direkt.
Eine "Rechnungskorrektur" wird/ wurde immer dann ausgegeben, wenn eine bestehende Rechnung ganz oder teilweise gutgeschrieben wird (Button: Rechnungskorrektur in der Rechnungsübersicht)
Was auffällt, der Umrechnungskurs wird ebenfalls angezeigt, was er jedoch eigentlich nicht dürfte, da die Darstellungsbedingung "NOT @OneCurrency" ist, d.h. in dem Rückgabewert der Variable ist ein Fehler. (Vorausgesetzt nur eine Währung / nur Euro wird verwendet).
@OneCurrency enthält die folgende Abfrage:
Not @InvoiceCurrencyAndShipFromCountryCurrencyDifferent And Not @InvoiceCurrencyAndTaxCountryCurrencyDifferent And Not @ShipFromCountryCurrencyAndTaxCountryCurrencyDifferent
und müsste TRUE zurückgeben.
Nur in der (manuellen) Gutschrift kommt FALSE zurück - in Storno's, Rechnungskorrektur, Storno vom Storno vom Storno u.s.w. kommt immer TRUE zurück. AUßER - man storniert die Gutschrift. Dann ist im Stornobeleg der gleiche Fehler.
Nach langem Gesuche habe ich den Grund für den Ausgabefehler gefunden:
Das Problem liegt hier in der Art der Anlage der Gutschrift - genauer in der Tabelle
dbo.tgutschrift in der Spalte
cVersandlandWaehrung - hier fehlt der Eintrag
EUR für Euro bei der manuellen Anlage einer Gutschrift über den Kunden.
Daher "weiß" die Gutschrift nicht, das Versandland(währung) und Empfangsland(währung) identisch sind und bewertet die Abfrage im Formular falsch.
Einzige mir bekannte Lösung bis JTL den Bug fixt (und das kann dauern, wenn man sich so manch andere Formularfehler ansieht die Jahre bekannt und immernoch beständig sind, ansieht)
Trage in der Datenbank manuell das EUR in die oben genannte Spalte und der Fehler ist weg. Einen anderen Weg habe ich nicht gefunden - auch keinen
Workflow, um den Wert zu setzen.
Da muss JTL ran und das Problem fixen - ich weißn das hilft nicht viel aber immerhin weißt Du jetzt woran es liegt.
Besten Gruß