[Alg] - Voorraadbeheer en real-time bruto-marge berekening.

[gvanh]

Voor een webwinkel die ik zelf aan het bouwen ben op basis van mijn eigen CMS, wil ik nu wat voorraadbeheer gaan inrichten. Daarbij heb ik het grootste deel van wat er - qua logisch proces - moet gaan gebeuren wel voor ogen. Het enige wat voor mij nog wat vaag is, is de berekening van de bruto-marge.

Bruto-marge is je verkoopprijs - inkoopprijs. Dat kan ik nog net aan. Alleen vraag ik me af hoe ik het beste wijzigingen in inkoop- en verkoopprijs kan verwerken. Insteek daarbij is dat je op ieder willkeurig moment voor iedere willekeurige verkoopperiode kan bekijken wat het behaalde bruto-resultaat is (dus verkoop - inkoop). Dus ook inzage per dag (of zelfs per uur), indien gewenst.

Met betrekking tot inkoopprijs eerst een simpel voorbeeld.

A. - Op 5 april boek ik in mijn voorraad 10 x product Q voor (inkoop) 5 euro per stuk.
B. - Op 7 april verkoop ik 8 x product Q voor een prijs van 10 euro per stuk.
C. - Op 12 april boek ik in mijn voorraad 20 x product Q voor (inkoop) 4 euro per stuk.
D. - Op 15 april verkoop ik 4 x product Q voor een prijs van 10 euro per stuk.

Het lijkt me dat je nu twee dingen kan doen om de marge van verkoop "D" te berekenen:
- FIFO: Je matcht de laatste 2 producten uit de batch van 5 april (marge per stuk = 5 euro), vervolgens match je 2 producten uit de batch van 12 april (marge per stuk = 6 euro). Totale marge is (2 x 5) + (2 x 6) = 22 euro.
- Gemiddelde inkoopprijs: Bij de inboeking van 12 april bereken je de nieuwe gemiddelde inkoopprijs voor alle producten die op dat moment in de voorraad zitten. In dit geval dus ((2 x 5) + (20 x 4)) / 22 = 4,09 euro. Marge van de verkoop op 15 april is dan 4 x (10 - 4,09) = 23,64.

Zijn bovenstaande methodes beide geaccepteerde methodes? Programmeertechnisch lijkt methode 2 me prettiger, omdat je dan met één inkoopprijs kan rekenen op het moment van een nieuwe order; de "ingewikkelde" berekeningen vallen dan op het moment van voorraad inboeken, de orderafhandeling is dan vrij eenvoudig. Bij de eerste methode (FIFO) is inboeken van nieuwe voorraad vrij eenvoudig (een rij met aantal en inkoopprijs), maar is de orderverwerking weer lastiger.

Iemand hiermee ervaring of wellicht tips, gedachten, etc.?

[flashin]

Ik zou het gewoon via het gemiddelde berekenen, of desnoods gewoon absoluut berekenen.
Dat moet ook niet indrukwekkend zijn, gewoon alle bestellingen & inkoop van die datum nalopen.

Hoe ziet je database model eruit? of ga je dat op basis van dit modelleren? FIFO is wel leuk, maar ik vind het een "onduidelijk" algoritme.

[dingstje]

Boekhoudkundig zijn er een aantal mogelijkheden. Elk bedrijf kan zelf zijn manier van voorraadwaardering van handelsgoederen kiezen, dus in je programma zou je die mogelijkheden dan ook moeten aantonen. Er hangen namelijk boekhoudkundige gevolgen vast aan de berekeningsmethode. Een bedrijf die vanuit boekhoudkundig standpunt een methode gekozen heeft zal die dus niet wijzigen omdat jouw softwarepakket dat niet aankan, maar zal een ander softwarepakket kiezen.

De drie methoden zijn gemiddelde prijs, FIFO, LIFO en individuele prijs. Dat laatste is natuurlijk enkel interessant in bepaalde gevallen waarbij de producten makkelijk individualiseerbaar zijn en daar ook een meerwaarde aan vasthangt. Dat zou je eventueel nog kunnen laten vallen... Maar je zal iig ook LIFO moeten implementeren.

