Heart-Profit ERP

Ik heb deze opnieuw gegenereerd en zie nu bij een aantal producten bv ART0006490 een behoefte van 99999999.99 kg

waar worden dit soort getallen door getriggert. Is dat een inrichtingsfout of een berekeningsfout.
Lijkt me dat dit soort getallen een probleem geven in de echte berekening van de behoeften.

kan iemand hier eens naar kijken?


PS ik zie dit soort getallen ook aan de productiebehoefte kant bv art1007680?

Het Opbouwen van de Elementaire Behoeftebasis (volgens mij gebruikt overigens bijna niemand dat meer, opdat dit ter plekke gebeurd bij de Behoefterun, lokaal) berekent verder eigenlijk niets. Het zet enkel orders om in behoeftes. Bekijk dus het VVV van het Artikel. Als je nergens een order hebt die zo'n behoefte kreëert, dan zal het vermoedelijk ergens een inrichtingsfout zijn.

Toch even voor je gekeken. De Behoefte staat op 30-12-2010, en op die datum heb je 3 orders.

Tsja... ergens in het kreëren van de Elementaire Behoeftebasis op het netwerk zit een kontrole die een te grote behoefte maximaliseert tot 999999999,999 (misschien ergens een 9 teveel of teweinig), en de koding die daarop kontroleert vat ik niet helemaal. Hoe dan ook, ze dateert uit 1994, dus dat zit er al een tijdje in, en dus ga ik er toch vanuit dat je "iets raars" doet dat je daar nu ineens last van hebt.

Maar, nogmaals, die Elementaire Behoeftebasis op het Netwerk wordt (als het goed is ook bij jullie) niet meer gebruikt, dus voor dat ik uren ga besteden om uit te zoeken wie hoe wat waar...

De reden dat ik ging kijken bij de elementaire behoeftes is dat ik wat vreemde dingen tegen kwam en dus wilde zien waar die mogelijk vandaan komen.

Zitten deze getallen ook in de troep bestanden op lokaal niveau (na het genereren van de behoefterun) ?

Dan kan ik daar eens kijken waar het misgaat.

Nee. Het betreft puur een numeric overflow preventie op de LOBH (Elementaire Behoeftebasis Netwerk) tabel.
Uiteraard kan er een vergelijkbaar iets in de normale behoefterun zitten, maar zonder aanleiding lijkt het me niet zinvol te gaan zoeken naar iets wat er mogelijk niet is. Wat is je probleem eigenlijk?

Wij zijn aan het proberen om de "fouten" uit de besteladviezen te halen en de boel aan het optimaliseren mbt omloopsnelheden en veiligheidsvoorraaden.

Nu kan ik al niet zien wat er fout gegaan is als het systeem op een artikel een foutmelding geeft (zie eerdere post over de combinatie van de 3 mogelijke foutenbronnen)
Maar artikelen die fout gaan geven ook geen vvv dus de analyse kost per artikel veel tijd.

Verder valt mij op dat als een behoefte van een grondstof getriggerd wordt door een magazijntekort (dus niet order gerelateerd) van een ander artikel deze in de vvv van de gronsdstof als een BI van de grondstof wordt getoond en niet als een BI van het artikel wat deze grondstof afroept.

Dat maakt de analyse en het corrigeren ingewikkeld.

zie ook http://ha1.heartprofit.nl/profit/index.php?topic=22454.0 (http://ha1.heartprofit.nl/profit/index.php?topic=22454.0)

dit is zo'n voorbeeld van een "foutmelding" welke dan uitgezocht moet worden. Immers "Fouten" komen niet terug in de besteladvieslijst

Behoefte ART0000480      / ORIG00  / XXXXXX / 17-03-2010 kon niet (op tijd?) worden gedekt; Geen Recept / Leverancier? Recept in een loop?
Behoefte ART0000480      / ORIG00  / XXXXXX / 18-03-2010 kon niet (op tijd?) worden gedekt; Geen Recept / Leverancier? Recept in een loop?

Als ik naar de VV kijk lijkt alles goed op datum afgedekt te zijn (zie plaatje)

Als ik naar de verpakkingen kijk is de ORIG00 de enige actieve verpakking.

En onder artikelmenu H staan daarvoor meerdere leveranciers gekoppeld, waaronder ook degene die als voorkeursleverancier gekoppeld is bij de verschijning (ook al staat die in dit geval fout)

Dus waarom hier toch een foutmelding?

Je moet ook niet naar het VVV van het Artikel kijken, maar je moet het VVV vanuit de Behoefterun opvragen (en bij het opstarten van de BhRun een vinkje plaatsen bij Analyseren Behoeftes). Dan toont het VVV ook de behoefte aan het produkt die volgt uit de verkoop van een ander Artikel, waarin je het produkt als grondstof nodig hebt.

Overigens, is ORIG00 gedefinieerd als "Afnemen Inhoud toegestaan = Ja" ?

De behoefterun respekteert die instelling, opdat als je een produkt hebt wat eindprodukt is maar tevens grondstof, het systeem niet voorstelt om 1000 blikken van 1 Kg open te trekken, maar juist voorstelt om opnieuw 1000 Kg te produceren.

