Sample Process and Apply Registrations to Periods
This operation provides means to process and apply registrations to a policy with sample payment registrations. It makes possible to predict the outcome of sample payments and determine coverage period that "would be" paid for a policy.
This feature is available when the system property indicates that the registrations should be applied to the periods.
The process consists of the following sub steps:
-
-
determines the Date paid to for payments that received on time and are exact.
-
creates mutation for a late and non-accurate payment
-
-
Apply Registrations to Periods
-
determines the date paid to for payments that are not on time and are not exact.
-
Resource Representation
The resource representation of a policy that can be processed looks like
{
" ...policy properties ...",
"links": [
{
"href": "http://<host>:<port>/<contextRoot>/generic/policies/<id>",
"rel": "self"
},
{
"href": "http://<host>:<port>/<contextRoot>/policies/<id>/sampleprocessandapplyregistrations",
"rel": "policy:sampleprocessandapplyregistrations",
"httpMethod": "POST"
}
]
}
The sampleprocessandapplyregistrations link is present for a policy in the latest version, for status 'Approved', 'Edit' or Pended':
{
... policy properties ...
"links": [
{
"href": "http://<host>:<port>/<contextRoot>/generic/policies/<id>",
"rel": "self"
}
]
}Policy events for recalculation of level 'Policy' (referring to the policy at hand) or level 'Insurable Entity' (referring to one of the policy enrollments of the policy at hand) are picked up and translated into policy mutations (non-persisted) (described in detail in the "Change Events" chapter of the Configuration Guide). That way the effect of any existing policy events can be taken into account during processing of registrations.
Then the next step is to invoke process registrations and apply registrations for the policy. The system considers the effect of sample registrations when sent in in the request [1] in the process and apply registration steps to determine the new date paid to.
Header
| Name | Description |
|---|---|
calculationResults |
|
Payload
It takes in the following attributes:
| Name | Description |
|---|---|
registrationList |
Sample registrations to apply. |
{
"registrationList":[
{
"codeType": "",
"type": "P",
"bankIdentifierCode": "",
"paperRemittanceDate": "",
"receiver": " ",
"ediRemittanceCode": "",
"status": "",
"code": "",
"bankName": "",
"policyCode": "",
"sentDate": "",
"bankAccountNumber": "",
"correlationId": "",
"appliedPayDate": "",
"amount": "",
"ediRemittanceDate": "",
"paperRemittanceCode": "",
"payDate": "",
"other attributes on registrations": ""
}]
}
The system validates the following attributes:
-
codeType and Type should be 'PAYMENT'
-
status should be 'N'
-
payDate should be a valid date
-
amount should be a valid +/- number
Response Messages
All the periods for which premium is (re)calculated are returned in the response.
Note that the policy calculation periods and calculation results are not stored nor are financial transactions created.
The response payload containing the calculation results looks like this:
{
"datePaidTo": ""
"calculationResultSetTotalBasePremium": {
"value": "",
"currency": ""
},
"calculationResultSetTotalAdjustment": {
"value": "",
"currency": ""
},
"calculationResultSetTotalSurcharge": {
"value": "",
"currency": ""
},
"calculationResultSetTotalResult": {
"value": "",
"currency": ""
},
"calculationResultList": [
{
"calculationPeriod: {
"startDate": "",
"endDate": "",
"displayName": ""
},
"calculationDate":""
"referenceDate:""
"policyContractStartDate: "",
"policyContractEndDate: "",
"groupAccount": {
"code": "",
"displayName: ""
},
"totalBasePremium": {
"value": "",
"currency": ""
},
"totalAdjustment": {
"value": "",
"currency": ""
},
"totalSurcharge": {
"value": "",
"currency": ""
},
"totalResult": {
"value": "",
"currency": ""
},
"calculationResultLineList": [
{
"sequence": "",
"referencedCalculationResultLine": {
"sequence": ""
},
"policyEnrollmentProduct": {
"policyEnrollment": {
"": {
"link": {
"href": "http://://generic//",
"rel": "insurableEntityType.usageName"
}
}
},
"enrollmentProduct": {
"code": "",
"displayName": ""
}
},
"scheduleDefinition": {
"code": "",
"type": "",
"surchargeRuleEvaluation": ""
},
"premiumSchedule": {
"code": ""
},
"addOn": {
"code": "",
"displayName: ""
},
"resultAmount": {
"value": "",
"currency": ""
},
"retrievedAmount": {
"currency": "",
"value":
},
"percentage":""
}
]
}
]
}
It is also possible to fetch up to 5 calculation result dynamic fields in the response by using accept header parameter "fields". This parameter takes the dynamic field usagenames separated by '|' For example: To get dynamicfieldusage1 and dynamicfieldusage2 in the response , the accept header must be set as application/json;fields=dynamicfieldusage1|dynamicfieldusage2.
This operation will also provide HTTP status codes as defined in Response Messages. If an error occurs, the appropriate HTTP status code is returned and a notification is sent containing error details. This way, the operation can be executed again after the reason for failure has been fixed.
The following operation specific error can occur:
Code |
Severity |
Message Text |
POL-HTTP-001 |
Fatal |
Policy must be the last version and in status Approved, Edit or Pended |
POL-HTTP-020 |
Fatal |
Registration codeType-type must be specified and must be 'PAYMENT' |
POL-HTTP-021 |
Fatal |
Registration status must be specified and must be new (N) |
GEN-HTTP-017 |
Fatal |
Mandatory property Pay Date is missing |
Authorization
The above described operation is protected by access restriction "policies.sampleprocessandapplyregistrations IP". A grant for this access restriction must be provided. If the access to a policy is restricted by a data access group restriction, then to perform this operation on that policy also a grant for that data access group restriction must be provided with the Update flag set.