Untitled Document

How could TariffEye be used in accounting?


V1 Pierre-Mikael Legris 8/03/2006

I’m sorry after re-reading this document, I notice that it it’s more a personal note, than something readable by someone else.

I wish it will be useful for you even if not all the context is explained.


We are talking about using TariffEye data-engine with an accounting system, in order to calculate fees.


Needs

Calculate the different types of fees

Periodic fees

Those are fixed fees that are issued periodically.

Reaction fees

Those fees are issued when normalized events occur; for example a transaction, a new position.

Contextual fees

The value of the fee depends on the state of the portfolio at a certain time.

Handle different tariffs

In space

Tariffs depend on a global politic for each institution, but for some group of customers some other tariffs may applies, this occur also on a per portfolio basis.

In time

Tariffs change within time.

Issue a human readable explanation of the calculation

For each fee, an explanation will be issued to the customer.

Design of TariffEye datamodel and calculation engine

Datamodel

All the data concerning a Tariff is relative to an abstraction called

Tarification which contains a collection of Tarifs. Tarifs are small fee calculation elements, their context of application is defined by bidimensional Trees.


Example:

Tarification: UBS

Tarif: Actions UBS

Context: <Base-Equities> + <Localisation-Switzerland> + <USER-UBS>


List of known Trees:


Used Trees and context:

Result:


The Tarif “Action UBS” now defines a service that can be subscribed. Each type of subscription has its own Tarif type: assets, transactions …


This architecture defines also the containers for Options (conditional states of the portfolio) and calculus structures.

Data Manipulation

Data manipulation is made by manipulating Java objects. A Tarification is serializable using the former Java Serializer and JavaBeans XML serialization.


Calculation Engine

The calculation engine was designed to keep track of every calculation with their comment, this is done by a “Visitor”.

Worksheets

Tarif objects are not participating in the fee calculation; they are the containers for Worksheets that take this in charge.


A worksheet, accept the “visit” of the calculation engine; it may request pre-calculation of other worksheets by the calculation engine.

Discounts

Discounts are attached to Worksheets, they participate to the calculus AFTER other elements calculation.

Limitation of actual design and solutions

Data

Portfolio data should be accessed from an external database. Accessing Portfolio data (options, assets, and transactions) should be easy. The main difficulty will come in representing the tariffs data and version in a hierarchical way.

It should be easy to request from the central database the tariff for portfolio ABCD and handle specific discounts, but also to modify the tariff for all the customers for one specified product.


Another solution would be to keep one Tariff database per portfolio (as it is today). And to achieve the “modify this product tariff for all customers” request will enumerate and modify, one by one user Tariffs; this no a “so-stupid” solution as having a too complicated relational database to handle versioning may be more difficult to manage than redundant information.

Time

TariffEye is not “time aware” and is designed to calculate all the fees in a row, so the calculation engine cannot be reused for a real accounting system. The request calculation system should be simpler than the actual one.


Including time in the calculation and data retrieval will not modify TariffEye architecture and should imply a small amount of coding.

Human readable calculation

TariffEye is designed to be able to describe fully the calculus made, but it has only been used for debugging so far…

Strength of actual design

TariffEye model, perfectly describe any bank Tariff encountered, and the level of abstraction makes easy the integration of new Tariff concepts.


What is for sure reusable in TariffEye is the way Tariffs are conceptualized.


The UI, permit all the manipulation and visualization a user would need. Using TariffEye as the end-user discount and special tariffs attribution by hooking TariffEye to another fee-calculation system may be quite easy to do.

Final Note

TariffEye is a standalone real-time calculation tool, all the code was turned on performance optimisation, hard testing and code reviewing is needed to use it in an accounting system.

Coypright (c) 2006-2016 SimpleData Sarl