DataBouwer.cls.xml

Is nu A en B, met beter geformuleerde asserts (AantalA, BestaatA, ...) en een verbeterde VoegToeProductOrderLijn() en VerwijderData(), die tegelijkertijd nu makkelijker uitbreidbaar zijn.

Na overleg hebben we dit issue laten vallen wegens het sop dat de kolen niet waard is?

Zoals besproken LegacyPartijAPI.GeefKlantNummerVoorPartijID() gebruikt, wegens niet voor AX bedoeld, maar voor Caché-intern gebruik.

Ik weet dat dit op veel plaatsen gebruikt wordt, maar er bestaat ook de AXimpl.AdminToAxUtils (die gaat wel lpadden). En eigenlijk is dat misschien wel juister, aangezien ge hier overal met AX-klantids aan het werken zijt (dus hoe dan ook 5 karakters lang (ook in repo))

Ik zou deze elvendertig calls ook in de onbeforeonetest steken. Op het eerste zicht zie ik maar 1 verwachtmethodcall hierop en principe overrulet die de reeds bestaande indienmethodcall. Op die manier blijven de testen wat meer beperkt tot hun essentie. (of ik heb mij miskeken)

Ik zou al die namen met 8'en en 9's hernoemen. Vind het momenteel nogal moeilijk om direct te zien wat ze betekenen. Wat doet VoegToeProductOrdelijn8(9) bv?
Kan je die twee methods al niet dezelfde naam geven en een extra parameter gebruiken (al dan niet gedefault)? Dat bespaart weeral een (bijna) duplicate private method. En waarom 8 en 9 en niet 1 en 2? precies dat de eerste 7 nog ergens anders staan