Tiers payeurs / affacturage (cas DGFiP n°8, BG-10)
Bridge ropi_fr_einvoicing_factoring — licence OPL-1 — 50,00 €.
Pourquoi
Sur les factures d'affacturage / cession de créance, l'émetteur doit déclarer un tiers payeur distinct : c'est le cas d'usage n°8 de la DGFiP (BG-10 Payee Party). Le socle Odoo 18.0 stock ne porte ni acc_holder_partner_id, ni is_factoring, ni payment_note sur res.partner.bank, ce qui bloque l'export UBL PayeeParty et CII 393/396 DL.
Comment le module corrige
- Ajoute sur
res.partner.bank:acc_holder_partner_id,is_factoring,payment_note. - Export UBL PayeeParty plat (BG-10) + CII / Factur-X (PayeeTradeParty, références 393/396 DL).
- Import PayeeParty (rebasculement lors de la réception d'un flux entrant PDP).
- Reprend les identifiants FR SIRET / TVA depuis
acc_holder_partner_id. pre_init_hook: bloque l'installation si les colonnes core existent déjà sur la tableres_partner_bank(branche18.0-cas8-factoring-payeedéployée).
Suivi upstream
- Issue Odoo : odoo/odoo#269315 — [18.0] account_edi_ubl_cii: Cas 8 factoring payee (BG-10)
- PR Odoo : odoo/odoo#269316 — commit
3092d39a9854(champs payee dansaccount_edi_ubl_ciiuniquement). - PR OCA OCA/l10n-france#782 et Akretion akretion/fr-einvoicing#6 — fermées. Stratégie : tout dans
odoo/odoo, pas de dépendanceaccount_edi_ubl_ciidans les modules tiers. - Branche interne :
18.0-cas8-factoring-payee(forkrpinset/odoo) ; bridge RoPi commiteba5126.
Migration avant désinstallation
Noms de champs identiques upstream / bridge (acc_holder_partner_id, is_factoring, payment_note) : désinstallation propre après upgrade core. Le pre_init_hook bloque de toute façon la réinstall si le core expose déjà les colonnes.
Install & test
- DB Docker de test :
fe_cas8/fe_cas8_ropi(init-fe-case-dbs.sh cas8). - Tests :
-u account_edi_ubl_cii --test-tags=/account_edi_payee. - Prix : 50,00 € OPL-1 — apps.odoo.com.
Cadre normatif
- EN 16931 — BG-10 Payee Party ; profils UBL 2.1 FR / CII D22B / Factur-X ZUGFeRD.
- Cas d'usage DGFiP n°8 (affacturage / tiers payeur).