|
Title: Produktie o.b.v. Dagafsluiting Post by: Wouter Rijnbende on September 27, 2010, 03:13:23 pm Produktie o.b.v. Dagafsluiting
Met ingang van heden is er een volledig nieuwe manier van produceren beschikbaar gekomen in Profit. Dit maatwerk betreft een samenspel tussen diverse schermen, waarbij de hele produktie feitelijk als black-box wordt beschouwd. Ze vereist een bijzondere werkwijze. Ze kan niet zomaar even worden geïmplementeerd, het is meer "je werkt op deze manier, of niet". Probleemstelling: Al eerder is gepoogd het produktiedeel in de AGF aan de praat te krijgen gebruikmakend van de normale wijze van produceren. Dit liep al snel fout door de talloze (halffabrikaat-) orders die aan de orde zijn, en die gereedgemeld moeten worden alvorens een volgende stap kan aanvangen danwel gereed kan worden gemeld. Een eenvoudig voorbeeld: Er zijn diverse eindprodukten (rauwkosten) waarin een produkt "Komkommer Bruinoise Gesneden 10 mm" in gebruikt wordt. Deze eindprodukten triggeren een behoefte aan een halffabrikaat "Komkommer Bruinoise Gesneden 10 mm". Om dit halffabrikaat te kunnen produceren, hebben we komkommers nodig, maar... die komkommers moeten eerst voorbewerkt worden om in het produktieproces te kunnen worden gebruikt. Schematisch gezien: "Komkommer -> Voorbewerken -> Bruinoise snijden 10 mm = Halffabrikaat -> Diverse eindprodukten". Neem voor dit voorbeeld eens aan dat bij iedere stap 10 Kg verlies optreedt. Als we 100 Kg bruinoise gesneden komkommer 10 mm nodig hebben, dan moeten we 110 Kg komkommers voorbewerken en hebben we 120 kg (bruut) komkommer nodig. De voorbewerkte komkommers hebben we echter niet alleen nodig om te verwerken in "Brunoise Gesneden Komkommer 10 mm", immers bedenk maar dat er naast "brunoise gesneden" ook nog andere snijmethoden zijn ("julienne gesneden", "stift gesneden"), dat we dat op verschillende diktes kunnen snijden, en dat we er bijv. ook nog blokken of plakken uit kunnen halen. En, dan hebben we het alleen nog maar over een "komkommer". Op zich nog niet zoveel 'raars', immers, bovenstaande wordt gewoon opgelost met eindprodukten, diverse halffabrikaten en grondstoffen, waarbij de Behoefterun wel bepaalt wat we precies nodig hebben... Ja, op zich klopt dat, en zou dat geen probleem hoeven op te leveren... De problematiek speelt zich vnl. af rond de hoeveelheid Produktieorders die uit bovenstaande (standaard) methode volgen, orders die allemaal gereed moeten worden gemeld, en eigenlijk nog vóórdat de volgende stap in behandeling wordt genomen. En dat, terwijl het veelal een soort continue proces is, immers, de man die moet voorbehandelen behandelt wel voor, zonder te weten voor welk eindprodukt dat precies gebeurt. Aan de orde van de dag zijn ook de talloze "mondelinge opdrachten" die er gedurende de dag nog bijkomen. Vanwege de zeer korte doorlooptijd, en de versheid van de produkten, staat de produktiechef continue in verbinding met de afdeling verkoop. Zodra er nog spoedbestellingen binnen komen, worden deze aan de produktiechef doorgegeven, die op zijn beurt even tegen de afdeling voorbewerking zegt: "ga nog even 10 kisten extra voorbewerken" en aan de snijafdeling: "er komt nog meer aan, snij dat maar brunoise 3 mm". Met name omwille van dit soort mondelinge opdrachten struikelt de normale produktiewijze, immers, er zijn op dat moment geen Produktieorders die verderop gereedgemeld kúnnen worden. Nb: Merk op dat als we in bovenstaand geval wél formele orders zouden willen aanmaken, de produktiechef eerst naar kantoor moet, nieuwe Produktieorders voor eindprodukten erin moet zetten, de Behoefterun moet draaien, Halffabrikaatorders moet genereren, deze moet printen, en de voorbewerkings- en snijafdeling van nieuwe produktieformulieren moet voorzien. Bij deze nieuwe produktiewijze gaan we stellen dat ieder Produktie-Magazijn (afdeling) 2 deuren heeft: door de ene deur worden de grondstoffen aangeleverd (= input), en door de andere deur verlaten de halffabrikaten-/eindprodukten de produktievloer (= output). Alles wat er verder aan bewerkingen of produktiestappen op die afdeling onderkent wordt, wordt gezien als een grote blackbox. Er worden wél Produktieopdrachten geprint voor alle onderkende halffabrikaten, maar deze hoeven niet gereed gemeld te worden ! :scratching: Het enige wat we doen is per Produktieafdeling registreren welke materialen we naar de afdeling verplaatst hebben (input) en wat we geproduceerd hebben (output). Per dag wordt hierbij de dag "afgesloten" en wordt de input gelinkt aan de output. Hoe werkt het ? Bedrijfsparameter De funktionaliteit horende bij deze werkwijze is opgehangen aan een Bedrijfsparameter "Produktie o.b.v. Dagafsluiting". Deze parameter dient op "Ja" te worden gezet om bepaalde funktionaliteit (schermen) te kunnen gebruiken. Let op: bij het produceren op deze wijze, is het de bedoeling dat dit ook op deze wijze gebeurt. Het systeem anticipeert er niet op dat er verschillende werkwijzen door elkaar gebruikt worden. Met het op Ja zetten van deze rubriek zal het niet zo zijn dat andere funktionaliteit (bijv. het handmatig gereedmelden van Produktieorders) niet meer uitgevoerd kan worden. Toch is het niet de bedoeling dat dat soort funktionaliteit gebruikt wordt, immers het kan/zal fout lopen. Beperk U dus tot de werkwijze zoals hier beschreven. (http://www.heartprofit.com/www/transfer/graphics/forum/lopappwy100927001.png) TOUCH SCREEN P.O. PLANNING 's Morgens, vroeg in de ochtend, wordt gepland wat er die dag geproduceerd moet worden. Hiertoe is een TouchScreen scherm ontwikkeld, waarop iedere afdeling zijn-/haar produkten te zien krijgt, en inzicht heeft in hoeveel er van welk produkt behoeftig is. Dit TouchScreen scherm baseert zich op de funktionaliteit "Resultaten VTV berekening op netwerk opslaan J/N", ontwikkeld t.b.v. het scherm "Raadplegen Artikel-/Verschijningen met VTV". Deze funktionaliteit kan vanuit de Artikelparameters worden geaktiveerd: (http://www.heartprofit.com/www/transfer/graphics/forum/lopaarwy100927001.png) Uitgangspunt hierbij is dat er een PC continue wordt ingezet voor niets anders dan VTV berekeningen. Zodra de VTV van een Artikel in het systeem wijzigt (omdat het produkt ergens verkocht is, ingekocht is, de voorraad gemuteerd is etc.) zal automatisch een nieuwe VTV berekening worden getriggerd. Nadat deze VTV berekend is, worden de resultaten van deze VTV berekening opgeslagen op het netwerk. Op deze wijze kunnen alle werkstations in het netwerk beschikken over aktuele VTV gegevens, zonder daar zelf iets voor te hoeven berekenen (dat is nl. al gebeurd). Met de eerst volgende parameter kan worden aangegeven hoeveel dagen vooruit de VTV berekend moet worden, en dient te worden opgeslagen. 10 tot 14 dagen vooruit is hier veelal méér dan genoeg. Terug naar het TouchScreen scherm: Het TouchScreen P.O. Planning bestaat uit 2 schermen. Op het 1e scherm kan de produktiechef een aantal instellingen doen m.b.t. het op het 2e scherm weer te geven VTV overzicht. (http://www.heartprofit.com/www/transfer/graphics/forum/lotspopl100927001.png) Links op het scherm worden de Artikelgroepen getoond waarvoor de produktiechef kan plannen. Via een Bedrijfsparameter (TouchScreen) kan worden aangegeven welke Artikelgroepen er in dit overzicht getoond moeten worden. Hiermee kan worden gerealiseerd dat u per te plannen afdeling één Artikelgroep opneemt om zodoende per afdeling alle Artikelen te zien die voor die afdeling gepland moeten worden. (http://www.heartprofit.com/www/transfer/graphics/forum/lopatswy100927001.png) Indien er niet specifiek een reeks Artikelgroepen wordt opgegeven, worden alle Artikelgroepen getoond. Geadviseerd wordt om toch zelf aan te geven voor welke Artikelgroepen er gepland moet worden, dit mede, omdat op deze wijze de volgorde kan worden aangegeven waarin de orders gepland moeten worden. Zo zal bijv. de planning voor de Snij-afdeling een behoefte kreëren aan voorbewerkte produkten, en zullen we eerst moeten plannen wat we gaan snijden alvorens we kunnen zien wat er voorbewerkt moet worden. Het is dan handiger dat de snijafdeling eerder in de lijst wordt getoond dan de voorbewerkingsafdeling. Rechts op het scherm treffen we nog een aantal instellingen aan: VTV Weergeven t/m Datum Op het 2e scherm (zie verderop) zullen de Artikelen worden getoond die aan de geselekteerde Artikelgroep zijn gekoppeld. Per Artikel-/Verschijning wordt daarbij de VTV weergegeven. Middels deze rubriek kan worden aangegeven t/m welke VTV datum die VTV berekend moet worden. Standaard is dit 1 dag vooruit, wat als effekt zal hebben dat het scherm ons toont wat we vandaag + morgen nodig hebben. Desgewenst kan de datum verder in de toekomst worden gezet, opdat we voor een groter tijdsbestek gaan plannen. Merk op dat deze datum nooit verder in de toekomst kan liggen dan het aantal dagen dat de VTV vooruit berekend (en opgeslagen) wordt. Bestelniveau respekteren Als het scherm 's morgens vroeg wordt opgestart, kan hieruit volgen dat er 20 stuks op voorraad liggen, en er 5 verkocht zijn, en het Bestelniveau op 60 staat. Deze gegevens impliceren dat we er 45 moeten produceren, immers 20-5 = 15 beschikbaar, welke we moeten aanvullen tot het Bestelniveau (60-15 = 45). Dit Bestelniveau betreft echter een waarde die voor de hele dag bestemd is. Als we dus later op de dag nogmaals zouden gaan kijken, moeten we niet nogmaals gaan aanvullen tot de 60, immers de hele ochtend zullen er al diverse leveringen kunnen hebben plaatsgevonden. Derhalve moeten we het Bestelniveau voor een planning later op de dag kunnen uitschakelen. Alleen behoeftige Artikelen Normaal gesproken zal deze parameter altijd aan staan. Als ze aan staat, worden alleen dié produkten getoond waar ook daadwerkelijk een behoefte voor bestaat. Produkten waar voldoende voorraad van aanwezig is, of waar geen voorraad van is maar welke ook niet verkocht zijn, worden dan niet in het overzicht getoond. Deze toggle is echter opgenomen om de produktiechef toch een e.o.a. Koninginnedagsalade op te kunnen nemen in de planning, zonder dat er op dat moment al bestellingen lopen voor dat produkt. Als de parameter wordt uitgeschakeld zullen alle Artikelen getoond worden. Herberekenen indien nodig Zoals eerder uitgelegd, anticipeert het bewaren van de VTV gegevens op het netwerk dat er een opstelling is waarbij er (minimaal) één PC continue wordt ingezet voor VTV berekeningen. In een eerdere versie moest dat overigens formeel een Batchprocessor zijn, tegenwoordig hoeft dat niet meer en volstaat ook een gewoon werkstation. Bij het berekenen en bewaren van de VTV gegevens anticiperen we er ook op dat het werkstation welke de VTV gegevens opvraagt, ze deze ter plekke herberekend in het geval dat ze konstateert dat de gegevens niet aktueel zijn. Hoewel het overzicht hier wel trager van wordt (immers, het werkstation gaat nu ook berekenen) kan op deze manier een netwerk van werkstations ontstaan waarbij ieder zijn steentje bijdraagt aan het zo aktueel mogelijk houden van de VTV gegevens; immers, iets wat door uw werkstation wordt berekend, hoeft niet meer opnieuw door de dedicated-VTV-bereken-PC te worden berekend. Default orders genereren Deze optie is meer voor onszelf opgenomen, omwille van testdoeleinden. Als enerzijds moeite gedaan is om per dag van de week netjes Bestelniveau's in te vullen, en anderzijds het systeem precies weet hoeveel er op voorraad ligt en behoeftig is in Verkooporders, dan is het systeem in staat om default voor te stellen hoeveel er geproduceerd moet worden. En, ervanuitgaande dat U niet meer wilt bestellen dat de aanvulling tot het Bestelniveau, volstaat "een druk op de knop" om alle behoeftig produkten om te zetten in orders... Willen we echter één specifiek produkt produceren, desnoods omdat we een testje willen maken, desnoods omdat dat ene produkt tussendoor geproduceerd moet worden, dan kunnen we middels deze toggle ervoor zorgen dat op het 2e scherm er default géén Produktieorder wordt gegenereerd. Alleen voor die produkten waarvan we dan expliciet aangeven dat ze geproduceerd moeten worden, zal een order worden gegenereerd. Linkerdeel Artikelnummer Indien we vooraf weten welk(e) Artikelen we willen gaan plannen, is het ook mogelijk om een linkerdeel van het te plannen Artikelnummer op te geven. Op deze wijze wordt het overzicht op het 2e scherm verkleind waardoor e.e.a. overzichterlijker wordt. Indien we vervolgens verwerken, verschijnt het 2e scherm, met daarop per Artikel-/Verschijning de VTV en hoe deze is opgebouwd. (http://www.heartprofit.com/www/transfer/graphics/forum/lotspopl100927003.png) Per Artikel-/Verschijning wordt er een regel getoond. Hierbij toont het systeem hoeveel er op voorraad ligt, hoeveel er verkocht is, wat er in produktie nodig is (input) danwel uit produktie staat te komen (output), of er nog resterende behoeftige gegevens bekend zijn, en hoeveel de uiteindelijke Verwachte Technische Voorraad zal zijn (per de datum zoals op het 1e scherm aangegeven). Die VTV wordt vervolgens afgezet tegen het Bestelniveau en resulteert in een te produceren hoeveelheid. De kolommen: Bestelniveau Bij de berekening van het Bestelniveau worden de Bestelparameters per dag v/d week gerespekteert. D.w.z., per dag van de week kan een ander Bestelniveau worden gedefinieerd. Herberekenen noodzakelijk Bij Artikel-/Verschijning 106061/BK500GR wordt een afbeelding van een rekenmachine getoond in de kolom 'HB'. 'HB' staat voor 'Herberekenen'. Op deze wijze wordt aangegeven dat de gegevens van deze kombinatie niet aktueel zijn, en dat deze eerst herberekend moeten worden. Merk op dat deze afbeelding hier alleen kan staan indien op het 1e scherm "Herberekenen indien nodig" met Nee werd gevuld. Immers, zo deze met Ja zijn gevuld, dan zouden de VTV gegevens ter plekke opnieuw berekend zijn. Aantal Bevat standaard de aanvulling van de VTV tot het Bestelniveau. De hoeveelheid kan handmatig nog worden overschreven. Aantal betreft een Aantal Verschijningen. Het is ook mogelijk dat er in plaats van een spinner met aantal, hier een foutmelding wordt weergegeven. Zo wordt bijvoorbeeld vooraf gekonstateerd dat er geen Recept aanwezig is en dat er helemaal geen Produktieorder toegevoegd kan worden voor een specifieke Artikel-/Verschijning. De meest voorkomende situatie zal echter de Verschijningsvorm ------- zijn, welke een behoefte ongeacht de Verschijning impliceert. Aangezien we niet ongeacht de Verschijning kunnen produceren, zullen we bij een van de overige Verschijningsvormen moeten aangeven hoe het produkt afgevuld moet worden. Order Een toggle button met de waarden ja (groen vinkje) en nee (rood kruis). Wordt default gevoed door de instelling "Default order genereren J/N" op het 1e scherm. Pas zodra deze button op Ja staat, zal de toets "Genereren Produktieorders" daadwerkelijk een Produktieorder genereren. NB: De toets is oorspronkelijk opgenomen om in situaties waarin er boerenkool verkocht is in de zomer, met één druk op de knop te kunnen zeggen "dat gaan we niet produceren" (zonder daarvoor eerst de spinner terug te zetten op een waarde 0). Met de toets "Produktieorders genereren" kunnen we vervolgens orders genereren v.w.b. de op dit scherm opgegeven hoeveelheden. Per Artikel-/Verschijning zal er één order worden gegenereerd; zouden we één produkt in 3 Verschijningsvormen produceren, dan krijgen we 3 orders (maar, let op, dit is alleen om technische reden, reedmelden van de orders doen we toch niet echt, zie verder...). In onderdelen op de Produktieorder Zoals al even genoemd, gaan we (per Produktieafdeling) alleen maar registreren hoeveel input er verbruikt is, en hoeveel output er opgeboekt is. Om dit achteraf met elkaar te kunnen matchen, worden alle produktiestappen die op dezelfde Produktieafdeling worden uitgevoerd, samengevoegd in één Produktieorder. (http://www.heartprofit.com/www/transfer/graphics/forum/loarwy100927001.png) Stel, we hebben een eindprodukt "Horeca Rauwkost", met een gelijknamig halffabrikaat. Bij het halffabrikaat kunnen we nu aangeven dat dit halffabrikaat niet als zodanig in een Produktieorder moet worden opgenomen, maar dat de onderdelen van dit produkt moeten worden opgenomen. En, bij die onderdelen (die in de Receptuur staan) kan ook weer worden aangegeven dat die in onderdelen moeten worden opgenomen, etc. Zodra de Produktieorder wordt toegevoegd, wordt deze op die manier uitgewerkt "tot op grondstofniveau". Echter, niet helemaal, want de parameter bevat nog "i.g.v. hetzelfde Produktie-Magazijn". Die toevoeging zorgt ervoor dat het uitwerken tot grondstofniveau enkel gebeurt zolang die grondstof (of halffabrikaat) nog toebehoort aan hetzelfde Produktiemagazijn, bijvoorbeeld de snijafdeling. Op deze manier krijgen we één produktieorder per afdeling, met daarbij de input voor die afdeling, en de output voor die afdeling. De snijafdeling heeft één order, en de afdeling voorbehandeling heeft ook één order (ongeacht of er nu gewassen, geschild, gehakt, in blokken snijden etc. aan de orde is: per afdeling één order met input-/output). Nb: Met Bewerkingen in de Receptuur wordt geen rekening gehouden. PRINTEN PRODUKTIE-DAGLIJSTEN In bovenstaande stap hebben we (per afdeling) orders gepland. Eerst zullen we bijv. de orders voor de snijafdeling gepland hebben, en op basis van de behoefte die daaruit volgt, zullen we de orders voor de Voorbewerkingsafdeling gepland hebben. De Produktieorders die hieruit volgen zijn (v.w.b. hetzelfde Produktiemagazijn) tot op grondstofniveau uitgewerkt. Maar ja... we kunnen alle halffabrikaten wel overslaan... maar op de werkvloer moet nog wel bekend zijn wat er geproduceerd moet worden! Via menupath 5-2-8-8-9 (let wel, ten tijde van dit schrijven) kan de funktie "Printen Produktie Daglijst o.b.v. Behoefterun in Excel" worden opgestart. (http://www.heartprofit.com/www/transfer/graphics/forum/lopodlex100927001.png) Deze print ziet a.h.w. de door U geplande Eindprodukten als Elementaire Behoeftes, genereert vervolgens een Besteladvies, en drukt vervolgens Produktieorders af o.b.v. de hoeveelheden die in het Besteladvies zouden komen te staan indien er wél formeel met halffabrikaten zou worden gewerkt. Op deze wijze kan er voor ieder in de Receptuur onderkend halffabrikaat tóch een opdracht worden verstrekt, zonder dat hiervoor formeel een Produktieorder in het systeem bestaat. De Produkieopdrachten zijn dus feitelijk "behoeftes" die gedekt moeten worden, en niet zo zeer "Produktieorders", immers die hoeven er niet te zijn. De Produktieopdrachten worden per Produktiestation uitgegeven, d.w.z., per halffabrikaat kan gewoon gedefinieerd worden op welk Produktiestation ze geproduceerd moet worden, opdat er specifiek voor dát Produktiestation een serie opdrachten kan worden geprint. Zo kan de "Snijafdeling" formeel bestaan uit: a. een grote-/kleine inpakmachine b. een blokmachine c. een mengmachine d. een grote-/kleine snijband waarbij een ieder van deze Produktiestations haar eigen opdrachten krijgt. De Produktie Daglijst wordt opgebouwd in Excel, waarbij de te produceren produkten per Produktiestation op een separaat Tabblad worden opgenomen. De meeste opdrachten zijn hierbij zo eenvoudig, dat we kunnen volstaan met één regelige opdrachten. (http://www.heartprofit.com/www/transfer/graphics/forum/lopodlex100927002.png) Als de man op de werkvloer ziet dat er 62,5 Kg komkommer brunoise gesneden 10 mm. moet worden, dan weet ze zelf wel dat dit moet gebeuren uit de voorbewerkte komkommers die op de snijafdeling zijn aangeleverd. Pas zodra er daadwerkelijk gemengd moet worden, zal bekend moeten worden gemaakt in welke verhouding er gemengd moet worden. De opdracht bevat dan een Receptje: (http://www.heartprofit.com/www/transfer/graphics/forum/lopodlex100927003.png) Uitgangspunt is dat op één afdeling maar één type opdracht toegepast wordt: dus óf eenregelige opdracht óf een receptje. Bij het betreffende Produktiestation kan specifiek t.b.v. deze Excelprint worden aangegeven hoe de opdracht moet worden afgedrukt: (http://www.heartprofit.com/www/transfer/graphics/forum/lolowy100927001.png) Naast wel/geen Recept weergeven (geen Recept impliceert één regelige opdracht), is er nog een 3e optie: "P". "P" impliceert dat er een Recept moet worden afgedrukt per Pagina. Hoewel er bij "Ja" ook een Recept wordt afgedrukt, zal bij "Ja" één A4-tje meerdere te produceren produkten kunnen bevatten. Dit, bijv. t.b.v. de mengafdeling die op een dag meerdere produkten moet mengen, en op deze manier meerdere orders op één blad afgedrukt krijgt. Bij een andere afdeling, bijv. de warme of koude keuken zullen ook Recepturen aan de orde zijn, maar daarbij kan worden aangegeven dat ieder te produceren produkt op een separate pagina moet worden afgedrukt. Op deze manier kunnen meerdere personen die op dezelfde afdeling aan het werk zijn de opdrachten makkelijker verdelen; ieder krijgt de pagina's mee van de produkten die hij-/zij moet gaan produceren. TOUCH SCREEN OVERBOEKEN VOORRAADITEMS We hebben nu Produktieorders gepland en "Produktieopdrachten geprint" voor de diverse afdelingen. Het daadwerkelijk produceren kan nu beginnen. Zoals uitgelegd, wordt iedere Produktieafdeling als een grote black-box gezien, waarbij slechts "de input" en "de output" wordt geregistreerd. "De output" betreft het gereedmelden van de produkten die geproduceerd zijn; daar komen we straks op terug. "De input" betreft de grondstoffen die naar de betreffende Produktievloer zijn verplaatst. Het TS Overboeken Voorraaditems bestaat uit 2 schermen. Op het eerste scherm geven we aan welk produkt we willen overboeken. De meest eenvoudige manier is om bovenin het scherm (rubriek Barkode) de Barkode van het te verplaatsen produkt te scannen. Afhankelijk van welke informatie er allemaal in die barkode zit, identificeren we daarmee zowel Artikel, Verschijningsvorm en het Chargenummer van de verplaatste voorraad. (http://www.heartprofit.com/www/transfer/graphics/forum/lotsobv2100927001.png) Omdat er niet altijd een etiket op de doos hoeft te zitten, danwel het voor kan komen dat het etiket niet gescand kan worden, is het ook mogelijk om handmatig naar het betreffende produkt te navigeren. Hiertoe is een Sidegrid control met een Keyboard control opgenomen. We kunnen het linkerdeel van de Artikelomschrijving invullen, waarna in het Sidegrid enkel nog de Artikelen getoond worden die overeenkomen met het linkerdeel van de omschrijving. Om onderscheid te maken tussen de diverse soorten komkommers (de normale bruut komkommers, de voorbewerkte komkommers etc.) wordt geadviseerd om de verschillende produkten ook te voorzien van een Selektiekriterium. Deze leiden op dit scherm tot de diverse Selektiekriteria buttons (tussen de Barkode en het Sidegrid control) en dienen als filter op de in het Sidegrid te tonen artikelen. Van ieder produkt in het Sidegrid waarvan voorraad aanwezig is (lees: er valt wat te verplaatsen) zal de regel in het groen worden weergegeven. Regels die rood zijn hoeven we net zo goed niet te selekteren, immers, er is toch geen voorraad van aanwezig, en er valt daarvan niets te verplaatsen. Indien we een regel gescand danwel geselekteerd hebben, kunnen we door naar het volgende scherm: (http://www.heartprofit.com/www/transfer/graphics/forum/lotsobv2100927002.png) In het midden worden hier de verschillende Voorraaditems getoond welke voldoen. Per Voorraaditem wordt één regel getoond. Boven in het scherm zijn twee soorten filters mogelijk: a. Lokatie van waaraf verplaatst wordt b. Verschijningsvormen Een keuze bij een van deze filters zal het overzicht met de Verschijningsvormen doen verkleinen. Uit dit voorbeeld blijkt het niet, maar stel dat we de komkommers in verschillende kisten hebben zitten, en we hebben iets overgeboekt wat in kisten van 24 stuks zit, kunnen we deze Verschijningsvorm selekteren, en worden alleen de kisten van 24 komkommers getoond. De Spinner "Aantal Verschijningen" is nu nog disabled. We kunnen deze pas invullen zodra aan het systeem bekend is gemaakt wat er precies verplaatst wordt. Hiertoe kunnen we een specifieke partij selekteren (button bij de opsomming van de Voorraaditems), maar het is ook mogelijk om én op Verschijningsvorm én op Lokatie te filteren; het systeem zal dan FIFO het opgegeven aantal Verschijningen van de geselekteerde lokatie afboeken. Nb: Merk op dat waar wordt toegestaan om produkten niet te scannen, het (dus) mogelijk is om verkeerde partijen te boeken. Stel dat we 10 stuks op voorraad hebben van Charge A en 10 stuks van Charge B, we vervolgens 10B rapen om over te boeken, maar dit niet kenbaar maken aan het systeem; we zeggen gewoon dat we er 10 overgeboekt hebben en laten het systeem de oudste charge overboeken... Administratief wordt 10A overgeboekt, maar in werkelijkheid liggen er nog 10 stuks van partij A op voorraad, mét mogelijk een barkode die partij A impliceert. Een ander zou dus nu partij A kunnen scannen, waarbij het systeem niet meer weet dat deze aanwezig is. De werkwijze wordt toegestaan op basis van de wetenschap dat e.e.a. hier zodanig is opgezet dat een produkt enkel de EAN codering van de Artikel-/Verschijning bevat, en niet het Chargenummer. Feitelijk, dezelfde wijze als dat u een potje pindakaas in de supermarkt koopt: de barkode heeft aan om welk produkt het gaat, maar identificeert niet de partij. Omdat we de computer niet vertellen welke partij we daadwerkelijk geleverd hebben, zal het systeem er zelf een mogen boeken, met als resultaat dat we ons moeten realiseren dat de traceability niet perfekt is. Onder in het scherm kan middels een button worden aangegeven naar welke Lokatie er verplaatst wordt. (http://www.heartprofit.com/www/transfer/graphics/forum/lolowy100927002.png) Let op: Het uitgangspunt bij Produceren o.b.v. Dagafsluiting is dat de input van ieder Produktie-Magazijn wordt geboekt op een Lokatie waarvan de Identifikatie gelijk is aan de eerste 2 letters van dat Produktie-Magazijn, aangevuld met '000'. Dus, PV000 voor de afdeling voorbehandeling, PS000 voor de snijafdeling etc. Het is de bedoeling dat bij al deze P_000 lokatie's bij de Lokatie wordt aangegeven dat deze in het TS Overboeken Voorraaditem getoond moet worden. Naast een serie buttons voor de Lokaties waarnaar verplaatst kan worden, kan de 1e button ook de waarde "terug" bevatten. Deze waarde ontstaat indien er een produkt wordt gescand op een van de Produktieafdelingen. Zodra een produkt wordt overgeboekt, wordt daarbij tevens opgeslagen vanaf welke Lokatie dit werd overgeboekt. Op die manier is het ook mogelijk om een produkt terug te boeken. Stel dat we 14 kisten overboeken naar de Snijafdeling, en we 4 kisten overhouden (met name weer vanwege de mondelinge opdrachten, waarbij aangegeven kan worden 'snij maar wat minder, en ga maar een ander produkt doen'), dan kunnen we deze weer terugboeken naar de lokatie waar ze vandaan kwamen. TOUCH SCREEN OPBOEKEN GEREED PRODUKT Waar de input aan de ene zijde is geboekt door simpelweg de Voorraad te verplaatsen naar de Produktievloer, gaan we aan de andere kant van het magazijn de output opboeken. Op de grens van de produktieruimte naar de plek waar de voorraad wordt opgeslagen, dient een TS scherm te hangen. Alle produkten die uit produktie komen dienen opgeboekt te worden d.m.v. scannen + opgaaf van het aantal geproduceerde Verschijningen. Op eenzelfde manier als bij het TS Overboeken Voorraaditems, dienen we ook hier op het 1e scherm aan te geven welk produkt we geproduceerd hebben. Ook hier kan dat óf d.m.v. het eindprodukt te scannen óf door handmatig te navigeren naar het betreffende produkt. Ook hier wordt geadviseerd om gebruik te maken van de Selektie Kriteria buttons, om te kunnen filteren op bijv. alleen de voorbewerkte produkten. (http://www.heartprofit.com/www/transfer/graphics/forum/lotspoop100927001.png) Waar een regel in het TS Overboeken Voorraaditem "groen" was zodra er voorraad aanwezig was, is de regel hier "blauw" in het geval dat er een Produktieorder werd gevonden. Indien we een keuze moeten maken tussen verschillende produkten, kan het feit dat een regel blauw is ons helpen, immers, dat is de versie waarvoor de produktiechef een order had gepland. (http://www.heartprofit.com/www/transfer/graphics/forum/lotspoop100927002.png) Op het 2e scherm worden boven in het scherm de Verschijningsvormen van het geselekteerde Artikel weergegeven. Indien er meerdere Verschijningsvormen zijn én de gebruiker niet reeds d.m.v. de gescande EAN code impliceerde om welke Artikel-/Verschijning het gaat, zal ze zelf moeten aangeven in welke Verschijning het produkt geproduceerd werd. Indien er reeds een Produktieorder gepland was voor dit produkt, zal op het scherm het Produktieordernummer en Chargenummer worden getoond. Maar... het dynamische is dat we geen Produktieorder hoéven te hebben. Ieder produkt wat geproduceerd is, dient te worden opgeboekt. Zodra er iets wordt opgeboekt waarvoor nog géén Produktieorder aanwezig is, zal er ter plekke een order worden aangemaakt. Hiermee is de produktie volledig dynamisch en kan deels vooraf worden gepland wat er geproduceerd moet worden en deels mondeling opdrachten worden verstrekt op de werkvloer. Hierdoor kan flexibel worden ingegrepen op spoedbestellingen van klanten, waarmee men kan volstaan met een simpel "produceer nog even xxx zakjes van produkt yyyy". TOUCH SCREEN VOORRAADITEM IN ONDERDELEN (TERUG) NAAR PRODUKTIE Stel dat we op de snijafdeling een Produktieorder hebben gepland voor een horeca rauwkost, waarin o.a. het produkt "Chinese Kool" is verwerkt. Uitgewerkt naar onderdelen impliceert dat dat aan het begin van de produktielijn "Chinese Kool" in kratten naar de produktievloer moeten worden gebracht, en dat deze kool gesneden moet worden. Om diverse redenen (geen tijd om te snijden, te kleine hoeveelheid, een partij die op moet) kan worden besloten om de Chinese Kool niet opnieuw te gaan snijden, maar om een reeds afgevuld eindprodukt uit de voorraad te halen, en terug te steken in produktie. Op zich klinkt dit eenvoudig, ware het niet dat de Produktieorders allemaal waren uitgewerkt tot op grondstofniveau, en er daarmee geen enkel Recept is die een behoefte heeft aan een Eindprodukt. Om hier kostprijs technisch toch juist mee overweg te kunnen gaan, zal het betreffende teruggeboekte produkt in onderdelen (grondstof component) moeten worden teruggeboekt naar de produktievloer. Let op: het produkt wordt enkel om technische redenen (om tijdens de Dagafsluiting de match met het verbruik (op grondstofniveau) te kunnen maken) in onderdelen teruggeboekt. In werkelijkheid zal dit natuurlijk nooit kunnen gebeuren. E.e.a. werkt dan ook slechts één niveau diep, en het uitgangspunt is ook dat er verder niets gebeurd met de teruggeboekte onderdelen (dan als verbruik afboeken tijdens de Dagafsluiting). Het is dan ook pertinent niet de bedoeling om aan de achterzijde zakjes chinese kool terug naar de produktievloer te boeken, om aan de inputkant ineens hele chinese kolen terug op voorraad te kunnen leggen (en die vervolgens weer te leveren aan een klant). Bij het terugboeken van een produkt in onderdelen wordt opnieuw het Recept uitgewerkt tot op grondstofniveau, en wederom "v.w.b. het Magazijn hetzelfde blijft". Zou de snijafdeling chinese kool eerst moeten voorbewerken, dan zal het terugboeken van verpakte gesneden chinese kool naar de snijafdeling resulteren in het opboeken van voorbewerkte chinese kool (= de grondstof van chinese kool voor de snijafdeling). Het is ook mogelijk om een produkt terug te boeken welke volgens de Receptuur wordt opgebouwd uit andere produkten. Stel dat er een roerbak-mix zou worden teruggeboekt naar de produktievloer, dan heeft dat als effekt dat de prei, de paprika, de uien etc. weer terug op voorraad geboekt worden. Omdat we ook rekening moeten houden met de situatie dat er handmatig een eindprodukt op voorraad gelegd wordt, en dié vervolgens naar de Produktievloer wordt teruggeboekt, wordt de kostprijs in alle gevallen volgens dezelfde wijze berekend. De waarde van het teruggeboekte eindprodukt wordt evenredig verdeeld over de grondstoffen, op basis van de hoeveelheid en de Effektieve Kostprijs. Ofwel, als een eindprodukt bestaat uit 60% A met een prijs van 0,35 en 40% B met een prijs van 0,85, en het eindprodukt heeft een waarde (om welke reden dan ook) van 0,70 dan zal deze als volgt worden verdeeld: 60A x 0,35 = 21,0 40B x 0,85 = 34,0 21,0 + 34,0 = 55,0 De kostprijs van A wordt nu (0,70 / 55,0) * 21,0 = 0,2673 De kostprijs van B wordt nu (0,70 / 55,0) * 34,0 = 0,4327 Tezamen zijn deze 2 waarden weer 0,70. Het scherm t.b.v. het terugboeken van een eindprodukt naar de Produktievloer is precies hetzelfde scherm als dat van Overboeken Voorraaditems. Wel wordt het door een separaat (autoriseerbaar) scherm getriggerd. Zodra dit overboek scherm wordt toegepast als "In onderdelen terug naar Produktievloer" kan de voorraad alleen maar worden teruggeboekt naar de '000' Lokatie van het Produktie-Magazijn van het betreffende Artikel. (http://www.heartprofit.com/www/transfer/graphics/forum/lotsmnvo100927001.png) DAGAFSLUITING Na een dag werken, dient als allerlaatste op de dag, de produktie te worden "afgesloten". Tijdens dit proces zal de benodigde input worden gematched met de naar produktie verplaatste voorraad. Hoewel in eerste instantie niet gepland, is deze funktionaliteit toch opgezet in de vorm van een TouchScreen scherm. Uitgangspunt is wel dat deze "op kantoor" wordt uitgevoerd (of beter: dat er ook een toetsenbord beschikbaar is). (http://www.heartprofit.com/www/transfer/graphics/forum/lotspoda100927001.png) Op het hoofdscherm van de Dagafsluiting worden de verschillende Produktieafdelingen weergegeven. Om deze afdelingen in de juiste volgorde te kunnen weergeven (eerst zal de voorbewerking afgesloten moeten worden, doordoor worden de prijzen van de voorbewerkte produkten bekend, daarna kan de snijafdeling worden afgesloten etc.) kan bij het Magazijn een volgnummer worden ingevuld. Middels dit volgnummer wordt bepaald in welke volgorde de Magazijnen hier op het scherm moeten worden weergegeven. (http://www.heartprofit.com/www/transfer/graphics/forum/lomawy100927001.png) Per Magazijn wordt aangegeven of er voorraad is verplaatst naar de betreffende Produktievloer, of er Produktieorders zijn opgeboekt, en indien beide Ja zijn, een button om de Dagafsluiting te draaien voor dat magazijn. Na verwerking wordt er een kontrole overzicht in Excelgegenereerd. Na beoordeling van die Excelsheet, kan besloten worden al dan niet te verwerken. (http://www.heartprofit.com/www/transfer/graphics/forum/lotspoda100927002.png) (http://www.heartprofit.com/www/transfer/graphics/forum/lotspoda100927003.png) Ieder van de afdelingen (voorbewerken, snijkeuken, koude keuken, warme keuken) wordt beschouwd als een afgerond stukje met eigen input en eigen output. Zodra de dag wordt afgesloten worden als eerste alle Produktieorders van dat Produktiemagazijn herberekend naar de daadwerkelijk geproduceerde hoeveelheid. Stel dat we minder komkommer hebben voorbewerkt, dan triggert dit ook een kleinere behoefte aan komkommers. Het hergenereren van de orders gebeurt bewust zo laat mogelijk in het proces, om de gebruiker zo lang mogelijk de tijd te geven eventuele wijzigingen in de Recepturen aan te brengen. In bovenstaand voorbeeld heb ik 120 Kg komkommer voorbewerkt. Volgens het Recept hebben we per Kg eindprodukt 2,5 komkommer nodig; voor 120 Kg zouden we dus 300 komkommers mogen verbruiken (zie kolom 'Behoefte'). In werkelijkheid hebben we 14 kisten van 24 komkomers (= 336 stuks) verplaatst naar de produktievloer (zie kolom 'Verbruik'). Kolom 'Index' wordt gevuld met de indexwaarde; 100% is norm, minder is lager dan de norm, meer is hoger dan de norm. Vervolgens nog 2 kolommen waarin het absolute verschil (36 komkommers) en het procentuele verschil (12%) wordt weergegeven. Als we akkoord gaan met bovenstaande, zal het erop neerkomen dat we 12% meer komkommers verbruikt hebben. Dit kan bijv. mogelijk zijn omdat de komkommers kleiner waren, we er grotere stukken vanaf hebben moeten snijden etc. Als we verwerken zal er in iedere Produktieorder waarin komkommers verbruikt zijn, 12% méér worden afgeboekt dan wat de norm was. Hiermee wordt het extra verbruik netjes verdeeld over alle produkten die er uit de betreffende grondstof geproduceerd zijn. Om niet ieder produkt te hoeven beoordelen in deze Excelsheet, kunnen we in het 1e scherm een 2 tal rubrieken opgeven. Percentage kontrole korrekt verbruik Alle afwijkingen die binnen 0% en deze marge vallen, zijn sowieso akkoord. Daarvan gaat U niet uitzoeken of ze kloppen. Deze regels zullen in het groen worden weergegeven. Regels die méér afwijken krijgen een ander kleurtje toegekend. Percentage maximale afwijking Dit betreft het percentage wat het verbruik maximaal mag afwijken. Zodra deze grens bereikt wordt, wordt de Dagafsluiting geblokkeerd; U kunt dan niet verder. Het is dan té voor de hand liggend dat er ergens een fout is gemaakt. Mogelijk is iemand vergeten de niet gebruikte voorraad terug te boeken, mogelijk is iemand vergeten om output op te boeken, mogelijk is het Recept verkeerd. Hoe dan ook, de kans is groot dat er iets mis is. En, aangezien 'verwerken' bepalend is voor de kostprijs van alle geproduceerde produkten, kunnen we maar beter eerst uitzoeken of alles korrekt is, alvorens straks alles met een verkeerde prijs op voorraad staat. Nb: Er is niet (en dat gaat w.s. ook niet gebeuren) voorzien in funktionaliteit om een Dagafsluitingsprocedure terug te draaien. Dit mag als té complex worden betiteld. Alvorens de Dagafsluiting te kunnen goedkeuren, volgt er nog een tussenliggend scherm met daarin een aantal mogelijke meldingen, waarmee het doorgaan kan worden afgekeurd. (http://www.heartprofit.com/www/transfer/graphics/forum/lotspoda100927004.png) Zo kan hier bijv. in staan dat een Produktieorder niet herberekend kan worden, omdat de Nakijkvlag van het Recept nog aan staat. Indien alle kontroles akkoord worden bevonden, volgt het scherm: (http://www.heartprofit.com/www/transfer/graphics/forum/lotspoda100927005.png) en kan met de Verwerk button daadwerkelijk worden verwerkt. Let op: Na het afsluiten van de dag zal er geen voorraad meer liggen op de P_000 Lokaties (behoudens eventuele hulpstoffen, zie verderop). Alle overige voorraad wordt geacht te zijn "verproduceerd" (lees: verbruikt te zijn in de produktieorders die op dat magazijn geproduceerd zijn). Nb: Eigenlijk is dit ook de enige reden dat de afdeling "Voorbehandeling" in dit voorbeeld als een separate afdeling wordt betiteld. De afdeling voorbewerking wil nog wel eens een paar dagen vooruitwerken, en alvast voorraad produceren die een dag later verbruikt zal worden. Alles wat door deze afdeling geproduceerd wordt, zal dus eerst terug de cel in gaan, en met een separate handeling weer moeten worden overgeboekt naar de volgende afdeling: de snijafdeling, immers, alle voorraad die door de input-/output deur gaat moét geboekt worden. Zoals bij bovenstaande 'Let op' al genoemd: er is een uitzondering op de veronderstelling dat alle op de produktievloeren aanwezige voorraad verbruikt is. In de warme- en koude keuken worden diverse "hulpstoffen" gebruikt. Kruiden, peper, zout etc. Het feit dat er nu ergens een doos met 12 bussen zout van 1 Kg in de keuken staat, houdt niet in dat al deze bussen aan het einde van de dag verdeeld moeten worden over de produkten waar zoet in is verwerkt. "Zout" moet worden uitgesloten van de produkten waarvan de voorraad verdeeld wordt over alle Produktieorders die er behoefte aan hebben. Derhalve is het mogelijk om op Artikelniveau aan te geven dat een Artikel een "Voor Dagafsluiting uit te sluiten hulpstof" betreft. (http://www.heartprofit.com/www/transfer/graphics/forum/loarwy100927002.png) Er is nóg een situatie waarin de Dagafsluiting geblokkeerd zal worden, en dat is indien er wél behoefte is aan een bepaald produkt, maar er geen voorraad aanwezig is. Doel van deze kontrole is ervoor te zorgen dat als we enerzijds wel stellen dat we rode paprika gesneden hebben, maar anderszijds er nergens rode paprika naar de Produktievloer is verplaatst, er wel iets niet of verkeerd geboekt zal zijn. Alternatieven Hoewel deze run al behoorlijk complex is, kunnen we nog situaties verzinnen die e.e.a. nog veel complexer maken, en waar op dit moment expliciet geen rekening mee gehouden is. Hierbij valt o.a. te denken aan het werken met "alternatieven". Zo hebben we sites waar maar één artikel voor "Paprika Rood" gebruikt wordt, we hebben ze ook waar dit er tientallen zijn, onderverdeeld naar maat (50/70, 60/80, 70/90, 80/100), naar kwaliteitsklasse (1,2,3) of zelfs naar land van herkomst. Waar het bij de klant voor wie dit maatwerk ontwikkeld is voldoende is om de Receptuur naar "Paprika Rood" te laten verwijzen, zal het wenselijk kunnen zijn om van alle verschillende maten/klassen/landen aan te geven dat deze door elkaar verbruikt mogen worden. Terugdraaien Waar de ene klant stelt dat er iets in het systeem geboekt moet kunnen worden, stelt een andere klant hogere eisen, en vraagt naast funktionaliteit om iets te boeken meteen ook funktionaliteit aan om iets wat geboekt is weer ongedaan te kunnen maken. De Dagafsluitingsrun wordt dermate complex geacht, dat er niet voorzien is in funktionaliteit om een Dagafsluitingsrun terug te draaien. De verwachting is dat e.e.a. terugboekfunktie ook nimmer gemaakt zal worden. Als iemand dus ná de Dagafsluiting komt met "oh ja, ik moest nog 10 kistjes op-/afboeken", dan heb je pech gehad. Uitgangspunt is dat alle voorraad die aan de input- danwel output zijde door de deur komt gescand wordt. DOORREKENEN KOSTPRIJZEN Het hele ontwerp bevat nog een funktie, en daarvan is besloten om deze vooralsnog even te laten voor wat ze is. Een produkt welke tijdens het opboeken opgeboekt wordt, kent nog geen kostprijs. Van dergelijke items is gesteld dat zij wél aan een klant geleverd mogen worden, doch dan met de beperking dat die levering nog niet gefaktureerd kan worden. Ok, geen probleem. Een andere beperking zegt echter dat het niet is toegestaan om produkten waarvan de kostprijs nog niet bekend is, af te mogen boeken in andere Produktieorders. Dit, omdat het effect van het bekend worden van de prijs van een halffabrikaat, meteen kan doorwerken in honderden andere produkten die uit dat halffabrikaat geproduceerd zijn. Ervanuitgaande dat we in Profit al beschikken over "Doorrekenen Gewijzigde Inkoopprijs" funktionaliteit, lijkt het erop dat er wel mogelijkheden zijn om dit zodanig aan te passen dat de prijs van een halffabrikaat achteraf wordt doorgekopieerd naar alle produkten die eruit geproduceerd zijn. Ondanks het kostenplaatje van deze aanpassing, was de eerdere gedachte dat deze funktionaliteit toch nodig was, om maar één reden: de warme-/kouden keuken maakt gebruik van de halffabrikaten die door de snijafdeling geproduceerd zijn, en deze keukens stoppen eerder met produceren dan de snijafdeling (die langer doorwerkt). Derhalve zou de warme-/koude keuken ook eerder de dag moeten kunnen afsluiten. Mede omdat de Dagafsluiting nu als een twee traps raket is opgezet (we hebben de mogelijkheid om alle kontroles op te starten, de excel op het scherm te presenteren, inzicht te krijgen in wat er precies geboekt zal gaan worden, nog vóórdat we daadwerkelijk gaan afsluiten), zouden we kunnen besluiten om de chef van de warme-/koude keuken eerst dat 1e deel te laten kontroleren, om daarna iemand anders daadwerkelijk de dag te laten afsluiten. Doordat dan de Dagafsluiting van de Snijkeuken eerst plaatsvindt, zullen als vanzelf de produkten die naar de warme-/koude keuken geboekt zijn van een waarde worden voorzien, en kan aldaar de dag worden afgesloten zonder dat er ook maar iets op een complexe wijze achteraf opnieuw moet worden doorgerekend. Wat hier wel bij hoort, is dat de warme-/koude keuken aan het einde van de dag al orders moeten kunnen plannen voor de volgende dag, zonder dat deze orders bij de Dagafsluiting worden meegenomen. De Dagafsluiting zal derhalve Produktieorders waarop niets is opgeboekt overslaan tijdens de Dagafsluitingsprocedure. |