Neu Bug: Ameise-Export Gutschriften Vollständig

[Stephan K.]

Hallo,

ich mache gerade die Buchhaltung für 2020 Österreich und möchte zur Kontrolle alle Rechnungen + Gutschriften für das Jahr ausgeben. Innerhalb diesen Jahres wurde die UST-ID für Österreich hinterlegt. Das ist kein Problem.
Aber JTL-Wawi hat damit ein Problem.

Ich kann mir entweder die Daten ausgeben lassen mit den Steuereinstellungen, aber dann fehlen alle Daten, die ein "falsches" Steuerkonto haben. Oder ich kann die Daten "Steuereinstellungen nicht beachten" ausgeben lassen und erhalte dann Kauderwelsch.
Immerhin scheinen die Rechnungs-Nettobeträge unter der falschen Ausgabe "Betrag USt." zu laufen. Das ist eine Krücke zur Wahrheit. Ich habe auch nicht alle Gutschriften kontrolliert. Sondern nur stichprobenartig

Kennt jemand einen Weg, unabhängig von den Wawi-Berechnungen eine "raw"-Ausgabe zu starten, die ignoriert, was da an Berechnungen hineinmanipuliert wird? Sondern was tatsächlich für die einzelnen Transaktionen hinterlegt ist.
Das Problem gab es vor Monaten bereits schonmal. Ich dachte es sei final behoben worden und ich kann den Daten trauen. Aber scheinbar ist das ein Trugschluss.

 

[MichaelH]

Ohne auf dein Problem im Detail eingehen zu wollen - wir verwenden immer noch NICHT die Vorlagen mit (neu), sondern die Alten.
Da wird alles exportiert, es kommen zwar ggf. Hinweise wegen Steuerschlüssel, aber letztlich sind alle Daten drin.

Ich habe mich bislang nicht damit befasst was an den (neu) besser oder anders sein soll, weil die Alten perfekt funktionieren und das seit eh und je.

 

[Stephan K.]

Weil ich damit schnell nach Plattform, der UST-ID, Versandland und Zielland etc pp sortieren kann. Hilfreich für multinationalen Versand

 

[MichaelH]

Diese Felder gibt es in der "alten" Vorlage aber auch, ich erkenne hier keinen Unterschied, so auf die Schnelle ...

 

[Enrico W.]

Das Problem ist recht einfach und hat mit dem verwendeten Export weniger etwas zu tun.

Um kurz auf die Frage von @MichaelH einzugehen: Die Exporte mit dem Zusatz (Neu) waren die, bei denen weiterentwickelt wurde. In den "Alten" Exporten gab es maximal Bugfixing. Mit der 1.6 werden die alten dann entfernt, die bestehenden Exportvorlagen werden auf die dann nicht mehr ganz so neuen Exporte migriert. Es gab jetzt nicht zwingend viele Änderungen in den Gutschriften, ich meine, die meisten waren im Rechnungsexport und im alten DATEV-Export, der dann huch - auch noch überflüssig wurde.

Nun zu Deiner Frage. Wie bereits angedeutet hat das nichts mit dem verwendeten Export zu tun sondern schlichtweg mit der Umstellung. Das gleiche Problem haben auch User, die z.B. die Lieferschwellen überschritten haben.
Die Vorgehensweise ist jetzt wie folgt:
Exportiere einmal den Teil der Rechnungen bzw. Gutschriften AB der Umstellung. Dann ändere die Steuereinstellungen so um, wie sie vor der Umstellung waren, und exportiere dann den Bereich BIS zur Umstellung. Dann solltest Du die sauberen Daten haben.
Wenn Du vorher eine Datenbanksicherung machst und den Abgleich ausschaltest, brauchst Du die Steuereinstellungen anschließend nicht wieder ändern sondern kannst die Sicherung importieren. Ansonsten halt Steuereinstellungen dann wieder auf den jetzigen Stand ummodeln.

