First intermediate_opening_balance line missing

[phamthangpri]

Hi,

How can I get the first line on intermediate_opening_balance and account_identification ?
Here is the parsing result with this info missing :

Here is my file :

Thanks,

[wolph]

The file doesn't appear to have an intermediate_opening_balance, only an opening_balance (the :60F:: https://mt940.readthedocs.io/en/latest/mt940.tags.html#module-mt940.tags

The account identification data is across the entire file so that's in the transactions (plural) object, not in a singular transaction.

[phamthangpri]

but sometimes, it can not retrieve the account_identification in the entire file, all account_identification values in transactions are null.

[wolph]

That is very odd, that should only happen if it either doesn't detect the field at all or if something is overwriting it. Do you have any (anonymised) files you can send to test?

[phamthangpri]

Hi,
Yes,
Here is an example but didn't check if all account identifications are detected. I'm on holiday now. If this file works, I send you another one after my holiday.
https://docs.google.com/document/d/1K73rB2Yu2JRWTuy1k0oEtqS-em98px0O9NgEW5AcaXs/edit?usp=drivesdk

But yesterday, I read 7000 files and it didn't work very well. Just 30% of account identifications were detected. Finally, I needed to dev by myself to read the account identification.

Thanks

[wolph]

I've done a bit of research and as far as I can see it's properly parsing the account identifications without issues. But... the account identification is in the transactions object and not the transaction itself.

To illustrate:

transactions = mt940.parse('test.mt940')

for transaction in transactions:
    print(transactions.data['account_identification'], transaction)

With the loglevel set to debug you can see what it is and is not parsing but that gets very verbose. But it does show the account_identification for me in these cases. Perhaps you can share some other testdata where it fails?

[wolph]

Reopening — still relevant. We could not reproduce the ~30% account_identification miss without sample data. If you can share a (redacted) statement that fails, we'll fix it; leaving open to track.

[wolph]

Took a fresh look at this as part of a full audit (#127). It splits into two distinct file shapes:

Shape 1 — multiple :20: blocks, one account/page each. This already works today via parse_statements():

statements = mt940.parse_statements(your_file)
statements[0].data['intermediate_opening_balance']  # first block's own balance, not overwritten

Each :20: block gets its own Transactions, so its first :60M:/:25: is preserved independently.

Shape 2 — one :20: block with multiple :28C: pages sharing it. This is reproduced and still broken: parse_statements() splits only on ^:20:, so the whole paged file becomes a single block, and the second page's :60M:/:25: overwrites the first page's data. Added a strict-xfail regression test (test_paged_single_block_first_intermediate_balance_accessible) pinning this. Fixing it requires a design decision (detailed in #127, "Needs decision") — not resolved by this PR.

If your original file matches shape 1, parse_statements() should already resolve it. If it's shape 2, it's the same open question as #127.