[Alg] Facturatiesoftware - procedures

[BikkelZ]

Ik zit eigenlijk een beetje met het aloude probleem dat software ook eindgebruikers kent. Het is op dit moment zo dat bepaalde software die ik gemaakt heb ook facturen genereert. De volgende zaken zijn van belang bij facturen:

- Dat ze correct zijn (duh)
- Dat de factuurnummers uniek en opeenvolgend zijn

Blijkbaar is het voor de mensen die de contracten, producten etc. invoeren in het systeem nogal moeilijk om te begrijpen dat als de informatie correct invoeren de factureren er correct uit komen rollen en als ze dat niet doen de facturen dus ook niet correct zijn. Aangezien ik dan degene ben die het uit de database mag gaan peuteren, met wisselend succes afhankelijk van het feit of er nog facturen gegenereerd zijn daarna, begin ik me toch eigenlijk een beetje af te vragen wie waar nou precies voor verantwoordelijk zou moeten zijn.

Aangezien er wel verwacht wordt dat alle gegenereerde facturen opgeslagen worden en automatisch doornummeren, producten niet dubbel gefactureerd worden en ga zo maar door, kan ik dus niet die flexibiliteit van 'oeps foutje, we draaien het nog een keer uit met dezelfde nummers' inbouwen.

Hoe los je dit probleem normaal gesproken op? Want je kunt blijkbaar niet van eindgebruikers verwachten dat ze een clou hebben blijkbaar, maar om constant in een database te moeten gaan rommelen om er voor te zorgen dat hun gerommel gecorrigeerd kan worden en er tegelijkertijd toch een redelijk rigide systeem gehandhaafd moet worden om dubbelfacturen te voorkomen.

[Gerco]

Wat is nu precies je probleem? Wat kunnen die gebruikers verkeerd invoeren? Misschien is het een idee om te zorgen dat ze uberhaupt al geen onzin kunnen invoeren, dan hoef je daar ook geen rekening mee te houden bij het genereren van je facturen. Een en ander is natuurlijk sterk afhankelijk van de soort onzin die ze nu invoeren.

Als zij, bijvoorbeeld, een locatie twee keer verhuren aan een andere persoon in dezelfde periode moet de software dat niet toestaan. Je kan niet dezelfde locatie twee keer tegelijk verhuren en dat moeten ze dus ook niet in kunnen voeren.

Enige duidelijkheid over de soort fouten waar je het over hebt is wel handig

[Crazy D]

Je kunt in de software veel proberen af te vangen, maar uiteindelijk zijn de gebruikers verantwoordelijk voor de juistheid van de gegevens. Je kunt inbouwen dat een produkt niet verhuurd kan worden in eenzelfde periode, maar je kunt niet controleren of de klant sowieso wel dat produkt wilde huren. Leg de verantwoording maar gewoon bij eindgebruikers. Ze schelden 2 dagen op je, de 3e dag komt de manager vertellen dat ze goed werk moeten leveren of een andere baan moeten zoeken, en de 4e dag werkt alles gewoon zoals het hoort, letten mensen op op wat ze doen, etc.

En je kunt natuurlijk altijd faktuurnummers pas toekennen bij een bepaalde aktie (bv bij definitief afdrukken of fiatteren) in plaats van bij de invoer. Fakturen laten vervallen is ook een optie die je vaak ziet. Zo kun je een faktuur nogmaals genereren, maar dan wel goed...

[cowgirl]

Crazy D schreef op woensdag 20 september 2006 @ 12:52:
En je kunt natuurlijk altijd faktuurnummers pas toekennen bij een bepaalde aktie (bv bij definitief afdrukken of fiatteren) in plaats van bij de invoer.

Dat is op zich een hele goede optie. Een order kan dan nog gecorrigeerd worden voordat er daadwerkelijk gefactureerd wordt. Als je werkt met klanten aan de balie is dit wel lastiger omdat deze de factuur direct mee willen hebben.

