Add support for swiss payment standards - Githubissues

salesking / sepa_king

Ruby gem for creating SEPA XML files

MIT License

149 stars 118 forks source link

Add support for swiss payment standards #82

Closed tobischo closed 5 years ago

tobischo commented 5 years ago

This change adds support for swiss payment standards as specified by the SIX Group (https://www.six-group.com/interbank-clearing/de/home/standardization/iso-payments/customer-bank/implementation-guidelines.html).

More specifically it adds support for

pain.008.001.02.ch.03 (Implementation Guidline (pdf), Schema and examples (zip))
pain.001.001.03.ch.02 (Implementation Guidline (pdf), Schema and examples (zip))

Please note that there are a couple of differences between swiss direct debits and sepa direct debits:

Only allows IBANs from Switzerland or Liechtenstein
Does not use BIC but instead the Clearing System Member Identifier, which is the local bank code (3-5 digits) and can be automatically determined from an IBAN from switzerland or liechtenstein (5th to 9th digit)
If ISR Debits are used, you need to provide the ISR Participant Number
It uses structured remittance information to pass along ISR or IPI reference numbers
It does NOT use mandate_id and mandate_date_of_signature
service_level is either CHDD or CHTA
local_instrument depends on service level and is DDCOR1, DDB2B, LSV+ and BDD
sequence_type is not used
batch_booking is not used

As stated in #81 I am not entirely sure if this is the best approach, especially in regard to long term maintainability or whether SPS would even belong into this gem. It would be great having it all in one place in my opinion, however it puts more responsibility on the user to correct utilize sepa_king.

Please have a look at the changes and let me know about your preferred way of having it integrated

coveralls commented 5 years ago

Coverage remained the same at 100.0% when pulling 0e1345af9a518a80a44919d320489f41dcb6008d on tobischo:feature/support_swiss_payment_standards into 6bc9bf2080adca308ddba4da6154d4fc0b07df0d on salesking:master.

coveralls commented 5 years ago

Coverage remained the same at 100.0% when pulling 0e1345af9a518a80a44919d320489f41dcb6008d on tobischo:feature/support_swiss_payment_standards into 6bc9bf2080adca308ddba4da6154d4fc0b07df0d on salesking:master.

coveralls commented 5 years ago

Coverage remained the same at 100.0% when pulling 0e1345af9a518a80a44919d320489f41dcb6008d on tobischo:feature/support_swiss_payment_standards into 6bc9bf2080adca308ddba4da6154d4fc0b07df0d on salesking:master.

coveralls commented 5 years ago

Coverage remained the same at 100.0% when pulling 0e1345af9a518a80a44919d320489f41dcb6008d on tobischo:feature/support_swiss_payment_standards into 6bc9bf2080adca308ddba4da6154d4fc0b07df0d on salesking:master.

coveralls commented 5 years ago

Coverage remained the same at 100.0% when pulling ebfed21c058019e968192cafd31647f3c86b1793 on tobischo:feature/support_swiss_payment_standards into 6bc9bf2080adca308ddba4da6154d4fc0b07df0d on salesking:master.

tobischo commented 5 years ago

It is possible to validate swiss pain files here: https://validation.iso-payments.ch/validation/(S(twsybqsebpeubej2ldeghay2))/KUNDEBANK/analyze.aspx?Proj=1&Lang=EN (requires registration)

ledermann commented 5 years ago

Wow, this is a big one. Looks great!

After some consideration, I tend not to merge this changes because:

SPS is not SEPA and there are more differences than I was aware of (thanks for the list above!)
Maintaining SPS in the long term requires someone with uses cases in this area (means: not me)

I see this options:

Building a second gem "sps_king" by copying the code and use your work. This should be easy because you have already done the main work.
Crazy idea: Splitting the code into three gems: Core gem with basic classes and utils, sepa_king, sps_king. Lots of work to be done, but no code duplication.

Currently, I'm very busy with other projects, so I can't work on this gem right now.

tobischo commented 5 years ago

Yup, after I read the SPS documentation and especially after implementing it, I can certainly understand that. Since you do not have the use case for it, it does not make sense for you to support it. Furthermore a separate gem maintained by Barzahlen would make potential changes that come up while actually using it much easier (e.g. in case my interpretation of the SPS documentation does not match the authors intentions and the banks usage).

I am not sure the name will end up being sps_king, but that's the first thing that came to mind 😄

I like the idea of having a shared basis, although I don't think I'll have the time right now to come up with a concept for that either. I guess having the sps library in a working and released state could reveal similarities that could be extracted. Then again, it could also impede changes to either of the gems if we first have to go to the dependency and fix something there. On the other hand it could save us from having to implement features twice. I suppose we'll cross that bridge when we come to it.

tobischo commented 5 years ago

We ended up calling it sps_king after all 😄 https://github.com/Barzahlen/sps_king