UBL

[se7en]

Kan iemand mij informatie bezorgen hoe ik via een FM database een UBL-formaat kan creëren.

[menno]

Informatie over UBL kan je vinden via: https://nl.wikipedia.org/wiki/Universal_Business_Language

 

Transformatie doe je door te exporteren vanuit filemaker met fmpxml-formaat en xslt. Met xslt kan je ieder gewenst testformaat creëren. Algemene info over xslt kan je starten op https://www.w3schools.com/xml/xsl_intro.asp en filemaker-specifiek kan je in oudere versies (zoals FMPA11) in C:\Program Files\FileMaker\FileMaker Pro 11 Advanced\Nederlands Extra’s\Voorbeelden xml en xslt-voorbeelden aantreffen

[harpermac]

se7en zou je die voorbeeld documenten misschien willen delen want ik kan hem bij zowel 13 als 16 niet vinden, zit namelijk met het zelfde probleem.

[se7en]

Informatie over UBL kan je vinden via: https://nl.wikipedia.org/wiki/Universal_Business_Language

 

Transformatie doe je door te exporteren vanuit filemaker met fmpxml-formaat en xslt. Met xslt kan je ieder gewenst testformaat creëren. Algemene info over xslt kan je starten op https://www.w3schools.com/xml/xsl_intro.asp en filemaker-specifiek kan je in oudere versies (zoals FMPA11) in C:\Program Files\FileMaker\FileMaker Pro 11 Advanced\Nederlands Extra’s\Voorbeelden xml en xslt-voorbeelden aantreffen

 

Begrijp niet goed wat je hier wil mee aantonen.

Ben op zoek naar UBL format uit Filemaker.

Kan je dit even toelichten

[menno]

Begrijp niet goed wat je hier wil mee aantonen.

Ben op zoek naar UBL format uit Filemaker.

Kan je dit even toelichten

UBL is een bepaalde vorm van (zakelijke) berichten die in XML wordt gemaakt. Dus heb je XSLT nodig om van het XML-formaat van FileMaker het XML-formaat van UBL te maken, danwel andersom. De links geven je een prima startpunt waar je uitleg krijgt over wat UBL is en welke eisen er aande berichten hangen respectievelijk de taal XSLT. Er zijn vele berichtsoorten mogelijk binnen UBL, waarbij de onderdelen van de berichten aan een standaard voldoen en nogmaals die voorwaarden kan je vinden via de links.

 

Doe eerst zelf maar wat meer moeite en toon dat ook maar aan door een abstract van je probleem hier te tonen/uploaden. Met een beetje geluk kan je hier dan wel worden geholpen. Jij geeft hier nu niet eens een voorbeeld van een bericht dat je wilt maken, wat verwacht jij dan? Je betaalt hier toch niemand voor op dit forum?

[Marsau]

Ik ben eigenlijk wel erg benieuwd naar ervaringen met betrekking tot het genereren van UBL-facturen. Inderdaad, een hoop informatie over de UBL is aanwezig; maar hoor nog weinig van succesvolle implementaties in of in combinatie met Filemaker.

 

Dit forum is toch niet alleen voor oplossen van problemen, maar ook kennisdeling. Toch?

 

Als we weten wie specifieke expertise heeft kunnen we elkaar ook gericht helpen, wellicht ook commercieel.

[se7en]

Ondertussen is het UBL gelukt.

Mijn laatste probleem is om het veld waarin deze code staat te exporteren en/of op te slaan naar een txt met extensie .xml.

Je kan wel exporteren naar txt (tab gescheiden) maar daarmee lukt het niet.

[Banach]

