Heart-Profit ERP
November 27, 2024, 08:36:36 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: "Recept bestaat niet" fout behoefte run  (Read 4070 times)
0 Members and 0 Guests are viewing this topic.
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« on: July 26, 2007, 11:58:45 am »

LOPBIVGN / LOPBIVRA Generen besteladvies geeft meestal de melding: "Fouten geconstateerd bij de behoefterun."

Bij het bedrijf laco gebruiken we dit wel eens om de inrichting zo links en rechts te verbeteren. Bij Meel wilde ik dat in datzelfde kader ook gaan doen. Er zijn echter van die fouten die ik niet kan plaatsen.

BIJ "***FOUTEN-/OPMERKINGEN M.B.T. DEZE BEHOEFTERUN. ***" staat bijvoorbeeld deze:

"Recept 18010/HALF bestaat niet"

Die constatering klopt wel, want het recept bestaat ook echt niet. Je kunt dit spul namelijk niet apart maken, het komt namelijk vrij als bijproduct bij productie van andere producten. Ook is dit als dynamisch verbruiksartikel opgenomen bij andere (meng)recepten. Dus ja, je hebt dit spul wel nodig, en dat heeft de behoefterun in die zin ook goed gezien.

Ik heb op blad 5 van loarwy (wijzigen artikelen) de rubriek "In besteladvies" uitgevinkt. (van artikel 18010)
Ik heb op blad 1 van LOVAWY (wijzigen artikel verschijning) van de 18010/half de rubrieken "Effectueren veiligheidsvoorraad en bestelniveau " en "... eoq" uitgevinkt.

Dit met de gedachte dat dit artikel zou worden overgeslagen door de behoefterun.

Wat moet er gebeuren om deze "fout" op te lossen, welke parameter(s) zie ik daarbij over het hoofd? Ik wil er namelijk liever geen receptuur voor maken, omdat je daarmee (voor mijn gevoel)  een bijproduct omdoopt tot hoofdproduct.
Logged

KM
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5367


View Profile WWW
« Reply #1 on: July 26, 2007, 12:12:17 pm »

Good question...

Om te beginnen moet er bij de Artikel-/Verschijning geen Bestelniveau danwel EOQ zijn ingevuld. Zo dit er al niet staat, dan zal er geen behoefte zijn a.g.v. het Bestelniveau, en houdt het feit dat het produkt toch getriggerd wordt in dat je meer behoeftig hebt dan er is. Feitelijk moet je nu "bijprodukt maken" door een ander produkt te produceren.

Het uitschakelen van "In Besteladvies" heeft weinig te maken met de hele berekening. Er wordt altijd met alles gerekend, hooguit wordt aan het einde van de rit niet alles in het Besteladvies getoond.

Je kunt je afvragen of het feit dat je een melding krijgt nog wel zo fout is, immers, er zal ook niets fout gaan. Immers, er is bijprodukt behoeftig wat je niet hebt, en zolang niemand er een order in zet voor een produkt (wat je eigenlijk niet nodig hebt, maar waarin dit bijprodukt ontstaat) zul je niet kunnen produceren.
Logged

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

Posts: 4076


Just testing


View Profile WWW
« Reply #2 on: July 27, 2007, 11:22:34 am »

Vanuit een iets andere invalshoek :

De Behoefte aan een Bijprodukt krijg je via de Behoefterun nooit gedekt. Dit komt al doordat je uit meerdere Recepten hetzelfde Bijprodukt kunt krijgen, en het systeem niet zou weten welk hoofdprodukt te triggeren (Produktieorder voor voor te stellen). Met dit als basis :

Een Bijprodukt is geen Inkoopprodukt en het is geen Produktie produkt. Het is "niets". Het zou dan ook nooit behoeftig mógen worden. Overigens, wordt het behoeftig en er is onvoldoende Technische Voorraad dan wel Economische Vooraad, dan heb je sowieso een probleem; dit moet organisatorisch worden opgelost in de trant van "we wéten dat we altijd (is ook op ieder moment in de tijd) meer Bijprodukt produceren dan dat we er Behoefte aan hebben, en dus komt het altijd vanzelf goed.

Uit dit alles mag volgen dat een Bijprodukt domweg niet wordt meegenomen in de Behoefterun. Dit zou een indikator vergen die zegt dat het een Bijprodukt betreft. Op basis van deze indikator wordt dan de foutmelding niet weergegeven, en of alles verder vanzelf goed "uitpakt" hangt af van het genoemde organisatorische aspekt.

Mocht dit inderdaad zijn gewenst, dan kan dit voor 2,5 uur worden gemaakt. E.e.a. onder het voorbehoud dat ik het juist zie.
Logged

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

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #3 on: July 30, 2007, 03:23:59 pm »

