In Bearbeitung Rabatte werden in den Exports falsch behandelt.

  • Temporäre Senkung der Mehrwertsteuer Hier findet ihr gesammelt alle Informationen, Videos und Fragen inkl. Antworten: https://forum.jtl-software.de/threads/mehrwertsteuer-senkung-vom-01-07-31-12-2020-offizieller-diskussionthread-video.129542/

patoc

Aktives Mitglied
20. Juni 2017
41
3
Liebes Forum,

wir haben drei Kassen im Einsatz und sind gerade dabei, den ersten Monatsabschluss durchzuführen. Generell versuchen wir noch den besten Weg zu finden, die Daten an DATEV zu übergeben aber zuvor alles korrekt validiert zu haben. Dazu Ziehen wir die folgenden Exports heran:
1. Kassenbuch (PDF)
2. Bons (CSV)
3. DATEV-Buchungsstapel (CSV)

Die Versionen: WAWI 1.5.30.1 und die POS: 1.0.2.5 - also alle auf dem aktuellen Stand!

Erste Feststellung: Unsere Bons haben eine Länge von 13 Zeichen - die werden aber in den meisten Fällen einfach frühzeitig abgeschnitten:
a) auf dem Kassenbon nach 8 Zeichen
b) im Datev-Export nach 12 Zeichen
c) im Kassenbuch passt es aber! ;)
-> Kriegt man das irgendwie hin, auf dem Bon alle 13 Zeichen anzuzeigen?

Was aber viel gravierender ist: Die Behandlung von Rabatten passt nicht!! Nehmen wir ein Beispiel:
> Kaffee 9,90
> Pralinen 1,30
> Rabatt -1,68
> Summe: 9,52

So schaut es bei den einzelnen Export-Formaten aus:
1. Kassenbuch -> Endsumme des Bons passt, also alles gut!
2. Bons -> Der Rabatt wird als eigene Zeile aufgeführt, was schon mal gut ist. ABER: Der Rabatt wird POSITIV dargestellt, also als ein Umsatz. Damit stimmt natürlich die gesamte Umsatzberechnung nicht
> 9,90
> 1,30
> 1,68 (positiv, obwohl abgezogen werden müsste!)
3. DATEV-Buchungsstapel -> Ganz schlimm: Da wird der Rabatt einfach auf den Bon addiert bzw. der Rabatt einfach ignoriert:
> 11,20 im Soll

D.h., weder den Export (Bons) noch der DATEV-Export ist so zu gebrauchen.

Kennt Ihr diesen Fehler auch?

@JTL: Ist Euch das bewusst?

Oder haben wir hier irgend eine Einstellung übersehen? Wie gesagt, auf dem Kundenbon passt bis auf die Bonnummer alles - der Rabatt wird also schon als Rabatt verstanden. Aber buchhaltärisch passt das überhaupt nicht.

Irgendwelche Ideen?

Liebe Grüße und Dank!
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
...hat etwas keine(r) dieses Thema? Das müsste doch bei jedem Monatsabschluss zu Fehlern führen, die - hoffentlich - dem Steuerberater auffallen?! LG
 

Janusch

Administrator
Mitarbeiter
24. März 2006
13.730
213
Hallo,
Bon Länge ist auf 12 Zeichen begrenzt, das ist die länge die von Datev erlaubt ist im Export. Beim Drucken ist es von der Druckbreoze abhängig: 39 Zeichen = 7, 42 Zeichen = 8 und 48 Zeichen = 10

Ich bin alle Kombinationen durchgegangen, dabei die 2 Probleme erkannt:

- Buchungsexport - CSV - durch die Umstellung der Rabatte ist es nicht aufgefallen, die Rabatte müssen negiert werden.
- Datev - Hier gibt es ein Problem mit Positionsübergreifenden Belegrabatten. In der Regel werden alle anderen Varianten von den Positionen direkt abgezogen

Beide Probleme sind in der nä. Version behoben.
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
Guten Abend Janusch,

okay, sehr gut - es freut mich, dass Du es rekonstruieren konntest!

Zwei Fragen:
1. Wann kommt die nächste Version?
2. Kann ich dann mit dieser neuen Version den alten Monat erneut, dann aber korrekt exportierten?

