VerpakkingOnderdeelBuilder.cls.xml

Ter info :
1) Alles in één testklasse is oké; maar je kan ook meerdere testklasses maken, met naam .TestLosseComponentInBulk.cls en .TestBOG.cls
2) Testklasse bevat meestal ook de naam van de public method die je aan 't testen bent. Maar misschien werd de naam dan te lang.
Je hoeft dit hier niet te veranderen, maar is taak van reviewer om dit op te merken

Deze method doet exact hetzelfde als ..BestelEenheidLosseComponentenInBulkBepaler.GeefBestelEenheidZRFLosseComponentenInBulk()
Uiteraard klopt dat ook qua resultaat, maar waarom staat de code dan dubbel? --> dubbel onderhoud.
Misschien kan je hier (BOG) de implementatie van LosCompInBulkk laten oproepen.

SCA: Momenteel geen aandacht besteden aan pallet-inhoud!

Kaartje UST4201 aangemaakt

OnBeforeOneTest() --> zelfde opmerking als bij de UT DoosBepaler

DoosBepaler als property invullen via OnBeforeOneTest() zetten --> telkens één regel minder, overzichtelijker

Dezelfde method ook toevoegen voor "Rug" : VerwachtMethodCall("GeefBreedteInMM")

De Key van PRBS is nu altijd "LOSSECOM" , hiermee loop je het risico dat sommige onderdelen zullen worden samengeteld en dus als 1 gesommeerde bouwsteen zullen getoond worden.

Ook hier kan je best specifiek per "onderdeel" een Key toekennen (zie vhDeploy.Maatwerk.LBX.BouwsteenmappingxTAXVerpakkingen )
VPRUG / VPZIJ / VPFRO join DOO / INS / SPC / VDP / VUL

Zoals mondeling besproken :

Naam meer expliciet maken :
analoog aan "Front dekseldoos" - "Zijkant_Links tussenschot" , ...

Omschrijving product aanpassen/vertaling (van Rol ?)
Is ook reeds hierboven aangehaald, in ProductieDetailBlad.xml
--> aanpassing zal meteen op beide bestanden effect hebben. Twee vliegen in ene klap

Etiketten voor nieuwe dozen toevoegen. Dit staat al reeds op je planning (Analyse + PvA + impl.)
dus deze comment enkel als reminder

Pallet inhoud : de aantallen moeten uiteindelijk terug aangevuld worden, hé.

N.B.: ik vind het wel een beetje vreemd dat deze aansturingsactie zich baseert op de verpakking. Tenzij dat de reden is : "omdat we hiermee de juiste aantallen van iedere 'doos' kennen."

LosseComponentenZRF_Doos + _Insert + _Spacer + ... --> deze moeten nog "vertaald" worden. Maak hiervoor gerust een nieuw kanban-kaartje aan.

var DoosConfiguratieBepalerRug --> algemeen: DoosConfiguratieBepaler