UBL Ketentest versus UBL SI aandachtspunten

UBL Ketentest – versus UBL SI aandachtspunten Bijgewerkt: 14 april 2016 Dit document bevat aandachtspunten met betrekking tot UBL-SI die onder andere zijn ingebracht door deelnemers aan de UBL Ketentest. Waar mogelijk is per aandachtspunt informatie over de toepasbaarheid opgenomen. Punt F1

Omschrijving OPEN Functionele aandachtspunten Op welke wijze valideert UBL-SI de BTWberekening per regel en per factuur en hoe wordt geadviseerd om te gaan met eventuele daarbij optredende afrondingsverschillen?

Impact HOOG

F6

Welke afspraken gelden er binnen UBL-SI voor opname van BTW-nummer van de ontvanger als dit bekend is?

MIDDEL

www.ublketentest.nl



Toepasbaarheid Antwoord SI: Lastige vraag die ik goed uit moet zoeken. Wordt vervolgd Probleem komt voort uit een fout in de gebruikte XSLT artefacts. Upgrade naar XSLT2 is nodig voor Testtool. Wordt ingepland Q1 2016. 1. Voor nu is het zaak deze handmatig te valideren als deze error optreedt. 2. We gaan de testtool updaten met een nieuwe versie die om kan gaan met afrondingsverschillen. Dit vereist een rewrite van alle validatie artefacts. We zijn daar bijna mee klaar en zijn de testtool aan het testen. Tenslotte: de berekeningen moeten als volgt kloppen: TaxAmount moet overeenkomen met de som van TaxSubTotal\TaxAmount TaxSubTotal\TaxAmount moet gelijk zijn aan het TaxableAmount x TaxCategory\Percent LegalMonetaryTotal/LineExtensionAmount moet overeenkomen met de LineExtensionAmounts op factuurregelniveau (ex BTW) LegalMonetaryTotal /TaxInclusiveAmount moet gelijk zijn aan LegalMonetaryTotal /TaxIexclusiveAmount + TaxAmount Antwoord SI: Hoewel niet fiscaal vereist (volgens mij) is of het BTW of het KVK nummer van de ontvanger verplicht in doc:Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyIdentification/cbc:ID of doc:Invoice/cac:BuyerCustomerParty/cac:Party/cac:PartyIdentification/cbc:ID Opmerking Gerard: de vraag is maar of BTW- en KvK-nummer van een ontvanger bekend is. BTW-nummer mogelijk als buitenlandse partij, t.b.v. ICP-transactie. Leidt tot een signaal tijdens de UBL-SI validatie als ontbreekt. Opmerking Jaap Jan: Dat klopt. Binnen SI-FULL is BTW of KVK van de ontvanger wel









1

UBL Ketentest – versus UBL SI aandachtspunten Punt Omschrijving

Impact

F8

Het veld cac:Delivery/cbc:ID is binnen UBL standaard aanwezig voor pakbonnummer. Klopt het dat dit veld niet gebruikt wordt binnen UBl-SI? Het veld aanleveren levert een warning op.

F10

Wat is de juiste codering voor de BTWHOOG codes? Het gaat om een compleet overzicht van alle BTW-regelingen.

F11

Totaaltelling van de factuurregels wijkt af HOOG van de factuurtotalen (door korting die niet in UBL zit). Wordt niet gemeld door de validatie. Is binnen UBL een voorziening voor de “G”- HOOG rekening bij de Paymentmeans?

F12

LAAG

F13

Welke UBL-codering is precies van toepassing voor volgende Paymentmeans: - Per kas betaald - Automatische incasso - Factuur nog betalen

LAAG

F14

Voorstel bij validatietool onderscheid te maken tussen ‘warnings’ en ‘extra

MIDDEL

www.ublketentest.nl



