Informationen zu joachim_buchhaltung - DATEV-Community

joachim_buchhaltung · ‎21.03.2024

Nun, die Sparkassen erfahren manches von ihrem Rechenzentrum ja auch nicht direkt. Die Kommunikationswege können da u.U. sehr lang sein. Ich würde einfach mal vermuten, der oder die AnsprechpartnerIn bei der SK hatte da einfach noch keine Info dazu vorliegen.

joachim_buchhaltung · ‎08.07.2022

Hallo @Antje_Naumann , vielen Dank für die ausführliche Info. Dann war das mit der Neunstelligen Nummer wohl eine individuelle Sache dieses Steuerbüros oder eine falsch verstandene Info. Wir machen das mit dem Dateinamen jetzt eben auch so, wie Sie es beschrieben haben. Das ist dann zumindest konsistent, Ich weiß nicht, ob Sie das intern entsprechend weiter leiten können, aber es wäre vielleicht gut, diese "Konvention" in die Formatbeschreibungen aufzunehmen, die im Developer Portal zu finden sind. Es ist nämlich so, dass man als Drittanbieter, der Datev-Dateien erzeugt, häufig mal Rückfragen aus Steuerbüros auf den Tisch bekommt, die letztlich nur besagen, dass da etwas anders ist, als sie es gewohnt sind, aber es gibt keine auffindbaren Infos dazu, wie es richtig bzw. Konventionsgemäß wäre... Das erleichtert eine Koexistenz zwischen der Datev und potentiellen Datenzulieferern sicher sehr.

joachim_buchhaltung · ‎04.07.2022

Hallo, einer unserer Nutzer wurde vom StB gebeten, den Dateinamen von zu importierenden Buchungsstapeln nach dem Schema EXTF_BuchungsstapelJJJJMMTT_{neunstellige Nummer} anzuliefern. Nun ist in der Schnittstellenbeschreibung zu den Datev_Buchungsstapeln keinerlei Info zum Aufbau des Dateinamens zu finden. Kann mir jemand erklären, was sich in der neunstelligen Nummer verbirgt und wozu diese Zahl im REWE benutzt wird? Ist das einfach eine Nummer, die eben die Eindeutigkeit des Stapels garantieren soll, also reicht hier eine neunstellige Zufallszahl? Und muss gewährleistet sein, dass wenn man zwei mal den selben Stapel exportiert, die gleiche Nummer generiert wird, sofern sich auch der Inhalt des stapels nicht verändert? Ist das so eine Art Prüfsumme über den Dateiinhalt und wenn ja, wo isz der entsprechende Algorhithmus benannt oder beschrieben? Vielen Dank vorab

joachim_buchhaltung · ‎30.05.2022

Hallo Björn, vielen Dank für Ihre Antwort. Ich beginne zu verstehen: Es gibt die Möglichkeit, ASCII-Dateien zu importieren und dabei kann es sich zufällig eben auch um eine ASCII-Datei handeln, die genau dem Format eines Buchungsstapels entspricht, aber nicht im "richtigen" Buchungsstapelformat ist, weil eben die Header-Zeile fehlt.

joachim_buchhaltung · ‎30.05.2022

Hallo, ein Kunde lieferte uns einen Buchungsstapel zu, der in unserem Programm nicht eingelesen werden konnte. Bei näherem Hinschauen stellte sich heraus, dass die Datei keine Header-Zeile (die, die mit DTVF oder EXTF beginnt) enthält. Die Zeile mit den Spaltenüberschriften ist da, die Spalten sind auch gemäß Buchungsstapelformat vorhanden (nicht die neueste Version, aber dennoch einlesbar). Der Hersteller dieser Software meinte, das sei schon seit vielen Jahren so und es habe damit nie Probleme gegeben. Nun meine Fragen: ist das evtl. das "alte" ASCII-Format? Oder gibt es in REWE tatsächlich die Möglichkeit, einen Buchungsstapel ohne diese erste Zeile einzulesen?(Ich kann zu diesem Altformat keinerlei Doku finden) Woher nimmt man denn in einem solchen Fall am besten das Jahr der Buchungen? Es ist ja üblicher Weise in der (hier eben nicht vorhandenen) Headerzeile Vielen Dank für Ideen und Hinweise J. JTuchel

joachim_buchhaltung · ‎25.06.2021

Hallo Herr Lachmann, vielen Dank für die Präzisierung, auch in der Doku. Beide Fragen sind damit komplett beantwortet. Ich nehme an, es wird über kurz oder lang auch https://developer.datev.de/portal/de/dtvf/formate/buchungsstapel auf diesen neuen Stand gebracht.

joachim_buchhaltung · ‎23.06.2021

