Heart-Profit ERP
July 01, 2024, 03:56:54 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: produktie orders  (Read 2861 times)
0 Members and 0 Guests are viewing this topic.
Dinand
Profitable
***
Offline Offline

Posts: 682


View Profile
« on: June 19, 2008, 05:14:39 pm »


Bij ons worden p.o door de ene afdeling (her)gegenereerd middels 5-2-1-1 en dan juiste p.o en shft-F6. Hier wordt opgegeven wat er in totaal is geproduceerd. Dus eerste én tweede keus samen.
Vervolgens wordt de p.o door een ander goedgekeurd en wordt de produktie gesplits in eerste en tweede soort. Dit samen mag (uiteraard) niet meer zijn dat wat er bij het genereren ingegeven wordt. Dit kan toch gebeuren. Zie mijn bijlage. Hier zijn er ruim 30.000 stuks gemaakt en toch is de uiteindelijke output ruim 93.000.
Is dit te tackelen of desnoods een melding dan aantal niet meer kan zijn dat wat gegenereerd is? (minder kan wel, omdat je altijd afval/uitval hebt)


* productie-order.png (16.39 KB, 733x786 - viewed 168 times.)
Logged

BS
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #1 on: June 20, 2008, 08:16:38 am »

In het algemeen kun je middels bedrijfsparameters, E registreren welk uitval "reëel" is (winst of verlies). Maar, dit is een bedrijfsparameter wat over al je produkten heen gaat, en wat voor dit (soort) produkt(en) geldt, hoeft niet voor je andere produkten te gelden. Ik bedoel, je kan wel instellen dat er maar 1% afwijking mag zijn, maar misschien heb je ook nog wel mengrecepten waarbij dat niet op gaat.

Een heel ander iets is de procedure die je volgt. Hierbij kan ik me afvragen hoe je bijv. je grondstoffen verbruik boekt. Boek je zelf expliciet af wat je verbruikt hebt? of boek je e.e.a. normatief o.b.v. de ordergrootte die je zelf hebt opgegeven? Zo het laatste geval, kan ik me voorstellen dat je wel eens geholpen kunt zijn met een voorloopscherm waarin je én output 1e keus én output 2e keus opgeeft, waarna het systeem de P.O. zelf herberekend o.b.v. de opgegeven output, en deze conform norm afboekt, en opboekt wat jij hebt opgegeven. M.i. boek je nu nl. ook pas de order zodra deze helemaal klaar (lees: alle 1e en 2e keus bekend is), immers, anders kun je dat ding niet herberekenen o.b.v. de werkelijke output.
Logged

Heart-Profit company ID : HA
Dinand
Profitable
***
Offline Offline

Posts: 682


View Profile
« Reply #2 on: June 20, 2008, 03:57:35 pm »

Wij boeken in Almelo altijd de werkelijke verbruiken af aan de hand van output lijsten van produktie. Vooraf genereren wij de p.o. door bij een p.o. middels shift F6 de juiste aantallen in te geven. Zie bijlage. Vervolgens worden de werkelijke verbruiken afgeboekt bij 5-2-2-1.
Acheraf (een dag later) worden de eerste en tweede soort ingevoerd.
In het genoemde en bijgevoegde voorbeeld van gisteren worden eerst de werkelijke verbruiken (obv. werkelijke produktie van ruim 90.000) gedeeld door 30.720 stuks. Dit heeft dan tot gevolg dat de kostprijs te hoog is. Vervolgens wordt er bij goedkeuring een groot bedrag ten gunste van het resultaat (uitval) geboekt.
Je zou dan een melding moeten krijgen dat je niet meer kunt ingeven dan wat je gegenereerd hebt net voor het afboeken van de verbruiken. Feit blijft dat je dan nog wel de hoge verbruiken uitsmeert over een te laag aantal.  Daarom vraag ik mij af wet wijsheid is en is denk je genoemde parameter om het max. uitval% in te geven beter. Waar kan ik dit vullen bij E. Is dit de eerste of de tweede optie?

Overigens vind ik dat het bedoelde voorbeeld wel gezien had mogen worden door mijn collega, maar dat is een andere discussie.
Verder komt het ook voor dat p.o. normatief worden afgeboekt v.w.b. verbruikte grondstoffen.


* productieorder2.png (6.99 KB, 404x171 - viewed 144 times.)
Logged

BS
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #3 on: June 23, 2008, 09:18:58 am »

Quote
Een heel ander iets is de procedure die je volgt [...] Zo het laatste geval, kan ik me voorstellen dat je wel eens geholpen kunt zijn met een voorloopscherm ...

Dinand, je moet hier toch eens over nadenken, maar dan in een wat andere context dan Normatief Afboeken zoals Wouter het bedoelde;

Ik denk dat de procedure die je toepast zich ervoor leent om een soort "kontrolerend" (inderdaad) voorloopscherm te hebben wat erop toeziet dat je e.e.a. alleen kunt invullen zoals het bij jou consistent moet werken. E.e.a. wordt (denk ik) uitgelokt doordat je eigenlijk altijd die output opboekt onafhankelijk van hoe het is voorgekookt (i.v.m. 1e en 2e keus) terwijl het systeem in principe toestaat dat je meer opboekt dan dat de grondstoffen toestaan, maar wat (alweer, denk ik) in jouw geval niet zomaar valt af te leiden uit die grondstoffen.

