Heart-Profit ERP

Wanneer een productieorder handmatig gemanipuleerd is, is de controle tussen afgeboekte en opgeboekte hoeveelheden niet consistent

Ik heb hier het voorbeeld van een PO waar 300 kg in moest, en 0 kg ingegaan is, maar wel een output heeft van 300 kg
Ons maximale productieverlies staat op 40%


:22c:

pikt iemand dit nog op?
Is toch wel essentieel dat dit goed gaat

Anders kun je heel wat materiaal uit lucht genereren, lijkt me handig....

Oh ... dit topic is nooit voorbijgekomen. Althans, niet dat ook maar iemand dat hier heeft gezien. Forumfoutje ?

Volgens mij werkt dat produktieverlies-/winst o.b.v. de ordergrootte, en niet op de ingestoken hoeveelheid grondstoffen. Immers, een vaste link tussen input en output is er niet altijd. Zo kan het standaard zo zijn dat je 100 liter nodig hebt om 80 te produceren, waarbij die 20 niet meteen 'uitval' is.

Nu weet ik wel dat er wel vaker aan deze melding gesleuteld is, dus misschien is e.e.a. mogelijk middels e.o.a. bedrijfsparameter?

Nb: Er zijn klanten die inderdaad 'iets' uit 'niets' (blackbox) produceren.

Als ik de helptekst lees kom ik toch tot de conlusie dat mijn interpretatie: n.l. het aantal ingestoken kg grondstoffen en opgeboekte product mag niet meer dan X % afwijken, klopt.

Zo is deze parameter ook aan ons uitgelegd en ik weet dat ik in het verleden meerdere malen de melding kreeg: "Er wordt een niet reeele productiewinst gegenereerd" waarop het systeem weigerde...


Zie onderstaande helptekst:



Bij Meng-Recepturen mag het uitgangspunt zijn dat (bijv.) het gewicht
van alle grondstoffen het gewicht van het eindprodukt oplevert.       
Echter, juist bij deze Meng-Recepturen ontstaat meer of minder       
Produktie-verlies, waardoor minder gewicht eindprodukt ontstaat       
dan verwacht;                                                         

Middels deze Parameter kan worden aangegeven hoeveel Produktieverlies
is toegestaan, wil het systeem het Gereedmelden van de Produktieorder
nog accepteren.  Bedenk hierbij dat het Gereedmelden op zich normatief
zou kunnen plaatsvinden (dus boeken wat het systeem verwacht op basis
van de Receptuur), doch dat dit in de praktijk niet zal gebeuren,     
aangezien e.e.a. staat of valt met juiste voorraad-registratie. Aldus
zal bij het Gereedmelden (Opboeken Gereed Produkt) "automatisch" de   
daadwerkelijk opgeboekte hoeveelheid worden geregistreerd, omdat     
anders het voorraadverschil eindprodukt (veelal beheerd door een     
andere afdeling : expeditie !!) niet zal kunnen worden verantwoord.   

Dus, juist omdat de daadwerkelijke hoeveelheid gereed produkt zal     
worden opgeboekt, terwijl de grondstoffen veelal wèl normatief werden
afgeboekt (Produktie doet binnen haar afdeling wat ze wil, en is zelf
verantwoordelijk voor door haar gekreëerd voorraadverschil) zal een   
onevenredig verlies kunnen "ontstaan".  Immers, als er minder         
grondstof werd verbruikt dan geboekt (werd normatief gedaan),         
komt er wel degelijk minder eindprodukt uit de order; de Gereed-     
melding wordt zoals vooromschreven wèl naar werkelijkheid gedaan,     
waardoor automatisch een niet-reëel Produktieverlies is ontstaan.     

Deze Parameter geeft aan hoeveel in percentage deze afwijking mag     
zijn. Dus, stel dat 10 % wordt ingevuld, dan zal bij 100 kg           
grondstoffen 90 kg gereed produkt mogen ontstaan, minder niet.         

Voor de goede orde wordt nog opgemerkt dat de 10 kg verlies uit het   
voorgaande, daadwerkelijk verlies kan/mag zijn, doch dat hier ook     
"10 kg speling" kan worden gehanteerd voor "het nog normatief mogen   
afboeken".  Met andere woorden, Produktie is niet geïnteresseerd in   
de laatste 10 % detail, "wenst" dus 10 % Voorraadverschil, doch       
verliest geen enkele tijd aan het juist moeten registreren van       
afgeboekte grondstoffen (normatief afboeken kan met één druk op       
de knop).                                      

