adds msg id accessor to batch detail

[gadimbaylisahil]

It would be great to add MsgId accessor for batch detail as some back office and ERP systems can also make use of it to bulk update transaction statuses.

https://github.com/Barzahlen/camt_parser/issues/35

[tobischo]

Thank you for the contribution.

Would you mind adding a reference to documentation for this field? That really helped with the previous PR. If we have to look that up as well, the review is bound to take longer.

[gadimbaylisahil]

Hi @tobischo, first thanks for amazing work for the CAMT parser.

Regarding this PR:

I am not sure what are your use cases of the parser but I have worked with applications where we were submitting transactions to financial institutions(batch_booking=true) and then would pull bank statements(C53) which would then be parsed and analyzed to find the given transaction, in order to update its corresponding internal status.

Doing so, for ( batch_booking=false ) is easy, as you can individually see the transactions and update them accordingly in your system, erp etc...

Use case for MsgId would come into play here. When submitting a payment request to banks such as:

                  xml.Document xmlns: 'urn:iso:std:iso:20022:tech:xsd:pain.008.003.02' do
                    xml.CstmrDrctDbtInitn do
                      xml.GrpHdr do
                        xml.MsgId options[:msg_id]
                        xml.CreDtTm Time.zone.now
                        xml.NbOfTxs transactions.size
                        xml.InitgPty do
                          xml.Nm options[:partner_name]
....

You would pass a Unique Random Identifier for MsgId field, while saving it in transactions that were submitted in this batch internally.

You would then read the CAMT report, find the MsgId, query within the system and update the transactions.

Also, to note:

If a direct debit/credit is failed, they will be individually listed in the bank statement and won't be hidden.

Please, correct me if there is any clear misunderstanding by my part.

Thinking this is common use case is an assumption by my side.

I have monkey patched for personal use, but if you think all these make sense, would be great to have it.

[tobischo]

Thank you, I understand how the field is supposed to work, however I had hoped to receive some official documentation you could point me to which explains whether the field is always required or not and what the specific constraints are.

From the documentation I read, it somewhat depends on the bank (it was not in each of them)

Closest I could find was https://www.dzbank.de/content/dam/dzbank_de/de/home/produkte_services/Firmenkunden/PDF-Dokumente/transaction%20banking/elektronicBanking/Anlage3_Datenformate_V3.0.pdf PDF page 391, Numbering page 384

Your example is not correct in the tests, because only up to 35 characters are allowed though. I will correct that.

[gadimbaylisahil]

Thank you, I understand how the field is supposed to work, however I had hoped to receive some official documentation you could point me to which explains whether the field is always required or not and what the specific constraints are.

From the documentation I read, it somewhat depends on the bank (it was not in each of them)

Closest I could find was https://www.dzbank.de/content/dam/dzbank_de/de/home/produkte_services/Firmenkunden/PDF-Dokumente/transaction%20banking/elektronicBanking/Anlage3_Datenformate_V3.0.pdf PDF page 391, Numbering page 384

Your example is not correct in the tests, because only up to 35 characters are allowed though. I will correct that.

Oops, sorry for misunderstanding, I thought you were asking about the use case. Thanks!