Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: EN/NL toegevoegd


Div
styleno-print
classno-print

NL/EN


Excerpt

Version: 1.04
Date: 01-11-2017

...

Expand
title...

1.1 Doelgroep

Dit document verstrekt een gedetailleerde beschrijving van de Incassomachtigen oplossing van de Nederlandse banken voor Core en B2B. Het document is bedoeld voor degenen die gedetailleerde informatie behoeven ten aanzien van deze oplossing. 

De specificaties in dit document gelden in beginsel voor zowel de Core als B2B oplossing. Echter, waar een specificatie specifiek geldt voor één van de twee producten is dit in twee kleuren aangegeven:

Incassomachtigen Creditors zijn bedrijven die Incassomachtigen willen gebruiken en daartoe een Incassomachtigen contract hebben afgesloten met een bank. Creditors worden geacht een incassocontract te hebben getekend alvorens ze een Incassomachtigen contract aanvragen. 

Dit document is bedoeld voor Creditors die aan willen sluiten op het Incassomachtigen platform van de door hen gekozen Creditor bank. Het behandelt het berichtenverkeer tussen Creditors en hun bank. Voor Creditors is het berichtenverkeer tussen de Routing Service van de Creditor Bank en de Validation Service van de Debtor Bank niet van belang. Dit deel van de Incassomachtigen Standaard wordt daarom in dit document niet behandeld, tenzij de berichten van enig belang geacht worden.

Dit document is niet bank-specifiek; dit wil zeggen dat alleen generieke Incassomachtigen zaken in dit document worden behandeld. Informatie over non-standaard aansluitvormen bij specifieke banken en de hulp-(middelen) die een bank verstrekt om aan te sluiten op Incassomachtigen zijn geen onderdeel van dit document. Voor informatie over deze onderwerpen verwijzen wij u naar de door uw bank verstrekte (aanvullende) documentatie.

Om Creditors verder te ondersteunen, zijn er Software Libraries ontwikkeld in .NET, PHP en Java. Neem contact op met uw bank voor meer informatie betreffende deze Software Libraries.

1.2 Andere referenties

Title

Versie

Verstrekt door

UNIFI (20022)


ISO

SDD Implementation Guidelines

7.0

EPC

SDD Rulebook

7.0

EPC

XML message for SEPA Direct Debit Initiation Implementation Guidelines for the Netherlands. Verkrijgbaar op http://www.betaalvereniging.nl/wp-uploads/ 2013/01/XMLMessage-for-SDD-Version-7.0-February-2013.pdf

7.0

BVN

Payments Mandate Urgent Maintenance en de bericht XSD’s.  Verkrijgbaar op http://www.iso20022.org/full_catalogue.page onder het kopje ‘Pain - Payments Initiation’

oktober 2014

ISO

External Code Sets spreadsheet

13 juni 2014

ISO

De Base16, Base32, en Base64 Data Encodering http://www.ietf.org/rfc/rfc3548.txt 

Juli 2003

Network Working Group

Base64 Content-Transfer-Encoding http://tools.ietf.org/html/rfc2045iDxsection-6.8

November 1996

Network Working Group

Multilingual European Subset 2 (MES-2) Unicode.org http://www.utf8-chartable.de/unicode-utf8-table.pl

15 april 2000

CEN

Open Web Application Security Project (OWASP) http://www.owasp.org

Niet bekend

OWASP

XML Signature Syntax and Processing (Second Edition), W3C Recommendation 10 June 2008 http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/

Tweede editie, 10 June 2008

World Wide Web Consortium (W3C)

GUIDELINES ON ALGORITHMS USAGE AND KEY MANAGEMENT (EPC342-08)

Versie 1.1 goedgekeurd 23 februari 2009

EPC

ITU-T RECOMMENDATION X.690 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

(07/2002)

ITU-T

LC858 Use of encryption algorithms and key management systems for banking applications and systems

7 januari 2011

NVB

TLS Protocol version 1.0 http://www.ietf.org/rfc/rfc2246.txt

1.0, januari 1999

IETF

TLS Protocol version 1.1 http://www.ietf.org/rfc/rfc4346.txt

1.1, april 2006

IETF

TLS Protocol version 1.2 http://www.ietf.org/rfc/rfc5246.txt

