Objective
A transaction is a record of the sale of a policy or other asset. While the way transactions are managed will vary depending on the needs of the business, the most commonly defined activity is a monthly paid premium for each active customer that may include premiums, eligible counts, claims expense or other data that is eligible for commission.
Before we go into the process flow for importing and posting transactions, let’s review the key transaction tables.
The master transaction record is stored in the TranHead (short for Transaction Header) table, so named because it contains the header information for the transaction. This includes an auto-generated primary key called TranHeadNo and a pointer to the customer record called CustomerNo.
The TranHis (Transaction History) table holds the billing information for the vendor. It is used as the source information to calculate the commission amount. Key fields in this table include the Transaction History Number (TranHisNo), Transaction Head Number (TranHeadNo), Broker Number (BrokerNo), and Vendor Number (VendorNo).
The BrokerHistory table contains the summary of all broker balances, including earned and paid commissions by billing period. This is important for keeping track of outstanding balances, so they can be properly applied to current payouts.
As we saw in the unit on data integration, TranHead records are imported via an import table called InTranHead. However, the transaction posting process does much more. It is during the posting process that the calculation takes place.
During the transaction posting process, InTranHead records are converted to TranHead records and a broker specific TranHis record is created for every broker found during the Broker Detail lookup process. TranHis records are also updated with additional information derived or computed as part of the payout process.
After computation is complete, a BrokerHistory record is created for every TranHis record that was computed for the first time or recomputed and an adjustment was created from the Computation task in Payout. Additional BrokerHistory records can be created without a TranHis or TranHead through Bonus Calculations or Manual Adjustments being created as part of the payout.
BrokerHistory records are the final payment records created by the payout process, and are locked once the payout has been finalized.
When a transaction enters the system, it contains minimal detail. Before it can be posted, we need a process to populate the transaction with necessary data from the policy, customer and broker records. This is done using a Global Transaction Default.
Typically, a transaction would include the following information:
However, this isn’t enough detail to calculate the commission. We need to ensure that the correct producer is paid, that they are paid the right amount, and the ERP extract is distributing the payment across the correct Lines of Business. Therefore, at a minimum, the system also needs the following information:
Global Transaction Defaults allow us to populate data on the transaction that’s needed for calculating commissions, reporting, AP extracts and other output. Data can be populated directly, or it can be derived or modified though the use of expressions.
Let’s look at an example.
A transaction comes in for a policy sold to Page Mortgage Group with the following information:
This isn’t enough to calculate the commission. For example, we don’t know who the writing agent or agency is, the location, policy age, and other information that tells us what the commission rate will be. The Global Transaction Default tells the system how to pull this information and add it to the transaction.
In this exercise, we will use the Global Transaction Default to populate the transaction with the information we will need to compensate the payees. This includes the State field, which we will retrieve from the Customer Policy.
Update the Global Transaction Default to only apply to transactions with a Transaction Type of Income Transaction.
From the Administrator portal, select Commission Settings→Global Transaction Defaults.
Open the first record in the list, with tab sequence 10.
Under Entity Rules, select (+).
Set the recType to Match Rules.
Select Save.
Select Add Rule.
Set the Field Name to TransType.
Leave the Comparator at Equals.
Set the Field Value to Income Transaction.
Add a step to populate the state from the customer policy record to the transaction.
Scroll to the After CustPolicy section.
Select (+).
Enter the following information in the TranDefault Detil screen:
Select Save.
Select Close.
Now that we have configured the Global Transaction Default, we can import and post our transactions. As we saw earlier, posting transactions uses the Global Transaction Default settings to populate the Transaction Detail with data from other tables; then, the commission is calculated from a Schedule.
Once the Post process is complete, the transactions will be visible in the Integration portal under Inquiry→Transaction Search.
In this exercise, we will import and post a set of transactions from a spreadsheet using the same process we used in Unit 5. An Import Format called TransactionImport has already been created.
Create the Transactions import file.
From the Integration portal, select Inbound Data→File Search.
Select Add (+)
Enter the following for the Transaction Import file:
Select Save.
Select Add Import Request.
Set the import format to Transaction Import.
Leave the upload type set to Client.
Select Choose File.
Select Transactions.xls, then select Open.
Select Next.
Select Complete.
Post the Transactions
Select Ready.
Select OK.
Select Post.
In the Statistics area, verify the Posted column is populated with the number of transactions.
View the imported and posted transactions.
From the Manager portal, select Inquiry→Transaction Search.
Select Search to display all transactions.
Open any transaction and view the details.