Lieben Dank und Gruß!
 

Janusch

Administrator
Mitarbeiter
24. März 2006
13.730
213
Hallo,
die Version testen wir aktuell, denke das wir diese Mo. rausgeben können.

Alte Monate können neu korrekt exportiert werden.
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
Hallo Janusch,

nur zum Verständnis: " denke das wir diese Mo. rausgeben können " -> heißt Montag, richtig?

Dann würden wir den Montag abwarten, bevor wir die Exports für den aktuellen Monatsabschluss manuell aufbohren.

Lieben Dank
 

Janusch

Administrator
Mitarbeiter
24. März 2006
13.730
213
Genau, ist vom Test abhängig und die Veröffentlichung am Mo. kann auch noch 12 Std. dauern im Playstore wo wir keinen Einfluss drauf haben.
 

kostjas

Aktives Mitglied
6. Februar 2018
8
0
Ergänzend dazu haben wir festgestellt, dass der Rabatt in den exportierten Belegen als eine Position aufgeführt wird. Enthält der Bon mehrere Positionen mit verschiedenen MwSt.- Sätzen, ist eine Trennung nicht möglich.
Es müssen pro MwSt.-Satz der verrechnete Rabatt als eigene Zeile ausgegeben werden.

Danke für die schnelle Reaktion seitens JTL!
 

Janusch

Administrator
Mitarbeiter
24. März 2006
13.730
213
Hallo,

Wenn ich einem Beleg dem Kunden für einen Artikel mit 19% einen Aritkelrabatt gebe und nicht für die Artikel mit 7% dann ist es gewollt und auch legitim.
Bei einem Beleg wird der Beleg-Rabatt der höheren USt. zugewiesen, das könnte genauso ein Artikelrabatt sein. In einer CSV kann man die beiden Arten nicht mehr unterscheiden.

Kann der Händler nicht entschieden was er rabattiert?
 

kostjas

Aktives Mitglied
6. Februar 2018
8
0
Danke für deine schnelle Antwort.
Meine Frage bezieht sich auf einen Bon, bei dem alle Positionen mit einem Rabatt reduziert werden. Es ist dabei doch für eine korrekte Berechnung der USt. notwendig, den Rabatt im Beleg nach 5% und 16% zu unterscheiden. Nach welcher Logik wird der Belegrabatt der höheren USt. zugewiesen?
Oder habe ich einen Denkfehler?
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
Hallo Janusch,

wir haben nun für alle drei Kassen den Monatsabschluss basierend auf dem DATEV-Export und dem BONs-Export durchgeführt. Es gab noch mindestens 5 Bugs. Diese habe ich dem Support mitgeteilt, inkl. Bildmaterial. Hier nochmal für Dich gepostet:

Zu den JTL POS Bugs im Reporting: Wir haben den DATEV-Export mit den Bons abgeglichen
  1. Die Verkaufssummen weichen zwischen DATEV und Bons geringfügig ab. Wahrscheinlich handelt es sich hier um einzelnen Positionen - die konnten wir aber noch nicht identifizieren. Hier die Zusammenfassung der Abweichungen für drei Filialen
    1602658196388.png

  2. BONs: Hier stimmen die folgenden Felder nicht
    -> Die Quantity passt, aber Unit Price ist bereits die Summe und Gross Total multipliziert die "bereits Summe" nochmal mit der Quantity
    1602657880235.png

  3. Oftmals wird beim Bezahlen mit teils Bar UND teils Gutschein aus dem Gutschein im DATEV-Export ein ominöser Geldtransit
    1602657911714.png
    => 11,50 Gutschein wir mit Geldtransit und Konto 1460 ausgegeben. Weder das Konto noch der Begriff sind so richtig und wurden von uns so auch nicht definiert:
    1602657934782.png

  4. Die Summen auf dem Kassenbon stimmen teilweise nicht, hier zwei Beispiele

    1602657973756.png1602658021276.png

    -> Wie wir analysiert haben kamen zumindest diese beiden Falschsummen irgendwie durch gewährte Rabatte zustande

    1602658056864.png

    Dieser Rabatt ist wie folgt angelegt, und funktioniert in den meisten Fällen aber auch korrekt:
    1602658081192.png
    1602658093692.png
  5. Zähldifferenzen werden nicht exportiert. D.h., wenn ein Mitarbeiter eine Differenz zu Soll- und Ist-Kassenbestand hat kann er diesen zwar eingeben, er wird aber weder bei den Bons noch im DATEV-Export ausgegeben. Damit stimmt natürlich den Kassenbestand in DATEV nicht, sodass wir diese Differenzen nachtragen mussten:

    1602658142273.png

