anskaffelser/ehf-postaward-g3

Specifications part of EHF Post-Award, 3rd generation.

EHF Post-Award (G3)

Please use Anskaffelser.dev for easy access to EHF resources and other related resources.

ehf-postaward-g3's Issues

EHF Advanced Ordering 3.0.1

Order Initiation

• Validator feiler når det brukes priser med desimaler og ikke bare heltall
  Order Change
• Syntax beskriver at "SequenceNumberID" på hodenivå, men validator krever det åpenbart (og det er naturlig at den er påkrevd i Order Change)
• Validator feiler når priser er inkludert; uten pris og med SequenceNumberID" på hodenivå så er det mulig å få OK i validator

EHF Advanced Ordering 3.0 - Order Response

Equinor whish to have optional possibility to use «OrderLine\Item\Description» in addition to «OrderLine\Item\Name».
The same wish will be sent to PEPPOL Order Response transaction 3.0 (T76)

Link to Schematron bundle missing on reminder page

Change of link and text in Implementation guideline EHF catalog 3.0- 3.10

https://anskaflen.dev/postaward/g3/spec/current/catalogue-3.0/guide/#_environment_social_responsibility_and_ecological
Broken link to old code list must be removed.
Snippets must be changed where codes from the new code list are used instead of from the old code list: "Example of labeling in an EHF Catalog message"
New code list: https://anskaflen.dev/postaward/g3/spec/current/codelist/PackagingMarkedLabelAccreditationCode/

Wrong configuration for validation of Order Change and Order Cancellation

Determine the UblVersion for ehf:forward-billing:3.0

In EHF3 certain document types uses Ubl version 2.1 and some document types uses 2.2 (e.g. Invoice and CreditNote in forward-billing:3.0). Therefore Ublversion must be identified using the document contents.

Since UblVersionId is not included in the document anymore, how can we determine/extract UblVersion ?

If not what is the alternative ?

EHF Forward Billing 3.0: Issues with examplefiles, Schematron/validation rules and UBL version

Hi,

Very nice to see this becoming its own, standalone format/specification!

We (Pagero) have had a look at this and have a few thoughts we´d like to raise...

No. 1: The example files (found here) contains some minor errors...

a. The /(Invoice|CreditNote)/cac:AccountingCustomerParty/cac:Party/cbc:Name is incorrectly placed, should be inside a cac:PartyName-segment. This error exists in all four testfiles.

b. In the CreditNote-examples, the xmlns-declaration incorrectly points to the Invoice-XSD: <CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"..., it should point to the CreditNote: <CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"....

c. In the CreditNote-examples, cbc:DueDate should not be included according to the UBL XSD.

No. 2: Is the "PEPPOL-EN16931-R007"-rule expected to be "relaxed" in the PEPPOL BIS Billing 3.0 spring release?

Jan André Mærøe at Digdir told us that you do not NOT plan to release any "EHF Forward Billing 3.0"-specific Schematron-rules and that we should use the underlying PEPPOL BIS/EHF Billing 3.0 Schematron-rules... But after running some tests in different validators it appears there actually are some discrepancies in regards to the validation rules used. It appears Difi/DigDirs online validator recognizes the format as it´s own, separate "EHF Forward Billing 3.0 (Profile 08)" and all four UNEDITED testfiles (i.e. including the XSD-errors mentioned above, which looks to us as if the XSD-validation isn´t correctly performed) pass the validation without errors, whereas we, in both Validex´ and Philip Helger´s validators, get a couple of errors when using the PEPPOL BIS Billing 3.0 specification, in addition to the XSD-errors mentioned above...

Ignoring two errors related to invalid GLN (warning) and Norwegian ORGNR (fatal) in the examplefiles, the following error is going to be problematic for us:

Flag: fatal
Rule id: PEPPOL-EN16931-R007
Message: Business process MUST be in the format 'urn:fdc:peppol.eu:2017:poacc:billing:NN:1.0' where NN indicates the process number.
Location: /(Invoice[1]|CreditNote[1])

If this and/or any other of the validation rules from the "regular" PEPPOL BIS/EHF Billing 3.0 are to be adjusted/deviated from, we would ask that you please publish, support and maintain separate Schematron-files for the format as a whole. Otherwise we would have to introduce a step where we manually have to adjust the PEPPOL BIS/EHF Billing 3.0 Schematron-files, and this is something we (and hopefully most other APs) would like to avoid.

