Is er iemand die mij dit mysterie kan verduidelijken. Ik snap namelijk nog steeds niet waar de fout is gemaakt.
Ik ben eruit
Op zich is de problematiek die hier optreed herkenbaar, werkt al sinds jaar en dag zo, en bij deze maar even beschreven, opdat een volgende er ook wat aan heeft:
Als je een Produktieorder maakt voor 1 Kg, moet je daarop geen 100 Kg gaan afboeken en opboeken, want je kostprijs zal 100x te hoog zijn.
Dit heeft alles te maken met "welke waarde moet worden toegekend aan de voorraad" en "welke waarde moet worden toegekend aan het uitval". Om even een voorbeeld te geven: stel je een P.O. hebt voor 100 Kg, en er komt 95 Kg output uit, moet die 5 Kg dan als "uitval" worden verwerkt, of vind je dat de kostprijs van de overige 95 Kg duurder moet worden. Als je voor het laatste kiest, heb je wat dat betreft dus nooit "uitval", maar, omdat de kostprijs per eenheid hoger wordt, heb je steeds andere marges in je verkoopstatistieken. Hoe je dit wenst, kun je in principe zelf regelen, inderdaad, door het achteraf aanpassen van de ordergrootte (zie ook de helptekst, daarmee geef je aan over hoeveel eenheden de kostprijs van de totale charge verdeeld moet worden).
Nb: Merk op dat ik hierboven bewust speek over "Kg", immers, bovenstaande is ontstaan vanuit de hoek "Mengrecepten".
Zouden we een produktieorder in één scherm gereedmelden, dus in één handeling én het grondstoffenverbruik registreren én de output opboeken, dan zou Profit vrij simpel in staat zijn om te zeggen "we willen financieel nooit uitval hebben, en dus moeten de totale kosten van alle afboekingen altijd worden toegekend aan de hoeveelheid opgeboekt produkt".
Helaas is het in praktijk echter niet zo simpel. Laten we als eerste eens beginnen met de "normale" situatie: we boeken eerst grondstoffen af, en gaan daarna pas opboeken:
Dit opboeken kan in meerdere etappes gebeuren. Dit, omdat het opboeken in praktijk meerdere dagen in beslag kan nemen, maar desnoods omdat de 100 Kg die geproduceerd is moet worden afgevuld in blikken van 5, 10 en 20 Kg. Reeds bij de 1e opboeking zal het systeem een kostprijs moeten toekennen aan het op te boeken eindprodukt, en tsja... als we niet in één scherm alles ineens boeken, dan weten we niet wat er verder nog geboekt gaat worden. Het enige wat we kunnen doen is ervanuitgaan dat als we een
order krijgen voor 100 Kg, we wel 100 Kg zullen gaan produceren. De kostprijs van de afgeboekte materialen zal vervolgens worden gedeeld op de Ordergrootte, en bepaalt op die wijze de prijs per eenheid.
Zijn de kosten van alle afboekingen + bewerkingen tezamen EUR 500,-, dan zal (eigenlijk nog vóórdat het opboeken begint) al vaststaan dat ieder op te boeken Kg EUR 5,- kost. Blijkt uiteindelijk (desnoods na meerdere dagen) dat er maar 95 Kg is opgeboekt en er niets meer volgt, dan zal op dat moment de resterende 5 Kg (á EUR 5,-) als Uitval worden gejournaliseerd.
Nu kan het best zo zijn dat de Produktieorder al helemaal gereed is; de gebruikers hebben op de Produktiebon ingevuld wat er is afgeboekt, en wat er is opgeboekt, en op een bedrijfsbureau wordt de Produktieorder opgeboekt. A.h.v. de Produktieorderprint kan de opboeker dus al zien dat er 2x20,3x10, 5x5 is opgeboekt (totaal derhalve 95 Kg) is opgeboekt. Na het afboeken van de grondstoffen, zal het grondstoffenverbruik expliciet moeten worden goedgekeurd alvorens men kan opboeken. Bij het goedkeuren van de Produktieorder bestaat de mogelijk om de ordergrootte aan te passen. Als dus vóóraf bekend is dat er 95 Kg uit is gekomen, kan de ordergrootte worden gewijzigd naar 95 kg. Gaan we daarna opboeken, dan zal nog steeds bij de 1e opboeking al een prijs per eenheid moeten worden berekend, echter, omdat we de ordergrootte hebben overschreven met 95 kg, zal de EUR 500,- nu worden verdeeld over 95 Kg output, met als resultaat een prijs van EUR 5,2632 per Kg.
Nb: Uitgangspunt is dan natuurlijk wel dat we ook 95 Kg gaan opboeken, immers, zouden we alsnog 100 Kg opboeken, dan hebben we 100 Kg tegen een te hoge prijs opgeboekt (en ontstaat er nog een produktiewinst).
Bij Assemblage Recepten is het inderdaad niet mogelijk om achteraf deze ordergrootte aan te passen!
Waarom niet kun je je afvragen. Mogelijk omdat dit niet nodig is, mogelijk omdat het te complex is, en mogelijk omdat het nergens op slaat (bijv. wat als je e.e.a. combineert met Serienummering). Hoe dan ook, het is niet mogelijk (maar, middels aanvullend maatwerk zullen we er vast wel weer een mouw aan weten te passen).
Omdat het bij een Produktieorder o.b.v. een Assemblage-Recept nooit is toegestaan de ordergrootte te kunnen overschrijven, ontstaat daar al snel de situatie dat als je een Produktieorder toevoegt voor 1 Verschijning, maar je gaat er 97x zoveel op afboeken, dat de kostprijs van die order dus 97x zo hoog wordt, verdeeld wordt over de ordergrootte, en daarmee de prijs per eenheid voor ieder outputitem dus ook 97x zo duur wordt.
Het effekt wordt nog eens versterkt door de situatie dat we (o.b.v. een parameter) toestaan om éérst gereed produkt op te kunnen boeken (omdat er een vrachtwagen klaar staat die dit mee moet nemen naar een klant), terwijl het grondstof verbruik nog niet eens bekend is. Omdat in zo'n situatie én de kostprijs én de totale output nog niet bekend zijn, kunnen we daar al helemaal niet vooraf "de werkelijke kostprijs" bepalen. Derhalve wordt in dat geval de output opgeboekt tegen een waarde van EUR 0,00, met Chargesoort "Prijs niet bekend". Dergelijke Voorraad mag wél worden geleverd, maar, de order waarop zo'n partij wordt geleverd kan niet worden gefaktureerd (immers, "kostprijs verkopen" kan niet worden bepaald). Zodra nu achteraf de grondstoffen worden geboekt, zal alsnog de kostprijs bekend worden, en wordt deze doorgerekend naar de voorraad én naar de reeds geleverde voorraad (waarna er
alsnog kan worden gefaktureerd).
Nb: Voorraad waarvan de prijs niet bekend is mag niet in Produktieorders worden ingestoken, omdat het te complex wordt om dát alles weer door te rekenen naar de halffabrikaten en eindprodukten die daar uit rollen.
Jullie gebruiken én Assemblage Recepten én dit "Opboeken voordat het grondstoffenverbruik bekend is";
een kombinatie die per definitie niet zijn toegestaan bij de gratie dat je niet in staat bent de ordergrootte aan te passen bij Assemblage Recepten. D.w.z., als dit dit toepast om 97 stuks op te boeken op een order van 1. E.e.a. is toch toegestaan omdat bijv. bij het opboeken van stenen een 1e en 2e keus kan ontstaan. Wat dat betreft vraag ik me dus af hoe dit al die tijd ooit heeft kunnen werken.
PO 2011-12-14-0031 betreft een order die is uitgeschreven voor een hoeveelheid van 1 Verschijning.
Volgens het werkelijke verbruik heb je 98x zoveel materiaal verbruikt.
Tevens heb je 98x de norm opgeboekt.
Of beter geformuleerd: je hebt gewoon 98 stuks geproduceerd op een order van 1 stuks.
Als je naar 5-2-1-8-1 gaat, zie je dat de totale kostprijs van die batch op EUR 1.668,70 uitkomt.
Die prijs wordt gedeeld op 1 Verschijning van 25 Kg, ofwel EUR 66,7483 per Kg. Vervolgens heb je 98x25= 2450 Kg opgeboekt x 66,7483 = EUR 163.533,33 (met misschien nog een paar stuivers voor emballage erbij). Hoe dan ook, de bedragen die je in je schermprint terugvindt.
Nu schrijf je alleen dat de ene PO dit probleem wel heeft, en de ander niet? PO 201112070019 zou goed zijn.
PO 2011-12-07-0019 betreft eveneens een order voor 1 Verschijning, waarop je 97 geproduceerd hebt.
Het werkelijk verbruik in deze order is ongeveer 97x zoveel als de norm.
Nb: Merk op dat je je bewerkingen hier met een faktor 10x teveel hebt afgeboekt.
In de output heb je 97x de norm opgeboekt. De kostprijs van deze batch bedraagt EUR 2.309,8930 wat neer komt op EUR 92,3960 / Kg (zoals je bij 5-2-1-8-1 kunt zien), en het zou in de lijn der verwachting liggen dat hier de output ook zijn opgeboekt voor dit bedrag. Als ik echter naar de Voorraadmutaties kijk, is deze order opgeboekt met een waarde van EUR 936,29 !?!??
Ha... en nu komen we ergens...
In je Recepten maak je gebruik van rubriek "Opboeken tegen voorkalkulatorische kostprijs". Als je naar de helptekst van die rubriek gaat, wordt precies het proces "broodjes bakken" beschreven (hetgeen dus wel voor jullie zal zijn ontwikkeld). De helptekst aldaar beschrijft ook dat het doel van die rubriek is, om te voorkomen dat er in de situatie "Opboeken nog voordat het grondstoffen verbruik bekend is" voorraad wordt opgeboekt met een waarde EUR 0,00 (Prijs niet bekend), omdat je daar bijna niets mee kunt.
De helptekst beschrijft ook dat er eerst broodjes gebakken moeten worden, dit vermalen moet worden tot paneermeel, en dat daarna de paneermeel wordt afgezakt. Het probleem wat ontstaat is dat om af te kunnen zakken, we eerst moeten weten hoeveel paneermeel er verbruikt is, en we dat pas weten als de hele order (na een paar dagen) klaar is. Ofwel, jullie konden niets met de tegen 0,00 opgeboekte voorraad (immers, dat mag je niet in een Produktieorder inzetten), en dus zal er maatwerk zijn ontwikkeld om in zo'n situatie i.p.v. tegen 0,00 op te boeken, de voorraad tegen een voorgekalkuleerde prijs op te boeken.
De eerder genoemde EUR 936,29 is dan ook gelijk aan 2425 Kg x 0,3861 (Effektieve Kostprijs v/h Artikel).
Mooi... en dan vermoed ik al waar dit naar toe gaat :-)
Als je naar het 1e helpscherm kijkt:
dan staat daar expliciet uitgelegd dat deze situatie alleen is ontwikkeld voor de situatie "opboeken zonder dat de kostprijs bekend is", ofwel, de situatie dat er anders tegen een prijs 0,00 zou worden opgeboekt; dat opboeken tegen 0,00 moest dus worden voorkomen !
Een theorie is dat jullie tot op heden altijd éérst hebben opgeboekt (en dan pas afboeken), in welk geval de prijs 0,00 zou zijn geworden en waarna dit maatwerk in werking trad die deze 0,00 prijs overrulede met de Effektieve Kostprijs v/h Artikel, maar nú zelf die procedure hebben gewijzigd naar "we gaan eerst afboeken, en dan pas opboeken". Immers, zou je eerst gaan afboeken (en goedkeuren) dan is de prijs per eenheid al bekend (weliswaar véél te hoog), treedt de situatie "prijs is niet bekend" niet op, is opboeken met prijs 0,00 nooit aan de orde, en wordt dus ook dit maatwerk niet geaktiveerd (omdat dat alleen in werking treedt bij de situatie "prijs = 0,00").
Als laatste nog eens kijken of we die theorie nog enigzins kunnen bewijzen:
Dit produkt is (zie Financiele Groep) gekoppeld aan Goederen in Bewerking rekening 70001. Als ik een Dagboek opvraag van deze Grootboekrekening (7-1-2-2-8-1), met daarbij een filter op het PO nummer, dan kun je zien dat:
op 7/12 het eindprodukt is opgeboekt,
tussen 7/12 en 12/12 materialen en bewerkingen zijn afgeboekt,
op 12/12 de PO is afgesloten, waarna het resultaat geboekt is.
Ofwel: deze order is inderdaad opgeboekt vóórdat het grondstoffenverbruik bekend was, zou dus opgeboekt worden tegen 0,00, en dus heeft "Opboeken o.b.v. Voorkalkulatie" ervoor gezorgd dat het nu is opgeboekt tegen de effektieve kostprijs.
Dan nu een van de orders die verkeerd is, bijv. order 2011.12.14.0031:
Ook hier via 7-1-2-2-8-1 een Dagboek van 70001 gedraaid met filter op PO nummer. In deze order heb je op 14/12 en 15/12 de materialen en bewerkingen afgeboekt, daarna is op 15/12 het grondstoffenverbruik goedgekeurd (kostprijs per eenheid is dan bekend, even los van het feit dat deze dan veel te hoog is a.g.v. het produceren van 98 stuks op een order van 1), en daarna heb je je output
opgeboekt. Hier is het maatwerk "Opboeken o.b.v. Voorkalkulatie" niet getriggerd, immers, er was al een prijs per eenheid bekend.
Toegegeven, het is maf dat we hier nu achter komen. Je zou haast gaan denken dat dit met een upgrade van doen heeft, maar ik heb hier zelden zo veel "foute" afzakorders voorbij zien komen.
Ik denk dat de eindkonklusie moet zijn dat jullie anders zijn gaan werken, en dat waar jullie voorheen eerst gingen opboeken en dan pas afboeken, jullie dat nu andersom doen.
Nb: Terzijde nog even de opmerking dat als e.e.a. als Mengrecept zou zijn ingericht, je volgens mij precies had kunnen doen wat je wilt, en er op zich ook geen noodzaak is waarom je voor het afvullen van paneermeel "assemblage recepten" nodig hebt. Wel kan ik me voorstellen dat er ooit voor Assemblage Recepten is gekozen "opdat je gebruik kon maken van Gedeeltelijk Gereedmelden", waarvan je inmiddels in een ander topic hebt aangegeven dat je dat niet meer gebruikt, maar ondertussen nog wel met allemaal Assemblage Recepten zit.