[Edmin]

Mochten het generieke producten zijn, dan lijkt de gemiddelde prijs methode het meest handzaam. Echter, het hangt sterk af van het soort product dat je verkoopt. Is er echt sprake van een dagprijs of fluctueert de prijs trager? Bij een sterke schommeling in de dagprijs is het wellicht verstandiger om een andere methode te selecteren.

[Gomez12]

Idd wat dingstje zegt, in wezen maakt het niet uit wat je kiest zolang je het maar kan onderbouwen en er aan vast blijft houden.
Je kan niet eventjes halverwege het boekjaar zeggen dat je opeens een andere methode gaat gebruiken, dan krijg je boekhoudkundig eventjes een uitdaging

In de praktijk zie ik voornamelijk gemiddelde prijs gebruikt worden omdat het gewoon makkelijker te proggen is...

[mocean]

Je kan ook een vaste prijs zelf kiezen per boekjaar. Binnenkomende voorraad wordt dan ingeboekt als waarde op die prijs, dan is de waarde van je voorraad prijs x stuks. Verschillen van de werkelijke inkoopprijs en je eigen vaste prijs boek je dan op 'Prijsverschillen inkoop', dat is een verlies&winst rekening. Mocht er nou een flinke prijsschommeling zijn, dan pas jeje vaste prijs aan, en herwaardeer je je voorraad. Volgens mij is dit ook een bekende methode.

[Gomez12]

Ken de methode niet, maar ik kan me niet voorstellen dat een boekhouder / directie erg vrolijk wordt van een herwaardering van de voorraad gewoon eventjes halverwege het jaar...

Nog even daargelaten dat je in wezen als je zelf een prijs kiest gewoon je eigen voorraad zit te schatten. Lijkt me dat er aan het zelf kiezen wel enige regeltjes verbonden moeten zijn, zodat je niet vlak voor een overname eventjes je voorraad kan gaan herwaarderen...

Nogmaals, ik ken de methode niet, maar lijkt me extreem fraudegevoelig...

Moet je naar de bank om een hogere lening af te sluiten, herwaaringkje voor je bezoek, herwaarderingkje na je bezoek. Et voila, je hebt een hogere lening...

[gvanh]

Dank voor de reacties. Mooist zou inderdaad zijn om de drie gangbare methodes allemaal te ondersteunen. Dat vergt wel nogal wat flexibiliteit van het systeem. Met betrekking tot database-layout heb ik inderdaad nog geen definitieve invulling, dat wilde ik (mede) laten afhangen van de gekozen berekening voor marge.

Even "hardop denkend", en voortbordurend op wat ik al heb, kom ik tot de volgende DB indeling.

Product-tabel heb ik al en is (versimpeld):

code:

TABLE products (
  productID int(11) NOT NULL,
  price float NOT NULL default '0',
  currencyID int(11) NOT NULL default '0',
)

Tabellen voor orders zijn er ook al en zijn ongeveer zo (versimpeld):

code:

TABLE orders (
  orderID int(11) NOT NULL default '0',
  auth_userID int(11) NOT NULL default '0',
  default_currency_rate float NOT NULL default '0',
  order_currency_rate float NOT NULL default '0',
  amounttotal float NOT NULL default '0'
)

TABLE orderlines (
  productID int(11) NOT NULL default '0',
  quantity int(11) NOT NULL default '0',
  price float NOT NULL default '0',
  subtotal float NOT NULL default '0',
  discount float NOT NULL default '0',
  purchase_price float NOT NULL default '0' <---- HIER???
)

Tabel voor voorraad mutaties zou dan zoiets kunnen zijn:

code:

TABLE stock_mutations (
  mutationID int(11) NOT NULL default '0',
  mutation_date DATE,
  productID int(11) NOT NULL default '0', 
  quantity int(11) NOT NULL default '0',
  price float NOT NULL default '0'
)

