Verschil factuurbedrag PDF en systeem / backend

J_NL_EU

Goedemiddag,

Er zit er een verschil in het totaalbedrag dat op de PDF factuur staat, en het bedrag zoals het in de backend staat.

De verschillen lopen op tot 5 cent per order. Erg lastig voor onze b2b klanten dus.

Wie heeft daar nog meer last vast?

Groet,

Jan

FOO

Klopt, dat is sinds anderhalve week ongeveer zo. Bij ons wordt het veroorzaakt door de procentuele staffelkortingen op onze site.

Hierover heb ik al contact gehad met LS, omdat hierdoor de facturen een foutmelding kregen met het inlezen naar Snelstart. Het advies van LS: de staffelprijzen "even" uitschakelen........ 😖

Nadat ik had aangegeven dat dit uiteraard geen oplossing is en ook geen kwestie van "even" aanpassen (nog los van de omzet die dit gaat kosten), was het advies dit eens te bespreken met de ontwikkelaars van ons boekhoudprogramma om te kijken of zij iets in kunnen stellen.

Het probleem wordt dus verplaatst naar het boekhoudprogramma. Gelukkig loopt onze koppeling via Snelkoppeling.eu en had ik reeds contact met hen opgenomen. Zij hebben binnen een dag een aanpassing gemaakt, zodat de facturen alsnog ingelezen kunnen worden. Ondertussen is er vanuit LS na 22 juli geen update meer geweest. De facturen komen echter nog altijd niet overeen met het bedrag dat de klant daadwerkelijk betaalt.

Justinnit

Zelfde issue hier, bij diverse orders verschil van 2-5 cent op de facturen..

Justinnit

Wat trouwens ook een feestje is voor je eigen boekhouding. Je LS order facturen koppelen aan niet matchende betalingen voor duizenden facturen per maand!

Dave0701

Kom ze af en toe tegen. Verschil is dan plus of min tussen de 1 a 10 cent.

Zo hebben wij ook een waarde bon die men kan geven. product is €1 dus al ze 100 euro willen tikken ze bij aantal 100 in. Op een of andere manier bij elke 20 euro haalt die er een cent af. Geen idee hoe en LS ook niet. Al meerdere tickets voor aangemaakt maar hoor je niks meer van.

Reken systeem lijkt wel brak zo.

5+5 =9 toch!🤐

Jeroen - Inventory Alarm

Als software ontwikkelaar met de nodige ervaring heb ik aardig wat facturatiesystemen gezien en ook gebouwd.

Bij verschillen in totalen heb ik eigenlijk vooral deze twee fouten gezien. Dit is vooral voor developers die dit lezen. Maar wellicht is dit ook iets dat gebruikers herkennen als ze de facturen bekijken?

1) BTW moet je onder de streep (gegroepeerd per percentage) berekenen, en niet: per factuuregel, vervolgens afronden, pas daarna optellen.

Voorbeeld, correct:

Factuurregel 1: product a EUR 24,99 ex 21% btw. 

Factuurregel 2: product a EUR 24,99 ex 21% btw. 

Factuurregel 3: product a EUR 24,99 ex 21% btw. 

Factuurregel 4: product a EUR 24,99 ex 21% btw. 

Totaal ex btw EUR 99,96

Btw 21%: EUR 20,99 (onafgerond was dat EUR 20,9916)

Maar hoe het niet moet:

Factuurregel 1: product a EUR 24,99 ex 21% btw: btw is EUR 5,25 (onafgerond was dat EUR 5,2479)

Factuurregel 2: product a EUR 24,99 ex 21% btw: btw is EUR 5,25

Factuurregel 3: product a EUR 24,99 ex 21% btw: btw is EUR 5,25

Factuurregel 4: product a EUR 24,99 ex 21% btw: btw is EUR 5,25

Totaal ex btw EUR 99,96

Btw 21%: EUR 21,00 (namelijk de optelling van de afgeronde btw per regel, en dat klopt dus niet)

Verschil: 1 eurocent... maar afh van je aantal factuurregels kan dit oplopen natuurlijk.

2) het gebruik van datatype floating point / double (niet doen! 20,20 wordt soms 20.19999999999996) ipv decimal (wel doen, met 2 achter komma). Nogal technisch. Hier een Java voorbeeld maar geldt voor bijna elke programmeertaal. Je verzint het niet, maar een onervaren programmeur stinkt hier zo in. 

