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.
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 | |
---|---|---|---|---|
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.
3.1 Splash
3.3 Platform
3.4 Edit/New Platform
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.