In principe zou de laatste tabel voldoende moeten zijn om de bruto-marge te kunnen berekenen. Is het nu handig om de inkoopprijs (purchase_price?) al te berekenen op het moment dat de order wordt aangemaakt, zodat je bij rapportages alleen nog maar hoeft op te tellen, of is het handiger om de berekening te doen op het moment dat je de rapportage wil hebben?

Verder is de stock_mutations tabel nu zo opgebouwd dat je eigenlijk altijd de volledige tabel nodig hebt om berekeningen te kunnen uitvoeren. Je weet immers nooit vantevoren wanneer een ingekochte batch geen invloed meer heeft op de marge (ofwel, per wanneer de batch volledig verkocht is). Het wordt dan lastig om de tabel te archiveren of zo. In het theoretische geval dat het systeem 20 jaar in de lucht is, moet je dan ook altijd de volledige historie hebben om betrouwbaar bepaalde berekeningen te kunnen maken.

[gorgi_19]

Hoe ga je de marge berekenen van goederen die al wel verkocht zijn, maar nog niet op voorraad zijn?

[Gomez12]

Ik zou je tabel products niet zo noemen of gewoon een losse tabel prijzen maken. Prijzen en producten hebben gewoon een 1:n relatie

Ik zou in je orderlines ook gewoon de inkoop opnemen afhankelijk van de gekozen methode. Scheelt je een boel performance als iemand ooit eens de marge op regel niveau / bonniveau wil weten. Net zoiets als een productname die zou ik ook in orderlines zetten.

Orderlines moet je imho gewoon niet gaan normaliseren. Een orderregel is een vaste entiteit met vaste waardes. Een join met een btw-tabel is bijv qua normalisatie wel goed, maar je moet allerlei extra voorzieningen gaan treffen om te zorgen dat niemand je waardes in je btw-tabel aanpast. Dat beinvloed namelijk gelijk het bedrijfsresultaat in je app.

Sowieso vind ik je quantity's laag en inconsequent, maar ik kom dan ook uit een sector waar gewoon 200 schroeven in een doosje zitten en als er dan een pallet besteld wordt zijn dit er best veel.
En ga uberhaupt eens gewoon na welke velddefinities je wilt hanteren. Je products table kan niet zoveel product ids aan als je andere tabellen...

Prijzen zou ik nooit op float zetten, gewoon een decimal of indien mogelijk een currency veld maken, desnoods een int veld wat je in je app overal door 100 deelt. Float heeft de neiging om onprecies te zijn, en bij een optelling van alle prijzen van alle orderlines van een jaar kan dat verschil best groot worden...

Subtotal zou ik weer niet in mijn orderlines zetten. Als er later 1 regel verwijderd moet worden mag je alle regels van die order gaan herberekenen...

Total_amount in je orders tabel vind ik persoonlijk altijd riskant, ergens heb je in de loop der tijd 1 bugje zitten die zorgt dat deze niet helemaal goed bijgewerkt wordt en je gaat de bietenbrug op met je totaal-overzichten. Qua optimalisatie / performance kan ik het wel weer heel goed begrijpen maar gooi dan ook je totale inkoop erbij voor je marge berekeningen.

Currency is wmb gebonden aan een prijs en hoort dan ook bij de prijs in de orderlines erbij, op zich kan ik geen zinnige situatie voorstellen waarbij het binnen een bon gaat afwijken en het dus bij de orderlines moet, maar gewoon een inschatting van houd de dingen bij elkaar die bij elkaar horen.