1.2, augustus 2008

IETF

Referenties

1.3 Conventies met betrekking tot de notaties

Berichten en redirects worden geschreven als dit, en data elementen worden geschreven als dit.

1.4 Definities van online bankieren

In dit document worden de termen 'internet bankieren' en 'online bankieren' gebruikt. Voor Debtor banken die Incassomachtigen mobiel implementeren, zouden deze termen geïnterpreteerd moeten worden als 'internet bankieren' en/of 'mobiel bankieren'. Waar internet of online gerelateerde terminologie gebruikt wordt, moet dit altijd gelezen worden als ook betrekking hebbende op het mobiele kanaal. In geval het mobiele gebruik van Incassomachtigen tot aanvullende vereisten (requirements) leidt, zullen deze specifiek benoemd worden in deze Implementatie Gids.

1.5 Revisies

Versie

Beschrijving

Release datum

1.02

Versie voor publicatie

10 april 2015

1.03

  • De canonicalization method voor het berekenen van de digest is aangepast naar exclusive canonicalization
  • De archiveringseisen zijn verduidelijkt
  • De eisen aan het formaat van eMandateID zijn toegelicht
  • Het gebruik van het Creditor Adres is toegelicht
  • Toegelicht dat de DateTime in het pain.012 bericht het moment van ondertekenen van de Incassomachtiging is

4 mei 2015

1.04

  • Hoofdstuk 13 is toegevoegd, met informatie over de relatie met de incasso
  • De archiveringseisen voor de machtiging zijn verduidelijkt
  • De eisen aan het plaatsen van timestamps door de Creditor zijn verduidelijkt
  • De XML-tags zijn toegevoegd in de tabellen met XML elementen, zodat de tabellen eenvoudiger te relateren zijn aan de xml berichten
  • Toegelicht dat de elektronische handtekening over de machtiging gecontroleerd moet worden door de Creditor
  • De formaateisen voor het veld maximum bedrag zijn verduidelijkt
  • Creditors mogen in B2B het veld ‘maximum amount’ bij amendments (pain.010) niet meer gebruiken (wijziging ten opzichte van vorige versie zakelijk Incassomachtigen CIG)

31 december

2015

1.6 Wijzigingen in vergelijking met eerdere versies

Wijzigingen die zijn doorgevoerd sinds versie 1.02

  1. De canonicalization method die gebruikt wordt voor het berekenen van de Digest is gewijzigd van inclusive canonicalization naar exclusive canonicalization. Dit heeft impact op zowel de berekening zelf, als het gedeelte van het XML bericht waar het berekeningsproces wordt omschreven.
  2. De eisen aan het archiveren van de originele Incassomachtiging (het ISO pain.012 bericht welke de elektronische handtekening en certificaat informatie bevat) zijn verduidelijkt. Het ISO pain.012 bericht can worden gearchiveerd nadat het is uitgepakt uit de XML envelop, met behulp van exclusive canonicalization. Alternatief is dat Creditors er voor kiezen om simpelweg het gehele StatusResponse bericht te archiveren.
  3. De eisen aan het formaat van eMandateID zijn verduidelijkt. Creditors worden er aan herinnerd dat de karakters van een eMandateID beperkt dienen te worden tot de SEPA Direct Debit karakter set, welke strikter is dan de MES-2 karakterset.
  4. Het gebruik van Creditor Adres is verduidelijkt. De Creditor dient zijn adres te registeren via twee adres regels, waarbij de eerste regel over het algemeen gebruikt wordt voor informatie over de straat, het huisnummer en toevoegingen, en de tweede regel voor postcode en stad.
  5. Toegelicht dat de dateTime in het ISO pain.012 bericht het moment van ondertekenen van de Incassomachtiging is. Het element eMandate.DateTimestamp is in de pain.012 tabel geplaatst om dit duidelijk te maken.

