CacheAdminA_trunk2010

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.

Ik snap de redenering maar ik vind dit niet correct. Mss eens in de groep gooien en beslissen wat we hiermee doen?

De testmethod voor de standaardlade staat nu inderdaad dubbel. Dus ik heb ze in deze klasse verwijderd.

Wat de ZijkantLogo-testen van Kurt betreft, daar ga ik wel afblijven, hé

Vond het eerst zelf ook een beetje vreemd, waarom da aangepast is :-P
Verklaring vrij eenvoudig :
Naam moet consistent zijn met de andere vhTest.Utils ... Kenmerken() klassen, omdat de UT's voor de convertoren dit oproepen:

Method "Test: TAX Standaardlade"()
{
Do ..AssertConverter("StandaardLade")
}

Method "Test: TAX BinnenLade"()
{
Do ..AssertConverter("BinnenLade")
}

Method "Test: TAX LadeMetVeelExtras"()
{
Do ..AssertConverter("LadeMetVeelExtras")
}

Anders falen de UT's ... spijtig genoeg.
(normaal gezien moet dan de UT-impl aangepast worden en niet de code, maar deze wijziging heeft geen invloed op de werking van de nietmeeleverens, denk.)
Deze tactiek was ook al toegepast bij LBX door één van m'n voorgangers.

De "ByRef" is hier om aan te geven dat het EconKenmerken-object zal aangepast worden.
Technisch is het niet fout om da als .local door te geven. Objecten worden trouwens altijd als "pointer naar geheugenplaats" doorgegeven.

Principe is bovendien overgenomen van de 2 lijnen eronder, en dat leek mij niet verkeerd om het zo aan te duiden.

Laat zeker weten als je hier toch aan twijfelt.

Zal bij volgende opkuis verwijderd worden.

Vreemd dat deze klasse in de review van UST3954 zit, want is gecommit onder UST3942 :-?
Hoe dan ook : nieuwe UT toegevoegd, maar ook gecommit onder UST3942 .
De review heb ik wel hier toegevoegd, want gij hebt er achter gevraagd :-D :-D