Gebruik 'Export Field Contents' (http://www.filemaker.com/help/13/fmp/nl/html/scripts_ref1.36.61.html#1029659)

Een complicatie kan zijn dat je dan onder FM13 een UTF-16 encoded bestand krijgt. Veel programma's kunnen dat niet aan als input. Je moet het dan converteren naar UTF-8. Op de Mac doe je dat met iconv.

[menno]

Dit forum is toch niet alleen voor oplossen van problemen, maar ook kennisdeling. Toch?

Als we weten wie specifieke expertise heeft kunnen we elkaar ook gericht helpen, wellicht ook commercieel.

Hi Mars,

 

je kan voor de standaarden eens kijken naar:

http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html en

http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html

Als je van .html simpelweg .pdf maakt, krijg je de zaak in pdf-formaat.

 

De Nederlandse en Belgische overheid hanteren beiden versie 2.0 , waarbij de Belgische overheid een aangepaste versie schijnt te hanteren die is gebaseerd op 2.0. Ik weet nu niet waar je die kan vinden (niet naar gezocht).

 

In een notedop komt het hier op neer: je moet met je afnemer/leverancier afspreken welke delen van de UBL-standaard moeten worden gebruikt. Het kan zijn dat je alleen quotation, order, order cancellation en invoice hieft te gebruiken, maar dat kan ook minder of meer zijn. In de beide documenten staan verwijzingen naar xsd's excel's en voorbeelden van ubl-xml bestanden, zodat je weet wat je na keuze moet gaan produceren.

 

Het maken van de xml's lijkt me geen enkel probleem, dat kan op verschillende manieren (xml/xsl, tekstvervangen, xml-samenstellen), maar ik zou persoonlijk kiezen om met xml/xsl-export en import te werken. Reken voor het maken van een xslt, afhankelijk van de complexiteit, op 4 tot 8 uur per stuk plus de tijd die je nodig hebt om in FM de juiste data te verzamelen. Heb je dat eenmaal gedaan, dan is het alleen nog maar knopjes drukken

 

Ben jij ook op de summit volgende week? Kunnen we dan eens kijken of we een clubje bij elkaar kunnen krijgen die dit eens op poten kunnen/willen zetten.

[burggraaf]

Wij zijn hier al even mee bezig en op zich hebben we het (vanuit onze software) wel werkend.

 

Er is echter nog 1 hobbel en dat is de afronding. UBL wil persé een afronding op 2 decimalen... Maar ja, dan kan het zomaar zijn dat je met afrondingsverschillen komt te zitten. Nog niet gevonden hoe je dat dan, volgens de UBL normering, zou moeten oplossen.

[menno]

Als je afrondings-verschillen hebt, dan reken je op ongelijke momenten kortings- en btw-percentages. Daar zijn al heel wat woorden over opgeschreven. Je moet voor één rekenmethode kiezen.

 

Wanneer je 5 artikelen hebt en je berekent over ieder artikel afzonderlijk eenzelfde percentage van dat artikel en telt dan de uitkomsten op, dan is die uitkomt in principe anders dan wanneer je eerst de bedragen van de artikelen bij elkaar optelt en dán het percentage daarover berekent.

 

Dit probleem treedt vooral op bij kleine bedragen, maar ook bij grotere bedragen wanneer een btw-percentage bijvoorbeeld is gebroken. Wij hanteren in Nederland 21 en 6 procent, maar dat kan morgen zomaar 21,5 en 7,5 worden en dan heb je er met grotere getallen ook last van.

 

Ter illustratie heb ik een excel toegevoegd. Het eerste deel staan kleine bedragen, daar treden afronding verschillen op het totaal op. Het tweede deel bevat dezelfde getallen x100 en dan zijn er geen verschillen meer.

 

Geef je bij de nettobedragen de btw-bedragen mee, dan moeten jouw cumulaties diezelfde bedragen optellen, anders gaat de vierkantscontrole bij verwerking fout en wordt je bestand geweigerd.

 

Je herinnert je misschien natuurkunde-praktikum van de middelbare school, waar je bij het meten moest noteren wat de maximale aflees-nauwkeurigheid van de meetapparatuur was. Als je een gemiddelde moest nemen van de metingen, dan moest je die nauwkeurigheid verwerken in je foutberekening. Heb je dus 7 getallen op 0,01 afgerond, dan is de fout dus ± 0,005 x 7 = ± 0,035. In het eerste deel van de excel is de totale afwijking - 0,02 over totaal 7 bedragen, dat is dus binnen de norm

Afrondingsverschillen.zip

[burggraaf]

Ja, er is al veel over gezegd maar... dat geeft geen oplossing... In je voorbeeld ga je nog uit van een simpele systematiek met 1 BTW percentage maar als er meerdere BTW percentages door elkaar worden gebruikt wordt het complexer (en ja, dat moet ook kunnen). Ook het terug rekenen van inclusief naar exclusief. Dus, je komt vroeg of laat te zitten met de verschillen en zelf een cent verschil op het totaal is geen optie.

 

Het lastige daarbij is dat je per regel de BTW moet opgeven. Je kunt dus niet 'aan het eind' even de optelsom van je BTW maken waardoor je de verschillen kleiner kunt maken. Ook UBL doet de vierkantsvergelijking maar technisch gezien kan dat eigenlijk niet.

 

Of zoals ik ook al tegenkwam:

There are no specific agreements concerning the match between the total in the header of the invoice and the detail lines, mainly because this is by rounding theoretically impossible. The receiver has the responsibility to prevent the possible inconsistency that may arise in this way.

[menno]

In je voorbeeld ga je nog uit van een simpele systematiek met 1 BTW percentage maar als er meerdere BTW percentages door elkaar worden gebruikt wordt het complexer (en ja, dat moet ook kunnen)

Mijn voorbeeld gaat niet uit van 1 percentage, maar toont er slechts één, meerdere btw-percentages in dit voorbeeld zouden niets toevoegen. De rekenmethodes wijzigen namelijk nooit en er zijn er slechts twee mogelijk, waarbij in ieder systeem er altijd slechts één wordt gebruikt:

 

• Per lineitem; op iedere order/factuurregel de btw berekenen
  
• Per btw-klasse; alle bedragen van een btw-percentage x worden bij elkaar geteld en daarover wordt dan het btw-percentage toegepast. (Bij meerdere btw-klassen op een order/factuur, wordt dit voor iedere klasse afzonderlijk gedaan, maar dit maakt voor de werkwijze niks uit)

 

Tenslotte heb je nog een taak om rekening mee te houden: prijzen zijn netto óf bruto (exclusief of inclusief BTW). Bij netto-prijzen wordt de BTW over het bedrag berekend en bij bruto-prijzen wordt het er van berekend. in formulevorm:

 

• Netto: BTWbedrag = NettoBedrag * BTWperc
  
• Bruto: BTWbedrag = BrutoBedrag - BrutoBedrag/(1+Percentage/100)

 

Uiteindelijk moet de ontvangende partij bij jou aangeven hoe zij de BTW-bedragen berekenen en jij moet daar rekening mee houden met wat je aanlevert. Heb je een probleem, dan is het probleem dat je het niet goed hebt afgestemd. Het correct uitrekenen van de BTW is geen probleem er zijn alleen meerdere (allemaal correcte) methoden, die tov elkaar afwijkende uitkomsten kunnen hebben en dat heb ik geprobeerd te illustreren met de excel.

 

Jij kwam in de documentatie al tegen dat de ontvanger verantwoordelijk is om eventuele afwijkingen bij de ontvangst van de gegevens correct te verwerken. De praktijk is helaas anders en dus zal je het met elkaar af moeten stemmen.

 

In de B2B handel wordt meestal met nettoprijzen en btw per line-item gewerkt en is de aansluiting met de meeste financiële systemen het eenvoudigst (exact, twinfield, afas, king, proacc, etc).

In de B2C handel wordt meestal met bruto prijjzen, maar ook met btw per line-item gewerkt. Ook daar is de aansluiting met financiële systemen dan geen enkel probleem.

[burggraaf]

Het probleem zit hem in het volgende: Of het nu kleine of grote getallen zijn in UBL moet je per lijn het bruto bedrag vermelden (2 decimalen) en de BTW (2 decimalen). Vervolgens kun je de boel optellen en kom je afgerond prima uit maar... De controle bij UBL gooit roet in het eten. Deze pakt het totale brutobedrag (van de lijnen) en rekent de BTW uit afgerond op 2 decimalen. Deze moet overeenstemmen met de optelsom van de regels en daar zaten nu dus juist die 'vervelende' afrondingen in. Eigenlijk precies zoals jij ook weergeeft in het 1e voorbeeld je Excel bestand en concludeert dat het niet klopt. Ergo, de kans is groot dat het niet klopt en daar ga je ook nooit uitkomen.

 

Inmiddels is me duidelijk dat men in UBL daarvoor een parameter in heeft zitten waarin je het afrondingsverschil kunt opnemen. Dat is ook de enige methode op het kloppend te krijgen op basis van de door UBL gehanteerde afrondingsmethode per lijn.

[menno]

Als ik jou verhaal lees wordt dus tijdens de import van jouw UBL-bestand de btw per line-item berekend, vervolgens worden die btw-bedragen bij elkaar geteld. Parallel worden alle bruto bedragen bij elkaar geteld en daarvan wordt eveneens de totale btw berekend....... Dan moet je die parameter waar jij het over hebt dus altijd meegeven, want de kans dat de vierkantscontrole slaagt is zo wel heel erg klein geworden.

 

Ik heb overigens even zitten kijken naar een voorbeeld van een factuur op http://docs.oasis-open.org/ubl/os-UBL-2.1/xml/UBL-Invoice-2.0-Example.xml en daarin wordt met netto-prijzen gerekend en niet met bruto zoals jij aangeeft in jouw situatie te doen. Verder worden daarin per line-item de btw-bedragen aangegeven en in het element "cac:TaxTotal" wordt het cumulatief van alle btw-bedragen geplaatst (cac:TaxAmount) en binnen die TaxTotal staat er een opsomming van de cac:TaxSubtotal met het cumulatief per btw-klasse.

 

Het kan natuurlijk zijn dat ik me vergis, maar zo te zien gaat het gewoon goed als je voor die TaxTotal gewoon de losse btw-bedragen bij elkaar optelt en daarvan het totaal (per btw-klasse elk in een aparte TaxSubtotal) bij elkaar optelt in de TaxTotal.

 

Wanneer het totaal van Invoice/TaxTotal/TaxAmount overeenkomt met de optelsom van alle Invoice/TaxTotal/TaxSubtotal/TaxAmount én met de optelsom van alle Invoice/InvoiceLine/TaxTotal/TaxSubtotal/TaxAmount is de vierkantscontrole gewoon geslaagd. Hetzelfde geldt voor de getallen van de optelsom van alle Invoice/TaxTotal/TaxSubtotal/TaxableAmount en de optelsom van alle Invoice/InvoiceLine/TaxTotal/TaxSubtotal/TaxableAmount

 

Als je maar altijd één en dezelfde rkenmethode gebruikt

[burggraaf]

Als ik jou verhaal lees wordt dus tijdens de import van jouw UBL-bestand de btw per line-item berekend, vervolgens worden die btw-bedragen bij elkaar geteld. Parallel worden alle bruto bedragen bij elkaar geteld en daarvan wordt eveneens de totale btw berekend....... Dan moet je die parameter waar jij het over hebt dus altijd meegeven, want de kans dat de vierkantscontrole slaagt is zo wel heel erg klein geworden.

Dat klopt want dat is in beginsel ook wat er gebeurt als je het UBL bestand wilt inlezen in een boekhoudingpakket (er komen teveel afrondingsverschillen naar voren) of je moet per keer handmatig de correctie gaan toepassen.

 

Ik heb overigens even zitten kijken naar een voorbeeld van een factuur op http://docs.oasis-open.org/ubl/os-UBL-2.1/xml/UBL-Invoice-2.0-Example.xml en daarin wordt met netto-prijzen gerekend en niet met bruto zoals jij aangeeft in jouw situatie te doen. Verder worden daarin per line-item de btw-bedragen aangegeven en in het element "cac:TaxTotal" wordt het cumulatief van alle btw-bedragen geplaatst (cac:TaxAmount) en binnen die TaxTotal staat er een opsomming van de cac:TaxSubtotal met het cumulatief per btw-klasse.

Klopt alleen... In het voorbeeld heb je geen last van afrondingsverschillen.

 

Het kan natuurlijk zijn dat ik me vergis, maar zo te zien gaat het gewoon goed als je voor die TaxTotal gewoon de losse btw-bedragen bij elkaar optelt en daarvan het totaal (per btw-klasse elk in een aparte TaxSubtotal) bij elkaar optelt in de TaxTotal.

Geen vergissing want dat klopt vanzelfsprekend ook.

 

Ik snap ook zeker het punt wat je maakt en ik kan me daarop zich ook wel in vinden (het gaat niet om die paar centen). Maar... Het probleem gaat hem uiteindelijk toch zitten in de afronding. De ene klant neemt daar wellicht genoegen mee, de ander niet. En de gemiddelde boekhouder zal toch echt zeggen: "Het moet kloppen!"

[Banach]

De belastingdienst maakt er in ieder geval geen probleem van.

[menno]

Klopt alleen... In het voorbeeld heb je geen last van afrondingsverschillen.

Dat klopt, maar in het voorbeeld heb je in de eerste plaats geen last van afrondings-verschillen omdat in de line-items de btw-bedragen per line-item apart worden berekend. Vervolgens worden die op de line-items berekende bedragen gebruikt om de totalen per btw-klasse te bepalen.

 

Inherent is dan dat je geen afrondings-verschillen hebt, of je mooie bedragen hebt of niet maakt dan niet uit want afronden wordt door iedereen en alle programma's op dezelfde manier gedaan: bij exact en ½ minimum eenheid wordt er naar de erop volgende eenheid afgerond en anders naar de voorgaande.

 

Ik ben het met je eens dat een berekening moet kloppen, maar afronden moet je gewoon altijd op dezelfde manier doen en dan kan je zonder zorgen je getallen met elkaar vergelijken en vierkants-controles uitvoeren. Bepaal je fracties van line-items, dan moet je die resultaten in alle vervolgresultaten verwerken. (Zie ook mijn voetnoot over foutberekening bij het natuurkunde-praktikum op de middelbare school, want dat is het principe)

[Banach]

Reactie gewist omdat ik verkeerd gelezen heb, sorry.

[Marsau]

Hi Menno,

ja, ik ben er bij. Leuk om je dan te ontmoeten

 

En alle andere vrienden hier, natuurlijk..

 

hartelijke groet, Mars