Wijzigingen die zijn doorgevoerd sinds versie 1.03

  1. Hoofdstuk 13 is toegevoegd, met informatie over de relatie tussen het product Incassomachtigen en het uitvoeren van de incasso, alsmede de relatie met de overstapservice.
  2. Toegelicht dat het opslaan van het bericht dat de machtiging bevat dient te gebeuren zonder enige wijzigingen aan dit bericht te doen, in verband met de controleerbaarheid van de elektronische handtekening.
  3. De eisen aan timestamps gezet door de Creditor zijn verduidelijkt. De Creditor mag in timestamps na de secondes nul tot drie decimalen meegeven en is dus niet verplicht om altijd drie decimalen te gebruiken.
  4. De XML-tags zijn toegevoegd in de tabellen met XML elementen in hoofdstuk 8 en 9.
  5. Indien het StatusResponse bericht de status “success” bevat is er een pain.012 bericht aanwezig met de elektronische handtekening over de machtiging. Deze handtekening dient gecontroleerd te worden door de Creditor bij ontvangst van de machtiging
  6. De eisen aan het veld maximum bedrag zijn verduidelijkt; het moet een bedrag tussen 0.01 en 999999999.99 zijn met nul of twee decimalen. Het decimale scheidingsteken is een punt.

...

  • Real-time online machtigen via een vertrouwd en bestaand internetbankier-product waar de Debtor al bekend mee is;
  • Real-time goedkeuren van de Incassomachtiging door de Debtor en real-time bevestiging van de Incassomachtiging aan de Creditor door de Creditor Bank. De Creditor ontvangt een Incassomachtiging dat getekend is door de Debtor Bank namens de Debtor;
  • Officieel erkend als geldige machtiging door de deelnemende Debtor banken. De termijn voor storneren en terugboeken van de SEPA Direct Debit incasso’s van de Creditor voor Core wordt hierdoor gereduceerd van 13 maanden tot 56 dagen;
  • De Debtor Bank verwerkt alleen zakelijke (Business to Business) SEPA Direct Debit incasso’s indien deze verwijzen naar een vooraf geregistreerde machtiging. Als onderdeel van het Incassomachtigen proces wordt de registratie van de Incassomachtigingen door de bank automatisch bijgewerkt op basis van de afgifte/wijziging/intrekking van een Incassomachtiging. Dit betekent dat de Creditor meteen kan overgaan tot incasseren. In vergelijking met het huidige mandaat-registratie proces zorgt deze methode voor een grote verlaging van de tijd tussen de afgifte van de machtiging en de incassering en het aantal mislukte incasso’s vanwege registratiefouten.
  • Incassomachtigen biedt de flexibiliteit om machtigingen te ontvangen voor verschillende doelen (bijvoorbeeld donaties, tijdschriftabonnementen, telefonische/e-mail bestellingen);
  • Ondersteunt meervoudig ondertekenen in de Debtor Bank omgeving in het geval dat dit nodig is voor specifieke Debtors.

