ProductieDetailDocument

ik heb het opgekuist. Dat komt wel goed zonder die controle.

Script zal normaal gezien nog 1x manueel getriggerd worden, en is nadien niet meer nodig. Zal ook niet als geplande taak (bvb. wekelijks) in de background lopen.
Dus eigenlijk zou dit script zelfs mogen gearchiveerd worden.
Anderszijds is dit wel handig (als template) voor toekomstige gelijkaardige gevallen. Daarom zal ik het laten staan.

Bepalen van klantnummer is inderdaad niet alledaags, maar als het werkt..!

Overal waar gelogd wordt naar ^LOG.WV, is dit code die nog dient te blijven bestaan of was dat puur ter hulp bij de ontwikkeling?

Moet dit nog gebeuren of niet? Anders is het mss beter om commentaar te verwijderen?

Mag gerust ingekort worden naar:
"Test: Zet 0 karakters van korttekst in bold indien TBX"

Idem voor die van TAX hierna.

Ter verduidelijking zou je kunnen werken met 3 lokale variabelen (booleans). Dan kun je iets beschrijvends meegeven aan de method GeefProductDetailLijnen, waardoor degene die na jou komt (of jijzelf als het lang geleden is dat je de code gezien hebt) niet naar die private method moet gaan kijken om te weten waarvoor er booleans worden doorgegeven.

Dit is de assert die er toe doet. Aangezien het hier om stringmanipulatie gaat kun je er best voor proberen zorgen dat ofwel:

• deze zo waarheidsgetrouw mogelijk is door echte kortteksten te gebruiken.
• deze zodanig ineen te steken dat datgene wat getest wordt zo snel en duidelijk mogelijk weergegeven wordt.

Je zou dit, in samenspel met de opmerking over de naamgeving van de test, zo kunnen aanpakken dat je deze kortteksten begint met een kleine nummerreeks, gevolgd door iets beschrijvends. Bv:
"123456789 frontbevestiging Exp T"
Dat zou dan resulteren in:
"123<b>4</b>56<b>7</b>89 frontbevestiging Exp T"
Zo is het direct duidelijk dat karakters 4 en 7 in bold komen te staan bij frontbevestiging Exp T.

Je moet niet testen of het V1 is, want je WEET al dat het V1 is, want je hebt in de setup van de test ervoor gezorgd dat het ZEKER V1 is, dus deze assert mag er overal uit.

"Zet 2 karakters" blijft te algemeen. Je test moet zeggen welke twee karakters, dus bv:
"Test: Zet karakter 4 en 7 van korttekst..."

Naamgeving parameters:
IsV1 i.p.v. IsV1Aanwezig
HeeftFrontBevestiging i.p.v. FrontbevestigingAanwezig

Uitleg:

• We gebruiken elders in de code ook bv IsProbox of IsFlatpackV1. In gedachten zetten we er nog het woord "Verpakking" achter Het woord "Aanwezig" biedt geen meerwaarde.
• Booleans beginnen bij grote voorkeur met "Is" of "Heeft".

Ook bovenstaand codeblok mag wat refactoring ondergaan...
Je checkt 2 keer op HeeftFrontBevestiging, dus daar kun je dan beter eerst een selectie op maken:

If HeeftFrontBevestiging {
    ... Hier dan een genestte If-Else-structuur voor al dan niet FrontbevestigingExandoT
} Else {
    ...
}

P.s.: Geen ElseIf nodig dus, maar als je hem wel gebruikt, dan een grote I alstublieft

Bovenstaand codeblok zou gerefactored moeten worden. Aangezien de helper-methods ook werken met booleans als parameter, hoef je hier geen if-else-structuur te maken. j kunt hier gewoon 2 calls doen en de aangeleverde booleans hieraan meegeven:
Do ProductDetailLijnen.Insert(..GeefProductDetailLijnVerpakking(IsV1Aanwezig)
Do ProductDetailLijnen.Insert(..GeefProductDetailLijnOnderdeel(FrontbevestigingAanwezig, FrontbevestigingExpandoTAanwezig)