No. 3: Lastly, we believe that the use of UBL 2.2 in the EHF Forward Billing 3.0 is contradictory since the underlying Peppol BIS/EHF Billing 3.0 uses UBL 2.1.

Hope you understand, let me know if anything is unclear or if you have any questions!

Looking forward to your reply!

Sebastian Boklund
Pagero Group

Update the environmental code list from GS1 to the latest version

At the request of Bergen municipality and Vieri AS, update the environmental code list from GS1 to the latest version: https://anskaflen.dev/postaward/g3/spec/current/codelist/PackagingMarkedLabelAccreditationCode/

Example files of 2020-03-23 release are incorrect

The following example files are invalid, because they have a double XML declaration:

• catalogue-3.0\Catalogue_Example.xml
• punch-out-3.0\PunchOut_Example.xml

Source: https://vefa.difi.no/ehf/g3/files/examples.zip

EHF eller PEPPOL BIS

I guidene som ligger som RC, så er tekstene ikke endret til å si at disse dokumentene er EHF og ikke PEPPOL BIS. Slik det ser ut nå, så har det kun vært lagt inn en beskrivelse øverst i dokumentet som sier at dette er en EHF. Resten av teksten i dokumentene ser ikke ut til å ha blitt endret, ei heller eksempler som viser PEPPOL CustomizationID for eksempel.

Enten bør EHF settes lik PEPPOL BIS, og referere kun til dokumentasjon som finnes på openPEPPOL (slik som for EHF Fakturering), eller så bør alle dokumenter renskrives slik at det reflekteres gjennom HELE dokumentet at det er en EHF, ikke en PEPPOL BIS. I dag finnes det f.eks følgende tekster:

• This chapter describes the principles and assumptions that underlie the use of PEPPOL Ordering
  *This PEPPOL BIS supports a process for suppliers to send a catalogue

National addition in environment, social responsibility and ecological label code list

As we agreed, DFØ ANS ABI has come to the conclusion that at present only a new code is needed as a national addition in: https://anskaflen.dev/postaward/g3/spec/current/syntax/catalogue-3.0/cac -CatalogueLine/cac-Item/cac-Certificate/cbc-CertificateTypeCode/ at the top of the code list: https://anskaflener.dev/postaward/g3/spec/current/codelist/PackagingMarkedLabelAccreditationCode/

National addition Code: Used
Definition: Used means that the item is not new, but used by at least one other owner/user before it is purchased

Text that refers to using N/A must be an mistake as we use the GS1 code list in the EHF catalogue today
"The UBL structure used for item labeling requires this elements, use the value NA."

For the EHF catalogue 3.0, this text must be rewritten so that it explains how to use the current code list (GS1 + national supplement).
We have sent in an issue for Peppol BIS with the same change request

Include is pointing to a reference that does not exist in EHF-REMINDER-3.0.sch

Hi,

I'm unable to transform SCH to XSL due to this issue

ehf-postaward-g3/rules/reminder-3.0/sch/EHF-REMINDER-3.0.sch

Line 24 in 07f5078

<include href="../../../target/generated/reminder-basic.sch"/>

BR,
Jussi

Doc update, UBL Credit Note ubl:CreditNote cac:PaymentMeans

Hei,
Ikke helt sikker på hvor dette burde rapporteres, men jeg vet dere vet :D

Det ser ut som om jeg har funnet en feil i dokumentasjonen. Per https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-creditnote/cac-PaymentMeans/ ser det ut som om en ubl:CreditNote -> cac:PaymentMeans kan ha 0..1 cbc:PaymentDueDate. Invoice dok'n https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-PaymentMeans/ har ikke cbc:PaymentDueDate.

Validatoren sier /cn:CreditNote[1], Test: not(cac:PaymentMeans/cbc:PaymentDueDate)

Adding support for ListValue in AdditionalItemProperty

We need support for ListValue elements in AdditionalItemProperty when using NameCode.

This is related to:

• Catalogue
• Punch Out
• Order Agreement
• Order Resposne

EHF Reminder 3.0

Need to add a new code "REM" to BR-CL-20.

Binding towards UBL 2.2 or 2.1?

The different documentation of EHF v3 documents have a mismatch in reference to UBL schema/namespace.

In chapter 2 the following text is found (my emphasis):
"Technical interoperability
Binding to OASIS UBL 2.1, see UBL 2.1"

In appendix A the following is found (my emphasis):
This implementation guide builds on UBL 2.2 Schemas, available from OASIS