https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio

https://spin.atomicobject.com/2014/08/14/currency-rounding-errors/

Dave0701

Ik ben erachter waar deze fout vandaan komt.

Standaard kosten deze veren € 1.75

Bij 16 stuks krijgt met 10% korting. Dan kosten ze nog maar €1.575

Doe je dat maal 16 dan kom je op € 25.20

Alleen er word op verkeerde momenten verschillend manieren afgerond.

€1.575 moet € 1.58 worden en dan klopt het wel weer.

Alleen doen ze op de factuur dus anders dan in het overzicht.

Jeroen - Inventory Alarm

Inderdaad, de fout is dat er 1,575 wordt gebruikt in de berekening ipv 1,58. Altijd eerst afronden op 2 decimalen en pas dan kun je vermeningvuldigen lijkt me...

Alternatief zou zijn: eerst normale totaal berekenen en pas dan daar de 10% korting op bepalen: 16 stuks kosten normaal 16x EUR 1,75 = EUR 28, maar met 10% korting is dat EUR 25,20.

De fout zit in dezelfde hoek als mijn BTW voorbeeld, men moet consequent goed nadenken waar er wordt afgerond en of de totalen dan nog wel kloppen. Lightspeed lezen jullie mee?

Je hebt nu elk geval de fout gevonden en duidelijk gedocumenteerd. Als je nog eens je webshop aan de wilgen hangt kun je misschien nog eens als Quality Assurance / Software Tester bij Lightspeed aan de slag :)

Jeroen - Inventory Alarm

Doet me ook denken aan een oud "ikje", column in NRC

Het jochie voor me bij de kassa heeft twee blikjes cola van 52 cent per stuk. “Dat wordt een euro en vijf cent,” zegt de caissière. Hij kijkt bedremmeld naar de euro die hij zo stevig in zijn vuistje had geklemd. “Dat is tekort,” zegt de caissière, “ga eerst maar thuis een stuiver halen.” Ik had het jochie natuurlijk vijf cent kunnen geven, maar ik had een beter plan. Net voordat hij naar huis wil rennen, houd ik hem tegen. “Koop één blikje!” zeg ik tegen hem. “Nee, want mijn broertje wil ook een blikje cola.” “Vertrouw me maar,” zeg ik met een glimlach. Hij zet een blikje op de band. “Dat is vijftig cent,” zegt de caissière, die nog niets vermoedt. Ze geeft hem een muntje van vijftig cent als wisselgeld. “Nou kun je ook het tweede blikje kopen,” zeg ik. Hij lacht zijn tanden bloot. Daarna moet ik afrekenen. De caissière lacht niet naar me. “Dat is 18,05 euro,” zegt ze bits. Ik pak een biljet van 20 euro. “Wil je een stuiver erbij?”, vraag ik. 

Justinnit

Mooi analyse heren, het lijkt bij mij ook te gebeuren met orders waar een staffelkorting is toegepast.

@Lightspeed met bovenstaande analyse lijkt het me niet heel ingewikkeld om dit te fixen?

Graag hoor ik hoe lang jullie hiervoor nodig hebben.

hortiheatingshop

Goedemorgen,

Helaas hebben wij ook problemen met het totaalbedrag op sommige facturen. Het totaalbedrag klopt soms niet. Soms zijn de verschillen 1 a 2 cent, maar nu factuur met verschil van 20 cent!

Er is geen sprake van staffelprijzen o.i.d., de optelling is gewoon niet goed.

Betaling via Mollie geeft wél het juiste bedrag van € 217,20.

Dit staat heel onprofessioneel richting onze klanten en geeft problemen met automatisch inlezen en afboeken in ons boekhoudsysteem.

Justinnit

@hortiheatingshop hier ook, duizenden mutaties handmatig moeten koppelen aan betalingen...

Jeroen - Inventory Alarm