Toepasbaarheid verplicht (of in het geval van een overheid een OIN). Omdat dit niet altijd opgaat voor SILITE is het een warning. Antwoord SI: De warning komt voort uit het feit dat een ontvangende ERP systeem de pakbonnummer mogelijk niet kan verwerken binnen SI. Verwijzingen vanuit de factuur naar andere document gebeurt door middel van het veld doc:Invoice/cac:AdditionalDocumentReference/cbc:DocumentType Voor nu is het opnemen van een pakbon referentie op Delivery niveau niet ondersteund. Wel in PC434 voorzien, dus met de nieuwe SI-UBL komt deze ook mee. Binnen SI is dit niet strak vastgelegd. Praktijk is dat participanten het volgende gebruiken: TaxCategory wordt over het algemeen niet strict gehanteerd. We zien waardes als "1" en "AA" door elkaar gebruikt. Het veld "Percent" is wel altijd opgenomen en moet de actuele percentage weergeven. Validatie tool wordt op dit moment aangepast om betere validaties uit te voeren. Zijn in laatste test fase bezig.

Zie mail 23-6-2015: Binnen GS1 is hiervoor het blok PaymentOnBlockedAccount opgenomen. Antwoord SI: uitvragen binnen SI-groep hoe dit is opgelost. JJ: Is op dit moment niet ondersteunt in SI. Zie mail 23-6-2015 Factuur nog betalen lijkt me de standaard situatie conform Referentiefactuur Ketentest. JJ: Per kas betaald: 10 Automatische incasso: 49 Factuur nog betalen: 30 Nu hebben sommige leveranciers de neiging extra elementen weg te halen omdat ze een warning geven, terwijl deze juist reuze handig kunnen zijn.









2

UBL Ketentest – versus UBL SI aandachtspunten Punt Omschrijving elementen’.

Impact

F15

Zijn subtotals mogelijk bij een UBL factuur?

LAAG

F16

Validatie UBL 2.0 / SI 1.0 blijkt zeer globaal, waardoor foutieve UBL-facturen wel door de validatie heen komen, maar soms niet verwerkt kunnen worden in de Ketentest. Zelfs als LineExtensionAmount niet juist is meldt de validatie dit niet altijd. Verlegde BTW is niet uitgewerkt binnen SI. Wordt wel gebruikt door de markt.

ZEER HOOG

Code “ZZZ” bij Reason code Allowance/Charge geeft bij SI 1.1 een warning sinds november 2015 (hiervoor niet)

MIDDEL

F17

F18

www.ublketentest.nl



HOOG

Toepasbaarheid JJ: Velden die nodig zijn kunnen worden ingebracht in SI-UBL, en zullen worden beoordeeld. 30-8-2015 Nu tweemaal gevraagd. Denk het niet. Voor zekerheid even navragen bij SI. Wat voor subtotals worden hier bedoeld? Meer subtotals op line niveau? Is idd niet ondersteund. Gemeld bij SI, geen actie ondernomen/niet teruggekoppeld SI: Bekend issue met de validatietool versie 1.0. JJN: Wordt gefixed. Voorstel vanuit UBL Ketentest: Conform codering UN/ECE 5305 TaxCategory = “AE”; VAT Reverse Charge. Code specifying that the standard VAT rate is levied from the invoicee. TaxExemptionReason = “Reverse charge” of “btw verlegd”. BTW en BTW-percentages op de factuur zijn “0” (of ontbreken). Let op dat hiernaast de BTW-nummers van zowel leverancier als afnemer vermeld moet worden! JJ: TaxCategory = "E" TaxExemptionReason = “Reverse charge” of “btw verlegd”. Volgens mij is TaxCategory "AE" niet officieel. Ik kom er niet achter of die nu in de laatste versie van de codelist staat. We gebruiken in ieder geval de CEN CWA codelist. Is idd geen officiele standaard. Mail gezonden aan SI. Melding is “Warning: [CL-T10-R010]-Coded allowance and charge reasons SHOULD belong to the UNCL 4465 code list BII2 subset”. Dat terwijl “ZZZ” wel in de lijst staat, zie http://www.unece.org/trade/untdid/d95a/uncl/uncl4465.htm Wij gebruiken een BII2 subset van die lijst waarin ZZZ niet is opgenomen.









3

UBL Ketentest – versus UBL SI aandachtspunten Punt Omschrijving

Impact

