Open matthiasoliveiro opened 4 years ago
Hierbij is het dan wel de truc om dit model zo licht mogelijk te implementeren, het complete verhaal kent bijna 300 attributen. Das gewoon overkill.
Tweede aandachtspunt is dat sommige van deze gegevens binnen commonground in andere componenten belegd zijn. Het doel van het datamodel van dit component zou dan wat mij betreft ook moeten zijn om het “gat” tussen andere componenten (zo as orders, pdc en contacten) op te vangen zodat de volledige dataset rijk genoeg is om een e-Factuur te genereren. Of dat vervolgens ook de weergave vorm is is dan trouwens weer aan de BL (hoewel het ondersteunen van het format wel een nice to have zouu zijn wat mij betreft)
Ten positieve is het ondersteunen van een logius standaard natuurlijk een beetje een no-brainer. En kan e-Factuur de koppeling met de financiële administratie een stuk vergemakkelijken.
We moeten het datamodel sowieso gaan mappen op de gegevens die nodig zijn om een betaling op een nette manier in ons financieel systeem te krijgen.
Verkeerde link verwijzingen:
op de linkjes na (is een algemeen probleem waar een apart issue van #438) kan dit gereviewd worden
Op missende documentatie bij query string parameters na, akkoord
Voor dit component stellen wij de EN-16391-1 norm met de NLCIUS inperking van het datamodel voor. Wij willen deze norm volgen als zijnde een Europese richtlijn met landelijk bepaalde inperking. Om binnen Nederland geldige e-facturen te versturen moet deze norm worden geïmplementeerd.
Taken lijst todo:
Checklist Definition of done