Dat klinkt leuk, maar artikelen die in de "foutenlijst staan" komen juist niet terug in de overzicht behoeftes, en daar kun je dus ook geen VVV van opvragen dat is nu juist het probleem.

- Hij staat in de foutenlijst
- dus is behoefte niet duidelijk
-staat niet in behoeftelijst die gepresenteerd wordt
- dus analyse is "onmogelijk" ...

komt hij misschien met de fout omdat in de order de levertijd niet bevestigd is?

zo van :

als IO klopt dan gaat alles goed en is opname in besteladvies niet nodig, maar datum is niet gegarandeerd dus komt in "foutenlijst"?

Als je vanuit het Besteladvies (LOIDRA - Hmenu,6,2,F1,2) met Control+F6 WyBad uitvoert, zie je daar het produkt dan wel?
Daar heb je ook een toets naar Raadplegen VVV.

De Behoefterun doet voor zover ik weet niets met al dan niet bevestigde leverdata.

Dan weet ik dus nog steeds niet wat er mis gaat bij ART0000480. En waarom hij dus genoemd staat in de "foutenlijst"

Jouw "WHYBAD" werkt niet, immers het artikel wordt niet getoond in de bestellijst en dan kan ik hem daar dus ook niet selecteren.

Blijft mijn vraag open:
Hoe analyseer ik wat in de foutenlijst getoont wordt?
Ik heb geen tussentabel met behoeftes
Ik weet niet welke van de 3 modi de fout afroept, dus hoe kan ik de fout zoeken en oplossen?

Wat zie ik wel dat jij niet ziet ?

Vervolgens zie je dat er per vandaag een uitgaande behoefte is aan 500 eenheden.
Precies diezelfde hoeveelheid heb je als Bestelniveau opgegeven.

Dat houdt in dat er besteld moet worden, en wel "onmiddelijk", immers, je VTV per vandaag is al onder het minimum.
Helaas heb je één dag Produktie-/Inkooptijd, dus "vandaag" ga je dat nooit meer redden, en vandaar de melding.

Dat je het de 18e ook niet gaat redden zal vermoedelijk komen omdat je de 18e weer een behoefte van 150 hebt, die het Bestelniveau van 500 weer onderuit haalt.

De 19e komt er voldoende binnen, en loopt de boel weer glad.

af en toe hè.....    :(

maar ik snap hem

thx

Even terzijde maarb wel belangrijk voor de beeldvorming:

Maar dat betekent dat je dus in de MRP run de "bestelbehoefte artikel van tabblad 5 dus eigenlijk definieerd als een veiligheidsvoorraad.

Immers je geeft een foutmelding als het artikel onder het bestelniveau zakt. En dat is in logistiek normaliter gekoppeld aan de veiligheidsvoorraad en niet aan het bestelniveau.

Immers er is de algemene logistieke formule:

bestelniveau = (veiligheidsvoorraad) + (gemiddelde verbruik in levertijd)

En jij stelt hier dat bestelniveau = veiligheidsvoorraad

dus dat betekend dat ik altijd artikelen in mijn  "foutenlijst" krijg die er formeel niet horen te zijn als je uitgaat van het feit dat bestelniveau en veiligheidsvoorraad 2 verschillende zaken zijn.

Trouwens op artikel/verschijningsniveau repecteer je deze verschillen wel, want daar werk je zowel met een bestelniveau als met een term veiligheidsvoorraad.

Nee hoor, werkt daar op dezelfde manier.

Met je formule heb je gelijk, de Veiligheidsvoorraad wordt enkel gebruikt in de berekening van het Bestelniveau !

Het wel wat anders werken dan wat je in de boeken leest, omdat het aspekt "tijd" erin verweven zit.

Tsja... en verder... 

Het Bestelniveau is een voorraadniveau waarop besteld moet worden als je daar onder komt...

Stel dat je voorraad 0 is, en je Bestelniveau 500, en we zouden slechts 100 gaan bestellen, dan weet je teminste zeker dat als je daarna nógmaals je Behoefterun draait, de VTV dan 100 is versus een Bestelniveau van 500, komen we dus nog 400 onder het Bestelniveau uit, en zal er dus weer besteld moeten worden. Kortom, we zullen minimaal 500 moeten bestellen om niet onder het Bestelniveau uit te blijven komen.

Dus? Bestelniveau = Veiligheidsvoorraad ?

Nee. Precies zoals in jouw formule: Veiligheidsvoorraad + het gemiddelde verbruik gedurende de Produktie-/Inkooptijd.

Dus, als jij 500 minimaal op voorraad wilt houden, 1 week produktietijd hebt, en gedurende die week gemiddeld 200 verbruikt, zul je opnieuw moeten produceren als je onder de 700 (500 + 200) uitkomt. Veiligheidsvoorraad = 500, Gemiddeld verbruik = 200, dus Bestelniveau = 700.

Er zijn echter niet veel bedrijven waarvan ik weet dat ze het Bestelniveau ook daadwerkelijk laten berekenen, en dus zal het er wel opneerkomen dat zij (net als jullie) het eindgetal zelf invullen.