Crazy D schreef op woensdag 20 september 2006 @ 12:52:
Fakturen laten vervallen is ook een optie die je vaak ziet. Zo kun je een faktuur nogmaals genereren, maar dan wel goed...

Vervallen is niet netjes. Ook de belastingdienst kan daar problemen over maken. De 'correcte' manier om een foute faktuur te laten vervallen is deze te krediteren en een nieuwe order te maken voor het juiste bedrag/ de juiste artikelen.

[BikkelZ]

De fouten die ze maken:

- Producten die ze als gratis beloofd hebben aan de klant op de standaardprijs laten staan
- Geen contractnummers meenemen als er iets overgezet wordt uit een ander systeem

Dat zijn geen dingen waar ik iets tegen kan doen door er nog meer programmeerwerk tegen aan te gooien. Mijn gevoel vertelde me ook dat het gewoon PEBCAK is, en niet iets waar ik wat tegen kan doen.

De optie om eerst testfacturen te genereren ga ik denk ik nog wel inbouwen, maar waarschijnlijk moet ik dan wel moet koeienletters over het midden 'TESTFACTUUR' zetten zodat ze niet op het ongoddelijke idee komen dat ze deze facturen ook al best kunnen insturen en dus niet meer definitief de boel hoeven uit te draaien.

Want dan loopt de nummering weer in de soep....


Als je facturen wil laten vervallen, hoe gaat dat, mede Belastingdiensttechnisch in zijn werk? Want als het niet toevallig het laatste rijtje is, dan zit er dus een gat in de nummering, en daar wordt boekhouding weer niet blij van.

[P_de_B]

De meeste facturatie software vraagt ook 'Zijn de facturen correct afgedrukt?'

Als de vraag met ja beantwoord wordt zijn de facturen definitief, en kunnen ze dus slechts door een creditnota gecorrigeerd worden.

[MissingDog]

Je kunt een factuur wel laten vervallen (na boeking) als het de laatste van het rijtje is, maar wanneer je met een multi-user systeem werkt zit je met locking etc. om dit mogelijk te maken. Ik zou zelf kiezen voor een oplossing die altijd de boekhouding op orde houdt en dus altijd een creditfactuur boeken bij het laten vervallen van een onjuist geboekte factuur. Pro-forma werken is een nette manier om mee aan de gang te gaan, dus eerst akkoord geven voor inboeken.
Op die manier zal je nooit problemen krijgen met onjuiste omzetcijfers door een fout in de facturatie.

En het PEBKAC verhaal....tja...die vlieger gaat helaas maar al te vaak op, al is 't in het pakket wat ik hier gebruik meestal PEBDAK (developer and keyboard). Hang bijna dagelijks met de ontwikkelaar aan de telefoon om wat foutjes recht te zetten...voel me af en toe medeontwikkelaar, maar dat is denk ik alleen maar fijn omdat ik de consequenties van wijzigingen vooraf kan overzien en hierop kan inspelen met m'n suggesties.

[ Voor 6% gewijzigd door MissingDog op 20-09-2006 13:21 ]

[alx]

Aan de software kant valt wel degelijk wat te doen. Foolproof kan niet (then the universe makes a better fool), maar ga nou eens na met gebruikers wat de meest gemaakte fouten zijn en kijk of die door de software af te vangen zijn (weigeren of waarschuwen). De rest is voor de gebruiker.

Het is extreem moeilijk om mensen ervan te overtuigen dat ze zelf moeten blijven nadenken als ze met machines samenwerken. Maar vraag ze maar ns of ze zonder te kijken doorlopen als het stoplicht op groen springt. Toch is dit nodig, want automatisering kan mss wel, zeg, 80% naar 90% correctheid brengen, maar verreweg de beste resultaten (>> 99%) ontstaan bij wederzijdse controle, simpelweg, omdat het type fouten dat beide maakt, verschilt.

