diff --git a/guide/profile/codes/invoice-specific.adoc b/guide/profile/codes/invoice-specific.adoc index 33c5a555..34c2a0ee 100644 --- a/guide/profile/codes/invoice-specific.adoc +++ b/guide/profile/codes/invoice-specific.adoc @@ -63,6 +63,12 @@ include::../../syntax/codelists/inv-type.adoc[] | 380 | Invoice +|326 +|Partial invoice +|Document/message specifying details of an incomplete invoice. +| 380 +| Invoice + |331 |Commercial invoice which includes a packing list |Commercial transaction (invoice) will include a packing list. @@ -81,6 +87,12 @@ include::../../syntax/codelists/inv-type.adoc[] | 380 | Invoice +|384 +|Corrected invoice +|Commercial invoice that includes revised information differing from an earlier submission of the same invoice. +| 380 +| Invoice + |386 |Prepayment invoice |An invoice to pay amounts for goods and services in advance; these amounts will be subtracted from the final invoice. diff --git a/guide/release-notes/main.adoc b/guide/release-notes/main.adoc index b5a646f8..41d5e6cb 100644 --- a/guide/release-notes/main.adoc +++ b/guide/release-notes/main.adoc @@ -15,6 +15,8 @@ IMPORTANT: Changes in code lists are also reflected by changes in the validation :leveloffset: +1 +include::v3.0.16.adoc[] + include::v3.0.15.adoc[] include::v3.0.14.adoc[] diff --git a/guide/release-notes/v3.0.16.adoc b/guide/release-notes/v3.0.16.adoc new file mode 100644 index 00000000..a932c2c9 --- /dev/null +++ b/guide/release-notes/v3.0.16.adoc @@ -0,0 +1,20 @@ += Version 3.0.16 +[horizontal] +Release date:: 2023-11-01 + +== Changes to BIS document + +* A recommendation has been added to the Sales Order Reference element for handling cases where there is no Purchase Order Reference. This clarifies what to do with the mandatory UBL element for Purchase Order Reference. Example file is added which illustrates this. + +* Text in section 4.6 on negative invoices edited to remove historic comparison to BIS2 and justification for the change. No functional change. + +== Changes to code lists and validation artefacts + +* The validation rule identified as PEPPOL-EN16931-R006, which ensures that only one Invoice Object is allowed at the document level in an invoice/credit note, has been removed. This is because it duplicates the European standard rule UBL-SR-04, making it redundant and unnecessary. + +* The structure of the Peppol Schematron rule set has been improved for better quality. A function that was previously located in the Greek rules section is now correctly positioned alongside other functions. + +* Added invoice type codes 326 "Partial invoice" and 384 "Corrected invoice" as synonyms to code 380. + +== Changes to Country-Specific Rules + diff --git a/guide/transaction-spec/functionality/negative-invoices.adoc b/guide/transaction-spec/functionality/negative-invoices.adoc index 3a8caaf0..d6654323 100644 --- a/guide/transaction-spec/functionality/negative-invoices.adoc +++ b/guide/transaction-spec/functionality/negative-invoices.adoc @@ -2,21 +2,15 @@ = Negative invoices and credit notes -In line with requirements of {EN16931} this BIS supports negative grand totals. This represents a significant change in comparison to {openpeppol}’s previous specifications where invoices and credit notes have non-negative total. - -The argument for negative invoices is to open up for a wider spectrum of invoicing processes. +In line with requirements of {EN16931} this BIS supports negative grand totals in order to open up for a wider spectrum of invoicing processes. Examples of such processes are -* Preliminary (estimated) consumption invoice that is balanced out in a later meter-based invoice; -* Pre-payment (with or without VAT) is settled through a final invoice; and +* Preliminary (estimated) consumption invoice that is balanced out in a later meter-based invoice; +* Pre-payment (with or without VAT) is settled through a final invoice; and * Some user communities prefer to use negative invoice rather than credit note when correcting transactions. -==== -NOTE: Buyers who value automatic matching of e-invoices to orders or invoicing objects may wish to limit the areas and situations where complex transactions can be accepted and voice their requirements at time of procurement. -==== - -The decision has the following implications on the transaction format: +This has the following implications on the transaction format: * The invoice (now with “negative invoice capacity”) can function as an alternative to the credit note. Invoice-generating systems may implement either option, while invoice-receiving systems have to support both of them. * The transaction format for credit note has to be designed to accommodate for negative grand total, as well; this is because an entire negative invoice may have to be balanced out by means of a credit note. diff --git a/rules/examples/sales-order-example.xml b/rules/examples/sales-order-example.xml new file mode 100644 index 00000000..87f16242 --- /dev/null +++ b/rules/examples/sales-order-example.xml @@ -0,0 +1,214 @@ + + + urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 + urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 + Snippet1 + 2017-11-13 + 2017-12-01 + 380 + EUR + 4025:123:4343 + 0150abc + + NA + 123456 + + + + 9482348239847239874 + + 99887766 + + + SupplierTradingName Ltd. + + + Main street 1 + Postbox 123 + London + GB 123 EW + + GB + + + + GB1232434 + + VAT + + + + SupplierOfficialName Ltd + GB983294 + + + + + + FR23342 + + FR23342 + + + BuyerTradingName AS + + + Hovedgatan 32 + Po box 878 + Stockholm + 456 34 + + SE + + + + SE4598375937 + + VAT + + + + Buyer Official Name + 39937423947 + + + Lisa Johnson + 23434234 + lj@buyer.se + + + + + 2017-11-01 + + 9483759475923478 + + Delivery street 2 + Building 56 + Stockholm + 21234 + + SE + + + + + + Delivery party Name + + + + + 30 + Snippet1 + + IBAN32423940 + AccountName + + BIC324098 + + + + + Payment within 10 days, 2% discount + + + true + Insurance + 25 + + S + 25.0 + + VAT + + + + + 331.25 + + 1325 + 331.25 + + S + 25.0 + + VAT + + + + + + 1300 + 1325 + 1656.25 + 25 + 1656.25 + + + + 1 + 7 + 2800 + Konteringsstreng + + 123 + + + Description of item + item name + + 21382183120983 + + + NO + + + 09348023 + + + S + 25.0 + + VAT + + + + + 400 + + + + 2 + -3 + -1500 + + 123 + + + Description 2 + item name 2 + + 21382183120983 + + + NO + + + 09348023 + + + S + 25.0 + + VAT + + + + + 500 + + + diff --git a/rules/sch/PEPPOL-EN16931-CII.sch b/rules/sch/PEPPOL-EN16931-CII.sch index 3c855f7e..3908d952 100644 --- a/rules/sch/PEPPOL-EN16931-CII.sch +++ b/rules/sch/PEPPOL-EN16931-CII.sch @@ -533,7 +533,7 @@ Last update: 2022 May release 3.0.13. Invoice type code MUST be set according to the profile. diff --git a/rules/sch/PEPPOL-EN16931-UBL.sch b/rules/sch/PEPPOL-EN16931-UBL.sch index bef742f5..5834b279 100644 --- a/rules/sch/PEPPOL-EN16931-UBL.sch +++ b/rules/sch/PEPPOL-EN16931-UBL.sch @@ -178,6 +178,24 @@ Last update: 2023 May release 3.0.15. ((string-to-codepoints(substring($val,11,1)) - 48) * 19)) mod 89 = 0 "/> + + + + + + + + @@ -213,7 +231,6 @@ Last update: 2023 May release 3.0.15. Only one tax total with tax subtotals MUST be provided. Only one tax total without tax subtotals MUST be provided when tax currency code is provided. Invoice total VAT amount and Invoice total VAT amount in accounting currency MUST have the same operational sign - Only one invoiced object is allowed on document level VAT accounting currency code MUST be different from invoice currency code when provided. @@ -477,23 +494,7 @@ Last update: 2023 May release 3.0.15. - - - - - - - + @@ -509,7 +510,7 @@ Last update: 2023 May release 3.0.15. - + @@ -690,7 +691,7 @@ Last update: 2023 May release 3.0.15. Invoice type code MUST be set according to the profile. diff --git a/rules/unit-UBL-GR/GR_Validation_GRR001.xml b/rules/unit-UBL-GR/GR_Validation_GRR001.xml index 9456fcbd..30c200ee 100644 --- a/rules/unit-UBL-GR/GR_Validation_GRR001.xml +++ b/rules/unit-UBL-GR/GR_Validation_GRR001.xml @@ -362,7 +362,7 @@ xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"> - 061828591|11/11/2010|0|11.1|| + 061828591|11/11/2010|0|1.1|| 2010-11-11 diff --git a/rules/unit-UBL-PEPPOL/PEPPOL-EN16931-R006.xml b/rules/unit-UBL-PEPPOL/PEPPOL-EN16931-R006.xml deleted file mode 100644 index 2b08c332..00000000 --- a/rules/unit-UBL-PEPPOL/PEPPOL-EN16931-R006.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - Verify existence of not more than a single object identifier on document level - PEPPOL-EN16931-R006 - - - - PEPPOL-EN16931-R006 - - - - - DR35141 - 130 - - - - ts12345 - Technical specification - - - www.techspec.no - - - - - - - - - PEPPOL-EN16931-R006 - - - - - ts12345 - Technical specification - - - www.techspec.no - - - - - - - - - PEPPOL-EN16931-R006 - - - - - - - - - - - PEPPOL-EN16931-R006 - - - - - - 130 - - - - 130 - - - - - diff --git a/structure/codelist/UNCL1001-inv.xml b/structure/codelist/UNCL1001-inv.xml index b8b197de..8d0a7baa 100644 --- a/structure/codelist/UNCL1001-inv.xml +++ b/structure/codelist/UNCL1001-inv.xml @@ -56,6 +56,12 @@ Payment request for completed units A request for payment for completed units. + + + 326 + Partial invoice + Document/message specifying details of an incomplete invoice. + 331 @@ -85,7 +91,13 @@ relevant party. - + + + 384 + Corrected invoice + Commercial invoice that includes revised information differing from an earlier submission of the same invoice. + + 386 Prepayment invoice diff --git a/structure/syntax/ubl-creditnote.xml b/structure/syntax/ubl-creditnote.xml index 2cbd0178..c4f50351 100755 --- a/structure/syntax/ubl-creditnote.xml +++ b/structure/syntax/ubl-creditnote.xml @@ -208,7 +208,7 @@ cbc:ID Purchase order reference - An identifier of a referenced purchase order, issued by the Buyer.An invoice must have buyer reference (BT-10) or purchase order reference. + An identifier of a referenced purchase order, issued by the Buyer. An invoice must have buyer reference (BT-10) or purchase order reference. In cases where sales order reference is provided, but there's no purchase order reference, then use value "NA" as this element is mandatory in UBL Document Reference BT-13 PEPPOL-EN16931-R003 @@ -218,7 +218,7 @@ cbc:SalesOrderID Sales order reference - An identifier of a referenced sales order, issued by the Seller. + An identifier of a referenced Sales order, issued by the Seller. In cases where sales order reference is provided, but there's no purchase order reference, then set cac:OrderReference/cbc:ID to value "NA" as this element is mandatory in UBL. Document Reference BT-14 112233 diff --git a/structure/syntax/ubl-invoice.xml b/structure/syntax/ubl-invoice.xml index f95379b4..ac66bb1c 100755 --- a/structure/syntax/ubl-invoice.xml +++ b/structure/syntax/ubl-invoice.xml @@ -214,7 +214,7 @@ cbc:ID Purchase order reference - An identifier of a referenced purchase order, issued by the Buyer.An invoice must have buyer reference (BT-10) or purchase order reference. + An identifier of a referenced purchase order, issued by the Buyer. An invoice must have buyer reference (BT-10) or purchase order reference. In cases where sales order reference is provided, but there's no purchase order reference, then use value "NA" as this element is mandatory in UBL. Document Reference BT-13 PEPPOL-EN16931-R003 @@ -224,7 +224,7 @@ cbc:SalesOrderID Sales order reference - An identifier of a referenced sales order, issued by the Seller. + An identifier of a referenced sales order, issued by the Seller. In cases where sales order reference is provided, but there's no purchase order reference, then set cac:OrderReference/cbc:ID to value "NA" as this element is mandatory in UBL. Document Reference BT-14 112233