Neu FBA - Reparatur- Tool steht zum Download bereit!

  • Wichtiger Hinweis Liebe Kunden, solltet Ihr den DATEV Rechnungsdatenservice 2.0 nutzen, dann müsst Ihr bis zum 30.06.2024 JTL-Wawi 1.9 installieren. Danach wird die Schnittstelle für ältere Versionen nicht mehr unterstützt.
  • JTL-Connect 2024: Ihr habt noch kein Ticket? Jetzt Early Bird Ticket zum Vorzugspreis sichern! HIER geht es zum Ticketverkauf

Stephan K.

Sehr aktives Mitglied
14. Mai 2014
1.180
269
Nutzt hier keiner Taxdoo?

Dort erhielten wir folgende Info:

Stornorechnung, Rechnungskorrektur, Storno-Rechnungskorrektur

Seit der JTL-Version 1.6.x ist es möglich, Rechnungen und Rechnungskorrekturen zu stornieren und anschließend den zugrundeliegenden Auftrag zu bearbeiten. Damit unser System für jeden Sachverhalt die Daten korrekt importieren kann, beachtet bitte folgende Informationen:

Stornorechnungen werden nicht von Taxdoo importiert. Importiert werden immer die Aufträge (als Bestellungen) und Rechnungskorrekturen (diese entsprechen technisch in JTL einer Gutschrift und werden also solche von Taxdoo importiert).

Bitte erstellt daher bei umsatzsteuerlich relevanten Änderungen an einem bereits importierten Auftrag, für den zudem bereits eine Rechnung erstellt wurde, immer eine Rechnungskorrektur anstatt einer Stornorechnung. Solche Änderungen sind:

  • jegliche Beträge des Auftrags (z.B. Artikelpreise, Versandkosten)
  • Angaben zum Versandlager
  • Angaben zur Lieferadresse (Land und Postleitzahl)
Eine Stornorechnung könnt ihr hingegen erstellen, wenn lediglich die Rechnungsadresse nachträglich korrigiert werden muss, da dies keine Auswirkungen auf die umsatzsteuerliche Bewertung des Auftrages hat.

Solltet ihr eine Rechnungskorrektur stornieren, importiert Taxdoo diese als Gutschrift mit positiven Werten.

In anderen Worten... das Tool ist für Taxdoo Kunden nicht nutzbar.

Wird den von JTL in solchen Fällen nicht mit Firmen wie Taxdoo kommuniziert?

Ich kann hier nicht neutral antworten, da wir schon jahrelang JTL nutzen. Aber auf deine letzte Frage würde ich nur zu gern antworten und meine große Senftube öffnen.
So neutral wie möglich: Wir können froh sein, dass Storno/Korrektur überhaupt als Unterscheidung in 1.6 implementiert wurden.
Steuerlich sollte man nicht unbedingt auf JTL vertrauen.



Hier eine kleine Anleitung für alle, die mit JTL2Datev arbeiten:

Ameise > Buchungsdaten > Rechnungen

Auswahlfelder:
Rechnungsnummer
Storniert am
Externe Bestellnummer
--
Dank zahlreicher bug-Meldungen funktioniert das immerhin derzeit in der 1.7.11 mit den richtigen Werten -
--
Hier löscht ihr im Export alle stornierten Rechnungen heraus und bei den Amazon Bestellnummern alle Suffixe. Liste1

Wechsel zu JTL2Datev
Jetzt öffnet ihr die Amazon Buchungsdaten mit Excel und schaut euch zu jeder "Es existieren 2 Rechnungen" die fehlenden Rechnungsnummern an (wird z.B. je nach Einstellung als externe Auftragsnummer in Belegfeld 1 angegeben). Mit Liste1 und SVERWEIS könnt ihr nun alle Amazon Bestellnummern durch die gültigen Rechnungsnummern füllen lassen.
Ihr macht aus der Zuordnung "Externe Bestellnummer" (die ohne Rechnungsnummern) und den Ergebnissen aus SVERWEIS nun daraus Liste2. Alle Order-IDs haben nun ja ggf. eine Rechnungsnummer erhalten. Nur diese sind gültig.
Alle übrig gebliebenen, auf die dieser Fall nicht zutrifft, müssen geprüft werden

