A Condition Record is a generic way to store price data that allows to export them easily to an external ERP system or to access them in real time using API calls.

Condition Records can be automatically exported from Price Lists, Live Price Grids, Agreements/Promotions, Quotes or Calculation Grids using the Groovy conditionRecordHelper methods. Condition Records are records without sku, which can hold 1–12 keys and 1–30 attributes.

The logic is executed after a document or object (Price List, Quote, Price Grid Item, etc.) is approved or denied or after recalculation of an approved Agreement/Promotion.

conditionRecordHelper.addOrUpdate([
key1: VKORG,
key2: VTWEG,
key3: currentItem.sku,
validTo: validTo,
validFrom: validFrom, //mandatory field
conditionRecordSetId: conditionRecordSetPR00_id,
conditionValue: price,
unitOfMeasure: "barrels",
currency: "EUR",
//integrationStatus: 1,
attribute1: "attr",
attribute2: "attr2",
attribute3: "attr3 VAL222",
attribute4: "attr4 VAL3333",
])

Condition Record logic can be defined as part of a generic workflow logic definition:

workflow.withDefaultConditionRecordLogic("DefaultCRLogic")

This also means you can turn off the default CR logic by defining null on the step:

workflow.addApprovalStep("DefaultApproval")
                .withApprovers("user1")
                .withConditionRecordLogic("")
                .setReason("Standard approval")

Supported object types:

Quote
Price Grid Item
Calculation Grid Item
Rebate Agreement
Agreement/Promotion (also the recalculation of an approved one)
Data Change Request
Price List
Rebate Record
Model Record
Claim
Model
Custom Form
Compensation Plan
Compensation Record
Rebate Record Group

How Overlapping Intervals Are Solved

The system handles validity period overlaps after the approval of Condition Records (e.g., prices) to ensure that there is always only one valid price at any given time.

If the validity period of a new Condition Record overlaps with that of an existing Condition Record, the system resolves the overlap so that only one Condition Record is valid for any period of time.

Newly added Condition Records have priority over existing ones. The existing records will be adjusted to accommodate the validity period of the new Condition Record.

When resolving an overlap, the following rules apply:

When the new condition partially overlaps with an existing condition, the existing condition is end-dated.
When there is a complete overlap, the existing condition is deleted.
When the new condition is completely overlapped by an existing one, the existing condition is end-dated and a new condition is created at the end of the validity period of the new condition.

Examples

Scenario 1: The new Condition Record completely overlaps an already existing Condition Record (it can overlap several records) – the already existing record(s) will be deleted.

Scenario 2: The new Condition Record is completely within the validity period of an already existing record – the already existing record is end-dated (on the left side) right before the new record starts. A new condition record has to be created right after the new record ends with the same validity end as the original record.

Scenario 3: The new condition record partially overlaps an existing record where the existing one starts earlier – the existing record is end-dated right before the new one starts.

Scenario 4: The new condition record partially overlaps an existing record where the new one starts earlier – the existing record will now be valid from the moment when the validity of the new record ends.

The overall scenario combines all the scenarios above.

How To Enable Condition Records for Agreements & Promotions

You can configure Agreements & Promotions to generate either Price Records or Condition Records.

The parameters property in the JSON definition of Agreement & Promotion Type determines what type of records will be created and when:

"parameters": {
    "recordType": "conditionRecord",
    "recordCalculation": "approve"
  }

recordType – Sets whether Price Records or Condition Records will be generated. The following parameters are accepted:
- priceRecord (default)
- conditionRecord
recordCalculation – Sets whether Condition Records are generated on approval or when the Agreement/Promotion is calculated based on the setting on the Calculation page. The following parameters are accepted:
- approve (default)
- scheduler

In both approve and scheduler options, additional configuration is needed.

approve: workflow.withConditionRecordLogic("ApprovalCRLogic") or workflow.withDefaultConditionRecordLogic("ApprovalCRLogic") in the workflow logic. For more details, see withConditionRecordLogic() and withDefaultConditionRecordLogic() Groovy API documentation.
scheduler: The line item logic contains conditionRecordHelper.addOrUpdate() executed in the calculation "contractRecalculation" context.

How to set up the Condition Record logic in case of not having a workflow generated

The Advanced Property “conditionRecordLogicsWhenNoWorkflowDefined“ is a map where different logic names (for the different entities) can be setup, and those logics will be used if nothing else can be set up on the workflow level. An example of such value could be:

{"pricelist": "DefaultCRLogic",
"quote": "DefaultCRLogic",
"pricegriditem": "DefaultCRLogic",
"calculationgriditem": "DefaultCRLogic",
"rebateagreement": "DefaultCRLogic",
"contract": "DefaultCRLogic",
"dcr": "DefaultCRLogic",
"rebaterecord": "DefaultCRLogic",
"modelrecord": "DefaultCRLogic",
"claim": "DefaultCRLogic",
"model": "DefaultCRLogic",
"customform": "DefaultCRLogic",
"compensation": "DefaultCRLogic",
"compensationrecord": "DefaultCRLogic",
"rebaterecordgroup": "DefaultCRLogic"}

Configuration Engineer Knowledge Base

Condition Records (Reference)

How Overlapping Intervals Are Solved

Examples

How To Enable Condition Records for Agreements & Promotions

How to set up the Condition Record logic in case of not having a workflow generated