EventHandler

Repository maken over Flow.Uitlevering.Hoofding ? encapsulaties gebruiken waar het kan? overweeg met PRA om te zien of het de investering waard is.
Indien niet gebruik maken van encapsulatie:
nu wordt 2 x $Order uitgevoerd voor één uitlevering. zo ook voor de volgende whiles
Dat kan beter
Na de rest van de code te bekijken : Repository maken (resulteert in één iterator en testbaarheid of meer dan één uitlevering correct afgehandeld worden.

ik zou dit toch over een paar lijnen spreiden, gaat wat leesbaarder worden dan.

Private?

Wat doen we met Data?

grrrrr...

grrrr....

Maak hier een specifieke method voor waarvan de naam betekenis heeft. 63 zegt niet veel. cfr andere opmerking op de impl hiervan.

cfr andere opmerking in implementatie

Lijkt me 2 mooie methods om private te zetten en dan in specifiek genaamde methods voor speciefieke gegevens te gebruiken.
Nu staat er ergens anders in de code een getal 63 te blinken....

// GeefVerzendwijze methode gebruiken uit apps.common.dataservice ipv zelf rechtstreeks %OpenId te doen

//$Not van maken ipv '

// GeefBon --> Geef klant --> via objecten oproepen, niet rechtstreeks via de global

//$Not van maken in plaats van ..VerzendwijzeUitgesteldPakbonBoekenAx(bon, klant) = $$$False

een else kant toevoegen met een log

else

// var hernoemen naar GeneratePakbonMagGeboektWordenResult en ook het vereder gebruik , argument in methode aanpassen

Niet gewoon gebruik maken van de globals maar de gemapte objecten gebruiken zoals Geefbon
Daaraan een methode toevoegen als en Zetvlag(new)
De zet vlag zal dan onderstaande set piece bevatten

ctor toevoegen en injecteren van de geeforderapiservice niet via context

VerwerkRecord hernoemen naar VerwerkBon (dit is iets duidelijker)

• Naamgevingen verduidelijken
• Geen engelse stukken vb VerzendwijzeLONG..
• {} plaatsen volgens cache standaard
• Zie ook confluence notities voor dit ticket

De specs waren hier mss niet duidelijk genoeg, maar per productlijn genereer je hier identieke lijnen (wat vroeger niet het geval was vanwege de inventsync die uniek is)
Al de informatie die je in het bericht moet steken kan je bepalen adhv bon, je hebt de lijnen niet nodig.
Je moet dus eigenlijk maar één lijn per bon voor zien.
AX kan er tegen, maar ze geen x keer de zelfde bon markeren dat geboekt mag worden.
Dit gaat de opzet van de test mocks data etc ook wat eenvoudiger maken

Algemene opmerking code conventions volgorde van elementen van een class
1 parameters
2 properties
3 Constructor (%OnNew)
4 Public methods
5 Private methods

voor Testcases onbefore* en onafter* methods voor de eigenlijke test methods

zie alg opmerking codeconventions

Meegeven van GeneratePickingCompleetResult kan nu nog.
Voor de volgende fase, het uitgesteld raisen van de event heb je dat resultaat niet meer...
Test op pickingcompleetresultaat dus in deze method steken.
Of anders refactoren bij implementatie 2e fase