Sehr geehrte Damen und Herren,
wir programmieren gerade eine XML-Schnittstelle zu DATEV. Dadurch das unsere Kunden Bauningenieurbüros sind haben wir sehr oft Abschlagsrechnungen (Anzahlungen). Bauprojekte dauern in der Regel Jahre. Schlussrechnungen werden i. d. R. erst bei Abnahme des Bauprojektes gestellt:
Die geleisteten Zahlungen auf die Anzahlungen können wir in payment_conditions/@amount_of_payment bzw. payment_conditions/@time_of_payment abbilden. Wie können wir aber Anzahlungen zu / in Schlussrechnungen zu ordnen / auflösen?
Beispiel:
Anzahlung Nr. 1 am 01.02.2018, Zahlung 100 Euro
Anzahlung Nr. 2 am 01.03.2019, Zahlung 200 Euro
Anzahlung Nr. 3 am 01.04.2020, Zahlung 0 Euro
Schlussrechnung am 02.05.2020 mit Anzahlungen 1, 2 und 3 auflösen. Mit der Löung oben in der Schnittstelle haben wir nur die beiden Zahlungen auf Anzahlungen. In welchen Feldern der Schlussrechnung können die Anzahlungen in der XML angegeben werden?
Bedanke mich schon an dieser Stelle für Ihre Rückmeldungen.
Gelöst! Gehe zu Lösung.
Hallo @Werner_Wolfgang ,
für diese Sachverhalte sollten Sie besser die CSV-Datei im DATEV-Format umsetzen.
Mit der können Sie diese Form von Rechnungen bis ins Detail steuern.
Die XML-Schnittstelle hat kein Datenfeld zur Differenzierung von Anzahlungs- und Schlussrechnung. Die CSV-Datei schon. Die von Ihnen genannten Datenfelder payment_conditions/@amount_of_payment bzw. payment_conditions/@time_of_payment sind übrigens keine Datenfelder, die in Unternehmen online übernommen werden. Sie dienen lediglich zur Erzeugung eines künstlichen Belegs (wird immer erzeugt).
Sie können auch trotz CSV-Datei eine Verlinkung zu einem Belegbild ermöglichen. Hierfür ist die Spalte "Beleglink" in der CSV-Datei zu befüllen und dann müssen Sie nur noch den Beleg mit der DATEV XML-Schnittstelle online (nur document.xml + digitale Belege erforderlich) nach Unternehmen online bringen.
Für weitere Details dazu, können Sie auch hier eine Schnittstellenberatung buchen:
https://www.datev.de/online-kalender-schnittstellen
(z.B. Allgemeine Konzeptberatung)
Viele Grüße
Vincent Franke
Hallo Wolfgang,
wir haben uns ebenfalls mit der Erstellung diverser DATEV Schnittstellen beschäftigt und unsere Erfahrungen im folgenden Artikel zusammengefasst, vielleicht ist das ein oder andere für Sie interessant.
https://medium.com/spesenfuchs/datev-export-von-reisekosten-573109187441
Frohes Schaffen
Reisekostenrechner
Ich glaube ich habe mich falsch ausgedrückt: Wir unterscheiden Anzahlungen und Ausgangsrechnungen im XML nicht. Hier mal ein Beispiel wie es geplant ist:
Die Anzahlungen sollen aber den Rechnungen aufgelöst werden:
Ich habe hier ein Beispiel mit anonymen Daten:
Schlussrechnung 50.000 netto, 19% MwSt. mit den drei Anzahlungen, die drei Anzahlungen sollen aufgelöst werden:
Erster Tag <accountsReceivableLedger> ist die Buchung Umsatz für die Schlussrechnung
Forderung Debitor 60304 an Umsatzerlöse 8000
Zweiter Tag <accountsReceivableLedger> ist Buchung Auflösung 1. Anzahlung vollständig bezahlt
1711 Erhaltene deb. Anzahlungen an Forderung Debitor 60304
Dritter/Vierter Tag <accountsReceivableLedger> ist die Auflösung 2. Anzahlung teilweise bezahlt
1711 Erhaltene deb. Anzahlungen an Forderung Debitor 60304 (für bezahlten Betrag)
1452 angeforderte deb. Anzahlungen 1411 an Forderung Debitor 60304 (für ausstehenden Anzahlungsbetrag)
<?xml version="1.0" encoding="utf-8"?>
<LedgerImport xmlns="http://xml.datev.de/bedi/tps/ledger/v050" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xml.datev.de/bedi/tps/ledger/v050 Belegverwaltung_online_ledger_import_v050.xsd" version="5.0"
generator_info="xxx" generating_system="xxx" xml_data="Kopie nur zur Verbuchung berechtigt nicht zum Vorsteuerabzug">
<consolidate consolidatedAmount="59500.00" consolidatedDate="2020-09-16" consolidatedInvoiceId="20-100-0024-RE" consolidatedCurrencyCode="EUR">
<accountsReceivableLedger>
<date>2020-09-16</date>
<amount>59500.00</amount>
<accountNo>8000</accountNo>
<costCategoryId>100</costCategoryId>
<costCategoryId2>DATEVAZ</costCategoryId2>
<tax>19.00</tax>
<information>Schlussrechnungtext</information>
<currencyCode>EUR</currencyCode>
<invoiceId>20-100-0024-RE</invoiceId>
<bookingText>20-100-0024-RE R-wiko</bookingText>
<partyId>23424</partyId>
<vatId>DE219531833</vatId>
<exchangeRate>1.000000</exchangeRate >
<dueDate>2020-10-16</dueDate>
<bpAccountNo>60304</bpAccountNo>
<customerName>Matthias Brecht</customerName>
<customerCity>Freiburg</customerCity>
</accountsReceivableLedger>
<accountsReceivableLedger>
<date>2020-09-16</date>
<amount>1190.00</amount>
<accountNo>1711</accountNo>
<costCategoryId>100</costCategoryId>
<costCategoryId2>DATEVAZ</costCategoryId2>
<tax>19.00</tax>
<information>Schlussrechnungtext</information>
<currencyCode>EUR</currencyCode>
<invoiceId>20-100-0024-RE</invoiceId>
<bookingText>Abz. Anzahlung AZ.2020.1039</bookingText>
<partyId>23424</partyId>
<vatId>DE219531833</vatId>
<exchangeRate>1.000000</exchangeRate >
<dueDate>2020-10-16</dueDate>
<bpAccountNo>60304</bpAccountNo>
<customerName>Werner XX</customerName>
<customerCity>Freiburg</customerCity>
</accountsReceivableLedger>
<accountsReceivableLedger>
<date>2020-09-16</date>
<amount>595.00</amount>
<accountNo>1711</accountNo>
<costCategoryId>100</costCategoryId>
<costCategoryId2>DATEVAZ</costCategoryId2>
<tax>19.00</tax>
<information>Schlussrechnungtext</information>
<currencyCode>EUR</currencyCode>
<invoiceId>20-100-0024-RE</invoiceId>
<bookingText>AAbz. Anzahlung AZ.2020.1040</bookingText>
<partyId>23424</partyId>
<vatId>DE219531833</vatId>
<exchangeRate>1.000000</exchangeRate >
<dueDate>2020-10-16</dueDate>
<bpAccountNo>60304</bpAccountNo>
<customerName>Werner XX</customerName>
<customerCity>Freiburg</customerCity>
</accountsReceivableLedger>
<accountsReceivableLedger>
<date>2020-09-16</date>
<amount>595.00</amount>
<accountNo>1452</accountNo>
<costCategoryId>100</costCategoryId>
<costCategoryId2>DATEVAZ</costCategoryId2>
<tax>19.00</tax>
<information>Schlussrechnungtext</information>
<currencyCode>EUR</currencyCode>
<invoiceId>20-100-0024-RE</invoiceId>
<bookingText>Aufloesung offner AZ-Betraege AZ.2020.1040</bookingText>
<partyId>23424</partyId>
<vatId>DE219531833</vatId>
<exchangeRate>1.000000</exchangeRate >
<dueDate>2020-10-16</dueDate>
<bpAccountNo>60304</bpAccountNo>
<customerName>Werner XX</customerName>
<customerCity>Freiburg</customerCity>
</accountsReceivableLedger>
</consolidate>
</LedgerImport>
Ich muss dieses Thema wieder aktuell stellen.
Unser Mandant programmiert gerade eine eigene ERP-Software. Dabei unterstützen wir vorab, in dem wir den Import prüfen und auf mögliche Zusatzinformationen hinweisen.
Dabei haben wir dem Mandanten schon mitgeteilt, dass über den DATEV-Export die Informationen zum Anzahlungstool angegeben werden sollten, damit diese in KaReWe korrekt verarbeitet werden können. (vgl. Zeile 95 und 96 beim csv-Export - Erläuterungen im Developer Portal und Anzahlungs-Ratgeber).
Da nun eine direkte Schnittstelle, also nicht nur ein DATEV-Export, programmiert werden soll, haben wir an die DATEV-Schnittstellenberatung verwiesen.
Nun kam die Mitteilung, dass wohl die Angaben, die für die Buchung mit dem Anzahlungstool, nicht in die xml-Schnittstelle übernommen werden können (lt. Schnittstellenberatung).
Dies ist mir schleierhaft. In dem Dokument zur xml-Schnittstelle ist unter 7.1 erfasst, dass die Order-ID angegeben werden kann, wenn man das Anzahlungstool nutzt. Aber es fehlt die Information, ob es sich um eine Anzahlungs- oder Schlussrechnung handelt.
Ich kann es mir nur erklären, dass dies bisher in DATEV Unternehmen online bei Nutzung von Auftragswesen online wegen der fehlenden Möglichkeit der Erstellung von Anzahlungsrechnungen nicht in der Schnittstelle enthalten war. Allerdings kann man in Auftragswesen Next nun Anzahlungsrechnungen erstellen. Das bedeutet doch, dass die Zusatzinformaion zumindest aus Auftragswesen Next im xml enthalten sein müsste. Warum ist dies bei der allgemeinen xml-Schnittstelle nicht enthalten?
Auch in Bezug auf E-Rechnung etc. wäre diese Information sicherlich dienlich.
Habe ich hier etwas übersehen? Ist dies in Planung und kommt das noch? Es scheint mir hier, dass das Thema Anzahlungen hier noch in den Kinderschuhen steckt.