Beste Grüße und Dank
 
Zuletzt bearbeitet:

Janusch

Administrator
Mitarbeiter
24. März 2006
13.730
213
Hallo,
da scheinen noch die Bilde rzu fehlen. So kann man sich keinen Bild machen.

Der Fehler mit dem Bon - Rabatt hatte Auswirkungen auf einige Berechnungen im Bon und Datev - Export.

2. Quantity, das wird nicht an Datev übergeben
3. Die POS kennt keine Gutscheine, alle Zahlungsarten außer Bar werden wie Kartenzahlung behandelt. Deshalb geht es an Transit.
4. Bsp. fehlt, könnte folge von dem Rabatt Bug sein
5. Wie speichert ihr das im datev? Ich hab hier unseren externen Berater angefragt, so etwas gibt es nicht lauft denen. Entweder muss der Verkäufer das Geld aus eigener Tasche reinlegen oder eine priv. Entnahme machen.
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
Guten Morgen Janusch,

vielen Dank für Deine Antwort. Entschuldige, ich wusste nicht, dass man Bilder auch inline einfügen kann - habe ich nun nachgeholt, siehe oben im Post.

Ad 1: Okay, hoffen wir hier also, dass es beim nächsten Monatsabschluss passt. Denn dieses Mal können wir das denke ich nicht mehr nachstellen.
Ad 2: Quantity ist ja korrekt. Aber Gross Unit Price und Gross Total sind falsch zugeordnet bzw. berechnet. Unabhängig von DATEV.
Ad 3: Aber wir haben doch die Zahlart "Gutschein einlösen" definiert:
1602658532093.png

und so kann diese definierte Zahlart beim Bezahlen ausgewählt werden:

1602658580795.png

==> da würde man doch erwarten, dass hierfür das hinterlegte Konto genutzt wird (4102) und nicht Geldtransit? So haben wir es im DATEV-Export für uns auch entsprechend korrigiert. Aber es wäre sinnvoll, wenn das im DATEV-Export direkt passieren würde und nicht noch manuelle Eingriffe danach benötigen würde.
==> Und für die beiden hinterlegten Karten (EC, Kredit) werden ja auch die dort definierten Konten 1461, 1462 im Export verwendet?!

Ad 4: Schau Dir mal bitte das Bildmaterial oben an. Ja, es hängt am Rabatt. Ob das behoben ist, kann ich natürlich nicht beurteilen. Super wäre es!
Ad 5: Wir haben daraus Korrekturbuchungen gemacht. Aber verstehe ich Dich richtig, dass es hier eigentlich gar keine Differenzen geben darf? Dann wäre es natürlich auch sinnvoll, wenn die Kasse hier einen Hinweis ausgeben würde oder die Zählung so nicht akzeptiert wird. Denn der ein oder andere Mitarbeiter denkt sich dann einfach: "naja, habe ich halt ne Differenz... was soll's?!" Das Thema ist halt, dass so der DATEV-Export nicht stimmig ist, da so der Kassenbestand nicht stimmt.

Herzlichen Dank und Gruß!
 

Janusch

Administrator
Mitarbeiter
24. März 2006
13.730
213
Hallo,
die Differenzen bei 1 und 4 das sieht nach dem Rabatt-Bug aus. Das betraf Kassenbuch und die Exporte.

Bei 2. das ist der normale CSV Export, das prüfen wir. Ich bin von datev ausgegangen.

3. Das ist nur der Name, den kann jeder Frei eingeben. Der Typ aller Zahlungsarten ist "Kartenzahlung" und diese werden im Export immer an Transit Konto gebucht. Wir sind dabei echte Gutschiene zu implementieren, so wird bald in der Zahlungsart neues Feld dazu kommen, wo man den Typ auswählen kann zwischen "Kartenzahlung" und "Gutschein". Danach wird der Export wissen wie er die Datensätze abspeichern muss.

