291 lines
10 KiB
Markdown
291 lines
10 KiB
Markdown
### Vom Steuerberater.
|
||
|
||
Umsatzerlöse
|
||
|
||
- 8400 Erlöse 19% -> Steuerschlüssel 9
|
||
- 8300 Erlöse 7% -> Steuerschlüssel 8
|
||
- 8120 Steuerfreie Umsätze nach § 4 Nr. 1a UStG (Drittland) -> Steuerschlüssel = 11
|
||
- 8125 Steuerfreie innergemeinschaftliche Lieferungen nach § 4 Nr. 1b UStG (EU) -> Steuerschlüssel = 1
|
||
|
||
Provisionen (Unterscheidung in Shop, Payline und Wachstumsbonus)
|
||
|
||
- 4760 Verkaufsprovision (Shop + Wachstumsbonus)
|
||
o 19% -> Steuerschlüssel = 9
|
||
o Kleinunternehmer -> Steuerschlüssen = 50
|
||
o Reverse Charge -> Steuerschlüssel = 94
|
||
- 4764 (Payline)
|
||
o 19% -> Steuerschlüssel = 9
|
||
o Kleinunternehmer -> Steuerschlüssen = 50
|
||
o Reverse Charge -> Steuerschlüssel = 94
|
||
|
||
Relevante Felder/Spalten
|
||
|
||
- Umsatz (Spalte A) -> Bruttobetrag je Steuerschlüssel
|
||
- Soll/Haben (Spalte B)
|
||
o Umsatz -> H
|
||
o Provisionen -> S
|
||
- Konto (Spalte G)
|
||
o Umsätze -> siehe Umsatzerlöse
|
||
o Provisionen -> siehe Gutschriften
|
||
- Gegenkonto (Spalte H)
|
||
o Umsatzerlöse = Debitorenkonto (vermutlich Sammelkonto)
|
||
o Provisionen = Kreditorenkonto (vermutlich Sammelkonto)
|
||
- Buchungsschlüssel
|
||
o Steuerschlüssel siehe oben je Sachverhalt
|
||
- Belegdatum (Spalte J) = Rechnungs-/Gutschriftsdatum
|
||
- Belegfeld 1 (Spalte K)
|
||
o Umsatz = Rechnungsnummer
|
||
o Gutschrift = Gutschriftnummer
|
||
- Buchungstext (Spalte N)
|
||
o Umsatz = Name Kunde (Nachname Vorname)
|
||
o Provisionen = Name Kunde (Nachname Vorname)
|
||
- EU-Land u. UStID (Spalte AN)
|
||
o USt-ID
|
||
|
||
Gegenkonto Umsatz
|
||
|
||
- Payone -> Debitor (Mapping erforderlich)
|
||
- Paypal -> 1230
|
||
- Kunden -> vermutlich Sammeldebitor
|
||
|
||
Gegenbuchung Provisionen
|
||
|
||
- Kreditor 71586
|
||
- Vermutlich Sammelkreditor
|
||
|
||
Zu klären
|
||
|
||
- Kundennummer erforderlich?
|
||
- Kreditorennummer erforderlich?
|
||
|
||
Erläuterungen
|
||
|
||
1. Header
|
||
a. DATEV-Format - DATEV Developer Portal
|
||
2. Buchungsstapel
|
||
a. DATEV-Format - DATEV Developer Portal
|
||
|
||
### Erste Konzeption für ein DATEV-Export-Modul (EXTF „Buchungsstapel“) im Laravel-CRM – basierend auf dem Briefing des Steuerberaters und orientiert am DATEV Developer Portal (Header + Buchungsstapel). 
|
||
|
||
⸻
|
||
|
||
1. Zielbild: Was das Modul am Ende liefern muss
|
||
|
||
Output: pro Abrechnungsperiode (z. B. Monat) eine Datei EXTF_Buchungsstapel.csv mit 1. Header-Satz (erste Zeile, beginnt mit EXTF;700;21;...) 2. Spaltenkopfzeile (zweite Zeile) 3. Buchungszeilen (ab Zeile 3, je Buchung eine Zeile) 
|
||
|
||
Euer Beispiel/Template entspricht genau diesem Muster (Headerzeile + Spaltenkopfzeile + Daten).
|
||
|
||
⸻
|
||
|
||
2. Fachliche Logik (Mapping) – so entstehen Buchungszeilen
|
||
|
||
2.1 Buchungsarten (aus euren CRM-Daten ableitbar)
|
||
|
||
Ihr habt im System bereits: Bestellungen, Rechnungen, Gutschriften, Storno usw. Daraus leitet ihr je Datensatz eine „Buchungsart“ ab:
|
||
• Umsatz (Rechnung / Belastung)
|
||
• Soll/Haben: H
|
||
• Konto: Erlöskonto (8400/8300/8120/8125)
|
||
• Gegenkonto: Debitor/Zahlkonto (Payone/PayPal/Sammeldebitor)
|
||
• Provision (Gutschrift / Abzug) (Shop, Payline, Wachstumsbonus)
|
||
• Soll/Haben: S
|
||
• Konto: 4760 (Shop+Wachstumsbonus) oder 4764 (Payline)
|
||
• Gegenkonto: Kreditor (z. B. 71586 oder Sammelkreditor)
|
||
|
||
Wichtig: „Provision“ ist in eurem Export fachlich eine eigene Buchungslogik, auch wenn sie technisch über Gutschriften abgebildet ist.
|
||
|
||
2.2 Steuerschlüssel & Konten (1:1 aus dem Briefing)
|
||
|
||
Umsatzerlöse
|
||
• 8400 Erlöse 19% → Steuerschlüssel 9
|
||
• 8300 Erlöse 7% → Steuerschlüssel 8
|
||
• 8120 Drittland steuerfrei §4 Nr. 1a → Steuerschlüssel 11
|
||
• 8125 IG Lieferung steuerfrei §4 Nr. 1b → Steuerschlüssel 1
|
||
|
||
Provisionen
|
||
• 4760 Verkaufsprovision (Shop + Wachstumsbonus)
|
||
• 19% → 9
|
||
• Kleinunternehmer → 50
|
||
• Reverse Charge → 94
|
||
• 4764 (Payline)
|
||
• 19% → 9
|
||
• Kleinunternehmer → 50
|
||
• Reverse Charge → 94
|
||
|
||
2.3 Relevante DATEV-Spalten (aus Steuerberater-Vorgabe)
|
||
|
||
Ihr befüllt (mindestens) folgende Felder:
|
||
• Spalte A Umsatz: Bruttobetrag je Steuerschlüssel
|
||
• Spalte B Soll/Haben: Umsatz = H, Provisionen = S
|
||
• Spalte G Konto: wie oben
|
||
• Spalte H Gegenkonto: Debitor/Kreditor/Zahlkonto (Mapping)
|
||
• Buchungsschlüssel (BU-Schlüssel): Steuerschlüssel wie oben
|
||
• Belegdatum (Spalte J): Rechnungs-/Gutschriftsdatum
|
||
• Belegfeld 1 (Spalte K): Rechnungsnummer / Gutschriftsnummer
|
||
• Buchungstext (Spalte N): Name Kunde „Nachname Vorname“
|
||
• EU-Land u. UStID (Spalte AN): USt-ID (wenn vorhanden)
|
||
|
||
Die restlichen DATEV-Spalten bleiben leer (aber müssen als Trennzeichen „mitlaufen“, weil das Format feste Spaltenpositionen hat). 
|
||
|
||
⸻
|
||
|
||
3. Gegenkonto-Logik (entscheidet über Debitor/Zahlkonto)
|
||
|
||
Aus dem Briefing:
|
||
|
||
Gegenkonto Umsatz
|
||
• Payone → Debitor (Mapping erforderlich)
|
||
• PayPal → 1230
|
||
• Kunden → Sammeldebitor (vermutlich)
|
||
|
||
Gegenbuchung Provisionen
|
||
• Kreditor 71586 (oder Sammelkreditor)
|
||
|
||
Empfehlung (damit es skalierbar bleibt)
|
||
|
||
Baut das als Regelwerk + Mappingtabellen, nicht hardcodiert.
|
||
|
||
(A) payment_method_counteraccounts
|
||
• payment_method (payone, paypal, invoice, …)
|
||
• counteraccount_type (DEBITOR, GL_ACCOUNT)
|
||
• counteraccount_value (z. B. 1230)
|
||
|
||
(B) payone_debitor_mapping
|
||
• Schlüssel z. B. payone_account_id / merchant_id / settlement_reference
|
||
• Ziel: debitor_account_no
|
||
|
||
Fallback-Regeln 1. Wenn PayPal → 1230 2. Wenn Payone und Mapping gefunden → gemappter Debitor 3. Sonst → Sammeldebitor
|
||
|
||
⸻
|
||
|
||
4. „Zu klären“ (Kundennummer/Kreditorennummer) – pragmatische Konzeption ohne Blocker
|
||
|
||
Ihr könnt das so designen, dass beides optional ist, aber unterstützt wird:
|
||
|
||
Option 1: Sammelkonten (schnell, wenig Stammdatenpflege)
|
||
• Gegenkonto Umsatz: Sammeldebitor
|
||
• Gegenkonto Provision: Sammelkreditor/71586
|
||
• Vorteil: einfacher Start
|
||
• Nachteil: keine OP-Auswertung pro Kunde in DATEV
|
||
|
||
Option 2: echte Debitoren/Kreditoren (sauberer, mehr Pflege)
|
||
• Jeder Kunde bekommt Debitorennummer (und ggf. Kreditorennummer, wenn Provisionen individuell laufen sollen)
|
||
• Optional zusätzlich Export „Debitoren/Kreditoren“-Stammdaten in DATEV-Format (separater EXTF-Datensatztyp) 
|
||
|
||
Empfehlung für eure Roadmap
|
||
• Phase 1: Sammelkonten + Payone-Mapping + PayPal 1230
|
||
• Phase 2: Debitoren/Kreditoren optional (wenn Steuerberater OP-Listen braucht)
|
||
|
||
Ist geklärt. Option 1 Wird umgesetzt. Zusätzlich wird immer wie in Phase 1 noch das Payone-Mapping + PayPal 1230 etc angahangen.
|
||
|
||
⸻
|
||
|
||
5. Storno / Korrekturen / Gutschriften: robustes Regelwerk
|
||
|
||
Ihr wollt verhindern, dass „Storno“ doppelt wirkt oder als falsches Vorzeichen rausgeht.
|
||
|
||
Konzeptionell sauber:
|
||
• Jede exportierte Zeile bekommt eine interne Export-Signatur (z. B. source_type, source_id, line_hash) und wird als „exportiert“ protokolliert.
|
||
• Storno/Gutschrift wird als eigene Buchung exportiert (typischerweise Gegenbuchung zur Ursprungsbuchung), nicht als stilles Überschreiben.
|
||
|
||
DATEV-seitig gibt es Felder/Mechaniken für Umkehr/Korrektur; wie ihr das exakt nutzt (eigener Umkehrschlüssel vs. negativer Betrag) sollte ihr einmal mit dem Steuerberater festziehen, aber euer Modul kann beides abbilden:
|
||
• Variante A: negativer Umsatzbetrag in Spalte A
|
||
• Variante B: Umkehr-/Berichtigungsschlüssel befüllen (wenn gewünscht)
|
||
|
||
(Die DATEV-Doku zum Buchungsstapel beschreibt die Struktur/Spalten; die konkrete Kanzlei-Konvention ist oft Mandantenstandard.) 
|
||
|
||
⸻
|
||
|
||
6. Datenmodell in Laravel (minimal, aber vollständig)
|
||
|
||
6.1 Kern-Tabellen
|
||
|
||
datev_exports
|
||
• id, period_from, period_to, created_by
|
||
• status (draft/generated/downloaded/locked)
|
||
• berater_nr, mandant_nr (für Header)
|
||
• filename, file_path, hash
|
||
|
||
datev_export_lines
|
||
• export_id
|
||
• source_type (invoice/credit_note/cancellation/commission)
|
||
• source_id
|
||
• amount_gross
|
||
• soll_haben (H/S)
|
||
• konto
|
||
• gegenkonto
|
||
• bu_schluessel
|
||
• belegdatum
|
||
• belegfeld1
|
||
• buchungstext
|
||
• ustid, eu_land
|
||
• row_csv (optional: final gerenderte Zeile zur Nachvollziehbarkeit)
|
||
|
||
accounting_rules (konfigurierbar)
|
||
• für Umsatz: VAT-Case → (konto, bu)
|
||
• für Provision: scenario → (konto, bu)
|
||
|
||
counteraccount_mappings (Payone/PayPal/Default)
|
||
|
||
6.2 Warum „Export Lines“ speichern?
|
||
• Audit-Trail (Steuerberaterfragen)
|
||
• Re-Download exakt identisch
|
||
• Sperre gegen Doppel-Export derselben Quellen
|
||
|
||
⸻
|
||
|
||
7. UI/Workflow (CRM-Modul) 1. Periode wählen (Monat/Zeitraum) 2. Datenbasis anzeigen: Anzahl Rechnungen, Gutschriften, Stornos, Provisionen 3. Regel-Preview: gruppiert nach (Konto, Gegenkonto, Steuerschlüssel) + Summen 4. Validierungscheck (Blocking):
|
||
• fehlender Steuercase (z. B. EU ohne USt-ID aber als IG markiert)
|
||
• fehlendes Payone-Debitor-Mapping (falls Pflicht)
|
||
• fehlendes Belegdatum/Belegnr. 5. Export generieren → Datei + Protokoll 6. Lock (optional) → „Dieses Periodenset ist final“
|
||
|
||
⸻
|
||
|
||
8. CSV/Format-Generator (technische Konzeption, ohne Code)
|
||
• Semikolon als Delimiter
|
||
• Headerzeile gemäß DATEV-Vorgaben (Formatkategorie 21 = Buchungsstapel, Versionen etc.) 
|
||
• Danach Spaltenkopfzeile (fixe Reihenfolge)
|
||
• Dann Zeilen mit exakt derselben Spaltenanzahl (leere Felder als leer zwischen ;)
|
||
|
||
Praxis-Hinweis: Haltet Header-Felder (Berater-Nr, Mandant-Nr, Zeitraum) als Kanzlei-Konfiguration im CRM, damit ihr nicht pro Export „handwerkelt“. (Gerade diese Angaben sind beim Import relevant.) 
|
||
|
||
⸻
|
||
|
||
9. Konkrete Regel-Engine (so entscheidet ihr automatisch)
|
||
|
||
Umsatz-Fallunterscheidung
|
||
|
||
Input: invoice.vat_rate, invoice.destination_country, invoice.customer_vat_id, invoice.tax_exemption_reason
|
||
|
||
Mapping:
|
||
• vat_rate == 19% → (8400, bu=9)
|
||
• vat_rate == 7% → (8300, bu=8)
|
||
• Drittland steuerfrei → (8120, bu=11)
|
||
• EU IG Lieferung steuerfrei → (8125, bu=1)
|
||
|
||
Provision-Fallunterscheidung
|
||
|
||
Input: commission.type (shop/payline/bonus), supplier_tax_status (normal/KU/RC)
|
||
• type shop|bonus → konto 4760
|
||
• type payline → konto 4764
|
||
• tax_status normal → bu 9
|
||
• KU → bu 50
|
||
• RC → bu 94
|
||
|
||
⸻
|
||
|
||
10. Was ich aus eurer Beispieldatei ableite (für die Konzeption wichtig)
|
||
|
||
Eure Datei nutzt exakt das typische Muster:
|
||
• Zeile 1: EXTF;700;21;Buchungsstapel;...
|
||
• Zeile 2: Spaltenüberschriften (u. a. „Umsatz (ohne Soll/Haben-Kz)“, „Soll/Haben-Kennzeichen“, „Konto“, „Gegenkonto“, „BU-Schlüssel“, „Belegdatum“, …)
|
||
• Danach Datenzeilen mit vielen leeren Feldern (DATEV-typisch bei Minimalbefüllung)
|
||
|
||
Das bestätigt: Ihr braucht vor allem stabile Spaltenpositionen + korrektes Mapping, nicht „alle 116 Felder“. 
|
||
|
||
⸻
|
||
|
||
Wenn du willst, kann ich als nächsten Schritt (ohne extra Rückfragen) aus eurem Briefing ein konkretes Mapping-Dokument erstellen (als technische Spezifikation):
|
||
• Feld-zu-Quelle (CRM) je DATEV-Spalte
|
||
• Regelprioritäten (Fallbacks)
|
||
• Validierungsregeln + Fehlermeldungen (für UI)
|
||
• Testfälle (z. B. EU ohne USt-ID, Storno nach Periodenwechsel, Payone ohne Mapping, KU/RC-Provisionen)
|