Neu angelegte Druckvorlage 1.6 - Finde den Fehler & suche Hilfe

[Stephan K.]

Hi,
kurze Eckdaten:

Amazon VCS - also man muss innerhalb von 24 Stunden eine Rechnung hochladen.

Update auf 1.6 an Weihnachten - großer Fehler.
Viel zu viele Fehler, undokumentierte Änderungen, veränderte Hintergrundprozesse mit Datenabruf... Restore unmöglich.


Daher meine Frage an die community, die die 1.6 schon länger nutzen: Wie kann man hier eine ordentliche Rechnung erzeugen, die die Mindestansprüche einer Rechnung befriedigt?
JTL scheint es einfach nicht drauf zu haben. Es ist schlampig.
Man könnte ja unbeirrt weiter arbeiten, aber nein, JTL hat wohl im Größenwahn wie toll sie doch sind, ja auch die alten Vorlagen teils funktionslos gemacht, weil Variablen einfach nicht mehr vorhanden sind... Ist das effizient? An die SQL-Profis gerichtet.
Und ist das verantwortungsbewusst? An den gesunden Menschenverstand gerichtet.

Hier die out-of-the-box Vorlage von JTL, die nur in der Formatierung ein bisschen Rumgespiele erfahren hat (also andere Farben, ggf. andere Schriftgrößen und die Mehrwertsteuer "19,00" wurde auf "19" gekürzt:

Wie kann man das Rechnungsdatum und das Lieferdatum korrekt ausgeben?
Wieso tauchen Rundungsfehler beim Einzel- und beim Gesamtpreis einer Position auf?
Wieso sind die Nettobeträge nicht aufgeführt?
Wieso ist der Tabelleninhalt der Nettobeträge plötzlich nach links gerückt? Bei manchen ist das so, nicht bei allen....
Wieso taucht der offene Rechnunbgsbetrag nicht auf? Da Amazon = bezahlt, es muss 0,00 sein.
Wieso wird daher - wahrscheinlich, JTL hat hierzu ja keine Äußerung oder Anleitung zur Hand gegeben - ebenso falsch von der DRUCKVORLAGE das Ergebnis/die Bedingung gewählt und nicht der festgeschriebene Wert der VCS-Rechnung? Da der Betrag 0 ist, darf nicht der Hinweis zum Bezahlen auftauchen. So steht er in der Rechnung und bei Amazon. Nur nicht bei JTL.

Bei den ganzen Test gestern: Es hat alles funktioniert. Beim Blick heute ins Archiv für die Rechnungen von gestern: Man könnte JTL gegen die Wand klatschen. Es hat wieder Mal unerwartete Ergebnisse produziert und man haftet dafür.

 

[mh1]

Hallo,

es wird schwierig auf die vielen Fragen zu antworten bzw. erstmal zu erkennen, was eine konkrete Frage ist und was eine Äußerung deiner Unzufriedenheit ist

Ich versuche es mal und fange mit dem ersten an. Vielleicht springen dann andere ein.

Wie kann man das Rechnungsdatum und das Lieferdatum korrekt ausgeben?

Was genau meinst du mit "korrekt"? In dem Screenshot von dir steht ja jeweils "27.12.2022". Sollte dieses Datum anders formatiert werden, oder müsste es ein ganz anderes Datum sein?
Falls es ein anderes Datum sein müßte, wie steht es denn im Auftrag? Denn die Standard Druckvorlagen berechnen da ja nichts, sondern zeigen nur die Werte aus der Wawi an.

Wieso tauchen Rundungsfehler beim Einzel- und beim Gesamtpreis einer Position auf?

Auch hier die Frage, wie steht es denn in der Wawi? Also welche Preise sind im Artikelstamm für den Artikel hinterlegt und wie siet es dann in dem Auftrag aus?

Update auf 1.6 an Weihnachten - großer Fehler.

Ja, das war es wohl. Wird ja auch in der Checkliste zum Upgrade so beschrieben . Bringt dir jetzt natürlich nichts mehr, aber man muss jetzt halt mit Ruhe Problem für Problem einzeln ankucken und beheben

Viel zu viele Fehler, undokumentierte Änderungen, veränderte Hintergrundprozesse mit Datenabruf... Restore unmöglich.

Was genau meinst du denn mit "Restore unmöglich".
Ein Restore, also das Wiederherstellen der Datenbank aus einem Backup ist doch eine Funktion des SQL-Servers. Das dürfte doch das Update auf die 1.6 nicht zerstört haben...???

 

[Stephan K.]

Es ist schwer nicht unzufrieden zu sein bei solchen Mängeln.
Den Update-Guide habe ich sehr penibel in der Theorie vorbereitet. In allen Punkten, die möglich sind. Hast du dir den billigen, kurzen Satz von JTL dazu mal durchgelesen? "Bitte prüfen Sie, ob individuelle Anpassungen an Ihren Vorlagen noch kompatibel sind." Und die Realität? "Für unsere in IT-Dingen nicht unbedarfte, zahlende Kundschaft: Wir haben Variablen, die sich per Vokabular nicht 1:1 übersetzen lassen, einfach ins Englisch getauscht. Alte entfernt, neue unvollständig und fehlerhaft implementiert (falsch hard-coded per SQL) und wieso bei einem SPLIT-Auftrag von Amazon eine Rechnung richtig und die andere falsch erstellt wird: Wir haben zusätzlich auch undokumentiert Prozesse vom API-Datenabruf mit Amazon geändert. Manches steht jetzt sofort, anderes nur mit Verzögerung zur Verfügung und so richtig eine perfekte Zuordnung kriegen wir ehrlich gesagt auch nicht hin."
Und das ist nur das Wissen, das ich aus 2,5 Tagen mit List & Label, VCS und der 1.6 per data-crawling im forum und durch mich selbst habe.

Zurück zum lösungsorientierten Ansatz:

Es gibt nur ein paar Datumsvariablen. Es muss für den Versandhandel in einer Rechnung beides geben: Rechnungs- und Lieferdatum. Und ja, bei Aufträgen von gestern (mit VCS-Rechnung) steht das heutige Datum der Lieferung mit drin. Oder anders ausgedrückt: Die paar Datumsmöglichkeiten spucken entweder nur ein einziges Datum aus oder gar keines. Es ist schlichtweg falsch, wenn man es korrekt nimmt. Und das muss man.

Rundungsfehler durch unendliche Dezimalstellen im Artikelstamm?
Nein. Damit hat es nichts zu tun. Schau es dir nochmal an. Ein Artikel, eine einzige Position. Beim Einzelpreis wird anders gerechnet/gerundet als beim Gesamtpreis. Einmal ",89" und einmal ",90" und das beim gleichen Artikel.

Wenn Amazon-Rechnungen per se schon bezahlt sind, wieso wird dann zufällig doch aus der Druckvorlage diese Bedingung abgegriffen und der Kunde erneut zur Zahlung aufgefordert? Oder fehlt im Hintergrund nur der entsprechende Datensatz, weil JTL mal wieder geschlampt hat und nichts erklärt oder Hinweise gibt oder die eigene Software (nur JTL kennt die eigene Software unter der Haube)? Das würde dann bedeuten, dass die Druckvorlage wegen JTL Inkonsistenz (um nicht einen ähnlich klingenden Namen zu verwenden) einfach jedes Mal ein anderes Ergebnis liefert. Heute: Bitte nochmal zahlen. Morgen: Die Steuer fehlt, aber immerhin haben Sie bezahlt und schulden uns 0 Euro.
Und hier spielt eben auch ein neues, geändertes Zeiterfassungssystem (undokumentiert, scheinbar hat JTL vergessen das zu erwähnen) mit hinein: Wann werden welche Daten abgegriffen und wieso/warum wird dann manchmal bei fehlenden Daten die Ausgabe nicht on-hold gestellt oder gleich ganz abgebrochen? Das macht JTL doch an anderer Stelle auch so! Nein, dieses Mal wird nur die Hälfte richtig aufgedruckt und dem Kunden zugeschickt, aber wenn man es so und so und so und so macht, DANN hat man endlich eine saubere, korrekte Rechnung und Buchhaltung. In Deutschland. Aber vielleicht sitzt JTL auch im Ausland.
Gehts noch!?

Das hier sind beide verwendeten Variablen.
EKs werden immer zweistellig eingetragen, VK-Preise selbstverständlich per VCS angegeben. Also "manipulationssicher."
Ich denke noch immer nicht, dass der Fehler am User liegt.

LocCurrL$ (InvoicePosition.TotalGrossPrice, JTL_GetCulture(Report.CountryISO, Report.LanguageISO, Report.CurrencyISO))   = x,90
LocCurrL$ (InvoicePosition.GrossPricePerUnit, JTL_GetCulture(Report.CountryISO, Report.LanguageISO, Report.CurrencyISO))  = x,89

Und ja: Ganz oft funktioniert es richtig. Mir als dummer Laie würde dazu beim Qualitätscheck jedoch einfallen: Wir haben da was selbst programmiert. Also alle zweistelligen Dezimalstellen (100 der Zahl) mit diesen Variablen durchexerzieren und schauen, ob man vielleicht doch etwas mit heißer Nadel gestrickt hat...
Denn dann hätte man gesehen, dass manche Werte eben nicht identisch gerundet werden.

 

[mh1]

Es muss für den Versandhandel in einer Rechnung beides geben: Rechnungs- und Lieferdatum.

Es gibt doch beides?!?
Also in unseren Rechnungsvorlagen kriegen wir das Rechnungsdatum mit Report.CreationDate und das Lieferdatum mit Report.ServiceDate
Nochmals die Frage: ist denn in der Wawi überhaupt ein Lieferdatum gesetzt?
Also wir geben dann als TT.MM.JJJJ formatiert aus z.B. LocDate$(Report.CreationDate, "de-DE") oder du holst dir das de-DE mit JTL_GetCulture() => JTL_GetCulture(Report.CountryISO, Report.LanguageISO, Report.CurrencyISO))