Habt ihr später den DATEV-Export gemacht, gibt es keine Hinweisfelder mehr wie z.B. "2 Rechnungen gefunden." Dafür braucht man Liste2
Hier könnt ihr nun ruhigen Gewissens eure Arbeit aus Liste2 einfach per SVERWEIS abgleichen und füllen lassen und nutzt diese Datevdatei für eure Software oder den StB.

Die wirkliche Denkarbeit findet also in Schritt 2 statt beim Erzeugen von Liste 2. Der Rest ist nur Bastelarbeit für maschinellen Abgleich.
 
  • Gefällt mir
Reaktionen: sanja9 und Nina L.

Stephan K.

Sehr aktives Mitglied
14. Mai 2014
1.180
269
Kleine Bug-Meldung:
Es scheinen auch "TBYB Order Payment" betroffen zu sein. Diese wurden nicht storniert und existieren noch als Duplikat, obwohl die Daten dazu eigentlich im Settlement-Report vorhanden sind (Verfügbar und nicht verzögert).
 

Stephan K.

Sehr aktives Mitglied
14. Mai 2014
1.180
269
Kleine Bug-Meldung:
Das Tool scheint auch nicht zu erkennen, wenn ein Duplikat noch am gleichen Tag erstellt wurde, dass es sich um ein solches handelt.
 

neuling-help

Sehr aktives Mitglied
15. Mai 2016
258
46
Ich kann hier nicht neutral antworten, da wir schon jahrelang JTL nutzen. Aber auf deine letzte Frage würde ich nur zu gern antworten und meine große Senftube öffnen.
So neutral wie möglich: Wir können froh sein, dass Storno/Korrektur überhaupt als Unterscheidung in 1.6 implementiert wurden.
Steuerlich sollte man nicht unbedingt auf JTL vertrauen.



Hier eine kleine Anleitung für alle, die mit JTL2Datev arbeiten:

Ameise > Buchungsdaten > Rechnungen

Auswahlfelder:
Rechnungsnummer
Storniert am
Externe Bestellnummer
--
Dank zahlreicher bug-Meldungen funktioniert das immerhin derzeit in der 1.7.11 mit den richtigen Werten -
--
Hier löscht ihr im Export alle stornierten Rechnungen heraus und bei den Amazon Bestellnummern alle Suffixe. Liste1

Wechsel zu JTL2Datev
Jetzt öffnet ihr die Amazon Buchungsdaten mit Excel und schaut euch zu jeder "Es existieren 2 Rechnungen" die fehlenden Rechnungsnummern an (wird z.B. je nach Einstellung als externe Auftragsnummer in Belegfeld 1 angegeben). Mit Liste1 und SVERWEIS könnt ihr nun alle Amazon Bestellnummern durch die gültigen Rechnungsnummern füllen lassen.
Ihr macht aus der Zuordnung "Externe Bestellnummer" (die ohne Rechnungsnummern) und den Ergebnissen aus SVERWEIS nun daraus Liste2. Alle Order-IDs haben nun ja ggf. eine Rechnungsnummer erhalten. Nur diese sind gültig.
Alle übrig gebliebenen, auf die dieser Fall nicht zutrifft, müssen geprüft werden

Habt ihr später den DATEV-Export gemacht, gibt es keine Hinweisfelder mehr wie z.B. "2 Rechnungen gefunden." Dafür braucht man Liste2
Hier könnt ihr nun ruhigen Gewissens eure Arbeit aus Liste2 einfach per SVERWEIS abgleichen und füllen lassen und nutzt diese Datevdatei für eure Software oder den StB.

