Zuerst einmal ein freundliches Hallo an alle. Bin Neuling und daher noch nicht mit allen Funktionen vertraut und bitte um Verständnis, wenn ich irgendetwas in der Bedienung der Diskussion falsch mache.
Unsere EDV für unsere Kleinfirma mit 2 Mitarbeitern erledigt im eigenen Unternehmen zuverlässig seit über 30 Jahren die Erfassung der notwendigen Daten zur Verbuchung in der Finanzbuchhaltung, Erstellung von GuV, Umsatzsteuervoranmeldung etc., basierend auf der Datenbank FoxPro, welche noch unter einem in einer virtuellen Maschine gepflegten Windows 2000 läuft. Alles superschnell und mit einem Abfragekomfort, wie man es aus den Suchmaschinen im Internet kennt (schon lang bevor DATEV überhaupt an solche Komfortfunktionen dachte). Dieses Programm können wir auch pflegen und in jede Richtung weiterentwickeln. Im Bereich der Buchhaltung gibt es nur die Einschränkung, dass die Werte für AfAs von Hand eingepflegt werden und wir es grundsätzlich dem Steuerberater überlassen, die Art der Abschreibung bei größeren Anschaffungen zu empfehlen bzw. festzulegen. Außerdem haben wir die Erfahrung gemacht, dass Banken oder andere Institutionen nur Vertrauen in Zahlen und Daten haben, wenn auf dem Ausdruck "DATEV" steht. Wir wollen auch keine "moderneren" Windows-Versionen installieren, weil wir in allen anderen Bereichen vollständig auf unixoiden Systemen arbeiten und ständige Lizenzgebühren für uns längst Vergangenheit sind. Leider ist eine Mandantenschnittstelle im Sinne von "Rechnungswesen Compact" für Linux nicht verfügbar (Auskunft des Steuerberaters - Ich lasse mich gern anderweitig belehren). Wenn es RechnungswesenCompact für Linux gäbe, würden wir es kaufen/lizensieren und jährlich updaten. Ich sage dies nur deshalb, weil wir mit unserer EDV vollumfängtlich zufrieden sind und deshalb Vorschläge in Richtung "Kaufen Sie sich doch ein aktuelles Windows" kein Gehör finden werden.
Folglich übermitteln wir die Buchungen für den Quartalsabschlüsse an den Steuerberater und nutzen hierfür die ASCII-Schnittstelle, d.h, den ASCII-Transfer. Unser System erstellt die Datensätze mit einer Kopfzeile vor den Daten. Hier ein Beispiel aus dem Jahr 2009 (zwecks Anonymisierung; klar dass aktuelle Daten auf 2016 enden):
"","",,,,"","","",,""
"EUR","+",200.00,0,1460,"***1","VGL33","31012009",1600,"KONTO AN KASSE"
"EUR","-",4.55,0,6800,"***2","","31012009",1600,"DEUTSCHE POST AG"
usw.
Dabei halten wir uns an das von DATEV früher einmal übermittelte Schema für das Datenformat "Buchungssätze":
Felder Typ Länge
Währungskennung A 0
**Soll/Haben-Kennzeichen A 0
**Umsatz (ohne Soll/Haben-Kennzeichen) N 0
BU-Schlüssel N 0
**Gegenkonto (OHNE BU-Schlüssel) N 0
Belegfeld1 A 0
Belegfeld2 A 0
*Datum D 0
*Konto N 0
Buchungstext A 0
*=Mussfeld
Allgemeine Einstellungen:
Satzaufbau: variabel
Feldausrichtung: rechts
Zeichensatz: ASCII-Format
Import ab Zeile 1:
Trennzeichen Felder: , (Komma)
Trennzeichen Nachkommastellen: . (Punkt)
Zeichen um Textfelder: " (Anführungszeichen
Trennzeichen Tausenderstellen: <Kein Trennzeichen>
Vorzeichen/Betragskennzeichen: S/H nach dem Beleg
Datumsformat: TTMM
Genau diesem Feldaufbau entsprechen auch obige Datensätze. In den Jahren 2005 - 2009 hatten wir uns jeweils auch eine Version von Rechnungswesen Compact besorgt, nur, um dort probehalber alle Daten im Bestand monatsweise einzulesen und zu verarbeiten. Neuere Versionen erfordern neuere Windows-Versionen, weshalb wir nicht mehr weiter updaten wollten. Wir konnten sämtliche Probleme, die sich durch das beschränkte Datenformat, welches DATEV verwendet (Keine Umlaute, etc.) durch Filter, die entsprechende Daten in das gewünschte Format bringen, eliminieren. Da sich nach unserem Ermessen aber an dem grundsätzlichen Aufbau der Datensätze nichts mehr geändert hat, verzichten wir seit 2009 auf eine Aktualisierung. Wir wenden stattdessen den Trick an, die bei den bei uns vorhandenen Datensätzen das aktuelle Jahresdatum gegen 2009 zu ersetzen und die Daten probehalber in die 2009er-Version von DATEV einzulesen. Dies klappte und klappt bei uns bisher anstandslos.
Als wir nun die Quartalsdaten an unseren Steuerberater übermittelt haben, gab es jedoch beim Einlesen Probleme:
Das Feld Gegenkonto des ersten Datensatzes wird beim Einlesen auf 0 gesetzt, was zur Folge hat, dass das DATEV-Programm natürlich eine "Fehlende Eingabe" in diesem Feld als Fehler "anmeckert". Beim zweiten Datensatz steht das Gegenkonto des ersten Datensatzes, beim dritten das des zweiten, usw. mit anderen Worten, die Spalte Gegenkonto wird quasi um eine Reihe nach unten verschoben. Die erste Eintragung wird "genullt", der letzte Eintrag in diesem Feld "verschwindet". Dies würde Rohdaten entsprechen, die wie folgt aussähen:
"","",,,,"","","",,""
"EUR","+",200.00,0,0000,"***1","VGL33","31012009",1600,"KONTO AN KASSE"
"EUR","-",4.55,0,1460,"***2","","31012009",1600,"DEUTSCHE POST AG"
usw.
Dass sich damit in Folge weitere Fehler bei den Buchungsschlüsseln ergeben ist eine logische Folge. Die von uns gelieferten Daten sind aber einwandfrei, d.h. nicht etwa bzgl. des einen Feldes "verschoben"! Ein Einlesen in die 2009 DATEV-Version liefert hingegen völlig fehlerfreie Ergebnisse,
Da ich zur Zeit mit Grippe im Bett liege, komme ich nicht direkt an einen Rechner des Steuerberarers, sehe also auch keine Eingabemaske bzw. mögliche Optionen. Für mich gibt es aber zwei potentielle "Fehlermöglichkeiten", wenn man unterstellt, dass der ASCII-Import bei DATEV-Kanzleiprogrammen zur Zeit nicht einen prinzipiellen "bug" hat:
Entweder,
DATEV verlangt mittlerweile irgendwelche anderen Trennzeichen (könnten wir bei den Rohdaten natürlich ändern)
oder
DATEV erlaubt neuerdings in der Formatbeschreibung, dass auch auf Felder vor oder nach der aktuellen Zeile ein Zugriff möglich wäre?
Könnte mir freundlicherweise irgendjemand sagen, ob ihm oder ihr Etwas zu bekannt ist oder ob jemand den sonstigen Grund für den Fehler kennt?
Danke für jeden Hinweis
