Migration vers Odoo — lecteur DATEV-EXTF

migration_datev — Lecteur DATEV-EXTF (lot L5)

Lecteur du format DATEV-EXTF (CSV normé allemand, écosystème DATEV, Lexware et, en secours, toute comptabilité allemande/autrichienne susceptible d'exporter ce format), au-dessus du pipeline d'écriture de migration_account (lot L3) — dépendance, aucun fichier de migration_account ni de migration_base n'est modifié.

État : non éprouvé en production.

Pourquoi pas d'API DATEV

migration_spec.md § 4.5 est explicite : l'accès à DATEVconnect online (l'API REST du fournisseur) est réservé aux partenaires DATEV, avec une barrière d'au moins 25 clients de référence — disproportionné pour un connecteur de migration ponctuelle. Ce module ne porte donc aucun appel réseau : c'est un lecteur de fichier, point.

Ce qu'il lit, ce qu'il ne devine jamais

• Buchungsstapel (écritures) : une ligne = une écriture déjà complète et équilibrée (Konto contre Gegenkonto, même montant) — pas de regroupement multi-lignes comme le FEC français. Umsatz (montant à virgule), Soll/Haben-Kennzeichen (S débite Konto/crédite Gegenkonto, H l'inverse), Belegdatum (JJMM, sans année), Belegfeld 1 (identifiant externe s'il est renseigné), BU-Schlüssel (conservé, jamais utilisé pour recalculer une taxe).
• Debitoren/Kreditoren-Stammdaten (comptes de tiers) : Konto + toute colonne dont le nom commence par « Name » (entreprise ou personne physique), dédupliqué à la lecture.
• Colonnes lues par nom, jamais par position fixe (suffixe entre parenthèses ignoré : « Umsatz (ohne Soll/Haben-Kz) » = « Umsatz ») — un export avec des colonnes optionnelles absentes ou réordonnées reste lisible.
• Exercice comptable : le format ne porte jamais l'année sur Belegdatum. — voir le manifeste), mais fait toujours foi de migration.job.exercice_comptable_debut quand il est renseigné, et refuse clairement sinon — jamais une année devinée en silence.
• Comptes de tiers : le Buchungsstapel n'a pas de colonne équivalente à CompAuxNum (FEC) — le compte de tiers est le numéro de compte, dans une plage propre à chaque mandant. migration.job.datev_compte_tiers_de/ _a la rend explicite ; sans réglage, aucune ligne n'est rattachée à un tiers.
• SKR03/SKR04 : aucun mapping recréé — la résolution de compte de migration_account (recherche par code, exacte puis préfixe) suffit dès qu'Odoo porte le bon plan (l10n_de, natif SKR03 et SKR04). Le choix du plan doit être fait avant la première écriture, ce module ne le vérifie pas lui-même (aucun moyen de le déduire du fichier).

Utilisation

1. Installer migration_datev (dépend de migration_account).
2. Sur un job de migration (source « Fichier »), déposer le fichier Buchungsstapel sur le checkpoint « Écritures »/« Factures » et, si utile, le fichier Debitoren/Kreditoren sur « Comptes auxiliaires » — format « DATEV-EXTF » choisi explicitement sur chaque checkpoint (jamais deviné par extension).
3. Renseigner exercice_comptable_debut sur le job (obligatoire si l'en-tête du fichier ne peut pas être lu avec certitude).
4. Renseigner datev_compte_tiers_de/_a si les comptes de tiers doivent être rattachés automatiquement.
5. Table de correspondance des journaux (migration.journal.map) : toutes les écritures DATEV portent le code source constant « DATEV » — une seule ligne à compléter par job.

Tests

Voir tests/ : test_lecteur_datev.py (marqueur EXTF/DTVF, colonnes par nom, encodage CP-1252/UTF-8, Soll/Haben, montants à virgule, dates JJMM + exercice, comptes de tiers), test_migration_datev.py (équilibre, idempotence inter-jobs, rattachement des comptes de tiers, conservation du BU-Schlüssel).

Doctrine lite/premium

Ce module est le lite : lecteur de fichier, LGPL-3, gratuit. migration_datev_premium (OPL-1, non fait ici) porterait les lots multi-exercices, l'export Lexware et le rapprochement automatique

Licence LGPL-3 — gratuit — DYONYSOS