pain.001;SPS;2022 standard validation fails

[sdespont]

SIX validation : https://validation.iso-payments.ch for the last standard "pain.001;SPS;2022" returns an error

Someone know if the XSD path must be updated?

(Line number) - Errors
******************************************************
(0002) - Error: no declaration found for element 'Document'


(0001) <?xml version="1.0" encoding="UTF-8"?>
(0002) <Document xmlns="http://www.six-interbank-clearing.com/de/pain.001.001.03.ch.02.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.six-interbank-clearing.com/de/pain.001.001.03.ch.02.xsd pain.001.001.03.ch.02.xsd">

[eric-reichenbach]

There's a lot of modifications in the new standard https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/implementation-guidelines-ct-developer_support-2022.pdf

As this new modifications are due on the 18th of november, I'll look into it. We might need to be able to support both versions at the same time to ease the transition. I'm not sure which pattern would be the most efficient however.

• We'll need new CreditTransfer classes for the renamed payment types.
• Some nodes have new names
• Some validation rules have been altered

I wonder if we should do a new fork for the new Specs? It would allow to generate both versions in parallel to transition smoothly.

@toooni , @sprain , @a-schild

[sdespont]

Yes, this library must support both versions. In my point of view, CustomerCreditTransfer constructor must contains a new optional parameter permitting the switch with the new specs version 2022. That way, there is no BC and no need to create a new fork.

After reading the spec 2022, I think that the main changes are :

• New <Document> header with new XSD <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09 pain.001.001.09.ch.03.xsd">
• <CtctDtls> drops Nm and add company and software details in <Othr>
• New way to format dates permitting to specify a "date" or "datetime" (only need to surround date with <Dt>)

[sdespont]

Also, the new version "could" (you know how banking institutions are up to date...) be accepted since end of November 2022, but the current one has a grace period of two years before being refused. Therefore, both versions must be supported until end of 2024.

https://www.six-group.com/en/products-services/banking-services/standardization/iso-payments.html

[sprain]

I wonder if we should do a new fork for the new Specs? It would allow to generate both versions in parallel to transition smoothly.

I'd suggest to handle it by releasing a new v3.0 major version.
Thus makes upgrading to the new specs a deliberate move and at the same time leaves room for fixes in v2.0.x.

[will2877]

Are there any other changes that would need to be addressed in a v3.0

[sdespont]

Even if SPS 2021 is still valid until november 2025, it would be a good thing to address all needed changes before.