Heart-Profit ERP
November 27, 2024, 01:23:53 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Muteren en Herberekenen PO Grootte bij PO met Dagsegmenten  (Read 646 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27476


View Profile WWW
« on: August 24, 2018, 10:59:44 am »

Sinds deze Releasenote vinden we dat het mogelijk moet zijn om een Produktieorder met Dagsegmenten ook te kunnen wijzigen. Nieuwe Dagsegmenten toevoegen e.d. is niet mogelijk, maar het moet wel mogelijk zijn korrekties aan te brengen op een bestaande Produktieorder. Regels kunnen worden toegevoegd, gewijzigd en verwijderd.

Regels die toegevoegd worden, worden opgenomen onder hetzelfde Dagsegment als door dat regelnummer geïmpleceerd wordt. De regels van de P.O. impliceren de volgorde waarin geproduceerd wordt. Alle regels die onder een bepaald Dagsegment zijn opgenomen behoren tot dat Dagsegment. Het is niet toegestaan een nieuwe P.O. Regel op te nemen vóór het 1e Dagsegment.

Na iedere wijziging van de Produktieorderregels zal de Produktieordergrootte opnieuw worden herberekend. Voor deze Dagsegment orders geldt hiervoor nu een nieuw algoritme.

Het nieuwe algoritme was nodig, omdat Produktieorders die ontstaan zijn uit een Recept waarvan de Receptgrootte niet door Profit werd berekend maar "handmatig" werd overruled (of in dit geval werd overruled door een Receptgrootte zoals in Excel aangegeven) enkel tot een gewijzigde P.O. grootte leidde als er achteraf "Gereed Produkt" bij de order werd ingevuld. Deze leidde 1:1 tot een PO verhoging. Wijzigingen of toevoegingen in doorloop #1 werden niet (of niet altijd) doorberekend aan de PO grootte.

Nb: Dat "niet doorberekenen" is ontstaan bij Recepten waarbij we 100 Kg A samenvoegen met 45 Kg B, om vervolgens te stellen dat er 110 Kg C uit komt. Profit zou een Receptgrootte van 145 Kg uitrekenen maar de gebruiker overrulet dit met 110 Kg. Hier kunnen we al niet stellen dat als we 1 Kg meer A er in gooien, er ook 1 Kg meer C uit de order komt, immers, het kan net zo goed produkt B zijn die tijdens het produktieproces 'verdampt' en tot de verminderde ordergrootte leidt. Feitelijk zegt de koding hier 'als je ons de Receptgrootte niet laat uitrekenen, kunnen we dat ook niet doen als jij achteraf wijzigingen aanbrengt in het Recept'. Deze vlieger gaat in mindere mate op bij de ingelezen Excel Recepten. Daar is weliswaar sprake van een afwijking, maar, meer omdat Excel ergens met een ander Soortelijk Gewicht rekent dan Profit (lees: als het Soortelijk Gewicht in Profit wordt aangepast, gaat iemand dan al zijn Excel Recepten hierop aanpassen?).

M.i.v. deze Releasenote zullen wijzigingen op Produktieorders die o.b.v. een Dagsegment-Recept zijn gegenereerd tóch worden doorberekend naar de P.O. grootte. Dit via een speciale daartoe geïntroduceerde berekening, die per Produktieorderregel weet hoeveel grondstof er conform Recept in moest, en de verandering daarop relatief verrekend in de oorspronkelijke P.O. Grootte, gebruikmakend van de faktor tussen de handmatig ingegeven Receptgrootte en de door Profit berekende Receptgrootte.

Met een klein voorbeeld proberen we het uit te leggen: Stel dat we een Excel Recept inlezen en Excel geeft aan dat het Recept 4800 L groot is. Als we het Recept in Profit inlezen, volgt er echter een Receptgrootte van 4780 L uit. Hieruit kunnen we een faktor 4800/4780e berekenen (ofwel, als we een Produktieorder toevoegen voor 4800 L dan is die Produktieordergrootte 1,00418x groter dan door Profit werd berekend). Als in deze Produktieorder 1500 Kg van een grondstof nodig is, welke hoeveelheid gewijzigd wordt naar 1200 Kg, dan steken we 300 Kg minder in. Als die grondstof een Soortelijk Gewicht heeft van 2,6 Kg/L impliceert dat dat 300 Kg minder 115,385 L minder eindprodukt zou impliceren. Echter, gezien de faktor 1,00418 zal de korrektie nu uitkomen op 115,940 L.

In het Excel Recept is het ook mogelijk om minimale-/maximale waarden te berekenen. Per Receptregel wordt een indikatie aangegeven van de af te boeken hoeveelheid, maar vanuit Excel worden (per regel) marges aangestuurd die leiden tot een onder-/bovengrens. De margepercentages worden niet in Profit geregistreerd, de uit Excel resulterende onder-/bovengrens wél, maar, als "read only" waarden. Ze worden vanuit het Recept doorgekopieerd naar de Produktieorder, maar kunnen nergens in Profit worden gewijzigd (overigens enkel "omdat dat niet is ontwikkeld").

Het effekt is dat voor alle regels die vanuit Profit worden gewijzigd géén onder-/bovengrens beschikbaar is. Mocht een regel worden gewijzigd waarbij al zo'n marge was opgenomen, dan vervalt deze (immers, als de benodigde 1500 Kg tussen de 1480 en 1510 mag liggen, en we wijzigen het naar 1200 Kg, dan kunnen we niet simpelweg stellen dat ze 20 Kg naar beneden en 10 Kg naar boven mag afwijken; ook een scenario 'procentueel berekenen' hoeft niet te voldoen).

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOAPKPTV    Koppelen Artikel (Bijstelling)    16-08-2018    24-08-2018
LOAPKPWY    Wijzigen Produktieorder-regel (Bijstelling)    17-08-2018    23-08-2018
LOKV0109    Omschrijving (nog) niet bekend    23-08-2018    23-08-2018
LOPORGHB    Omschrijving (nog) niet bekend    22-08-2018    23-08-2018
LOPQVW      Verwijderen Produktieorder-Regels    17-08-2018    24-08-2018
Logged
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.073 seconds with 19 queries.