Ik werk niet bij Lightspeed maar mijn handen jeuken wel als ik dit lees. Het feit dat wel het juiste bedrag via Mollie wordt getoond, geeft aan dat onder de motorkap wel het juiste bedrag wordt gebruikt. Bij genereren van een factuur (in pdf, web pagina, mail of wat dan ook) is er altijd een stap waarbij een getalletje wordt opgehaald van "onder de motorkap" (in dit geval 217,20), en dat wordt dan getoond op de factuur een een veldje. Bij die stap kan óók iets mis gaan, bv door een verkeerde instelling van een scherm-veldje (0 decimalen ipv 2). Dus dan is het overal goed behálve op het scherm, en dat is wat de klant ziet. Een perfecte ijsberg met een vuiltje op de top die boven water uitsteekt. Maar die top is wat de klant ziet en uiteindelijk hetgene dat van belang is voor de klant.

Hopelijk zet support dit snel door naar de ontwikkelaars.

-- edit, zie hieronder. Lijkt op een probleem mbt hoe de btw wordt berekend in de pdf, en niet zozeer een display probleem --

Jeroen - Inventory Alarm

@hortiheatingshop ik herken de layout met de grijze balkjes als de factuur pdf van Lightspeed. Vraagje: als je de order bekijkt in je LS backend, staat daar dan bij totaalbedrag wel 217,20 of staat daar ook 217,00?

Dus dit lijstje, als je "Details tonen" openklapt bij de order, hoe ziet dat eruit?

Jeroen - Inventory Alarm

@hortiheatingshop yep jij hebt het 1) btw afrondingsprobleem zoals ik eerder beschreef.

Correcte BTW: EUR 3,59 * 50 stuks = EUR 179,50. BTW 21% = EUR 37,695 afgerond EUR 37,70

Foutieve BTW: EUR 3,59 BTW 21% = EUR 0,7539 afgerond EUR 0,75. Doe dat maal 50 = EUR 37,50.

En dat is dus precies EUR 0,20 verschil.

Mijn analyse mbt je plaatje:

Regel "Totaal excl. BTW" wordt correct uitgerekend: 3,59 * 50 = 179,50

Regel "BTW 21%" wordt correct uitgerekend: 21% over 179,50 = 37,70

Totaal incl BTW wordt foutief uitgerekend: 21% over 3,59 = 0,75 afgerond, dat keer 50 = EUR 37,50 BTW, plus EUR 179,50 = EUR 217,00.

Ik vermoed dat in de code die de pdf maakt, de BTW berekening dus anders wordt gedaan dan in de code die het bedrag tbv de betaling regelt (Mollie).

@Lightspeed ik nodig jullie van harte uit om mij uit te leggen dat ik het helemaal verkeerd heb :)

-- edit-- even op een testshop ex btw een product aangemaakt. Handmatig offerte gemaakt en omgezet naar een order. Heb precies dezelfde fout in de factuur pdf. Staat wel goed in de backend bij order. Is dus een pdf btw uitrekenprobleem inderdaad.

Jeroen - Inventory Alarm

Net even via de chat (LS backend, Help knop linksonder, Chat met ons, Live chat) contact gehad met LS en ze op deze post gewezen en gevraagd of ze er naar willen kijken.

Paula

@Jeroen - Inventory Alarm 😍 Jij mag blijven 😄

Ik werk niet bij Lightspeed maar mijn handen jeuken wel als ik dit lees

Heb je niet stiekem ergens nog een paar uurtjes over? 😉

Jeroen - Inventory Alarm

@Paula

Heb je niet stiekem ergens nog een paar uurtjes over? 😉

Je zou het haast denken he. Druk zat eigenlijk. Of je doet als onderstaande developer die een nieuwe baan had (bleek een 1 april grap te zijn dus niet echt gebeurd, maar toch leuk)

Paula

Zoiets bijvoorbeeld ;) Haha!

Jip

@Jeroen - Inventory Alarm

Ik zeg doen! Misschien dat ze dan wakker worden:

https://www.lightspeedhq.nl/vacatures/overzicht/amsterdam/

Frank

Lol

Ik heb dit al een jaar of 6 geleden doorgegeven naar toen nog SeoShop.

Een jaar of wat geleden ook op dit forum maar omdat blijkbaar te weinig mensen dit genoeg interesseerde om dit te rapporteren is daar tot op heden niks mee gedaan. De bedragen zijn echt op 30% van alle facturen fout. met 1 tot 2 cent verschil als gevolg. Allemaal doordat het @Lightspeed systeem niet goed kan afronden en optellen.@Lightspeed Team