De kontrole op een niet reële Produktiewinst vindt ook in deze situatie plaats. Echter waar dit er ooit toe leidde dat de Produktieorder niet goedgekeurd kon worden heeft de gebruiker tegenwoordig de mogelijkheid om het verschil te accepteren. Iemand zal er dus bewust voor gekozen hebben om uit lucht 12 vaten van 25 KG op te boeken.

Zoals reeds telefonisch aangegeven ben ik daar niet blij mee.

We hebben juist voor een ERP systeem gekozen om dit soort zaken niet mogelijk te maken.
Als dat nu gewijzigd is naar een "softe" melding, betekent dit dus dat we nooit een sluitende voorraadsituatie krijgen.

Daar wordt ik dus echt niet blij van...

Je kiest in mijn opinie juist voor een ERP systeem om zaken dicht te spijkeren, niet om er allemaal workarounds in te bakken.
Het neerleggen bij een willekeurige gebruiker betekent altijd ellende, zoals dit ook weer laat zien.
Kijkk alleen maar naar kostprijzen e.d.

Marco,

Waar een ander juist blij mee is, ben jij niet blij mee. Feit is dat jij kunt werken in deze situatie, waar een ander in de andere situatie niet zou kùnnen werken.

Er zijn hier vele kombinaties mogelijk en daarnaast 10tallen soorten processen die dan weer dit, dan weer dat verlangen.

Wat je waarschijnlijk niet eens weet, is dat dit in de loop der jaren bijna "kontinu" verandert. In dit geval heb je het na een half jaar gemerkt.

Omdat er kennlijk niet 1 scenario kan worden bedacht waarmee iedereen tevreden is, moeten we nu dan maar met een Bedrijfsparameter op de proppen komen die de melding al dan niet weergeeft (c.q. alsnog goedkeuren niet toestaat, of juist wel zoals het momenteel in elkaar zit).

4 uur.

Dat is mooi,
Zat er een beveiliging in het systeem tegen "domme fouten" (mijn optiek)
Zetten jullie dat voor een andere klant uit, en mag ik € 450 euri betalen om de oude situatie weer af te kunnen roepen!

En daarbij het argument, je merkt het pas na een half jaar:
Deze functionaliteit beveiligd tegen "stomme" fouten waarvan ik hoop dat ze nooit voorkomen, maar waarvan we beiden wisten dat ze wel mogelijk zijn (gezien de ingebouwde functionaliteit).

Daarnaast weet ik dat ik normaliter redelijk consequent de releasenotes lees en ik kan me deze melding en de impact niet herrinneren: zal wel weer in de releasenotes hebben gestaan als korte melding in de trand van : "Controle aangepast"

In de releasenotes vind ik in ieder geval niets over een melding productiewinst/productieverlies
Alleen over uitval bij assemblage recepturen, en wij gebruiken mengrecepturen

Misschien begrijp je het niet helemaal;

Er zijn klanten die niet anders kùnnen dan de "fout" -die voor hen dus helemaal geen fout *is*- accepteren. Domweg omdat het hun waarheid is. Ik neem  aan dat je me niet duidelijk wilt maken dat die klanten dan maar moeten barsten omdat jij zonodig domme gebruikers hebt (overigens, jouw woorden, en nooit die van mij !).

Het lijkt me dan ook een heel eerlijke keuze : gebruikers opvoeden (of wat het ook vergt) of een Bedrijfsparameter betalen.

Het lijkt me eerder dat jij een foute implementatie hebt mbt mengrecepturen en dynamische recepturen

Immers bij mengrecepturen is zover ik kan zien mijn situatie altijd "goed" en in alle andere gevallen praat je niet over mengrecepturen

Zie jouw eigen helptekst:

I.g.v. een Mengreceptuur kan het eindprodukt pas worden gereedgemeld           
indien de Grondstoffen werden afgeboekt, immers halverwege tijdens   
het Produktieproces zal nog geen eindprodukt klaar zijn. Ook hier     
blijkt weer dat het totaal aantal eenheden grondstof gerelateerd is   
aan het totaal aantal eenheden eindprodukt.                           

Blijft mijn stelling dus overeind...

Graag bedrijfsparameter maken welke het volgende afdwingt:
Indien productieverlies c.q. productie winst hoger is dan de %-waarde opgegeven in het veld "toegestane percentage productieverlies" deze boeking blokkeren

ter vergelijking ingestoken kgs met PO-goedkeurwaarde en PO-output


:19c:

Marco, ik ga niet eens lezen - laat staan beoordelen wat je er nu van maakt en of het wel anders is als dat het is waarop nu de foutmelding volgt.

De Bedrijfsparameter voor 4 uur vermijdt de foutmelding as is. Klaar.
is dat de bedoeling ?

yep