oxaion open erlaubt die Bereitstellung von Buchungsstapeln und Debitoren-/Kreditoren-Stammdaten als ASCII-Datei (Dateinamen-Erweiterung.txt/-.csv) für den Import von oxaion Daten in ein DATEV pro-Rechnungswesen-Programm. Dabei wird das in den DATEV pro-Rechnungswesen-Programmen hinterlegte Standardformat (= DATEV-Format) in Version 5.1 bereitgestellt. Im oxaion Standard nicht unterstützt werden vom DATEV-Format abweichende individuelle ASCII-Formate.
Ein Export nach DATEV ist somit möglich für

  • die oxaion Adress-bzw. Personenkonteninformationen,
  • den aus der oxaion Materialwirtschaft resultierenden Rechnungsbelege (Rechnungen der Module Verkauf, Einkauf, Projekt und Service) oder alternativ
  • den kompletten Buchungsstoff der oxaion Finanzbuchhaltung.

Um diese Übergaben durchführen zu können, müssen bei der Systemeinrichtung von oxaion open und in DATEV diverse Vorgaben unbedingt berücksichtigt werden. Nur die strikte Einhaltung dieser Konventionen stellt eine funktionsfähige, korrekte Übergabe von Adressen, Rechnungen und Fibu-Belege an DATEV sicher.

Die Übergabe der Belege der Lager-/Fibu-Schnittstelle gehört explizit nicht zum Leistungsumfang der DATEV-Übergabe des oxaion Standards. Dies muss bei der Einrichtung des Firmenstamms (Lasche Installationskennzeichen) durch Inaktivierung des Moduls "Lager/Fibu" berücksichtigt werden. Die Lager-/Fibu-Schnittstelle in oxaion dient der Abbildung einer permanenten Inventur. Die zugehörigen oxaion Buchungsvorgänge sind nicht kompatibel mit der üblichen Buchungslogik von DATEV und erfordern eine Umstellung der DATEV-Buchungssystematik in Verbindung mit einer detaillierten Analyse bezüglich der konkreten Anpassungen in DATEV. 

