TRANPT

From Wiki
Jump to: navigation, search
Tranpt.PNG
Name Transaction Processing
Shortcut TRANPT
Area

See the NOVUS Walkthrough Guide for further information.


There are various programs for posting transactions into the IBA ledger. Transactions can only be made against a specified policy and the year for which a market has been created. A transaction may be either templated or non-templated.

In a templated transaction, the amounts for each party involved in the market are computed automatically by the system from the signed lines.

For Helix installations where IFRS17 has been applied transactions will not be possible unless the profit field in RISKNEW has been completed.

In NOVUS `gross amounts` are always entered into transaction processing screens and the order per cent is applied.

In non-templated transactions in the TRANPTN program, amounts for each party can be specified individually. Note that a non-templated transaction still requires a market – amounts can only be specified for those parties which exist in the market. The TRANPT program can be accessed directly from the menu or via the risk query screen thereby allowing the required policy and year to be identified. It supports a wide range of features such as instalments, section splits and fixed fees.

For a detailed explanation, with examples of how NOVUS handles cash flow through the system, please see the NOVUS cash flow page.

Transaction processing against proportional treaties must take place through the proportional treaty module(TTY).

If risk details are being used, the TRANPT program will automatically get the premium from there.

When risk details are used the automatic premium calculation can not be changed. The only way to get an AP (additional premium) or RP (return premium) is to go into the risk via the RISKEND program and modify the sums insured, or cover period: NOVUS automatically calculates the premium. The TRANPT program finds the latest endorsement number and gets the premium due. The original premium (PM) is always endorsement zero. Not all risk details carry premium (i.e.group G does not)

If the claims module is installed, claim and refund of claim technical entries must be made through the claims system.

Cash is entered via the CASHENTRY program.

If the system is configured to use the broker portal, the transaction numbers generated may contain a mix of alphanumeric characters.

Proceeding through from the RISKNEW program into the TRANPT program from a risk record that does not have a figure in the "est GWP" field will not permit the transaction to be committed. This is most commonly the case for master binders or lineslips. Please ensure that the TRANPT program is accessed directly from the shortcut menu or the ribbon.

Basic Concepts

Instalments.

All Morning Data products maintain four dates for each record in the IBA.

1. Instalment Date

Up to 99 yearly, half-yearly, quarterly or monthly instalments can be specified. The program divides the gross amount and the period into equal pieces putting any roundings on the first instalment. Each instalment will always balance to zero. The only technical entry program designed to handle instalments is the main TRANPT program.

In this program the instalment date is driven by default from the inception date of the policy although the instalments can be based on a different date is required. If the inception date has lapsed then the instalment dates can also fall prior to the current system date. Hence instalment dates can be lapsed dates.


2. Payable By Date

This may be used by the user to control terms of credit on either debit or credit items and should use this date accordingly to meet the requirement. For instance payable by dates would be used to drive aged debtors reports. The TRANPT program generates payable by dates from the base date (inception date of the policy).

Payable by dates can be lapsed dates. The TRANPT program allows the first payable by date, and subsequent instalments to be generated automatically by allowing a ‘delay’ to be specified for the first and subsequent instalments. The payable by dates are populated by adding the appropriate delay to the base date based instalments.


3. Accounting Date

This is the date for which the transaction instalment will be accounted in the nominal ledger (NL). For soft currency transactions, the accounting date, therefore, defines the period into which the soft currency transaction will go in the nominal ledger. On conversion, the accounting date is changed to the conversion date which defines the period into which the contra NL soft currency entry will be made, and the period into which it will be aggregated (in destination currency) in the period summary totals in the EPERIOD program. Unlike the other two dates, the accounting date will change on conversion.

The nominal ledger can be configured either to accrue brokerage or to account for instalments in the NL on an instalment basis. If the database is configured not to accrue brokerage, the accounting date will initially be the same as the instalment date. If the Accrue_NL field is set to Y then the accounting date for all instalments will initially be set to the date of the first instalments.

However, for instalments that extend to more than one year, the accounting date for the second and subsequent year instalments is set to the respective anniversary date of the base date. Accounting dates will follow the instalment dates if they fall in the future.

If the instalment dates have lapsed the ‘earliest account date’ on the screen should be adjusted if posting to earlier months is required. Posting to closed/blocked months is not permitted. For example, unless the earliest accounting date is set back, monthly instalments on a policy incepting on 1st January but not entered into the system until 23rd March will have three entries for 23rd March and then other instalments falling 1st April, 1st May etc. Instalment dates and amounts can be adjusted if required.

