Als developer wil ik het Betaal component common ground proof maken

[matthiasoliveiro]

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.

Organisatie	Standaard	URL
stpe	e-Factuur	https://stpe.semantic-treehouse.nl/#/Standard/Standard_1528543874_00976362

Taken lijst todo:

• Architectuur afstemming
• Ontwerp gegevens model
• Realisatie
• Postman testscripts
• Documentatie Redoc
• Testscripts aan leveren aan testvoorziening
• Voorbeeld implementatie
• Code opleveren in Utrecht repo

Checklist Definition of done

• Oas documentatie
• Postman scripts (test scripts)
• Aangeleveren testscripts aan de api test voorziening
• Containers moeten gepubliceert zijn
• Gereviewd op de design decisions
• Voorbeeld implementatie beschikbaar
• Redoc moet beschikbaar zijn
• Documentatie moet beschikbaar zijn op github-pages
• NLX integratie moet werken

[rubenvdlinde]

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.

[matthiasoliveiro]

• Test voorziening geeft niet thuis en kunnen we niet afronden.
• Github pages is een strech goal en een nice to have, we hebben het nu ander opgelost via de readme (zie tabel)
• NLX hebben we een andere afspraak voor gemaakt en wordt los opgepakt. Het component is NLX ready maar het staat nog niet aan dat is een andere story

[CMasselink]

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:

[matthiasoliveiro]

op de linkjes na (is een algemeen probleem waar een apart issue van #438) kan dit gereviewd worden

[CMasselink]

Op missende documentatie bij query string parameters na, akkoord