Je bent niet al te concreet, maar als dubbelfactureren een veel gemaakte (en ernstige) fout is, lijkt me dat dat wel te detecteren moet zijn.

edit: komt een beetje laat...

[Gerco]

BikkelZ schreef op woensdag 20 september 2006 @ 13:12:
Als je facturen wil laten vervallen, hoe gaat dat, mede Belastingdiensttechnisch in zijn werk? Want als het niet toevallig het laatste rijtje is, dan zit er dus een gat in de nummering, en daar wordt boekhouding weer niet blij van.

Een factuur, eenmaal genummerd, kun je nooit meer verwijderen. Gaten in je nummering mag niet. De enige correcte manier om dit te doen is 1 of meerdere facturen sturen die de 'vervallen' factuur crediteren en het correcte nieuwe bedrag in rekening brengen.

[Verwijderd]

cowgirl schreef op woensdag 20 september 2006 @ 13:10:[...]

Vervallen is niet netjes. Ook de belastingdienst kan daar problemen over maken. De 'correcte' manier om een foute faktuur te laten vervallen is deze te krediteren en een nieuwe order te maken voor het juiste bedrag/ de juiste artikelen.

Dit lijkt me de enige juiste manier. Op die manier ligt de actie ook bij de gebruiker en niet bij jou, zeker gezien

- Producten die ze als gratis beloofd hebben aan de klant op de standaardprijs laten staan
- Geen contractnummers meenemen als er iets overgezet wordt uit een ander systeem

het hier blijkbaar gewoon over lompigheid van de eindgebruiker gaat en jij eigenlijk goed gek bent dat je überhaupt dit d.m.v. gerommel in de database gaat proberen op te lossen.

Volgende keer als ze bij je komen zeuren over een foute factuur dus lekker laten crediteren en opnieuw laten aanmaken.

Opvoeden heet dat.

[Janoz]

Dit topic lijkt (o.a.) mij meer thuis te passen in SEA.

[marander]

Ja de nummering van facturen is natuurlijk heilig en moet opvolgend blijven. Maar verwijderen kan natuurlijk wel als de verwijderde nummers weer gebruikt worden. Let wel op dat als je een db hebt met een id erin zal de belastingdienst het nog steeds zien.

Je hebt echt het gebruikelijke probleem en dat is dat je met gebruikers hebt te maken. Die hebben instructie nodig en willen "gewoon effe" alles invullen zonder te denken welke gevolgen. Voordeel is dat je uren kan maken om hun fouten te herstellen. Maar ja das natuurlijk niet echt een voordeel of een leuke job.

Kan je de contractnummers niet uit de andere db halen? Dan is dat alvast geautomatiseerd.

Succes!

[RobIII]

marander schreef op woensdag 20 september 2006 @ 13:48:
Ja de nummering van facturen is natuurlijk heilig en moet opvolgend blijven. Maar verwijderen kan natuurlijk wel als de verwijderde nummers weer gebruikt worden. Let wel op dat als je een db hebt met een id erin zal de belastingdienst het nog steeds zien.

Alsof de belastingdienst low-level je DB in duikt om te kijken of in jouw (custom) applicatie de ID's wel kloppen. En wie zegt dat mijn software die oplopende/doorlopende ID's wel als dusdanig gebruikt?

[djluc]

Wat je eigenlijk eens moet doen is gewoon een dagje meewerken met de mensen die de software gebruiken. Uiteraard maken zij fouten, maar vanaf dat moment ga je wel heel goed inzien waarom die gemaakt worden. Ook merk je andere dingen die zo logisch lijken maar het toch niet zijn.

[marander]

RobIII schreef op woensdag 20 september 2006 @ 13:53:
[...]

Alsof de belastingdienst low-level je DB in duikt om te kijken of in jouw (custom) applicatie de ID's wel kloppen. En wie zegt dat mijn software die oplopende/doorlopende ID's wel als dusdanig gebruikt?

Hehe wacht maar af ...