Wat je opmerkingen betreft.
Wmb moeten standaard rapportages altijd zo simpel mogelijk zijn opgebouwd.
Bij een marge rapport over het afgelopen half jaar wens ik niet een half uur te moeten wachten omdat er nog vanalles berekend moet worden.
Bij een voorraadoverzicht / voorraadwaarde overzicht wens ik niet te wachten tot de data van 20 jaar terug opgehaald is, maak maar een hulptabel aan die 1x per jaar de totalen wegschrijft. Dan kan ik gewoon archiveren etc. Ik zie weinig toegevoegde waarde in het bewaren van 20 jaar oude data alleen omdat jouw progje er anders niet mee overweg kan.
Er is binnen een normaal bedrijf niemand die data van 20 jaar nog iets interesseert op regelniveau. Het is leuk voor de statistieken. Maar voor de rest echt niet imho...

[Gomez12]

gorgi_19 schreef op maandag 11 augustus 2008 @ 21:59:
Hoe ga je de marge berekenen van goederen die al wel verkocht zijn, maar nog niet op voorraad zijn?

Dat kan niet , je kan gewoon niets offreren/verkopen wat niet op voorraad is.

[terabyte]

Gomez12 schreef op maandag 11 augustus 2008 @ 22:04:
[...]
je kan gewoon niets offreren/verkopen wat niet op voorraad is.

aparte uitspraak...
Dus de bouwer van een jacht moet een jacht eerst bouwen voordat ie het kan verkopen?

[mocean]

Gomez12 schreef op maandag 11 augustus 2008 @ 20:32:
Ken de methode niet, maar ik kan me niet voorstellen dat een boekhouder / directie erg vrolijk wordt van een herwaardering van de voorraad gewoon eventjes halverwege het jaar...

Nog even daargelaten dat je in wezen als je zelf een prijs kiest gewoon je eigen voorraad zit te schatten. Lijkt me dat er aan het zelf kiezen wel enige regeltjes verbonden moeten zijn, zodat je niet vlak voor een overname eventjes je voorraad kan gaan herwaarderen...

Nogmaals, ik ken de methode niet, maar lijkt me extreem fraudegevoelig...

Moet je naar de bank om een hogere lening af te sluiten, herwaaringkje voor je bezoek, herwaarderingkje na je bezoek. Et voila, je hebt een hogere lening...

't is toch wel gebruikelijk, zie bijvoorbeeld: http://www.adfas.com/produkten/specs/inkoop.htm

Het systeem heet "Vaste verrekenprijs" en ik heb het zeker ooit geleerd zo bij Economie II

[joca]

Gomez12 schreef op maandag 11 augustus 2008 @ 22:04:
[...]

Dat kan niet , je kan gewoon niets offreren/verkopen wat niet op voorraad is.

Hmm, bijzonder. Veel (handels)ondernemingen werken met minimale voorraad, immers hoe verder je de voorraad terug in de keten kan duwen hoe beter. Voorraad kost geld (opslag, rente, risico incourant, etc..).
Ook 'nieuwe' producten worden vaak al verkocht voordat ze bestaan.

Marge op producten die niet op voorraad zijn kan je bijvoorbeeld berekenen op historische gegevens (laatste inkoopprijs, gem prijs etc) of je neemt hiervoor een in te vullen stelpost als er geen historische prijzen zijn.

Voor TS, ik weet niet precies voor welke branche je dit maakt, maar maak ook per inkoop een vaste post die je over de artikelen kunt verdelen voor bijvoorbeeld transport kosten. Er zijn artikelen waarbij de transportkosten aanzienlijk zijn in verhouding tot de waarde, je kan deze kosten dan in de kostprijs meenemen.

[leuk_he]

herwaardering van de voorraad is niet ongebruikelijk. Maar je moet wel alle herwarderernge bijhouden en rapporteren, anders kun je hele vreemde situaties krijgen.

Bruto marge zegt niet zo heel veel, meestal gebruik je de netto marge,

(verkoopprijs - BTW) - ( inkooprijs + oplslagen + vervoer -betalingtalings kortingen + opslagkosten )

Matchen op welke batch het slaat is financieel gezien niet interessant.

[joca]

mocean schreef op maandag 11 augustus 2008 @ 22:16:
[...]

