Neu Datev Rechnungsdatenservice 2.0 - Zahlungsart der Gutschrift

[wometo]

Hallo zusammen,

ich verwende jetzt seit einiger Zeit den Datev Rechnungsdatenservice 2.0 und bin damit eigentlich sehr zufrieden.
Einzig bei den Gutschrift hänge ich ein wenig.

Problem: Bei der Übermittlung der Gutschriften wird keine Zahlungsart übergeben.
Hierdurch wird die Gutschrift nicht automatisch zugeordnet und muss manuell erfasst werden.

Habe ich vielleicht irgendwo eine Einstellung übersehen?
Falls nein, wie bewerkstelligt ihr die Zuordnung von Gutschriften?

Vielen Dank & Grüße
Wolfgang

 

[wometo]

Hier mal die Antwort vom Support, vielleicht stellt sich jemand mal die gleiche Frage:
-------------------------
Hallo Wolfgang,

das ist im Moment noch nicht möglich.
Wir haben dazu bereits ein Ticket in unserem issue tracker. Den Status kannst du mit dem folgenden Link nachverfolgen:
https://issues.jtl-software.de/issues/WAWI-53794

Mit freundlichem Gruß

--

Jan-Patrick Schmidt
-------------------------

 

[wometo]

Hallo,

nächster Schritt:
Seit 1.8 wird die Zahlungsart an Datev übergeben.
ABER: Nur wenn die Zahlung in der Gutschrift gesetzt ist. Dies ist lt. Support aber nur manuell möglich:
------------
ich habe nochmal Rücksprache mit den Kollegen gehalten, die sich um die Rechnungskorrekturen kümmern.
Eine Automatisierung ist nicht möglich. Die Zahlung für Rechnungskorrekturen müssten manuell gesetzt werden.
-----------

Jetzt stellt sich mir die Frage wie ihr das macht bei all den Marktplatz Gutschriften, bei denen keine Zahlung aus JTL heraus erfolgt.
ich hätte ja auf einen Workflow gehofft, der die übernimmt. Denn die Gutschriften werden ja bei Amazon auch automatisch erstellt.

Vielleicht habe ich ja etwas übersehen und jemand von euch hat eine Idee, wie man dies automatisieren kann.

 

[Verkäuferlein]

Jetzt stellt sich mir die Frage wie ihr das macht bei all den Marktplatz Gutschriften, bei denen keine Zahlung aus JTL heraus erfolgt.

Leider per "KlickieKlickie", also jede Retoure nach Auslösen der Zahlung markieren, Zahlung setzen und wieder schließen.

Schön wäre, wenn JTL automatische Rückerstattungen ermöglichen würde und dies dann natürlich auch entsprechend hinterlegt wird.

Das geht wohl aber erst, wenn das hier umgesetzt ist:
https://issues.jtl-software.de/issues/WAWI-31427

Aber wie funktioniert denn das mit dem Rechnungsdatenservice genau und wie bekommt ihr dann die Zahlungen (und Gebühren) in Datev?
Direkt über Datev über den Zahlungsdatenservice?

 

[wometo]

Hi,

Tja, das habe ich befürchtet Naja, in der Wawi geht es zu mindestens schneller als in Datev. Somit ist ein wenig was gewonnen.
ich bin aktuell noch mit dem Support in Kontakt, ob es vielleicht noch eine Möglichkeit gibt das nur die Zahlungsart exportiert wird, ohne das setzen einer Zahlung. Sollte ich etwas erfahren, schreib ich hier rein.

Rechnungsdatenservice?
Naja, wir exportieren damit alle Belege aus der Wawi an Datev. Sprich alle Positionen inkl Texte und Beträge, Kundendaten, Steuereinstellungen (UST Nummern)usw... Seit der 1.8 werden auch die Belege als PDF temporär generiert und an das Datev Rechenzentrum übertragen. Somit haben wir dann wirklich alles in Datev.
Zahlungen machen wir komplett in Datev. Hier unterscheiden wir in drei Bereiche:
1. Angebundene Konten (Zahlungsdatenservice): Bank und PayPal
2. Konten mit DB Export: Für alle Amazon Marktplätze ziehe ich die kompletten Zahlungsdaten (inkl. Gebühren) aus der Wawi DB und übergebe diese dann via ASCII Import an Datev.
3. Konten ohne DB Export: Die restlichen Marktplätze hole ich mir von den jeweiligen Marktplätzen. Diese importiere ich dann ins Excel (VBA Skript) und reichere sie dort mit Buchhaltungsdaten (z.B. Rechungsnummern) an und übergebe diese Datei dann wiederum an Datev.

