Offerte's

[blitzzartproductions]

Iemand een slim idee hoe je gemakkelijk van het standaard facturen record een Offerterecord kunt maken?

Ik hoor het graag

[Heckle]

is het normaal niet anders om

offerte naar factuur

 

Steven

[dudematters]

kijk eens naar custumcrm.nl

 

Het lijkt me ook dat je het beter andersom kan doen, maar je vraag is wel wat vaag.

Ik maak eruit op dat je van een bestaande factuur weer een nieuwe offerte wilt maken.

Daarbij zal je toch een beetje moeten uitleggen hoe je factuur is opgebouwd om daar een goed antwoord te kunnen geven.

[blitzzartproductions]

ik heb gewoon het standaard facturen template zeg maar. en dan wil ik daar aan een offerte toevoegen en idd is het dat je een offerte stuurt en daarna een factuur dus is mijn vraag hoe kan ik dit in dit template zonder al te veel poespas makkelijk maken?

[JeanWM]

Maak van de status een attribute, dan hoef je enkel de status aan te passen op het ogenblik dat de offerte een factuur wordt.

 

Dat kan door een checkbox, radio button of drop down te gebruiken, bv.

[Gem]

Ja juist Jean maar dit is niet de optimale werkwijze gezien je door het veranderen van offerte naar leveringsbon of faktuur eigenlijk de offerte doet verdwijnen.

Boekhoudkundig kan je hierdoor in de problemen komen omdat je de bewaartermijn van de offertes niet naleeft.

 

lees meer hier: http://www.dezaak.nl/renderer.do/menuId/62302/sf/62302/returnPage/62302/itemId/704407/realItemId/704407/pageId/381/instanceId/2176/

[JeanWM]

Boekhoudkundig kan je hierdoor in de problemen komen omdat je de bewaartermijn van de offertes niet naleeft.

 

 

Hmmm... niet helemaal.

 

Je kunt bewijzen dat je een procedure hebt die een offerte omzet in factuur.

Dat bewijst dat alle facturen omzet genererende offertes zijn van geboorte (als dat een nederlandstalige uitdukking is).

 

Vermits je de facturen bewaart, bewaar je automatisch ook de onderliggende offerte.

 

De niet omzet genererende offertes....die blijven offertes.

 

De fiscus zegt dat je die zaken moet bewaren, niet op welke manier je ze moet bewaren.

Ik noem mijn facturen "omzet genererende offertes".

 

Op het ogenblik dat de offerte een factuur wordt, halen we een "volgnummer voor factuur' op uit een "factuur opvolgingstable".

 

De factuurnummer volgorde zal niet dezelfde zijn als de offertes.

Vanaf dat ogenblik verandert de status van de offerte. Het wordt een factuur.

Die status wordt scriptmatig gededecteerd voor alle sorteringen, zoekfuncties, printopdrachten enz.

 

Vraag ik een lijst van offertes, dan zullen "reeds facturen" daar deel van uitmaken.

Vraag ik facturen op, dan zullen de "niet tot factuur omgevormde offertes' niet weergegeven worden.

 

De fiscus zegt dat je "het moet vastleggen", niet "hoe" je het moet doen.

 

Als je je procedure gedocumenteerd hebt, wat je zou moeten doen als je een database maakt, daar dient je data model en je database model voor, zit je goed.

Je offerte nummering heeft geen gaten en je factuur nummering heeft geen gaten.

[Ari]

Het gebeurt toch ook wel regelmatig dat een uitgebrachte offerte niet 1 op 1 als order wordt gemaakt. De klant wil bijvoorbeeld een bepaalde offerteregel niet of later geleverd hebben.

[JeanWM]

Het gebeurt toch ook wel regelmatig dat een uitgebrachte offerte niet 1 op 1 als order wordt gemaakt. De klant wil bijvoorbeeld een bepaalde offerteregel niet of later geleverd hebben.

 

Dan wordt de offerte toch aangepast ?

 

De offerte reflecteert alle afgesproken modaliteiten.

Het zijn die zaken, niet meer en niets minder, die je gaat aanrekenen aan de klant.

 

Mogelijke veranderingen/aanpassingen bewaar je in een offerte history.

De versie die door de klant wordt aanvaard wordt een factuur. Daar speelt versioning een rol.

 

Ik zie daar geen probleem, tenzij je zaken aan je klant aanrekent die niet op de offerte staan....

[Gem]

Hm Yes Jean, I follow you.

 

Eigenlijk werk ik ook op deze manier maar ik zat zo al te denken wat ik zou zeggen tegen de fiscus als de vraag van de offertes (bewaartermijn) op mij afgevuurd zou worden.

 

Ik werk met leveringsbonnen. Elke leveringsbon kan ook het gevolg zijn van een offerte (radio button offerte-leveringsbon).

