“Action UBS” now defines a service that can be subscribed. Each
type of subscription has its own Tarif
type: assets, transactions …
architecture defines also the containers for Options
(conditional states of the portfolio) and calculus structures.
manipulation is made by manipulating Java objects. A Tarification
is serializable using the former Java Serializer and JavaBeans XML
calculation engine was designed to keep track of every calculation
with their comment, this is done by a “Visitor”.
objects are not participating in the fee calculation; they are the
containers for Worksheets
that take this in charge.
worksheet, accept the “visit” of the calculation engine; it may
request pre-calculation of other worksheets by the calculation
are attached to Worksheets,
they participate to the calculus AFTER other elements calculation.
of actual design and solutions
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.
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.
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.
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.
time in the calculation and data retrieval will not modify TariffEye
architecture and should imply a small amount of coding.
Human readable calculation
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
model, perfectly describe any bank Tariff encountered, and the level
of abstraction makes easy the integration of new Tariff concepts.
for sure reusable in TariffEye is the way Tariffs are conceptualized.
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.
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.