DataM

- Geen naleveringData nodig voor klant DeDecker (6780), want meestal is deze info te groot voor het renderen van de PDF in DocBase.

- naleveringData wordt nu afgekapt na 30 items. (40 was te hoog)

- naleveringData wordt nu afgekapt na 40 items.

- na Refactor => nog een kleine aanpassing indien meer dan 20 items, want probleem in DocBase wegens plaatsgebrek :-P

- DelimiterNaKorttekstInfo wordt ":" om alles op 1 lijn te zetten.

- Refactor => De tekstlijnen, met uitzondering van de titellijn, zijn nu herleid tot 1 enkele Opmerking => Bugfix omdat er een Leverbon was met teveel Opmerkingen-tags en dit een error gaf in Docbase

- Rechtstreekse leveringen via bon kunne bepalen.

- Toevoeging check of KlantId op gevonden order wel zelfde is als KlantId op de bon => range wordt hergebruikt dus check is niet overbodig, doch ook niet helemaal sluitend, maar toch al tot de klant zelf beperkend

- Kleine refactor van logica van opeenvolgende stappen

- Toevoeging dat het om richtdata gaat => codechange

- Komma wordt nu indien nodig wel correct verwijderd

- Uitbreiding extra UnitTest => Er zijn 2 orders met elk 2 ProductOrderLijnen met zelfde producten erop

- Ophalen van vertalingen voorzien in de code => Naleveringen per

- Todo => Deploy van vertalingen, TestCase

- OrderId wordt nu mee in de naleveringsdata gezet.

- DateTimeApi er weer uitgehaald => datum-vergelijk en -omzetting tot "asap"-melding indien nodig => gaan we bij nader inzien toch niet doen

- Todo => Vertalingen, TestCase

- Refactor na review => Maakt nu gebruik van LeverAdresRepository met query-functionaliteit en bijhorende TestCase

- Bij het loggen van schaarsheid van plaatsen voor nieuwe leveradressen is het nu een error ipv een warning en bovendien wordt vanaf nu pas gelogd als er nog maar 10 plaatsen vrij zijn => betekenisvoller dan 100 vrije plaatsen => dat was niet acuut genoeg om al op te handelen

- Aantal vrije plaatsen wordt nu correct berekend

- Logging-meldingtekst verduidelijkt

- write eruit

- lijst uitgebreid

- KlantOrderInstellingen aanpassen zodat LBX en TBX kasten kunnen besteld worden

- NevesBelgium toegevoegd in IsExtraAfdrukVanOrgaluxEtikettenNodig

- Gerelateerd aan vorige aanpassing, zijnde [ICT-759] [rvWV] PM: Maatwerk: BOMBOL VHIP481: Waarschuwing indien wijzigen variant die reeds voorbij orderklaar is:

- OrderService => Niet het Order moet bewaard worden, maar wel de OrderLijn, want daar zit de wijziging op. Order bewaren op die plek is overhead, want is op PRNr op OrderLijn na ongewijzigd.

- ProductOrderlijn => Property ProductIdIsGewijzigd als pointer om op juiste moment indexen te killen en rebuilden => Gebeurde blijkbaar (nog) niet in hoofde van de ProductUpdater, door vorige implementatie van VerwijderIndexenIndienNodig en BouwIndexenIndienNodig.

- ProductOrderlijn => Indexen rebuilden in ZetProductID weggehaald (was toevoeging in bovengenoemde story) => Was onzinnig, want in SWNODE^FLOWORD2 wordt gepersisteerde data opgehaald en die is op dat moment nog ongewijzigd (nog met oude PRNr) => Zou dus enkel de VerwijderIndexen ongedaan maken ipv de nieuwe te zetten.

- ProductOrderlijn => Voor rebuilden van indexen na zetten van ProductID voor ProductUpdate wordt nu vertrouwd op de Save => Die doet de Save van de Super vooraleer de indexen te rebuilden, dus al met juiste data opgehaald in SWNODE^FLOWORD2.

- ProductOrderlijn => Geen event ingesloten => Order2Admin volgt sowieso nog.

- DataMProductOrderlijn-Mock uitgebreid met Save.

- Bon markeren als rechtstreeks te leveren.

- AxSaledID van de bon kunnen ophalen.

- erin geslaagd om de testen niet in de vhUnitTest package te steken. mea culpa :)

- nieuwe logica op basis van aap-halux-klantinstellingen (niet meer met hardcoded lijstje werken)