Die wirkliche Denkarbeit findet also in Schritt 2 statt beim Erzeugen von Liste 2. Der Rest ist nur Bastelarbeit für maschinellen Abgleich.
Puhh, ein Grund mehr, nicht auf 1.6 bzw. 1.7 zu switchen :)).
 

Ben&Camilla

Aktives Mitglied
1. August 2018
7
0
Hallo Zusammen

Wir haben das Tool durchlaufen lassen aber die fehlenden VCS-Belege werden nicht importiert. (Bei uns wurde aber auch keine doppelte Rechnungen usw. erstellt) WAWI 1.7.10.0
Mit fehlen einfach nur die VCS Rechnungen / Gutschriften.
Testweise habe ich einen der doppelten Auftrag (Lieferschein usw.) gelöscht.

Leider bekommen wir noch immer die Fehlermeldung s. Screenshot.
Fehlermeldung VCS nach Löschung 13.07.2023.JPG

Bei diesem Bespiel gibt es bei mir im System nur noch einen Auftrag!!! Wie bekomme ich die Auftragsmenge angepasst, dass es zur VCS-Menge passt. dann müsste es doch laufen...

Wie ich das sehe, haben einige dieses Problem hier.

Gruß Ben & Camilla
 

Stephan K.

Sehr aktives Mitglied
14. Mai 2014
1.180
269
Puhh, ein Grund mehr, nicht auf 1.6 bzw. 1.7 zu switchen :)).
Es hat gewiss auch Vorteile!
Aber insgesamt wird es inkonsistent.

Eigentlich war der Anlass zum Jahreswechsel (auf die 1.6): Kaufland anbinden. Danach kam ein kurzer Nervenzusammenbruch, da dieses Major Update krass viel Pflege braucht! Man kann nach dem Update nicht sofort weiter arbeiten. Und es gibt auch kein geiles Intro dazu, was alles neu ist, was kaputt gemacht wurde, was geht und was nicht.
Aber ich lese hier noch bei SCX mit und frage mich ernsthaft, wie man so eine billige Plattform wie Kaufland gefühlt über 2,5 Jahre im Open Beta lässt und einfach wie bei eBay grundlegende Dinge fehlen.

Man will einfach zu viel bei JTL (aber die Gerüchte über den Verkauf ergeben da durchaus Sinn). Die Wawi bläht auf, aber hat nicht die Substanz dazu.

Hallo, wurde schon ein Ticket hierzu erstellt? Unser Support hilft Euch gerne weiter.

Nein, tut mir leid. Dazu hatte ich gestern keine Zeit mehr. Aber ich denke, dass der entsprechende Chef-Programmierer mit liest, da es ja ein sehr heikles Thema für JTL ist.
Selbst nach dem Tool-Durchlauf gab es ca. 50 manuelle Stornierungen (mit allem drum und dran, Auftrag, Rechnung, ggf. Korrektur, Lieferschein). Das war ein programmfüllender Abend!

Ich möchte dich als neue Mod trotzdem hier begrüßen!
 

Arne Janson

Offizieller Servicepartner
SPBanner
17. Juni 2019
671
192
Ich kann hier nicht neutral antworten, da wir schon jahrelang JTL nutzen. Aber auf deine letzte Frage würde ich nur zu gern antworten und meine große Senftube öffnen.
So neutral wie möglich: Wir können froh sein, dass Storno/Korrektur überhaupt als Unterscheidung in 1.6 implementiert wurden.
Steuerlich sollte man nicht unbedingt auf JTL vertrauen.



Hier eine kleine Anleitung für alle, die mit JTL2Datev arbeiten:

Ameise > Buchungsdaten > Rechnungen

Auswahlfelder:
Rechnungsnummer
Storniert am
Externe Bestellnummer
--
Dank zahlreicher bug-Meldungen funktioniert das immerhin derzeit in der 1.7.11 mit den richtigen Werten -
--
Hier löscht ihr im Export alle stornierten Rechnungen heraus und bei den Amazon Bestellnummern alle Suffixe. Liste1