Ein Artikel, eine einzige Position. Beim Einzelpreis wird anders gerechnet/gerundet als beim Gesamtpreis. Einmal ",89" und einmal ",90" und das beim gleichen Artikel.

Ich würde die Preise aber doch nochmals im Artikelstamm prüfen und zum Test mal überschreiben und nochmals einen Auftrag erstellen.
Wenn du die Möglichkeit hast auch in die Datenbank zu kucken, dann kannst du da ja auch mal schauen. Vielleicht kommt man dann dahinter, an welcher Stelle was falsch eingeben wurde, oder wer/wann/wo falsch rechnet.
Denn eigentlich sollte die Druckvorlage keine eigenen Berechnungen anstellen.
Evtl. hast du ein auch Testsystem, wo du einfach mal ein bisschen drin rumspielen und solche Dinge testen kannst.
Ansonsten direkt ein Ticket aufmachen.

Wenn Amazon-Rechnungen per se schon bezahlt sind, wieso wird dann zufällig doch aus der Druckvorlage diese Bedingung abgegriffen und der Kunde erneut zur Zahlung aufgefordert?

Auch hier nochmals die Frage, wie sieht denn der Auftrag in der Wawi aus?
Bei uns funktionieren diese Abläufe. Wenn ein Auftrag in der Wawi bezahlt ist, steht auf der Rechnung z.B.: Rechnungsbetrag 1€ ./. Zahlung vom ... 1€ = offener Betrag: 0
Aber berechnet wird das widerrum in der Wawi nicht in der Druckvorlage. Ich denke, es wäre falsch, wenn du in die Druckvorlage sowas wie IF Amazon THEN Report.OpenGrossPrice = 0 (Pseudocode) einfügst.

