Account holder field. about jejik-mt940 HOT 7 CLOSED

Interesting issue. I'll have to think about that a bit.

It looks like he Rabobank also provides the contra account holder's name so on the face I have no problem of adding it to the Transaction class and provide stubs for it in AbstractParser that are used in the transaction method. Perhaps the contraAccount field should even be made into an Account class of it's own (potentially also usable on the statement itself for the owner account information).

I did some digging in your fork but I don't think it's fool proof. It mis-parses the account holder on an MT940 export from my own bank account. Here's the transaction (redacted):

:61:1201010101D50,0N477NONREF
:86:59.81.43.912 WEHKAMP FINANCE BV IDEAL BETALING: 1234567890123456
7890123456789012 01-01-12 12:01  DESCRIPTION

Some more digging in the ABN-AMRO MT940 specs, it says in the appendix that transaction description lines are 32 characters long, but that they collapse every two lines into a single :86: line. So, charactes 0-31 after the :86: is line 1 and characters 32-63 are line 2.

Looking through my own MT940 export it looks like that, when ABN-AMRO knows the contra account holder name, it puts it on line 1, right after the contra account number (i.e. on characters 0-31). That would also explain the large number of spaces I see between the account number and the rest of the description in some transactions. In that case ABN-AMRO doesn't know the contra account holder name so it pads line 1 with spaces. Then line 2 comes which appears to be the description as ABN-AMRO recieved from the other bank (which usually has the contra account holder as the first description line).

A better algorithm may be to look at the first line (chars 0-31) and see if there's a name after the account number. If not, fall back to the contents of line 2 (chars 32-63 in the first :86: line).

If that something you can confirm with your own exports as well?

from jejik-mt940.

I am looking for the space-padding to identify the accountholder. Could it be that we have an 'edge case' here, because the padding is only one space and therefore fails to register?

If the first line always has the accountholder (if it's there), we could look at it like that. I'm assuming the format is like this:
:86:[line1][padding][rest] where [line1] + [padding] is always 31 (or maybe less if there is no line 2?) characers long. Seems like a possibility.

Anyway, a quick test on my import files with the current code seems to have the following fails.
(Importfiles are quite big, but contain more incomming then outgoing transaction. Currently testing about 55K transactions, and finding below fails)

• Internal bookings to ABN (costs etc) go wrong for both accountnumber and accounholder.
• Creditcard-company payments (incoming) go wrong for both accountnumber and accounholder
• Negative amounts seem to work rather bad for both account and accountholder, especially (or so it seems) payments to GIRO accounts. I'll look into that.
• Some positive amounts from GIRO also fail on both accounts. (conclusion: look more intro GIRO)
• international (SEPA) bookings.

If I filter these (I'll look in to them later, I can probably fix those) I get stuk with a handfull of lines that seem to have the same issue you mentioned:
redacted: ('X' is accountholder, 'Y' is description)

    12.34.56.789 XXXXXXXXX XXX XXXX YYYYY YYYYY
    12.34.56.789 XXXXXX XXXXXX XXXX YYYY YYYYYYYYYY
    12.34.56.789 XXXXXX XXXXXX XXXX YYYY YYYYYYYYYY
    12.34.56.789 XXXXXX XXXXXX XXXX YYYYYYYYYYYY

This will work with the "31 characters"

Finally, some strange ones I really don't know what to do with ('Z' is some extra description. '?' I really don't know)

    ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.: 01.02.34.567 YYYYYYYYY YYYYY
    12.34.56.789 ???????? ?????

This last one is (I think) someone with a strange name, and no description given. so it could be just

    12.34.56.789 XXXXXXXX XXXXX

First conclusion would be that your suggestion for the first 31 characters seems doable. I'll write a test, but it might take a while because of other parts need finishing first :)

from jejik-mt940.

Could you have a looksee here?

https://github.com/NanneHuiges/jejik-mt940/commits/accountHolder

I've added some extra code for recognizing "SEPA" (Single Euro Payments Area) lines, so you can actually get the account (BIC/IBAN) from those. This code still can't parse internal ABN transaction (interest, bankingcosts etc) as they don't provide any contraAccount info, but it fails only for a handful of obscure imports in my testfile.

Ignoring the SEPA, i've separated two cases: sometimes the bankaccount is the only thing on line 1, and the name is on line two. THe other case is that they are both on line one. Well, see for yourself, I'll wait for feedback before I go and pull request (not really sure on proper github etiquette :) )

from jejik-mt940.

I'm a bit swamped right now because of Easter but I'll have a look early next week. I have also sent an e-mail to ABN-AMRO asking for more recent specs that include how the description field is built up. The spec I have only mentions the contra account number but nothing else.

from jejik-mt940.

I finally manager to get through to someone at the ABN-AMRO bank. They've escalated the issue to their tech people so hopefully they can provide me with more up-to-date specifications of the MT940 files that they export from their internet banking site.

Sorry that this has taken a bit of time. I've also been struggling with some health issues lately so writing source code hasn't been my top priority.

from jejik-mt940.

No worries, things are going slow here also. If I have time, I'll upload my new code when it is ready for publication: I found out that "access online" exports in a different format if you use "reports", but I'm not really sure if this is different enough for a separate parser or not. Currently I have a second parser extending the default abn-amro parser, but that seems to be too much. I'll keep you posted

from jejik-mt940.

I have implemented this. Currently it sits in the class-injection branch (which features new Account objects) but it should be in master pretty soon. I have gone by my original assumption that the account holder is either in the first line directly after the account number (pos 0-31) or, if there is only space padding after the account, that the second portion (pos 32-65) contains the account holder name.

It's not 100% fool proof, but I think that the reason is that ABN-AMRO simply copies the description they get from other banks into their own description. So, maybe the account holder could be on the other description lines, but the format of those lines really depend on the originating bank. Trying to parse that reliably is going to be very complex.

from jejik-mt940.