Wechsel zu JTL2Datev
Jetzt öffnet ihr die Amazon Buchungsdaten mit Excel und schaut euch zu jeder "Es existieren 2 Rechnungen" die fehlenden Rechnungsnummern an (wird z.B. je nach Einstellung als externe Auftragsnummer in Belegfeld 1 angegeben). Mit Liste1 und SVERWEIS könnt ihr nun alle Amazon Bestellnummern durch die gültigen Rechnungsnummern füllen lassen.
Ihr macht aus der Zuordnung "Externe Bestellnummer" (die ohne Rechnungsnummern) und den Ergebnissen aus SVERWEIS nun daraus Liste2. Alle Order-IDs haben nun ja ggf. eine Rechnungsnummer erhalten. Nur diese sind gültig.
Alle übrig gebliebenen, auf die dieser Fall nicht zutrifft, müssen geprüft werden

Habt ihr später den DATEV-Export gemacht, gibt es keine Hinweisfelder mehr wie z.B. "2 Rechnungen gefunden." Dafür braucht man Liste2
Hier könnt ihr nun ruhigen Gewissens eure Arbeit aus Liste2 einfach per SVERWEIS abgleichen und füllen lassen und nutzt diese Datevdatei für eure Software oder den StB.

Die wirkliche Denkarbeit findet also in Schritt 2 statt beim Erzeugen von Liste 2. Der Rest ist nur Bastelarbeit für maschinellen Abgleich.
FYI JTL2Datev hat eine neue Version 1.36.05 herausgebracht, wo ein Haken gesetzt werden kann: "Bei der Zahlungszuordnung gutgeschrieben Belege ignorieren"

MfG
Arne Janson
 
  • Ich liebe es
Reaktionen: recent.digital

JohnFrea

Sehr aktives Mitglied
21. September 2017
742
225
@Dominic Nelle kannst Du mal was zum Stand der Dinge sagen? Wie sieht es aus mit dem Fehler in 1.5.55.6

Code:
[2023-07-12T10:43:55] [InvoiceCorrectionCorrectionService] Exception: System.ArgumentOutOfRangeException: Das angegebene Argument liegt außerhalb des gültigen Wertebereichs.

   bei FBAKorrektur.Business.InvoiceCorrectionCorrectionService.<Run>d__4.MoveNext().
 

Enrico W.

Administrator
Mitarbeiter
27. November 2014
8.520
1.685
@JohnFrea
Im Beitrag #89 hatte Sebastian darum geben, dass sich diejenigen, bei denen das noch nicht funktioniert, beim Support melden, um alle Spezialfälle abdecken zu können.
Meine Frage wäre: Hast Du das gemacht? Kannst Du mir die Ticketnummer dazu mal geben?
 

timmken

Sehr aktives Mitglied
2. September 2011
283
58
Hi,

also - alle bisherigen Bugfixes vom Tool waren inkrementell, d.h. wenn es ein Problem gab, reicht es, die neue Version vom Tool zu starten und alles wird bereinigt. Bei Problemen mit dem Tool gerne im Support melden, damit wir dann auch noch die letzten Spezialfälle zügig gelöst bekommen.

@fashioncase: Guter Hinweis mit den Lieferscheinen, werde ich dann in v5 einbauen, dass die auch noch gelöscht werden. Ich hatte mich in der ganzen Geschichte total auf den buchhalterischen Aspekt konzentriert und die Lieferscheine nicht berücksichtigt.
könntest du hier ggf. noch ein SQL posten das die offenen Aufträge storniert wenn man die ganzen falschen Rechnungen von Hand und nicht mit dem Tool storniert hat? Wir habe aktuell einige tausend "offene" Aufträge mit erstellten Lieferscheinen im System die sich nicht einfach stornieren lassen.