Omvormen via Produktieorder volgens methode #1 reserveerde altijd het hele Inputitem, en splitste de Output van de Produktieorder op in een deel 'Opdracht' en 'Restant'.
Reden van het restant was feitelijk omdat een Omvorm Opdracht de om te vormen voorraad reserveerde, en we niet een deel van een Voorraad item kunnen reserveren. Daartoe werd het hele item gereserveerd, en werd moest het restant formeel als Output worden opgeboekt.
Omdat er gereserveerd moest worden, zorgde methode #1 ervoor dat er pas een Omvorm Opdracht kon worden uitgeschreven, indien de voorraad daadwerkelijk op voorraad aanwezig was. Het was dus niet mogelijk om alvast een produkt in te kopen, en deze op voorhand om te vormen naar een andere Verschijningsvorm.
Omvormen via Produktieorder volgens methode #2 reserveert helemaal niets meer. Daarmee kwam ook de Outputsoort 'Restant' te vervallen, immers, het restant is er alleen maar bij de gratie dat we een deel van de input verbruiken, maar het hele inputitem moesten reserveren.
Tevens rond "Omvormen Produktieorder via methode #2" de benodigde Input expliciet af op hele Verschijningsvormen, met (optioneel) de mogelijkheid om dit benodigd aantal Verschijningen te verhogen. E.e.a. is ontwikkeld met als uitgangspunt dat bij het ompakken van een produkt uit poolbakken van 20 Kg naar dozen van 5 Kg, tevens eventuele 'rotte' produkten eruit gehaald worden, en er derhalve meer input nodig kan zijn afhankelijk van de kwaliteit van de partij. Als voor het Omvormen naar 100 dozen van 5 Kg 25 poolbakken van 20 Kg nodig zouden zijn, dan mogen we de benodigde hoeveelheid overschrijven tot bijv. 28 poolbakken, in welk geval we 100x5 Kg omvormen uit 28x20.
Omdat de Opdracht "100x5" is, zal de kostprijs van deze partij worden bepaald door de waarde van 28x20; de prijs per eenheid zal dus iets duurder worden.
Misschien iets minder voor de hand liggend, maar feitelijk blijkt uit bovenstaande dat op het moment dat we slechts 1 doos van 5 Kg zouden willen afvullen uit een poolbak van 20 Kg, de resterende 15 Kg verloren gaan, immers, er zijn geen restanten.
Nb: Dit betekent ook dat deze methode zich niet leent om een blikje van 20 liter af te vullen vanuit een vat van 200 liter, danwel om een vat om te vormen vanuit een grote tank. Een heel vat naar 10 blikken van 20, danwel de hele tank naar vaten is geen probleem, maar, zonder restanten zou de enige output 'het opgegeven blik/vat zijn'.
Omdat Omvormen Produktieorder via methode #2 niet vanaf de basis opnieuw is opgebouwd, maar teveel is gekopieerd van methode #1, blijkt nu dat er nog wel degelijk koding geraakt kon worden inzake restanten, waardoor er van alles mis gaat.
Het lijkt erop dat restanten getriggerd konden worden zodra de inhoud vanwaaruit werd omgevormd, niet netjes deelbaar is door de inhoud waarna wordt omgevormd, Ofwel, het omvormen van 25x10 kg naar 40x5 leverde geen restanten op, omdat 10 deelbaar was door 5. Zouden we echter 8x3 omvormen uit 3x10, dan hadden we ineens wel te maken met een restant.
Nog erger werd het als we toch zouden proberen om een vat van 200 liter om te vormen uit een tank van 1000 liter, hetgeen nl. de hele tank van 1000 liter als input nam (waardoor de prijs per eenheid 5 keer te duur werd) en de totale waarde van deze 1000 liter vervolgens toekende aan zowel het Opdracht deel (zo was het ook bedoeld, immers er behoorden geen restanten te zijn), maar ook aan het restant. Resultaat was een verdubbeling van de voorraadwaarde.
Met het elimineren van de restanten wordt het per definitie niet meer mogelijk om deze funktionaliteit te gebruiken om vanuit een tank van 1000 liter om te vormen naar een vat van 200 liter, immers, er wordt geen restant opgeboekt.
Er is dan ook gezocht naar een oplossing in de hoek van het niet afronden van de input op hele verschijningen, in welk geval het niet noodzakelijk is om de hele tank als input te gebruiken, maar slechts het benodigde deel. De daarvoor benodigde opdracht "ik wil graag 200 liter afboeken, maar dit moet uit de verschijningsvorm tank komen" laat zich niet registreren in een Produktieorder; immers, zodra er een Verschijningsvorm aan de orde is, zal aantal x inhoud gelijk moeten zijn aan het benodigd aantal eenheden, en dit hoeft niet altijd zo te zijn. Als ik 4x6 (24 Kg) wil omvormen uit dozen van 5 Kg, heb ik 4,8 doos nodig, en halve dozen kunnen we niet kwijt. Vervolgens kunnen we willen stellen dat we 5 dozen van 4,8 kg nodig hebben, maar er zit 5 Kg in de doos, dus ook dat werkt niet.
"Ongeacht de Verschijningsvorm" zou wel een oplossing zijn, ware het niet dat we bij de Omvorm Opdracht expliciet aangeven dat het de tank of het vat is van waaruit moet worden omgevormd. Technisch zou er "geacht Verschijningsvorm" moeten worden afgeboekt op de wijze van "ongeacht Verschijningsvorm".
Behoefteruntechnisch zal dit ook de benodigde implikaties hebben.
Al met al zal m.i.v. deze Releasenote zijn gesteld dat Omvormen via Produktieorder volgens methode #2 GEEN restanten meer kent; nimmer.
Zoals de beschrijving van deze funktionaliteit al aangeeft (zie
http://ha1.heartprofit.nl/profit/index.php?topic=18.0) is de funktionaliteit daarmee ook meer bedoeld voor Ompakken dan voor Omvormen.
Nb: Waarmee er overigens wel iets voor te zeggen is, dat dit 'naast' de bestaande methode #1 werkt, en niet 'in plaats van'.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOOOTV2 | Toevoegen Omvorm Opdracht | 16-05-2007 | 25-07-2007 |
| LOPOAVGK | Goedkeuren Produktieorder | 15-06-2007 | 26-07-2007 |
| LOPOGVB3 | Omschrijving (nog) niet bekend | 13-07-2007 | 26-07-2007 |
| LOPOGVBK | Opboeken Gereed Artikel/Versch | 13-07-2007 | 26-07-2007 |