Ja, Nordirland gehört zu GB, ist aber in Sachen innergemeinschaftliche Lieferungen ein EU-Mitglied. Im Falle von innergemeinschaftlichen Lieferungen ist hier also eine "spezielle" USt-ID mit dem Präfix XI zu nutzen. Da aber GB kein EU-Mitglied mehr ist, bezweifle ich, dass bei Fernverkäufen an einen Kunden ohne USt-ID in Nordirland das Länderkennzeichen GB korrekt wäre.... Meines Wissens (ich bin kein Profi auf dem Gebiet) hat GB weder in Sachen innergemeinschaftlicher Lieferungen noch in Sachen Fernverkäufen irgendwas in Buchungssätzen verloren, zumindest ab dem 1.1.2021...

joachim_buchhaltung · ‎23.06.2021

Hallo @ThoKrä , genau von dort komme ich her 😉 Leider ist die Beschreibung von Feld 40 nicht detailliert genug (für mich), drum bitte ich hier um Hilfe. Von "da kann auch nur das Land drin stehen" ist da nämlich nichts zu finden. Die komplette Beschreibung von Feld 40 lautet dort: Die USt-IdNr. besteht aus - 2-stelligen Länderkürzel (siehe Dok.-Nr. 1080169; Ausnahme Griechenland: Das Länderkürzel lautet EL) - 13-stelliger USt-IdNr. - Beispiel: DE133546770. Die USt-IdNr kann auch Buchstaben haben, z.B.: bei Österreich Detaillierte Informationen zur Erfassung von EU-Informationen im Buchungssatz: Dok.-Nr: 9211462. Und in den Musterdaten sind ausschliesslich Sätze, in denen Feld 40 leer ist oder eine komplette USt-ID enthält. Dieser Unschärfe hat mich erst auf die Idee gebracht, evtl Feld 120 in Betracht zu ziehen. M.E. ist die Beschreibung ohnehin unvollständig, da ein Hinweis auf das Länderkennzeichen XI für Nordirland fehlt. Das sollte sicher noch ergänzt werden.

joachim_buchhaltung · ‎23.06.2021

Hallo @Marco_Lachmann und vielen Dank. Ich bin ehrlich überrascht. Das heisst also, in Feld 40 kann entweder ein 2-stelliges Länderkürzel oder eine komplette USt-ID stehen? Für die Fernverkäufe gibt es ja gerade keine USt-ID, aber eben ein Bestimmungsland... Die Beschreibung für Feld 40 sollte da m.E. in der Dokumentation präzisiert werden.... Zusatzfragen: Eine griechische UStId beginnt nicht mit GR, sondern mit EL. Bei Fernverkäufen muss da aber dennoch GR rein, nehme ich an? Wie sieht das bei Nordirland aus? XI in der USt-ID und was ist das Länder-KZ für Nordirland? Vorab schon mal vielen Dank. J. Tuchel

joachim_buchhaltung · ‎18.06.2021

Hallo, wieder mal eine sehr technische Frage: wir bieten in unserem Programm an, Datev-Buchungsstapel zu ex- und importieren, um einen Austausch mit dem Steuerberater zu bewerkstelligen. Dabei nutzen wir den CSV-Buchungsstapel, wie er hier beschreiben ist. Nun bin ich mir zum Thema Fernabsätze an EU-Kunden ohne USt-ID nicht ganz sicher, welche Felder genau für das EU-Land und den Steuersatz im Land des Abnehmers genutzt werden. Mein Tipp aktuell wäre: Feld Nr. 41 ist der Steuersatz im Land des Abnehmers (z.B: Polen) Feld Nr. 120 ist das 2-stellige Länderkürzel des Landes, in das geliefert oder geleistet wurde. Die Dateibeschreibung (siehe Link oben) ist ein wenig uneindeutig beim Feld USTID (Nr. 40). Man kann das so lesen, als wenn da das Abnehmerland ODER eine vollständige UST-ID rein kommt. Deshalb bin ich mir mit den Feldern 42 und 120 nicht ganz sicher... Kann mir jemand hier weiter helfen? Herzlichen Dank J. Tuchel

joachim_buchhaltung · ‎08.02.2021

Ich habe zwischenzeitlich von der Schnittstellenberatung die Info, dass das offenbar ein Fehler war und die Dokumentationslinks auf developer.datev.de aktualisiert werden müssen. Insofern hat sich meine Anfrage in kürzester Zeit in Luft aufgelöst. Das deckt sich so gar nicht mit meinen bisherigen Erfahrungen mit den Kollegen bei der Schnittstellenberatung, aber erfreut mich dafür umso mehr. Danke fürs Mitlesen.

joachim_buchhaltung · ‎08.02.2021