...

  • De richtlijnen ter implementatie van Incassomachtigen zoals beschreven in dit document zijn bedoeld voor de Core/Zakelijke (Business to Business) SEPA Direct Debit.
  • De Incassomachtigen oplossing faciliteert het afgeven van nieuwe mandaten, het wijzigen van al bestaande mandaten en het intrekken van bestaande mandaten. De Creditor dient alle functionaliteiten aan te bieden.
    • De enige reden tot wijziging van het mandaat, is wanneer een Debtor van rekeningnummer wenst te wijzigen voor het innen van incasso’s, binnen dezelfde bank of naar een andere bank, of wanneer een Debtor het maximaal toegestane incassobedrag wil wijzigen. Na de redirect naar de internetbankieren omgeving van zijn bank kan de Debiteur zijn rekening kiezen en/of het maximum bedrag voor de incasso (opnieuw) instellen.  
    • Het intrekken van Incassomachtigingen wordt voor Core niet ondersteund door de Incassomachtigen oplossing zelf. De reden hiervoor is dat intrekkingen vaak betrekking hebben op het beëindigen van een abonnement of contract, in plaats van op het mandaat zelf. Het intrekken van Incassomachtigingen is om die reden een zaak die elektronisch gefaciliteerd moet worden door de Creditor, zonder dat de Debtor bank daar een rol in heeft.
  • De Incassomachtigen oplossing maakt gebruik van ISO XML 20022 Standaard eMandates berichten om Incassomachtigen-specifieke data over te dragen. De volgende berichten zijn in gebruik: pain.009.01.04 (nieuw, hier wordt ook naar gerefereerd als ‘Issuing’), pain.010.01.04 (wijziging), pain.011.01.04 (intrekking) en pain.012.01.04 (acceptance report). De informatie in het ISO XML 20022 acceptance report (pain.012) fungeert als de daadwerkelijke machtiging. De ISO berichten zijn in een container element geplaatst in de berichten. De XSD’s voor deze ISO berichten kunnen worden gevonden op http://www.iso20022.org/full_catalogue.page, zie ‘pain – Payments initiation’.
  • De Incassomachtigen oplossing is bedoeld voor zowel terugkerende als eenmalige mandaten.
  • In het Incassomachtigen proces wordt de Incassomachtiging-informatie aan de Debtor getoond in het Debtor bank domein.
  • Iedere Incassomachtiging heeft een eMandateID (kenmerk machtiging) dat uniek is binnen het CreditorID. Elke Creditor is verantwoordelijk voor het gebruiken van unieke eMandateID’s. Creditors dienen ervoor te zorgen dat het eMandateID voldoet aan de SEPA karakterset, zodat het gebruikt kan worden in het incassoproces.
  • De Creditor is verantwoordelijk voor het archiverenvan het originele mandaat en de elektronische handtekening (het ISO pain.012 bericht), samen met eventuele wijzigings- of intrekkingsinformatie die op een later moment kan zijn ontstaan. Het is te verwachten dat in de toekomst striktere eisen zullen worden gesteld aan elektronisch archiveren, met name met betrekking tot het waarborgen van de integriteit van documenten over een langere periode van tijd. Op de korte termijn zal binnen de regelgeving omtrent elektronisch identificeren het onderwerp eArchiving geadresseerd worden en zal een wettelijk raamwerk worden opgesteld met betrekking tot tijdstempels. Dit raamwerk zal worden geëvalueerd en worden toegepast in deze implementatie gids. Het ISO pain.012 bericht kan worden gearchiveerd nadat het is uitgepakt uit de XML envelop, met behulp van exclusive canonicalization. Alternatief is dat Creditors er voor kiezen om simpelweg het gehele StatusResponse bericht te archiveren. Het opslaan van het bericht dient te gebeuren zonder het bericht op enige wijze aan te passen, omdat de elektronische handtekening door aanpassingen ongeldig wordt. Een voorbeeld van een wijziging waardoor de elektronische handtekening direct ongeldig wordt is het aanpassen van de opmaak van het bericht.
  • De elementen eMandate.FrequencyCount en eMandate.FrequencyPeriod zijn opgenomen in de Incassomachtigen oplossing om de Consumentenbeschermingsinstellingen van de Debtor Bank voor Incasso te faciliteren. Deze elementen zijn echter opgenomen voor mogelijk toekomstig gebruik en zullen niet worden gebruikt in deze versie van Incassomachtigen. De Creditor mag deze velden NIET OPNEMEN in welk Incassomachtigen bericht dan ook.
  • Een goedgekeurde Incassomachtiging wordt voor Core door de Debtor bank gebruikt om de Debtor’s whitelistte updaten, maar dit gebeurt slechts indien de whitelist al geactiveerd was door de Debtor. Een inactieve whitelist zal niet worden geactiveerd door een Incassomachtiging. Een whitelist is de goedkeuringslijst van de Debtor voor incasso in zijn bankdomein. Indien de whitelist door de Debtor is geactiveerd mogen alleen incasso’s van machtigingen die op de whitelist staan door de bank worden uitgevoerd.
  • Indien de Creditor of het MandateID op de blacklist van de Debtor staat, zijn er binnen Core verscheidene opties:
  • Voor B2B worden Incassomachtigingen door de Debtor Bank gebruikt om de mandaatregistratie van de Debtor automatisch te updaten:

    • Een goedgekeurde nieuwe Incassomachtiging wordt toegevoegd aan de registratielijst
    • Wijzigingen van een Incassomachtiging (aanpassing van rekeningnummer of maximum incassobedrag) worden verwerkt in de registratielijst
    • Ingetrokken Incassomachtigingen worden verwijderd uit de registratielijst

...

De Creditor is vrij om intrekkingen van bestaande (papieren) mandaten te accepteren via de Incassomachtigen oplossing.

4.4 Consumentenbeschermingsinstellingen

