Inaktiv Summe in professioneller Rechnungsvorlage

JTL_Newbie

Aktives Mitglied
28. Mai 2011
35
0
Moin Community,

ich habe aktuell das Problem, dass meine Vorlagen für Rechnung, Lieferschein, etc. nicht für IGL bzw. Differenzbesteuerung funktionieren.

Nun habe ich mir die "professionelle Vorlage" in der Wawi erstellt und möchte diese anpassen. Dabei stellen sich mir folgende Hürden:

Bei der Rechnung wird die Summe bei einigen Rechnungen korrekt (s.Bild 1) dargestellt. Bei Rechnungen ohne MwSt. wird neben der Summe noch ein Betrag in Klammern angegeben (s.Bild 2). Komischerweise taucht bei manchen Rechnungen, die nur mit 19% versteuert werden, ebenfalls diese Klammern auf.

Ich möchte diese Klammern nun entfernen. Wie gehe ich da vor? Ich kann in dem Vorlageneditor dazu keine passende Stelle finden.

Da ich die Rechnungsvorlage ganz nett finde, möchte ich Sie auch weiter anpassen. Diese Mühe mache ich mir aber erst, wenn ich mit den Klammern weitergekommen bin.

Über eure Hilfe bin ich euch sehr dankbar.

Gruß

JTL_Newbie
(Version: 1.0.11.2)

Bild 1:
Den Anhang 18896 betrachten

Bild 2:

Den Anhang 18897 betrachten
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
AW: Summe in professioneller Rechnungsvorlage

Deine Anhänge lassen sich nicht öffnen. Hast Du die als Links oder über den Button "Grafik einfügen" im Toolbar eingefügt?
 

JTL_Newbie

Aktives Mitglied
28. Mai 2011
35
0
AW: Summe in professioneller Rechnungsvorlage

Moin,

ich habe sie über Grafik einfügen eingestellt.

Anbei noch einmal:

Bild 1:
vorlage_summe_01.jpg

Bild 2:

vorlage_summe_02.jpg

Gruß
 

Anhänge

  • vorlage_summe_01.jpg
    vorlage_summe_01.jpg
    14,1 KB · Aufrufe: 76
  • vorlage_summe_02.jpg
    vorlage_summe_02.jpg
    16,3 KB · Aufrufe: 67

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
AW: Summe in professioneller Rechnungsvorlage

Erst einmal grundsätzlich dazu, was da eigentlich mit diesen Klammerwerten getrieben wird: Wenn die Währung im Versandland, also dem Land AUS DEM versandt wird, nicht mit der Währung des aktuellen Vorgangs übereinstimmt, soll der Rechnungsbetrag einmal vor der Klammer in der Vorgangswährung und dann noch einmal in Klammern mit dem aktuell gesetzten Wechselkurs konvertiert in der Währund des Landes ausgegeben werden, aus dem versandt wird. Eigentlich soweit sehr schöne Idee.

Zu Deinem Problem gibt es denn auch zwei Antworten, die eine ist erfreulich, die andere eher nicht...

Erfreulich:

Wenn Du Dir in der Layout-Vorschau oder im Layout einmal den Berichtscontainer anschaust, gibt es da nur eine Stelle, an der "Gesamtpreis Netto" steht. Gleich daneben steht ein Feld, das mit "LocCurrL$(" anfängt. Klickst Du da drauf kommst Du direkt in den Formeleditor für diese Formel und dann springt Dir dort gleich das ' (' mitten in der Formel entgegen. Hier bist Du also richtig und kannst dann die Logik für die Klammerwerte leicht nachverfolgen. Der Formeleditor ist sehr mächtig und die Formeln sehen deshalb oft komplex aus, meistens sind sie es aber nicht, sondern sie sind nur "lang". Und wenn ich wirklich nicht mehr weiter weiss, kopiere ich mir die gesamte Formel raus in einen Editor mit Klammernverfolgung (z.B. Notepad++). Dann wird's leichter...

Weniger erfreulich:

Die Variablen, die innerhalb der Wawi für das Versandland gesetzt werden (Gebietsschema, Währung und Wechselkurs) weisen bei meinen Tests mit Rechnungen, egal ob innerdeutsch, EU, EFTA oder Drittländer praktisch alle bei der einen oder anderen von diesen drei Variablen falsche Werte auf. Es reicht aber in der Formel, die hier angewandt wird schon wenn Vorgang.Auftrag.Versandlandswährung inkorrekt gesetzt ist und Du bekommst Klammerwerte angezeigt.

Bei mir ist das Versandland immer DE, aber in den meisten meiner Tests ist Vorgang.Versandlandswährung leer und das reicht auch schon aus, um Klammerwerte anzuzeigen. Aber auch Vorgang.Gebietsschema ist in vielen Fällen falsch gesetzt und lautet dann bei mir "en-IE" statt "de-DE", so dass die Beträge das Euro-Zeichen dann nicht hinter, sondern vor dem Betrag stehen haben.

Ich habe auch getestet, ob dieses Problem vielleicht nur bei von JTL Wawi 0.99923 importierten/konvertierten Datensätzen auftritt, aber auch wenn ich einen Sofortauftrag erstelle stehen die Chance ohne Klammerwerte durchzukommen eher 50:50.

Fazit: Hier scheint es sich definitiv um einen Bug in der Wawi zu handeln. Ich werde das einmal im Bug-Forum posten.