't is toch wel gebruikelijk, zie bijvoorbeeld: http://www.adfas.com/produkten/specs/inkoop.htm

Het systeem heet "Vaste verrekenprijs" en ik heb het zeker ooit geleerd zo bij Economie II

Idd, dit kan handig zijn voor producten die je inkoopt per bepaalde eenheid en vervolgens laat bewerken. Denk bijvoorbeeld aan een een buis die je in 10 stukken laat snijden, je krijg vervolgens een factuur voor de buis en de stukken, ideaal, verreken deze prijzen en je hebt je inkoopprijs.
Echter heb je nog wat restanten over en deze laat je nog eens snijden, nu krijg je alleen een factuur voor de snijkosten, de buis had je immers al betaald. Wat is dan je inkoopprijs?

Ook kan je ervoor kiezen om voorraad te herwaarderen als deze verouderd/incourant raakt, zo voorkom je dat je ineens de volledige partij af moet schrijven.

Dit kan idd wat fraude gevoelig overkomen, maar geen geen enkele accountant zal een voorraad waarde accepteren die niet in verhouding staat tot de inkoop.

[Reptile209]

Gomez12 schreef op maandag 11 augustus 2008 @ 20:32:
[...]
Nog even daargelaten dat je in wezen als je zelf een prijs kiest gewoon je eigen voorraad zit te schatten. Lijkt me dat er aan het zelf kiezen wel enige regeltjes verbonden moeten zijn, zodat je niet vlak voor een overname eventjes je voorraad kan gaan herwaarderen...

Nogmaals, ik ken de methode niet, maar lijkt me extreem fraudegevoelig...

Moet je naar de bank om een hogere lening af te sluiten, herwaaringkje voor je bezoek, herwaarderingkje na je bezoek. Et voila, je hebt een hogere lening...

't Is met boekhouden nou net zo geregeld, dat je zo'n herwaardering niet even tijdelijk bij de buurman kan parkeren of in je zak kan steken. De post "herwaardering voorraad" komt netjes terug op je balans of in je V&W rekening, dus de bank ziet hem toch wel .
Ik vind het op zich wel een nette combinatie tussen gemak (rekenen met één prijs) en nauwkeurigheid (aan het einde van elke periode verreken je je administratieve voorraad weer met je herwaardering).

[Gomez12]

terabyte schreef op maandag 11 augustus 2008 @ 22:10:
[...]
aparte uitspraak...

joca schreef op maandag 11 augustus 2008 @ 22:24:
[...]
Hmm, bijzonder.

Sommige mensen hebben de smiley gemist...

In de huidige vorm zie ik geen mogelijkheid om een marge te bepalen als het niet op voorraad ligt. Dat het in de praktijk wel eens heel af en toe en incidenteel etc gebeurt daar kan ik ook niets aan doen...

joca schreef op maandag 11 augustus 2008 @ 22:31:
[...]
Ook kan je ervoor kiezen om voorraad te herwaarderen als deze verouderd/incourant raakt, zo voorkom je dat je ineens de volledige partij af moet schrijven.

Ik ken geen enkel systeem waarin je opeens een volledige partij af moet schrijven. Alle systemen die ik ken hebben methodes om voorraad gradueel af te schrijven. Dus om daar nou dit systeem voor te roemen?

Dit kan idd wat fraude gevoelig overkomen, maar geen geen enkele accountant zal een voorraad waarde accepteren die niet in verhouding staat tot de inkoop.

Zal vast wel zijn doordat ik geen boekhoudkundige kennis heb, maar als ik dit jaar product x waardeer op 1 euro. Ik koop er 200 van in. Verkoop er 100 in dit jaar. Boekhouding klopt 100%. Voorraadwaarde is 100 euro op 31 december. 1 juni herwaardeer ik dit product naar 2 euro want ik heb van de leverancier een fax gekregen dat het product nu 2 euro kost. Hele jaar verkoop ik er nul en koop ik er ook nul in. 31 december heb ik een voorraadstijging van 200% op dit product zonder inkoop... Lijkt mij raar, ik verwacht een afschrijving.

