AKP

- Verwerking Factuur berichten (INVOIC02)

- Review opmerkingen

- de receptienummer moet bepaald worden adhv Onvangstjournaal nummer. postfix in functie van hoeveel recepties er zijn, max 10 (0 tem 9)

- prefactor: BlumProductAPI los van ProductAPI

- review opmerking

- bijkomende routine uitvoeren om ontvangen stock mee in de 'on hold' voorraad te krijgen

- andere falende test door fake die niet automatische gegenereerd mag worden.

- Opkuis niet functionele code

- falende testen door wijziging in TestRunner op common repo

- Zetten van Applicatie op de context in de oproepende code gezet.

- $Get toegevoegd : receptie nummer bepalen van een zending is nogal moeilijk als het transport bericht zelfs nog niet is verwerkt.

Facturen worden gescheduled verwerkt, transport berichten niet, dit is bvb mogelijk op niet werkdagen zoals w-e dagen.

- Indien de referentie van een manuele toelevering eindigt op een blanco, verdwijnt deze bij overname in ^Verv

- Blum stuurt nog wel de blanco door in de factuur, en daarom mismatch. trim toegevoegd.

- We proberen geen prijs meer op te halen als we geen productnummer hebben.

- Fout bij manuele toeleverings lijnen bij voorbewerken factuurbericht om meerdere lijnen voor een zelfde toeleveringlijn samen te tellen.

- fout bij verplaatsen van dummy factuurlijnen naar de echte factuur indien deze meer dan 100 lijnen heeft

- maken dat verwerking niet vastloopt op toelevering die niet meer bestaat. (beschouwen als manuele toelevering, zodat dit in admin kan opgelost worden).

- Elimineren van voorloop nul gaf probleem in bepalen factuurtype

- Factuurnummer in pdf filenaam en XML verschillend (voorloop nul in factuurnummer)

- Archivering pdf ging niet naar juiste folder (jaar ontbrak).

- kinderziekten + combinatie van VH die lijn annulleerd/opnieuw aanmaakt

- opkuisen writes

- Review opmerkingen

- opkuis writes