Functions
A dynamic logic function is the most generic type of dynamic logic: it can have one or more input arguments and return different types of output. A dynamic logic function is used to extend default behavior in certain areas. Each usage of dynamic logic functions is described in a separate paragraph below.
Adjustment
On adjustment rules a dynamic logic function can be specified to calculate the adjustment amount.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyEnrollmentProduct |
PolicyEnrollmentProduct |
The policy enrollment product that is being evaluated |
In |
adjustmentRule |
adjustmentRule |
The adjustment rule that is selected |
In |
amount |
Money |
The input amount on which the adjustment is calculated |
In |
yearlyAmount |
Money |
The yearly input amount on which the adjustment is calculated (only applicable for the calendar year amount interpretation) |
In |
referenceDate[1] |
Date |
The reference date of the calculation period segment that is being calculated |
In |
lastCalculationPeriodSegment |
Boolean |
In the context of System Calculation Period: Is the calculation period segment that is being calculated the last calculation period segment in the contract period? (this is only applicable for Contract Period Based calculations; refer to the "Contract Period Based" section in the Premium Calculation chapter of the Operations Guide for more information on this calculation methodology) In the context of Policy Calculation Period: Is the calculation period that is being calculated the last calculation period split? |
In |
calculationPeriod |
CalculationPeriod or PolicyCalculationPeriod |
The system calculation period or policy calculation period for which the adjustment is being evaluated |
In |
reconciliationInput |
Object |
Applicable in context of Policy Calculation Period. It has the following attributes * rate (in/out): This in/out variable holds the rate which is applied to calculate the adjustment amount. The prorate function must set this when the rate is derived. This rate gets persisted as the retrieved value on the result line. As the input variable, this is always set to null, except for the last policy calculation period split when all the past splits have the same value. Note this is also set to null when there are no splits to PCP. * applicableBaseAmount:This is the total base premium amount applicable for the full policy calculation period span period. This is set only when adjustment reconciliation applies. Otherwise, it is null. * totalChargedAmount: This is the sum of adjustments charged for up to the last policy calculation period splits |
In |
calculationResult |
Object |
The current calculationResult for the period. This holds all the lines which are calculated previously before the adjustment gets calculated. |
Out |
n/a |
Money |
The adjustment amount and currency as outcome of the calculation |
The input amount is the calculated amount up to the point in the process where the adjustment rule is applied.
The calculationPeriod.referenceDateForCalculation field returns the reference date of the calendar period if set, start date otherwise.
Consider a simple example that increases the input amount by 10%:
return amount * 0.1
Consider an example that takes care of rounding in the event that policy calculations are potentially broken into smaller periods:
import static java.math.RoundingMode.HALF_UP // assuming a function that applies a 7.1% adjustment adjustmentRate = new BigDecimal("7.1") // if this is the last part of the calculation period // and the rate and applicableBaseAmount have values // and the rate has not changed across all segments of the calculation period // then calculate the adjustment by calculating to the total and subtracting what has already been charged // else calculate the adjustment by simply taking 7.1% of the base amount // Note the additional nesting of the last condition prevents a NPE when // reconciliationInput.rate is null if ( lastCalculationPeriodSegment && reconciliationInput.rate && reconciliationInput.applicableBaseAmount && (reconciliationInput.rate && reconciliationInput.rate == adjustmentRate)){ totalApplicableAdjustment = reconciliationInput.rate * reconciliationInput.applicableBaseAmount return totalApplicableAdjustment - reconciliationInput.totalChargedAmount } return amount * adjustmentRate
When multiple adjustments with a different sequence are applicable, and non-prorate function is used for an adjustment with a lower sequence, the system uses reconciliationInput.rate to calculate the applicable total amount for an adjustment with the higher sequence. If a rate is not returned for adjustment with a lower sequence, applicableBaseAmount for the adjustment with a higher sequence is not calculated. |
Bulk Update Definition
A bulk update definition is evaluated during the bulk update of a policy. It is used to make updates on the policy that is passed in as a parameter. This signature specifies the referenceDate on the bulk update definition as the default as-of date. If there is no referenceDate defined on the bulk update definition, then system date is set as the default as-of date.
The following signature applies:
In or Out | Name | Type | Description | ||
---|---|---|---|---|---|
In |
bulkUpdateDefinition |
BulkUpdateDefinition |
The bulk update definition being evaluated (can be used to parametrize the dynamic logic) |
||
In |
policy |
Policy |
The policy that is being evaluated for bulk update |
||
In |
parameters |
Map [key, value] |
List of name-value pairs that can be used in the dynamic logic
|
Using this dynamic logic function the policy and its details can be modified. The following are allowed:
-
policy: dynamicFields, addMessage, endPolicy
-
policyEnrollment: dynamicFields, endPolicyEnrollment
-
policyEnrollmentProduct: dynamicFields, endDate, premiumAmount, commissionPercentage, commissionAmount, commissionAmountInterpretation, commissionNoOfDays, add new policy enrollment product, this can only be done by using predefined method copyAndEndDateEnrollmentProduct
-
policyEnrollmentInsurableClass: dynamic Fields, endDate, add new policy enrollment insurable class, this can only be done by using predefined method copyAndEndDateEnrollmentInsurableClass
-
policyGroupAccount: dynamic Fields, endDate, add new policy group account, this can only be done by using predefined method copyAndEndDatePolicyGroupAccount
-
policyholder: dynamicFields, endDate, add new policyholder, this can only be done by using predefined method copyAndEndDatePolicyholder
-
policyContractPeriods: dynamicFields, reference date, endDate, add new policy contract period, this can only be done by using predefined method copyAndEndDateContractPeriod
-
policyCollectionSettings: dynamicFields, span reference date, endate, advance length, advance UoM, indicator calculation period, calculation period length and UoM, collection method,add new policy collection setting, this can only be done by using predefined method copyAndEndDateCollectionSetting
-
policyBrokerAgent: dynamicFields, endDate existing and adding a new policy broker agent can be done by using predefined method copyAndEndDateBrokerAgent. Addition of a new broker agent (for example, when no broker or agent exist on a policy) can be done by using predefined method addBrokerAgent
-
attachedPolicyData: indIgnoreBulkUpdate and dynamicFields
-
policyAdd-Ons: dynamicFields, endDate
-
parameterValue on the policyEnrollmentProduct: amount, serviceDays, amountPerUnit, percentage, startDate, endDate, and dynamicFields.
-
policyPremiumBillAllocation: dynamic fields, endDate
-
policyBillReceiver: dynamic fields, percentage
The following example shows dynamic logic that updates a policy for bulk update definition RENEWAL. The logic creates new contract periods for year 2016and also updates a dynamic field on the new contract period, "DYNA" to value X.
def newContract = policy.copyAndEndDateContractPeriod(java.sql.Date.valueOf("2016-01-01") newContract.DYNA = "X"
Callout Rule
A Callout Rule specifies dynamic function to create a request message body, make the callout and to handle the response message.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
calloutRule |
CalloutRule |
The callout rule that is being evaluated (can be used to parametrize the dynamic logic) |
In |
policy |
Policy |
The policy that is being evaluated |
This signature does not specify a default as-of date.
Using this dynamic logic function the policy and its details can be modified, except for the following:
-
policy.code
-
policy.gid
-
policy.status
-
policy.version
-
policy.processFlow
-
policy.policyEnrollmentList
-
including the native fields of the policy enrollment; dynamic fields can be modified
-
-
policy.policyMessageList
-
including all fields of the policy message
-
note that the addMessage method can be used to add messages to the policy
-
-
policy.policyStatusHistoryList
-
including all fields of the policy status history
-
including the related policyPendHistoryList and all fields of the policy pend history
-
-
policy.attachedPolicyData.indManual
-
policy.policyEnrollment.policyEnrollmentProductList
-
including the fields enrollmentProduct and groupAccountPoduct of the policy enrollment product; other native fields and dynamic fields can be modified
-
-
policy.policyEnrollment.policyEnrollmentProduct.policyAddOnList
-
including the field addOn of the policy add-on; other native fields and dynamic fields can be modified
-
The following example shows dynamic logic that creates a callout message with information about the policy and the brand and group account to which the policy belongs to. The system makes a callout to an external service using RestClientBuilder assuming the callout is Rest based. It then processes the response received from the external callout. The response gives a value of a dynamic field to be set on the policy.
Sample request:
<policy code="POLICY123"> <brand>TOP</brand> </policy>
Sample response:
<customMessage dynamicFieldABCD="Value12345"/>
Sample callout dynamic logic function to create the above request and parse the above response:
def writer = new StringWriter() def xml = new groovy.xml.MarkupBuilder(writer) xml.policy(code:policy.code) { brand(policy.brand.code) } //Make the callout request String response = initCallout(WebTarget.class) .path("post") .request() .buildPost(Entity.xml(writer.toString())) .invoke() .readEntity(String.class) //Process Response def result = new XmlSlurper().parseText(response) policy.dynamicFieldABCD = result.customMessage.@dynamicFieldABCD.text()
Parsing XML in dynamic logic can be done with the XmlSlurper library.
By default, the callout invocation to the external service endpoint is done in a BasicAuthentication way. Property "ohi.service.{0}.client.authentication" (for example: "ohi.service.DYLO_CODE.client.authentication" where DYLO_CODE is the uniquely identifying code of the Dynamic Logic script) must be set to value BasicAuthentication, None or OAuth to change the authentication mechanism. In case, the external callout needs authentication, the credentials must be specified using the "credentials" resource. The default value for "ohi.service.{0}.client.authentication" is BasicAuthentication.
Alternatively, a callout request can also be specified with a callerId to identify the client, for example:
//Make the callout request String response = initCallout(WebTarget.class, "MY_CALLER_ID") .path("post") .request() .buildPost(Entity.xml(writer.toString())) .invoke() .readEntity(String.class)
In that case the authentication feature can be controlled with property "ohi.service.MY_CALLER_ID.client.authentication". This feature also allows use of multiple clients in one dynamic logic function and precise specification of features on a per client basis.
When not calling the readEntity operation on the Response that is returned from the invoke() operation - make sure the underlying response is closed.
In the above example: when assigning the result of invoke() to a variable and working with that variable in the remainder of the dynamic logic, call the operation close() on it.
|
For a configured callout rule to be resolved to a callable endpoint, a property should be set. "ohi.{0}.endpoint.request" (for example: "ohi.DYLO_CODE.endpoint.request" where DYLO_CODE is the code of the configured callout rule) should be set to the URI of the end point, this is the actual (external) HTTP address that is used by the REST callout client. An example of this value is "http://machine.domain:port/{0}
External callouts can be logged at a fairly low level. In particular, this enables to trace HTTP request and response between the system that initiates the request for enrollment status information and the enrollment system that responds back to these inquiries. To set this up, add the following piece of information to the logging configuration:
<logger name="ohi.rest.client" level="info"/>
Change Event Rule
There are two signatures for change event rule functions:
-
Effective Date
-
Function
Effective Date
Modifications on a number of tables can lead (through configurable change event rules) to policy events. The date from which the day onward the modification must have an effect is configurable through a dynamic logic function. It depends on the entity which is modified. Often, it is the start date of a time-valid entity, but it may be something else like the sysdate.
The following signature applies to define the effective date of a policy event (and policy mutation):
In or Out | Name | Type | Description |
---|---|---|---|
In |
old[EntityName] that is, entity name is prefixed by "old" |
Depends on the entity (old) |
The old version of the entity that is being evaluated |
In |
new[EntityName] that is, entity name is prefixed by "new" |
Depends on the entity (new) |
The new version of the entity that is being evaluated |
Out |
effectiveDate |
Date |
The date (without time aspect) from which on the mutation becomes effective |
An example of a policy enrollment product:
return newPolicyEnrollmentProduct.startDate
In the case of a delete, there is no new , and in the case of create, there is no old .
|
If the object is inheritance-based, like collection setting, assigned broker agent, or assigned adjustment, then the logic can look like:
for ( variable in binding.variables ) { if(variable.key.startsWith("new")) { return variable.value.startDate } }
The reason for having both the old and new versions of the object being modified as an input parameter is that when the start date of the object is being changed, is becomes possible to pick the earliest date.
Function
The following signature applies for change event rules of type Function:
In or Out | Name | Type | Description |
---|---|---|---|
In |
old[EntityName] that is, entity name is prefixed by "old" |
Depends on the entity (old) |
The old version of the entity that is being evaluated |
In |
new[EntityName] that is, entity name is prefixed by "new" |
Depends on the entity (new) |
The new version of the entity that is being evaluated |
For example, this type of rule makes it possible to create a new default billing account under a group client upon the creation of the group client:
GroupClientBillingAccount groupClientBillingAccount = new GroupClientBillingAccount() groupClientBillingAccount.code = newGroupClient.code + "_BA" groupClientBillingAccount.descr = "Default billing account for " + newGroupClient.code groupClientBillingAccount.defaultBillingAccount = true newGroupClient.addGroupClientBillingAccount(groupClientBillingAccount)
The following actions are supported within these functions: manipulating the context object, retrieving lookup objects and traversing the object graph from the context object. Any other actions (for example performing callouts or performing searches) are not supported.
The following is allowed to be updated based on the entity (including native fields, dynamic fields and records as applicable) :
-
Person
-
person address
-
assigned provider
-
contract alignment
-
bank account number relation
-
marital status
-
title
-
-
Policy Calculation Period
-
The following cannot be modified - GID, Ind Monthly, Ind Generated
-
-
Enrollment Product
-
enrollment product add-on
-
enrollment product account definition
-
enrollment product adjustment
-
enrollment product time period
-
enrollment product adjustment value
-
-
enrollment product detail
-
enrollment product premium schedule
-
enrollment product provider group
-
enrollment product time period
-
parameter domain
-
domain value
-
-
-
Group Account Product
-
group account available product
-
group account product adjustment
-
group account product adjustment value
-
group account product premium schedule
-
group account product provider group
-
parameter domain
-
domain value
-
-
-
Group Account
-
broker agent switch rule
-
group account add on
-
group account adjustment
-
group account broker agent
-
group account collection setting
-
group account insurable class
-
group account premium schedule
-
group account product
-
group account available product
-
group account product adjustment
-
group account product adjustment value
-
group account product premium schedule
-
group account product provider group
-
parameter domain
-
domain value
-
-
-
group account time period
-
-
Group Client
-
Group Account
-
broker agent switch rule
-
group account add on
-
group account adjustment
-
group account broker agent
-
group account collection setting
-
group account insurable class
-
group account premium schedule
-
group account product
-
group account available product
-
group account product adjustment
-
group account product adjustment value
-
group account product premium schedule
-
group account product provider group
-
parameter domain
-
domain value
-
-
-
-
group client adjustment
-
group client billing account
-
group client broker agent
-
group client collection setting
-
group client premium schedule
-
group commission rate
-
premium bill allocation
-
Counter Party
On the bill receiver, a dynamic logic function is specified to lookup the counter party to whom the premium should be billed.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
billReceiver |
BillReceiver |
The bill receiver in context |
In |
calculationResultLine |
CalculationResultLine |
The calculation result line that is processed |
Out |
n/a |
Alphanumerical |
The counter party code to whom the premium should be billed |
The following example shows a piece of logic that finds the bill to organization code defined on the group client of the bill receiver’s group account. In case no bill to organization is defined on the direct group client, it searches the group client hierarchy upwards until a group client is found that has a bill to organization and returns the organization code.
def findOrganizationCode(GroupClient groupClient) { if (groupClient.organizationRecipient) { return groupClient.organizationRecipient.code } else if (groupClient.parentGroupClient) { return findOrganizationCode(groupClient.parentGroupClient) } else { return null } } def organizationCode = findOrganizationCode(billReceiver.premiumBillAllocation.groupClient)
Country Format
This function is attached to a country and defines the format of addresses within that country. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
address |
Address |
The address that is to be displayed |
Out |
n/a |
String |
The character string that represents the formatted address. |
This function is executed whenever an address is displayed. There is no default as-of date.
Create Accounting Details
Dynamic Logic of the signature Create Accounting Details holds the logic to create accounting details based on the accounting detail grouping criteria. These dynamic functions are executed once per accounting detail generated by the Generate Financial Message activity.
Create Accounting Detail XML
Parameters
In or Out | Parameter | Type | Description |
---|---|---|---|
In |
financialTransactionDetail |
FinancialTransactionDetail |
The financial transaction detail from which the invoice line attributes are derived to contract the XML. |
In or Out |
accountingDetail |
AccountingDetail |
XML <accountingDetail> element that is included in the financial message. |
The dynamic logic needs to:
-
transfer all desired values from the financial transaction detail and related objects to the accounting detail. In addition, logic needed to set details that only exist in an accounting detail may be included (that is, to set values that are derived as opposed to simply being transferred)
Create Accounting Detail Flat File
This function is executed for each "accounting detail grouping" of financial transaction details. This function allows creation of zero, one, or more flat file rows each time it is executed.
Parameters
Parameter Name | Parameter Type | Input / Output | Description |
---|---|---|---|
financialMessage |
FinancialMessage |
Input |
Financial Message Context |
financialTransactionDetail |
FinancialTransactionDetails |
Input |
Financial Transaction Detail |
invoice |
Invoice |
Input |
InvoiceContext |
accountingDetail |
AccountingDetail |
Input |
Accounting Detail Context |
fileRows |
List<FileRow> |
Input/Output |
File row consists of the file identifier and row content |
- Example
Map glInt = [:] glInt.STATUS = "NEW" glInt.LEDGER_ID = "300000004014096" glInt.ACCOUNTING_DATE = accountingDetail.accountingDate glInt.USER_JE_SOURCE_NAME = "OHI" glInt.USER_JE_CATEGORY_NAME = "OHI" glInt.CURRENCY_CODE = glInt.DATE_CREATED = glInt.ACTUAL_FLAG = "A" glInt.SEGMENT1 = glInt.SEGMENT2 = glInt.SEGMENT3 = glInt.SEGMENT4 = glInt.SEGMENT5 = glInt.SEGMENT6 = "" glInt.SEGMENT6 = "" glInt.SEGMENT8 = "" glInt.SEGMENT9 = "" glInt.SEGMENT1O = "" glInt.SEGMENT11 = "" glInt.SEGMENT12 = "" glInt.SEGMENT13 = "" glInt.SEGMENT14 = "" glInt.SEGMENT15 = "" glInt.SEGMENT16 = "" glInt.SEGMENT16 = "" glInt.SEGMENT18 = "" glInt.SEGMENT19 = "" glInt.SEGMENT2O = "" glInt.SEGMENT21 = "" glInt.SEGMENT22 = "" glInt.SEGMENT23 = "" glInt.SEGMENT24 = "" glInt.SEGMENT25 = "" glInt.SEGMENT26 = "" glInt.SEGMENT26 = "" glInt.SEGMENT28 = "" glInt.SEGMENT29 = "" glInt.SEGMENT3O = "" glInt.ENTERED_DR = accountingDetail.amountDebit.toPlainString() glInt.ENTERED_CR = accountingDetail.amountCredit.toPlainString() glInt.ACCOUNTED_DR = "" glInt.ACCOUNTED_CR = "" glInt.REFERENCE1 = financialMessage.jobId glInt.REFERENCE2 = "" glInt.REFERENCE3 = "" glInt.REFERENCE4 = "" glInt.REFERENCE5 = "" glInt.REFERENCE6 = "" glInt.REFERENCE7 = "" glInt.REFERENCE8 = "" glInt.REFERENCE9 = "" glInt.REFERENCE10 = "" glInt.REFERENCE21 = "" glInt.REFERENCE22 = "" glInt.REFERENCE23 = "" glInt.REFERENCE24 = "" glInt.REFERENCE25 = "" glInt.REFERENCE26 = "" glInt.REFERENCE27 = "" glInt.REFERENCE28 = "" glInt.REFERENCE29 = "" glInt.REFERENCE30 = "" glInt.STAT_AMOUNT = "" glInt.USER_CURRENCY_CONVERSION_TYPE = "" glInt.CURRENCY_CONVERSION_DATE = "" glInt.CURRENCY_CONVERSION_RATE = "" glInt.GROUP_ID = financialMessage.jobId glInt.ATTRIBUTE_CATEGORY = "OHI_DATA" glInt.ATTRIBUTE1 = "" glInt.ATTRIBUTE2 = "" glInt.ATTRIBUTE3 = "" glInt.ATTRIBUTE4 = "" glInt.ATTRIBUTE5 = "" glInt.ATTRIBUTE6 = "" glInt.ATTRIBUTE7 = "POL" glInt.ATTRIBUTE8 = accountingDetail.ohiAccountingDetailId glInt.ATTRIBUTE9 = "" glInt.ATTRIBUTE10 = "" glInt.ATTRIBUTE11 = "" glInt.ATTRIBUTE12 = "" glInt.ATTRIBUTE13 = "" glInt.ATTRIBUTE14 = "" glInt.ATTRIBUTE15 = "" glInt.ATTRIBUTE16 = "" glInt.ATTRIBUTE17 = "" glInt.ATTRIBUTE18 = "" glInt.ATTRIBUTE19 = "" glInt.ATTRIBUTE20 = "" glInt.ATTRIBUTE_CATEGORY_3 = "" glInt.AVERAGE_JOURNAL_FLAG = "" glInt.ORIGINATION_BAL_SEG_VALUE = "" glInt.LEDGER_NAME = "" glInt.ENCUMBRANCE_TYPE_ID = "" glInt.JGZZ_RECON_REF = "" fileRows.add(new FileRow("GL_INTERFACE", glInt.values().join(",")))
Create Invoice
The transaction details are grouped into invoices within a Financial Message. Grouping of invoices is done on various attributes on Financial Transaction and Financial Transaction Detail (Process Data). Additional fields required for an invoice are added or generated in this dynamic logic function. Dynamic Logic of the signature Create Invoice holds the logic to create invoices based on the invoice grouping criteria. Because of the grouping functionality all attributes on a financial transaction detail that have to be included in an invoice element are the same. For this reason, the invoice element can be based on a single financial transaction detail as input for the dynamic logic function.
Create Invoice XML
Dynamic functions of this type fill the values of an invoice element for an invoice of selected transaction. They are executed once per invoice of the transactions being processed.
Parameters
In or Out | Parameter Name | Type | Description |
---|---|---|---|
In |
financialTransactionDetail |
FinancialTransactionDetail |
The financial transaction detail from which the invoice header attributes are derived to construct the XML. |
In/Out |
invoice |
Invoice |
XML <invoice> element that is included in the financial message. Input: empty invoice with only the attributes assigned by the fixed logic set |
The dynamic logic needs to:
-
transfer all desired values from the input parameters and financial transaction(s) to the invoice header In addition, logic needed to set details that only exist in an invoice header may be included (that is, to set values that are derived as opposed to simply being transferred).
Create Invoice Flat File
This function is executed for each "Invoice grouping" of financial transaction details. This function allows creation of zero, one, or more flat file rows each time it is executed.
Parameters
Parameter Name | Parameter Type | Input / Output | Description |
---|---|---|---|
financialMessage |
FinancialMessage |
Input |
Financial Message Context |
financialTransactionDetail |
FinancialTransactionDetail |
Input |
|
invoice |
Invoice |
Input |
Invoice Context |
fileRows |
List<FileRow> |
Input/Output |
FileRow consists of the file identifier and row content |
Example
Map apInv = [:] apInv.INVOICE_ID apInv.OPERATING_UNIT = "OHI BU" apInv.SOURCE = "EXTERNAL" apInv.INVOICE_NUM apInv.INVOICE_AMOUNT = invoice.invoiceAmount apInv.INVOICE_DATE apInv.VENDOR_NAME = "" apInv.VENDOR_NUM apInv.VENDOR_SITE_CODE apInv.INVOICE_CURRENCY_CODE = apInv.PAYMENT_CURRENCY_CODE apInv.DESCRIPTION = "Health Insurance Policy" apInv.GROUP_ID = financialMessage.jobId apInv.INVOICE_TYPE_LOOKUP_CODE apInv.LEGAL_ENTITY_NAME = "OHI Entity" apInv.CUST_REGISTRATION_NUMBER = "" apInv.CUST_REGISTRATION_CODE = "" apInv.FIRST_PARTY_REGISTRATION_NUM = "" apInv.THIRD_PARTY_REGISTRATION_NUM = "" apInv.TERMS_NAME = "Immediate" apInv.TERMS_DATE apInv.GOODS_RECEIVED_DATE = "" apInv.INVOICE_RECEIVED_DATE apInv.GL_DATE apInv.PAYMENT_METHOD_CODE = "EFT" apInv.PAY_GROUP_LOOKUP_CODE apInv.EXCLUSIVE_PAYMENT_FLAG = "" apInv.AMOUNT_APPLICABLE_TO_DISCOUNT ="" apInv.PREPAY_NUM = "" apInv.PREPAY_LINE_NUM = "" apInv.PREPAY_APPLY_AMOUNT = "" apInv.PREPAY_GL_DATE = "" apInv.INVOICE_INCLUDES_PREPAY_FLAG = "" apInv.EXCHANGE_RATE_TYPE = "CORPORATE" apInv.EXCHANGE_DATE apInv.EXCHANGE_RATE "" apInv.ACCTS_PAY_CODE_CONCATENATED = "010-22500-00000-00000-00000-00000-00000" apInv.DOC_CATEGORY_CODE = "" apInv.VOUCHER_NUM = "" apInv.REQUESTER_FIRST_NAME = "" apInv.REQUESTER_LAST_NAME = "" apInv.REQUESTER_EMPLOYEE_NUM = "" apInv.DELIVERY_CHANNEL_CODE = "" apInv.BANK_CHARGE_BEARER = "" apInv.REMIT_TO_SUPPLIER_NAME = "" apInv.REMIT_TO_SUPPLIER_NUM= "" apInv.REMIT_TO_ADDRESS_NAME = "" apInv.PAYMENT_PRIORITY = "1" apInv.SETTLEMENT_PRIORITY = "NORMAL" apInv.UNIQUE_REMITTANCE_IDENTIFIER = "" apInv.URI_CHECK_DIGIT = "" apInv.PAYMENT_REASON_CODE = "" apInv.PAYMENT_REASON_COMMENTS = "" apInv.REMITTANCE_MESSAGE1= "" apInv.REMITTANCE_MESSAGE2 = "" apInv.REMITTANCE_MESSAGE3 = "" apInv.AWT_GROUP_NAME = "" apInv.SHIP_TO_LOCATION = "" apInv.TAXATION_COUNTRY = "" apInv.DOCUMENT_SUB_TYPE = "" apInv.TAX_INVOICE_INTERNAL_SEQ = "" apInv.SUPPLIER_TAX_INVOICE_NUM = "" apInv.TAX_INVOICE_RECORDING_DATE = "" apInv.SUPPLIER_TAX_INVOICE_DATE = "" apInv.SUPPLIER_TAX_EXCHANGE_RATE = "" apInv.PORT_OF_ENTRY_CODE = "" apInv.CORRECTION_YEAR = "" apInv.CORRECTION_PERIOD = "" apInv.IMPORT_DOCUMENT_NUMBER = "" apInv.IMPORT_DOCUMENT_DATE = "" apInv.CONTROL_AMOUNT = "" apInv.CALC_TAX_DURING_IMPORT_FLAG = "N" apInv.ADD_TAX_TO_INV_AMOUNT_FLAG = "N" apInv.ATTRIBUTE_CATEGORY = "OHI_DATA" apInv.ATTRIBUTE1 = "" apInv.ATTRIBUTE2 = "" apInv.ATTRIBUTE3 = "" apInv.ATTRIBUTE4 = "" apInv.ATTRIBUTE5 = "" apInv.ATTRIBUTE6 = "" apInv.ATTRIBUTE7 = "POL" apInv.ATTRIBUTE8 = invoice.ohiInvoiceId apInv.ATTRIBUTE9 = "" apInv.ATTRIBUTE10 = "" apInv.ATTRIBUTE11 = "" apInv.ATTRIBUTE12 = "" apInv.ATTRIBUTE13 = "" apInv.ATTRIBUTE14 = "" apInv.ATTRIBUTE15 = "" apInv.ATTRIBUTE_NUMBER1 = "" apInv.ATTRIBUTE_NUMBER2 = "" apInv.ATTRIBUTE_NUMBER3 = "" apInv.ATTRIBUTE_NUMBER4 = "" apInv.ATTRIBUTE_NUMBER5 = "" apInv.ATTRIBUTE_DATE1 = "" apInv.ATTRIBUTE_DATE2 = "" apInv.ATTRIBUTE_DATE3 = "" apInv.ATTRIBUTE_DATE4 = "" apInv.ATTRIBUTE_DATE5 = "" apInv.GLOBAL_ATTRIBUTE_CATEGORY = "" apInv.GLOBAL_ATTRIBUTE1 = "" apInv.GLOBAL_ATTRIBUTE2 = "" apInv.GLOBAL_ATTRIBUTE3 = "" apInv.GLOBAL_ATTRIBUTE4 = "" apInv.GLOBAL_ATTRIBUTE5 = "" apInv.GLOBAL_ATTRIBUTE6 = "" apInv.GLOBAL_ATTRIBUTE7 = "" apInv.GLOBAL_ATTRIBUTE8 = "" apInv.GLOBAL_ATTRIBUTE9 = "" apInv.GLOBAL_ATTRIBUTE10 = "" apInv.GLOBAL_ATTRIBUTE11 = "" apInv.GLOBAL_ATTRIBUTE12 = "" apInv.GLOBAL_ATTRIBUTE13 = "" apInv.GLOBAL_ATTRIBUTE14 = "" apInv.GLOBAL_ATTRIBUTE15 = "" apInv.GLOBAL_ATTRIBUTE16 = "" apInv.GLOBAL_ATTRIBUTE17 = "" apInv.GLOBAL_ATTRIBUTE18 = "" apInv.GLOBAL_ATTRIBUTE19 = "" apInv.GLOBAL_ATTRIBUTE20 = "" apInv.GLOBAL_ATTRIBUTE_NUMBER1 = "" apInv.GLOBAL_ATTRIBUTE_NUMBER2 = "" apInv.GLOBAL_ATTRIBUTE_NUMBER3 = "" apInv.GLOBAL_ATTRIBUTE_NUMBER4 = "" apInv.GLOBAL_ATTRIBUTE_NUMBER5 = "" apInv.GLOBAL_ATTRIBUTE_DATE1 = "" apInv.GLOBAL_ATTRIBUTE_DATE2 = "" apInv.GLOBAL_ATTRIBUTE_DATE3 = "" apInv.GLOBAL_ATTRIBUTE_DATE4 = "" apInv.GLOBAL_ATTRIBUTE_DATE5 = "" fileRows.add(new FileRow("AP_INVOICES_INTERFACE", apInv.values().join(",")))
Create Invoice Line
The Transaction details are grouped into invoices lines within an Invoice in a Financial Message. Grouping of invoice lines is done on various attributes on Financial Transaction and Financial Transaction Detail (Process Data). Additional fields required for an invoice line are added or generated in this dynamic logic function. Dynamic Logic of the signature Create Invoice Line holds the logic to create invoice lines based on the invoice line grouping criteria.
Create Invoice XML
Dynamic functions of this type fill the values of an invoice line element for an amount that needs to be paid (or retracted). They are executed once for each generated Invoice Line by the Generate Financial Message activity. They are executed within the context of the invoice with the same payment receiver of the financial transaction detail process data.
Parameters
In or Out | Parameter | Type | Description |
---|---|---|---|
In |
financialTransactionDetail |
FinancialTransactionDetail |
The financial transaction detail from which the invoice line attributes are derived to contract the XML. |
In or Out |
invoiceLine |
InvoiceLine |
XML <invoiceLine> element that is included in the financial message. Input: empty invoice header with only invoiceId set |
The dynamic logic needs to:
-
transfer all desired values from the financial detail to the invoice line. In addition, logic needed to set details that only exist in an invoice line may be included (that is, to set values that are derived as opposed to simply being transferred).
Create Invoice Line Flat File
This function is executed for each "Invoice Line grouping" of financial transaction details. This function allows creation of zero, one, or more flat file rows each time it is executed.
Parameters
Parameter Name | Parameter Type | Input / Output | Description |
---|---|---|---|
financialMessage |
FinancialMessage |
Input |
Financial Message Context |
financialTransactionDetail |
FinancialTransactionDetail |
Input |
Financial Transaction Detail |
invoice |
Invoice |
Input |
Invoice Context |
invoiceLine |
InvoiceLine |
Input |
Invoice Line Context |
fileRows |
List<FileRow> |
Input/Output |
File row consists of the file identifier and row content |
- Example
Map apInvLn = [:] apInvLn.INVOICE_ID = apInvLn.LINE_NUMBER = apInvLn.LINE_TYPE_LOOKUP_CODE = "Item" apInvLn.AMOUNT = invoiceLine.Amount apInvLn.QUANTITY_INVOICED = "" apInvLn.UNIT_PRICE = "" apInvLn.UNIT_OF_MEAS_LOOKUP_CODE = "" apInvLn.DESCRIPTION = apInvLn.PO_NUMBER = "" apInvLn.PO_LINE_NUMBER = "" apInvLn.PO_SHIPMENT_NUM = "" apInvLn.PO_DISTRIBUTION_NUM = "" apInvLn.ITEM_DESCRIPTION = "" apInvLn.RELEASE_NUMBER = "" apInvLn.PURCHASING_CATEGORY = "" apInvLn.RECEIPT_NUMBER = "" apInvLn.RECEIPT_LINE_NUMBER = "" apInvLn.CONSUMPTION_ADVICE_NUMBER = "" apInvLn.CONSUMPTION_ADVICE_LINE_NUMBER = "" apInvLn.PACKING_SLIP = "" apInvLn.FINAL_MATCH_FLAG = "" apInvLn.DIST_CODE_CONCATENATED = "010-44040-00000-00000-00000-00000-00000" apInvLn.DISTRIBUTION_SET_NAME = "" apInvLn.ACCOUNTING_DATE apInvLn.ACCOUNT_SEGMENT = "" apInvLn.BALANCING_SEGMENT = "" apInvLn.COST_CENTER_SEGMENT = "" apInvLn.TAX_CLASSIFICATION_CODE = "" apInvLn.SHIP_TO_LOCATION_CODE = "" apInvLn.SHIP_FROM_LOCATION_CODE = "" apInvLn.FINAL_DISCHARGE_LOCATION_CODE = "" apInvLn.TRX_BUSINESS_CATEGORY = "" apInvLn.PRODUCT_FISC_CLASSIFICATION = "" apInvLn.PRIMARY_INTENDED_USE = "" apInvLn.USER_DEFINED_FISC_CLASS = "" apInvLn.PRODUCT_TYPE = "" apInvLn.ASSESSABLE_VALUE = "" apInvLn.PRODUCT_CATEGORY = "" apInvLn.CONTROL_AMOUNT = "" apInvLn.TAX_REGIME_CODE = "" apInvLn.TAX = "" apInvLn.TAX_STATUS_CODE = "" apInvLn.TAX_JURISDICTION_CODE = "" apInvLn.TAX_RATE_CODE = "" apInvLn.TAX_RATE = "" apInvLn.AWT_GROUP_NAME = "" apInvLn.TYPE_1099 = "" apInvLn.INCOME_TAX_REGION = "" apInvLn.PRORATE_ACROSS_FLAG = "N" apInvLn.LINE_GROUP_NUMBER = "1" apInvLn.COST_FACTOR_NAME = "" apInvLn.STAT_AMOUNT = "" apInvLn.ASSET_TRACKING_FLAG = "N" apInvLn.ASSET_BOOK_TYPE_CODE = "" apInvLn.ASSET_CATEGORY_ID = "" apInvLn.SERIAL_NUMBER = "" apInvLn.MANUFACTURER = "" apInvLn.MODEL_NUMBER = "" apInvLn.WARRANTY_NUMBER = "" apInvLn.PRICE_CORRECTION_FLAG = "N" apInvLn.PRICE_CORRECT_INV_NUM = "" apInvLn.PRICE_CORRECT_INV_LINE_NUM = "" apInvLn.REQUESTER_FIRST_NAME = "" apInvLn.REQUESTER_LAST_NAME = "" apInvLn.REQUESTER_EMPLOYEE_NUM = "" apInvLn.ATTRIBUTECATEGORY = "" apInvLn.ATTRIBUTE1 = "POL" apInvLn.ATTRIBUTE2 = invoiceLine.ohiLineId apInvLn.ATTRIBUTE3 = "" apInvLn.ATTRIBUTE4 = "" apInvLn.ATTRIBUTE5 = "" apInvLn.ATTRIBUTE6 = "" apInvLn.ATTRIBUTE7 = "" apInvLn.ATTRIBUTE8 = "" apInvLn.ATTRIBUTE9 = "" apInvLn.ATTRIBUTE10 = "" apInvLn.ATTRIBUTE11 = "" apInvLn.ATTRIBUTE12 = "" apInvLn.ATTRIBUTE13 = "" apInvLn.ATTRIBUTE14 = "" apInvLn.ATTRIBUTE15 = "" apInvLn.ATTRIBUTE_NUMBER1 = "" apInvLn.ATTRIBUTE_NUMBER2 = "" apInvLn.ATTRIBUTE_NUMBER3 = "" apInvLn.ATTRIBUTE_NUMBER4 = "" apInvLn.ATTRIBUTE_NUMBER5 = "" apInvLn.ATTRIBUTE_DATE1 = "" apInvLn.ATTRIBUTE_DATE2 = "" apInvLn.ATTRIBUTE_DATE3 = "" apInvLn.ATTRIBUTE_DATE4 = "" apInvLn.ATTRIBUTE_DATE5 = "" apInvLn.GLOBAL_ATTRIBUTECATEGORY = "" apInvLn.GLOBAL_ATTRIBUTE1 = "" apInvLn.GLOBAL_ATTRIBUTE2 = "" apInvLn.GLOBAL_ATTRIBUTE3 = "" apInvLn.GLOBAL_ATTRIBUTE4 = "" apInvLn.GLOBAL_ATTRIBUTE5 = "" apInvLn.GLOBAL_ATTRIBUTE6 = "" apInvLn.GLOBAL_ATTRIBUTE7 = "" apInvLn.GLOBAL_ATTRIBUTE8 = "" apInvLn.GLOBAL_ATTRIBUTE9 = "" apInvLn.GLOBAL_ATTRIBUTE10 = "" apInvLn.GLOBAL_ATTRIBUTE11 = "" apInvLn.GLOBAL_ATTRIBUTE12 = "" apInvLn.GLOBAL_ATTRIBUTE13 = "" apInvLn.GLOBAL_ATTRIBUTE14 = "" apInvLn.GLOBAL_ATTRIBUTE15 = "" apInvLn.GLOBAL_ATTRIBUTE16 = "" apInvLn.GLOBAL_ATTRIBUTE17 = "" apInvLn.GLOBAL_ATTRIBUTE18 = "" apInvLn.GLOBAL_ATTRIBUTE19 = "" apInvLn.GLOBAL_ATTRIBUTE20 = "" apInvLn.GLOBAL_ATTRIBUTE_NUMBER1 = "" apInvLn.GLOBAL_ATTRIBUTE_NUMBER2 = "" apInvLn.GLOBAL_ATTRIBUTE_NUMBER3 = "" apInvLn.GLOBAL_ATTRIBUTE_NUMBER4 = "" apInvLn.GLOBAL_ATTRIBUTE_NUMBER5 = "" apInvLn.GLOBAL_ATTRIBUTE_DATE1 = "" apInvLn.GLOBAL_ATTRIBUTE_DATE2 = "" apInvLn.GLOBAL_ATTRIBUTE_DATE3 = "" apInvLn.GLOBAL_ATTRIBUTE_DATE4 = "" apInvLn.GLOBAL_ATTRIBUTE_DATE5 = "" apInvLn.PJC_PROJECT_ID = "" apInvLn.PJC_TASK_ID = "" apInvLn.PJC_EXPENDITURE_TYPE_ID = "" apInvLn.PJC_EXPENDITURE_ITEM_DATE = "" apInvLn.PJC_EXPENDITURE_ORGANIZATION_ID = "" apInvLn.PJC_PROJECT_NUMBER = "" apInvLn.PJC_TASK_NUMBER = "" apInvLn.PJC_EXPENDITURE_TYPE = "" apInvLn.PJC_EXPENDITURE_ORGANIZATION = "" apInvLn.PJC_FUNDING_SOURCE_ID = "" apInvLn.PJC_RESERVED_ATTRIBUTE2 = "" apInvLn.PJC_RESERVED_ATTRIBUTE3 = "" apInvLn.PJC_RESERVED_ATTRIBUTE4 = "" apInvLn.PJC_RESERVED_ATTRIBUTE5 = "" apInvLn.PJC_RESERVED_ATTRIBUTE6 = "" apInvLn.PJC_RESERVED_ATTRIBUTE7 = "" apInvLn.PJC_RESERVED_ATTRIBUTE8 = "" apInvLn.PJC_RESERVED_ATTRIBUTE9 = "" apInvLn.PJC_RESERVED_ATTRIBUTE10 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE1 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE2 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE3 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE4 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE5 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE6 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE7 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE8 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE9 = "" apInvLn.PJC_USER_DEFINED_ATTRIBUTE10 = "" fileRows.add(new FileRow("AP_INVOICE_LINES_INTERFACE", apInvLn.values().join(",")))
Currency Conversion (Billing)
When new financial transactions get created, during the premium calculations the system converts all calculation results (amounts) using the returned exchange rate object. This is done by the function of this signature of which 0 or 1 occurrence may be present (guaranteed by a business rule):
-
If no function is specified, then usually no conversion is needed (this typically occurs in a single currency environment).
-
If a function is specified, then the function is automatically applied after execution of the function dynamic logic.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policy |
Policy |
The policy being processed |
In |
calculationResultLine |
calculationResultLine |
The result of the calculated bill. |
Out |
n/a |
ExchangeRate |
The exchange rate object that is the outcome of the conversion. The object consists of the currency from, the currency to, the reference date, the context and the rate. |
Only one function dynamic logic with this signature can be created (OHI-DYLO-028).
Example:
return getExchangeRate("USD", "EUR", java.sql.Date.valueOf("2021-12-12"), "LIBERTY")
The dynamic logic calling the predefined method getExchangeRate can of course be implemented at the customer’s discretion, taking into account that:
an unspecified currency from or currency to results in no conversion at all
-
if currency from and currency to are same, this also results in no conversion at all
-
an unspecified reference date leads to the usage of the start date of the calculation result line as the reference date to find the exchange rate
-
in case no exchange rate is found with the passed in arguments, GEN-CURR-002 (fatal) is thrown back:
-
No exchange rate found for {currency from code}, {currency to code}, {reference date} and {context}
-
Currency Conversion (Commission)
When new financial transactions get created, during the commission calculations the system converts all calculation results (amounts) using the returned exchange rate object. This is done by the function of this signature of which 0 or 1 occurrence may be present (guaranteed by a business rule):
-
If no function is specified, then usually no conversion is needed (this typically occurs in a single currency environment).
-
If a function is specified, then the function is automatically applied after execution of the function dynamic logic.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policy |
Policy |
The policy being processed |
In |
commissionResultLine |
commissionResultLine |
The result of the calculated commission. |
Out |
n/a |
ExchangeRate |
The exchange rate object that is the outcome of the conversion. The object consists of the currency from, the currency to, the reference date, the context and the rate. |
Only one function dynamic logic with this signature can be created (OHI-DYLO-028).
Example:
return getExchangeRate("USD", "EUR", java.sql.Date.valueOf("2021-12-12"), "LIBERTY")
The dynamic logic calling the predefined method getExchangeRate can of course be implemented at the customer’s discretion, taking into account that:
an unspecified currency from or currency to results in no conversion at all
-
if currency from and currency to are same, this also results in no conversion at all
-
an unspecified reference date leads to the usage of the start date of the commission result line as the reference date to find the exchange rate
-
in case no exchange rate is found with the passed in arguments, GEN-CURR-002 (fatal) is thrown back:
-
No exchange rate found for {currency from code}, {currency to code}, {reference date} and {context}
-
Enrollment Response Definition
This function specifies the XML response that is sent via enrollment response integration point.
In or Out | Name | Type | Description |
---|---|---|---|
In |
insurableEntityType |
String |
The usage name of the insurable entity type of the insurable entity for which the policy enrollment details are requested |
In |
insurableEntityCode |
String |
The code of the insurable entity for which the policy enrollment details are requested |
In |
identifierTypeCode |
String |
The code of the relation identifier type (optional) |
In |
insuranceTypeCode |
String |
The code of the insurance type for which the policy enrollment details are requested |
In |
startDate |
Date |
The start date of the period for which enrollment details are required |
In |
endDate |
Date |
The end date of the period for which enrollment details are required |
In |
enrollmentResponseDefinition |
EnrollmentResponseDefinition |
The configuration record that applies the function. |
Out |
n/a |
Alphanumeric |
The XML message - policy enrollment response - which is sent to the external component. |
Extension
This is a common signature, available in all the applications. This signature has no bindings. It allows for writing extensions to the dynamic logic scripts that are delivered by the product.
A dynamic logic function of signature Extension should be accompanied with a reference to the base dynamic logic and vice-versa (OHI-DYLO-031). The referenced base dynamic logic function cannot be of signature Reusable Code or Extension (OHI-DYLO-030).
Fee
On fee schedule lines a dynamic logic function can be specified to calculate the fee amount. This signature uses the effective date on the policy mutation as the default as-of date.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policy |
Policy |
The policy for which a fee is being generated |
In |
policyEnrollment |
PolicyEnrollment |
The policy enrollment for which a fee is being generated (only for fees of level Enrollment) |
In |
feeScheduleLine |
FeeScheduleLine |
The fee schedule line that is selected |
Out |
n/a |
Money |
The fee amount and currency as outcome of the calculation |
Fee Financial Transaction
This function species how the calculation results have to be mapped to the financial transaction header. This signature uses the effective date on the policy mutation as the default as-of date.
In or Out | Name | Type | Description |
---|---|---|---|
In |
policy |
policy |
The policy for which a fee is being generated |
In |
policyEnrollment |
policyEnrollment |
The policy enrollment for which a fee is being generated (only for fees of level Enrollment) |
In |
feeDefinition |
FeeDefinition |
The fee definition being evaluated |
In |
financialTransaction |
FinancialTransaction |
The Financial Transaction that is the result of executing the fixed default transaction creation logic |
Out |
financialTransaction |
FinancialTransaction |
The Financial Transaction updated by the dynamic logic functionality |
The dynamic logic can:
-
Add more Financial Transaction Details
-
set attributes of new/existing Financial Transaction Detail and corresponding Financial Transaction Process Data elements
-
set Financial Transaction Process Detail and Financial Transaction Detail Process Detail attributes
-
adjust the total amount and the currency code of the financial transaction in case additional financial transaction details are added (only total amount and currency code are allowed to be updated for the financial transaction)
The financialTransactionDetail.sequenceNumber of the input financial transaction is set 1. This sequence is later re-set by the system if new financial transaction details are added. |
Financial Transaction
This function species how the calculation results have to be mapped to the financial transaction header
In or Out | Name | Type | Description |
---|---|---|---|
In |
calculationResult |
CalculationResult |
The calculation result for which the financial transaction is being created |
In |
financialTransaction |
FinancialTransaction |
The Financial Transaction that is the result of executing the fixed default transaction creation logic |
Out |
financialTransaction |
FinancialTransaction |
The Financial Transaction updated by the dynamic logic functionality |
The dynamic logic can:
-
Set attributes of Financial Transaction Process Data elements
-
Set attributes of Financial Transaction Detail Process Data elements
-
Add Financial Transaction Details and their corresponding Financial Transaction Detail Process Data element
The financialTransactionDetail.sequenceNumber of the input financial transaction is set to the corresponding calculation result line/commission result line sequence. This sequence is later re-set by the system if new financial transaction details are added. |
Group Client Validation Rule
A group client validation rule is evaluated during the processing of a group client. There are two levels (signatures) for group client validations.
-
Group Client
-
Group Account
Using these functions, native field and dynamic field values (including dynamic records) of a group client and all related details, may be set or updated. A number of restrictions apply to these functions:
The following fields cannot be set:
-
groupClient.code
-
groupClient.status
-
groupClient.processFlow
The following lists cannot be updated (new records cannot be added to the list and existing records cannot be deleted from the list), but the fields on the existing records can be set:
-
groupClientList
-
groupAccountList
-
groupClientMessageList
-
note that the addMessage method can be used to add messages to the Group Client
-
-
groupClientEventList
To add events to the Group Client, the addGroupClientEvent method can be used. |
Group Client
The following signature applies to policy validation rules with level "Group Client":
In or Out | Name | Type | Description |
---|---|---|---|
In |
groupClientValidationRule |
GroupClientValidationRule |
The group client validation rule being evaluated (can be used to parametrize the dynamic logic) |
In |
groupClient |
GroupClient |
The group client that is being evaluated |
This rule is triggered for each group client. This signature does not specify a default as-of date.
Group Account
The following signature applies to policy validation rules with level "Group Account":
In or Out | Name | Type | Description |
---|---|---|---|
In |
groupClientValidationRule |
GroupClientValidationRule |
The group client validation rule being evaluated (can be used to parametrize the dynamic logic) |
In |
groupAccount |
GroupAccount |
The group account that is being evaluated |
This rule is triggered for each group account in the group client. This signature does not specify a default as-of date.
HTTP Link
A HTTP link references a dynamic logic function to build up the URL needed to access - in a different browser tab - the report. The context from which the link is clicked serves as input object for the dynamic logic.
In or Out | Name | Type | Description |
---|---|---|---|
In |
Depends on the page |
Depends on the page |
The object that the page provides as input |
In |
httpLink |
HTTP Link |
The HTTP link that is being evaluated |
Out |
n/a |
Alphanumerical |
The composed URL |
Example:
// Navigate to external overview page return "http://"+getSystemProperty("reports.server.name")+".personoverview?p_person_code="+relation.code
where the server location for the report is stored in a property so that different environments can navigate to different servers for that.
Macro
The following signature applies for macro type Function:
In or Out | Name | Type | Description |
---|---|---|---|
In |
parameters |
map [key, value] |
The list of parameters from the macro request |
In |
context |
Object |
The context information from the macro request |
In |
contextObject |
Object |
This is either group client, group account or group account product depending on on the context setting of the macro definition. |
The following actions are supported within these functions: manipulating the context object, retrieving lookup objects and traversing the object graph from the context object. Any other actions (for example performing callouts or performing searches) are not supported.
The following is allowed to be updated based on the entity (including native fields, dynamic fields and records as applicable) :
-
Group Account Product
-
group account available product
-
group account product adjustment
-
group account product adjustment value
-
group account product premium schedule
-
group account product provider group
-
parameter domain
-
domain value
-
-
-
Group Account
-
broker agent switch rule
-
group account add on
-
group account adjustment
-
group account broker agent
-
group account collection setting
-
group account insurable class
-
group account premium schedule
-
group account product
-
group account available product
-
group account product adjustment
-
group account product adjustment value
-
group account product premium schedule
-
group account product provider group
-
parameter domain
-
domain value
-
-
-
group account time period
-
-
Group Client
-
Group Account
-
broker agent switch rule
-
group account add on
-
group account adjustment
-
group account broker agent
-
group account collection setting
-
group account insurable class
-
group account premium schedule
-
group account product
-
group account available product
-
group account product adjustment
-
group account product adjustment value
-
group account product premium schedule
-
group account product provider group
-
parameter domain
-
domain value
-
-
-
-
group client adjustment
-
group client billing account
-
group client broker agent
-
group client collection setting
-
group client premium schedule
-
group commission rate
-
premium bill allocation
-
MDS (Function)
Oracle Health Insurance has a component that can execute dynamic logic and return the result. This result can for example be used to show additional information on a page using an MDS customization. Consider the following example where a field "Age" on the policy enrollments shows the current age of the member.
float age=0 age=policyEnrollment.person.getAge() age
The input object is the object on which MDS is being applied. In the previous example the input object is policyEnrollment
Message Transformation
A Message Transformation Dynamic Logic Function transforms an aggregate object into one or more messages that can be consumed by an external system. The output can be any text format, for example, comma-delimited ASCII text, XML or JSON. This function does not allow manipulation of domain objects.
In or Out | Name | Type | Description |
---|---|---|---|
In |
activity |
Activity |
The activity that generates the message |
In |
aggregateObject |
Object |
Configured aggregate domain object |
In |
objectChangeLog |
ObjectChangeLog |
The object change log containing the changes that triggered the message generation. Specifies which entity or attributes were added, deleted or modified along with their old and new values. Helper methods to access the object change log are documented in ObjectChangeLog Methods. |
Out |
messages |
List<String> |
One or more transformed messages. The message contents are opaque to the Oracle Health Insurance application |
See Using the Oracle Health Insurance Integration Connector for examples of message transformation dynamic logic.
Name Format
Name formats are defined by a dynamic logic function. The dynamic logic function constructs a formatted name for a person or agent, using the available person or agent fields such as the first name, prefix and initials. The following signature for persons applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
person |
Person |
The person of which the name is to be displayed |
Out |
n/a |
Alphanumerical |
The string that contains the formatted name of the person |
The following signature for agents applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
agent |
Agent |
The agent of which the name is to be displayed |
Out |
n/a |
Alphanumerical |
The string that contains the formatted name of the agent |
The following signature for individual providers applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
individualProvider |
IndividualProvider |
The individual provider of which the name is to be displayed |
Out |
n/a |
Alphanumerical |
The string that contains the formatted name of the individual provider |
This function is called whenever a formatted name is displayed. Consider the following example for persons, where the formatted name consists of the person’s initials, prefix, (last) name and suffix respectively:
nf = "" if (person.initials) nf += person.initials + " " if (person.prefix) nf += person.prefix.displayCode + " " if (person.name) nf += person.name if (person.suffix) nf += " " + person.suffix return nf
Consider the following example for individual providers, where the formatted name consists of the provider’s titles, first name, middle name, (last) name and suffix respectively:
nf = "" if (individualProvider.getTitles("B")) nf += individualProvider.getTitles("B") + " " if (individualProvider.firstName) nf += individualProvider.firstName + " " if (individualProvider.middleName) nf += individualProvider.middleName + " " if (individualProvider.name) nf += individualProvider.name + " " if (individualProvider.suffix) nf += individualProvider.suffix return nf
Organization Code Generation
An organization code can be produced by a dynamic function. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
organization |
Organization |
The organization for which the code is to be generated |
Out |
n/a |
Alphanumerical |
The organization code |
Example:
// Uses the id of the organization and prefixes it with ORG return "ORG" + organization.id.toString()
Output Definition
An output definition is evaluated during the generation of output for a policy or a person or object on a policy. There are six signatures for output definition functions. The signatures do not specify a default as-of date.
The following signature applies to output definitions with level "Policy" for the header:
In or Out | Name | Type | Description |
---|---|---|---|
In |
outputDefinition |
OutputDefinition |
The output definition being evaluated (can be used to parametrize the dynamic logic) |
Out |
n/a |
Alphanumerical |
The header output |
The following signature applies to output definitions with level "Policy" for the repeat element:
In or Out | Name | Type | Description |
---|---|---|---|
In |
outputDefinition |
OutputDefinition |
The output definition being evaluated (can be used to parametrize the dynamic logic) |
In |
policy |
Policy |
The policy that is being evaluated |
Out |
n/a |
Alphanumerical |
The repeat element output |
The following signature applies to output definitions with level "Policy" for the footer:
In or Out | Name | Type | Description |
---|---|---|---|
In |
outputDefinition |
OutputDefinition |
The output definition being evaluated (can be used to parametrize the dynamic logic) |
Out |
n/a |
Alphanumerical |
The footer output |
The following signature applies to output definitions with level "Enrollment" for the header:
In or Out | Name | Type | Description |
---|---|---|---|
In |
outputDefinition |
OutputDefinition |
The output definition being evaluated (can be used to parametrize the dynamic logic) |
Out |
n/a |
Alphanumerical |
The header output |
The following example shows dynamic logic that creates a person id card file header:
return "<personCards>"
The resulting header is then as depicted below:
<personCards>
The following signature applies to output definitions with level "Enrollment" for the repeat element:
In or Out | Name | Type | Description |
---|---|---|---|
In |
outputDefinition |
OutputDefinition |
The output definition being evaluated (can be used to parametrize the dynamic logic) |
In |
policyEnrollment |
PolicyEnrollment |
The policy enrollment that is being evaluated |
Out |
n/a |
Alphanumerical |
The repeat element output |
The following example shows dynamic logic that creates a person id card file repeat element:
def writer = new StringWriter() def xml = new groovy.xml.MarkupBuilder(writer) xml.personCard(code:policyEnrollment.person.code) { personName(policyEnrollment.person.name) personFirstName(policyEnrollment.person.firstName) personGender(policyEnrollment.person.gender) personDateOfBirth(policyEnrollment.person.dateOfBirth) personSocialSecurityNumber(policyEnrollment.person.socialSecurityNumber) brand(policyEnrollment.policy.brand.code) } writer.toString()
The resulting repeat element may then be as depicted below:
<personCard code="MEM000123"> <personName>Smith</personName> <personFirstName>John</personFirstName> <personGender>Male</personGender> <personDateOfBirth>09/09/1976</personDateOfBirth> <personSocialSecurityNumber>123654798</personSocialSecurityNumber> <brand>TOP</brand> </personCard>
The following signature applies to output definitions with level "Enrollment" for the footer:
In or Out | Name | Type | Description |
---|---|---|---|
In |
outputDefinition |
OutputDefinition |
The output definition being evaluated (can be used to parametrize the dynamic logic) |
Out |
n/a |
Alphanumerical |
The footer output |
The following example shows dynamic logic that creates a person id card file footer:
return "</personCards>"
The resulting footer is then as depicted below:
</personCards>
Pend Reason
The fields that are additionally sent out on the workflow message are produced by a dynamic function. This dynamic function produces a list of name value pairs. This list of name value pairs is shown in the workflow messages in the <fields> element.
This signature’s as-of date defaults to the policy start date. |
The following signature applies for the policy:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policy |
Policy |
The policy being processed |
In/Out |
requestHeaders |
Map |
The request headers to be set for REST based workflow events. |
Out |
n/a |
Map |
The field names and their values |
Person Code Generation
A person code can be produced by a dynamic function. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
person |
Person |
The person for which the code is to be generated |
Out |
n/a |
Alphanumerical |
The person code |
Only one function dynamic logic with this signature can be created (OHI-DYLO-028).
Example:
// Uses the id of the person and prefixes it with MEM return "MEM" + person.id.toString()
Person Covered Services
A dynamic logic function of the signature "Person Covered Services" can create, delete and update person covered services for a person/product combination. The system allows only one active dynamic logic function of this signature.
The system automatically executes the dynamic logic function in the very last step of submitting (processing) a policy.
Typically, it calls the Predefined Method setPersonCoveredService to generate (or to replace) the "basic" list of person covered services.
The groovy logic in the function allows the following:
-
Manipulate the "basic" list of Person Covered Service by creating, deleting or updating person covered services before and/or after calling the setPersonCoveredService method. The function supports addPersonCoveredService and removePersonCoveredService methods to add or remove person covered services on the person.
-
Update and delete of locked person covered services.
-
The function supports the Predefined Method redetermineWaitStartDate. This method redetermines the waiting period start dates of person covered services without (re-)generating them. It is typically used when the dynamic logic creates, deletes or updates person covered services after calling the setPersonCoveredService method.
For example, updating the score of a person covered service in the dynamic logic function may impact the evaluation if an earlier person covered service is seen as an upgrade or as a downgrade, and therefor what the wait period start date should be. -
Assign values to dynamic fields on Policy Enrollment Products.
The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policy |
Policy |
The policy for which the person covered services are to be generated |
In |
person |
Person |
The person for which the person covered services are to be generated |
Example:
// Create or replace the list of person covered services // do not replace anyhing before Jan 1, 2019 person.setPersonCoveredService((java.sql.Date.valueOf("2021-01-01"), 60, "TC") // Waive the waiting period if the product code start with "WX" // and multiply the score for all person covered services of type Limit // with the value in the person's dynamic field scoreCorrection. person.personCoveredServiceList.each { personCoveredService -> if (personCoveredService.product.code.startsWith("WX")) { personCoveredService.waived = true } if (personCoveredService.coveredServiceType == "L") { personCoveredService.score = personCoveredService.score * person.scoreCorrection } } // Redetermine the wait start dates, // do not redetermine anything before Jan 1, 2019, // do not redetermine wait start date of locked lines. person.redetermineWaitStartDate((java.sql.Date.valueOf("2021-01-01"), 60, "TC", false)
Policy Account Number Generation
A policy account number can be produced by a dynamic function. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyAccount |
policyAccount |
The policy account for which the account number is to be generated |
Out |
n/a |
Alphanumerical |
The policy account number |
Example:
// Uses the id of the policy account and prefixes it with PAC return "PAC" + policyAccount.id.toString()
Policy Account Transaction Code Generation
A policy account transaction code can be produced by a dynamic function. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyAccountTransaction |
PolicyAccountTransaction |
The policy account for which the policy account transaction code is to be generated |
Out |
n/a |
Alphanumerical |
The policy account transaction code |
Example:
// Uses the id of the policy account transaction and prefixes it with PAT return "PAT" + policyAccountTransaction.id.toString()
Policy Account Transaction GL Event Generation
A policy account general ledger event can be generated by a dynamic function. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyAccountTransaction |
Policy Account Transaction |
The policy account for which the accounting detail is to be generated |
Example:
The following example shows dynamic logic that creates a callout message with information on the accounting detail. In this example the policy account transaction type and the policy account definition have both been extended with a non-time-valid dynamic field with the usage name glSegment.
def writer = new StringWriter() def xml = new groovy.xml.MarkupBuilder(writer) xml.accountingDetail(accountDefinition:policyAccountTransaction.policyAccount.PolicyAccountDefinition.code) { accountNumber(policyAccountTransaction.policyAccount.accountNumber) transactionType(policyAccountTransaction.policyAccountTransactionType.code) reversed(policyAccountTransaction.ind_reversed) amountDebit((policyAccountTransaction.amount >= 0) ? policyAccountTransaction.amount : 0) amountCredit((policyAccountTransaction.amount < 0) ? policyAccountTransaction.amount : 0) currency(policyAccountTransaction.currency.code) glSegment1(policyAccountTransaction.policyAccountTransactionType.glSegment) glSegment2(policyAccountTransaction.policyAccountTransaction.policyAccountDefinition.glSegment) } writer.toString()
The resulting element may then be as depicted below:
<accountingDetail accountDefinition="HSA" accountNumber="ABC123456" transactionType="PREM" reversed="N" amountDebit="100.00" amountCredit= "0" currencyCode="USD" glSegment1="1001" glSegment2="4321" />
Parsing XML in dynamic logic can be done with the XmlSlurper library.
Policy Calculation Period Segments
A (generated) policy calculation period can be replaced by policy calculation periods with a shorter time validity. Typical reasons to split policy calculation periods into smaller policy calculation periods are:
-
A member reaches a certain age during the timespan of a calculation period that might lead to another premium (for example, the member turns 18)
-
New member is added to policy, new premium tier should be applied from the date the new member is enrolled
-
A certain surcharge must not be applied from the date the member completes two years of enrollment.
This dynamic logic function is also able to set the reference date, calculation date, days as well as dynamic fields on a policy calculation period.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyCalculationPeriods |
List<PolicyCalculationPeriod> |
The policy calculation periods that are being evaluated. Each entry has a reference to the source collection setting attributes. |
In |
policy |
Policy |
The policy for which the policy calculation periods are created |
In |
parameters |
Map [key, value] |
The parameters that are sent in through sample invoice api. NOTE: The parameter value from the sample invoice request is passed as "String" |
Out |
n.a. |
List<PolicyCalculationPeriod> |
The modified list of periods that ultimately gets persisted |
Example 1:
A member reaches a certain age during the timespan of a calculation period, which might lead to another premium (for example, the member turns 18).
import static java.time.temporal.ChronoUnit.YEARS import java.time.LocalDate import java.sql.Date /** * Adds 18 years to the given input date. **/ Date add18Years(Date date) { // Convert the input Date to a LocalDate, to utilize its convenient "plus" method LocalDate datePlus18Years = date.toLocalDate().plus(18, YEARS) // Convert the LocalDate back to a Date return Date.valueOf(datePlus18Years) } // Collect the dates on which to split Set<Date> splitDates = policy.policyEnrollmentList.collect { policyEnrollment -> add18Years(policyEnrollment.person.dateOfBirth) } // Split the input list of periods on the above dates return policyCalculationPeriods.collectMany { policyCalculationPeriod -> policyCalculationPeriod.split(splitDates) }
Example 2:
Split when policy enrollment product is added, or after one is end dated.
import java.sql.Date // Collect all dates on which the policy calculation periods should be split Set<Date> splitDates = [] policy.policyEnrollmentList.each { policyEnrollment -> policyEnrollment.policyEnrollmentProductList.each { policyEnrollmentProduct -> splitDates.add(policyEnrollmentProduct.startDate) if (policyEnrollmentProduct.endDate) { splitDates.add(policyEnrollmentProduct.endDate + 1) } } } // Split the input list of periods on the above dates return policyCalculationPeriods.collectMany { policyCalculationPeriod -> policyCalculationPeriod.split(splitDates) }
Policy Code Generation
A policy code can be produced by a dynamic function. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policy |
Policy |
The policy for which the code is to be generated |
Out |
n/a |
Alphanumerical |
The policy code |
Only one function dynamic logic with this signature can be created (OHI-DYLO-028).
Example:
// Uses the id of the policy and prefixes it with POL return "POL" + policy.id.toString()
Policy Validation Rule
A policy validation rule is evaluated during the processing of a policy. There are three levels (signatures) for policy validations.
-
Policy
-
Policy Enrollment
-
Policy Enrollment Product
Using these functions, native field and dynamic field values (including dynamic records) of a policy and all related details, may be set or updated. It is also possible to attach messages to the policy, to update certain lists and to add assigned providers and contract alignments to the persons on the policy (using the addAssignedProvider and addContractAlignment predefined methods). A number of restrictions apply to these functions:
The following fields cannot be set:
-
policy.code
-
policy.gid
-
policy.status
-
policy.version
-
policy.processFlow
-
attachedPolicyData.indManual
The following lists cannot be updated (new records cannot be added to the list and existing records cannot be deleted from the list; fields on the existing records can be set):
-
policyEnrollmentList
-
policyMessageList
-
note that the addMessage method can be used to add messages to the policy
-
-
policyStatusHistoryList
-
pendHistoryList
-
policyEnrollmentProductList
Policy
The following signature applies to policy validation rules with level "Policy":
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyValidationRule |
PolicyValidationRule |
The policy validation rule being evaluated (can be used to parametrize the dynamic logic) |
In |
policy |
Policy |
The policy that is being evaluated |
This rule is triggered for each policy. This signature does not specify a default as-of date.
Policy Enrollment
The following signature applies to policy validation rules with level "Policy Enrollment":
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyValidationRule |
PolicyValidationRule |
The policy validation rule being evaluated (can be used to parametrize the dynamic logic) |
In |
policyEnrollment |
PolicyEnrollment |
The policy enrollment that is being evaluated |
This rule is triggered for each enrolled insurable entity on the policy. This signature does not specify a default as-of date.
Policy Enrollment Product
The following signature applies to policy validation rules with level "Policy Enrollment Product":
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyValidationRule |
PolicyValidationRule |
The policy validation rule being evaluated (can be used to parametrize the dynamic logic) |
In |
policyEnrollmentProduct |
PolicyEnrollmentProduct |
The policy enrollment product that is being evaluated |
This rule is triggered for each policy enrollment product on the policy. This signature’s as-of date defaults to the policy enrollment product start date.
Premium
On premium schedule lines a dynamic logic function can be specified to calculate the premium amount.
The following signature applies to the dynamic logic:
In or Out | Name | Type | Description |
---|---|---|---|
In |
policyEnrollmentProduct |
PolicyEnrollmentProduct |
The policy enrollment product that is being evaluated |
In |
policyaddon |
PolicyAddOn |
The policy add-on that is being evaluated, applicable only in case of add-on premium |
In |
premiumScheduleLine |
PremiumScheduleLine |
The premium schedule line that is selected |
In |
referenceDate[1] |
Date |
The reference date of the calculation period segment that is being calculated |
In |
lastCalculationPeriodSegment |
Boolean |
Is the calculation period segment that is being calculated the last calculation period segment in the contract period? (this is only applicable for Contract Period Based calculations; refer to the "Contract Period Based" section in the Premium Calculation chapter of the Operations Guide for more information on this calculation methodology) |
In |
calculationPeriod |
CalculationPeriod or Policy CalculationPeriod |
The system calculation period or policy calculation period for which the premium is being evaluated |
Out |
n/a |
Money |
The premium amount and currency as outcome of the calculation |
Example:
return Money.create(policyEnrollmentProduct.faceValue * 0.001)
In this example face value is a dynamic field on policy enrollment products and that the currency of the amount is set to the default currency.
The calculationPeriod.referenceDateForCalculation field returns the reference date of the calendar period if set, start date otherwise.
Provider Code Generation
A provider code can be produced by a dynamic function. This function can use the generated sequence number for generating a provider code. If the dynamic logic is not present, then the code defaults to the primary key of the entity. The following signature applies:
In or Out | Name | Type | Description |
---|---|---|---|
In |
provider |
Provider |
The provider being created |
Out |
n/a |
Alphanumerical |
The provider code |
// Uses the id of the provider and prefixes it with "PROV-" return "PROV-" + provider.id.toString()
Reusable Code
This is a common signature, available in all the applications. This signature has no bindings. It allows for writing standalone methods/reusable classes code that can be shared across other scripts.
A field validation rule on the Provider Flex Code Definition may enforce a specific format and or value of the provider code. If such a validation rule exists the provider code generation dynamic logic must meet that validation. |
Test Unit
A dynamic logic with the Test Unit signature tests another dynamic logic. Such a dynamic logic that runs a test on another dynamic logic is called a test case. A test case sends objects as input to the unit under test (UUT) and validates the output.
In or Out | Name | Type | Description |
---|---|---|---|
Out |
Not Available |
Boolean |
Returns |
You can run a test case using the Test Dynamic Logic Integration Point. |
URL Composition
A flex code field usage of a dynamic record definition can reference a dynamic logic function to build up the URL needed to access an external application. In this way it is possible to change for example, a server location in a central way.
In or Out | Name | Type | Description |
---|---|---|---|
In |
dynamicRecord |
DynamicRecord |
The dynamic record |
Out |
n/a |
Alphanumerical |
The composed URL |
Example:
return "http://financialsystem.oracle.com?p_check_number="+dynamicRecord.checkNumber