Week 80 - September Sales Review

By Angus Cheng

September Sales

Another month has gone by, let’s take a look at the monthly revenue graph.

Oh no, revenue went down! In August we brought in $62,596 HKD and in September we brought in $46,736 HKD. Not great news, but it’s actually okay. This is because 60% of August’s revenue came from one off work for a single customer.

The Monthly Recurring Revenue graph is looking excellent. It increased from $21,701 HKD in August to $37,481 HKD in September.

We also set new records for new subscribers and sign ups.

Last Week’s Goals

Plumpbird: How did you get on with the goals you set last week?

❌ 1. Finish the front end translation for one language

Still going with this, it took longer than I expected to pull out all the strings from the front end. We also need to pull out strings from serverside error messages.

✅ 2. Translate the blog into Japanese

This is done, and can be enjoyed here.

✅ 3. Talk to twenty users

I figured it would be most useful to email the heaviest users. So I queried the old database for that list of users. I also figured I didn’t want to contact users I’ve already contacted. It’s annoying getting unsolicited emails, so before writing the email I’d search my inbox for their email address. If I had emailed them before I skipped them. I went down the list and hand typed each email, I did this so that I wouldn’t trigger a spam algorithm. It took me a few hours, and I got two replies.

Customer #1

Nothing to do. We are very happy with the software thank you.

Good to see this customer is happy.

Customer #2

Yes the year is important. Without the year the file will not import.

After a few emails I learned that he would like year to be included in the transaction date. Okay, I have some experience with that.

Enriching Dates for First National Bank

In a previous blog post I talked about how I figured out the correct year for transaction date values without a year. Since I’ve done multiple times for other banks, it should be easy right?

Plumpbird: I’m not sure about that Angus.

It wasn’t so straight forward, because all my date enrichment code assumed the dates would be in English. First National Bank documents can be in English or Afrikaans. Java’s date libraries support parsing dates in multiple languages. So I started restructuring my classes to supporting passing in a Locale.

After that, parsing a long date like 17 Maart 2021 worked, but parsing a short date like 05 Mrt or 05 Maa did not work. Annoyingly, “Maa” and “Mrt” are both short forms of “March”, perhaps First National Bank are making up their own abbreviations.

DateTimeFormatterBuilder() allows you to specify your own “ChronoField” patterns. This worked well I was able to enrich the years. I let the customer know and he was happy.

It’s perfect now.

Documents Fixed

  1. USA - Community Bank North America
  2. USA - Northfield Savings Bank
  3. USA - Toronto Dominion Bank
  4. South Africa - Standard Bank
  5. UK - Monese
  6. USA - Peoples United Bank
  7. South Africa - First National Bank

One Line, Multiple Header Matches

For some reason, American banks like to group transactions into multiple tables. Very often you’ll see a special table for outgoing checks. Typically these check tables will have a Date, Check Number and Amount header. Like this:

To save space they might duplicate the headers

Some banks repeat the headers two times. Alright, so what? We can configure our parsers to look out for one, two or three sets of headers. That should deal with these repeated headers right?

Wrong. There are banks out there, that will send out one set of headers if only one check was paid for that period. Two sets of headers if only two checks were paid and three sets of headers if three or more checks were paid.

For those banks, you would need to configure the parsers like this:

  • Look for [X, Y, Z] headers
  • Look for [X, Y, Z, X, Y, Z] headers
  • Look for [X, Y, Z, X, Y, Z, Y, Z] headers

That’s very annoying. I did it for a little, but then realised it would be better to continue searching for a match after finding a match.

This Week’s Goals

1. Finish the front end translation for one language

There’s a bit more preparation needed, but once that done I can hire a translator. There aren’t that many strings, so the translation part should be pretty quick.

2. Contact 40 users

Similar to last week, this time I’ll message users that showed a ‘buy intent’, but did not buy.

3. Allow excluding certain descriptions

Often we pick up “Beginning balance” and “End balance” records as transactions. They aren’t transactions, so we should be able to set rules to exclude them.

4. Document Conversion Feedback

I want to include a message box that allows the user to tell us when a conversion hasn’t worked. This should increase feedback from users, which should improve the product.

UNTIL NEXT TIME