Das Problem ist halt, dass die Wawi aktuell noch keine Steuerhistorie kennt. Somit findet die Ameise nicht die notwendigen Daten um alles korrekt auszugeben, sobald etwas geändert wurde. Wir haben das auf dem Schirm, die Umsetzung ist aber echt heftig, da nicht nur die Ameise davon betroffen sein wird. Daher bleibt aktuell nur dieser Workaround.

 

[Stephan K.]

Diese Felder gibt es in der "alten" Vorlage aber auch, ich erkenne hier keinen Unterschied, so auf die Schnelle ...

Dann zeig mir das mal so auf die Schnelle. SteuerID gibt immer nur eine UST-ID aus. "Versandland" oder Versandland ISO suche ich vergeblich etc pp
Und dann schau mal die Vorlage "Rechnungskorrekturen" an, worum es eigentlich auch geht (topic). Da fehlen gleich mal mehr als ein Dutzend der Exportfelder...



@Enrico W.
Dann mal viel Spaß mit MOSS/OSS ab Juli. Dann erwartet euch ja "echt heftig" viel Arbeit, wenn das bisher nicht möglich ist. Stell dir mal das cross-over dann vor, was jetzt mit mehreren Versandländer schon krass viel Umstellung bedeutet für den "work-around" um die Jahresdaten auszulesen. Sorry, aber das leiste ich nicht. Ich stelle jetzt nicht für x-Länder das AB Datum um, um dann vier Wochen später für das nächste Land die Umstellung einzupflegen, um dann danach für die anderen Länder wieder...
Wie soll das dann realistisch in ein paar Monaten aussehen, wenn man in einem EU-Land die 10.000 € "EU-Lieferschwelle" knackt und dann in jedem anderen Land umsatzsteuerpflichtig wird und das nicht sauber für alle Plattformen, Versandländer etc. exportieren kann?

Die Buchhaltung/Finanzen mit JTL ist unterirdisch.

Und ich frage derzeit ja nur nach einem raw-Datenexport. Das sollte machbar sein, ohne dass JTL hier "magic" bewirkt.
Das, was ich aus der Verkaufsansicht exportieren kann, ist zu wenig. Zwar richtige Zahlen, aber selbst bei den Gutschriften gibt es ja nichtmal die UST-ID als Feldausgabe...

Ich seh schon. Das wird mal wieder "echt heftig" viel Arbeit und ist eigentlich pille-palle.

edit:
Alte Variante funktioniert, aber viel zu wenig Informationen
Neue lässt mit "Steuereinstellung beachten" die "falschen" weg (Datensatz unvollständig) und ohne die Steuereinstellung kommen nur absolut fantastische Quadrillionen als Beträge raus. Immerhin der USt.-Betrag stimmt, der als "netto-Betrag" ausgegeben wird (stichprobenartig). Ich könnte jetzt ganz simpel eine mathematische Formel anwenden in Excel, aber dann habe ich 1. den Datensatz manipuliert und 2. ist der Bericht schon fehlerhaft und es gibt kein Garant für die richtigen Zahlen.

Also Variante 1 mit 2 kombinieren scheint wohl nicht zu gehen. Raw-Export scheint auch nicht zu gehen.

Dann macht doch als work-around in der Verkaufsansicht und der Gutschriftenansicht mehr Spalten zur Auswahl. Ich kann Spalten ja auch noch zusätzlich filtern. Außerdem kann ich sagen: Zeige mir 45.000 Datensätze an. Das geht ja immerhin.
Ist doch besser als diese x-fache Arbeit mit der Steuerumstellung für alle Länder.

 

[Enrico W.]

Ich kann Deinen Ärger durchaus verstehen. Letztlich ist die JTL-Wawi aber eine Warenwirtschaft und keine vollwertige Buchhaltung. Diesen Anspruch haben wir nie erhoben. Ich weiß, das ist evtl. auch ein wenig Wortklauberei und bringt Dich jetzt auch nicht weiter.
Die Geschichte mit der Steuerhistorie haben wir tatsächlich auf dem Schirm und sie wird auch aktuell evaluiert. Nur - das ist wie gesagt, nicht mal eben so gemacht. Mit einer halbgaren Lösung ist Euch auch nicht geholfen.

 

