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:

Table 1. Adjustment
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:

Table 2. Bulk Update Definition
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.

The parameters input object only takes the named-pairs parameter (optional) values of an activity and not any other parameters. See configuration:bulk-update:bulk-update.adoc#_activity_parameters for more information. The following example is a sample parameter lists passed as arguments during a bulk update:

"fromProduct;ENPR_001;toProduct;ENPR_002;TransferDate;2022-06-30"
"firstPolicy;POLI_001;secondPolicy;POLI_002;brand;BRAN_001"

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:

Table 3. Callout Rule
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 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):

Table 4. Effective Date
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

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:

Table 5. 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:

Table 6. Counter Party
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:

Table 7. Country Format
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

Table 8. Create Accounting Detail XML
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

Table 9. Create Accounting Detail Flat File
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

Table 10. Create Invoice XML
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

Table 11. Create Invoice Flat File
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

Table 12. Create Invoice XML
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

Table 13. Create Invoice Line Flat File
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:

Table 14. Currency Conversion (Billing)
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:

Table 15. Currency Conversion (Commission)
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.

Table 16. Enrollment Response Definition
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:

Table 17. Fee
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.

Table 18. Fee Financial Transaction
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

Table 19. Financial Transaction
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":

Table 20. 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":

Table 21. 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.

Macro

The following signature applies for macro type Function:

Table 22. Macro
In or Out Name Type Description

In

parameters

map [key, value]

The list of parameters from the macro request

In

requestContext

Object

The context information from the macro request

In/out

context

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, 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

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.

Table 23. Message Transformation
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 Change Logs and Enrollment Change Events

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.

Notification Payload

On notification definition a dynamic logic function is specified to generate a notification with a payload of changes made on the policy for certain business events that gets evaluated successfully on a policy enrollment events.

The following signature applies to the dynamic logic:

Table 24. Notification Payload
In or Out Name Type Description

In

oldPolicy

Policy (old)

The old version of the policy that is being evaluated

In

newPolicy

Policy (new)

The new version of the policy that is being evaluated

In

policyEnrollmentEvent

PolicyEnrollmentEvent

The policy enrollment event that is being evaluated

In

policyEnrollmentEventChangeSet

PolicyEnrollmentEventChangeSet

Change details that triggered the business event

In/Out

requestHeaders

Map

The outbound request headers to be set

Out

n/a

String

The notification message payload to be sent

Organization Code Generation

An organization code can be produced by a dynamic function. The following signature applies:

Table 25. Organization Code Generation
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:

Table 26. Output Definition
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:

Table 27. Output Definition at Policy Level
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:

Table 28. Output Definition with Policy Level at 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:

Table 29. Output Definition with Enrollment 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:

Table 30. Output Definition with Enrollment Level at 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:

Table 31. Output Definition with Enrollment Level at 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:

Table 32. Pend Reason
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
Table 33. Start Workflow Request
In or Out Name Type Description

In

businessObject

Policy

Type of the business object that triggers the workflow.

Out

n/a

Map<String, Object> with 2 entries

The key "payload" is mandatory and contains the generated string payload.

The key "requestHeaders" is optional. If present, it is a nested Map<String, String> with request headers to be included in the message to the workflow system.
Table 34. Start Workflow Response
In or Out Name Type Description

In

startWorkflowResponse

String

The response of the workflow system after receiving a Start Workflow Request.

Out

n/a

String

The URL of the resource defining the started workflow process (processId).
Table 35. End Workflow Request
In or Out Name Type Description

In

businessObject

Policy

Type of the business to end the workflow.

In

processId

String

The REST URL of the workflow process to be cancelled.

Out

n/a

Map<String, Object> with 3 entries

The key "payload" is mandatory and contains the generated string payload.

The key "URL" is mandatory and contains the URL to where the message has to be sent.

The key "requestHeaders" is optional. If present, it is a nested Map<String, String> with request headers to be included in the message to the workflow system.

Person Code Generation

A person code can be produced by a dynamic function. The following signature applies:

Table 36. Person Code Generation
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:

Table 37. Person Covered Services
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:

Table 38. Policy Account Number Generation
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:

Table 39. Policy Account Transaction Code Generation
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:

Table 40. Policy Account Transaction GL Event Generation
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:

Table 41. Policy Calculation Period Segments
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:

Table 42. Policy Code Generation
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 works when the application is processing a policy. There are three signatures for policy validation:

  • Policy

  • Policy Enrollment

  • Policy Enrollment Product

You can set and update fixed fields and dynamic field values (including dynamic records) of a policy using this function. You can even set a person’s code using this function. You can attach messages to a policy, update certain lists, and add assigned providers or contract alignments to a person on a policy (using the addAssignedProvider and addContractAlignment predefined methods). There is a list of entities that cannot use this function.

Following are the fields that the function does not set:

  • policy.code

  • policy.gid

  • policy.status

  • policy.version

  • policy.processFlow

  • attachedPolicyData.indManual

Following are the lists that the function does not update. This means that the function does not add or delete records but can set fields on an existing record:

  • policyEnrollmentList
    NOTE: you can use removePolicyEnrollment method to remove enrollments from a policy.

  • policyMessageList
    NOTE: you can use the addMessage method to add messages to a policy.

  • policyStatusHistoryList

  • policyPendReasonList

  • policyEnrollmentProductList
    NOTE: you can use addPolicyEnrollmentProduct to add an enrollment product to a policy enrollment.
    NOTE: you can use removePolicyEnrollmentProduct to remove an enrollment product from a policy enrollment.

Policy

The following signature applies to policy validation rules with level "Policy":

Table 43. 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":

Table 44. 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":

Table 45. 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:

Table 46. Premium
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:

Table 47. Provider Code Generation
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.

Table 48. Test Unit
In or Out Name Type Description

Out

Not Available

Boolean

Returns true if the test case ran successfully, false otherwise.
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.

Table 49. URL Composition
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
1. Reference Date - For policy calculation period this date is set to the date as referred by the value reference date setting on the schedule definition or premium schedule (as applicable) when such a setting is specified.