Somit haben wir einen vollständigen Überblick aller Zahlungen, Gebühren und Belege in Datev.

Durch die "Automatisierung" mit VBA Skripten, konnten wir den Aufwand extrem senken. Wir brauchen pro Monat mit ca. 70.000 Buchungen in etwa 5 Stunden

Hoffentlich habe ich dich jetzt hier nicht mit Details erschlagen, ich finde das Thema nur extrem spannend !

 

[Verkäuferlein]

Hoffentlich habe ich dich jetzt hier nicht mit Details erschlagen, ich finde das Thema nur extrem spannend !

Nein, klingt gut, wir arbeiten aktuell mit JTL2Datev UO von Jera und übertragen damit sowohl die Rechnungs- als auch die Zahlungsdaten zu Datev.

Mein Problem bei der Sache ist eben nur, dass ich Bauchschmerzen wegen der GoBD habe, auf die die Steuerprüfer ja immer stärker angespitzt werden.

Die Datev (oder auch die Zahlungsdienstleister selber) tun sich ja leider verhältnismäßig schwer damit, moderne Zahlungsarten anzubinden und die meisten Zahlungsanbieter nutzen scheinbar ja auch keine standardisierten Anbindungen/Schnittstellen.

Weder bei JTL2Datev noch bei Deiner Lösung wäre ich mir so sicher, ob man damit wirklich GoBD-konform unterwegs ist oder ein Steuerprüfer nicht zumindest darauf aus ist, das genauer unter die Lupe zu nehmen.

Cool würde ich daher finden, wenn JTL das irgendwann mal aus einem Guss anbieten würde und man im Prinzip alle Zahlungsdaten, Gebühren und die Belege bzw. Rechnungsdaten direkt aus der Wawi an Datev übertragen könnte/würde und dementsprechend auch alle Zahlungsarten (Anbieter) sauber an die Wawi angebunden sind oder zumindest die Möglichkeit dazu besteht.

Theoretisch müsste JTL dann vermutlich über den Buchungsdatenservice an Datev anzubinden sein, die Frage ist dann wiederum nur, ob die Wawi damit nicht zu sehr in Richtung "FiBu-Software" abdriftet. Aus Sicht der Praktikabilität und der GoBD fände ich das aber das Optimum, weil man dann nur die Wawi und Datev als relevante Programme hat und nicht noch Schnittstellen und manuelle Prozesse gesondert betrachten muss.

 

[wometo]

Hier muss ich dir uneingeschränkt Recht geben.
Die GoBD und deren Auslegung ist wahrscheinlich das größte Problem bei dieser ganzen Thematik.

Für mich ist die Unveränderbarkeit der Transaktionsdaten mit einem vernünftigen Aufwand eigentlich nicht zu gewährleisten. Selbst wenn du eine Systemlandschaft hättest, die zu 100% aus JTL und Datev besteht. Auf Datenbankebene gibt es schlichtweg keine Protokollierung bei JTL und auch bei Datev werden die Übertragungen nicht revisionssicher abgespeichert.

Meine größte Hoffnung ist hierbei folgender Passus:
"Die GoB können sich durch gutachterliche Stellungnahmen, Handelsbrauch, ständige Übung, Gewohnheitsrecht, organisatorische und technische Änderungen weiterentwickeln und sind einem Wandel unterworfen."
Vielleicht ist dies ein Ansatzpunkt für Verhandlungen

In der Praxis versuche ich das Problem von Gebühren aus den Marktplätzen durch das Archivieren der Gebührenrechnungen etwas abzufedern.
Ob das was hilft wird mir die nächste Betriebsprüfung zeigen.

Auf alle Fälle schön, das sich in diesem Forum auch Leute rum treiben, die den steuerlichen Aspekt nicht unterschätzen.