OfferteBerekenaar.cls.xml

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

't is een iterator, alle Isberekend resultaten moeten in rekening gebracht worden, dus && gebruiken.
Als we met False starten zal m nooit true worden.

Kunt ge BerekeningIsVolledig niet beter defaulten op false en dan hier gewoon = Stapeling.IsBerekend?

Waarom een stringske?

Voorlopig kan de introductie van dependency geen kwaad, commentaar toegevoegd dat bij eventuele uitbereiding hier wel rekening mee gehouden moet worden.
nvdr : de term 'Offerte' slaat hier op de 'virtuele' offerte van DHL voor het transport in casu, niet de Vanhoeck offerte die bepalend is voor de goederen die getransporteerd moeten worden.
Wat dit betreft is het aantal laden te transporteren volledig irrelevant, want DHL rekent niet in 'laden', maar palletten.
De afpsraak van 10€ is ts van hoecke en Hein, DHL heeft hier eigenlijk niets in te zien.
Pragmatisch is het wel de minst kostend oplossing om het hier te bereken.

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.