Eine Beschreibung des DATEV-Formats findet sich in der DATEV Info Datenbank (http://www.datev.de/dnlexos/mobile/webapp.aspx) für das Dokument Nr. 1036228.

Die im Zuge dieses Verfahrenshandbuchs gezeigten Sachkonten sind dem DATEV Standardkontenrahmen (SKR) 03 entnommen. Die Konten sind dabei beliebig gewählt und stellen keine Vorgabe dar. 

Die Programme für die Bereitstellung der DATEV-Schnittstellen finden sich im Schnittstellenmenü der Finanzbuchhaltung: 


Grundlegende Einstellungen

Konfiguration der DATEV-Schnittstelle

Die grundlegenden Einstellungen zur DATEV-Schnittstelle werden in der firmenspezifischen oxaion Tabelle FRDDTV vorgenommen:

Unter Firmennummer ist die Nummer der Mandanten in oxaion einzugeben, für den die Daten übergeben werden sollen. 

Die Berater- sowie Mandantennummer dient der Identifikation des DATEV-Anwenders.

Als 'Verrechnungskonto allgemein' ist das Sachkonto einzutragen, welches bei der Übergabe des kompletten Buchungsstoffs der oxaion Finanzbuchhaltung für die Buchungszeilen der oxaion Belege jeweils als Gegenkonto herangezogen wird. Der Saldo diese Konto beträgt immer null.

Das allgemeine Verrechnungskonto muss ein funktionsneutrales Konto sein (keine Zusatzfunktion Vorsteuer/Mehrwertsteuer, keine Hauptfunktion). Hierzu bietet sich das DATEV-Konto ꞌSonstige Verrechnungskonten (Interimskonten)ꞌ an. Im SKR03 lautet das Konto 1792; im SKR 04 ist dies das Konto 3630.

Alternativ kann in DATEV in der Kontenklasse 9 auch ein funktionsneutrales Hilfskonto neu angelegt werden. Im SKR 03/04 Stand 2014 ist der Bereich 9989 bis 9999 noch unbelegt.

Die 'Länge des Sachkonto' bezieht sich auf die Länge der Sachkontonummern in DATEV. Sind in DATEV die Sachkontennummern 4-stellig definiert, ist hier eine 4 einzutragen. In DATEV sind die Personenkontennummern eine Stelle länger als die Sachkontennummern. Vierstellige Sachkonten implizieren also Personenkonten mit 5 Stellen. oxaion unterstützt 4- bis 6-stellige Sachkontennummern. Die korrespondierenden Personenkontennummern sind dann 5 bis 7-stellig. Die hier gewählte Einstellung ist für die Struktur der Sachkontennummern und Adressen- bzw. Personenkontennummern in oxaion bindend. 

Für die an DATEV zu übergebenden Adressen und Buchungen ist jeweils unter 'Pfad für DATEV Stammdatenʹ und 'Pfad für DATEV Bewegungsdatenʹ ein Netzwerkverzeichnis (oder alternativ ein lokales Verzeichnis) anzugeben, in welches die Daten von oxaion ausgegeben werden. Das Netzwerkverzeichnis muss als UNC-Pfad angegeben werden. Die Angabe eines gemappten Laufwerks ist nicht zulässig.

Die im DATEV-Format bereitgestellten Dateien lauten:

  • 'EXTF_Stammdaten.csv' (Adressen),
  • 'EXTF_buchung.csv' (Buchungsstoff der Materialwirtschaft) bzw.
  • 'EXTF_buchungKomplett.csv' (kompletter Buchungsstoff der Finanzbuchhaltung).

Ferner erfolgt in den angegebenen Pfaden bei der ersten Übergabe systemseitig die Anlage eines Unterordners Archiv. Jede Adress-/Buchungsübergabe wird zusätzlich in den Archiv-Ordner kopiert und erhält einen Zeitstempel.

Bei der Rechnungsübergabe an DATEV ist es möglich entweder das Fälligkeitsdatum oder die Zahlungsbedingung an DATEV zu übergeben. Bei Auswahl der 'Rechnungsübergabe mit Zahlungsbedingung' wird im Belegfeld 2 des DATEV Buchungsstapels die Zahlungsbedingung der oxaion Rechnung eingestellt. Seitens DATEV besteht dabei die Restriktion, dass nur 2-stellige Zahlungsbedingung übergeben werden können. Es wird somit die 2. und 3. Stelle der oxaion Zahlungsbedingung übergeben. Dies ist bei der Erfassung der Zahlungsbedingung in oxaion und DATEV zu berücksichtigen. Insofern die Rechnungsübergabe mit Zahlungsbedingung nicht ausgewählt ist bzw. die Rechnung eine 'individuelle Zahlungskondition' aufweist, wird in das Belegfeld 2 das Fälligkeitsdatum eingestellt.

Die Ausgabe des Leistungsdatums ist vorzusehen, falls die DATEV Anwendung leistungsorientiert arbeitet. Mit DATEV-Format Version 5.1 ermöglicht DATEV die Einstellung eines Leistungsdatums im Buchungsstapel. In diesem Fall steuert das Leistungsdatum den Vorlauf des Buchungsstapels und der Vorlauf ist nicht mehr automatisch die Periode der Umsatzsteuervoranmeldung. Voraussetzung für die Übergabe des Leistungsdatums ist, dass die DATEV Anwendung selbst leistungsorientiert konfiguriert ist. Insofern bei Eingangsrechnungen Leistungsbezug und Rechnungseingang in unterschiedlichen Perioden liegen, kann in oxaion das Eingangsdatum der Rechnung abweichend erfasst werden. Dies wird dann anstatt des Rechnungsdatums in das Belegdatum des Belegs des DATEV-Buchungsstapels eingestellt; das oxaion Rechnungsdatum entspricht dabei dem DATEV Leistungsdatum. Bei debitorischen Rechnungen wird das oxaion Buchungsdatum grundsätzlich sowohl als Leistungsdatum als auch Belegdatum an DATEV übergeben.

Prämissen für die Konfiguration von oxaion und DATEV

Ist für einen oxaion Mandanten die Nutzung der DATEV-Schnittstelle beabsichtigt, müssen sowohl in oxaion als auch in DATEV bei der System-Einrichtung verschiedene Restriktionen und Prämissen berücksichtigt werden. Nur deren strikte Beachtung stellt die Kompatibilität der Schnittstelle von oxaion an DATEV sicher.

Sachkonten
Die Länge der Sachkonten in DATEV kann 4, 5 oder 6 Stellen betragen (Erweiterungskonten werden von oxaion nicht unterstützt). Bei der Erfassung der 7-stelligen Sachkonten in oxaion werden Nullen vorangestellt. Ferner darf in oxaion nicht mit Unterkonten gearbeitet werden, da diese Information nicht übergeben werden kann.
Zudem sollten für alle DATEV Konten mit Steuerautomatik, der dem Steuervorgang entsprechende oxaion Steuerschlüssel im Sachkonto hinterlegt werden. Nur so ist eine steuerkonforme Buchung und korrekte Übergabe der Belege an DATEV gewährleistet.

Adressen/Personenkonten
Die mit der Länge des Sachkontos in DATEV korrespondierende Länge des Personenkontos in DATEV ist 5, 6 oder 7 Stellen. Debitoren beginnen dabei entsprechend dem DATEV SKR mit einer führenden Ziffer zwischen 1 und 6; Kreditoren beginnen mit einer führenden Ziffer zwischen 7 und 9. Bei 5-stelligen Personenkonten besitzen Debitoren folglich die Nummern 10000 bis 69999; Kreditoren weisen die Nummern 70000 bis 99999 auf.
Dies ist in oxaion bei der Erfassung von Adressen und Personenkonten bzw. der Anlage der entsprechenden Nummernkreise zu berücksichtigen.
In oxaion sind Personenkonten 13-stellig und bestehen aus einer 10-stelligen Adresse, ergänzt um eine 3-stellige Personenkontenart. Die 10-stellige Adresse besteht dabei aus einer 7-stellige Adressnummer, verlängert um die 3-stellige Filialnummer. 

Die 7-stellige Adressnummer entspricht dabei der Personenkontonummer in DATEV. Bei der Erfassung der Adressnummer in oxaion sind den DATEV Personenkontennummern ggf. Nullen voranzustellen. 

Die Filialnummer einer Adresse in oxaion darf nicht zur Unterscheidung der Adressnummer genutzt werden. Aus DATEV Sicht lassen sich z.B. die zwei oxaion Adressen 0010000 000 und 0010000 001 nicht unterscheiden. Bei der Übergabe der Adressinformationen würde die Adresse 0010000 001 daher ignoriert werden. Bei der Rechnungsübergabe an DATEV würden die Rechnungen solcher zwei Adressen unter der ersten Adressnummer bereitgestellt werden. Dies kann am Einfachsten durch die strikte Beschränkung auf eine einzige Filialnummer z.B. '000' vermieden werden. 

Bei der Erfassung der Personenkonten in oxaion muss sichergestellt werden, dass zu jeder Adresse auch nur ein Personenkonto vorhanden ist. Insofern zu einer Adresse mehrere Personenkonten vorhanden sind, werden bei der Übergabe der Adressen-/Personenkonteninformationen an DATEV lediglich die Informationen des ersten Kontos berücksichtigt. Auch geht die Information des konkreten Personenkontos bei der Übergabe der Rechnungen und des Buchungsstoffes Fibu an DATEV verloren. Es muss daher grundsätzlich auf die Anlage mehrere Personenkonten zu einer Adresse verzichtet werden.

Lediglich bei Nutzung der Anzahlungsautomatismen in oxaion ist die Erfassung mehrerer Personenkonten zu einer Adresse zulässig. In oxaion erfordern diese Automatismen die Erfassung von drei Personenkonten zu einer Adresse.

Für DATEV ist diese Unterscheidung ohne Bedeutung, in DATEV werden Anzahlungen über ein und dasselbe Personenkonto gebucht. Insofern können bei der Übergabe an DATEV die Anzahlungsbuchungen der verschiedenen Personenkonten von oxaion auf die Adressnummer reduziert werden.

Bei der Übergabe der Adress-/Personenkonteninformationen an DATEV werden sowohl die Informationen neuer als auch geänderter Adressen bzw. Personenkonten übertragen.

Bei der Übergabe der Stamm- und Bewegungsdaten an DATEV findet keine Umsetzung der Personenkonten- und Sachkontennummern statt. 

Steuerschlüssel
Die Steuerschlüssel müssen in oxaion anlog DATEV angelegt werden. Den einstelligen DATEV Steuerschlüssel ist in oxaion dabei eine Null voranzustellen. Zusätzlich müssen wie unten gezeigt die Systemsteuerschlüssel 9U und 9V in oxaion erfasst sein. Werden Rechnungen mit einem Steuerschlüssel 9U oder 9V an DATEV übergeben, wird in den DATEV Buchungssatz kein Steuerschlüssel eingestellt.

Alternativ zur oben gezeigten DATEV-konformen Anlage der oxaion Steuerschlüssel besteht die Möglichkeit, für die Übergabe der Buchungsstoffs an DATEV über die oxaion Tabelle FRDDTS die oxaion Steuerschlüssel in die DATEV Steuerschlüssel zu konvertieren. Die DATEV Steuerschlüssel sind dabei im zweiten Tabellenparameter 'Steuerschlüssel DATEV' linksbündig einzutragen.

Sachkonten ohne Steuerautomatik
Sachkonten mit Zusatzfunktion Vorsteuer/Mehrwertsteuer aber ohne Kontenfunktion AM (keine Steuerautomatik), müssen insofern gebucht in der Tabelle FRDKOA (Konten ohne Automatik) erfasst werden. In diesem Fall wird der Steuerschlüssel in die die Buchungszeile eingestellt.

Umbuchung an DATEV
Über die Tabelle FRDDTU (Umbuchungen DATEV) besteht die Möglichkeit, für die Übergabe an DATEV eine Umbuchung auf ein abweichendes Sachkonto vorzusehen. Diese Umbuchungen werden für die Kombination aus Sachkonto und Steuerschlüssel der oxaion Buchungszeile definiert. 

Das Sachkonto wird mit einer Länge von 6 Stellen angegeben. Der Steuerschlüssel mit einer Länge von 4 Stellen. Ist der Steuerschlüssel kürzer, so ist der Steuerschlüssel, wie im Programm "Steuerschlüssel" erfasst, einzugeben. Dies ist i.d.R. linksbündig.

Zahlungsbedingungen, Kostenstellen und Kostenträger
Es erfolgt keine Übergabe der in oxaion vorhandenen Zahlungsbedingungen an DATEV. Die Zahlungsbedingungen sind in DATEV manuell zu erfassen. Für die Anlage der Zahlungsbedingungen stehen sowohl in oxaion als auch in DATEV grundsätzlich 3 Stellen zur Verfügung.
Insofern jedoch aufgrund entsprechender Einstellung der Tabelle VRLDTV (vgl. Parameter Rechnungsübergabe mit Zahlungsbedingung) im Belegfeld 2 des DATEV Buchungsstapels die Zahlungsbedingung anstatt dem Fälligkeitsdatum übergeben wird, dürfen die Zahlungsbedingungen aufgrund einer DATEV Restriktion lediglich 2-stellig sein. Dabei werden die 2. und 3. Stelle der oxaion Zahlungsbedingung in das Belegfeld 2 des Buchungsstapels eingestellt. Die 2 stellige Anlage der Zahlungsbedingungen sollte daher in oxaion mit einem führenden Leerzeichen erfolgen.
Entsprechend verhält es sich für die Kostenstellen und Kostenträger. Diese sind in DATEV analog oxaion manuell zu erfassen. Dabei sind die unterschiedlichen Längen zu beachten:


Länge in oxaion

Länge in DATEV

Kostenträger

10 Stellen

8 Stellen

Kostenstelle

7 Stellen

8 Stellen


Fremdwährung
Bei Firmen, deren Basiswährung nicht dem Euro entspricht, wird nur die Basiswährung übergeben.
Bei der Übergabe der Rechnungen (USNINP) an DATEV werden für in Fremdwährung gestellte Rechnungen lediglich der Fremdwährungsbetrag, der Kurs und der Währungsschlüssel übergeben. Die Umrechnung in Basiswährung erfolgt durch DATEV anhand des übergebenden Kurses.
Bei der Übergabe des kompletten Buchungsstoffs an DATEV werden die Buchungen ausschließlich in Basis-Währung übergeben. 

Die Notation der Fremdwährungskurse in oxaion muss in Mengennotation erfolgen:

Forderung- und Verbindlichkeitshauptkonten
Die Buchungen der Forderung- und Verbindlichkeitshauptkonten werden an DATEV nicht übergeben.

Belegnummer/-datum bei Lieferanten-Rechnungen
DATEV kennt nur eine Belegnummer und unterscheidet nicht wie oxaion zwischen einer internen Belegnummer und einer externen Rechnungsnummer. Bei Lieferanten-Rechnungen wird in DATEV die Rechnungsnummer des Lieferanten als Belegnummer geführt; die Belegablage in DATEV erfolgt sortiert nach Lieferanten und Rechnungsnummer des Lieferanten. Aus diesem Grund wird bei kreditorischen Belegen die externe Rechnungsnummer des Belegs an DATEV als Belegnummer übergeben. Liegt keine externe Rechnungsnummer vor, wird wie bei den debitorischen Belegen die interne Belegnummer an DATEV übertragen. Die Eingabe der externen Rechnungsnummer in oxaion muss linksbündig erfolgen. Es ist sinnvoll, diese bei einer Länge größer als 12 Stellen, von links auf 12 Stellen (Länge der Belegnummer in DATEV) zu kürzen. 

Ferner wird bei der Übergabe der Lieferantenrechnungen aus EKS (USNINP) an DATEV anstatt des Buchungsdatums grundsätzlich das Rechnungsdatum als Belegdatum übergeben (DATEV erfasst Eingangsrechnungen üblicherweise mit Belegdatum gleich Rechnungsdatum). Bei Ausgabe des Leistungsdatums (vgl. hierzu Konfiguration der DATEV-Schnittstelle), wird das Rechnungsdatum in das Leistungsdatum und das Eingangsdatum in das Belegdatum eingestellt. Falls die oxaion Rechnung kein Eingangsdatum ausweist, wird auch in das Belegdatum das Rechnungsdatum eingestellt. 

Wird mit der oxaion Finanzbuchhaltung gearbeitet und es erfolgt eine Übergabe des kompletten Buchungsstoffs an DATEV, muss bei der Buchung kreditorischer Belege in der Finanzbuchhaltung das Rechnungsdatum als oxaion Buchungsdatum eingeben werden. Dies ist erforderlich, um die Abstimmbarkeit der Umsatzsteuervoranmeldungen zu ermöglichen. In DATEV gibt das Belegdatum die Steuerperiode vor, in oxaion ist dies das Buchungsdatum bzw. Eingangsdatum. 

Gleiches gilt in diesem Falle für die Erfassung der Lieferantenrechnungen im Einkaufsmodul EKS. Um den Kontierungsgewohnheiten von DATEV Rechnung zu tragen, muss auch für diese sichergestellt sein, dass als Buchungsdatum das Rechnungsdatum vorgegeben wird. In diesem Zusammenhang ist die Tabelle VRLE14 bzgl. des Unterlassungswerts für das Buchungsdatum zu prüfen (in oxaion wird üblicherweise das Eingangsdatum als Unterlassungswert für das Buchungsdatum herangezogen). Auf die manuelle Eingebbarkeit des Buchungsdatums sollte vor diesem Hintergrund möglichst verzichtet werden. Sofern der Anwender leistungsorientiert arbeitet, wird für die kreditorischen Belege der Finanzbuchhaltung als DATEV Belegdatum das oxaion Eingangsdatum und als DATEV Leistungsdatum das oxaion Buchungsdatum eingestellt. Insofern der Beleg kein Eingangsdatum ausweist wird das Buchungsdatum auch als DATEV Belegdatum herangezogen. 

Darüber hinaus sollte der Parameter Periodenprüfung Tabelle VRLE20 grundsätzlich so eingestellt sein, dass die Rechnungen nicht an die Eingangsschnittstelle der Fibu übergeben werden, falls die Buchungsperiode buchhalterisch (Periodenstatus Finanzbuchhaltung) nicht geöffnet ist. Ist das Kennzeichen Periodenprüfung gesetzt, wird ein Buchungsdatum automatisch auf die nächste freie Periode abgeändert, insofern die zugehörige Periode nicht offen ist. Die Einstellung bzw. Änderung dieses Parameters erfordert eine Abstimmung mit der Finanzbuchhaltung. 

Es ist in diesem Zusammenhang unbedingt notwendig, die Periodensteuerung in oxaion mit der Umsatzsteuervoranmeldung (UVA) in DATEV zu synchronisieren. Die UVA-Periode in DATEV bzw. der Vorlauf wird durch das bis-Datum des DATEV-Buchungsstapels bestimmt. Das bis-Datum ergibt sich dabei aus dem größten Buchungsdatum der zu übergebenden Belege. Dies ist insbesondere bei der Rechnungsübergabe (USNINP) zu beachten, da diese einen variablen Übergabezeitraum ermöglicht. 

Einrichtung der Anzahlungskontenarten

Bei der Einrichtung der Kontenarten für die Verarbeitung der Anzahlungen (vgl. hierzu das oxaion Verfahrenshandbuch Anzahlungen) ist darauf zu achten, dass bei einer debitorischen Kontenart vom Typ "1" als Verrechnungskonto 1 das DATEV Konto 'Verrechnungskonto erhaltenen Anzahlungen bei Buchung über Debitorenkonto' hinterlegt wird (im SKR 03 lautet dies 1593; im SKR 04 lautet dieses 1495). Analog verhält es sich mit der kreditorischen Kontenarten vom Typ "1". Hier ist das DATEV-Konto 'Verrechnungskonto geleistete Anzahlungen bei Buchung über Kreditorenkonto' heranzuziehen (im SKR 03 lautet dies 1793; im SKR 04 lautet dieses 3695). Als Sachkonto diese Kontenart sollte in der Kontenklasse 9 ein funktionsneutrales Konto definiert und hinterlegt werden. 

Bei einer debitorischen Kontenart vom Typ "2" ist bei 19% Steuer als Verrechnungskonto 1 das DATEV-Konto 'Erhaltene versteuerte Anzahlungen 19% Umsatzsteuer (Verbindlichkeiten)' zu hinterlegen (im SKR 03 lautet dies 1718; im SKR 04 lautet dieses 3272). Für eine kreditorische Kontenart vom Typ 2 bei 19% Steuer ist das DATEV-Konto 'Geleistete Anzahlungen 19% Vorsteuer' heranzuziehen (im SKR 03 lautet dies 1518; im SKR 04 lautet dieses 1186). Als Sachkonto und Verrechnungskonto 2 dieser Kontenart sollten in der Kontenklasse 9 funktionsneutrale Konten definiert und hinterlegt werden.

Die dargestellte Einrichtung der Anzahlungskontenarten ist nicht zwingend und muss mit der konkreten Buchungspraxis der Anzahlungen des DATEV-Anwenders abgestimmt werden. Diese kann von der dargestellten Systematik abweichen

Rechnungsübergabe an DATEV und Nutzung der Anzahlungen

Insofern aus den oxaion Modulen EKS, VKS und PRM ausschließlich die Rechnungen und nicht der gesamte Buchungsstoff an DATEV übergeben werden, sind bei Nutzung der Anzahlungsfunktionalität Restriktionen zu berücksichtigen, welche auch in DATEV eine besondere Handhabe erfordern. Voraussetzung für die hier beschriebene Funktionalität ist, dass das Installationskennzeichen Finanzbuchhaltung im Firmenstamm nicht ausgewählt ist. 

Da aus der DATEV-Finanzbuchhaltung keine Rückmeldung über die Zahlung der Anzahlungsrechnungen an oxaion erfolgt, werden die in oxaion erstellten Anzahlungsrechnungen nicht an DATEV übergeben. 

Bei Stellung der Schlussrechnung in PRM werden nun auf dem Rechnungsbelegdruck sämtliche gestellte Anzahlungen in Abzug gebracht und der noch nicht in Rechnung gestellte Teil ausgewiesen. 

Im Belegdruck einer VKS-Schlussrechnung werden ebenfalls die bereits gestellten Anzahlungs-rechnungen aufgeführt und der der noch nicht in Rechnung gestellte Restbetrag ausgewiesen. 

Bei Stellung der Schlussrechnung erfolgt, analog einer Übergabe innerhalb oxaion, auch an DATEV grundsätzlich die Übergabe des vollständigen Rechnungsbetrags. In der oxaion Finanzbuchhaltung werden bei Verbuchung der Schlussrechnung noch nicht bezahlte Anzahlungen storniert und bereits erfolgte Zahlungen werden mit der Schlussrechnung verrechnet. In der oxaion Finanzbuchhaltung entsteht so ein Rest-OP über den noch offenen Teilbetrag der Schlussrechnung. 

In DATEV müssen die aus den Zahlungen der Anzahlungsrechnungen resultierenden steuerlichen Abgrenzungsbuchungen (Nettoausweis der Anzahlungen, Steuerbuchung) manuell durchgeführt werden. Ebenso sind mit Übergabe der Schlussrechnung aus oxaion, in DATEV die steuerlichen Abgrenzungsbuchungen zu stornieren und es ist eine Verrechnung der bereits gezahlten Anzahlungen mit der Schlussrechnung aus oxaion vorzunehmen. Diese Tätigkeiten können in DATEV im Rahmen des Monatsabschlusses erfolgen.

  • Keine Stichwörter