Tja, hoe fout is het. Ik vindt 'm gewoon lastig. Aan het einde van de behoefterun wordt je getracteert op een paar fouten, die niet fout zijn. Tja, zo kun je het ook zien.

Waar ik nog wel een oplossing voor zou willen is deze opmerking:
"
Inhoud 11518/BULK/03-08-2007 te groot (150462.000)
"

Wat kun je hier aan doen om die fouten te voorkomen?
Logged

KM
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4076


Just testing


View Profile WWW
« Reply #4 on: July 30, 2007, 03:28:17 pm »

Betreft dit een onderdeel van een continu proces (zal wel) ?
Logged

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

Posts: 5367


View Profile WWW
« Reply #5 on: July 30, 2007, 03:45:06 pm »

Waar ik nog wel een oplossing voor zou willen is deze opmerking:
Inhoud 11518/BULK/03-08-2007 te groot (150462.000)

De maximale inhoud van 1 Artikel-/Verschijning is 99999,999. Ofwel, nèt iets minder dan honderdduizend.
Melding is wat dat betreft terecht, want je kunt deze bulk hoeveelheid niet in 1x bestellen.
Zodra dit soort situaties aan de orde zijn, moet je je afvragen of je eenheid wel juist is.
Bij KG kun je in grammen afboeken, maar ja... doe je dat überhaupt?
Is je eenheid TN dan is je behoefte feitelijk 150,462 TN en zou je tot 99999,999 TN kunnen gaan.

Er zijn klanten die in zo'n geval een Verschijningsvorm "Duizend Kg" aanmaken, en feitelijk 151 x de Verschijningsvorm "Duizend Kg" moeten gaan produceren. Niet echt netjes, want alles wordt afgerond op hele Verschijningen (duizendtallen), maar toch.
Logged

Heart-Profit company ID : HA
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #6 on: July 30, 2007, 04:35:08 pm »

Ik weet dat ik nooit meer dan 30.000 kilogram per keer ga maken. Misschien wel 150 ton in een week, maar dan 5 x 30.000 kg.  Meer kilogrammen passen er niet in een BULKauto. Maar ja, m'n HPP voor de hele week ligt vast op de vrijdag. A.g.v.  verkooporders wordt die behoefte wel wat verdeeld over de verschillende dagen.

Is het verdelen in porties van 10 of 30 ton ook een optie?
Logged

KM
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #7 on: July 31, 2007, 09:33:54 am »

Dan kom ik nog een waarschuwing tegen waar ik even geen benul van heb hoe dat opgelost moet worden:
"
Behoefte 14602           / 25KG    / XXXXXX / 10-08-2007 kon niet (op tijd?) worden gedekt; Geen Recept / Leverancier? Recept in een loop?
Behoefte 14602           / 25KG    / XXXXXX / 17-08-2007 kon niet (op tijd?) worden gedekt; Geen Recept / Leverancier? Recept in een loop?
"


Betreft een verpakt eindartikel.

  • 1. Er is nog een flinke voorraad
  • 2. Blad 5 wijzigen artikel: Productie- / inkooptijd in dagen is niet ingevuld
  • 3. Hij duikt voorlopig nog niet onder het bestelniveau.
  • 4. Het enige waar ik me iets bij voor zou kunnen stellen: dit eindproduct is ook onderdeel van een halffabrikaat.

In welke hoek moet je hiervoor een oplossing zoeken?
Logged

KM
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5367


View Profile WWW
« Reply #8 on: July 31, 2007, 09:56:17 am »

Is het verdelen in porties van 10 of 30 ton ook een optie?

Daar zijn wel mogelijkheden voor ja. Bijv. via "Maximale Ordergrootte in Verschijningen" (die wordt dacht ik i.g.v. bulk afgehandeld als Eenheden); instelbaar bij de Artikel-/Verschijning.
Dan heb je op Artikelniveau nog "1 P.O. per Batchgrootte", waarbij je denk ik bij het Recept die Batchgrootte kwijt kunt.

Je moet in de testbestanden hier maar eens wat mee spelen.
Logged

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

Posts: 5367


View Profile WWW
« Reply #9 on: July 31, 2007, 10:00:20 am »

In welke hoek moet je hiervoor een oplossing zoeken?

Nb: Het is niet handig dat je meerdere Behoefterun vragen stelt in 1 Topic.

