Herkunftskennzeichen Nach Import von Buchungsstapeln

[#1]

Wie haben folgende Situation:

Mandant erfaßt seine Buchhaltung vor Ort und sendet uns die DATEV- Vorläufe per Email zu.

In der Kanzlei werden die Vorläufe importiert, kontrolliert (notfalls korrigiert) und dann festgeschrieben und gesendet.

Der Masterbestand mit den Festschreibe- und Sendeprotokollen liegt damit immer in der Kanzlei.

(So verfahren wir seit Desy- DOS- Zeiten, heute Mittelstand Pro (ehem. Rewe Compact)...)

früher (bis November 2015) hatten die importierten Zeilen das Herkunftskennzeichen "SV" und die in der Kanzlei korrigierten Buchungen erhielten das "RE"

Seit der Jahreswechsel- Version von Rewe bekommen alle importierten Zeilen das Herkunftskennzeichen "RE" und somit ist nicht mehr erkennbar, welche Buchungen der Kanzlei- Mitarbeiter ändern mußte.

Das Thema: "Festschreiben beim Import" stellt sich nicht, da die EG- Buchungen bereits aus dem Mandanten- System gemeldet wurden und beim Datenimport lediglich verdichtete Umsätze ohne ID- Bummer übergeben werden, welches das Festschreibungsmerkmal weg kickt.

Frage:

Wurde die Funktion vom Herkunftskennzeichen absichtlich geändert, oder kann mit einer baldigen Widerherstellung das alten Zustandes gerechnet werden?

PS: Hotline ist heute überlastet und hat mich mehrmals aus der Leitung gekickt... Deshalb die Anfrage hier im Forum.

Gruß, Kolberg

[#2]

Hallo Herr Kolberg,

die Änderung beim Herkunftszeichen ist letztes Jahr im Rahmen der umfangreichen Änderungen durch die GoBD erfolgt. Werden Daten im DATEV-Format ausgetauscht, bleibt das ursprüngliche Herkunftskennzeichen (aus dem Vorsystem oder Rechnungswesen-System des Mandanten) erhalten.

Diese Änderung ist beim Datenaustausch in vielen Fällen zwingend erforderlich, da ansonsten diese im Allgemeinen notwendige Information zum Buchungssatz verloren ginge. Mit dem Herkunftskennzeichen werden auch andere Programmprüfungen durchgeführt (z. B. Änderungssperre für "Buchungen bereichsweise ändern").

Meines Erachtens kann diese Einstellungen nicht geändert werden - hier bliebe nur der Weg das Herkunftskennzeichen direkt in der Importdatei zu ändern.

Viele Grüße

Christian Wielgoß

[#3]

Wenn dann müsste man diese Änderung jedes Mal dokumentieren. Grundsätzlich ist das kein Problem ich würde mir aber überlegen, die Unterscheidung an anderen Gesichtspunkten als dem Herkunftskennzeichen festzumachen. (Z.B. Benutzerkürzel oder Primanotenbeschriftung)

[#4]

Um Missverständnisse auszuräumen,

Mein Problem ist, daß bei den importierten Einzelbuchungssätzen durch das neue "RE" später nicht mehr erkennbar ist, ob diese Buchungssätze original vom Mandanten kommen, oder ob diese in der Kanzlei geändert wurden. (Screen aus einem Kontoblatt)

Eine Dokumentation "zu Fuß" (also Zeilenvergleich der Primanota) möchte niemand vornehmen, genauso, wie sich ein manuelles Bearbeiten der Transfer- Datei aus GoDB- Gründen verbietet.

Im Buchungsstapel vom Mandant "DTVF_Buchungsstapel_###_###_00001.csv" ist seit 2014 das "RE" in den Einzelzeilen vorhanden, welche beim Import durch das "SV" ersetzt wurden. Ab der Jahreswechsel- Version vom ReWe funktioniert das nicht mehr, und hier sehe ich einen Programmfehler.

[#5]

Hallo Herr Kolberg,

nein, ein Programmfehler sehe ich hier nicht. Letztendlich ist das nun einmal den GoBD geschuldet...

Viele Grüße

Christian Wielgoß

[#6]

Wenn das alte Postversand- Format importiert wird, funktioniert es wunderbar, daß das "SV" generiert wird, welches beim Bearbeiten zum "RE" wird. So läßt sich auf den Konten später problemlos erkennen, welche Buchungen vom Mandanten erfolgten, und welche Buchungen hier in der Kanzlei korrigiert wurden.

Vielleicht kann sich ein DATEV Mitarbeiter dazu äußern, weshalb diese Funktion beim DATEV- Format weg fallen mußte, insbesondere dann, wenn ein Festschreiben der beim Mandanten vorerfaßten Stapel beim Import nicht erfolgt.

Uns - und auch später dem Prüfer - fehlt diese Herkunftsinformation der Buchungssätze.

[#7]

Hallo Herr Kolberg,

da  Sie Änderungen ja schon offen dokumentieren wollen.... Welchen Unterschied macht es da, den Mand.-Vorlauf festzuschreiben und die Kanzleibuchungen in einen neuen Vorlauf zu schreiben? Wie Herr Wielgroß treffend ausführt, das sind die GoBD.

Gruß

C. Rohwäder

[#8]

Sehr geehrter Herr Rohwäder,

oben schrieb ich, daß EG- Sammelbuchungen enthalten sind, und aufgrund der nicht vorhandenen ID- Nummer für diese Vorläufe eine automatische Festschreibung vom System verweigert wird. (Siehe der kleine gelbe Screenshot)

Diese Sachverhalte wurden von der Mandanten- Software längst übermittelt, so daß diese Hinweise vor dem Festschreiben gelöscht werden können.

[#9]

Hallo Herr Kolberg,

bitte beachten Sie, dass das Herkunftskennzeichen nicht von der Festschreibung beim Import abhängig ist.

Bei der Nutzung des Auslaufmodells Postversanddaten finden die Kennzeichnung mit "SV" statt, da in diesem Format die Buchungsinformationen nur eingeschränkt möglich sind, so ist dort das Herkunftskennzeichen z. B. gar nicht vorhanden.

Viele Grüße

Christian Wielgoß

[#10]

Sehr geehrter Herr Wielgoß,

Diese wichtige Funktion wurde mit der Jahreswechsel- Version vom REWE geändert, und meine Frage an DATEV ist, ob dieses absichtlich geschah, oder ob in der Programmierung (oder nur in der Dokumentation) etwas übersehen wurde, was mit dem nächsten Update wieder korrigiert wird.

Ich würde mir von DATEV wünschen, daß auch in Zukunft erkennbar ist, welcher Buchungssatz einer Import- Datei nachträglich bearbeitet wurde; insbesondere dann, wenn es beim Import zu einem Fehler kam, der zum Festschreiben in der Kanzlei zu korrigieren ist.

[#11]

Dann wäre der saubere Weg die korrigierte Version vom Mandantensystem zu übernehmen.

[#12]

Wie oben geschrieben, handelt es sich beim Mandanten um eine Vorerfassung.

Der Referenzbestand mit den Festschreibungskennzeichen befindet sich in der Kanzlei.

Edit:
Selbstverständlich werden die Sammelbuchungen nicht gelöscht, sondern nur die Hinweise auf die nicht mögliche UST. ID- Nummer entsorgt.

[#13]

Hallo Herr Kolberg,

habe das mit dem vorherigen löschen der EG-Sammelbuchungen so verstanden.

Gruß

C. Rohwäder

[#14]

Hallo Herr Kolberg,

wie schon geschrieben, gehe ich nicht davon aus, dass es sich um einen Fehler handelt. Aus dem Gedächtnis bin ich auch der Meinung, dass dieser Sachverhalt in einem der Neuerungen-Dokumente (das ich leider nicht mehr finde) erwähnt war.

Eine Korrektur zu meinen Ausführungen wegen der Postversanddaten: Hier werden lediglich die Herkunftskennzeichen für SV (sonstige Stapel) und LO (Lohn) mitgegeben.

Viele Grüße

Christian Wielgoß

[#15]

Sehr geehrte Damen und Herren bei DATEV,

Es gibt bei Abschlüssen die Möglichkeit, den Abschlußlauf des Vorjahres zu exportieren, um diesen dann im laufenden Jahr wieder ohne Festschreibung zu importieren, um dann alle Buchungen mit SV an die tatsächlichen Gegebenheiten anzupassen.

Leider funktioniert das nicht mehr, und es gibt für den Sachbearbeiter keinerlei Möglichlkeiten, zu sehen, welche Buchungssätze aus dem Import stammen, bzw. welche Buchungssätze er selber erfaßte.

Dringender Wunsch:

Wenigstens das HK- Kennzeichen ließe sich "bereichsweise ändern:

Danke für eine zeitnahe Implementierung.

Kolberg

[#16]

Hallo zusammen,

wie gewohnt erfasse ich alle Anregungen aus dem Thread und melde mich, wenn es Neues dazu gibt.

Mit freundlichen Grüßen

Marco Lachmann

Service Rechnungswesen (FIBU)

DATEV eG