[MichaelH]

@Enrico

Ui, das ist keine gute Aussage - die WAWI ermittelt den Umsatz und den Verbrauch, in der WAWI werden Zahlungen zugeordnet.
Nur die WAWI kann das, keine FIBU.

Ausgenommen du willst jeden Beleg mit Verbrauchsdaten in die FIBU eintippen.

Also:
Insofern ist jede WAWI auch die JTL-WAWI eine "Hilfsbuchhaltung" welche also als Nebenbuch sowohl den Lagerwert (=Vermögen), als auch den Verbrauch (=Bestandsführung) und auch die Basisdaten für den Deckungsbeitrags-Rechnung (DBI) liefert und auch liefern muss, ausgenommen du willst das alles mit Papier und Bleistift führen wir vor 60 Jahren.

Konklusio:
Natürlich muss die WAWI das können und richtig machen

PS: Nicht umsonst schreibe ich schon jahrelang dass die WAWI Lücken hat in der Lagerführung und im Artikelkonto welche sie genaugenommen gar nicht haben dürfte.
PPS: Und nicht so lange her wollte man uns sogar das Artikelkonto wegnehmen, weil es ja WMS gibt, aber WMS ist wiederum nur ein Hilfsprogramm zum Artikelkonto welches angibt wo die Ware tatsächlich liegt und kein Ersatz für ein Artikelkonto

Konklusio II:
Schon länger läuft manches irgendwie in die falsche Richtung und mit seltsamen Sichtweisen von JTL

 

[Enrico W.]

Ich bin da absolut bei Euch, wenn ihr sagt, dass da noch vieles passieren muss, schließlich sollte auch aus meiner Sicht heraus ca. 99% direkt aus der Wawi oder den angrenzenden Produkten gemacht werden können. Und besonders glücklich bin ich auch nicht, wenn ich solche Aussagen treffen muss - sie entsprechen aber dem aktuellen Stand - und danach ist das - daher ja auch der Name - eine Warenwirtschaft. Mir wäre es auch lieber, wenn ich sagen könnte: Setz da den Haken und trag evtl. hier noch was ein und dann geht das.

 

[MichaelH]

@Enrico

"Materialwirtschaft oder Warenwirtschaft" -> https://de.wikipedia.org/wiki/Materialwirtschaft



@Stephan

Je nachdem wie du die Steuerverwaltung angelegt und verwaltet hat, kannst du sehr wohl Rückschlüsse ziehen anhand vom Steuerschlüssel der bei der Variante "alt" ausgegeben wird.
Also wir haben keine Probleme damit und der korrekten Zuordnung der Daten in der FIBU / Import.

Nur wenn es dann die alten Vorlagen in 1.6 nicht mehr geben soll und/oder diese anders funktionieren, obwohl 2021 vieles umzustellen ist, krieg' ich wieder mal die Krise ... und wurschtle lieber auf dem alten Weg mit 1.5.x weiter. Ächz.

 

[Enrico W.]

Doch, die Vorlagen gibts noch, die kannst du auch unverändert weiter nutzen. Die werden zu einem Export migriert.
Wenn Du da auf Nr. sicher gehen möchtest, dann ticker mich einfach mal per PM an. Ich würd mir dann mit Deinem Einverständnis von dir eine obfuskierte Datenbanksicherung geben lassen und aktuelle Wawi und 1.6 exportieren und die Datenbestände vergleichen.
Das ist sicherlich schöner, als meine generischen Daten.

 

[MichaelH]

@Enrico W.

Dafür ist es noch zu früh, ich muss mir die 1.6 hin wie her sehr genau ansehen, jeden Arbeitsablauf der für uns wichtig ist, alle Auswertungen und Exporte, bis hin zu IntraStat bevor ich nur daran denken kann diese live einzusetzen.

Daher habe ich Geduld mit der 1.6. und hoffe dass JTL eine saubere Arbeit leistet, denn die 1.6 ist für mich eigentlich eine 2.0 weil der Kern der WAWI die Auftragsbearbeitung komplett umgestellt wird und nicht nur das, sie wird komplett überarbeitet mit neuen Funktionen.

 