Als je je facturen digitaal maakt ben je verplicht die dan ook digitaal te bewaren. Als de belasting dan wat van je wil, ben je verplicht om die db te overhandigen. En ze hebben een geweldig pakket om alle db's uit te lezen Is het niet opvolgend? Dan komen ze toch even verder bij je spitten, vinden ze leuk

[Janoz]

Je eigen interne ID's maken niks uit. Je factuurnummers zullen voor de belastingdienst echter wel oplopend moeten zijn en mogen geen gaten bevatten. Ook het hergebruik van verwijderde nummers is niet toegestaan omdat de chronologische volgorde dan niet meer klopt.

Zodra een factuurnummer toegekend is mag een factuur dus neit meer worden aangepast of verwijderd.

[BikkelZ]

Hoe zit het precies met die creditnota's? Zou ik dan alle producten die op die factuur voorkomen met een negatief bedrag op een factuur met nieuw factuurnummer moeten zetten, daarna aangepast moeten worden zodat het wel goed staat, en dan weer gefactureerd worden?

Ik leid mijn factuurnummers af aan het hoogste factuurnummer, is dat 342 dan is het volgende factuurnummer 343, en als die weer in de database opgeslagen is dat het hoogste factuurnummer, etc. Zoiets met ID's doen is vragen om problemen, want de meeste (alle?) databases passen hun next index number niet aan als je de laatste regel verwijdert.

Het geautomatiseerd overzetten was een optie, maar had zoveel voeten in de aarde, dat ik voor relatief weinig contracten (+/- 30) eerst een CRM database met 100.000 contacten en bijbehorende bedrijven moest doorzoeken, zowel op tabel adres als contactpersoon, vervolgens of een nieuwe contactpersoon, of nieuwe contactpersoon en bedrijf, of met het reeds bestaande contactpersoonnummer in de database met bedrijven die gefactureerd moeten worden gaan kijken of die er al in staat. Natuurlijk moet de spelling van (bedrijfs-)namen precies correct zijn anders zit je alsnog met "Jansen BV" en "Jansen B.V." die toevalligerwijs een heer Jansen in dienst hebben en ook nog eens op dezelfde plaats zich bevinden.

Dan de nieuwe relatie die gefactureerd moet worden er bij zetten of juist de reeds bestaande pakken, vervolgens het contract wat al gebruikt werd hergebruiken of juist een nieuwe aanmaken, en vervolgens de bestelde producten vergelijken om te zorgen dat die onverhoopt niet dubbel zouden zijn. Ik denk dat er een tabelletje of acht in deze procedure voorbij kwamen die allemaal op de een of andere manier aan elkaar gekoppeld waren die gecontroleerd moesten worden en een insert id of een bestaand id weer mee moesten geven naar de volgende.

Je begrijpt, dit mochten ze dus lekker handmatig gaan doen, want volgens mijn voorzichtige schattingen moesten ze zo'n 14 jaar werken met beide softwarepakketten wilde deze investering van tijd zich terugbetalen in gewonnen tijd voor de betrokken medewerkers. Ben wel zo vriendelijk geweest om wat aanpassingen binnen het pakket te doen waardoor er snel en eenvoudig overgezet kon worden gezien de aard van de producten in de externe database van een website.

(zowel binnen het pakket zelf als via een website kunnen bestellingen etc. ingevoerd worden).

[ Voor 15% gewijzigd door BikkelZ op 20-09-2006 14:15 ]

[RobIII]

marander schreef op woensdag 20 september 2006 @ 14:02:
[...]


Hehe wacht maar af ...

Als je je facturen digitaal maakt ben je verplicht die dan ook digitaal te bewaren. Als de belasting dan wat van je wil, ben je verplicht om die db te overhandigen. En ze hebben een geweldig pakket om alle db's uit te lezen Is het niet opvolgend? Dan komen ze toch even verder bij je spitten, vinden ze leuk