The earliest accounting date defaults to the current system date unless NOVUS has been configured to run in FRS5G mode. This is a UK accounting requirement to force IBA entries into the IBA ledger as close as possible to the inception date. If the system is configured in FRSG5 mode:

  • The earliest accounting date will default to the first date of the earliest open period after the policy inception date, or the system date, whichever is earlier.
  • All accounting instalment dates will be the same – the date the system is able to determine given the setting of the ‘earliest account date’, and the base date.

If premiums are processed late, it can often happen that the first few instalments are blocked to the same accounting date but each still needs to preserve its respective identity. The entry details field is an identifier for the transaction 03Q21 which equates to third quarter 2021. This is a mandatory field and is used in the processing of E2I reports. It is also the most useful way for the business to identify transactions.

The earliest accounting date: defaults to the incept date of the policy or the first day of the current period for a PM, MD (minimum deposit premium) etc. if the incept date falls in a blocked period.

For an AP, RP, etc. the system defaults to today's date.


The earliest accounting date: can be changed to any date in an open period.

The base date defaults to the incept date of the policy for all transaction types. The instalment dates, and payable by dates are calculated from this. The account date will be either the same as the base date or the first day of the current period if the base date falls in the blocked period.

The account date will be the base date: or earliest A/C date, whichever is later. The account date can never be earlier than the earliest A/C date:.

The date entry in the TRANPT program is designed to be as flexible as possible for date entry to allow for any reasonable pattern of dates that are required for the transaction. The only rules are that the account date must be in an open period and the account date is the same for all instalments on a transaction.

The net brokerage % replaces any brokerage in the market set up with a fixed value.


Prem W.ToC: is the premium warranty terms of credit number of days. Terms/trade is the number of days added to the payable by date for PANs


4. Original Accounting Date

This is set to the accounting date when the entry is made. In the case of soft currency transactions, the accounting date will be changed to the date the transaction is converted whilst the original accounting date remains unchanged. It, therefore, provides a pointer to the period into which the soft currency records were entered in the NL.


Section Split

This feature enables a transaction to be split across sections, provided the policy has been created with multiple sections. To use this feature, enter all in the section field.

Taxes and Fees.

This feature enables a wide range of different taxes and fees to be applied to the transaction at the time of making the technical entry. A pre-configured set of taxes and fees is supplied as standard, but other types can be configured as the need arises.

N.B. The alpha identifiers are case-specific giving a total of 52 possible options of upper and lower case letters. It is possible to change the description of the tax or fee to highlight more specifically what it is for. This remains a unique code.

NOVUS differentiates a ‘tax’ from a ‘fee’ in two regards:

  • A fee applies to the first instalment and a single section each only and must be expressed in monetary terms.
  • A tax will apply (equally) to all instalments and is expressed as a percentage of the line gross order per cent amount or, brokerage. A facility for accruing taxes into the first instalment is also provided.

In both cases, the structure of the tax or fees can be configured to include revenue accounts or the tax/fee can be entirely non-revenue based. For example, an admin fee of, GBP 50 would be a revenue-based fee; IPT (client tax) at 5% would not involve revenue accounts.

Those fees or taxes that involve revenue nominal ledger accounts require pseudo IBA accounts to be set up before they can be used in the fees structure. All such pseudo IBA accounts must begin with ‘X’ and comprise three characters only such as XBK, the brokerage account. For example, an account XBP could be set up and specified as the IBA pseudo (‘pot’) account for policy fees.

To better understand how taxes and fees work, the debit and credit ‘account’ must be specified. The fee configuration table can regulate whether the debit and credit accounts can be changed in the TRANPT program. If the ‘account’ is an actual IBA account (revenue such as XBP, or non-revenue such as LIRMA (London International Insurance and Reinsurance Market Association)) then this side of the debit/credit movement can be described as ‘ONE’ i.e. this half of the movement will go to ONE account.

If change is permitted, this ‘account’ could be changed to a recognised suffix such as ‘*’ for all clients or ‘.’ for all insurers. Similarly, in conjunction with the not applicable tax field in IBA account maintenance, an IBA account code can be configured not to apply to a set of specified taxes. If this account were to be found amongst the all clients or all insurers, the model would reduce to ALL-SOME or SOME-ALL. The specific tax feature applies to taxes only – not fees.