[Enrico W.]

Wie du magst, das Angebot steht.

 

[Stephan K.]

@Enrico W.
Vor gar nicht allzu langer Zeit wurde ich von seitens JTL deutlich zurecht gewiesen, als ich die Behauptung von der Website "JTL ist ein ERP" krass in Frage gestellt habe.
Jetzt kommst du und sagst, dass die JTL nur die Waren bewirtschaftet...
Das ist so krass wie das "siezen" und "duzen" bei euch. Der eine duzt mich unverhohlt und denkt sich nichts dabei, der andere siezt mich und beide sagen, dass das so bei JTL gehandhabt wird.

Ich denke immer noch, dass die einfachste, wenn schon komische, Exportvariante die aus der GUI- Wawi direkt ist in der Verkaufsansicht (Rechnungen/Gutschriften) mit erweiterten Tabellenspalten. Der Vorteil dabei ist sogar, dass der csv-Export in 5 Sekunden erledigt ist und die Ameise dafür 20 Minuten braucht.


@MichaelH
Jetzt sagst du also, dass die Zuordnung nur aufgrund der Steuerschlüssel geht. Das war nie Thema und damit widersprichst du dir, dass die gleichen Exportfelder auch in der alten Vorlage vorhanden sind.
Nach dem Schema kann ich auch die alte und die neue Vorlage mit Datenexport nehmen und mit Excel und SVERWEIS viel Spaß haben... wobei noch immer nicht geklärt ist, dass die neue Exportvorlage die echten Zahlen und Daten ausliest und in eine .csv schreibt und sie nicht mit weiß-der-Teufel-was multipliziert und dividiert, dass nur gröbster Mist dabei herauskommt.

Ich habe heute 3 Stunden Vorbereitung für Österreich gemacht und ich hätte jetzt gerne den Abschluss auch noch hinbekommen, aber mit JTL ist ein simpler, vollständiger Export so kompliziert und fehleranfällig wie der Berliner Flughafen.
Wenn da ne 5 in der Rechnung/Angebot steht, soll auch eine 5 dabei herauskommen und keine 217... so einfach, so schwer.
In der GUI scheint es ja zu funktionieren. Da wird sogar der festgeschriebene Steuersatz angezeigt, hui.

 

[MichaelH]

Oh Sorry, ja, da hast recht, ich hatte mir nicht den Jahresexport angesehen, Steuerschlüssel ist 0 ... aber für uns kein Problem, da der effektive Steuersatz vorhanden ist und somit darüber nachvollziehbar: 5/16 7/19 10/20 mehr Steuersätze haben wir aktuell nicht

Wir haben ein Makro das die CSV für die FIBU umformatiert (in Buchungssätze) und aufbereitet und dort wurde das entsprechend angepasst, mache ich aber nicht selbst.
Da wir 2 Steuersätze haben wäre ein Export über GUI nicht möglich, weil die Aufteilung fehlt.

Manuel hat aber im Juni-Video eine Variante gezeigt wie mehrere Steuersätze aktiviert werden können ( also 5/16 und 7/19) und somit der Fehler mit fehlendem Steuerschlüssel in der Ameise nicht erscheint. Zumindest hatte ich es so verstanden ...
Ich wollte es mal testen, weil wir aber das Problem nicht hatten, habe ich es dann doch nicht gemacht.

Plan für Lieferschwelle 07/2021:
ich werde schon im Laufe des Frühlings alle Länder als separate Steuerzonen anlegen, auch wenn sie noch keinen anderen Steuersatz haben, die Aufteilung ist dann schon gemacht und ab 1.7. erhalten die dann ihren Steuersatz. Somit stimmt dann Steuersatz und Steuerschlüssel.
Das Abgrenzungsproblem mit 1.7. wird damit zwar nicht gelöst, aber die Schnittstelle ist getestet und funktioniert.
Besser wäre gewesen es schon mit 1.1.2021 zu machen ...