5. Das ist der Optimal Fall. Es war nur die Antwort die uns gegeben wurde. Wir könnten für die Differenz auch eine Entnahme als Beleg erstellen. Es ist aber von Fall zu Fall unterschiedlich. Existiert eine Mankoabrede so kann der Mitarbeiter dafür haften und muss die Differenz bezahlen, gibt es keine haftet der Arbeitgeber dafür.
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
Hallo Janusch,

okay - sehr gut soweit.

Zu 3: Das ist für mich nur bedingt nachvollziehbar. Denn 1) Werden reine Kartenzahlungen nie über Geldtransit gebucht sondern über das jeweilige Kartenkonto (1461, 1462) und gegen das Umsatzkonto (4302, 4402), und 2) gibt es auch Gutscheinzahlungen, die korrekt abgebildet werden (per 4102 an 4302 - siehe unten z.B. Bon 51 ganz oben). Daher nochmal zur Veranschaulichung:

Das hier sind alle "falsch" exportierten Gutscheinzahlungen, die überdies auch keine Bon-Nummer ausgewiesen bekommen! (wäre hier im Feld "Belegfeld1" hinterlegt)

1602683322577.png

Beispiel-Bon 110 daraus: (entspricht der ERSTEN Zeile in obiger Abbildung)
1602683804671.png

Und hier ein Ausschnitt alle "korrekt" ausgegeben Kartenzahlungen, inkl. der Gutscheinzahlungen:

1602683424317.png

z.B. hier Bon 89:
1602683941171.png
Oder hier Bon 94:
1602684003024.png

Oder hier Bon 51:
1602684062084.png

Zusammenfassend stelle ich also vermutend fest, dass bei reiner Gutschein-Zahlung oder in Kombination Gutschein-UNBAR (z.B. EC-Karte) alles richtig exportiert wird. Aber wenn ein Gutschein zusammen mit einer Bar-Zahlung kombiniert wird, dann a) die Bon-Nummer nicht ausgegeben wird und vor allem b) neben dem Kassenkonto nur das Geldtransitkonto 1460 angesprochen wird. Richtig wäre hier aber...

1602684417659.png

....umzuwandeln in:

Soll: 4302 | 1600 -> voller Einkaufsbetrag (22,50 EUR) -> passt
Haben: 4102 statt 1460 | 1600 Gutscheinbetrag (10,75 EUR) -> passt noch nicht

Oder siehst Du das anders?

Beste Grüße und Dank!
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
Hallo trummerjo,

genau - so sehe ich das auch! Siehe mein Dokumentation im Post darüber ;)

Ich würde allerdings noch weiter detaillieren: Bei Split-Zahlungen in Kombination BAR-Gutschein wird anders exportiert als bei Split-Zahlungen in Kombination UNBAR-Gutschein. Das ist nicht konsistent.

Beste Grüße und Dank!
 

trummerjo

Aktives Mitglied
30. März 2016
90
24
Ach jetzt weiß ich's wieder.
Diese Buchung existiert, weil erst der gesamte Bon Wert in die Kasse gebucht wird und anschließend der Teil der EC Karte (oder halt Gutschein).

Aber wieso das so gebucht wird, kann ich auch nicht genau sagen. Ich fände es besser, wenn der Umweg über die Kasse nicht gegangen wird (EC Zahlungen oder was auch immer haben da auch kurzzeitig m.E. nichts drin zu suchen), sondern direkt die entsprechenden Zahlungen an die Umsatzkonten gebucht werden.

btw. das verwendete Transitkonto das aktuell bei den Splitzahlungen verwendet wird lässt sich einstellen. Irgendwo ist's versteckt habs grad auf die schnelle nicht gefunden.
 

patoc

