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


I am honestly not sure about this, Kees. Martin commented earlier today that several PaymentMeans elements are permitted in EN16931, *as long as they use the same PaymentMeansCode*. Iâm looking at these schematron validation rules:

 

https://github.com/ConnectingEurope/eInvoicing-EN16931/tree/master/ubl/schematron

 

And I canât find any validation rule that prevents multiple PaymentMeans. Or perhaps I am looking in the wrong place?

 

In Martinâs example he provides two means of payment, a bank giro (UNCL4461 code 56) and something that could be a post giro (UNCL4461 code 50). Because he canât have two PaymentMeans elements with two /different/ payment means codes then he is instead including two PaymentMeans element with the same âwildcardâ payment means code (UNCL4461 code 30, transfer of funds).

 

Assuming (1) that EN16931 allows for several PaymentMeans as long as they use the same PaymentMeansCode and (2) that code 30 (or any other code for that matter) is generally accepted as a sort of generic catch-all code, then that would in Pedroâs case and just about anywhere else as well.

 

I am not qualified to weigh in on what could be different interpretations of EN16931 nor of the UN code list.

 

Regarding the UBL specific part of this thread, I do feel that it is important to discourage the use of UBL cbc:Note elements for structured information that has a proper designate place elsewhere in UBL, as was described in the initial comment.

 

 

 

From: "Duvekot, Kees" <kduvekot@Wehkamp.nl>
Date: Tuesday, November 26, 2019 at 8:29 AM
To: Kenneth Bengtsson <kbengtsson@efact.pe>, Martin Forsberg <martin.forsberg@ecru.se>, Pedro Fernandes <pedro.fernandes@ADP.PT>, "ubl-dev@lists.oasis-open.org" <ubl-dev@lists.oasis-open.org>
Subject: RE: [ubl-dev] Implementation of EN 16931, CIUS and UBL

 

Kenneth,

 

I think that the multiple PaymentMeans in PEPPOL are a mistake in the documentation of the syntax there. There is no mention of that in the documentation also. And it will fail the schematron validation for the published EU Norm .. so it will never pass the validation on the access points.

 

Kees D.

 

Van: Kenneth Bengtsson [mailto:kbengtsson@efact.pe]
Verzonden: dinsdag 26 november 2019 13:36
Aan: Martin Forsberg <martin.forsberg@ecru.se>; Pedro Fernandes <pedro.fernandes@ADP.PT>; ubl-dev@lists.oasis-open.org
Onderwerp: Re: [ubl-dev] Implementation of EN 16931, CIUS and UBL

 

Martin, could you then also clarify:

 

The PEPPOL CIUS claims to be EN16931 compliant. EN16931 does not allow multiple PaymentMeans, except (as I understand Andreaâs comment) through the use of an extension. The PEPPOL CIUS allows multiple PaymentMeans. How is this possible if not by using an extension?

 

/Kenneth

 

 

 

From: Martin Forsberg <martin.forsberg@ecru.se>
Date: Tuesday, November 26, 2019 at 7:27 AM
To: Kenneth Bengtsson <kbengtsson@efact.pe>, Pedro Fernandes <pedro.fernandes@ADP.PT>, "ubl-dev@lists.oasis-open.org" <ubl-dev@lists.oasis-open.org>
Subject: SV: [ubl-dev] Implementation of EN 16931, CIUS and UBL

 

Short clarification â Sweden is using the PEPPOL CIUS (BIS Billing 3). Our use of payment means is not an extension.

 

/Martin

 

FrÃn: Kenneth Bengtsson <kbengtsson@efact.pe>
Skickat: den 26 november 2019 13:21
Till: Pedro Fernandes <pedro.fernandes@ADP.PT>; ubl-dev@lists.oasis-open.org
Ãmne: Re: [ubl-dev] Implementation of EN 16931, CIUS and UBL

 

And until then, could the CIUS-PT not use an extension as in the examples from Sweden and PEPPOL?

 

@Pedro, I think it would be very important to direct the Portuguese authority to this thread so as to avoid making the mistake with the Note elements that your showed. There is also a (draft, yet close to finished) UBL Committee Note providing guidance on the use of the PaymentMeans structure: https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cnprd01/UBL-Payment-v1.0-cnprd01.html

 

/Kenneth

 

 

 

From: Pedro Fernandes <pedro.fernandes@ADP.PT>
Date: Tuesday, November 26, 2019 at 7:05 AM
To: "ubl-dev@lists.oasis-open.org" <ubl-dev@lists.oasis-open.org>
Subject: RE: [ubl-dev] Implementation of EN 16931, CIUS and UBL

 

That would be a great thing!

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: Kees Duvekot [mailto:kees@sipico.com]
Sent: 26 de novembro de 2019 11:51
To: Martin Forsberg <martin.forsberg@ecru.se>; ubl-dev@lists.oasis-open.org
Cc: Andrea Caccia <andrea.caccia@studiocaccia.com>; Pedro Fernandes <pedro.fernandes@ADP.PT>
Subject: Re: [ubl-dev] Implementation of EN 16931, CIUS and UBL

 

So .... Based on all this ... I think it might be good to ask for a repeatable paymentmeans in the EU norm?

 

On Tue, Nov 26, 2019, 12:44 Martin Forsberg <martin.forsberg@ecru.se> wrote:

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?

 

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]