Het produkt zal behoeftig kunnen worden als halffabrikaat van een ander produkt.
Bij het opstarten van de BhRun moet je rubriek 'Behoefte Analyseren' op Ja zetten, en dat vanuit het Besteladvies het VVV opvragen. Dan zie je misschien wel 'BI' (Besteladvies-/Behoefterun Input) regels staan van het produkt waarin dit artikel benodigd is.
Logged

Heart-Profit company ID : HA
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #10 on: July 31, 2007, 10:19:13 am »

De maximale inhoud van 1 Artikel-/Verschijning is 99999,999. Ofwel, nèt iets minder dan honderdduizend.
Melding is wat dat betreft terecht, want je kunt deze bulk hoeveelheid niet in 1x bestellen.
Zodra dit soort situaties aan de orde zijn, moet je je afvragen of je eenheid wel juist is.
Bij KG kun je in grammen afboeken, maar ja... doe je dat überhaupt?
Is je eenheid TN dan is je behoefte feitelijk 150,462 TN en zou je tot 99999,999 TN kunnen gaan.

Er zijn klanten die in zo'n geval een Verschijningsvorm "Duizend Kg" aanmaken, en feitelijk 151 x de Verschijningsvorm "Duizend Kg" moeten gaan produceren. Niet echt netjes, want alles wordt afgerond op hele Verschijningen (duizendtallen), maar toch.

Dit wordt 'oorlog' met de commercie. Het betreffen namelijk eindproducten. Deze kennen allen de voorraadeenheid kilogram. Omdat er te veel (verwachte) afname is in een week van bepaalde artikelen, zou dit in tonnen moeten gaan voortaan. Per 100 gram worden de eindproducten doorgaans afgewogen. Zo zwart wit had je het hier niet neergezet, dat maak ik er dan wellicht zelf van, maar is er werkelijk niet wat anders te verzinnen? Je kunt namelijk technisch gezien niet 1 productieorder van 150.000 kilogram maken. Dat lukt productietechnisch gewoon niet. Ik zou bijvoorbeeld een vraag van > 99.999 in een week wel verdeeld willen zien over meerdere dagen, bijvoorbeeld dinsdag 75.000 en vrijdag 75.000. Nu wordt een vraag van >99.999 kg gewoon buiten beschouwing gelaten door de behoefterun. (als ik het goed zie). Het is dus niet alleen een 'fout' die gesignaleerd wordt, de behoefte is ook te groot om te tonen.
Logged

KM
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #11 on: July 31, 2007, 10:39:17 am »

1 po per batchgrootte, batchgroootte ingevuld, max ordergrootte in versch. ingevuld, maar hij blijft roepen dat 'ie te groot is. Dus nog voordat er rekening gehouden gaat worden met eoq/batchgrootte etc.

Is het een oplossing om bij het genereren van de HPP items (vanuit de vraagvoorspelling) dit alvast te tackelen?
Logged

KM
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5367


View Profile WWW
« Reply #12 on: July 31, 2007, 11:41:06 am »

Het is dus niet alleen een 'fout' die gesignaleerd wordt, de behoefte is ook te groot om te tonen.

Wat er getoond wordt zijn Besteladviesregels. Iedere Besteladviesregel = 1 bestelling. Heeft dus niets te maken met "tonen", want hij zou een besteladvies presenteren welke zich niet laat bestellen. Via de methodiek met "max. ordergrootte" zou een bestelling van 150.000 als 5x30000 in het Besteladvies moeten kunnen komen. Dan heb je 5 afzonderlijke regels in het besteladvies staan. Als met die 5 regels de melding nog komt, dan is het fout; maar ik vermoed dat jij die opsplitsing naar 5 regels nog niet eens hebt.

Nb: Ondertussen zijn we ook al behoorlijk aan het inrichten, wat normaliter 'betaald werk' is.
Logged

Heart-Profit company ID : HA
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #13 on: July 31, 2007, 12:27:28 pm »

JA ik heb 'm al verdeeld over verschillende regels. Oorzaak, durf ik het te noemen of niet, nou ja vooruit dan maar... De inhoud was op 31-8-2007 te groot, maar de behoefterun hoefde maar te kijken tot 5-8-2007.......... AARGH. Dus laten kijken tot 1-9-2007 en daar werd de behoefte van desbetreffende week verdeeld over vier orders. toch blijft de inhoud te groot volgens de fouten/opmerkingen bij de behoefterun.

***FOUTEN-/OPMERKINGEN M.B.T. DEZE BEHOEFTERUN. ***

Inhoud 12058/BULK/31-08-2007 te groot (115401.000)


Maar toch wordt 'ie op die dag in vier delen getoond in de behoefterun.


* loidra12058.JPG (51.43 KB, 933x387 - viewed 145 times.)
Logged

KM
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.086 seconds with 21 queries.