Heart-Profit ERP
July 06, 2024, 02:51:17 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Uitval door leidingwerk tussen Menger en Afvullijn  (Read 1546 times)
0 Members and 0 Guests are viewing this topic.
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« on: August 22, 2019, 05:47:38 pm »

In topic http://ha1.heartprofit.nl/profit/index.php?topic=29345.0 is beschreven dat bij de Lokatiegegevens per Menger een Uitval kan worden geregistreerd; een hoeveelheid welke niet kan worden afgevuld omdat ze in het leidingwerk tussen de Menger en het Afvulstation achterblijft. Die Releasenote betreft enkel de registratie van die hoeveelheid, in dit topic gaan we verder in op het gebruik van dit uitval.

In onderstaand voorbeeld hebben we bij Produktiestation PTS91 aangegeven dat er standaard 300 (Liter) achterblijft in de leidingen:


Bij het Recept kunnen we vervolgens een Faktor instellen die op deze waarde wordt losgelaten; default staat deze faktor altijd op 1, maar in dit voorbeeld hebben we haar met 1,25 gevuld:


We gaan nu een Produktieorder toevoegen voor een produkt 502AD0020, en doen dit volgens een Recept waarvan de Receptgrootte op 8000 Liter staat. Dit produkt wordt geproduceerd op Produktiestation PTS91, zijnde een Menger waar 10000 Liter in past. Bij Produktiestation PTS91 staat aangegeven dat er 300 Liter uitval is, omdat deze hoeveelheid achterblijft in het leidingwerk vanaf de Menger naar de Afvullijn. Bij het Recept staat een faktor 1,25 ingevuld welke op deze 300 wordt losgelaten. Ofwel, zodra we een Produktieorder toevoegen waarbij we 1 "Kuip" produceren, dan zullen we 8000 L gaan produceren waarvan 1,25 x 300 L = 375 L niet zal kunnen worden afgevuld. Dit uitval (indien van toepassing) zal achter de omschrijving van het Produktiestation worden weergegeven:


Aan de grondstofbehoefte verandert er nu helemaal niets. We verwerken nog steeds dezelfde grondstoffen, welke (conform Recept) zouden moeten resulteren in een output van 8000 Liter eindprodukt. Het Recept kunnen we daarmee optimaliseren voor wat betreft het zo veel mogelijk kunnen inzetten van volle zakken grondstoffen, zodat we zo min mogelijk hoeven af te wegen. V.w.b. de Outputzijde van de Produktieorder weet Profit nu dat er van deze 8000 Liter, 375 Liter achter blijft in het leidingwerk tussen de Menger en de Afvullijn. Dit betreft een hoeveelheid welke niet zal kunnen worden afgevuld. Het Afvuladres van de Produktieorder zal dus geen 8000 Liter, maar 7625 Liter bedragen.

Nb: In bovenstaande schermprint zien we de output van de Produktieorder die over blikken van 20 liter is verdeeld omdat bij het Toevoegen van de P.O. is aangegeven dat "alles" in 20 liter blikken moet worden afgevuld. Er is een nieuw scherm in ontwikkeling welke dit scherm gaat vervangen door een scherm welke ons via een Listmover control toont welke behoefte er aan dit produkt is, in welke Verschijningsvorm (5 liter blikken, 20 liter blikken etc) en zelfs rekening houdt met de specifieke Emballagewensen van de klanten en de Labels die op de blikken geplakt moeten worden. Met dat scherm gaan we feitelijk de 'behoeftes' aan de verschillende kombinaties 'slepen' naar de Output van de Produktieorder. Ook in dát scherm zullen we niet meer dan 7625 Liter mogen slepen naar de Output, immers, meer kunnen we niet afvullen.
 

Produktieordergrootte:
Als we een Recept van 8000 Liter gaan produceren en we kunnen 375 Liter niet afvullen, dan kunnen we ons afvragen wat er nu boven onze Produktieorder als 'Produktieordergrootte' moet staan. Is dat de 8000 Liter waarop het grondstoffenverbruik gebaseerd is, of juist de 7625 Liter waarop de Output van de Produktieorder gebaseerd is?  Hierbij is om meerdere redenen gekozen om de ordergrootte te baseren op de verwachtte op te boeken hoeveelheid van de Produktieorder, ofwel, de hoeveelheid gekorrigeerd met het uitval welke niet afgevuld kan worden.

Kostprijs per L
Een van die redenen is dat de Kostprijs per Liter gereed produkt wordt bepaald door de kostprijs van de Batch (som van de kostprijs van afgeboekte materialen + bewerkingen) te delen door de Produktieordergrootte. Als nu de P.O. grootte 8000 Liter zou zijn, wordt de prijs per eenheid feitelijk te laag, en ontstaat er altijd financieel een uitval resultaat (immers, we boeken maar 7625 van de 8000 Liter op; financieel zou er steeds 375 Liter op uitval worden gejournaliseerd in plaats van deze hoeveelheid door te berekenen aan het gereed produkt). Natuurlijk zijn er situaties mogelijk dat als we de kostprijs pas 'aan het einde van de rit' bepalen (bijvoorbeeld indien een Produktieorder met een Status "Z" werkt) te bepalen hoeveel er daadwerkelijk geproduceerd is, maar, we moeten ook rekening houden met de standaard werkwijze, waarbij we 'vandaag' alvast een pallet willen opboeken (omdat een vrachtwagen er op zit te wachten), en we morgen pas de rest van de order afvullen (en dán dus ook pas bekend is hoeveel uitval er werkelijk is). Omdat de pallet die we 'vandaag' opboeken al een kostprijs toegekend moet krijgen, wordt de Literprijs gebaseerd op de hoeveelheid die we verwachten dat er opgeboekt zal worden, en dus moet deze hoeveelheid 375 Liter lager zijn.

Bijprodukten
Feitelijk is hiermee ook eenzelfde soort werkwijze gehanteerd als dat we bij Bijprodukten doen. stel dat we 1000 stenen produceren, en het Recept geeft aan dat hiervan gemiddeld 100 ST "2e keus" zijn, dan resulteert dit in een Produktieorder die voor 1000 stenen grondstoffen verbruikt, en waarvan de Output is gevuld met 900 ST daadwerkelijk produkt en 100 ST 2e keuze. Ook in deze situatie zal de Produktieorderheader 900 ST bevatten (de verwachtte op te boeken hoeveelheid). Alhier wordt de kostprijs bepaald door de som van de grondstoffen en bewerkingen (voor 1000 stenen), daar wordt de 'terugwinwaarde van de 2e keuze' op in mindering gebracht, en het restant zal worden gedeeld op de verwachtte 900 stenen die we produceren.

Bij dit Uitval a.g.v. hetgeen wat achterblijft in het leidingwerk van de Menger naar de Afvullijn doen we eigenlijk niet anders. Eigenlijk zouden we er zelfs voor kunnen kiezen om de hoeveelheid die in het leidingwerk achter blijft als een soort 'bijprodukt' te registreren, immers, zo'n leiding zal na het afvullen schoongemaakt moeten worden, en hetgeen in de leiding zit, zal er toch ergens weer uitkomen... Hier is nu echter niet voor gekozen, omdat de registratie hiervan meer tijd kost dan het oplevert, maar nog meer, omdat als we met Bijprodukten werken, we verplicht zijn om éérst de hoeveelheid 2e keuze op te boeken, alvorens we het daadwerkelijke produkt gaan gereedmelden. Dit heeft te maken met het feit dat de terugwinwaarde van dat bijprodukt van invloed is op de kostprijs van het te produceren produkt.

Statistieken en andere overzichten
Nóg een reden mag zijn dat we tal van rapportages hebben die rapporteren op het aantal eenheden zoals vermeld in de Produktieorder. Hierbij zullen we diverse rapportages met elkaar kunnen (willen) vergelijken. Bedenk dat als we aan de ene kant een statistiek draaien die aangeeft hoeveel Liter we van een bepaald produkt geproduceerd hebben en deze 8000 Liter zou tonen, we dit nooit kunnen matchen met het feit dat een ander overzicht aantoont dat er maar 7625 Liter de voorraad ingegaan is. Natuurlijk, met dit ene Recept in het achterhoofd kunnen we bedenken 'oh, dat is die 375 Liter', maar, met duizenden Produktieorders op jaarbasis, zou dit leiden tot een verschil van enkele tonnen in Liters. We kunnen moeilijk tegen de accountant zeggen 'nee hoor, die liters zijn niet van een vrachtwagen gevallen... die zijn gewoon in het leidingwerk achtergebleven'.


Niet overal:
Zoals ook in topic http://ha1.heartprofit.nl/profit/index.php?topic=29345.0 is genoemd, hebben we bij de ontwikkeling van dit maatwerk het toegestaan om dit alleen te ondervangen in die funktionaliteit die ook daadwerkelijk gebruikt wordt binnen dit ontwerp. Bepaalde systeemdelen zijn niet aangepast op dit type uitval.

Behoefterun
Zo is bekend dat bijv. Produktieorders altijd met de hand worden toegevoegd en nooit vanuit de Behoefterun worden gegenereerd. Daarmee is het (voor de klant voor wie e.e.a. ontwikkeld is) ook niet nodig om zo'n Behoefterun hierop aan te passen.
Aanpassingen in die hoek zijn vanzelfsprekend wel aan de orde als iemand wél met de Behoefterun werkt, immers, stel dat we 8000 L verkocht hebben, dan redden we het niet door 1 kuip van 8000 L te produceren, immers, daar komt slechts 7625 L uit wat we kunnen afvullen. Met andere woorden, we zullen in zo'n geval 2 batches moeten maken, wat impliceert dat we meer grondstoffen nodig hebben, en waarvoor we dus ook meer grondstoffen moeten inkopen. Hoewel de betreffende klant wél zijn grondstofbehoefte dekt via een Behoefterun, is aanpassing van de Behoefterun tóch niet aan de orde. Dit heeft ermee te maken dat de grondstofbehoefte via de Behoefterun wordt bepaald door de behoefte die bestaat op Produktieorders die al zijn toegevoegd, niet op basis van eindprodukten die verkocht zijn en waar nog geen Produktieorder voor is gemaakt.

Mengrecepten
Deze vorm van uitval is alleen van toepassing bij Mengrecepten, alwaar 'Afvullen' aan de orde is. Vanzelfsprekend kunnen we ook Assemblage Recepten maken om bijv. 1 blik van 20 Liter te produceren, maar, het Uitval a.g.v. het leidingwerk tussen de Menger en de Afvullijn werkt enkel bij Mengrecepten en niet bij (Dynamische) Assemblage Recepten.

Overigen
Om nog even een paar expliciete voorbeelden te geven van funktionaliteit welke hier niet op is aangepast:
  • Genereren Produktieorder vanuit een Verkooporder (-/Regel)
  • Annulerings Advies (= inverse Behoefterun)
  • Omvorm Opdrachten
  • Kompleet Gereedmelden Produktieorders (LOPOGM is niet toegestaan bij zgn. Dagsegment Recepten waarvoor we dit ontwikkelen)
  • Klantspecifieke Produktie Interfaces zoals Interface "Graanverwerking"
  • Genereren P.O. op basis van Keuringsgegevens, wat dat ook precies mag zijn...
  • Produktieorders die uit Inkooporders worden gegenereerd t.b.v. aanleveren materiaal i.g.v. Uitbesteding
  • Touchscreen P.O. o.b.v. Dagafsluiting
  • TouchScreen & Scanterminal Aanpassen Natuur-/Ouderdom
  • Artikel vervangen in (lopende) Produktieorders
  • Herberekenen P.O. op basis van een hoeveelheid grondstof; zal niet voorkomen bij zgn. Dagsegment Recepten omdat de Recepten hier vast staan met hun hoeveelheden

Met aanvullend maatwerk kan dit type uitval natuurlijk alsnog op dit soort plekken worden vervolmaakt.


Ingrijpen waar nodig:
Hoewel we (zie boven) de hoeveelheid op de Produktieorder verlagen met dit uitval, registreren we intern toch alle data bij de Produktieorderheader. Zo is bij de Produktieorder bekend dat de grondstofbehoefte is gebaseerd op een Recept van 8000 Liter, dat er 375 Liter uitval is, en dat er 7625 Liter output verwacht wordt. Met deze data kunnen we alsnog ingrijpen op alle plekken waar dit wenselijk is. Bedenk dat we bijvoorbeeld ervoor kunnen kiezen om de Produktieorder weer te geven als "8000 L - 375 L = 7625 Liter". Dat gezegd hebbende... laten we het maar meteen in praktijk brengen door zoiets in het eerder genoemde scherm aan te brengen:

Op deze manier zien we nu dat we een P.O. hebben gemaakt voor 8000 L, maar waarop we 7625 L eindprodukt verwachten te kunnen afvullen.

Naast plekken waar we 'informatief' iets meer willen tonen, zullen er ook af en toe funktionele aanpassingen benodigd zijn:

Herberekenen P.O. grootte
In de omgeving waarbinnen dit maatwerk ontwikkeld wordt is herberekening naar een nieuwe ordergrootte op zich niet aan de orde, wel kan een herberekening plaatsvinden om de P.O. feitelijk te 'vernieuwen' als er een nieuwe versie van het Recept ontstaat. Als we een order herberekenen gebeurt dit op basis van de oorspronkelijke hoeveelheid zoals deze in het Recept staat aangegeven; 8000 L dus, en niet de 7625 L die overblijft nadat het uitval meegerekend is.
Merk ook op dat we een Produktieorder kunnen herberekenen conform een ander Recept. Dit andere Recept kan weer een andere Uitval-Faktor hebben, en daarmee resulteren in een andere hoeveelheid uitval dan op de oorspronkelijke order aan de orde was. In onderstaand voorbeeld Herberekenen we de order naar een Recept voor batches tot maximaal 5000 Liter; dit Recept staat op 4800 L en heeft een Uitval-Faktor van 1.

Op de resulterende order geldt nu een niet-afvulbare-hoeveelheid van 300 Liter, zijnde de hoeveelheid zoals opgegeven bij de Menger (welke niet wijzigde door de herberekening) doch nu maar een faktor 1,00 i.p.v. 1,25, omdat het nieuwe Recept een faktor 1,00 bevat. In onze Produktieorder is de Input dus gebaseerd op 4800 Liter, en de output op 4500 Liter.



Verplaatsen naar andere Menger
Het Uitval waar we het hier over hebben betreft zoals gezegd een uitval welke ontstaat door een hoeveelheid die niet kan worden afgevuld omdat ze in het leidingwerk achterblijft tussen de Menger en de Afvullijn. Als we nu een Produktieorder verplaatsen naar een ander Produktiestation (lees: Menger) dan kan die andere Menger in theorie verder weg van (of juist dichterbij) de Afvullijn liggen. De lengte van het leidingwerk kan anders zijn, en derhalve kan de output van de Produktieorder óók wijzigen als de Produktieorder verplaatst wordt naar een andere menger.
Let op: Als bijvoorbeeld a.g.v. het verplaatsen van een order naar een andere Menger het niet-afvulbare-deel (het uitval) wijzigt (omdat het nieuwe Produktiestation verder weg, of juist dichterbij ligt), dan zal het Advuladvies van de Produktieorder hier niet automatisch op (kunnen) worden aangepast. Dit 'verplaatsen' zal in zo'n geval er toe leiden dat iemand het Afvuladvies van de Produktieorder moet herzien. Als dit optreedt, krijgt de Gebruiker daarvan een melding.

Berekening Soortelijke Massa
In hoeverre is nu dit Uitval van invloed op de berekening van de Soortelijke Massa?
Wel, het lijkt er op van "niet".
Het "waarom niet" heeft alles te maken met de wijze waarop deze Soortelijke Massa wordt berekend...
Met de Soortelijke Massa (ook wel Soortelijk Gewicht genoemd) registreren we hoeveel Kilogram 1 Liter weegt. Heel simpel beredeneerd zal dit impliceren dat als we 2000 Kg grondstoffen in een kuip gooien, en we hebben daarmee 1000 L eindprodukt geproduceerd, het er wel op neer zal komen dat 1 Liter eindprodukt 2 Kg weegt. Het Soortelijk Gewicht is dan 2 Kg / L.
Echter, zó zit de berekening van de Soortelijke Massa niet in elkaar... De berekening van de Soortelijke Massa (Hoofdmenu-1-1-1-8-7) telt alle kilogrammen uit  het Recept, en rekent per grondstof uit hoeveel Liters die grondstof zou impliceren conform de Soortelijke Massa van die grondstof. Vervolgens telt ze al deze afzonderelijke Kilogrammen bij elkaar op, en deelt dit door de som van het aantal berekende Liters. Het resultaat van die deling leidt tot de Soortelijke Massa van het Eindprodukt. Met andere woorden, stel dat we een Recept hebben welke we op 1000 L definiëren en hier 2000 Kg van één bepaald produkt ingooien waarvan de Soortelijke Massa op 1 Kg / L staat, dan zal de berekening 2000 Kg berekenen met een equivalent (conform de Soortelijke Massa van de grondstoffen) van 2000 L. Hieruit volgt dat de Soortelijke Massa van het eindprodukt óók op 1 Kg / L uitkomt.  De berekening van de Soortelijke Massa doet dus niets met de Recepgrootte! en daarmee *dus* óók niets met het niet-afvulbare deel van de Produktieorder output.

Maar ja... hoe weten we nu dat alle grondstoffen een korrekt Soortelijk Gewicht ingevuld hebben? Misschien heeft iemand wel vergeten om dat veld in te vullen, en staat ze nog op de defaultwaarde van 1 Kg / L. Onder andere om dat soort redenen is het kader boven de Funktie "Raadplegen-/Afboeken grondstoffen" enige tijd geleden uitgebreid met een aantal faktoren, waaronder een berekening van de Soortelijke Massa, maar dán een die zich juist wél baseert op het gewicht van de Input en het werkelijke aantal Liters output. Het verschil tussen dié manier van berekenen van de Soortelijke Massa en de Soortelijke Massa die bij het Artikel is ingevuld wordt weergegeven in de vorm van een Afwijkingspercentage. Als deze te hoog wordt kan dit er op duiden dat het Soortelijk Gewicht van een of meerdere grondstoffen niet korrekt is ingevuld. Vanzelfsprekend zit er ook al een verschil indien er méér of minder wordt afgevuld dan volgens de order gepland was.

Om in dat scherm zélf het soortelijk gewicht na te kunnen rekenen, is in dit kader nu óók de som van het gewicht van de grondstoffen opgenomen, alsmede de gedefiniëerde hoeveelheid uitval.

Ofwel, in dit voorbeeld hebben we in totaal 6.088,053 Kg grondstoffen verbruikt. De output van de Produktieorder betrof 4.400 Liter, maar, we gaan er vanuit dat er 300 Liter in het leidingwerk is achtergebleven *dus* zal er 4700 Liter geproduceerd zijn. Het soortelijk gewicht komt daarmee uit op 6.088,053 / 4700 = 1,295330 Kg/L.

Merk op dat we hier dus eigenlijk appels met peren aan het vergelijken zijn, immers, de waarde van de Soortelijke Massa van het Artikel is totaal niet gerelateerd aan de output van de order, waar de alhier berekende waarde dat wel is. En mét dat dat gebeurd, zullen we (t.o.v. de situatie waarin we géén Uitval registreerden wat in het leidingwerk achter blijft) wél met die niet-afvulbare-hoeveelheid rekening moeten houden, anders lopen deze faktoren nóg meer uit de pas.
Nb: Dat we hier geen appels met peren moeten vergelijken is weer een hele andere discussie.
Logged

Heart-Profit company ID : HA
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.081 seconds with 19 queries.