Genereren Prod/Inkoopbehoefte - melding keuze receptverschijning

[pascal]

Via 6-2-F1 kun je de prod/inkoopbehoefte genereren. 
Wanneer je deze uitvoert krijg je echter bij (volgens mij) elk artikel met meerdere recepten de vraag welk recept gebruikt moet worden.
Met de hoeveelheden artikelen (en veel artikelen hebben een alternatief recept) komt de melding wel heel vaak.

Kan ik ergens instellen dat hij automatisch het voorkeursrecept gebruikt en je dus geen melding meer krijgt? Misschien middels een bedrijfsparameter?

[Wouter Rijnbende]

Kan ik ergens instellen dat hij automatisch het voorkeursrecept gebruikt en je dus geen melding meer krijgt? Misschien middels een bedrijfsparameter?

"Een voorkeurs Recept" is er niet, maar er zijn wel mogelijkheden om deze melding te elimineren.

Als eerste moet je je afvragen waarom je eigenlijk meerdere Recepten hebt om hetzelfde produkt te kunnen produceren.

Dit zou te maken kunnen hebben met een andere produktiewijze afhankelijk van de betreffende hoeveel. Als we verf gaan produceren in kleine hoeveelheden, dan pakken we een aantal tubes pasta, en gaan deze pasta's mengen. Moeten we grotere hoeveelheden produceren, dan produceren we hetzelfde produkt van scrap af aan op basis van de grondstoffen.
Met dit als uitgangspunt kun je bij een Recept aangeven dat een Recept geselekteerd moet worden o.b.v. de Behoeftige Hoeveelheid.
Zo kan worden ingesteld dat bijv. onder de 25 Kg het Pasta Recept getriggerd moet worden, en boven de 25 Kg het Kuip-recept.

Er zijn ook klanten die geen module Profit-Emballage hebben, en zodoende de Emballage opnemen in het Recept. In dat geval zal bijv. de Produktievorm bij het Recept ingevuld moeten worden om niet steeds deze keuze te krijgen.

Verder is er nog een mogelijkheid om bij de Verschijningsvorm (Hmenu-1-1-2-1) v/d Recept-/Verschijning aan te geven dat die Verschijningsvorm "Kostprijsbepalend" is.  Als je én een Kostprijsbepalende én een niet-kostprijsbepalende Verschijningsvorm hebt, prefeleert de eerste.
(Hmm... raar trouwens, want volgens mij is dat voor de Kostprijsberekening ontwikkeld, en kan aldaar gebruikt worden om bijv. een Calculatie-Recept en een Produktie-Recept te maken, en dan te calculeren met het calculatie-Recept; maar ja, produceren doe je juist niet met dat calculatie-Recept).

Een hele specifieke werkwijze (die ontwikkeld is voor de nieuwe TS schermen) kan zelfs nog een ander Recept selekteren afhankelijk van het Magazijn waarin het betreffende Produkt wordt geproduceerd; hier heb je echter niets aan in de Behoefterun.

Verder zie ik dat er nog iets bestaat als het definiëren van een prioriteit.  Als je dan meerdere Recepten hebt van dezelfde keuze, kun je i.i.g. nog afdwingen in welke volgorde deze moeten worden getoond.

Maar ja, terug naar mijn eerste opmerking, wat is jouw reden voor 2 Recepten?

[pascal]

We hebben verschillende recepten voor verschillende productie-stations.
Een artikel kan op de robot gemaakt worden, 1 van de productiemachines of met de hand (receptverschijning  wordt dan respectievelijk ROBOT, HENKE/KALKM/MASA en HAND).
Kleinere series kunnen met de robot of hand gemaakt worden, grotere worden doorgaans op een productiemachine gemaakt. De receptuur van een handwerk-artikel is anders dan van een robot. Ook de bewerkingen (kosten machine-uren danwel handwerk etc) verschillen.

[Wouter Rijnbende]

