Results 1 to 10 of 10

Thread: Factuur ontwerp - chronologie en concept facturen

  1. #1

    Factuur ontwerp - chronologie en concept facturen

    Hallo hallo,

    Zelf gebruik ik een facturatie programma (Acumulus) waarbij ik zelf de factuur datum kan bepalen. Het gevolg hiervan is dat opeenvolgende factuurnummers niet perse chronologisch hoeven te zijn. Factuurnummer 1 kan een later datum hebben dan factuurnummer 2.

    1) Is het juist om de gebruiker de eindgebruiker de factuurdatum te laten bepalen? Zelf denk ik dat dit namelijk door het systeem zelf moet gebeuren.

    2) Moet er chronologie zijn tussen factuurnummers en datums.

    Op stackoverflow las ik een stukje over concept facturen en dat dit niet handig is om te doen. Met als voornaamste argument dat je in heel veel queries moet filteren op “concept” en dat dit foutgevoelig is. Volgens Aaronaught is een concept factuur geen factuur. En daar heeft ie gelijk in, maar dat is het hele idee achter concept. Op zich valt er wat voor te zeggen om twee tabellen te hebben één voor concept facturen en één voor facturen. Wat is jouw mening/ervaring met het concept items zoals concept factuur in dit geval?

    Bij voorbaat dank!

  2. #2
    https://www.belastingdienst.nl/wps/w.../factuureisen/

    Er zijn een paar eisen aan facturen. De nummering moet sluitend zijn, opvolgend zonder gaten, en de factuur moet de datum bevatten waarop deze is uitgereikt. Dat hoeft elkaar niet per se uit te sluiten. Als je het zo leest kan het best zijn dat je nu een factuur maakt, die je pas volgende week verstuurt. In dat geval staat de datum van volgende week op de factuur, maar zit hij qua nummer wel tussen die van vandaag.

    Het nadeel van concept-facturen is dat ze misschien wel nooit definitief worden. Het lijkt me dan ook niet handig om er al een factuurnummer aan te hangen zolang ze nog niet definitief zijn.

    We hebben zelf een soortgelijk probleem, waarin we een factuur in stapjes gaan opbouwen en er gedurende de dag nog producten aan toe kunnen voegen. Het plan dat we nu hebben is om wel dezelfde tabel te gebruiken, maar het factuurnummer pas op het laatst in te vullen. Dat factuurnummer is toch een aparte nummering (het interne id hoeft namelijk niet oplopend en sluitend te zijn, maar het fiscale factuurnummer wel). De afwezigheid van het factuurnummer betekent dat de factuur nog niet af is en nog aangepast kan worden. Het betekent ook dat de factuur nog niet afgedrukt mag worden.

    Dat lijkt op het concept-vinkje waar jij het over hebt, maar dat is niet helemaal waar. We weten namelijk zeker dat die factuur definitief gaat worden. Als je dat niet zeker weet, of als een factuur over een langere periode opgebouwd kan worden (bij ons is dat maximaal een dag), dan moet je waarschijnlijk ook in allerlei rapportages rekening gaan houden met die concept-facturen.

    Dat kan je natuurlijk oplossen met een view die je overal gebruikt, zodat je niet de condities ervoor overal moet uitschrijven, maar ik denk eerlijk gezegd dat het beter is om die facturen weg te houden uit de factuur-tabel.

    Overigens gebruiken wij daar de order-tabel voor. Op de order kan je aangeven wat de klant uiteindelijk wil hebben. Op basis van die order kan eventueel ook een pro-forma factuur uitgedraaid worden, waarop je dus kan zien hoe de factuur er ongeveer uit zou gaan zien als de order op dat moment uitgeleverd zou gaan worden.
    1+1=b

  3. #3
    Volgens mij heb je gelijk en hoeft de factuur datum niet gelijk te lopen met het volgnummer. Ik heb er nooit zo opgelet, maar ik ging er altijd vanuit dat het hoogste factuurnummer dat ik ontvang ook de meest recente was. Waarschijnlijk is dit in de praktijk ook vaak het geval, zeker als ontvanger van de facturen.

    Het nadeel van concept-facturen is dat ze misschien wel nooit definitief worden. Het lijkt me dan ook niet handig om er al een factuurnummer aan te hangen zolang ze nog niet definitief zijn.
    Nee dat is zeker niet handig. Ik was van plan om pas een factuurnummer toe te kennen als de factuur definitief is.

    het interne id hoeft namelijk niet oplopend en sluitend te zijn, maar het fiscale factuurnummer wel
    Helemaal mee eens. Ik ben van mening dat je nooit een key moet gebruiken voor een waarde uit de echte wereld, zoals bijvoorbeeld een factuurnummer maar ook niet voor een klantnummer.


    1) Wat is de reden dat er gekozen is om nog items te kunnen toevoegen gedurende de dag en bijvoorbeeld niet direct de definitieve/complete/verstuurbare factuur een dag later te maken?

    2) Wat doe je als een order geannuleerd wordt voordat de factuur verstuurd is (en dus nog geen factuurnummer heeft)?

    3) Wordt een factuur eind van de dag automatisch "verstuurbaar" gemaakt?

    Overigens gebruiken wij daar de order-tabel voor. Op de order kan je aangeven wat de klant uiteindelijk wil hebben. Op basis van die order kan eventueel ook een pro-forma factuur uitgedraaid worden, waarop je dus kan zien hoe de factuur er ongeveer uit zou gaan zien als de order op dat moment uitgeleverd zou gaan worden.
    In mijn ontwerp is de relatie order-factuur niet één op één. Een factuur kan voor meerdere orders zijn en één order kan over meerdere facturen verdeeld zijn. Ook komen mijn factuur items niet altijd uit een producten tabel, maar kan het ook bijvoorbeeld een (deel) facturering voor een project zijn of voor gewerkte uren. Om een pro-forma factuur op basis van een order te genereren gaat dan niet lukken.

  4. #4
    De pro-forma factuur wordt bij ons ook vrijwel niet gebruikt.

    In onze business (spullen in doosjes doen en opsturen naar klanten), komt er verder ook niet zoveel bij kijken.

    1) Van oudsher is het maken van een zending, het afboeken van de voorraad en het opstellen van de factuur een enkele stap.
    Maar tegenwoordig is ons logistieke proces gefragmenteerd is. Als je twee producten koopt, dan kan het gebeuren dat die uit twee verschillende magazijnen komen (of uit twee uithoeken van hetzelfde magazijn), en daarom afzonderlijk van elkaar verpakt en verzonden worden.
    Maar dat betekent dat je in die situatie nu twee facturen zal krijgen. Dat is natuurlijk verwarrend.

    Daarbij stoppen we de factuur het liefst bij de (laatste) verzendbevestiging. Dat betekent dus dat we bij het inpakken van een deel van een order ook een deel van de factuur opmaken. Dat deel is dan ook daadwerkelijk ingepakt en verzonden en is dus definitief. En dat is dan ook direct het grote verschil met jouw situatie waarin je over een concept-factuur praat. Die van ons is geen concept, maar is alleen nog incompleet.

    2 en 3) Als de rest van de order geannuleerd zou worden, of om andere redenen niet verzonden zou worden, dan kunnen we alsnog de factuur zoals hij dan staat afronden en los e-mailen. De factuur wordt ook niet verzonden naar de klant totdat deze 'af' is en voorzien van een factuurnummer, en na die tijd mag hij ook niet meer worden aangepast, maar moet er een nieuwe factuur gemaakt worden.

    Als iets eenmaal verzonden is dan kan het ook niet geannuleerd worden. Het is dan eigenlijk een ander proces, waarin het verzonden product teruggestuurd wordt, en er een credit-factuur wordt gemaakt voor de eerder factuur.
    1+1=b

  5. #5
    bij een pro forma factuur (die geen factuur is) zie je vaak een ordernummer terug. Vaak worden ze gebruikt om bv een aanbod te doen en zit er een proforma factuur bij. Betaal je die krijg je (als het goed is) een definitieve factuur met een ander nummer (en nu is het wel een definitieve factuur). Op die factuur staat dan dat ie betaald is en een verwijzing naar de pro-forma.

    Ik heb dat paar keer aan de hand gehad met bestellingen waar ze alleen credit card ondersteunen (die ik geen heb). Om jou toch te kunnen leveren ontvang je de proforma. Ik gok dat die bedrijven dat zo doen omdat ze soms te maken hebben met grapjassen. In nl moet je de btw afdragen op de factuurdatum (al is dat voor de meesten in praktijk maandelijks of 3 maandelijks) en dat kan een dure grap worden als je nep debiteur niet betaald. Vervolgens terugvorderen van die btw op een niet inbare factuur is aan allerlei voorwaarden gebonden, vandaar dus de pro forma.

    Ik zou persoonlijk pro-forma facturen niet in de factuurtabel zetten, simpelweg omdat het geen facturen zijn.

    Het principe van facturen die nog geen factuur zijn (beetje zoals Jos beschrijft) wordt ook best veel gebruikt. Exact had dat bv jaren terug al in zijn dos versie van zijn project management software. Zij noemden dat proeffacturen. Alles stond al in de tabellen met een batchnummer maar zonder factuurnummers. Die werden gecontroleerd en als het correct was werd er een klap op gegeven en kregen ze via een proces een factuurnummer. Waren ze niet correct werd de hele batch verwijderd, deed je je correcties en startte het proces opnieuw.

  6. #6
    1) Van oudsher is het maken van een zending, het afboeken van de voorraad en het opstellen van de factuur een enkele stap.
    Maar tegenwoordig is ons logistieke proces gefragmenteerd is. Als je twee producten koopt, dan kan het gebeuren dat die uit twee verschillende magazijnen komen (of uit twee uithoeken van hetzelfde magazijn), en daarom afzonderlijk van elkaar verpakt en verzonden worden.
    Maar dat betekent dat je in die situatie nu twee facturen zal krijgen. Dat is natuurlijk verwarrend.

    Daarbij stoppen we de factuur het liefst bij de (laatste) verzendbevestiging. Dat betekent dus dat we bij het inpakken van een deel van een order ook een deel van de factuur opmaken. Dat deel is dan ook daadwerkelijk ingepakt en verzonden en is dus definitief. En dat is dan ook direct het grote verschil met jouw situatie waarin je over een concept-factuur praat. Die van ons is geen concept, maar is alleen nog incompleet.
    das inderdaad best verwarrend

    Heb dinsdag wasmachine / droger en wat accessoires en diensten besteld. Op de site ging alles feilloos in 1 proces en 1 order en 1 ideal betaling. Uiteindelijk ontving ik 3 facturen. Het verwarrende zit hem vooral in de manier waarop jullie de ideal betaling verwerken door verrekening op een van de facturen. Administratief sluit het allemaal keurig maar door de creditbedragen wordt het verwarrend.

  7. #7
    Jup. Ik had er misschien bij moeten zeggen dat die 'van oudsher' nog steeds geldt, en dat ik hoop om het beschreven proces ergens in het komende halfjaar definitief te maken.
    1+1=b

  8. #8
    Van oudsher is het maken van een zending, het afboeken van de voorraad en het opstellen van de factuur een enkele stap.
    Nu begrijp ik waarom

    Ik gok dat die bedrijven dat zo doen omdat ze soms te maken hebben met grapjassen...
    Het was de bedoeling dat mijn probleem kleiner wordt , niet groter

    De reden dat ik met concept facturen wilde werken, had niks te maken met het grapjassen probleem van Benno. Ik kan me voorstellen dat de eindgebruiker tijdens het opstellen van een factuur voor bijvoorbeeld gewerkte uren eerst nog wat navraag moet doen. Het is dan makkelijk om de factuur even te kunnen parkeren tot bijvoorbeeld de volgende dag.


    Ik neig er naar, na alles wat ik gelezen heb, om de factuur tabel alleen te vullen met daadwerkelijk facturen en niet met concept facturen. Waarschijnlijk laat ik het grapjassen probleem even liggen voor versie 2.0

  9. #9
    Ik neig er naar, na alles wat ik gelezen heb, om de factuur tabel alleen te vullen met daadwerkelijk facturen en niet met concept facturen. Waarschijnlijk laat ik het grapjassen probleem even liggen voor versie 2.0
    In jouw voorbeeld zou ik ze denk ik wel in factuurtabel zetten als factuurregels maar nog geen nummer geven.

    Maar aan de hand van wat je beschrijft vraag ik me af of je proces wel klopt. Als een factuur wordt gemaakt voor gewerkte uren dan hoort daar volgens mij een (of meerdere) getekende uren formulieren bij. Dus volgens mij mist er in jouw omschrijving een stap.

  10. #10
    In jouw voorbeeld zou ik ze denk ik wel in factuurtabel zetten als factuurregels maar nog geen nummer geven.
    Ik zou het zo kunnen maken dat concepten na een x-aantal dagen automatisch verwijderd worden. Toch lees ik op veel plekken dat de factuur tabel een soort heilige status heeft en dat je daar niet in moet rommelen.

    Mijn omschrijving is verre van compleet. De uren worden ook bijgehouden en gekoppeld aan een factuur item. Het was slechts bedoeld om aan te geven dat het voor kan komen dat een eindgebruiker een factuur niet direct kan afronden. Als je dan alleen kunt annuleren of opslaan heb je of onnodige veel facturen nodig of je moet opnieuw beginnen.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •