Heart-Profit ERP

Scan Terminal scherm Afboeken Input P.O.

M.i.v. deze Releasenote is de werkwijze van het Scan Terminal scherm "Afboeken Input Produktieorder" (zie http://ha1.heartprofit.nl/profit/index.php?topic=18039.0) aangepast.

LET OP: Lees onderstaande aandachtig, i.v.m. gehanteerde omrekenmethoden die niet 100% de werkelijkheid nadoen, doch waarvan is gesteld dat deze verschillen "voor lief" worden genomen.

In de nieuwe versie zijn een aantal wijzigingen doorgevoerd:

a. hoeveelheid alternatief in mindering op oorspronkelijke behoefte

b. keuzebuttons voor omrekening o.b.v. gewicht danwel Voorraadeenheid

c. het "gepland verbruik alternatief" is komen te vervallen

Het eerste punt is waar het feitelijk om gaat. Stel dat we een Produktieorder hebben waarin 2000 Kg produkt A nodig is, en we verbruiken 1200 Kg van een alternatief, dan bleef de oorspronkelijke regel nog steeds op een behoefte van 2000 Kg staan. Het gevolg was dat zowel de Behoefterun alsmede "Raadplegen Artikel-/Verschijningen met VTV" v.w.b. produkt A een behoefte toonden van 2000 Kg, waar in werkelijkheid meer dan de helft al door een alternatief gedekt was.

Hoeveel we van produkt A minder hoeven in te zetten als we produkt B verbruiken hangt volledig van de situatie af, en, willen we dit goed doen, dan kunnen we hier een komplete subadministratie bij verzinnen, waarin uiteindelijk zoveel 'registratiewerk' gaat zitten, dat niemand dit gaat aangeven-/onderhouden. Derhalve is dan ook bewust gesteld dat we dit niet doen, dat we het simpel houden, en de verschillen voor lief nemen.

Om even een paar voorbeelden te geven waar het om gaat:

Stel we gaan paprika's in blokjes snijden. Volgens het Recept hebben we 1000 Kg paprika's nodig van een maat 70/90, maar in werkelijkheid verbruiken we paprika's van een maat 90/110. Hoewel de paprika's groter zijn, en per stuk méér zullen wegen, halen we vast ook méér blokjes uit een grotere paprika, en mogen we wellicht stellen dat we 1000 Kg maat 70/90 kunnen vervangen door 1000 Kg maat 90/110.

Nu maken we echter paprika-stoplichten. Hierbij gaan één rode, één groene en één gele paprika in een zakje. Als we nu 1000 stoplichten moeten maken, hebben we dus ook 1000 rode, groene en gele paprika's nodig. Stel dat een paprika maat 70/90 gemiddeld 175 gram weegt, en een paprika 90/110 gemiddeld 200 gram, dan mag duidelijk zijn dat we nu niet 175 Kg maat 70/90 kunnen vervangen door 175 Kg maat 90/110, immers we zouden te weinig hebben.

We kunnen vervolgens talloze voorbeelden verzinnen waarbij een omrekeningverhouding aan de orde is om om te rekenen van A naar B, afhankelijk van de situatie. We hebben hiervoor een heel ontwerp op de plank liggen, doch zoals gezegd, het vereist (te)veel registratiewerk om hier op een juiste wijze mee om te kunnen gaan. Als die moeite echter genomen wordt, gaat het ontwerp wel zover dat we bijvoorbeeld zouden kunnen aangeven hoeveel sap we uit een bepaald type sinaasappel halen, en met hoeveel sinasappels van een minder sappig type we dit moeten vervangen.

De hoeveelheid "Gepland verbruik Alternatief" zoals we dat in de oude situatie hadden opgenomen is komen te vervallen. Het doel hiervan was bij het scannen van een alternatief, de behoeftige hoeveelheid van het oorspronkelijk produkt werd omgerekend naar het alternatieve produkt, en dat dit vervolgens kon worden overschreven, maar vervolgens mocht er feitelijk niets mee gebeuren. Daarnaast wist de gebruiker op de vloer, bij het overstappen op een alternatief, niet hoeveel en hoelang er o.b.v. dat alternatief geproduceerd zou worden, en kon ze de rubriek feitelijk niet eens vullen. Per heden is deze rubriek verdwenen.

De nieuwe situatie:



In de nieuwe situatie houden we het (bewust) simpel. We staan de gebruiker toe om op 2 manieren om te rekenen:

a. Omrekenen o.b.v. gewicht

b. Omrekenen o.b.v. het aantal Voorraadeenheden

Omrekenen o.b.v. gewicht is altijd mogelijk, immers, ieder produkt laat zich omrekenen naar een aantal kilogram. Ga maar naar Raadplegen Voorraaditems, druk op F1, en zie wat het gewicht van het Voorraaditem is. Voor Artikelen met een Voorraadeenheid "KG" geldt dat de Werkelijke Inhoud reeds het gewicht bevat, voor Artikelen met een andere Voorraadeenheid geldt dat deze via het "Gewicht per Voorraadeenheid" (zie Artikelgegevens) naar kilogram kan worden omgerekend.

Omrekenen o.b.v. het aantal Voorraadeenheden is aan de orde als zowel het oorspronkelijke produkt (A) alsmede het alternatief (B) beide in een andere Voorraadeenheid dan KG staan geregistreerd, bijv. "ST". Indien dit niet het geval is, zal deze mogelijkheid niet als keuze worden opgenomen, blijft er vanzelf maar één omrekenmethode over (nl. o.b.v. gewicht), en wordt die keuze automatisch gemaakt, opdat de gebruiker zo snel mogelijk verder kan.

In de meestel gevallen zal naar verwachting zowel het gevraagde produkt (A) alsmede het alternatief (B) dezelfde Voorraadeenheid hebben, waardoor in de meeste gevallen altijd geldt dat 1A = 1B. Van een echt "omrekenen" is dan ook geen sprake.

Een voorbeeld:

In onderstaand voorbeeld maak ik 1000 fruitschalen. Op een fruitschaal ligt één bakje champignons van 500 gram.

Onderstaand VTV scherm toont dat we +1000 Fruitschalen FRT001 verwachten, dat we met de doosjes Champignons 500 gram (CHA500NL) met 1000 doosjes de min in gaan, en dat we 2400 doosjes Champignons van 250 gram uit spanje hebben (CHA250ES).

(http://www.heartprofit.com/www/transfer/graphics/forum/lovavdra081223001.png)

Via het Scan Terminal scherm Afboeken Input scannen we de regel waarop het gevraagde produkt CHA500NL staat. Vervolgens scannen we de barcode van de te verbruiken partij, de CHA250ES.

(http://www.heartprofit.com/www/transfer/graphics/forum/lotsstag081223001.png)

Vervolgens vraagt het systeem hoe we de doosjes van 500 gram willen omrekenen naar doosjes van 250 gram. De eerste button toont o.b.v. "KG", de 2e button o.b.v. "ST".

NB: Deze 2e optie is er bij de gratie dat zowel Artikel CHA500NL alsmede CHA250ES in "ST" gedefinieerd zijn. Waren beide artikelen in "KG", dan was deze 2e optie er niet geweest, bleef er maar één mogelijkheid over, en zou er geen vraag worden gesteld.

Het is nu aan de Gebruiker om aan te geven of er o.b.v. "KG" danwel o.b.v. "ST" moet worden omgerekend.

Als de gebruiker kiest voor "KG" dan zal er evenveel kilogram van het alternatief verbruikt moeten worden. We hebben 1000 doosjes van 500 gram nodig = 500 Kg in totaal, en zullen dit vervangen door 500 Kg van het alternatief. Het alternatief betreft doosjes van 250 gram, en dus hebben we 500 Kg / 250 gram = 2000 doosjes van 250 gram nodig. De gebruiker geeft dus aan dat er kwa gewicht 500 gram op de schaal moet, hetgeen zal impliceren dat er 2 doosjes per schaal verbruikt moeten worden.

Kiest de gebruiker voor "ST" dan zal er 1:1 worden vervangen. Er waren 1000 doosjes van 500 gram nodig (= 1000 stuks) en dat wordt vervangen door 1000 stuks doosjes van 250 gram. Per saldo zullen we dan maar 250 Kg in de P.O. verwerken.

(http://www.heartprofit.com/www/transfer/graphics/forum/lotsstag081223002.png)

Zodra we een keuze gemaakt hebben (in dit geval kies ik voor "KG") gaan we verder naar het 2e scherm. Aldaar de oude 3 keuzes voor "Hele partij", "Aantal Verschijningen" en "Aantal Eenheden", waarbij v.w.b. de keuzes "Aantal Verschijningen" en "Aantal Eenheden" is gesteld dat deze per heden default met 0 worden gevuld.

Met dat we nl. wéten dat we niet (altijd) 100% juist kunnen omrekenen, laten we het scherm ook niet meer (standaard) tonen welke hoeveelheid er afgeboekt moet worden. De gebruiker gebruikt het scherm als registratie van hetgeen ze daadwerkelijk verbruikt heeft, maar het systeem stelt het verbruik niet voor.

Wel wordt (zie rubriek "Nodig:") getoond hoeveel het systeem berekende, in dit geval de 2000 doosjes van 250 gram.

De pallet CHA250ES die we scanden bevatte 800 doosjes, en we verwerken in dit voorbeeld de hele partij.

Waar in de oude situatie de 1000 Kg CHA500NL behoeftig bleef, zal nu het verbruik van de CHA250ES in mindering worden gebracht op de oorspronkelijke regel. We verbruikten 800 doosjes van 250 gram, hetgeen overeenkomt met 200 Kg. Deze 200 Kg is gelijk aan 400 doosjes van 500 gram. Als we nu de Produktieorderregels bekijken, zien we dat aldaar het verbruik van 800 ST CHA250ES is opgenomen, en dat de oorspronkelijke behoefte aan 1000 ST CHA500NL is afgenomen tot 600 ST.

(http://www.heartprofit.com/www/transfer/graphics/forum/lopoabra081223001.png)

Ook Raadplegen Artikel-/Verschijngen met VTV is nu bijgewerkt m.b.t. het ingezette alternatief, en toont dat we 800 ST minder CHA250ES op voorraad hebben, en dat we 400 ST minder CHA500NL nodig hebben.

(http://www.heartprofit.com/www/transfer/graphics/forum/lovavdra081223002.png)

Het verbruik van het alternatief (de 800 ST CHA250ES) wordt bij zowel de "norm" als het "verbruik" opgeteld.

Let op:

Tabel LOPR is in Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=20988.0 uitgebreid met een veld PRAANTO waarin de oorspronkelijke waarde van veld PRAANT wordt bewaard. Het gaat hier om de oorspronkelijk behoeftige hoeveelheid van het gevraagde produkt. Ieder doosje van 250 gram welke als alternatief ingezet wordt, wordt in mindering gebracht op de hoeveelheid van het oorspronkelijk gevraagde produkt, waardoor de hoeveelheid "doosjes van 500 gram" naar mate de P.O. verstrijkt, steeds lager zal worden.

Veld LOPR->PRAANTO bevat de oorspronkelijk gevraagde hoeveelheid van 1000 doosjes, met als doel deze in Kostprijscalculatie analyses te kunnen gebruiken. Momenteel is hier geen toepassing voor binnen Profit welke gebruik maakt van calculaties o.b.v. dit veld; het veld is geïntroduceerd t.b.v. calculaties buiten Profit om.

Funktie	Omschrijving	Dtm.Vl.Wyz	Dtm.L.Wyz
LOTSSTAG	Afboeken Input	16-12-2008	22-12-2008

Voor de aardigheid en misschien verder begrip nog een aanvulling :

De reden dat dit is veranderd zoals omschreven, is gelegen in het feit dat de volledige real time verwerking met de Scanterminals in het meer bijzondere geval van deze produktieomgeving niet "aansloot" bij de verdere processen in het systeem. Het al gegeven voorbeeld betrof de "Behoefterun", en meer in consistentie met de omgeving waarvoor dit is ontwikkeld betreft dit het "Toekennen Grondstoffen". Let wel, in alle geval gaat het hier (mede) om het doodleuk inzetten van produkt B waar produkt A is gevraagd (input van de Produktieorder), en waarbij het systeem dit op voorhand niet weet.

Zoals dit wàs opgelost (en dat was al moeilijk genoeg) werd e.e.a. weer consistent gemaakt bij het Afsluiten van de Produktieorder. En dit mag werken als je bijvoorbeeld eens per dag inkoopt (Behoefterun) of de betreffende partijen en (andere !) produkten toekent aan de input van de Produktieorders (Toekennen Grondstoffen). Alleen ... dit gebeurt niet eens per dag, maar feitelijk continu. En dus, waar het scannen op zich weliswaar voor real time verwerking zorgde, was de interne administratieve afhandeling dit niet, en werd uitgesteld tot Afsluiten Produktieorder.

De funktionele werking mag nu als volgt worden gezien :

a. Er wordt ingekocht (op basis van een (verwachte) behoefte;
b. Produkt wordt toegekend aan de Produktieorders; dit mogen appels op sinaasappels zijn;
c. Door produktie worden partijen en/of produkten gekozen die niet behoeven te voldoen aan de registratie in de Produktieorder (zie b.); Dit betreft niets anders dan het scannen van een pallet produkt, daarmee aangevend "*dit* doen we, ook al moest het anders";
d. Gedurende de produktie kan net zo vaak van partij/produkt worden gewisseld als is gewenst volgens de methode beschreven onder c.
e. Parallel aan c. en d. treedt ook weer b. op, met gevolgen voor a.

Het is feitelijk punt e. waar het om gaat, waar aan de ene kant tijdens produktie iedere keer het beste wordt gedaan wat op dat moment aan de orde is, en waarbij veranderd produkt het oorsrponkelijke ook laat vrijvallen, waardoor dit opnieuw kan worden ingezet middels "Toekennen Grondstoffen". Het geheel is nu dus één grote interaktie van real time registraties, waarbij aan de ene kant bijvoorbeeld een inkoper continu monitort wat bijv. voor het komende uur het beste is kwa produkt toekenning, terwijl aan de andere kant vele produktielijnen dit weliswaar als advies hanteren, maar toch anders kunnen beslissen bijvoorbeeld op basis van de kwaliteit van het produkt. Deze kan te slecht zijn voor de betreffende klant, maar ook te goed.

Het geheel is nu volledig real time opgezet, met parallel daaraan de grootst denkbare flexibiliteit in produktie, en met daarnaast handhaving van de inzichten in voor- en nakalkulatie op diverse niveaus, met als eerste niveau de Produktieorder zoals die uit de Receptuur komt, het tweede niveau waarbij Toekennen Grondstoffen dit aanpast, en het derde niveau waarbij de produktieafdeling nog weer iets anders doet. De nakalkulatie betreft dan het verschil tussen hoeveelheid output en gebruikte input, waarbij "gebruikte input" van ieder van de 3 genoemde niveaus kan zijn, doch waarbij dit momenteel deels is gebaseerd op zelf te maken queries.
Merk nog op dat het grootste deel van de problematiek in deze - het omrekenen betreft van voorgekalkuleerde (Receptuur, niveau 1) appels naar gehanteerde sinaasappels op niveau 2 en 3.