impl

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.

zie hierboven

Is ook gecovered door Method "Test: BereidVoorBestelling plaatst de hoofding op de offerte en bepaalt de mogelijke leverdatums - standaard zijn er geen herberekende lijnen en meldingen aan de gebruiker"()
Ik heb in ieder geval een test toegevoegd die controleert dat er geen verzendingmogelijkheden berekend worden voor standaard klanten.

aangezien deploy wordt er geen aanpassing doorgevoerd.

Wat met klanten zonder transportkeuze?

Misschien beter om de testen hier op te splitsen per method in de Service en dan misschien hier en daar nog een testje bijgooien om wat randgevallen of true-false dingen af te toetsen

ExactAantalKeer(1) om intentie duidelijk te maken

Wat met klanten zonder transportkeuze? Of is dat niet relevant?

Beter een ExactAantalKeer(0) op de MailAPIMock, om duidelijk de intentie te tonen

beter de vhTest.Fake.TECH.Mail ?

Aangezien dit de clou is van de test, kunt ge er misschien beter een ExactAantalKeer(1) bijzetten?

testje voor 0 palletten toevoegen

$$$Not