AutoComplete.cls.xml

Naar analogie van de method hierboven... de Quit zou waarschijnlijk beter zijn "SpecialWorkshopSifonlade".
Je gaat het dan wel overal moeten aanpassen natuurlijk, waaronder bovenaan in deze klasse in de VALUELIST.
M.a.w. idem als in de DISPLAYLIST.

Het probleem is dat je hier echt aan het randje zit van wat Windows aankan met de volledige bestandsnaam (247 karakters). Als dit langer is wordt er helemaal geen bestand aangemaakt.

Voor deze IT (BinnenladeLadeKleurW7) heb ik alvast de 006 terug toegevoegd. Dan zijn er in totaal 246 karakters voor de special workshop ImportFile met 100-999 aantal stuks.
Voor de LosseComponenten: volgens mij had deze oorspronkelijk ook geen nummering? Hoe dan ook zou dit in totaal dan 247 karakters zijn met een nummering, toch een beetje gevaarlijk lijkt mij (hoewel nipt mogelijk).

ProductTypeApi en ToeleveringService mogen terug verwijderd worden wegens uiteindelijk niet gebruikt (zie ook verderop).
P.s.: Ook als parameter en als property te verwijderen!

En eveneens niet vergeten de nodige aanpassingen door te voeren in bijhorende testcase: vhUnitTest.APPS.Halux.PPS.Activiteit.impl.TAOR.LijstVerwerkers.Opdeelzaag.OptimalisatieBestandenGenerator.VoerUit.TestProductGroep

Ik mis nog een test met als rol "Front".

Ai, dat is spijtig, dat je hier die "006" hebt weggelaten. Hierdoor staat de W7-specifieke test niet meer proper net onder de niet-W7-specifieke test. Dat zie je overzichtelijk als je deze klasse opzoekt via SVN. Die test-nummering heeft een doel
Hetzelfde geldt tevens ook voor de LosseComponenten-test!

Ik zou "ProductieGroep" niet afkorten in de variabelenaam, hij wordt door deze ingreep al meer dan voldoende ingekort
Dus: ProductieGroepEnum.

Bovenstaande private method BevatBatchProductMetBewerkingInSpecialWorkshop mag verwijderd worden, wegens uiteindelijk toch niet gebruikt (zie ook hogerop)

Property IsSpecialWorkshop mag terug verwijderd worden, want wordt uiteindelijk toch niet gebruikt (zie ook verderop).

Opkuis: Lijn in comment doet niet veel

bij voorwaarde (X="A") || (X="B") wordt soms gediscussieerd of je dan wel StringUtils.equals() moet gebruiken, of dit mag laten staan.
Bovenstaande pleit ervoor om toch met StringEquals te werken, want dan had jij nu bij deze uitbreiding geen review-opmerking van mij gekregen :-P
Bij deze ... helaas dus wel : hier StringUtils gebruiken aub.

hier nog een (in eerste instantie belachelijk simpele) test voorzien die gewoon checkt of mvx op lijn 4 komt. Het zou kunnen zijn dat er later meer logica aan te pas komt, maar dan is de test al voorzien (om direct uit te breiden)

aangezien implementatie er vrij dummyachtig uitziet, is deze lijn (momenteel) overbodig