Dus een offerte is heel vlug omgezet in leveringsbon. Alle offertes worden bewaard alsook alle leveringsbonnen. Een script zet na verloop van tijd alle leveringsbonnen (en dus niet de offertes) om naar een faktuur.

 

Concreet heb ik dan een faktuur bestaande uit een bundel leveringsbonnen maar ik kan niet meer nagaan of leveringsbon nr X voorheen een offerte was. Ik overweeg nu om een extra veld (boolean) aan te maken die dit bijhoudt.

 

Zou dit waterdicht zijn ?

[JeanWM]

Je gebruikt een tier 3 systeem en daar is niks mis mee.

 

Je begint met een offerte.

Die moet je verschillende keren aanpassen voor verschillende redenen.

 

Die aanpassingen kun je bijhouden in een history field. Indien nodig kun je die zelfs overzetten naar een related table.

Zo "registreer" je alle aanpassingen op offerte niveau.

 

Daaruit volgt een leveringsbon.

Het enige kritieke punt hier is dat de leveringsbon de werkelijkheid moet aantonen.

 

De leveringsbon wordt een factuur. Je rekent "de werkelijkheid" aan.

 

De kring is gesloten.

De laatste versie van de offerte heeft de goedkeuring van de kklant, terwijl je een history hebt van mogelijke veranderingen/aanpassingen.

 

Je hebt een leveringsbon die, of de hele werkelijkheid (lees offerte), of een deel ervan weergeeft.

Indien het een deel is, vind je dat terug in de history van de leveringsbon. Die related is aan de offerte.

 

De items van de leveringsbon(nen) worden aangerekend op een factuur. Die related is aan 1 of meerdere leveringsbon(nen), die related is/zijn aan offerte(s).

 

Vermits je een tier 3 systeem gebruikt is het best dat je een "versie" opvolging doet.

 

Als je nu via je database model kunt aantonen dat eenmaal een offerte leveringsbon wordt, dat je dan geen veranderingen meer kunt aanbrengen aan de versies van de offertes (lock via script oid), en je kunt aantonen dat eenmaal een leveringsbon een factuur werd, er geen veranderingen meer kunnen aangebracht worden aan de leveringsbon (lock via script oid) en dat eenmaal een factuur geprint werd er geen veranderingen meer kunnen aangebracht worden aan een factuur (lock via script oid) en dat hele process duidelijk gedocumenteerd is, zit je goed.

 

Elke verandering aan een factuur dient afgedekt te worden door een ofwel interne credit nota, of een credit nota aan de klant.

Denk erom dat credit notas een afzonderlijke nummering moeten volgen.

[Gem]

Jean, een creditnota is in opzet toch hetzelfde als een gewone factuur. Het verschil is dat het gefactureerde bedrag negatief is.

 

Men is vrij in de nummering van een creditnota. Aangezien het een gewone factuur is, worden creditfacturen meestal gewoon doorgenummerd.

Soms wordt er ook een aparte nummering gemaakt maar dit is echter niet nodig als er nauwelijks creditfacturen verstuurd worden.

 

Waarom verkiest jij een aparte nummering ?

[Rony Rabijns]

... een creditnota .... Waarom ... een aparte nummering ?

 

Omdat het vaak een apart verkoopdagboek is in een boekhouding.

[JeanWM]

Waarom verkiest jij een aparte nummering ?

 

Ervaring waarschijnlijk.

 

Als db developer weet ik dat een uitdrukking als: "dat zal maar weinig voorkomen", vroeg of laat eindigt in "het komt heel vaak voor".

 

En als creditnotas plots voor welke reden dan ook, meer voorkomen dan naar de goesting van je belasting controleur, heb je het zitten.

Dan moet je een afzonderlijk nummering systeem invoeren....of eindeloos in discussie gaan...

Eerste reden.

 

Een credit nota is inderdaad een "negatieve" factuur. Daar is niks mis mee.

Enkel, indien er BTW mee gemoeid is, moet die in je boekhouding op een andere rekening terecht komen.

Het is gemakkelijker om de oorsprong van die bedragen weer te vinden op die rekening. Ik zoek enkel in de crediet nota table met veel minder records dan in de factuur table met veel records.

Tweede reden

 

We hebben ook een module voor analytische boekhouding.

Een externe credit nota is geld dat een bedrijf "moet terug geven". Vermits dat dit enkel kan via een credit nota, is het dtabase technisch gemakkelijker om de gegevens te verzamelen uit een table die enkel daarvoor dient, ipv een sortering, extract, GTRR etc te doen.

Derde reden.

 

Na jaren heb ik geleerd dat als de fiscus je een keuze laat, je best die kiest waar er geen voorwaarde aan verbonden is.

"Dit is echter niet nodig als u nauwelijks creditfacturen verstuurt." Een "als" van de fiscus werkt bij mij als een rode lap....

Vierde reden

 

Zie Rony's post

Vijfde reden

[Gem]

fair enough !