https://community.lightspeedhq.com/nl/discussion/comment/14045#Comment_14045

FOO

Afronden ging bij onze facturen altijd goed, totdat de nieuwe regeling voor buitenlandse BTW in ging op 1 juli. Toen konden we ineens niet alle facturen meer in Snelstart importeren. Dit is naar mijn weten dan ook een "nieuw" probleem.

Ruud

@Lightspeed @Lightspeed Team Het afrondingsverschil is mij ook opgevallen. Het verbaasd mij dan ook dat hier geen reactie op komt vanuit Lightspeed.

Wahe

Deze issue speelt al langer, reeds in 2015 hebben we een melding gemaakt bij SeoShop, echter vanwege weinig meldingen was prio. niet zo hoog was antwoord van Seoshop.

Justinnit

Kan dit alsjeblieft opgelost worden @Lightspeed @Lightspeed Team!!

Michelle_Eier

Hi allemaal!

Graag wil ik vanuit Lightspeed reageren op dit topic om jullie hopelijk van wat extra informatie te voorzien.

De afgelopen weken hebben wij een exponentiele toename gezien in het aantal gemelde cases aangaande dit topic. Vanwege deze toename hebben wij dit topic nogmaals met hoogste prio bij onze developers neergelegd.

De laatste dagen is hier een uitvoerige analyse over gemaakt en heb ik zojuist de bevestiging gehad dat wij dit gaan oppakken. Momenteel kan ik jullie helaas nog geen tijdlijn geven.

Ik zal jullie de aankomende tijd updaten met de vorderingen omtrent dit topic.

Michelle

J_NL_EU

Hallo @Michelle_Eier,

Is er al iets meer bekend?

In totaal zijn we meer dan een half jaar verder, en onze klanten klagen behoorlijk.

Alvast bedankt,

Jan Marten

Jip

@Michelle_Eier

Wanneer is dit probleem opgelost? Op 23 september kwam de bevestiging van jou dat men hiermee aan de slag zou gaan. Het heeft de hoogste prioriteit.

Treurig dat het Lightspeed Developement team zo vreselijk traag werkt. En het is niet zo dat dit zelfde team al heel druk is geweest met de ontwikkeling van nieuwe features binnen Lightspeed de laatste jaren. Op dit forum staan nog veel punten open en deze worden maar niet opgepakt.

Wanneer gaan jullie eens starten? In de changelogs zie ik bugfixes of ongevraagde features. De gevraagde features worden gewoonweg niet uitgevoerd.

Ruud

@Lightspeed Team @Michelle_Eier @lightspeeduser@Lightspeed Inmiddels al meer bekend?

FOO

Op 11 oktober hebben wij onderstaande reactie ontvangen m.b.t. de afrondingen:

Afgelopen vrijdag ben ik door Product geïnformeerd dat we na het testen één oplossing hebben gekozen om te documenteren en te gaan implementeren.

Een voorlopige ETA/GA om deze oplossing daadwerkelijk in productie te nemen is gezet op uiterlijk eind november. Het team heeft ook aangegeven hard hun best te zullen om het voor half november op te leveren.

Verder heeft webwinkelfacturen mij laten weten een workaround gebouwd te hebben in relatie tot het issue. Het houdt ik dat ze in bepaalde situaties het ordertotaal incl boeken ipv total_invoice waarde mits het verschil niet te groot is. Hierdoor worden er geen of minder facturen tegen gehouden. Uiteraard is dit alleen van toepassing als jullie deze koppeling gebruiken.

Maringka van Amerongen-Pronk

hoi hoi,

Ik heb hier met LS al vele malen contact gehad en de toon wordt steeds onaardiger. Een paar cent klopt niet maar zou ik nog mee kunnen leven.

Het gaat bij ons niet om een paar centen, maar euro's per order en dat gemiddeld voor enkele honderden orders per dag.... Bijna elke order heeft het verschil.

Klanten zijn bij ons boos, al een aantal klanten nu hierdoor verloren.

En het enige wat ik hoor is, het heeft onze aandacht.

Nou not dus. Al maanden geleden eerste ticket ingestuurd.

Ik ga vandaag weer ticket insturen.

😡