Statements

Table of Contents

1 Introduction

The "Statements" application is a hosted web application (built with playframework 2 and mongodb), which helps a company of brokers to send a set of statements to their clients, via data received by external services.

4 / 4
splash.png

1.1 Terms

The following are some terms used in the rest of the document.

User

A person using the "Statements" application.

Client

A person receiving an emailed statement.

Platform

These represent an integration with Interactive Brokers, Betterment, ADP, or whatever the source of the data is. They are separately configured, with their own settings, template, and data files. All users see and edit the same list of platforms.

Statements

This is the list of statements that are eventually emailed. This is a collection of tabular data (from a uploaded file), and a template. There is only one active set of statements per platform. The user creates and reviews the statements, and then sends them. The statements are sent to the clients, as well as the archive address. After the statements are sent they are removed from the platform page.

Template

A text file that's used to produce an email. It can have parts of it substituted for variables within the tabular data. The substitutions also support filters (for manipulating the data inline,if needed)

For example, lets say we have a table that looks like:

name accountNum fee quarterlyFee email
John Doe 111223334 200.00 50.00 johndoe@mailer.com
Jane Doe 999933449 100.00 25.00 janedoe@mailer.com

And a template that looks like:

Hi <%= name %>,

Your Account <%= showLast(4)(accountNum) %>, is currently being billed and annual fee of <%= fee %>, billed daily over 252 business days. Your quarterly fee is <%= quarterlyfee %>,
please compare this with the statements you receive directly from the custodian, Interactive Brokers.

This would result in emails written like:

Hi John Doe,

Your Account xxxxx3334, is currently being billed and annual fee of 200.00, billed daily over 252 business days. Your quarterly fee is 50.00,
please compare this with the statements you receive directly from the custodian, Interactive Brokers.

This showed an example of

  • Variable substitution:
    <%= name %>
    
  • Variable substitution with filter:
    <%= showLast(4)(accountNum) %>
    

    "showLast" being a custom filter that will be added to the application.

More information on available syntax for the templates can be found here

2 Scenarios

2.1 Setting up a platform

Joe doesn't have the data for statements, but he wants to be prepared when it's time to send them out. He Logs into the app using his works google account. He starts by creating a new platform, naming it 'Interactive Brokers'. Joe then edits the template file to create the copy for the emails. He doesn't have the tabular data now, but he knows what form it will take, so he fills in some examples (with his own email). Joe takes a look at the imported data in the statement view and everything looks OK. Joe then chooses one of the rows to preview what the email will look like. Noticing problems he goes back and edits the template file, correcting a typo in one of the substitution variables. Now the email preview looks correct to Joe. Joe then sends the statements, and they arrive in his email box.

2.2 Preparing/sending a statement

It's time to send statements out, So Bob logs into the app using his work's Google account. Bob has a CSV file he exported from Interactive Brokers. From the list of platforms, he chooses 'Interactive Brokers', then 'upload file'. After the CSV uploads, Bob skims looks over the data in the table preview to confirm the import. Bob then quickly previews an email that would be sent for one row, and confirms everything looks ok. Bob then chooses to send the statements. The statements are emailed to all clients listed, and to the archive address.

3 UI

Here's a breakdown of how the UI, and what the different sections are for.

ui.png

3.1 Splash

splash.png

  • Simple splash screen with a login button. Authenticate through Google via OAuth2.
  • Login can be restricted to a configured domain (i.e. only Google accounts with the email user@dutchasset.com).

3.2 Home

home.png

  • Create, edit, or delete a platform.
  • Access a platform.

3.3 Platform

platform.png

  • Upload tabular data with CSV file.
  • View the current tabular data.
  • Make changes to tabular data inline.
  • Clear the tabular data.
  • Preview email for a given row in the tabular data.
  • Send statements via email.

3.4 Edit/New Platform

edit-platform.png

  • Edit the name of the platform.
  • Select the name of the field for retrieving email addresses (from the tabular data).
  • Edit the email body and subject templates.

3.5 Settings

settings.png

  • Configure smtp settings.
  • Configure archive email address.

3.6 Records

  • View list of all attempted batch emails.

4 Assumptions

4.1 No handling of overlap with users between platforms

If a user exists in two separate platforms (and therefore two sets of statements) it's expected that they'll receive an email for each statement their in.

4.2 No storage of data files

After the emails are sent for a set of statements, the data that produced the emails is cleared. Data entered into the system is completely local, when one user uploads the csv data, it isn't available for other users.

4.3 No automatic triggers for sending mail

Nothing fires these emails off automatically. A user must login, enter data, and press send on a given platform in order for the statements to be sent.

4.4 Modern browser support only

Author: Mike McFarland

Created: 2015-08-14 Fri 16:17

Emacs 24.5.1 (Org mode 8.2.10)

Validate