Aktives Mitglied
20. Juni 2017
41
3
Aber wieso das so gebucht wird, kann ich auch nicht genau sagen. Ich fände es besser, wenn der Umweg über die Kasse nicht gegangen wird (EC Zahlungen oder was auch immer haben da auch kurzzeitig m.E. nichts drin zu suchen), sondern direkt die entsprechenden Zahlungen an die Umsatzkonten gebucht werden.
Ja, genau. Wie in meinem Bild oben " Kartenzahlungen, inkl. der Gutscheinzahlungen " zu sehen ist wird hier einfach unterschiedlich vorgegangen. EC/Kredit und Split-frei Gutschein berührt das Kassenkonto gar nicht (nur 1461, 1462, 4102 auf die Umsatzkonten), ABER der "Split-Gutschein" bekommt keine Bon-Nummer und läuft aber über die Kasse (160x). Klar, da ja der volle Umsatz gegen die Kasse gebucht wird und dann natürlich der Rabatt da wieder runter muss. Aber das ist insgesamt einfach inkonsistent.

1461 ist aber ein Geldtransitkonto für Kartenzahlungen (SKR04). 1462 dann als extra erstelltes Konto auch.
Analog ist 1460 das Geldtransitkonto für Kasse-Bank-Bewegungen.
Ja, das sind gemäß DATEV natürlich alles Transitkonten. ABER: 1461 und 1462 haben wir explizit so konfiguriert. 1460 wird in dem Split-Fall (Zahlung teilweise BAR und teilweise via Gutschein) einfach durch JTL-Logik (ohne unsere Vorgabe) auf 1460 gebucht. 1460 ist aber eigentlich für Einzahlungen in die Bank reserviert.