eMandate.FrequencyCount en eMandate.FrequencyPeriod zijn opgenomen in dit document voor mogelijk toekomstig gebruik om de consumentenbeschermingsinstellingen van de Debtor banken te faciliteren. In de huidige implementatie van Incassomachtigen dienen deze elementen daarom niet te worden verwerkt door de Routing Service noch de Validation Service. Creditors mogen deze velden daarom niet opnemen in de huidige Incassomachtigen berichten, aangezien dit zal leiden tot een afwijzing van het gehele bericht.

4.5 Meervoudig ondertekenen

...

Dit hoofdstuk bevat een omschrijving van de algehele berichtstructuur voor het Directoryprotocol, het Transactieprotocol en het Statusprotocol. De volgende paragrafen beschrijven de specifieke velden in de XML berichten voor elk protocol in meer detail. 

Ieder bericht beschreven in deze paragrafen is een XML bericht dat conformeert aan het XML schema in APPENDIX D. 

5.1 General

HTTP

De volgende HTTP header wordt gebruikt voor alle berichten:

...

  • Alle berichten moeten voldoen aan de HTTP 1.1 standaard. Deze is gedefinieerd in RFC 2616 van W3C. Zie http://www.w3.org/Protocols/rfc2616/rfc2616.html voor meer informatie.
  • Een XML request bericht moet worden verstuurd via HTTP POST als body van het bericht.
  • Een XML response bericht moet worden verstuurd als body van een http 200 OK bericht.

XML Header

De volgende XML header wordt gebruikt voor alle berichten:

<?xml version="1.0" encoding="UTF-8"?>

Karakterset

  • In alle Incassomachtigen berichten moet de Unicode karakterset worden gebruikt. Alleen de MES-2 subset wordt ondersteund.
  • De codering moet worden gebruikt zoals aangegeven in de HTTP en XML headers: UTF-8 (Unicode Transformation Format).
  • Het gebruik van karakters die geen onderdeel zijn van de Unicode karakterset zal niet leiden tot een weigering van een verzoek, maar het karakter kan gewijzigd worden naar een spatie, vraagteken of asterisk.
  • Het Byte Order Mark (BOM) mag niet worden gebruikt. De UTF-8 representatie van de BOM is de byte sequentie 0xEF,0xBB,0xBF.

...

Het XML bericht dat wordt verzonden door de Creditor naar de Routing Service om de transactie te initiëren worden getoond in onderstaande tabellen: De Incassomachtiging informatie (ISO bericht) wordt in het container element geplaatst in het TransactionRequest. De definitie van het ISO bericht voor een nieuw Incassomachtigen-verzoek (ISO pain.009.001.004), een wijzigingsverzoek (ISO pain.010.001.004) en intrekkingsverzoek (ISO pain.011.001.004) worden getoond in onderstaande tabellen. 


Section


Column
width675px

Velden van het TransactionRequest

Naam

Omschrijving

Formaat

createDateTimestamp

Datum en tijdstip waarop het TransactionRequest bericht is gecreëerd.

DT

issuerID

Het ID (BIC) van de Debtor bank geselecteerd door de Debtor, zoals getoond in de Debtor bank lijst in de DirectoryResponse (Debtor.DebtorBankID).

ANS..max 11

merchantID

eMandate.ContractID zoals dit van de Creditor Bank ontvangen is. Indien het eMandate.ContractID uit minder dan 10 cijfers bestaat, worden voorloopnullen gebruikt.

PN..10

subID

eMandate.ContractSubID, door de Creditor Bank verstrekt aan Creditor, als Creditor aangeeft hier gebruik van te willen maken.

Een Creditor kan bij zijn Creditor Bank verzoeken om meerdere subID’s te mogen gebruiken. Hierdoor wordt op de Incassomachtiging niet alleen de  Creditor.Name (de incassant), maar ook de Creditor.TradeName en het relevante Creditor.Address  behorende bij het SubID weergegeven (Creditor.Name inzake Creditor.Tradename). 

Tenzij anders afgesproken met de Creditor Bank dient de Creditor hier 0 (nul) in te vullen als standaard subID (indien geen subIDs worden gebruikt).

N..max 6

merchantReturnURL