The set of possible combinations are:

  • ALL-ALL, ONE–ONE, ONE-ALL, ALL-ONE, SOME-ONE, ONE-SOME, SOME-ALL and ALL-SOME. Note the SOME-SOME combination is not permitted.

In most cases, the tax percentage would apply to the order per cent of the line(s) concerned. Taking IPT as an example, each client would be debited the IPT rate of 6% on the amount of premium each pays. Each insurer will be credited 6% of the signed share.

In rare but important cases, taxes are charged on brokerage. An example of this is Nigerian VAT which is charged to the client at 5% of the broker’s brokerage. Moreover, in Nigeria, VAT only applies to brokerage on business placed with insurers within Nigeria. A simple example will show the required result. In the example below, SWIS is not applicable to Nigerian VAT.

Gross premium GBP 1000, signed to 100% or order.


Signed Share Brok % Brok VAT @ 10%
AFIN * 100
SWIS .. 40 2.5% 10 Nil
MROA . 40 2.5% 10 1.00
NIRE . 10 2.5% 2.5 0.25
ARCI . 10 5% 5 0.50
.75%


The debit note to the client will be for GBP1,000 plus 1.75 VAT which will be credited to the VAT pseudo pot account. Note that calculating VAT in this way differs from the UK inputs and outputs approach. This calculation represents a VAT difference ready to be passed to the revenue. In the UK the corresponding tax takes the form of IPT which is net collected on behalf of the revenue by the insurer. IPT is much easier for insurance brokers to calculate than Nigerian VAT.

If the nominal ledger module is installed, IBA entries against pseudo revenue IBA accounts are posted to the nominal fees account specified in the system parameters table. There are separate fee accounts for banking and non-banking currencies.

In those cases where the default debit/credit structure can be changed, the system resolves any conflict intuitively. Such a situation may arise with taxes and the apparent percentage on the debit side does not equal the apparent percentage on the credit side. In such cases, the system gives priority to the credit side as the following example will make clear. It may be considered that taxes are ‘pulled’ not ‘pushed’

For example, consider a market as shown below having two clients on a 70/30 split of the business and two insurers on a 60/40 split of the risk and a 1% tax (similar to FET) to be paid by the insurers to the clients.


Signed Share
AFIN * 70%
ABLE * 30%
AIGL . 60%
BDRM . 40%


If the structure of the FET tax has been made to allow the default debit (all insurers) and the default credit (all clients) to be changed within the TRANPT program, the user is able to specify either third-party accounts for each side or accounts which already form part of the market. In the first case, there is no conflict - all the tax (1%) will go to/from that specified third party account.

If internal accounts are specified such as BDRM (.) or AFIN (*) or external accounts such as CAIN and BEST then the assumption is made that the requirement is to move 1% of the gross amount between these parties. This is a ONE-ONE movement. Hence given a 1,000 GBP premium, FET at 1% (GBP 10) will be debited from BDRM and credited to AFIN.

If only one of the default is changed (i.e. if the credit ALL clients is changed to a specified client) then the calculation follows an ALL-ONE pattern, starting with the ALL side to accommodate the situation that the ‘ALL’ may reduce to ‘SOME’ if selective taxes apply.

If AFIN is subject to FET but ABLE is not, and all insurers should pay their proportion of the FET, either specify AFIN as the credit client (leaving ‘ALL’ for the debit insurers) or configure the ABLE account not to apply to the FET tax code. However, these two approaches will give different results because NOVUS must look for selective taxes before all other considerations.

The first example deals with an ALL-ONE situation, whilst in the second case, it is an ALL-ALL situation (with the potential of reducing to ALL-SOME). If AFIN is specified as the specific credit account (ALL-ONE), AIGL and BDRM will respectively pay GBP 6 and GBP 4, and AFIN will be credited GBP 10.

Alternatively, if ABLE is set up with FET being not applicable (ALL-SOME), the selective taxes rule applies with the result that the selective tax amount is found to be GBP 7 credited to AFIN whilst debits of GBP 4.20 and GBP 2.80 are made against AIGL and BDRM respectively.


Market Versions

Market versions may be used to accommodate mid-term market changes. Each section on a technical entry is tagged to a particular market version. If the market should change mid-term it is useful to be able to preserve the current configuration of the market and use a new market version for the new configuration. This enables historical analysis to be carried out correctly and facilitates posting contra entries should the need arise.

If a single section has been specified, enter the market version number. The system checks that this market version exists for the above mix. [KEY-HELP] displays details of the market.


Templated Transaction Entry

