TestStandaardladeverpakkingMet3BodemondersteuningenBepaaltDoorBreedte1800

- Prijscorrecties na laatste aanpassingen => nieuwe testfiles

- Omleiding naar DotNet aangezet voor TAOR => nog nen hoop nieuwe testbestanden

- InterneBreedte wordt nu wel opgevuld door uitbreiding convertor

- DwarsverdelingType is toegevoegd aan een hoop vhTestFiles, part 2

- Nieuwe testfiles omdat PM op vraag van BIDI een korttekst aangepast heeft, voor verduidelijking - deel 2

- HeeftFrontHoogteVerstelling uit opstartfase gehaald => alles is nu HeeftFrontHoogteVerstelling = true

- Utils.DOM-kenmerken => nu MoventoKoppeling

- Al wat testjes gefixt

- Nieuwe testbestanden

- StringUtils Equals gebruikt want haakskes haakskes haakskes

- HeeftFrontHoogteVerstelling op een product geeft nu voor ALLE KoppelingTypes true terug, waardoor alles in de productieaansturing automatisch met HoogteVerstelling gaat zijn.

=> Eerdere poging tot (her)bereken via DOM.PM.Maatwerk.Calc.HF.impl.HalffabSpecKenmerkenAanpasser lukt niet, omdat de bereken voor productie het product niet wijzigt.

=> Op de nieuwe HalffabItemsboom staat dan wel de MoventoKoppeling, maar uiteindelijk wordt in de productieaansturing toch gekeken naar HeeftFrontHoogteVerstelling op het product zelf => dus dan geen witte rook

=> Nieuwe testbestanden

- Nieuwe testbestanden => BevatGeleiderBevestigingSchroeven staat nu altijd op false via de kenmerken, tenzij in Econ bepaald is dat het voor Alpnach via SFS is, waarbij het op true gezet wordt

- Uitbreiding nodige dto-kes en Utils-klassen en convertoren en bijhorende UnitTests met AantalDwarsverdelingen en DwarsverdelingKleur

- Uitsluiting DwarsverdelingKleur in KenmerkDomeinPostProcessor om VHintra-configurator niet kapot te maken

=> Nieuwe testbestanden

- Aanpassing van het productnummer van de veer (nieuwe is 3433118, oude was 1118152).

- Aanpassing van het AantalVeren, zowel voor bevestiging van de rug (volgens LadeHoogte) als van de bodem (volgens LadeDiepte).

=> Nieuwe testbestanden met lichte volgens Kevin aanvaardbare prijsverschillen

- UnitTests End2End TAX

- Nieuwe testbestanden

- Nodige aanpassingen in BOL-builders...

- Builder SpecialWorkShop toegevoegd => Nieuwe testbestanden

- vhTestFiles aangepast : nieuwe korttekst = ZYY.80X60 PLT 1/2 HT XX

- Fix test => verboden breedtes uitschakelen voor BulkPerOnderdeelGegroepeerd en LosseComponentenInBulk

- Tijden kartonmachine => Niet meer nodig voor zijkant, rug en front => testbestanden

- Inpakken => Voor zijkant, rug en front => nu vaste kost volgens LadeHoogte (N en M = 40 --- C, K en F = 55) => testbestanden

- kostenplaats toegevoegd ovor zijkantlogo.

- Niet onbelangrijk => is DiepteVerstelling wel aanwezig => testbestanden

- Palletprijs werd gewijzigd (andere leverancier)

- refactor liet het bord bloedrood worden en aangezien THB/TommyH er niet is vandaag, commit ik deze even.

(initialen hierboven gebruikt om er voor te zorgen dat je deze revisie ZEKER meeneemt)

- not wag unittesten die gewijzigd moesten worden

- insteltijden als kostenbuilder toegevoegd.

- Conversie dom naar apps ook productiewijze volledig. (conversies zijn voorzien om zowel "" als "V" om te zetten. MUST om te testen op accept dat APPS laag nog steeds ok is.

- getest met vhintra. Maatwerkconfigurator en maatwerkviewer = kostberekening. OK

- Losse component verwijderd van dto, samen met vhintra release. vhintra gebruikt nu ook voor losse component de productiewijze.

- productiewijze afgestemd voor intern. bij losse component geen volledig. bij flatpackv1 enkel volledig. bij v1 en probox keuze.

- manueel getest met vhintra. (eventueel nog testen voorzien voor kenmerkenpostprocessor.)

- lossecomponent property is vervangen door productiewijze had dus ook impact op DOM of APPS in convertoren. Verschill tussen "" leeg en "V" volledig. Dit is rechtgezet voor TAX

- Testfiles End2End.