MaatwerkIterator.cls.xml

Nope. Dan geeft de HasNext() netjes 0, zoals verwacht => Global is leeg => Geen stockverschillen gevonden => Default mailtje zal verstuurd worden met melding hiervan (zonder een onbestaand lijstje mee te sturen).

I'll remember for next time

nitpicking qua naamgeving: ik zelf zou een DataBouwer klasse een BouwHuppeldepup method geven. Als de method StelSamenDingesEnDinges is, kan je dat in een *SamenSteller steken.
Moet dat niet veranderen hoor, maar op veel andere plaatsen wordt dat ook gedaan: een *Bepaler heeft een Bepaal() enzo

juist een vraagske: moet er iets extra voorzien worden voor het geval de resultset leeg is?

Dan is dat nog steeds standaard gedrag, want dan zijn er geen AxConfigIds en blijft die variabele ook netjes leeg. Uiteindelijk doet die klasse, buiten het mailen, niets anders dan de data gemaakt door andere klassen binnenhalen en verzamelen, er wordt verder niets mee gedaan qua logica.

Heet nu "AxConfigIds"

"Ts" is de universele afkorting voor "Tussen"

Testje geschreven.

Done!

Nope. Zie uitleg bij lijn 60

Heb de naamgeving van die parameter wat aangepast, zodat het duidelijk is voor iedereen.

Nope! 'Deze' QtyVH is die zoals die berekent (som) en doorgegeven is door de SyncAllMaatwerk, en hangt dus volledig af van wat er op de OrderLijnen staat (in specifieke gevallen, gedefinieerd in de IteratorFilter van de dynamische Iterator gebruikt door de SyncAllMaatwerk). Het niet leeg zijn van deze parameter zorgt er tevens voor dat de InventSyncCreator weet dat het over een maatwerkproduct gaat dat via de SyncAllMaatwerk gesynct wordt.

Noem deze niet *Lijst, want het is geen %List. Zorgt alleen maar voor verwarring als iemand die wil gebruiken

wat is StockTs?

testen?

Mag volgens mij in een oneliner, want dat blijft leesbaar

Andere bedenking: is het niet beter om ##class(DOM.DomeinContext).Instance().GeefProductTypeAPI().IsMaatwerkProduct() te gebruiken op basis van de prnr? dan moet ge geen extra parameter gebruiken, is de opzet duidelijker en kunnen er properdere testen geschreven worden (eentje met true en eentje met false)
Op een of andere manier blijft het raar overkomen om die QtyVH op deze manier door te geven/gebruiken

ik zou hier op het eerste zicht niet direct de qtyvh doorgeven als parameter, maar ophalen via het PRNr en ProductApi. Dan is dat en passant proper testbaar en een simpelere call

vervang hier dan ineens IsMaatwerk door die haslength van hierboven. Dan hebt ge zo geen mogelijk foute omschrijvingen als 'ismaatwerk' dat afhangt van een of ander aantal.

testomschrijving zegt dat qthlx en qtyblockedhlx leeg blijven. aftoetsen in assert.

klopt het trouwens dat dat leeg moet zijn? moet dat niet 0 of 0.00 zijn? (zie sommige andere testen)