OnderdelenPickingLijst.cls.xml

Zoals gezegd in de method die deze aanroept... naamgeving is ontoereikend.
Wat de implementatie van deze method betreft... ik zal die reviewen nadat je ze eerst gerefactored hebt, wat dat kan het wel gebruiken
Je hebt hier tot 6 niveau's diep nestingen!! Ik tel 2 While's, 9 Ifs en een Else. Dat is wat veel van het goede binnen één en dezelfde method. Probeer kleine codeblokjes af te zonderen naar private methods, die een specifieke verantwoordelijkheid hebben.
Probeer daarbij ook oog te hebben voor de stukken die eventueel generischer gemaakt kunnen worden, zodat je niet aan code-duplicatie doet. Ik zie daar bijvoorbeeld 2 haast identieke codeblokjes, waarbij er een iterator genewed wordt, de 1e iteratie ervan wordt opgehaald indien die er is, gecheckt wordt of de Count() daarop > 0 en er dan een OnderdelenPickingUitvoeringInfo van wordt opgehaald. Dit leent zich er geweldig toe om af te zonderen met gebruik van generische naamgeving en het doorgeven van louter de juiste list als parameter. Dat zijn zes codelijnen maal twee, die je al kunt vervangen door twee keer één codelijn, bv.:
#dim SequentieNummerOorspronkelijkProduct As %Integer = ..GeefSequentieNummer(OorspronkelijkProduct.PickingsPerMaatwerkProductID)
en
#dim SequentieNummerProduct As %Integer = ..GeefSequentieNummer(Product.PickingsPerMaatwerkProductID)

Waarom een NieuweGesorteerdeUitvoeringInfoIt toevoegen? Is toch niet nodig? Gooi de Else weg, de If zorgt ervoor dat de iterator enkel in de juiste case wordt overschreven.

Minstens even belangrijk: De naamgeving van de method TelAantallenSamenVoorGeleiders laat nogal te wensen over hé, daaruit moet vooral blijken dat ze een iterator teruggeeft en dat blijkt uit deze naam zeker niet.

En ook nog: Tussen de declaratie van lokale variabelen en de eigenlijke logica laten we graag een lege lijn. Dit zorgt voor leesbaarheid