OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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

AdP Servicos

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.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]