Help?! Parsing a bank account number

Talk, speculate, discuss, pontificate. As long as it pertains to Hazel.

Moderators: Mr_Noodle, Moderators

Help?! Parsing a bank account number Fri Dec 05, 2014 2:23 am • by ejgallaher
Macbook Pro, mid-2010, SSD, 2-GB RAM, Yosemite.

I have learned a lot from the Noodle forums and Buzz (Brooks Duncan, Sparky, and http://technosavvy.org/2012/09/07/automated-bank-statement-filing-with-hazel/).

However, I can't do the following: My account number appears as follows; (numbers have been changed, but they appear in the order as shown.)

Account Number: 000007063008029

I'd like to extract the last four digits and include them in the filename, thusly: 2014-11-05 ejg-Chase-8029.pdf.

Thanks to Sparky I have the date piece working. I could hard-code the 8029, but we have multiple accounts with the same format, so I'd like to match the account number, then parse it to capture the last four digits.

I've tried a variety of strategies, but none seem to be working yet.

  • I can do a match for number using the [123] token, followed by '8029', but since there is no separator within the account number this does not seem right.
  • I tried restricting the action to include 'at least 4 digits', but this doesn't allow me to include only 4 digits.
  • Would it make any sense to enter the single digit token 11 times as a prefix to the final four? -- I can't quite wrap my head around this one.
  • Or, do I need to resort to some external code to parse this out? And if so, where would be a good place to start?

TIA. I hope this request makes some sense, and the results are useful to other newbies as well.
ejgallaher
 
Posts: 6
Joined: Thu Dec 04, 2014 8:52 pm

Re: Help?! Parsing a bank account number Fri Dec 05, 2014 1:08 pm • by Mr_Noodle
No need to hardcode anything. Why not do:

(123)(•account digits)

where •account digits is a custom attribute which itself consists of 4 digits. That will match the account number while putting the last 4 digits into the custom attribute which you can then use in any patterns after that.
Mr_Noodle
Site Admin
 
Posts: 11195
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Fantastic! Thanks for the quick reply!

This worked, although it needed a few modifications.

I hope it isn't too long-winded. :? I describe the logic behind the matching process for the benefit of others with similar questions. Pattern matching is extremely powerful, but it requires a certain mind-set and seems to baffle many newbies (myself included). Also, I updated the Subject to include the term pattern matching for easier access to others.

First, an aside -- pattern matching the date token -- I had been searching for the 2nd occurrence, since the format was January 05, 2011 through February 04, 2011, the latter date being the statement date itself. This worked great, until it didn't.

When I opened the pdf I found an additional paragraph describing a 'policy change as of June 01, 2011'. Although it appeared to be lower down on the page, it apparently was interpreted as the 2nd occurrence; perhaps they had the original document formatted in columns? Anyway, I changed the token to 'through mmmmm dd, yyyy', and reverted back to the 1st occurrence -- worked fine(!) -- a more precise definition of the match token.

Now, pattern matching the account number -- I used the token as you suggested. Rather then the account number, Hazel inserted some strange (?) number into the filename -- the last 4 digits of the PO Box! So I changed it to the 2nd occurrence. This time it inserted the last 4 digits of the ZIP code! Similar to the date problem, it is important to develop a precise description of the pattern itself, rather than relying on the occurrence number. (I can see where occurrence number might be useful, but it is obviously less precise and open to error.)

In this case, the account number always begins with 00000. Taking advantage of this structure, I therefore changed the token to [00000(123)(•account digits)]. Voila! Perfection!

Caveat... I learned many years ago that the computer is [virtually] infallible in doing what you tell it to do. The challenge is to convert [what you want it to do] into [what you actually tell it to do].

Statements prior to June 2009 were still not interpreted correctly. Lo and behold, they had changed the format of the account number, along with the layout of the statement itself. I am OK with this -- I can adapt the rules if I want to go back this far. It just illustrates that despite Hazel's magical tricks, we still have to be vigilant.

Thanks again. Hazel is fantastic! Support is fantastic!

Ed
ejgallaher
 
Posts: 6
Joined: Thu Dec 04, 2014 8:52 pm


Return to Open Discussion