In a templated transaction, the amounts to allocate to the various securities including brokerage and silent agents fees, are computed automatically by the system from the market configuration and the type of transaction (premium, claim etc).

There are four templated transaction entry programs:

General:

This program includes instalments, section splits, and ‘fixed’ fees. It is the most comprehensive of the templated transaction entry programs.

Consolidated:

This program allows a number of amounts to be grossed together which may be relevant in a small claims situation. For example amounts (which need not be small in size) such as 23.00-, 20.00- 2.34-, entered in the same transaction, will create three separate client lines grossing to 45.34- apportioned against the insurers (and brokerage if applicable) using the market structure.

Client Profile:

This type of entry is likely to apply to a direct insurance application. Templated transactions may be entered against the selected client profile to which a ‘cover’ or master policy has been assigned. The transaction is processed against the ‘cover’ market details tagged to the client profile record.

The client profile route enables a set of master policies such as might occur under a binding authority to be prepared and applied to the relevant client. It avoids having to set up a separate market for each client. Accounting to insurers is often accomplished in these circumstances on a bordereau.

The market model automatically generates a set of items in the IBA ledger, which net to zero. A typical premium would include one or more client lines, one or more insurer lines and most likely a brokerage line. This pattern is repeated for each instalment.

The market should be configured to include elements such as brokerage and silent agents. The system uses the transaction type to determine whether brokerage and commissions apply. Brokerage and commission (client discount) apply on premiums, additional premiums, and return premiums, but not on claims, a refund of claims, return premium no commission, and additional premium no commission.

If there are extra elements, which only apply to the specific transaction the ‘fixed fee’ module, may be used within the general transaction poster for this purpose. This module handles a wide variety of fees and taxes as you enter the transaction. Fixed fees are discussed under the general transaction entry program.


Transaction Types

Code Description
MD minimum deposit premium
PM original premium
RP return premium
RPN return premium no commission
AP additional premium
ADJ adjustment premium
APN additional premium no commission
ARN additional reinsurance premium no commission
CLM Claim
CBX Claims bordereau
DC initial declaration
PBX premium bordereau
PMR reinstatement premium
PRN reinstatement premium no commission
REF refund of claim
RPR return reinstatement premium
RRN return reinstatement premium no commission

Proportional Treaty

This is a complex transaction entry screen, which is templated with regard to commissions but not with regard to brokerage. In the case of proportional treaties, the brokerage element has already been calculated. The program looks for the gross premium amount from which it calculates the treaty commission, treaty overriding commission and any commission set up a ‘facultative’ commission but ignores brokerage computations as this has already been identified as a separate entry in the proportional treaty entry. This is the only transaction entry program, which can be used for proportional treaties.

NOVUS will check that where the Policy Type (GID 1) maps to a Processing Group (GID 14) that has the Transaction route set as 'T' for treaty, then transaction processing via TRANPT will be prevented with error "711E: Treaty - Process through the Prop. Treaty system"

For further details of this program please see the Proportional Treaty Section of this Wiki


Non-templated transaction

There is one non-templated transaction entry program, which allows the actual amounts for each line on the market to be specified. This program, therefore, disregards the market structure – the only constraint is that amounts can only be entered against the clients and insurers specified in the market i.e. third party entries are not permitted. Any difference between debit and credit entries is written to brokerage.

Transaction type: 'D' transaction: This program ignores the policy order percent i.e. it expects the entries to be 100% figures.

Transaction Processing fields

