ProductVolgensAxAttribuutBepaler

Mail productupdate AX

- Na review: Extra testje voor RequestConverter indien NIET SalesPriceBOM

- Casing aangepast voor leesbaarheid => vermijden dat sommige mensen in 1e instantie denken dat het over een event gaat :-D

- In GeefLadeVariantVanRangeVolgensProductId, ENKEL gebruikt door GeefProductIdVrij => Indien LadeVariant niet gevonden => Error-logging afgezwakt naar Info => Kan immers normale verwachte case zijn =>

=> indien range op was bij uitbesteding heeft ProductIdRecycleerder lege ProductId teruggegeven => ProductVolgensAxAttribuutBepaler heeft daarop een geheel nieuw Product gemaakt, waarvan de ID vervolgens in de RequestConverter wordt gebruikt om GeefProductIdVrij-call mee te doen

- Check op timestamp en indien nodig automatische vrijgave van ProductId's en indien nodig logging

- Bijhorende UnitTest

- Logging => ProductId vrijgegeven voor LadeVariant

- In de dedicated Global wordt in de data nu een 2e piece bijgehouden bij gebruik van een ProductId met daarin een Horolog

- Logging bij PersisteerRange

- Uitleg in comment ivm uitbreiding van ranges verduidelijkt

- Logger geïnjecteerd in constructor

- Logging uitgewerkt voor indien Schaarste in de range

- Bijhorende UnitTest

- CheckRangeOpBeschikbaarheidProductIds uitgebreid met 2e parameter => opgegeven komma delimited string van ProductIds checken => voor uitbreidingen

- Lokale BestaatProduct verwijderd => is door bovenstaande uitbreiding overbodig geworden

- 2 extra testjes hieromtrent

- Test-range beetje uitgebreid voor meer diversiteit

- Extra testje erbij

- Verduidelijking in de verklarende comments over het gebruik van methods: CheckAlleRangesOpBeschikbaarheidProductIds, CheckRangeOpBeschikbaarheidProductIds en BestaatProduct

- GeefTeRecyclerenProductId in ProductIdRecycleerder geeft nu eerstvolgend ProductId terug uit juiste range

- Implementatie GeefProductIdVrij

- In RequestConverter => al voorlopig check of het over juist case gaat en in dat geval voorziening in comment om GeefProductIdVrij op te roepen en ProductId na afloop weer vrij te geven

- Gerelateerd aan vorige aanpassing, zijnde [ICT-759] [rvWV] PM: Maatwerk: BOMBOL VHIP481: Waarschuwing indien wijzigen variant die reeds voorbij orderklaar is:

- OrderService => Niet het Order moet bewaard worden, maar wel de OrderLijn, want daar zit de wijziging op. Order bewaren op die plek is overhead, want is op PRNr op OrderLijn na ongewijzigd.

- ProductOrderlijn => Property ProductIdIsGewijzigd als pointer om op juiste moment indexen te killen en rebuilden => Gebeurde blijkbaar (nog) niet in hoofde van de ProductUpdater, door vorige implementatie van VerwijderIndexenIndienNodig en BouwIndexenIndienNodig.

- ProductOrderlijn => Indexen rebuilden in ZetProductID weggehaald (was toevoeging in bovengenoemde story) => Was onzinnig, want in SWNODE^FLOWORD2 wordt gepersisteerde data opgehaald en die is op dat moment nog ongewijzigd (nog met oude PRNr) => Zou dus enkel de VerwijderIndexen ongedaan maken ipv de nieuwe te zetten.

- ProductOrderlijn => Voor rebuilden van indexen na zetten van ProductID voor ProductUpdate wordt nu vertrouwd op de Save => Die doet de Save van de Super vooraleer de indexen te rebuilden, dus al met juiste data opgehaald in SWNODE^FLOWORD2.

- ProductOrderlijn => Geen event ingesloten => Order2Admin volgt sowieso nog.

- DataMProductOrderlijn-Mock uitgebreid met Save.

- Aanpassing van logging- en e-mail-tekst

- Verwerking review => GeefOrderLijnIteratorVolgensAxInventTransId moet GeefOrderLijnIteratorViaAxInventTransId zijn

- De orderlijn wordt dan toch NIET aangepast indien de toelevering al is klaargezet of in batch zit

- ToeleveringService => naamwijziging publieke method van IsOrderLijnAanTePassen naar VerwerkToelevering en is nu procedure ipv functie

- Orderlijn wordt nu gewijzigd ongeacht of VerwerkToelevering iets heeft kunnen doen

- ToeleveringService => actie van VerwerkToelevering is NIET meer om Toelevering aan te passen maar om ze indien mogelijk te verwijderen via de FlowToeService