Und hier spielt eben auch ein neues, geändertes Zeiterfassungssystem (undokumentiert, scheinbar hat JTL vergessen das zu erwähnen) mit hinein: Wann werden welche Daten abgegriffen und wieso/warum wird dann manchmal bei fehlenden Daten die Ausgabe nicht on-hold gestellt oder gleich ganz abgebrochen? Das macht JTL doch an anderer Stelle auch so! Nein, dieses Mal wird nur die Hälfte richtig aufgedruckt und dem Kunden zugeschickt, aber wenn man es so und so und so und so macht, DANN hat man endlich eine saubere, korrekte Rechnung und Buchhaltung. In Deutschland. Aber vielleicht sitzt JTL auch im Ausland.
Gehts noch!?

?? 🤔

Und ja: Ganz oft funktioniert es richtig. Mir als dummer Laie würde dazu beim Qualitätscheck jedoch einfallen: Wir haben da was selbst programmiert. Also alle zweistelligen Dezimalstellen (100 der Zahl) mit diesen Variablen durchexerzieren und schauen, ob man vielleicht doch etwas mit heißer Nadel gestrickt hat...
Denn dann hätte man gesehen, dass manche Werte eben nicht identisch gerundet werden.

??? 🤔

 

[Stephan K.]

Beispiel:

Auftrag vom 22. + Versand am 23. (ja, geprüft).



Ausgabe in der Druckvorlage wie gehabt ohne Veränderung:



Amazon VCS

Es ist egal, ob es ein Kalendertag Unterschied oder mehrere sind.

 

[mh1]

Beispiel:

Auftrag vom 22. + Versand am 23. (ja, geprüft).
Den Anhang 92419 betrachten

Mmmh - Das sieht ja komisch aus. Ich weiß aber natürlich auch nicht, welche Tabelle oder Sicht du in dem Screenshot abgefragt hast.

Wenn ich bei uns in die Report.Invoice schaue, ist bei den Rechnungen, die im Auftrag ein Lieferdatum hinterlegt haben immer die Uhrzeit 00:00. Das ist deshalb, weil ja immer nur ein Lieferdatum eingeben wurde (ohne Uhrzeit) und dann hängt der SQL-Server automatisch 00:00 an.

select CreationDate, ServiceDate from report.invoice where CreationDate<>ServiceDate order by CreationDate desc

CreationDate            ServiceDate
----------------------- -----------------------
2022-09-07 13:58:24.000 2022-09-09 00:00:00.000
2022-05-12 13:55:34.960 2022-05-09 00:00:00.000
...

In unserem Falle wird dann auch in der Rechnung richtigerweise als Rechnungsdatum das CreationDate genommen und als Lieferdatum das ServiceDate.

War denn das bei dir schon immer falsch, oder tritt der Fehler erst seit dem Update an Weihnachten auf?

Wie auch immer. Auf jedenfall solltest du dich damit an den Support wenden (tel. und/oder ggf. ein Ticket aufmachen).
Evtl. springt hier auch noch ein anderes Forenmitglied ein.