Parsing invalid statements returns 1 excess transaction about mt940 HOT 6 CLOSED

@wolph These are the tests reproducing this error: sq9mev@0209467

I'm not sure, but seems like empty transaction is unconditionally appended in https://github.com/WoLpH/mt940/blob/develop/mt940/models.py#L338

Removing that line causes many tests fails.

Seems like the same error is present v 4.3.

from mt940.

@wolph, here's proposed solution: sq9mev@f1896f6#diff-505920b44ddd6be1f840afac6c9c5f8a

It requires some tests to be changed (excess transaction is absent now, so must be removed in expected), but i have a problem with one of them:

sq9mev@f1896f6#diff-e1163247336b0e8a403f42a707358166

Single 86 line will not be parsed, because of https://github.com/sq9mev/mt940/blob/f1896f6001c8451c40f7edddb658dd7246d8cf1b/mt940/models.py#L372. Test data could be extended with some 61 line, but this raises further questions: how much loose should the parsing be? It probably depends on usecase…

What do you think?

from mt940.

They state 61 is optional, but 86 requires 61 (rule C1):

C1
If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. In addition, if field 86 is present, it must be present on the same page (message) of the statement as the related field 61 (Error code(s): C24)

https://www2.swift.com/uhbonline/books/public/en_uk/us9m_20160722/htframe.htm → 
MT 940 Customer Statement Message → MT 940 Network Validated Rules

From this perspective, my solutions seems to be correct (at least for mt940), but I'm not sure whether it is consistent with the assumptions of the library.

Meaning of 86 in mt942 is conditional:

C3
If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61 except if that field 86 is the last field in the message, then field 61 is optional. In addition, if field 86 is present, it must be on the same page (message) of the statement as the related field 61 (Error code(s): C24).

If the field 86 is the last field in the message and it is immediately preceded by field 61, then that field 86 is considered to provide information about the preceding field 61; otherwise the field 86 is considered to provide information about the message as a whole.

https://www2.swift.com/uhbonline/books/public/en_uk/us9m_20160722/htframe.htm → 
MT 942 Interim Transaction Report → MT 942 Network Validated Rules

I feel like I've opened Pandora's box.

from mt940.

The proposed solution looks like a good solution but I'm not really sure if there is a good solution for this problem. Since I initially created this library I have noticed that few banks actually adhere to the standard and most simply approximate it.

The currently defined scopes (Transaction and Transactions) are too limited for full mt942 support and we'd need at least a 3rd level (page) in between. I'm just not sure if it's worth the effort :P

from mt940.

I think it's not worth effort ;), however if you think its goot solution for excess transaction problem i'll make PR - one may depend on len transactions.transactions when processin parsed transactions, this was my case.

from mt940.

It's really a matter of opinion with this issue, some will like the new solution and others won't. I personally think the new version is better :)

Thanks for the fix!

from mt940.