Es ist einfach so: Jeder manuelle Aufwand, der zum Monatsabschluss in den Exports von JTL durchgeführt werden muss birgt das Risiko von individuellen Fehlern und kostet natürlich Zeit. Und so ein "Auseinandergefiesel" ist nicht gerade Vergnügungssteuer-pflichtig ;-(

LG!
 
  • Gefällt mir
Reaktionen: schnatz
Ähnliche Themen Forum Antworten Erstelldatum des Themas
Neu Ich weiß nicht ob es Bugs sind - Tastatur/Rabatte/Kassensturz Allgemeine Fragen zu JTL-POS 1
Neu Rabatte aus Shop nicht in Rechnungskorrektur vorhanden JTL-Wawi - Fehler und Bugs 0
Neu Rabatte nicht auf reduzierte Artikel User helfen Usern - Fragen zu JTL-Wawi 2
Neu Bei einem Import mit Kategorien werden die Wawi-Kats nicht gesetzt unter Marktplätze JTL-Wawi - Fehler und Bugs 0
Neu Aufträge dürfen nicht zusammengefasst werden JTL-Wawi - Fehler und Bugs 5
Neu PayPal Plus Zahlungen werden als nicht bezahlt geführt und falsch berechnet .... Abweichungen PayPal Zahlung und in der Wawi existierende Zahlung WooCommerce-Connector 2
Neu Bilder werden im Shop 5 nicht richtig angezeigt (PNG) Allgemeine Fragen zu JTL-Shop 2
Neu Textbausteine im Servicedesk werden abgeschnitten angezeigt ab 16 bzw. 17 Vorlagen JTL-Wawi - Fehler und Bugs 0
Bilder auf der Produktseite werden nicht richtig dargestellt Upgrade JTL-Shop4 auf JTL-Shop5 1
Neu Unicorn 2 Preise werden falsch übertragen User helfen Usern - Fragen zu JTL-Wawi 15
Neu JTL Shop5 bei JTL gehostet. Nova-Template ist nicht mit Smartphone zu nutzen . welche Einstellung muss da noch gemacht werden Templates für JTL-Shop 1
Neu Kundengruppen Rabatt im Artikel kann nicht gelöscht werden JTL-Wawi - Fehler und Bugs 5
Neu Artikel werden nicht importiert, weil in Aufträgen "reserviert" Schnittstellen Import / Export 1
Neu Webshop Abgleich kann nicht gestartet werden Onlineshop-Anbindung 0
Neu Woocommerce Connector 1.16.x / Bestände werden nicht aktualisiert WooCommerce-Connector 0
In Bearbeitung Kein Initialer Import von Amazon Bestellungen? Nur neue Bestellungen werden abgeholt Amazon-Anbindung - Fehler und Bugs 3
Neu wawi 1.5.37 Achtung, Rechnungen können unter umständen nicht mehr erstellt werden JTL-Wawi - Fehler und Bugs 5
Neu Veränderungen im Grundauftrag eines Abonnements werden nicht übernommen JTL-Wawi - Fehler und Bugs 0
Neu Rechnungs und andere Formulare - Tabelle rechts mit Total kann nicht gut angepasst werden Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
Neu Kategoriebilder werden nicht angezeigt Einrichtung von JTL-Shop4 2
Gelöst Import ohne Kategorie - Artikel kann nicht bearbeitet oder gelöscht werden JTL-Ameise - Fehler und Bugs 3
Neu Werte der Kattegorie-Attribute (Google Shopping) werden gelöscht - Connector 2.8.5 Shopware-Connector 0
Neu Kundenstammdaten änderungen werden geloggt? Installation von JTL-Wawi 0
Neu Artikel hat neue Bilder, alte werden angezeigt, obwohl Ordner auf FTP nicht exisitiert JTL-Shop - Fehler und Bugs 0
Neu Aufträge dürfen nicht zusammengeführt werden JTL-Wawi - Fehler und Bugs 6
Neu Bilder werden Artikeln nicht zugeordnet Shopware-Connector 4
Verwiesen an Support Diese Bestellung darf nicht geändert werden..... JTL-Workflows - Fehler und Bugs 1
Gelöst Ausgewählte sprachen werden im Shop nicht angezeigt Onlineshop-Anbindung 2
Neu Aus Abonnements erzeugte Aufträge werden sofort als "versandt" markiert JTL-Wawi - Fehler und Bugs 0
Neu Frisch vergebene Rechnungen können nicht per Zahlungsmodul bezahlt werden JTL-Wawi - Fehler und Bugs 0
Neu NOVA: Namen der Unterkategorien werden abgeschnitten Einrichtung von JTL-Shop4 1
Neu Neue Preise werden nicht abgeglichen Shopify-Connector 3
Gelöst Amazon Aufträge werden nicht abgeholt. Server 500 Fehler Amazon-Anbindung - Fehler und Bugs 18
Neu Ebay Angebotsimport - VarKombis können nicht zugeordnet werden eBay-Anbindung - Fehler und Bugs 0
Neu Mail werden nicht versendet JTL-Shop - Fehler und Bugs 5
In Bearbeitung Der Jtl-Shipping Server kann nicht erreicht werden JTL-ShippingLabels - Fehler und Bugs 2
Neu Bilder werden nicht mehr übertragen WooCommerce-Connector 0
Neu Artikelnummern werden nicht fortlaufend vergeben (Update 08.01. 10:14) User helfen Usern - Fragen zu JTL-Wawi 0
Neu Position auf Pickliste. Kann nicht gelöscht werden ! Arbeitsabläufe in JTL-Wawi 8
Neu Rechnungskorrekturen werden seit November nicht mehr von Amazon abgeholt Amazon-Anbindung - Fehler und Bugs 17
Neu Paypal Zahlungen werden nicht mehr übertragen Shopware-Connector 0
Neu Hilfe, Artikeldaten werden nicht mehr aktualisiert Shopware-Connector 14
Neu Artikelbilder werden nicht angezeigt Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
Neu Verkaufseinheiten / Maßeinheiten werden nicht übernommen Shopware-Connector 0
Neu Stückliste mit Artikel die nicht angezeigt werden JTL-Wawi - Ideen, Lob und Kritik 2
Neu Auslands-Adressen werden eigenmächtig von JTL geändert und werden damit unzustellbar [WAWI-43207] JTL-Wawi - Fehler und Bugs 0
Neu Shopkonfiguration - Cross-Sellings etc. werden nicht synchronisiert Shopify-Connector 7
Neu Fokus springt standardmäßig im Warenkorb immer nach oben, wenn z.B. Mengen geändert werden Betrieb / Pflege von JTL-Shop 1
Neu 2 Lager nur 1 darf mit zum Online-Shop synchronisiert werden User helfen Usern - Fragen zu JTL-Wawi 3
Neu geändert Artikelpreise werden nicht zu eBay übertragen eBay-Anbindung - Fehler und Bugs 0
Ähnliche Themen