OrgaluxBonOptimizer.cls.xml

- Maximale productgrootte 1 cm vergroten

- Fout rechtzetten

- Na reviewopmerking kwamen toch fouten door

- Reviewopmerkingen

- Indien het aantal bij boxdata op -1 staat moet dit stuk niet worden gemaakt. Dit is ook enkel het geval bij Meta 470 die geen snijrecept bevat.

- Indien een bon maar 1 product bevat die niet stapelbaar is, dan moet ook geen optimalisatie gebeuren of snijdata aangemaakt worden

- Nodige wijzigingen voor gegroepeerde producten anders dan OL matten

- Overdoos een centimeter marge geven zodat dozen makkelijk in overdoos kunnen worden geplaatst

- Basishoogte verpakking matten verminderen

- De partialloadonfloor (richting van stapeling) niet meer laten meetellen gezien dit eigenlijk geen meerwaarde is omdat het spelen met dimensies dit impliciet al omvat

- Logginginformatie wat aanpassen

- ContainerId aanpassen want was voor alle parallelle requesten hetzelfde waardoor cubeiq in de knoei geraakt. Uitleg van leverancier cubeIQ: 'If you’re using the same container id with different dimensions in parallel calls you’ll get in trouble at some point. To us, a container represents a single physical thing which should never really change, so those data items are stored in a central cache, not per thread. Just as an explanation: we cannot afford to store multiple copies across all threads since we have customers with millions of data items and things get pretty huge.v

- Enkel lijnen met aantal > 0 zijn relevant voor stapeling

- PRNr komt best niet op 0, beter null :)