Claim Validation Logic

Claim validation logic is a calculation logic in the Channel Management module which validates the claim data provided by the distributor against the data (Quote, Promotion Contract, …) available to the manufacturer. The aim is to verify if the data are in a good shape and if the claimed money matches the expectations.

To understand where the validation logic fits in the process, review Create Claim from XLS File (Use Case) and Create Claim from Quote/Contract (Use Case).

Use Cases

This claim validation logic is used in several cases:

• User selects a source of claim data, so each new item is calculated:

  • either uploads an XLS file

  • or selects a Quote or Contract as a source for the Claim.

• User clicks the Recalculate button to perform recalculation of all items.

• User manually overrides editable fields which triggers one line recalculation.

• User submits the Claim. It triggers recalculation of all line items but only the alerts will be written to the line items, so that the manual validations/rejections are persisted. All other results are not written back.

Logic API

• Nature: claim

  • Logic type: default (generic)

• Input fields: not available for this logic

• Context info:

  • Logic is executed for a Claim line item.

  • api.currentItem() – Provides data of the Claim object (the header information).

  • api.getClaimContext() – Provides API for reading the data of the row (coming either from the XLS or from the Claim “source” logic).

  • api.global – Preserved between calls of the logic for each line (during full recalculation).

• Elements

  • Results of elements with Display Mode Everywhere can be mapped to the Claim line item, using the mapping defined for the Claim Type (where the element names are mapped to the Claim line item field names).

  • Format defined for an element (whose result will be mapped) will override the format defined in the mapping.

  • One special element is dedicated to return the validation state:

    • The name of this element must be configured in the Claim Type.

    • A suggested name is "validationState".

    • Return value is a String, with value either NOT_VALIDATED, AUTO_VALIDATED or AUTO_REJECTED. See Claim Line Item (CLLI) Fields for details on these values.

• Warnings, Alerts – All warnings and alerts generated across all elements are collected and stored in field alerts of a Claim line item. This collection is then presented on the screen in one single cell Status shown as a red or yellow bullet icon.

  • Impact of critical alert – If there is at least one critical alert for the Claim line item, the end user will not be allowed to manually validate it.

• Exceptions – When the logic raises an exception, the error is stored on the Claim (header) and is visible on the page with a list of headers.

  • Impact of logic which failed with an error – The end user will not be able to manually validate the item.

Common Logic Structure and API Functions

The Claim validation logic typically performs:

• Element debug:

  • It creates a sample row used during logic testing (see detail below).

  • A suggested name is "debug".

• Element validation:

  • Reads the Claim header fields via api.currentItem("customerId").

  • Reads the row Claim data via api.getClaimContext().getRow().get("Claim_Quantity").

  • Reads data necessary for the Claim validation. If needed, the data can be cached in api.global, since it is persisted during recalculation of all the rows.

  • Validation of the row:

    • Correctness of the data

      • Proper format of the data

      • If the referred product, customer or quote actually exists

    • If the claim is legitimate

      • Lookup of relevant data for comparison – Quotes, Contracts, Rebates, …​

      • Ensure the Claim is valid with respect to the negotiated conditions

  • Calculate additional data needed for the Claim. You can store them, for example, in api.local and then read later in the "output" elements.

  • Eeport errors found:

    • Using functions:

      • api.yellowAlert(), api.redAlert(), api.criticalAlert()

      • api.addWarning()

    • All these errors will be collected on the Claim line item in field alerts and then presented to the user in one single field on the screen.

• Element validationState:

  • Returns the result of a row validation. You can either automatically validate/reject the row, or return a state that the user has to manually validate/reject. See the validationState values at Claim Line Item (CLLI) | Fields.

  • This element name must be configured in the Claim Type.

  • A suggested name is "validationState".

• Elements for "output":

  • Elements which return results to be mapped to the Claim line item.

  • Those elements must have Display Mode set to Everywhere and they can also define the format of the result.

Testing

During standard execution the Claim validation logic reads the following:

• Claim header

• Row with Claim data (coming from XLS or created by Claim source logic)

So you need to provide during logic test:

• Claim header fields – In the logic Inputs you can switch the context to Claim and then select the Claim document to be used for that purpose.

• Row with Claim data – You can create the sample row directly in the logic code, by placing the sample data directly into the Claim Context, instead of the real row coming from the XLS file. Create an element "debug" and create the row with Claim data.