Nicht direkt. Wir möchten einen Buchungsstapel in ein Drittprogramm einspielen, um ihn auszuwerten. Und dieses Drittprogramm kann die Versionen 10 und 11 der Buchungsstapel nicht verarbeiten. Leider sind sie noch nicht offiziell dokumentiert... Ich habe parallel von der Schnittstellenberatung eine Mail bekommen mit aktualisierten Informationen, vermutlich wurde im Developer Portal einfach vergessen, die Links auf aktuelle Dokumente zu setzen... Ich kläre das gerade mit einem Ansprechpartner des Developer Portals bzw. der Schnittstellenberatung.

joachim_buchhaltung · ‎08.02.2021

Das ist ja das Problem: wir haben keine Datev-Produkte im Einsatz oder Zugriff. Wir sind auf die Dokumentation angewiesen, die uns die Datev zur Verfügung stellt. Und die ist noch auf einem inzwischen vorletzten Stand, wenn ich das richtig sehe. Oder aber, es gibt inzwiscen aktuellere Dokumentation als die, die auf developer.datev.de verfügbar ist. Dass die Datev ihre eigenen Dateien wieder einlesen kann, glaube ich sehr gerne.

joachim_buchhaltung · ‎08.02.2021

Schon zum zweiten Mal innerhalb von ein paar Wochen erreicht uns ein DTVF-Buchungsstapel in einer bisher noch undokumentierten Version. Nutzer sind natürlich nicht begeistert, wenn sie ihre Daten nicht in unser Programm einlesen können.Vor kurzem war es ein Buchungsstapel mit der Dateiversion 10 und einem neuen Feld, heute kam eine Version 11 daher, in der auch wieder neue Spalten drin sind. Auf developer.datev.de gibt es aber keine neuere Dokumentation des Buchungsstapel-Formats. Da ist noch immer die Dateiversion 9 aktuell. Wie läuft so etwas denn üblicher Weise bei der Datev so ab? Ab wann dürfen Entwickler von Fremdlösungen denn mit einer passenden Dokumentation zu neuen Buchungsstapel-Versionen rechnen? Oder anders herum: wo muss ich denn nachschauen oder mich registrieren, um halbwegs rechtzeitig zu erfahren, dass im Buchungsstapel neue Spalten vorkommen (werden)? Erwarte ich zu viel, wenn ich hoffe, dass es mit der Einführung neuer Spalten das auch irgendwie kundgetan wird?

joachim_buchhaltung · ‎20.10.2020

Nur so als Erklärung, warum ich so blöde Fragen stelle: manche CSV-Einleseprogramme (Parser) würden mit dieser Art der Kennzeichnung eines Texts innerhalb eines Texts durch nochmalige Anführungszeichen nicht zurecht kommen.Für sie wäre das zweite Anführungszeichen ein Ende-Kennzeichen für den Text in der Spalte, und es gibt dann eigentlich keinen logischen Grund dafür, dass das nächste Zeichen nicht ein Spaltenende, also ein Semilkolon ist...

joachim_buchhaltung · ‎20.10.2020

Hallo, super, vielen Dank! Das war exakt die Info, die ich gesucht habe. Sie haben mir einiges an Zeit, Frust und Kosten für eine mehr oder weniger hilfreiche Schnittstellenberatung gespart! Also tatsächlich "BEDI "uztv8754..."" . Mit dankbaren Grüßen Joachim

joachim_buchhaltung · ‎20.10.2020

Da uns nur das Prüfprogramm vom Developer Portal zur Verfügung steht, habe ich jetzt mal beide Varianten ausprobiert: Das Datev-Prüfprogramm akzeptiert beides ohne Fehlermeldungen : "BEDI ""0a16fdb0-dd5c-4e6c-91b9-8d97ca554ad1""" "BEDI "0a16fdb0-dd5c-4e6c-91b9-8d97ca554ad1"" zeigt aber dann in der Datensatzliste an: "BEDI ""0a16fdb0-dd5c-4e6c-91b9-8d97ca554ad1""" wird angezeigt als BEDI "0a16fdb0-dd5c-4e6c-91b9-8d97ca554ad1" "BEDI "0a16fdb0-dd5c-4e6c-91b9-8d97ca554ad1"" wird angezeigt als BEDI 0a16fdb0-dd5c-4e6c-91b9-8d97ca554ad1 Das legt den Schluss nahe, dass man die GUID in zwei Anführungszeichen einschliessen muss. Nun ist das aber "nur" das Prüfprogramm und nicht z.B. Kanzlei RW, wie sie beim Nutzer läuft....

joachim_buchhaltung · ‎20.10.2020