Een Recept "per machine" om vervolgens afhankelijk van het Recept (en daarmee de machine) andere dekkingstarieven te kunnen definiëren is niet mogelijk. Maar, misschien kun je het toch aan je "kleine series" ophangen, en kan de selektie op behoeftige hoeveelheid ook bij jullie bepalend zijn voor het Recept.

Een alternatief zou bijvoorbeeld kunnen zijn dat we een instelling erbij maken dat een Recept vanuit een Behoefterun voorgesteld mag worden J/N. Dan zou je een werkwijze krijgen dat de Behoefterun standaard het WERK3 Recept triggert, maar dat als je Handmatig een P.O. toevoegt, je de keuze krijgt tussen WERK3 en ROBACH. Eigenlijk net zoiets als "Kostprijsbepalend J/N", maar dan specifiek voor de Behoefterun.

[pascal]

Een Recept "per machine" om vervolgens afhankelijk van het Recept (en daarmee de machine) andere dekkingstarieven te kunnen definiëren is niet mogelijk. Maar, misschien kun je het toch aan je "kleine series" ophangen, en kan de selektie op behoeftige hoeveelheid ook bij jullie bepalend zijn voor het Recept.

We gebruiken verschillende EPU's voor verschillende produktiestations, zie schermafdrukjes.

Een alternatief zou bijvoorbeeld kunnen zijn dat we een instelling erbij maken dat een Recept vanuit een Behoefterun voorgesteld mag worden J/N. Dan zou je een werkwijze krijgen dat de Behoefterun standaard het WERK3 Recept triggert, maar dat als je Handmatig een P.O. toevoegt, je de keuze krijgt tussen WERK3 en ROBACH. Eigenlijk net zoiets als "Kostprijsbepalend J/N", maar dan specifiek voor de Behoefterun.

Als ik het goed begrijp pakt hij standaard het voorkeursstation?

[Wouter Rijnbende]

Hmm... Dat EPU gebeuren is ontwikkeld voor "Resources". Het is dan ook standaard gedefinieerd als "aantal eenheden per uur wat de betreffende Resource een bewerking kan uitvoeren".

Dus, bij eenzelfde Recept zou je kunnen triggeren dat de ene Resource (machine) sneller produceert dan de andere, en daardoor er minder tijd nodig is om te produceren (en daardoor het goedkoper wordt). Bij een opzet met Resources zou je om deze reden geen 2 Recepten nodig hebben.

[Wouter Rijnbende]

Als ik het goed begrijp pakt hij standaard het voorkeursstation?

Begrijp je vraag niet.

[pascal]

Als ik het goed begrijp pakt hij standaard het voorkeursstation?

Begrijp je vraag niet.

Excuus, met voorkeursstation bedoel ik "voorkeurs recept verschijning".

[Wouter Rijnbende]

Bij die oplossing selekteer je geen "voorkeurs recept verschijning". Natuurlijk geef je wel een voorkeur aan, door bijv. te stellen dat "WERK3" wel uit de BhRun geselekteerd mag worden, en "ROBACH" niet. Dan wordt automatisch WERK3 geselekteerd (omdat ROBACH afvalt). Maar ja, heb je ook een WERK2, die óók vanuit de BhRun geseleteerd mag worden, dan kan er alsnog weer een popup volgen met de vraag WERK2 of WERK3.

Voor "een voorkeurs Recep-/Verschijning" is ook wel wat te verzinnen, maar ja, dat impliceert dan dat je voor ieder Artikel dat moet gaan invullen.

Wat dan nog weer een oplossing kan zijn, is dat waar je al de mogelijkheid hebt een prioriteit aan te geven, we een bedrijfsparameter maken die zegt "neem altijd de 1e conform die ingestelde prioriteit". Via de prio van de Artikel-/Verschijning kun je dan zelf bepalen dat WERK2 boven WERK3 gaat, en WERK3 boven ROBACH, en dat als WERK2/WERK3/ROBACH allemaal gedefinieerd zijn, dus de 1e (WERK2) geselekteerd wordt.

[pascal]

