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

  • 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

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.

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