URL van de Creditor waarheen de Debtor na autoriseren van de transactie geredirect moet worden door de Debtor bank en die terug leidt naar de website van de Creditor. (Hoeft niet noodzakelijkerwijs te beginnen met http:// of https://). 

Bijvoorbeeld: https://www.webwinkel.nl/betaalafhandeling

AN..max 512

expirationPeriod

Optioneel: De geldigheidsduur van het transactieverzoek gemeten vanaf ontvangst door de Debtor bank. De Debtor dient de Incassomachtiging te accorderen binnen deze tijd. Als dit niet gebeurt dan wordt de status van de transactie door de Debtor bank op “Expired” gezet.

Waarde volgens ISO 8601: PnYnMnDTnHnMnS. Minimum waarde: PT1M or PT60S (1 minuut); maximum waarde: P7D, PT168H, PT10.080M (7 dagen). De Creditor wordt aangeraden dit veld leeg te laten. 

RDT

language

Door middel van dit veld kan de Debtor bediend worden op de site van de Debtor bank in de taal naar keuze (of zoals deze geselecteerd is op de site van de webwinkel), indien de site van de Debtor bank dit ondersteunt.

Codelijst conform ISO 639-1. (Engels = ‘en’, Nederlands = ‘nl’)

Indien een niet bestaande of niet ondersteunde taal wordt opgegeven wordt de standaardtaal van de Debtor bank gebruikt.

Geadviseerd wordt om alleen “nl” te gebruiken omdat andere talen niet door alle Debtor banken worden ondersteund.

CL AN..2

entranceCode

De Transaction.entranceCode is een ‘authenticatie sleutel’ ten behoeve van continuering van de sessie tussen Creditor en Debtor, zelfs als de bestaande sessie is beëindigd. De Creditor kan hiermee de Debtor herkennen die hoort bij een (inmiddels afgeronde) transactie. De entranceCode moet voor iedere transactie een unieke waarde hebben.

De Transaction.entranceCode wordt hiertoe meegestuurd in de HTTP(S) GET naar de Creditor als parameter achter de merchantReturnURL.  De Transaction.entranceCode dient een minimale variatie van 1 miljoen te hebben. Deze code moet bestaan uit letters en/of cijfers (maximaal 40 posities).

De Transaction.entranceCode wordt aangemaakt door de Creditor. 

ANS..max 40

Container

Deze container bevat de ISO pain berichten. Dit kan een 009 (nieuwe Incassomachtiging), 010 (wijziging) of 011 (intrekking) bericht zijn. Zie tabellen hieronder voor meer informatie.


SignedInfo


*

SignatureValue


*

KeyInfo


*

*SignedInfo, SignatureValue en KeyInfo zijn XML Signature data elementen die gedefinieerd zijn in de XML-Signature Syntax and Processing (Second Edition) W3C Aanbeveling 10 juni 2008. De digitale handtekening wordt in meer detail beschreven in Hoofdstuk 11. Het XML Digital Signature Schema is beschikbaar bij de W3C op het adres: http://www.w3.org/TR/2002/RECxmldsig-core-20020212/xmldsig-core-schema.xsd# 


Div
stylepadding-left: 1cm
classno-print


Column
width100%

Insert excerpt
iDx AcquirerTrxReq (B)
iDx AcquirerTrxReq (B)
nopaneltrue




...

errorCode

errorMessage 

errorDetail

IX1100

Received XML not valid

Field generating error: location-reference in XML message

IX1200

Encoding type not UTF-8

IX1300

XML version number invalid

IX1600

Mandatory value missing

SO1000

Failure in system

System generating error: Issuer/Acquirer

SO1100

Issuer unavailable

SO1200

System busy. Try again later

SO1400

Unavailable due to maintenance

SE2000

Authentication error

Field generating error: location-reference in XML message

SE2100

Authentication method not supported

BR1200Version number invalid
BR1205ProductID invalid
BR1210Value contains non-permitted character
BR1220Value too long
BR1230Value too short
BR1270Invalid date/time
BR1280Invalid URL
AP1100MerchantID unknown
AP1200IssuerID unknown
AP1300SubID unknown
AP1500MerchantID not active
AP2600Transaction does not exist
AP2920Expiration period is not valid
AP3000

eMandates specific error
Details van de fout kunnen worden gevonden in het ISO pain.012 error acceptance bericht.

...