Voor de mensen die overtuigd zijn dat ik niet zomaar midden in het jaar een voorraadherwaardering mag doen op alleen een fax van een leverancier, zeg dan maar dat ik er eentje ingekocht heb en vanwege het prijsverschil tussen vaste prijs 1 euro en werkelijke inkoop 2 euro heb ik de voorraad geherwaardeerd ( het prijsverschil is nu toch groot genoeg )

[gorgi_19]

Gomez12 schreef op maandag 11 augustus 2008 @ 20:32:
Nog even daargelaten dat je in wezen als je zelf een prijs kiest gewoon je eigen voorraad zit te schatten. Lijkt me dat er aan het zelf kiezen wel enige regeltjes verbonden moeten zijn, zodat je niet vlak voor een overname eventjes je voorraad kan gaan herwaarderen...

Overname is makkelijk: dat is wat de gek er voor geeft. Winsten worden in deze gevallen meestal genormeerd en EBITDA / omzet keer multiplier genomen. Ook hier zijn vele ;modellen' voor.

Moet je naar de bank om een hogere lening af te sluiten, herwaaringkje voor je bezoek, herwaarderingkje na je bezoek. Et voila, je hebt een hogere lening...

Je current ratio verslechterd in ieder geval door deze actie. Buiten dit wordt er veelal ook gekeken naar jaarverslaggeving. Een langlopende lening om kortlopende activa te financieren is meestal ook niet een verstandige keuze, iets wat een bank ook zal opmerken.

joca schreef op maandag 11 augustus 2008 @ 22:31:
Idd, dit kan handig zijn voor producten die je inkoopt per bepaalde eenheid en vervolgens laat bewerken. Denk bijvoorbeeld aan een een buis die je in 10 stukken laat snijden, je krijg vervolgens een factuur voor de buis en de stukken, ideaal, verreken deze prijzen en je hebt je inkoopprijs.
Echter heb je nog wat restanten over en deze laat je nog eens snijden, nu krijg je alleen een factuur voor de snijkosten, de buis had je immers al betaald. Wat is dan je inkoopprijs?

Voorraad goederen is wat anders dan voorraad grondstoffen. Deze twee haal je door elkaar; strikt genomen ben je nu bezig met productie in plaats van handel.
VVP wordt vooral gebruikt voor inkopen waarin de inkoopwaarde van de producten (sterk) fluctueert over het jaar heen.

Gomez12 schreef op maandag 11 augustus 2008 @ 23:14:
In de huidige vorm zie ik geen mogelijkheid om een marge te bepalen als het niet op voorraad ligt. Dat het in de praktijk wel eens heel af en toe en incidenteel etc gebeurt daar kan ik ook niets aan doen...

Ik denk dat het vaker voorkomt dan je denkt. Verwacht je echt dat BOL.com alle producten op voorraad heeft? Ook bij bedrijven als Central Point zie je geregeld dat het niet op voorraad is; je kan het echter normaal bestellen.

Ik ken geen enkel systeem waarin je opeens een volledige partij af moet schrijven. Alle systemen die ik ken hebben methodes om voorraad gradueel af te schrijven. Dus om daar nou dit systeem voor te roemen?

Imho is dit idd een grensgeval; waar ligt een complete afwaardering voor bijvoorbeeld (water)schade of diefstal? Zie je wel terug in je voorraadgegevens (en afschrijving), maar heeft weinig te maken met je bruto-margebepaling

Zal vast wel zijn doordat ik geen boekhoudkundige kennis heb, maar als ik dit jaar product x waardeer op 1 euro. Ik koop er 200 van in. Verkoop er 100 in dit jaar. Boekhouding klopt 100%. Voorraadwaarde is 100 euro op 31 december. 1 juni herwaardeer ik dit product naar 2 euro want ik heb van de leverancier een fax gekregen dat het product nu 2 euro kost. Hele jaar verkoop ik er nul en koop ik er ook nul in. 31 december heb ik een voorraadstijging van 200% op dit product zonder inkoop... Lijkt mij raar, ik verwacht een afschrijving.