Field Label Description
Pol.No/Year:
If arriving from the risk query screen the policy number and year fields will be populated. If entering the program directly from the menu, enter the required policy number. The system displays the latest year for this policy number, which can be changed if required.
Endorsement Endorsement number (obtained from the RISKEND program
Section:
Enter the section to which the transaction is to apply or all if the entry is to be for more than 1 section.
Replace TranNo Transaction to be replaced
Type:
Enter the transaction type. Double click for a list of available types. If this is the first transaction against a given policy number year and section then the options are reduced to original premium and minimum deposit premium.
MVN:
If a single section has been specified, enter the market version number. The system checks that this market version exists for the above mix. [KEY-HELP] displays details of the market.
Earliest A/C Date:
This defaults to the current system date. If the system has been configured to run in FRS5G mode this date will default to the beginning of the earliest open period if the inception date of the policy has lapsed. This date determines the earliest accounting date that can be used in instalments.
Entry details:
This field may be used to set up structured data referring to the period of the transaction. Entries should follow the structure ‘03Q02’ meaning third-quarter 2002. The annotation can be edited in the adjacent field.
Premium W TOC:
If a premium warranty applies (terms of credit), enter the difference in days between the premium warranty dates and the instalment dates. The system will make a set of entries into the diary so that receipts and payments can be monitored by the command console.
Terms/trade Terms of trade in days. Added to payable date for PANS etc
Source:
Enter the currency of the transaction.
Dest:
If the source currency is not a banking currency enter the currency into which the transaction is likely to be converted. If the source currency is a banking currency then this currency will normally be the same as the source currency. Note that a transaction with different source and destination currencies will be treated as a soft currency transaction and will need to be converted before cash matching can be done.

Where a destination currency is selected where there is no bank account of that currency for the division of the policy/year for which the transaction is being created a warning will appear.

Gross:
For a single section transaction, enter the gross amount. Premium type transactions are entered as debits; claim type transactions are entered as credits (minus).
Section / Gross amount Split:
It is not necessary to make entries in this table for single section transactions. If the section has been set to all enter the gross amount and relevant market version for each section. Enter zero against those sections not involved in the transaction. (A zero amount against a section will still enable a fee to be processed against this section.) The aggregate of the amounts is shown in the gross amount field (in source currency).
Instalments
Base Date:
Date of the transaction or the date instalments are to commence. This defaults to the inception date of the policy.
Number:
Number of instalments. This field defaults to 1 implying annually (A) in the frequency Field. All other numbers require the frequency to be entered.
Frequency:
‘M’ monthly, ‘Q’ quarterly, ‘H’ half-yearly, ‘A’ annually,
Delay 1st/Other:
This sets the payable by date. Enter the number of days to delay the first instalment and then subsequent instalments.
Gross Amount:
Displayed automatically. Edit these dates using shift/tab (previous field) from the next block below.
Installment Date - Displayed automatically. Edit these dates using shift/tab (previous field) from the next block below.
Payable by Displayed automatically. Edit these dates using shift/tab (previous field) from the next block below.
Account Date: Displayed automatically
Tax/Fees Section:
Enter the fee code if this applies. LOV available. The calculation of the tax/fee depends on the configuration in the FEES program. Press [COMMIT] if taxes/fees do not apply or when the input of the taxes/fees is complete.
Tax Description:
Details of the select tax/fee are displayed.
Sect:
For taxes enter the section to which the tax should apply or all. For a tax, only those sections against which non zero amounts have been entered will be involved in the calculations. For a fee, specify the section to which the fee should apply. Fees may be assigned to a section having a zero amount (because the fee is an amount whilst the tax is a percentage).
B Basis - the percentage based on 'G'ross, 'O'rder, 'C'lient,'N'et amount, or 'S'ums insured.
 % of:
A tax will require a percentage of gross amount to be assigned to the specified accounts.
L/B:
Normally taxes are computed on the line (signed share) of the parties involved in the tax. Certain taxes (eg VAT in Nigeria on insurers) are computed as a percentage of brokerage. Select ‘L’ or B’ as required.
Adv:
Normally taxes apply on each instalment. By ‘advancing’ the tax all the tax can be applied to the first instalment only.
1st Inst. Amt:
A fee will require the amount of the fee to be entered. The fee will apply to the first instalment only. The amounts entered are the net amounts – they are not scaled in any way to the order percentage or signed lines.
Debit:
This displays the IBA account to be debited. Depending on how the tax/fee has been configured you may need to specify the appropriate account. If it has been configured as an all situation, this field will not be enterable.
Credit.
This displays the IBA account to be credited.
Press [COMMIT]…
Enter [COMMIT] to for calculations or shift/tab to revisit fees, instalments etc.

Precedence Taxes default to N when creating a market both on a net and gross basis.


Version History

v 7.0.0 – Updated to the latest version
v 6.4.0 – Updated to the latest version
v 6.2.0 – Updated to the latest version
v 6.0.0 – Updated to the latest version
v4.2.0 – Updated to latest version
V241L - FMX-2868 fixing index violations
V156M - SI based taxes implemented (see FEES)
V152M Trigger  i_ibat_all corrected to allow client specific market (i.e. not 'CLIENT')
V150M Tax/Fee calculations. Interpret a '.' suffix in fees as meaning '.' and and all facilities 'A'-'Z'.
V149M suppress TRAN_LOG message unless dataset is 'NIC'
v147P - First version of this form to use the new style. No other updates except the restyle.