Transactions can be accessed in two locations, one is the Transaction list page which shows Transactions across all policies, the other is accessed from within a Policy where only Transactions for that Policy are displayed.
Transactions can be created manually or imported using the Policy & Transaction import or the Transactions import.
Transaction List Page across all Policies
When adding a transaction from the list page that is not accessed within a Policy, the Policy number must be selected.
Add Transaction detail page accessed from List page across all policies
Creating a Transaction from the List Page across Policies:
Once the Policy number is entered, these values default in; Policyholder Name, Issuer, Transaction Date (today’s date), Status (Open), Commissionable Premium and Premium (initially from Policy detail values, then after the first Transaction from the previous Transaction).
Transaction Detail page – Add Transaction
Transaction List Page from within a Policy
Transactions for a Policy can be accessed from the Policy list page or from Policy Details.
Policy list page – detail view showing line options highlighting one to view Transaction details
Policy detail page – link to access transaction
The Transaction list page accessed from within a Policy does not have columns for the Policy Number, Policy Holder, and Issuer.
Transaction List page accessed from within a Policy
When you use one of the links to Add Transaction Record the page that is displayed does not require entry of the Policy number. Other than Policy Number, Policyholder, and Issuer, the same information defaults into the Transaction from the Policy Details or from the Previous Transaction as described earlier for adding a transaction.
Transaction Detail page accessed from within Policy Details
Additional Information on Transactions:
The Source File/Batch ID is populated when an import is used. If you need to remove a batch of Transactions, you can copy the filename in this section and paste it into ‘Remove Transactions’ if the Transactions are still in open Status.
Member Count is used for Policies with commissions based on fixed rates. A negative Member Count can also be used for Group and non-group Fixed Amount commission Policies. For a Fixed Amount that pays $25 per month to an Agent, when a -1 Member Count is used, the commission will be -$25. Or if a Group initially had a Transaction with a Member Count of 80, if it were discovered there was an error and it should have been 75, a Transaction of -5 could be used to pay back the overpayment amount. Imports that create Transactions will add a negative one to Member Count automatically if the Premium or Commission Received is negative.
Negative values for Premium and Commissionable Premium can be used. So, if an earlier Transaction were paid for an incorrect Premium of $100, a new Transaction could be created for -$100, and then an additional Transaction for the right amount could be used. Or.
The Transaction Date can be left to default to today’s date (date Transaction created) or can be adjusted. It can be helpful to make the Transaction date the same as the expected commission Processing Date to identify all transactions that were part of a cycle.
The Commission Processing Date for a cycle will look for all matching Transactions with a Transaction Date on or later than the Processing Date. While all Commissions should be paid when they come in to the Agents according to internal contractual arrangements, in an emergency the date could be moved beyond the Commission Processing Date if more time was needed to correct an error.
Effect when Payment Months is greater than one, for example, with three (3) Payment Months entered in a Transaction for a quarterly payment, in the Results page in the cycle, and in the Commission Activity in the Statements, each respective month will be displayed in separate lines for each month. This assures that Advances and Advance Recovery are calculated and displayed.
There is a validation on the Paid Thru Date for the first Transaction in the Commission Cycle for Policies set to allow paying an advance. This is to help prevent issues. This error may occur if the Paid Thru Date on your first transaction is past the first month.