F19

Voor de UBL-RGS pilot is gebruik gemaakt van AccountingCostCode, standaard element binnen UBL, maar niet in SI. Nodig als RGS gebruikt wordt binnen UBL.

MIDDEL

D1

Documentatie UBL-SI Is er een beschrijving met de impact van de overgang van UBL-SI v1.0 naar v1.1? Mede n.a.v. Schematron report: Warning: [SI-UBL-INV-R000]Simplerinvoicing v1.0 validation is used but will soon be obsolete, please move to Simplerinvoicing v1.1.

HOOG

D2.1 In de Excel staat bovenaan “Use the GS1 specifications for the calculations of the amounts”. D3

D4

MIDDEL

Er is een Excel met foutcodes van de MIDDEL validatie. Deze codes hebben betrekking op SI 1.0. Is er een nieuwe gebaseerd op SI 1.1 Is er een functionele beschrijving van de MIDDEL controles die via de Schematron (kijkt naar data en afhankelijkheden) uitgevoerd worden?

www.ublketentest.nl



Toepasbaarheid We kunnen dus niet garanderen dat de ontvanger snapt hoe hiermee om te gaan. Toelichting: [RGS code]. Wel is AccountingCost aanwezig als variabel veld, maar dan kan “RGS” en versie niet aangeduid worden. Al gemeld bij SI. Is van belang als officieel besloten wordt RGS te gebruiken binnen UBL (SI). SI: Binnen SI is voorstel voor wijziging opgenomen. Antwoord SI: Heb ik los in de mail gezet. Gerard: Alleen concept release note “Changes in Implementation Guidelines vs 1.1 vs 1.0” ontvangen. De warning “v1.0 validation is used but will soon be obsolete” verschijnt, echter zonder datum en migratiedocs. JJN: Release notes zijn gestuurd via email. Staan ook online. Ik ga ervan uit dat dit afgehandeld is Er is geen directe verwijzing naar de calculations. JJN: correct. Opmerking zal verwijderd worden uit de XLS. JJN: Er is geen nieuwe gebasseerd op 1.1. Staat wel op onze verlanglijst. JJN: Nee helaas niet. Staat wel op verlanglijst.











4

UBL Ketentest – versus UBL SI aandachtspunten Punt Omschrijving D5 Zijn er voorbeeldsets vanuit SI (1.0 / 1.1), dus UBL bijbehorende PDF’s? Zo kan ook eenvoudig verschil tussen 1.0 en 1.1 bestudeerd worden.

Impact HOOG (zelf opgepakt)

D6

De overgang van UBL 2.0 naar UBL 2.1 kent slechts 7 nieuwe velden, zoals DueDate. De overgang van SI 1.0 naar 1.1 kent 74 nieuwe elementen en 30 vervallen elementen. Graag voorbeelden UBL+PDF waarin dit is uitgewerkt. D6.2 SI 1.1 kent t.o.v. 1.0 30 vervallen elementen

D7

D8

D9 D10

MIDDEL

