Product Settlement Phase 3 – High Level Business Requirements
Req. Id / Description / Phase[1] /Functional - Settlement
Req.PS3.001 / The phase 3 solution extends the phase 2 solution. I.e. the functionality implemented in phase 2 remains in place or is enhanced by phase 3 functionality.
(For efficiency reasons only the most significant phase 2 requirements are listed in this table.) / 3
Req.PS3.002 / The system shall be able to settle the product sales amount of specific products between a Product Retailer and one or more Service Providers / 2
Req.PS3.003 / The system shall be able to settle the product sales amount of specific products based on actual usage at the various Service Providers. Usage is recorded on the product instance level and based on the (shadow) e-purse value of a travel. / 2
Req.PS3.004 / The system shall support two settlement methods for settling the product sales amount of a product instance:
a) Predefined: a predefined (absolute or relative) part[2] of the full product sales amount is settled to one or more Service Providers immediately (the split between the Service Providers can be absolute or relative)
b) Based on usage: a part2 of the full product sales amount is settled based on actual usage at the various Service Providers
(Both methods are mutually exclusive, i.e. settlement to a specific Service Provider is based on one and only one of these methods)
A product can have any combination of the above two methods, for example:
· A product is settled fully to Service Provider A
· A product is settled fully based on actual usage to various Service Providers
· A percentage of a product is settled based on actual usage to Service Provider A, B and C; the remainder is settled based on actual usage various Service Providers (excluding Service Provider A, B and C)
· A percentage of a product is settled to Service Provider A; the remainder is settled based on actual usage to various Service Providers (excluding Service Provider A)
· € 25 of a product is settled to Service Provider A; 10 % to Service Provider B; the remainder is settled based on actual usage to various Service Providers (excluding Service Provider A and B)
· Etc. / 3
Req.PS3.005 / The system shall allow to configure for each product whether or not the sales amount should be settled and, if so, how settlement should take place (any combination of predefined and based on actual usage settlement). / 3
Req.PS3.006 / The system shall settle the sales amount of a product instance after (part of) the validity of the product instance has ended. For monthly products settlement takes place when its validity expires; for yearly products settlement takes place after each passing of a quarter of its validity.
Note: durations (month, quarter year or year) are not defined as calendar durations (e.g. a quarter starts on the first day of a month and ends on the last day of the third month), but are equal to actual duration as linked to a specific product instance. / 2
Req.PS3.007 / Settlement data will be gathered per product, per card and per concession.
Note: the concession id used is the id from the check-out transaction. Cross-border transactions are ignored. / 2
Req.PS3.008 / Settlement will be done per Service Provider, reporting will be done per concession.
Note: the concession id used is the id from the check-out transaction. Cross-border transactions are ignored. / 2
Req.PS3.009 / TLS creates a dedicated bank account for the product sales revenues of product settlement.
Note: the value of all to be apportioned product sales is to be transferred from the retailers to this bank account. / 2
Req.PS3.010 / Unused monthly products (i.e. products for which no usage transactions have been received by the system) will be apportioned based on the default key for the corresponding product. / 2
Req.PS3.011 / Unused yearly products (i.e. products for which no usage transactions have been received by the system during a period (quarter year)) will be apportioned for that period based on the default key for the corresponding product. / 2
Req.PS3.012 / The settlement process and associated reporting will be done on a daily basis. Bank instructions will be generated to perform settlement on a daily basis. At a minimum the daily report will contain the applied aggregated apportionment key per product per concession. / 2
Req.PS3.013 / Settlement for a specific product instance is done a configurable number of days after expiration (or quarter year passing for yearly products) to allow for late transactions. / 2
Req.PS3.014 / Product refunds will be settled as negative sales; the refund value is deducted from the sales value. / 2
Req.PS3.015 / During the settlement of yearly products, only those products instances are settled for which a quarter year has fully expired, measured from the validity date of the product. The amount to be settled for a quarter equals a quarter of the sale amount. / 2
Req.PS3.016 / As long as a products instance’s sales amount is not available at the moment of settlement (no product sales transaction has been received), the product instance is excluded from the settle-ment process. Once the sales amount becomes available it is included (product sales transaction has been received). / 2
Req.PS3.017 / Only ‘good for settlement’ transactions are included in the product settlement process. / 2
Req.PS3.018 / Product settlement for first level refunds for monthly products is only done as long as the validity of the product instance has not yet started. In this case the refund amount is fully settled to the Retailer that refunded the product. The refund amount is deducted from the dedicated product sales revenues account. / 2
Req.PS3.019 / Product settlement for first level refunded yearly products takes place according to the following rule:
settlement amount = product sales amount minus already settled amount minus refund amount.
This settlement amount is then settled according to the apportionment key of the applicable quarter. If this rule results in a negative settlement amount, the product sales amount minus the already settled amount is settled to the Retailer that refunded the product and an exception is reported. / 2
Req.PS3.020 / First level refunds for product instances for which no sales transaction has been received will not be settled. An exception is reported instead. / 2
Req.PS3.021 / When a product is replaced or renewed onto a new card and is refunded (2nd level) on the old card, settlement of the product should continue as if it were not refunded on the old card. / 2
Req.PS3.022 / When a card is ended (i.e. second level refunded without replacement) that still has one or more valid (i.e. non expired) products loaded on it and one or more of these products is configured for settlement, the remaining unsettled amount is transferred to the LPR, along with a report detailing the case. / 2
Req.PS3.023 / At the end of the product settlement of a product, the remaining product amount should always be ‘0’. There should never be a value remaining which will stay in the product sales revenues account. / 2
Req.PS3.024 / Product instances that are blocked will be settled as if they are still usable. Either the default key for the product is used (when no more usage occurs) or (perhaps after unblocking the product instance) the key is calculated based on actual usage. / 2
Req.PS3.025 / The system shall be able to store all data to audit the settlement for as long as it is possible to dispute it. This may involve anonimizing transactions. / 3
Req.PS3.026 / The system shall enable resettling previously settled product sale amounts. This may be required when incorrect (static) apportionment keys were used during initial settlement. / 3
Req.PS3.027 / The system should allow ad hoc reporting to enable auditing the settlement results. / 2
Req.PS3.028 / The system shall be able to deal with a single transaction that may be split into multiple (virtual) transactions by the ‘Fare Calculation Engine’. Transactions may be split based on products used or concessions travelled. / 3
Functional - Exceptions
Req.PS3.029 / The system shall provide a means to deal with product instances for which settlement of the product sales amount should take place, but for which no product sales transaction has been received. The same applies to product refunds.
(A solution could be to report after 62 days all product instances which cannot be settled and to subsequently allow an operator to manually enter the product sales amount after which settlement takes place. Manually entering the sales amount could also be replaced by using a lookup table.) / 3
Non Functional - Interfacing
Req.PS3.030 / The system shall be able to interface with a ‘Fare Calculation Engine’ that will calculate the fare for transactions related to pre-specified products. The most likely process flow is the following:
1. Transactions are received and validated by the system
2. The system forwards transactions to the Fare Calculation Engine for fare calculation (if required)
3. The Fare Calculation engine returns the transactions to the system for settlement
Note: since transactions that are sent to the Fare Calculation Engine may return split into multiple transactions, an option could be to treat returned transaction entirely separate from transactions as originally generated. / 3
1 / 3
[1] “Phase” refers to when a requirement was first implemented. The assumption is that, unless explicitly stated otherwise, requirements for phase 2 are also applicable in phase 3.
[2] “Part” can be 100%.