Voor de mensen die overtuigd zijn dat ik niet zomaar midden in het jaar een voorraadherwaardering mag doen op alleen een fax van een leverancier, zeg dan maar dat ik er eentje ingekocht heb en vanwege het prijsverschil tussen vaste prijs 1 euro en werkelijke inkoop 2 euro heb ik de voorraad geherwaardeerd ( het prijsverschil is nu toch groot genoeg )

Deze discussie kan eindeloos gevoerd worden: Het is helemaal afhankelijk van welk stelsel je kiest. De bekende als FIFO, LIFO en VVP zijn voorbij gekomen. Je hebt nog tig andere stelsel: ijzeren voorraadstelsel, Traas, Edward & Bells en zo zullen er nog tig zijn. De wetgever staat slechts enkele stelsels toe.

Buiten dit: als je nu een herwaardering doet van je voorraad, zal je dat terugzien bij je bruto-marge. Deze is zuiverder, maar je winst zal er weinig door veranderen door je post prijsverschillen.

Voor de topicstarter
Een model bepalen heeft volgens mij nog geen zin; eerst moet je bepalen wat je zelf precies wil hebben en welke stelsel je wilt ondersteunen en in hoeverre je deze wilt implementeren. Daarna kan je kijken naar hoe deze te implementeren.

[ Voor 18% gewijzigd door gorgi_19 op 12-08-2008 06:19 ]

[gorgi_19]

.

[ Voor 99% gewijzigd door gorgi_19 op 12-08-2008 06:07 ]

[gvanh]

Voor de topicstarter
Een model bepalen heeft volgens mij nog geen zin; eerst moet je bepalen wat je zelf precies wil hebben en welke stelsel je wilt ondersteunen en in hoeverre je deze wilt implementeren. Daarna kan je kijken naar hoe deze te implementeren.

Als ik bovenstaande zo lees, dan zou ik nu zeggen dat het inderdaad de moeite loont om LIFO, FIFO en gemiddelde te ondersteunen.

Voor de topicstarter
Een model bepalen heeft volgens mij nog geen zin; eerst moet je bepalen wat je zelf precies wil hebben en welke stelsel je wilt ondersteunen en in hoeverre je deze wilt implementeren. Daarna kan je kijken naar hoe deze te implementeren.

Dat kan niet , je kan gewoon niets offreren/verkopen wat niet op voorraad is.

Dat is inderdaad niet handig. In de implementatie zoals ik daarboven heb gemaakt, is daarmee inderdaad geen rekening gehouden. Maar hoe zou dat dan wel moeten? Maak je een tabel met de inkoopprijzen voor producten, met daarin een datum waarop de prijs is berekend? Bij aanmaken van product bepaal je dan de eerste inkoopprijs, die niet afhankelijk is van een inboeking in de voorraad. Vervolgens ga je voorraad inboeken en wordt op het moment van inboeken een nieuwe gemiddelde prijs berekend. Die wordt weggeschreven onder de nieuwe datum. Dat geeft voor het gemiddelde-systeem een nieuwe prijs die je bij een order kan gebruiken.

In het geval van LIFO/FIFO, wordt op het moment van order gekeken of er voorraad is en - zo nee - dan wordt de laatst berekende inkoopprijs genomen; zo ja - dan wordt de inkoopprijs berekend op basis van de voorraad-boekingen.

Subtotal zou ik weer niet in mijn orderlines zetten. Als er later 1 regel verwijderd moet worden mag je alle regels van die order gaan herberekenen...

Subtotaal is het subtotaal per orderline, dus 3 x product Q à EUR. 13,25 = 39,75. Gaat dus niet om het subtotaal voor de volledige bestelling. Die geeft een makkelijke ingang om via DB-query het totaal van een bestelling binnen te trekken.