Toepasbaarheid Antwoord SI: 5 UBL-bestanden gebaseerd op SI 1.1. Geen PDF beschikbaar. Gerard: wellicht voorbeelden UBL 2.0 | UBL 2.0+SI 1.0 | UBL 2.1 | UBL 2.1+SI 1.1 (ook header elementen en namespaces die dan gelden). JJN: Wij werken niet met UBL voorbeelden in onze artefacts. We werken wel aan een module die UBL omzet in PDF, geintegreerd met de UBL Validator (zodat je naast een validatie rapport de PDF factuur terugkrijgt) maar deze is nog in een te beta fase. Er is geen set aan voorbeelden waarin de verschillen 1.0 vs 1.1 is uitgewerkt. Er is wel een set van voorbeelden voor 1.1 (https://github.com/SimplerInvoicing/testset/tree/master/SI-UBL-1.1)

Reden waarom deze elementen nu ontbreken zijn niet beschreven. JJ: We hebben hierin de EU standaard (PEPPOL) overgenomen. Deze 30 elementen zijn niet beschreven waarom ze zijn verwijderd. Deze elementen werden in SI overigens ook niet gebruikt, dus bij SI had dit geen impact. Is er vanuit SI documentatie voorhanden HOOG De praktijk leert dat enkele leveranciers die al langer geleden UBL ingebouwd hebben over impact c.q. verschillen UBL-OHNL. (extern (en het nu weer oppakken) zich gebaseerd hebben op UBL-OHNL. Er wordt dan ook opgepakt) verwezen naar een namespace via nltaxonomie die niet bestaat. Het is lastig uitleggen dat geadviseerd wordt UBL-SI te hanteren. Voor dit laatste is geen goed verhaal. Dat laatste ligt trouwens geenszins aan SI. JJ: NL Taxonomie zal op den duur worden uitgefasseerd. Binnen UBL-SI zijn elementen verwerkt MIDDEL Er zijn nogal wat leveranciers die wel de UBL-SI gebruiken maar (althans voorlopig) niets m.b.t. ‘Open Peppol’. Is duidelijk welke dit met Peppol doen. Documentatie bij wel/geen peppol gebruik is dan handig. zijn en waarvoor ze gebruikt worden. SI: De UBL file voor beide is gelijk. OrderReference en BillingReference qua LAAG SI: Wordt gecorrigeerd in volgende versie. volgorde verkeerd om in SI Excelsheet Creditnota SI 1.0 werkt anders dan SI 1.1 HOOG SI: Is change op validatietooling met bovengemiddelde impact.

www.ublketentest.nl



LAAG











5

UBL Ketentest – versus UBL SI aandachtspunten Punt Omschrijving Payment Amount. Zie doc. Gerard over creditnota. Even duiden in validatie. Procedureel P2 RFC’s openbaar maken.

Impact

HOOG

P3

Procedure RFC’s afstemmen

HOOG

F2

GEREED Op welke wijze valideert UBL-SI de InvoiceTypeCode (380 of 381)?

GEREED

F3

Hoe wordt geadviseerd om te gaan met

GEREED

www.ublketentest.nl



Toepasbaarheid JJ: Change op validator. Wordt meegenomen met volgende release vand e validator. Gerard: Binnen SI wordt gewerkt met RFC’s. Dat is natuurlijk een prima zaak, mede in relatie tot versiebeheer. Ik mis alleen een compleet overzicht van RFC’s met besluitvorming en consequenties. Mijn advies is om RFC’s openbaar te maken. Dan weet iedereen wat er speelt en worden dubbele onderwerpen voorkomen. SI: Vanaf volgend jaar zal nieuwe tool beschikbaar komen voor SI specificaties, open voor de markt, incl RFC's. Gerard: Vanuit de UBL Ketentest is de voorkeur uitgesproken voor UBL-SI als standaard. Het zou daarom goed zijn als de deelnemers aan de UBL Ketentest wat meer op de hoogte zijn van het beheer rondom UBI-SI. Zoals: ”Is er een helpdesk voor functionele/technische vragen? Hoe verloopt de RFC procedure? Eigenlijk is dit punt in de praktijk geboren door de praktijk van de UBL Ketentest. JJ: We gaan een support desk inrichten als stichting met een online community tool. Verwachtte datum van oplevering is eind april. Tot die tijd kunnen vragen aan [email protected] worden gestelt. De support desk functie zal overigens wel onderdeel zijn van een betaalde membership. Anders betalen de SI members voor support aan non-members. Zie hiervoor ook de invlechting van Ketentest in SI. Antwoord SI: De Invoicetypecode moet 380 of 384 zijn. 381 is binnen SI nog niet toegestaan. UN/EDIFACT: “384: Corrected invoice Commercial invoice that includes revised information differing from an earlier submission of the same invoice”. UN/EDIFACT: “381: Credit note Document/message for providing credit information to the relevant party”. Antwoord SI: Deze staat op de roadmap. Ik heb besloten deze in te brengen in het









6

UBL Ketentest – versus UBL SI aandachtspunten Punt Omschrijving een creditnota? Mede in relatie met InvoiceTypeCode (380 en 381).

F4

F5

F7

F9

F20

F21 5-216

Impact

Is Simplerinvoicing v1.0 gebaseerd op UBL GEREED 2.0 en is Simplerinvoicing v1.1 gebaseerd op UBL 2.1.? Welke afspraken gelden er binnen UBL-SI GEREED voor opname van KvK-nummer afzender als dit bekend is? Toelichting: BTW-nummer is wettelijk verplicht te melden op een factuur, uiteraard voor zover bekend (niet elke organisatie heeft een KvK-nr). Hoe wordt geadviseerd om te gaan met GEREED factuurregels zonder bedragen? De voorbeeld invoice bestanden van OASIS GEREED geven errors (2.0 slechts 1 en 2.1 meerdere) als deze door de UBL-SI validatie gehaald worden. Is hier een verklaring voor te geven? XSD en CurrencyID, unitCode GEREED

Als bij een adres (supplier of customer) een GEREED postbus is dan wordt de straat niet ingevuld. Dat leidt tot een warning. Postbus is feitelijk i.p.v. straat en zou dus geen warning moeten opleveren.

www.ublketentest.nl



Toepasbaarheid Change Advisory Board als extra document type. Bij BDO zijn we helaas niet veel wijzer geworden omdat de agenda gevuld was met een aantal andere zaken. Echter obv andere discussies heb ik wel een suggestie voor een oplossing. Gerard: waarom niet zelfde oplossing als NES en België? Antwoord SI: Ja, dit is correct.

Antwoord SI: BTW nummer supplier is verplicht. Deze staat in doc:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID KVK nummer van de supplier is ook verplicht (indien aanwezig). Deze staat in doc:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID Overigens kan in deze laatste ook een andere company identification staan, zoals OIN oid, dus er wordt niet afgedwongen dat dat daadwerkelijk een KVK is. Antwoord SI: Het Price element moet aanwezig zijn op een factuur. Bedragen moeten dan worden ingevuld als 0,00. Advies UBL-KT: Dergelijke regels weglaten uit UBL-factuur. JJN: UBL is redelijk vrijblijvend en bij UBL-SI is dit aangescherpt.

In het bestand: \xsd\common\UBL-UnqualifiedDataTypes-2.1.xsd: Volgende attributen veranderd van ‘use=required’ naar ‘use=optional’ > CurrencyID > unitCode. Gevraagd aan SI of dit de bedoeling is. Validaties kloppen in XSD. Melding opgelost. (Op basis van factuur 001100526480 Canon) Warning: [SI-UBL-INV-R423]-A supplier postal address in an invoice SHOULD contain at least, Street name and number, city name, zip code and country code. Warning: [SI-UBL-INV-R424]-A customer postal address in an invoice SHOULD contain at least, Street name and number, city name, zip code and country code. Kortgesloten met SI: Richtlijn belastingdienst is dat adres altijd moet voorkomen en postbus (zonder









7

UBL Ketentest – versus UBL SI aandachtspunten Punt Omschrijving

Impact

F22 5-216

Facturregels kunnen inclusief BTW zijn. In UBL moet excl. BTW gemeld worden bij regelbedragen. De vraag is of price wel inclusief BTW kan zijn en hoe dit dan aangeduid wordt. Graag ook voorbeeld regel met prijs incl. BTW t.o.v. prijs excl. BTW.

GEREED

D2

Binnen UBL Ketentest is een XSD Excel sheet vanuit SI. Is er een nieuwe gebaseerd op 1.1.?

GEREED

Toepasbaarheid straatnaam) niet voldoende is. In de praktijk wordt wel alleen met postbusnr gewerkt (ook door de Belastingdienst zelf ☺). (Op basis van factuur 199 Wilmar) 21.95FOUT Moet zijn 18,14 (21% hiervan is de 3,81) 3.81 21.95 Hoe nu aan te geven dat de prijs inclusief BTW is? Kortgesloten met SI: Regelbedragen MOET altijd excl. BTW zijn. Antwoord SI: zie http://www.simplerinvoicing.org/download-documents/



www.ublketentest.nl













8