I’m developing a Tryton module which using edocument_unece module and I’m working around allowances and charges. I looked at the UNCL5189 and UNCL7161 code lists added to edocument_unece in 8.0 (product.py) and I have a few questions and observations. I’d like to know whether they are intended or worth fixing.
What I understand of the design
product.template gets two fields, unece_allowance_charge_code (UNCL5189) and unece_special_service_code (UNCL7161), both visible only for services. The field names match the UNECE data elements.
Observations
Trailing spaces in UNCL7161 keys
Two-letter codes seem to be defined with a trailing space, e.g. ('AG ', ...), ('CB ', ...), ('DI ', ...), ('TX ', ...). If these values end up as-is in the UBL, they would not match the code list (EN 16931 rule BR-CL-20), since the code is CB, not CB .
No distinction between allowance and charge
EN 16931 / Peppol require allowance reason codes to be in UNCL5189 (BR-CL-19, and Peppol restricts it to a subset: 41, 42, 60, 62–68, 70, 71, 88, 95, 100, 102–105), and charge reason codes to be in UNCL7161 (BR-CL-20). The full UNCL5189 list is exposed, and it also contains charge codes (e.g. 80 Packing charge, 85 Warehousing charge, 101 Carbon footprint charge). So a user can select a code that is valid in EDIFACT but rejected by Peppol validation. Would it make sense to filter the selection to only keep codes supported by Peppol ?
UNCL7161: completeness
Some sequences have gaps (e.g. ADW, AEE), and the codes DAC and DAF–DAO (e.g. Assortment allowance, Dealer allowance, Multi-buy promotion) seem to be absent.I also wonder which directory version the list is meant to follow (EN 16931 refers to D.16B).
Labels (cosmetic)
Some labels differ from the D.16B names (e.g. AA “Advertising allowance” vs “Advertising”, AAC “Modification costs” vs “Technical modification”). It has no effect on validation, but it may matter if the lists are meant to mirror the official ones.
Questions
Is the goal to ship the full UN/EDIFACT lists, or the subsets used by EN 16931?
Is the allowance/charge distinction handled somewhere else (e.g. in the UBL template) ?
Would a patch (clean keys, missing codes, optional filtering/validation) be welcome ?
This is a copy/paste issue. I did not saw that some code had only 2 letters.
For me trying to replicate all the rules is time consuming for almost no benefit.
I think it is simpler to let the user responsible of the setup because if an invoice is rejected by PEPPOL rules, they can still fix it.
Trailing spaces: good to know. If some 8.0 databases already stored values like 'CB ', a migration may be needed to strip them.
Filtering: that makes sense. I agree that edocument_unece shouldn’t replicate Peppol rules but maybe an option in configuration to restrict selection fields option to only peppol supported ones would be nice.
Directory version: this is where I think a change is needed. The Peppol and EN 16931 validation rules expect the D.16B version of UNCL5189 and UNCL7161. If the lists come from D.98A, codes added since then can’t be selected at all, which is different from a misconfiguration the user could fix.
Labels: understood, following the UNECE labels makes sense for this module.
I also have a question besides e-invoicing with Peppol, which use cases do you have in mind for the codes that Peppol doesn’t support? For example, the full UNCL5189 list contains many codes for banking commissions and fees (letters of credit, etc.), and they don’t seem relevant for invoices. Is the goal to provide the full UNECE lists for other EDI formats, or to use them in other documents ?
PEPPOL claiming D16B code lists but there not. Even if codes on the PEPPOL page are correct some of them are not in the UNCL D16B.
I found D24A and D22B version in french einvoicing reform documentation and since french rfe use peppol network to communicate between different approved platform, peppol must a least support them so that why I guessed PEPPOL used these version
This is very strange because D.16B is also repeated in Peppol BIS Billing and Peppol BIS Billing
But of D.24A and D.22B are the actual superset used by PEPPOL so I guess we should update to those versions.
I think that if we see D16B on the PEPPOL site might be cause they reused their old documentation, added new codes and forgot to update the version number, idk.