Hi,
As a follow-up of #10 I'd like to open a discussion about bundling value providers for the French CTC track.
The French e-invoicing ecosystem produces documents under a few CustomizationID families that validate against the fr.ctc:* VESIDs in phive-rules-france.
AIFE / Chorus Pro track
Used by Chorus Pro (B2G) and direct PA (formerly PDP) exchanges.
Extended-CTC-FR
| Syntax |
CustomizationID |
VESID |
ubl2-invoice |
urn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-fr |
fr.ctc:extended-ubl-invoice:latest |
ubl2-creditnote |
urn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-fr |
fr.ctc:extended-ubl-creditnote:latest |
cii (with <set id="SyntaxVersion">D22B</set>) |
urn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-fr |
fr.ctc:extended-cii:latest |
EN16931 CIUS
| Syntax |
CustomizationID |
VESID |
ubl2-invoice |
urn:cen.eu:en16931:2017 |
fr.ctc:ubl-invoice:latest |
ubl2-creditnote |
urn:cen.eu:en16931:2017 |
fr.ctc:ubl-creditnote:latest |
cii |
urn:cen.eu:en16931:2017 |
fr.ctc:cii:latest |
The AFNOR CIUS samples carry the bare urn:cen.eu:en16931:2017 CustomizationID, which isn't unique to French CTC — claiming it as fr.ctc:* would create false positives for plain EN 16931 documents from other jurisdictions.
CDAR
| Syntax |
CustomizationID |
VESID |
cdar (new) |
urn.cpro.gouv.fr:1p0:CDV:invoice |
fr.ctc:cdar:latest |
The CDAR root element (CrossDomainAcknowledgementAndResponse) isn't in the default syntax list today — would need a new cdar syntax.
Peppol codelist v9.6 entries 272–278 (POAC-France)
Worth bundling these alongside the AIFE entries, or kept out of scope?
I'm not sure whether the codelist's process identifiers are actually what shows up inside the business document. Using urn:peppol:france:billing:regulated (or :non-regulated) as BT-23 fails the FNFE-MPE Schematron rule BR-FR-08:
[BR-FR-08/BT-23] : La valeur du mode de facturation (ram:ID) n'est pas autorisée. Valeurs acceptées : B1, S1, M1, B2, S2, M2, B4, S4, M4, S5, S6, B7, S7. Valeur actuelle : urn:peppol:france:billing:regulated.
So BT-23 in the payload still has to be a cadre-de-facturation code — the codelist's :regulated / :non-regulated look more like SBDH/SMP routing identifiers than payload ProfileID values?
Sources
If you'd like I could share my current syntaxes / value-provider XMLs (the ones I merge with the defaults) if that's useful for context.
Hi,
As a follow-up of #10 I'd like to open a discussion about bundling value providers for the French CTC track.
The French e-invoicing ecosystem produces documents under a few CustomizationID families that validate against the
fr.ctc:*VESIDs in phive-rules-france.AIFE / Chorus Pro track
Used by Chorus Pro (B2G) and direct PA (formerly PDP) exchanges.
Extended-CTC-FR
ubl2-invoiceurn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-frfr.ctc:extended-ubl-invoice:latestubl2-creditnoteurn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-frfr.ctc:extended-ubl-creditnote:latestcii(with<set id="SyntaxVersion">D22B</set>)urn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-frfr.ctc:extended-cii:latestEN16931 CIUS
ubl2-invoiceurn:cen.eu:en16931:2017fr.ctc:ubl-invoice:latestubl2-creditnoteurn:cen.eu:en16931:2017fr.ctc:ubl-creditnote:latestciiurn:cen.eu:en16931:2017fr.ctc:cii:latestThe AFNOR CIUS samples carry the bare
urn:cen.eu:en16931:2017CustomizationID, which isn't unique to French CTC — claiming it asfr.ctc:*would create false positives for plain EN 16931 documents from other jurisdictions.CDAR
cdar(new)urn.cpro.gouv.fr:1p0:CDV:invoicefr.ctc:cdar:latestThe CDAR root element (
CrossDomainAcknowledgementAndResponse) isn't in the default syntax list today — would need a newcdarsyntax.Peppol codelist v9.6 entries 272–278 (POAC-France)
Worth bundling these alongside the AIFE entries, or kept out of scope?
I'm not sure whether the codelist's process identifiers are actually what shows up inside the business document. Using
urn:peppol:france:billing:regulated(or:non-regulated) as BT-23 fails the FNFE-MPE Schematron rule BR-FR-08:So BT-23 in the payload still has to be a cadre-de-facturation code — the codelist's
:regulated/:non-regulatedlook more like SBDH/SMP routing identifiers than payload ProfileID values?Sources
If you'd like I could share my current syntaxes / value-provider XMLs (the ones I merge with the defaults) if that's useful for context.