End2End

TestFiles reviewen, is in dit soort stories bijna onbegonnen werk. Ik heb zo goed en zo kwaad mogelijk de changes bekeken.
Alvast bedankt om het aantal testfiles te filteren.
Het geheel lijkt me wel oké te zijn.

Ook in eCon enkele commits gereviewed.

De dossiercode "LI7K" was blijkbaar een onbedoelde tussenstap (Tricky situatie met de TAOR Losse componenten)
In combinatie met svn rev. 69413 is dit wel een correcte overgang.

Hierbij is deze change nagekeken en goedgekeurd!

FYI: Ik vind het zeker oké dat je hier de ##super hebt weggelaten. (de gegenereerde code die daar stond was eigenlijk zelfs niet correct : LadeHoogte is enum en dus niet in MM uitgedrukt )
De impl in deze afgeleide klasse is wel correct.

De implementatie voor "Lengte" hieronder zou ik wel in een private method steken, analoog aan GeefFrontPlaatHoogte()
Zo blijft deze method simpel leesbaar en overzichtelijk. En dan is de scope ook duidelijk, nl. dat Kleur W7 enkel impact heeft op de kenmerk "Lengte, en niet op de "Breedte" van het Front.

copy-paste foutje :
"... kan niet gemaild worden."
(ook al is de conditie altijd false :-P )

Deze method GeefPalletDraagstructuurProductId() zou eigenlijk beter verplaatst worden naar de builder zelf : private method in HFVerpakkingv001PalletDraagstructuur.cls
Zo vermijd je om de waarde via de constructor te moeten doorgeven.

De HFProboxPalletv001 wordt toegevoegd, hier in de "Verwerk verpakking Pallet" en tegelijkertijd staat er in de builder HFProboxPalletv001 dat "Aantal = 0" indien verpakking pallet.
Waarom dan niet gewoon die Builder hier NIET toevoegen. Da's toch minder complex, of ni?

Deze klasse mag rechstreeks afleiden van MaatwerkProductAlsHFKostItemBuilder (i.p.v. MaatwerkProductAlsHFKostItemBuilderSST)
Zie ook opmerking bij klasse MaatwerkProductAlsHFKostItemBuilderSST

Als de 3 Test-methods alle 3 dezelfde SST-kenmerken gebruiken, dan zal de test meteen veel duidelijker worden wanneer je deze in een private method afzondert,
en enkel de variatie als parameter doorgeeft. In dit geval is dat property Uitvoering en Bewegingstechnologie, denk.

Een andere insteek van Unittest :
Vul enkel die waarden in die noodzakelijk zijn. M.a.w. Hoogte, Breedte, Diepte, Kleur, stekkerType, ... zijn allemaal niet relevant voor deze UT.
Je zou dus kunnen opteren voor een GeefLegeSSTKenmerken() en nadien enkel Uitvoering en technologie in te vullen (or whatever is needed).

Volgens mijn wiskundegevoel is dit gewoon gelijk aan

    KostLade * ..Percentage 

of anders heb ik hier net een bug ontdekt?
:-P

In .NET moeten we wel de "nieuwe standaarden" van VoegToeBuilders() volgen, kwestie van geen KostItemBuilders in de %OnNew toe te voegen.
Hier in caché mag dat wel zo blijven :-P

Deze klasse is een exacte kopie van "DOM.PM.Maatwerk.Calc.Kost.MaatwerkProductAlsHFKostItemBuilder"
Ik zie geen enkele reden of specifieke dependency om een specifieke versie voor SST te maken. Dus wat mij betreft mag deze klasse verwijderd worden.
Of, zie ik iets over t hoofd?

Deze method komt vele malen voor in de Builders (idem voor =Servodrive)
Kunnen we een propere en efficiente oplossing vinden waarbij die method niet telkens opnieuw in de builder moet gedefinieerd worden. Laten we dat samen eens bekijken.

Het "tussen-niveau" ...HalffabItemBuilderBasis is bij SST eigenlijk niet nodig. Dit was wel zo bij de "Matten" omdat je MatX,MatY, ... hebt.
Hier, bij SST, heb je maar 1 klasse, t.t.z. Builder en BuilderBasis vallen samen.
Maar wat mij betreft hoeft dit niet weggewerkt te worden in caché. Misschien wel bij het porten naar .NET

FYI: het was uiteindelijk de dubbele definitie van de method GeefGekoppeldIKType() die voor enige verwarring zorgde. Vandaar de review opm.