In Bearbeitung Rabatte werden in den Exports falsch behandelt.

patoc

Aktives Mitglied
20. Juni 2017
87
6
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
87
6
...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.921
261
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
87
6
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.921
261
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
87
6
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.921
261
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
9
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.921
261
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
9
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
87
6
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.921
261
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
87
6
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.921
261
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
87
6
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
87
6
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!
 

schnitzel112

Sehr aktives Mitglied
30. März 2016
115
32
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
87
6
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
Titel Forum Antworten Datum
Neu Rabatte auf Rechnung ausweisen Fragen rund um LS-POS 0
Verschiedene Rabatte für einen Kunden anlegen JTL-Wawi 1.8 2
Neu Packtisch: Versandart soll explizit ausgewählt werden müssen Arbeitsabläufe in JTL-WMS / JTL-Packtisch+ 0
Versanddaten werden nicht übermittelt. JTL-Wawi 1.8 3
Neu Kategorie Bilder werden im Webshop nicht angezeigt User helfen Usern - Fragen zu JTL-Wawi 0
Neu Bilder von Merkmalen werden nicht angezeigt Gelöste Themen in diesem Bereich 5
Neu Vorschaubilder in der Artikeldetailseite werden nicht angezeigt Betrieb / Pflege von JTL-Shop 1
Neu Amazon Prime - DHL Versandlabel kann nicht gedruckt werden "Ein Prime Versandlabel wurde nicht gekauft, da kein verfügbares gefunden wurde." JTL-ShippingLabels - Fehler und Bugs 0
Neu Hersteller werden nicht übertragen Shopware-Connector 0
Neu Versandschein für Schweiz kann nicht gedruckt werden folgende Fehlermeldung JTL-ShippingLabels - Fehler und Bugs 1
Verbindung zu Kundencenter geht verloren und Lizenz muss erneut abgteglichen werden JTL-Wawi 1.8 16
Zahlungen werden nicht empfangen (WooCommerce) JTL-Wawi 1.8 0
Neu Shop in Unterverzeichnis führt dazu, dass Inhalte aus dem übergeordneten Verzeichnis im Shop gezeigt werden JTL-Shop - Fehler und Bugs 3
Neu Neu erstellte Kategorien werden nicht mehr im Megamenue & Kategoriebaum angezeigt Betrieb / Pflege von JTL-Shop 7
Rechnung zeigt Mehrwertsteuer 0% aus obwohl 7% berechnet werden - wenn UST-ID eingegeben JTL-Wawi 1.8 0
Kann ich eine email an die Wawi senden durch die dann ein neuer Auftrag generiert wird? (Daten müssen händisch vervollständigt werden...) JTL-Wawi 1.8 2
Neu DHL Paket Label Sonderzeichen - werden weggekürzt User helfen Usern - Fragen zu JTL-Wawi 0
Neu Track & Trace - Auslandssendungen automatisiert als PDF exportieren, bevor die Logs gelöscht werden. JTL-Track&Trace - Ideen, Lob und Kritik 0
Neu WAWI Kategorien werden im Shop nicht angezeigt Gelöste Themen in diesem Bereich 3
Neu Bilder werden Falsch im Shop angezeigt. WooCommerce-Connector 0
Neu Ebay Artikel - bei Umstellung auf Designvorlagen werden Beschreibungen verändert User helfen Usern - Fragen zu JTL-Wawi 1
Neu Es werden unterschiedliche Warenkorbansichten gezeigt JTL-Shop - Fehler und Bugs 2
Neu Inaktive Artikel werden mit 404 Fehler bei Google Search angezeigt Allgemeine Fragen zu JTL-Shop 2
Neu Download-Arikel werden im Backend des Kunden nicht angezeigt JTL-Shop - Fehler und Bugs 1
[JTL-WAWI API] Nettopreise werden nicht gespeichert JTL-Wawi 1.8 0
Neu Amazon Lister übergibt nur das Hauptbild an Amazon, weiter Bilder werden nicht übertragen Amazon-Lister - Fehler und Bugs 0
Neu Artikel werden nicht mehr aktualisiert, wenn sie sich auf Pickliste befinden JTL-Ameise - Fehler und Bugs 1
Neu syntaxfehler report.invoicebilltoaddress.country kann nicht interpretiert werden Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
Neu webp-Bilder werden nicht mehr generiert JTL-Shop - Fehler und Bugs 0
Neu Artikelbilder werden im Shop verzerrt angezeigt JTL-Shop - Fehler und Bugs 4
Neu Warum werden Filter nach Auswahl in der Sidebar ausgeblendet? Allgemeine Fragen zu JTL-Shop 3
Neu Beim duplizieren von Aufträgen werden alte Daten übernommen Arbeitsabläufe in JTL-Wawi 11
Otto externe Rechnungen werden mit falschem Datum erstellt Otto.de - Anbindung (SCX) 6
Verwiesen an Support TSE Modul wird nicht mehr erkannt, kann auch nicht wieder aktiviert werden, diverse Fehlermeldungen JTL-POS - Fehler und Bugs 1
Neu Easyshipping Amazon-Aufträge werden nicht abgeholt JTL-Wawi - Fehler und Bugs 2
Neu PayPal Checkout - Bestellungen werden nicht übertragen! User helfen Usern - Fragen zu JTL-Wawi 0
Variablen werden nicht mehr in die verschiedenen Vorlagen übertragen JTL-Wawi 1.8 0
Gelöst Preise werden falsch aufsummiert - bzw. nicht mit berechnet Gelöste Themen in diesem Bereich 2
Neu Bilder werden teilweise in verschiedenen Browser falsch dargestellt Gelöste Themen in diesem Bereich 3
Neu Versandkosten im Warenkorb werden als Artikel angezeigt Allgemeine Fragen zu JTL-Shop 6
Neu Artikel werden nicht übertragen Shopify-Connector 0
Neu Der mehrteilige Bezeichner "AlleAttributeMitWerten.Gruppe" konnte nicht gebunden werden JTL-Wawi - Fehler und Bugs 2
Neu Kategorien werden nicht abgeholt Shopware-Connector 0
Neu Es werden keine Variationen angezeigt JTL-Shop - Fehler und Bugs 1
Rechnung werden nicht auf Kaufland hochgeladen kaufland.de - Anbindung (SCX) 0
Neu Geschäftskundenpreise werden auf den Artikelseiten für jeden angezeigt JTL-Wawi - Fehler und Bugs 0
In Bearbeitung Kasse aktualisiert keine Produkte / Verkäufe werden jedoch in WAWI angezeigt JTL-POS - Fehler und Bugs 4
Neu Kategoriebilder werden immer mit großem leeren Platz (wie für das 2.Bild) angezeigt Allgemeine Fragen zu JTL-Shop 6
JTL-WMS und JTL-Packtisch+ Es können nun einzelne Artikel im Versand gewogen werden Arbeitsabläufe in JTL-WMS / JTL-Packtisch+ 0
Neu Woocommerce Upsells und Cross-Sells werden af JTL Shop angezeigt. JTL-Wawi - Fehler und Bugs 0

Ähnliche Themen