Bron?
Dit lijkt me klinkklare onzin. Wat als ik mijn eigen binaire bestandsformaat gebruik? Of als ik ze opsla in 1 of andere exotische DB?

[BertS]

marander schreef op woensdag 20 september 2006 @ 14:02:
[...]


Hehe wacht maar af ...

Als je je facturen digitaal maakt ben je verplicht die dan ook digitaal te bewaren. Als de belasting dan wat van je wil, ben je verplicht om die db te overhandigen. En ze hebben een geweldig pakket om alle db's uit te lezen Is het niet opvolgend? Dan komen ze toch even verder bij je spitten, vinden ze leuk

Klinkt leuk, maar wie zegt dat elk record in mijn factuur-tabel ook een factuurnummer heeft (gehad)? Als ik concept-facturen in diezelfde tabel heb staan, kan de missende ID net zo goed van een afgekeurde concept-factuur zijn, die dus ook gewoon verwijderd mag zijn...

[cowgirl]

BikkelZ schreef op woensdag 20 september 2006 @ 14:09:
Hoe zit het precies met die creditnota's? Zou ik dan alle producten die op die factuur voorkomen met een negatief bedrag op een factuur met nieuw factuurnummer moeten zetten, daarna aangepast moeten worden zodat het wel goed staat, en dan weer gefactureerd worden?

Je maakt een nieuwe faktuur met een nieuw nummer wat exact wegvalt tegen de bestaande faktuur. Eventueel worden artikelen ook weer terug in de voorraad geboekt en de foute faktuur en nieuwe kreditnota vallen tegen elkaar weg. Die kan je dus direkt allebei op 'betaald' zetten (ik neem tenminste aan dat je ook openstaande posten bijhoudt). Nu is er in feite niets meer gebeurd: de voorraad is weer terug op het oude niveau en het openstaand saldo bij de debiteur ook.
Nu kan dus de fout ingevoerde faktuur opnieuw ingevoerd worden, maar dan correct. Een derde faktuurnummer dus.

Om de gebruikers terwille te zijn zou je een functie kunnen maken 'deze faktuur krediteren' waarbij alle handelingen automatisch gebeuren. Het opnieuw correct invoeren zullen ze echter zelf moeten doen.

[djluc]

Om de gebruikers terwille te zijn zou je een functie kunnen maken 'deze faktuur krediteren' waarbij alle handelingen automatisch gebeuren. Het opnieuw correct invoeren zullen ze echter zelf moeten doen.

De gebruiker hoeft toch helemaal niets te weten van de achterliggende werking? Je maakt gewoon een knop edit factuur, zodra die edit verzonden wordt maak je een creditnota en een nieuwe factuur aan, niemand die er iets van merkt. Wel moet je zorgen dat je beide print zodat duidelijk wordt dat de oude niet meer correct is!

[Crazy D]

cowgirl schreef op woensdag 20 september 2006 @ 13:10:
Dat is op zich een hele goede optie. Een order kan dan nog gecorrigeerd worden voordat er daadwerkelijk gefactureerd wordt. Als je werkt met klanten aan de balie is dit wel lastiger omdat deze de factuur direct mee willen hebben.

Direct order/faktuur invoer laten starten, definitief afdrukken button op formulier, dat soort opties.

Vervallen is niet netjes. Ook de belastingdienst kan daar problemen over maken. De 'correcte' manier om een foute faktuur te laten vervallen is deze te krediteren en een nieuwe order te maken voor het juiste bedrag/ de juiste artikelen.

Dat weet ik niet, maar als dat zo is, kun je op het moment dat je de faktuur wilt laten vervallen, op de achtergrond gewoon een credit aanmaken.

Maar als het fouten zijn van het niveau 'per ongeluk een prijs ingevoerd terwijl dit gratis moest zijn' daar kan je gewoon niet tegen op programmeren. Bij een contractnummer kun je nog vragen of het de bedoeling is dat het contractnummer leeg is (dat hangt er vanaf hoeveel % van de fakturen een contractnummer moet hebben, je wordt ook niet blij als je 9 van de 10 keer extra op Nee moet klikken...).