Hallo nochmals, @chrisocki Sie beziehen sich auf das hier: Das ist natürlich in mehrerlei Hinsicht nur auf den ersten Blick ausführlich und komplett Wenn man sich den Beispieltext ansieht, sind das zwei verschiedene Anführungszeichen um die GUID herum, das eine ist nach hinten geneigt, das andere nach vorne. Welche Zeichen aus dem ANSI-Zeichenvorrat sind das denn? Meine Annahme, dass das simple doppelte Anführungszeichen seien, passen zu diesem Bild gar nicht Wie ich schon schrieb, verlangt das Datev-Prüfprogramm, dass die Spalte BelegLink in Anführungszeichen eingeschlossen ist. Es ist dann aber nicht CSV-konform, einfach nochmal Gänsefüßchen in diese Spalte zu packen, denn das 1. Anführungszeichen am Anfang der Spalte "eröffnet" den Text, das nachfolgende markiert dessen Ende. Gemeint ist aber in diesem speziellen Fall, dass man die GUID in den Text einbettet. Sie sehen, so ganz klar ist die Doku der Datev leider nicht...

joachim_buchhaltung · ‎20.10.2020

Hallo @chrisocki , vielen Dank für den Link. Das Developer Portal ist eine gute Ressource, um sich in die Formate einzulesen. Genau da komme ich her und leider ist das Dokument höchst unpräzise zum Thema BelegLink. Im Leitfaden steht, *im" Feld Beleglink müsse stehen BEDI "64564-..." Das Prüfprogramm moniert, dass die Textspalten in Gänsefüßchen stehen müssen, auch, wenn sie leer sind. Folgerichtig könnte man meinen, "BEDI "64564-..."" wäre das korrekte Format. Genau das ist aber eigentlich kein korrektes CSV mehr. So manches CSV-Einleseprogramm würde nach dem 2. Anführungszeichen eigentlich einen Spaltentrenner erwarten... Die Frage ist nun also, will die Datev hier korrektes CSV und die "Inneren" Gänsefüßchen müssen escaped werden (vorangestelltes Backslash oder nochmals ein Anführungszeichen o.ä.) oder ist es in Ordnung, wenn die Datei sich nicht um die Standards in Sachen CSV kümmert...

joachim_buchhaltung · ‎20.10.2020

Ich würde gerne eine Bonusfrage zu diesem Thema stellen: In der Datev-Formatbeschreibung steht, im Feld BelegLink solle stehen: BEDI "dgf56t235-..." also ein Präfix für die Anwendung, in der die Belege zu finden sind. Nun ist aber das ganze Feld BelegLink in Anfürhungszeichen zu stellen, das heisst, wenn ich die Datev-Formatbeschreibung wörtlich nehme, müsste in der Spalte BelegLink stehen: "BEDI "365zht4-.."" Das ist aber eigentlich kein gültiges CSV mehr, und so mancher CSV-Parser wird hier mit der Anzahl öffnender und schliessender Anführungszeichen durcheinander kommen.... Wie muss das Feld denn nun konkret befüllt sein (und nein, der Leitfaden 7.0 beantwortet diese Frage NICHT). Ganz konkret: IN wie viele Anführungszeichen muss die GUID eingeschlossen werden, innerhalb des Strings, der die ganez Spalte repräsentiert? Joachim

joachim_buchhaltung · ‎15.10.2020

Das Ergebnis ist - soweit erkennbar - korrekt, aber bei einem umfangreichen Buchungsstapel kommt der Hinweis hunderte Male und stört dann eben doch den Arbeitsfluss.

joachim_buchhaltung · ‎15.10.2020

Hallo und vielen Dank fürs Lesen und Antworten, @Marco_Lachmann , das Belegfeld 2 enthält in allen Zeilen der Datei doppelte Anführungszeichen, ist also leer, aber eben als Text markiert. Ist das nicht korrekt? Zudem habe ich noch gefunden, dass Spalte 15 / Postensperre leer ist, also weder eine 1 noch eine 0 enthält. Da es kein Mussfeld ist, scheint mir das aber i.O. zu sein?

joachim_buchhaltung · ‎13.10.2020

Wo kann ich näheres zu diesem Fehler finden? Problem: ein Buchungsstapel eines Fremdprogramms kann nicht eingelesen werden. Dabei sind in der Datei keinerlei OPOS-Informationen enthalten, die Spalten sind allesamt leer. Der Text zur Meldung: Zu diesem Buchungssatz liegen OPOS-Informationen (z.B. Postensperre) vor, es ist aber kein OPOS-Konto erfasst. Die OPOS-Eingaben werden in diesem Fall verworfen. Ich kann in der EXTF-Datei aber keinerlei OPOS-Eingaben finden...

Beiträge und Ideen von joachim_buchhaltung

Auszeichnungen