Het ligt iets ingewikkelder dan ik had gehoopt, ik dacht dat hij op basis van hoe wij het ingericht hebben, automatisch de voorkeurs recept verschijning kan selecteren.
We geven aan de hand van de naam van de receptverschijning aan welke verschijning de voorkeur heeft, zie schermafdruk.
Hij moet dus altijd de receptverschijning pakken die begint met "1" (1020U1HARDK moet 1ROBACH gebruikt worden). Het mooist is wanneer hij dit automatisch doet.

Voor "een voorkeurs Recep-/Verschijning" is ook wel wat te verzinnen, maar ja, dat impliceert dan dat je voor ieder Artikel dat moet gaan invullen.

Doen wij dit al niet, zie schermafdruk?

[Wouter Rijnbende]

Da's dan toch juist geen probleem?

Beide methoden zouden werken.

Als je ze laat sorteren, is 1* altijd de eerste, en dus mag hij de eerste nemen.

Of, je hebt feitelijk HAND/ROBOT/ROBACH/MASA/WERK3, en maakt kombinaties met 1/2/3/4 ervoor, voor een volgorde.
Ervanuitgaande dat er dus altijd een 1* gekoppeld is, zou je (nu al) bij de 1* Recept-/Verschijningen kunnen aangeven dat deze kostprijsbepalend zijn, en bij de 2*, 3*, 4* Recept-/Verschijningen doe je dat juist niet. Omdat er dan altijd maar één 1* Recept aan een Artikel gekoppeld is, zal hij vanzelf die nemen.

[pascal]

Als je ze laat sorteren, is 1* altijd de eerste, en dus mag hij de eerste nemen.

Dit is de oplossing waarbij je dit middels een bedrijfsparameter kunt kiezen, toch?

Of, je hebt feitelijk HAND/ROBOT/ROBACH/MASA/WERK3, en maakt kombinaties met 1/2/3/4 ervoor, voor een volgorde.

Ok, dus de situatie zoals nu bij ons al het geval is.

Ervanuitgaande dat er dus altijd een 1* gekoppeld is, zou je (nu al) bij de 1* Recept-/Verschijningen kunnen aangeven dat deze kostprijsbepalend zijn, en bij de 2*, 3*, 4* Recept-/Verschijningen doe je dat juist niet. Omdat er dan altijd maar één 1* Recept aan een Artikel gekoppeld is, zal hij vanzelf die nemen.

Waar in Profit moet ik bij de recept verschijning aangeven dat deze kostprijsbepalend is? Ergens onder 1-3-1-1 F5? Wanneer ik dit voor elk recept moet doen is dit nogal een klus.

[Wouter Rijnbende]

Waar in Profit moet ik bij de recept verschijning aangeven dat deze kostprijsbepalend is? Ergens onder 1-3-1-1 F5? Wanneer ik dit voor elk recept moet doen is dit nogal een klus.

Verder is er nog een mogelijkheid om bij de Verschijningsvorm (Hmenu-1-1-2-1) v/d Recept-/Verschijning aan te geven dat die Verschijningsvorm "Kostprijsbepalend" is. 

[pascal]

Och stom, niet ver genoeg terug gekeken...
Ik ga even kijken wat voor ons het handigst is.

[pascal]

Of, je hebt feitelijk HAND/ROBOT/ROBACH/MASA/WERK3, en maakt kombinaties met 1/2/3/4 ervoor, voor een volgorde.
Ervanuitgaande dat er dus altijd een 1* gekoppeld is, zou je (nu al) bij de 1* Recept-/Verschijningen kunnen aangeven dat deze kostprijsbepalend zijn, en bij de 2*, 3*, 4* Recept-/Verschijningen doe je dat juist niet. Omdat er dan altijd maar één 1* Recept aan een Artikel gekoppeld is, zal hij vanzelf die nemen.

Inmiddels mbv deze methode de 1xxx-receptverschijningen aangemerkt als kostprijsbepalend (en dit bij de 2xxx-receptverschijningen uitgevinkt). Nu gaat het goed.
Bedankt voor je hulp!