Parse 86 tag (information_to_account_owner) as a struct

[erictapen]

Thanks for this great library.

I'm struggling to understand the meaning of these character encodings for the information_to_account_owner field, like they can be seen here: https://github.com/svenstaro/mt940-rs/blob/master/tests/data/mt940/full/betterplace/with_binary_character.json#L26

They don't seem to be modified by the parsing code and I wonder, where the decoding logic for that should be located. Is that some part of the MT940 standard that's not implemented yet? Or is the user expected to decode this? And if yes, does any resource come to your mind explaining the encoding?

Because I suppose the two digit codes ?20 represent ASCII characters, but I can't make any sense of strings like the 051?00 in the beginning.

Edit: I now got some idea of the ? encoding. It doesn't encode special characters but separates fields identified by the two digits after the ?. What I don't get yet is what the three digits at the beginning and end mean.

[erictapen]

I looked at the Python project referenced in the Readme and it looks like they are decoding the information.

Their parsing logic seems to be in this _parse_mt940_details function: https://github.com/WoLpH/mt940/blob/develop/mt940/processors.py#L129

I might find some time to implement this and make a PR. But I'm wondering what would be the best place to add it. Should I add it to the pest grammar file? This would probably necessitate to add some extra fields to the parsing results, as the information_to_account_owner encodes up to 10 fields:

transaction_code  
posting_text  
prima_nota  
purpose  
applicant_bin  
applicant_iban  
applicant_name  
return_debit_notes  
recipient_name  
additional_purpose

[svenstaro]

Thanks for you interest to work on this! I think it should probably be added to the pest file as you suggested. From the Python code, it appears like it should be somewhat easy to parse. Would this live entirely in fn parse_86_tag()?

[erictapen]

Alright! I'll try to look into this in the following days. The project I need this for is a low effort high priority one for me, so it might take me some time to get back to it.

Without having given your code a second look I assume it could be kept inside fn parse_86_tag(). I'd probably change the return type from string to a struct, that consists of the fields mentioned above.

[svenstaro]

Sounds good. I think you'll find the code is fairly easy to get into as it's kept simple and compartmentalized.

[svenstaro]

@erictapen you still on the case?

[erictapen]

I still want to implement it, but other stuff has more priority in the next ~2 months I'm afraid.

[svenstaro]

Alright sure, the issue is going nowhere. :)

[svenstaro]

Would you like to try to pick this up?

[erictapen]

Sorry, other things in my head currently.
I actually tried to pick this up as part of a project for my studies (which would process mt940 data via WASM), but my Prof said no to my project proposal :/
So it might take a long time until I revisit this.

[svenstaro]

Ah, well then. I'll just leave this open for later then.