UBL Ketentest versus UBL SI aandachtspunten

Transcriptie

1 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. OPEN Functionele aandachtspunten F1 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? 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 Q 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 F6 Welke afspraken gelden er binnen UBL-SI voor opname van BTW-nummer van de ontvanger als dit bekend is? 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

2 verplicht (of in het geval van een overheid een OIN). Omdat dit niet altijd opgaat voor SI- LITE is het een warning. F8 F10 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. Wat is de juiste codering voor de BTWcodes? Het gaat om een compleet overzicht van alle BTW-regelingen. LAAG 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. F11 F12 Totaaltelling van de factuurregels wijkt af van de factuurtotalen (door korting die niet in UBL zit). Wordt niet gemeld door de validatie. Is binnen UBL een voorziening voor de G - rekening bij de Paymentmeans? Validatie tool wordt op dit moment aangepast om betere validaties uit te voeren. Zijn in laatste test fase bezig. Zie mail : Binnen GS1 is hiervoor het blok PaymentOnBlockedAccount opgenomen. Antwoord SI: uitvragen binnen SI-groep hoe dit is opgelost. F13 F14 Welke UBL-codering is precies van toepassing voor volgende Paymentmeans: - Per kas betaald - Automatische incasso - Factuur nog betalen Voorstel bij validatietool onderscheid te maken tussen warnings en extra JJ: Is op dit moment niet ondersteunt in SI. LAAG Zie mail 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

3 elementen. JJ: Velden die nodig zijn kunnen worden ingebracht in SI-UBL, en zullen worden beoordeeld. F15 Zijn subtotals mogelijk bij een UBL factuur? LAAG Nu tweemaal gevraagd. Denk het niet. Voor zekerheid even navragen bij SI. F16 F17 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 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. F18 Code ZZZ bij Reason code Allowance/Charge geeft bij SI 1.1 een warning sinds november 2015 (hiervoor niet) 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 Wij gebruiken een BII2 subset van die lijst waarin ZZZ niet is opgenomen. 3

4 We kunnen dus niet garanderen dat de ontvanger snapt hoe hiermee om te gaan. 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. Toelichting: <cbc:accountingcostcode listname RGS listversionid 1.1 >[RGS code]</cbc:accountingcostcode>. 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. 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. D2.1 In de Excel staat bovenaan Use the GS1 specifications for the calculations of the amounts. 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 . 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. D3 D4 Er is een Excel met foutcodes van de 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 controles die via de Schematron (kijkt naar data en afhankelijkheden) uitgevoerd worden? JJN: Er is geen nieuwe gebasseerd op 1.1. Staat wel op onze verlanglijst. JJN: Nee helaas niet. Staat wel op verlanglijst. 4

5 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. (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 vervallen elementen D7 Is er vanuit SI documentatie voorhanden over impact c.q. verschillen UBL-OHNL. LAAG (extern opgepakt) 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 ( 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. De praktijk leert dat enkele leveranciers die al langer geleden UBL ingebouwd hebben (en het nu weer oppakken) zich gebaseerd hebben op UBL-OHNL. Er wordt dan ook 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. D8 Binnen UBL-SI zijn elementen verwerkt m.b.t. Open Peppol. Is duidelijk welke dit zijn en waarvoor ze gebruikt worden. JJ: NL Taxonomie zal op den duur worden uitgefasseerd. Er zijn nogal wat leveranciers die wel de UBL-SI gebruiken maar (althans voorlopig) niets met Peppol doen. Documentatie bij wel/geen peppol gebruik is dan handig. SI: De UBL file voor beide is gelijk. D9 OrderReference en BillingReference qua LAAG SI: Wordt gecorrigeerd in volgende versie. volgorde verkeerd om in SI Excelsheet D10 Creditnota SI 1.0 werkt anders dan SI 1.1 SI: Is change op validatietooling met bovengemiddelde impact. 5

6 Payment Amount. Zie doc. Gerard over creditnota. Even duiden in validatie. JJ: Change op validator. Wordt meegenomen met volgende release vand e validator. Procedureel P2 RFC s openbaar maken. 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. P3 Procedure RFC s afstemmen 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 support@simplerinvoicing.org 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. F2 Op welke wijze valideert UBL-SI de InvoiceTypeCode (380 of 381)? 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. F3 Hoe wordt geadviseerd om te gaan met Antwoord SI: Deze staat op de roadmap. Ik heb besloten deze in te brengen in het 6

7 een creditnota? Mede in relatie met InvoiceTypeCode (380 en 381). 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ë? F4 Is Simplerinvoicing v1.0 gebaseerd op UBL 2.0 en is Simplerinvoicing v1.1 gebaseerd op UBL 2.1.? Antwoord SI: Ja, dit is correct. F5 F7 F9 Welke afspraken gelden er binnen UBL-SI 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 factuurregels zonder bedragen? De voorbeeld invoice bestanden van OASIS 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? 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. F20 XSD en CurrencyID, unitcode 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. F Als bij een adres (supplier of customer) een 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. (Op basis van factuur 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

8 straatnaam) niet voldoende is. In de praktijk wordt wel alleen met postbusnr gewerkt (ook door de Belastingdienst zelf ). F D2 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. Binnen UBL Ketentest is een XSD Excel sheet vanuit SI. Is er een nieuwe gebaseerd op 1.1.? (Op basis van factuur 199 Wilmar) <cbc:lineextensionamount currencyid="eur">21.95</cbc:lineextensionamount>fout Moet zijn 18,14 (21% hiervan is de 3,81) <cbc:taxamount currencyid="eur">3.81</cbc:taxamount> <cbc:priceamount currencyid="eur">21.95</cbc:priceamount> Hoe nu aan te geven dat de prijs inclusief BTW is? Kortgesloten met SI: Regelbedragen MOET altijd excl. BTW zijn. Antwoord SI: zie 8