[dingstje]

RobIII schreef op woensdag 20 september 2006 @ 14:24:
[...]

Bron?
Dit lijkt me klinkklare onzin. Wat als ik mijn eigen binaire bestandsformaat gebruik? Of als ik ze opsla in 1 of andere exotische DB?

Ik denk dat de belastingsadministratie wat software heeft waarmee ze de databases van alle commerciële boekhoudsoftware kan inlezen. IIRC moet je je pakket laten goedkeuren door de belastingsadministratie als je deze commercieel wil gaan verdelen (dus niet als je een specifiek pakket maakt voor één klant). Je zal dan als ontwikkelaar waarschijnlijk een library moeten aanleveren die de specifieke informatie uitleest uit de database en teruggeeft in het formaat dat de software van de belastingsdienst gebruikt.

_{Disclaimer: zwaar giswerk ;-)}

[marander]

RobIII schreef op woensdag 20 september 2006 @ 14:24:
[...]

Bron?
Dit lijkt me klinkklare onzin. Wat als ik mijn eigen binaire bestandsformaat gebruik? Of als ik ze opsla in 1 of andere exotische DB?

Klopt, dat kan ook. Maar als je een commercieel pakket hebt en dat wil aansluiten op boekhouding en belastingaangifte moet je het conform belasting aanmaken met auditmogelijkheden.

Bron is de belastingdienst

Oh en BikkelZ, een creditfactuur heeft geen negatief bedrag want het is al een credit. Dus officieel geen minnetjes gebruiken. Het staat en klinkt atuurlijk raar, maar goed.

[BikkelZ]

OK, er gaat nog wel wat tijd in zitten om dit allemaal netjes aan te passen, maar aangezien alles wat verkocht is gemerkt is als gefactureerd, moet het mogelijk zijn om een creditnota te genereren en daarna de gefactureerde producten weer vrij te geven.

En dan mogen ze naar hartelust kloten en rommelen en prutsen, maar ik hoor die telefoon niet meer gaan

[Verwijderd]

dingstje schreef op woensdag 20 september 2006 @ 18:06:
IIRC moet je je pakket laten goedkeuren door de belastingsadministratie als je deze commercieel wil gaan verdelen (dus niet als je een specifiek pakket maakt voor één klant). Je zal dan als ontwikkelaar waarschijnlijk een library moeten aanleveren die de specifieke informatie uitleest uit de database en teruggeeft in het formaat dat de software van de belastingsdienst gebruikt.

Nee, dat klopt niet. Het is voldoende wanneer je rapportage van de financiele gegevens in een door de belastingdienst geaccepteerd formaat kunt aanleveren (kan dus ook gewoon op papier zijn). Zolang je die rapportage kunt aanleveren, hoeven ze nooit fysiek in jouw database te graven.

Ze zijn wel blij wanneer je ervoor zorgt dat er met je data opslag niet onmerkbaar gesjoemeld kan worden, zoals per boeking een versleutelde weergave van stuknummer, artikelnummer en prijs van zowel de huidige als de vorige boeking opslaan (daarmee worden gewijzigde of verwijderde records goed aantoonbaar), maar in Nederland is zoiets nog niet verplicht.

Ook het naadloos doornummeren van facturen is niet verplicht, zolang je maar kunt aantonen dat er geen facturen 'weg' zijn. En zelfs het hergebruiken van een factuurnummer is toegestaan, maar dan moet je wel de historie van die factuur aan kunnen tonen.

In de praktijk is gewoon doornummeren, eerst een pro-forma (zonder factuurnummer), definitief factuurnummer bij afslaan, en een creditnota en nieuwe nota bij correcties wel zo handig. Geeft een stuk minder vragende blikken bij de belastingdienst...

[ Voor 18% gewijzigd door Verwijderd op 25-09-2006 14:04 ]