En ik zeg het maar even (ook voor iedereen hier) : e.e.a. zo maar relateren aan bijvoorbeeld de oorspronkelijke hoeveelheid output (in stuks ?) zal moeilijker blijken om goed te krijgen dan we willen, wat m.n. komt door alle kontroles die er al in zitten, en die feitelijk gerespekteerd moeten blijven worden. Die kontroles zou je dus vóór kunnen zijn, en dat doet zo'n voorloopscherm wellicht.
Logged

Heart-Profit company ID : HA
moderator all boards
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #4 on: June 24, 2008, 08:59:39 am »

Na telefonisch overleg blijkt dit wat anders in elkaar te zitten dan het leek :

1. Produktieorder wordt gegenereerd volgens de Receptuur. Hierin bevindt zich de grondstofbehoefte volgens "norm".

2. Op basis van de verwachte hoeveelheid Output wordt de PO hergegenereerd (hoeveelheid grondstoffen wordt mee-aangepast.

3. Bij 2 wordt de typefout gemaakt. Daar wordt 30.000 ingetypt i.p.v. 100.000.

4. Na (tijdens) produktie wordt het werkelijke grondstofverbruik afgeboekt. Dit is dus ruim 3 x hoger dan de "norm" op dat moment aangeeft (de gebruiker had hier al een rode lamp willen zien, want zelf zet 'ie 'm niet aan).

5. Als de output klaar is (gedroogd, een dag later) wordt de output opgeboekt. Dit gebeurt 1e en 2e keus, en elk van die regels is niet direkt gerelateerd aan de ene "norm" regel die op 30.000 staat. Hier wordt de 93.000 resp. 7.000 ingetypt. Ook hier had bij de gebruiker een lampje moeten gaan branden (die dus het liefst automatisch moet aangaan).

... en als klap op de vuurpijl doet het systeem het dan ook nog eens fout. Immers, je zou toch zeggen dat de totale opgeboekte hoeveelheid van 100.000 ook in de header zou moeten staan. Daar staat echter nog steeds de 30.000. Gevolg : kostprijzen onjuist.

Op National Geografic heb ik gezien dat een ongeluk eigenlijk nooit door één oorzaak ontstaat. Dat lijkt me hier wel op van toepassing.
Logged

Heart-Profit company ID : HA
moderator all boards
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #5 on: June 24, 2008, 09:38:10 am »

Een manier om dit op te lossen is de Produktieorder te laten lopen via Produktieorderstatus "Z" (geen Prijs bekend). Bij deze methode wordt achteraf, bij het Goedkeuren van de order bepaald hoeveel output er werd opgeboekt, en komt deze hoeveelheid in de order te staan. Vervolgens worden de afgeboekte kosten verdeeld over dat aantal, en wordt de prijs doorberekend aan de voorraad.
Het is denk ik ook de enige manier, immers je weet pas dat er 90.000 stuks uit de order zijn gekomen (en je je prijs moet baseren op 90.000) als de hele order kompleet is.

Produktieorders krijgen een status "Z" zodra er eerst Output wordt opgeboekt (mits toegestaan middels een bedrijfsparameter) alvorens het grondstoffenverbruik is goedgekeurd. In hun geval zou er een bedrijfsparameter (of instelling op Recept) nodig zijn die die methode standaard triggert.

Merk op dat het opgeboekte produkt zo goed als niet gebruikt kan worden zolang er geen waarde is toegekend. Leveren mag nog wel, maar dan mag die order niet gefaktureerd worden.
Logged

Heart-Profit company ID : HA
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #6 on: June 24, 2008, 10:10:27 am »

Quote
Een manier om dit op te lossen is de Produktieorder te laten lopen via Produktieorderstatus "Z" (geen Prijs bekend).

Ik heb het idee dat niet veel mensen dit gaan begrijpen, wat overigens het gevolg is van de wijze waarop e.e.a. technisch in elkaar zit (lees gerust : moet zitten).

Wel zie ik dat Wouter op de e.o.a. manier als uitgangspunt neemt dat de order in stappen wordt opgeboekt, wat wat mij betreft hier niet aan de orde is. De "op e.o.a." zal dan ook het gevolg zijn van het gegeven dat erop wordt geanticipeerd dat de order in stappen wordt opgeboekt, wat op zich (en uiteraard) al aan de orde is bij het administratief verwerken. Dit is dan op zich weer het gevolg van het nooit kunnen afsluiten van een order waar in stappen gereedmelden inderdaad aan de orde is, èn waarbij een order ook als "gereed" mag worden gezien als er sprake is van een continu proces (je wilt dan altijd met de output aan de gang, ook al loopt de order nog een week door).
Probeer dit maar niet te doorgronden, maar accepteer s.v.p. dat er meer speelt dan je weet ...

Niet tegenstaande het voorgaande, blijft het zo dat het funktioneel gezien domme onzin lijkt dat de kostprijs wordt gerelateerd aan de ooit werwachte hoeveelheid output (de 30.000). (Dinand,) Denk ook maar eens aan het volgende, maar met wèl het uitgangspunt dat het juist zou zijn dat de kostprijs wordt gerelateerd aan de ooit verwachte hoeveelheid output :

Je maakt een Produktieorder administratief in het systeem. Dit doe je dus voordat de produktie daadwerkelijk begint. Wat doe je (wellicht, want ik weet het niet echt) ? je wilt 90.000 stenen maken en geeft dat ook in als verwachte Output. Het systeem genereert daarbij de consistente hoeveelheid grondstoffen. Mooi;
In jullie geval lijkt het me om te beginnen al zo te zijn dat je niet in staat bent om die hoeveelheid grondstoffen op de steen nauwkeurig af te wegen enzovoort. En anders *wil* je dat gewoon niet (te veel moeite, te veel tijd). Uiteraard hoort hier wel bij dat je er niet zo mee zit dat je wat te veel of te weinig stenen maakt, wat op zich mag inhouden dat je meer op voorraad produceert en minder of niet op klant. Immers, je lokt uit dat er meer of minder stenen uitkomen.
Goed. Hiernaast lijkt het me dan ook nog zo dat je bij een gegeven hoeveelheid grondstof óók nog eens niet kan afdwingen hoeveel stenen hier uit komen. Dit komt a. door de grondstof zelf (bijvoorbeeld vocht daarin zal uitmaken -> hoe meer vocht hoe zwaarder en voor de hoeveelheid output maakt het geen z*k uit) en b. doordat je ook nog eens uitval zult kunnen hebben.

Als je dit alles goed doorwerkt, dan kom je er volgens mij op dat waar je 90.000 als verwachte hoeveelheid output opgeeft, er bijvoorbeeld 91.000 kan uitkomen, je dit ook eeuwig op deze wijze noteert en ... er van je kostprijs maar weinig klopt. Immers, het systeem hanteert eeuwig en altijd die 90.000 en a. had jij nooit door dat die 1.000 te veel de kostprijs beïnvloedt omdat b. er te veel parameters zijn waarop je geen zicht hebt.

Mijn persoonlijke konklusie is dat er hier maar één goede basis is om het zo goed mogelijk te doen : het systeem MOET rekenen met de hoeveelheid Output zoals daadwerkelijk gebruikt en ZAL werken met de werkelijke hoeveelheid gebruikte grondstoffen (dit laatste is altijd al zo), en de enige parameter waarmee je dan kunt mis zitten is het vol*lme/gewicht van de grondstof die varieert op basis van vochtgehalte en die dus de kostprijs onterecht beïnvloedt. Merk wel op dat deze beïnvloeding net zo goed aanwezig is bij inkoop, en dat je er wel voor zult hebben gezorgd dat je hier tegenkunt. Ofwel, geen probleem (waar het wel degelijk de hoeveelheid Output blijft beïnvloeden !!).

Per saldo komt het er m.i. dan op neer dat je best de uitval mag weglaten in de Output en dat dat op zich keurig de Kostprijs beïnvloedt. Dus, de vochtperikelen daargelaten, gooi je er iets in wat volgens het volume/gewicht een bepaalde kostprijs heeft, en daar komt iets netto uit met aldus dezelfde kostprijs. Dit is ALTIJD juist (of ik moet iets vergeten).

Dinand, voordat je het bent vergeten, de moraal : het systeem rekent voor jou(w inrichting) steevast met de 90.000 en nooit met wat er werkelijk uitkomt (deze uitspraak is overigens gebaseerd op jouw schermkopieën plus wat Wouter ervan zegt). En dit moet FOUT zijn.

Om geheel andere reden dan jouw aangedragen probleem (althans, zoals ik het heb verwoord in mijn eerdere post) heeft Wouter gelijk in de aangedragen oplossing. Dat daarmee het probleem er ook niet zou zijn geweest is mooi meegenomen.
Probeer s.v.p. te doorgronden dat jouw situatie best bijzonder is, mits ze zo is zoals zojuist omschreven.
Is het laatste niet waar, dan werkt Wouter's oplossing nog steeds, maar zou het voor het gevoel mooier mogen. Dit "mooier mogen" zou dan wel heel merkwaardig maatwerk worden met een prijs die je liever niet betaalt. Denk ik.
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #7 on: June 24, 2008, 10:23:19 am »

Wij pakken dit pragmatisch op:

Productie boekt grondstoffen af
Daarna keuring e.d.
Opboeken wordt niet afgesloten

Indien materiaal is vrigegeven voor tappen, dan eerst afvullen, als gereed is opbrengst bekend
Dan afboeken gronstoffen afsluiten tegen werkelijke opbrengst

Daarna afgetapte materialen in magazijn opboeken

Zo houdt je de prijs  "correct", immers wat je insteekt en uithaalt zijn dan ver bekend.

Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
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.022 seconds with 20 queries.