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.
Add-on Premium
On add-on premium schedule lines a dynamic logic function can be specified to calculate the add-on premium amount.
The following signature applies to the dynamic logic:
In / Out | Name | Type | Description |
---|---|---|---|
In |
policyEnrollmentProduct |
PolicyEnrollmentProduct |
The policy enrollment product that is being evaluated |
In |
addOnPremiumScheduleLine |
AddOnPremiumScheduleLine |
The add-on premium schedule line that is selected |
In |
amount |
Money |
The input amount on which the add-on amount is calculated |
In |
calculationPeriod |
CalculationPeriod or PolicyCalculationPeriod |
The system calculation period or policy calculation period for which the add-on premium is being evaluated |
In |
referenceDate[1] |
Date |
The reference date of the calculation period segment that is being calculated |
Out |
n/a |
Money |
The add-on premium amount and currency as outcome of the calculation |
Example:
return Money.create(policyEnrollmentProduct.faceValue * 0.001)
Note that 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.
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 / 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 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
|
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.
Example:
return amount * 0.01
To set the reconciliation rate
import static java.math.RoundingMode.HALF_UP reconciliationInput.rate = new BigDecimal("0.071")
To apply reconcile amounts in the last PCP when the non prorate function is used
if (lastCalculationPeriodSegment && reconciliationInput.rate!=null && reconciliationInput.applicableBaseAmount!=null) && (reconciliationInput.rate!=null && reconciliationInput.rate=newRate)){ total applicableAdjustment = reconciliationInput.rate*reconciliationInput.applicableBaseAmount return applicableAdjustment - reconciliationInput.totalChargedAmount }
- NOTE
-
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 / 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 |
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(Date.parse("yyyy-MM-dd", "2016-01-01").time) 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 / 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 fixed 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 fixed fields and dynamic fields can be modified
-
-
policy.policyEnrollment.policyEnrollmentProduct.policyAddOnList
-
including the field addOn of the policy add-on; other fixed 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.
Whenever you decide to not call the readEntity operation on the Response that is returned from the invoke() operation - you have to make sure the underlying response is closed. In the above example: if you assign the result of invoke() to a variable and work 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 day onward the modification should have 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 / 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 |
A straightforward example on policy enrollment product:
return newPolicyEnrollmentProduct.startDate
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 version 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 / 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 fixed 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 account definition
-
enrollment product adjustment
-
enrollment product time period
-
add-on premium schedule
-
add-on premium schedule line
-
schedule dimension value
-
-
-
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 add on override
-
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 add on override
-
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 add on override
-
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 / 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 / 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 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 / 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 / Out | Parameter | Type | Description |
---|---|---|---|
In |
financialTransactionDetail |
FinancialTransactionDetail |
The financial transaction detail from which the invoice line attributes are derived to contract the XML. |
In / 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(',')))
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 / Out | Parameter | Type | Description |
---|---|---|---|
In |
financialTransactionDetail |
FinancialTransactionDetail |
The financial transaction detail from which the invoice line attributes are derived to contract the XML. |
In / 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(',')))
Enrollment Response Definition
This function specifies the XML response that is sent via enrollment response integration point.
In / 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 |
lineOfBusiness |
String |
The code of the line of business 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. |
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 / 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 / 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)
- NOTE
-
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 / 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
- NOTE
-
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.
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 / 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.
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
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 / 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 / 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 / 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
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 / 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 / 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 / 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 / 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 / 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 / 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>
Organization Code Generation
An organization code can be produced by a dynamic function. The following signature applies:
In / 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()
Person Code Generation
A person code can be produced by a dynamic function. The following signature applies:
In / Out | Name | Type | Description |
---|---|---|---|
In |
person |
Person |
The person for which the code is to be generated |
Out |
n/a |
Alphanumerical |
The person code |
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 Pre-defined Methods setPersonCoveredService to generate (or to replace) the 'basic' list of person covered services.
The groovy logic in the function allows manipulating 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.
The function also allows update and delete of locked person covered services.
The function supports the Pre-defined Methods 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 log 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.
The following signature applies:
In / 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((new java.sql.Date(Date.parse("yyyy-MM-dd", "2019-01-01").time), 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((new java.sql.Date(Date.parse("yyyy-MM-dd", "2019-01-01").time), 60, 'TC', false)
Policy Account Number Generation
A policy account number can be produced by a dynamic function. The following signature applies:
In / 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 / 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 / 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 / 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 / Out | Name | Type | Description |
---|---|---|---|
In |
policy |
Policy |
The policy for which the code is to be generated |
Out |
n/a |
Alphanumerical |
The policy code |
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, fixed 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 / 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 / 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 / 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.
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 / 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()
- NOTE
-
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
Dynamic logic of this signature do not implement business functionality. They act instead as test drivers of other dynamic logic.
Dynamic logic can be tested by invoking the business process where the logic is called and see if it performs as expected. This is however a cumbersome process: many business process flows can only be executed under very specific circumstances and executing them may take long.
Here a test unit helps. The logic of the test unit can construct (or retrieve) input objects and pass them to the dynamic logic that is to be tested and validate the output. There is no need to start the business process. The Test Unit enables unit-testing of dynamic logic.
The following signature applies:
In / Out | Name | Type | Description |
---|---|---|---|
Out |
n/a |
String |
When null, the Test Unit ran successfully. Not null: the error situation encountered in the Test Unit. |
- NOTE
-
Test Units can be executed by invoking the development:integration-points:http-integration-points/test-dynamic-logic-integration-point.adoc
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, fixed 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; 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
Group Client
The following signature applies to policy validation rules with level "Group Client":
In / 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 / 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.
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 / Out | Name | Type | Description |
---|---|---|---|
In |
policyEnrollmentProduct |
PolicyEnrollmentProduct |
The policy enrollment product that is being evaluated |
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 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.
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.
- NOTE
-
This signature’s as-of date defaults to the policy start date.
The following signature applies for the policy:
In / 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 |
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 / 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. |
Example:
return getExchangeRate("USD", "EUR", new java.sql.Date(Date.parse("yyyy-mm-dd", "2015-12-12").getTime()), "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 / 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. |
Example:
return getExchangeRate("USD", "EUR", new java.sql.Date(Date.parse("yyyy-mm-dd", "2015-12-12").getTime()), "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}
-
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.
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.
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 / 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
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 / 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 integration-guide:integration-connector/using-the-ohi-integration-connector.adoc for examples of message transformation dynamic logic.