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


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?

Kees D.

Op di 26 nov. 2019 om 11:40 schreef Andrea Caccia <andrea.caccia@studiocaccia.com>:
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.

Regards
Andrea

Il giorno 26 nov 2019, alle ore 10:59, Pedro Fernandes <pedro.fernandes@ADP.PT> ha scritto:

Hi Kees!
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â.
Â
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:ÂKees Duvekot [mailto:kees@sipico.com]Â
Sent:Â25 de novembro de 2019 21:13
To:Âubl-dev@lists.oasis-open.org; Pedro Fernandes <pedro.fernandes@ADP.PT>
Subject:ÂRe: FW: [ubl-dev] Implementation of EN 16931, CIUS and UBL
Â

Â

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
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.



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