Re: FW: [ubl-dev] Implementation of EN 16931, CIUS and UBL

[Kees Duvekot <kees@sipico.com>]

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)

Van: Pedro Fernandes [mailto:pedro.fernandes@ADP.PT]
Verzonden: maandag 25 november 2019 11:09
Aan: Andrea Caccia <andrea.caccia@studiocaccia.com>
CC: ubl-dev@lists.oasis-open.org
Onderwerp: RE: [ubl-dev] Implementation of EN 16931, CIUS and UBL

Â

Hi Andrea!

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

Is this correct?

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.

Best regards

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.

Â

From: Andrea Caccia [mailto:andrea.caccia@studiocaccia.com]
Sent: 25 de novembro de 2019 04:45
To: Pedro Fernandes <pedro.fernandes@ADP.PT>
Cc: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Implementation of EN 16931, CIUS and UBL

Â

Hi Pedro,

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.

Â

Kind regards

Andrea

Â

Il giorno 22 nov 2019, alle ore 20:16, Kenneth Bengtsson <kbengtsson@efact.pe> ha scritto:

Â

Olà Pedro!

I just had a look at PEPPOLâs implementation, and they allow 0..n PaymentMeans: https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/tree/

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.

Atenciosamente,

Kenneth

Â

From: Pedro Fernandes <pedro.fernandes@ADP.PT>
Date: Friday, November 22, 2019 at 1:40 PM
To: "ubl-dev@lists.oasis-open.org" <ubl-dev@lists.oasis-open.org>
Subject: [ubl-dev] Implementation of EN 16931, CIUS and UBL

Â

Hi all!

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>#AMOUNT@ATMPAYMENT-001#3264.10#</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.

Best regards

Pedro Fernandes
DireÃÃo de Sistemas de InformaÃÃo

<image001.png>

Rua Visconde de Seabra 3 | 1700-421 Lisboa | Tel:Â212 469 549 (10549)Â| Fax:Â212 469 541Â| http://www.adp.pt

<image002.png>Â

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.

Â

Â