KB Article #180223
How to implement order types CCX / CCS, CCC (pain.001.002.0{2,3}) handler
Problem
How to implement order types CCX / CCS, CCC (pain.001.002.0{2,3}) handler
Resolution
(Full document available in attachment - PDF Format )
This handler processes container files with SEPA transfers in the following formats:
SEPA-3.1 — pain.001.001.03 in container.nnn.001.02 (GBIC2)
SEPA-3.0 — pain.001.001.03 in container.nnn.001.02
SEPA-2.7 — pain.001.003.03 in container.nnn.003.02
SEPA-2.5 — pain.001.002.03 in container.nnn.002.02
SEPA-2.4 — pain.001.002.02 in container.nnn.002
It enables the control of format and the setting of limit. When it is selected for a SEND transaction, the following form is proposed to the administrator with a set of check-boxes and fields enabling to define the handler processing - see attachment.
Allow only one PmtInf / Hashvalue mandatory
These checkboxes must be set for order types for service data centers.
(see description at the end of this document).
SRZ-Id / SRZ-Name
Enter
values here if the ID or name of the service data center (SRZ) shall be
checked(see description at the end of this document). You can also use
variables to provide customer-specific values here, e.g. $(_SRZID)
or $(_SRZName)
. This is configured at the customer under Parameters.
Salary payments
Here, you can set that the details for the electronic signature are suppressed for files containing the purpose codes BONU, PENS or SALA, that is, when additional signatures are added, the user cannot see the transaction details.
SEPA versions
Here you can specify which SEPA versions* should be supported.
*) Schemas
SEPA-3.1 — urn:conxml:xsd:container.nnn.001.02 (GBIC2)
SEPA-3.0 — urn:conxml:xsd:container.nnn.001.02
SEPA-2.7 — urn:conxml:xsd:container.nnn.003.02
SEPA-2.5 — urn:conxml:xsd:container.nnn.002.02
SEPA-2.4 — urn:conxml:xsd:container.nnn.002
SRZ (Service Rechenzentrum, service data center)
The handler CCC (pain.001.00x.0{2,3}) is able to make a validation as specified by the Deutsche Bundesbank (Specificaton in German there –English translation not available).
The hashvalue is the "hash" of a single file in the container. If a SRZ (Service Rechenzentrum, service data center) uploads files, the hash is mandatory for them:
<MsgPain001>
<HashValue>D7A8FBB307D7809469CA9ABCB0082E4F8D5651E46D3CDB762D02D0BF37C9E592
</HashValue>
<HashAlgorithm>SHA256</HashAlgorithm>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03">
<CstmrCdtTrfInitn>
<!-- content of the pain.001.001.03 file -->
</CstmrCdtTrfInitn>
</Document>
</MsgPain001>
The ID and Name are mandatory for a SRZ and the handler has to check them - these parameters are found inside of each file of the container, as a part of the pain.001.001.03 file).:
<InitgPty>
<Nm>Name des SRZ</Nm>
<Id>
<OrgId>
<Othr>
<Id>DRTHG23425</Id>
<!-- 10-stellige Kennung des SRZ -->
<SchmeNm><Prtry>SRZ</Prtry></SchmeNm>
<Issr>DK</Issr>
</Othr>
</OrgId>
</Id>
</InitgPty>