Weâve had a similar challenge in Sweden as we have two domestic payment systems (Plusgiro and Bankgiro) and it is very common to let the customer choose which
one to use. The supplier therefore provides both options in the invoice. The EN still allows for repeatable/unbounded FinancialAccount though. To use multiple FinancialAccounts, based on the UBL syntax binding, you have to repeat the whole PaymentMeans, but
the elements (paymentMeansCode,PaymentID and so on) must be identical, only PayeeFinancialAccount may differ. So we worked around the limitation by using the same Payment Means code (credit transfer,30) and two repetitions. We use the Institution /ID to indicate
which system to use.
Like this:
<cac:PaymentMeans>
<!--Credit transfer (domestic)
-->
<cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
<!--Remittance information-->
<cbc:PaymentID>18003582</cbc:PaymentID>
<cac:PayeeFinancialAccount>
<cbc:ID>1112222</cbc:ID>
<!--Bankgiro account, 7 or 8 digits-->
<cac:FinancialInstitutionBranch>
<!--National clearing codefor Bankgiro-->
<cbc:ID>SE:BANKGIRO</cbc:ID>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
<!--Credit transfer (domestic)
-->
<cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
<!--Remittance information-->
<cbc:PaymentID>18003582</cbc:PaymentID>
<cac:PayeeFinancialAccount>
<cbc:ID>121212</cbc:ID>
<!--Plusgiro account, 2-8 digits-->
<cac:FinancialInstitutionBranch>
<!--National clearing codefor Plusgiro-->
<cbc:ID>SE:PLUSGIRO</cbc:ID>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
I donât know if such an approach would work for you though.
Best regards
Martin Forsberg
FrÃn: Kees Duvekot <kees@sipico.com>
Skickat: den 26 november 2019 11:48
Till: Andrea Caccia <andrea.caccia@studiocaccia.com>
Kopia: Pedro Fernandes <pedro.fernandes@adp.pt>;
ubl-dev@lists.oasis-open.org
Ãmne: Re: [ubl-dev] Implementation of EN 16931, CIUS and UBL
Andrea,
so you are not talking about a CIUS (which doesn't allow this kind of cardinality change) .. but creating an extension .. which follows the EU norm, but by definition is
not in line with the EU norm and therefor can not be mandated?
Hi Pedro,
EN 16931 is a semantic standard and defines a data model for core elements. It has designed to be minimal while UBL is designed to be as comprehensive
as possible.
The result of the standardization was the consensus reached on what should be considered "core".
The standard defines what is mandatory to implement for the European public authorities and an extension mechanism is defined exactly for the
purpose to extend the functionalities where needed where - of course - an extension cannot exceed what is possible to implement with the actual format you use, in this case UBL.
UBL set no limitations on the number of payment means so if you define an extension to cange the 0..1 cadrinality to 0..n it is feasible with
UBL.
The use of an extension is a matter of agreement between the parties involved in its use.
Here in Portugal we use debit cards a lot.
Almost every invoice has debit card payment instructions.
Sometimes, when there is a previous unpaid invoice, the invoice has the instructions to pay the current invoice and the instructions to pay all unpaid
invoices.
This is very common in Portugal specially in electricity and water invoices.
I donât understand why you consider multiple payment means an error, itâs predicted in UBL standard and, as you can see, there is use for it.
You are right, it would be more accurate to discuss it in an EN 16931 group.
I brought here since supposedly EN 16931 is a restriction to UBL.
Itâs hard to me to understand why someone would restrict something that was correctly predicted in UBL standard and now there is the need to âwork aroundâ.
Pedro Fernandes
DireÃÃo de Sistemas de InformaÃÃo
Rua Visconde de Seabra 3 | 1700-421 Lisboa | Tel: 212 469 549 (10549) | Fax: 212 469
541 | http://www.adp.pt
Tenha uma EcoAtitude. Imprima
este e-mail apenas se necessÃrio.
Esta mensagem e os ficheiros anexos podem conter informaÃÃo confidencial ou reservada. Se, por engano, receber esta mensagem, solicita-se que informe de imediato
o remetente e que elimine a mensagem e ficheiros anexos sem os reproduzir.
This message and any files herewith attached may contain confidential or privileged information. If you receive this message in error, please notify us immediately and
delete this message and any files attached without copying them in any way.
The European norm dictates that you only have no or at most one PaymentMeans in the Semantic model (NEN-EN 16931-1:2017+A1:2019 en Page 54: BG-16 and Req ID R58)
and in that same document it also describes what you can do in a CIUS with the cardinality. Extending it to allow N PaymentMeans is NOT allowed in a CIUS. (7.3.2 Allowed specification in CIUS)
so any national norm that allows for more then 1 PaymentMeans is no longer a norm that is inline with EU norm.
so it looks like the CIUS-PT "worked around" this problem to use the Note element to encode the additional PaymentMeans.
The bigger question is ... why would you like to insert multiple PaymentMeans in your invoice?
can you describe your use-case @Pedro Fernandes ?
Kees D.
p.s. I think the multiple PaymentMeans in the openPEPPOL specifications are an error. but we can ask them about that. in their documentation there is no mention of multiple PaymentMeans.
p.s.2 ... I like this discussion .. but it not 100% UBL related .. but an implementation related discussion .. but I would suggest to still keep it here for now. (unless somebody know a better location to discuss this on a open list)
I think I understand what 0..1 and 0..n means.
- 0..1 means 0 (zero) structures filled or 1 structure filled
- 0..n means 0 (zero) structures filled OR 1 structure filled OR several structures filled
I donât want to oblige payment means to be filled, itâs the opposite.
I want the possibility to fill several payment means, if needed, like it is predicted in the original standard.
Pedro Fernandes
DireÃÃo de Sistemas de InformaÃÃo
Rua Visconde de Seabra 3 | 1700-421 Lisboa | Tel: 212 469 549 (10549) | Fax: 212 469
541 | http://www.adp.pt
Tenha uma EcoAtitude. Imprima
este e-mail apenas se necessÃrio.
Esta mensagem e os ficheiros anexos podem conter informaÃÃo confidencial ou reservada. Se, por engano, receber esta mensagem, solicita-se que informe de imediato
o remetente e que elimine a mensagem e ficheiros anexos sem os reproduzir.
This message and any files herewith attached may contain confidential or privileged information. If you receive this message in error, please notify us immediately and
delete this message and any files attached without copying them in any way.
limitations in EN 16931-1 have been decided in CEN/TC 434 where the main goal was to identify the core elements for an eInvoice.
Allowing only one payment method was agreed there as the minimum that each European authority has to accept.
It is still possible at national level to implement an extension (allowing 0..n PaymentMeans) as this gives more freedom to the supplier that - if agrees - can insert
as many PaymentMeans as the extension allows but you cannot oblige a supplier to insert more than one (as this is what EN 16931 requires). TR 16931-5 specifies how to create extensions.
Where do you see that it should be 0..1? The UBL Invoice certainly allows for 0..n PaymentMeans elements. Only the Quotation, SelfBilledInvoice and the RemittanceAdvice documents
are restricted to 0..1 PaymentMeans.
The use of the Note that you describe certainly seems like bad practice. The Note is intended to contain textual information for people (not machines) to read. The reason why itâs
unbounded is to allow for the same textual content expressed in several languages.
I have been trying to implement EU norm EN 16931.
I saw that that EN 16931 changed cardinality of âcac:PaymentMeansâ from [0..*] to [0..1]
I donât understand why this was changed.
Each country has to make itâs own CIUS (Core Invoice Usage Specifications) based on EN 16931.
In Portugal there may be several âPaymentMeansâ.
Portuguese CIUS (CIUS-PT) instruct us to use several âcbc:Noteâ fields to add additional âPaymentMeansâ.
For second and next payment means are like this:
<cbc:Note>#ENTITY@ATMPAYMENT-001#12345#</cbc:Note> <!-- second payment mean -->
<cbc:Note>#REFERENCE@ATMPAYMENT-001#012345678#</cbc:Note> <!-- second payment mean -->
<cbc:Note>#DESCRIPTION@ATMPAYMENT-001#Valor total do documento, mais valores em atraso (extrato)#</cbc:Note> <!-- second payment mean -->
This doesnât make sense to me.
I really would appreciate some light on the matter.
Pedro Fernandes
DireÃÃo de Sistemas de InformaÃÃo
Rua Visconde de Seabra 3 | 1700-421 Lisboa | Tel: 212 469 549 (10549) | Fax: 212 469 541 | http://www.adp.pt
Tenha uma EcoAtitude. Imprima
este e-mail apenas se necessÃrio.
Esta mensagem e os ficheiros anexos podem conter informaÃÃo confidencial ou reservada. Se, por engano, receber esta mensagem, solicita-se que informe de imediato o remetente
e que elimine a mensagem e ficheiros anexos sem os reproduzir.
This message and any files herewith attached may contain confidential or privileged information. If you receive this message in error, please notify us immediately and delete this message and any files attached without copying them in any way.