OfferteBerekenaar

Naar deze enu's wordt nog verwezen in APPS.EC.Transport.Service.cls. Moet die ook niet aangepast worden? Zit niet mee in review.

Naar deze dto's wordt nog verwezen in APPS.EC.Transport.Service.cls. Moet die ook niet aangepast worden? Zit niet mee in review.

deze heeft er niet zo veel mee te maken zou ik zeggen. Probleem dat die mee in de commit zit?

Als dit naar productie gaat, zeker ook de caretakerjob via de caché-systeembeheerportaal afzetten

OfferteBerekenaar heeft voor zover ik me herinner geen afhankelijkheden naar data zoals offertes en winkelkarren. M.a.w. deze software zou berekeningen kunnen maken enkel a.d.h.v. berekeninput gegevens.

APPS.TRANSP.OfferteService.dto.BerekenInput heeft lijst van APPS.TRANSP.OfferteService.dto.TeverzendenItem die het aantal bevatten. Dus ik denk dat er met deze gegevens het totaal aantal laden berekend kan worden.

Maarrrr.. ik ben niet zeker of dit ook het geval is met proboxen...Er zit ergens een berekening van aantal lades naar aantal proboxen en mogelijks worden de proboxen als verzendingitems meegegeven. Als dit het geval is denk ik dat er in een hogere laag waar winkelkarren wel gebruikt worden, de berekeninput dto aangepast moet worden met een extra property waarin het aantal lades van daaruit meegegeven kan worden.

"Als" er voor AX een fase komt waarbij ze het berekenen van transport van cache gebruiken a.d.h.v. een webservice met berekeninipnut dto, dan zou dat een goede reden zijn om geen winkelkarren of offertes te gebruiken. Allé, niet om een p.i.t.a. te zijn , maar te overwegen.

Even nagezien : APPS.VKP.impl.OfferteService.VerpakkingConvertor
in geval van probox worden dus eerst de verzendingitems gemaakt met afmetingen en die worden in berekeninput meegegeven. Dus in berekeninput zit het aantal lades niet meer als het probox is, maar het aantal probox dozen.