Payout Records are lightweight Rebate Records which are useful in situations when you need to generate thousands of Rebate Records that represent all possible combinations of several attributes (customer, product, period, etc.). To avoid overloading the system, you can use lightweight Payout Records with a lot simpler data structure.

A Payout Record has the following features:

• It is an attributed object that stores the calculated rebate amount(s) (accruals) + customer (e.g., store) and product level attributes, i.e., primitive values – it is not intended for large data structures.
  A total of 100 generic attributes are available for this purpose.

• It has built-in fields to reference the original Rebate Record and identify the Payout Record by name, within the scope of the (top level) Rebate Record. This is the list of available built-in fields:

  Open

  

• Global attribute metadata, i.e., a single set of attribute meta config (not per agreement or any other level).

• There are no predefined Payout Record types or statuses. The rebate logic decides which Type and Status to initialize or update a Payout Record with. In the UI, there is an option of limited control on visibility of the records by Type and Business Roles, as well a status transitions when using the Mass-Edit functionality.

• There is no workflow available.

• Payout Records are created by a RebateRecord logic, i.e., in the context of the Rebate Record Calculation task (given that this is a background job, large amounts of records can be created). The logic bears the full responsibility for the Payout Record creation, update and deletion (by name).
  It has also full control over the content (field values) of the records.

Configure Payout Records

Payout Records definition is part of the Rebate calculation logic. Decide which attributes you want to have in your Payout Records and, in the logic, map payout record attributes to the corresponding original rebate record attributes.

1. In the Advanced Configuration Options, create an entry with the name payoutRecordsConfiguration. Make the following settings:
   Name = payoutRecordsConfiguration
   Value =  { "validToFromStateTransitions": { "Approved": [ "Pending" ], "Denied": [ "Pending" ], "Paid": [ "Approved" ] }, "businessRolesConfig": { "SALES": { "types": [ "Accrual" ], "canEdit": true }, "ADMIN": { "types": [ "Summary" ], "canDelete": true } }, "editableFields": [ "payoutDate", "endDate", "status", "attribute1", "attribute3" ] }

   • Visibility and editability by record type and business roles:

     1. Set up business roles if you want to limit visibility/editability to only some groups of users.

     2. Add a type2BusinessRoles entry in the configuration value, mapping record type(s) to the business role(s) that a user is required to have (a user only needs to have one of the roles listed).

   • Define the set of statuses and allowed transitions:

     1. Define the set of statuses in the validToFromStateTransitions entry.

     2. Define valid status transitions by mapping each status to the set of statuses it can be transitioned from. In the example above a record can move from Pending to Approved and Denied and from Approved to Paid.
        You can use this property in mass edit operation where it filters out records which are not in a state that is allowed to transition to the "to-state" (if defined) passed in by the user.

        Example

        { "validToFromStateTransitions": { "Approved": [ "Pending" ], "Denied": [ "Pending" ], "Paid": [ "Approved" ] }, "businessRolesConfig": { "RebateAdmin" : { "types" : ["Accrual"], "canEdit" : true }, "FinancialAdmin" : { "types" : ["Summary"], "canDelete" : true } }, "editableFields" : ["payoutDate", "endDate", "status", "attribute1", "attribute10"] }

   • It is important to note that these limitations do not apply to the Rebate Record. Visibility of records is applied to the Payout Record data grid in the UI, while status transition control is applied to Mass-Edit of the record.

2. Add Payout Record generation code to your Rebate calculation logic.

   def rr = ... // get a rebate record from which to initialize some payout record attributes from def customer = rr.attribute1 def accrual = rr.attribute3 // breakdown the accruals by store (while for ex. the rebate record level's accrual is on customer level) for (def store : stores) { def storeAccrual = ..... // some breakdown calculation payoutRecords.add("Accrual", store, [attribute1: customer, attribute2: storeAccrual , attribute3: rr.attribute5] ) } payoutRecords.add("Summary", "Total", [attribute1: customer, attribute2: accrual] )

   See also the API documentation for the complete list of available methods.
    Note that the 'payoutRecords' binding is only available from a Rebate Record calculation context, i.e., the logic that calculates rebate records in a Rebate Record Calculation task (one default task is created automatically for every Rebates module implementation).

3. Go to Rebates > Rebate Calculations and edit the default calculation task or create a new one. The logic with the Payout Record generation code must be selected in the Logic drop-down list on the Calculation tab. 

4. Run the Rebate Calculation task.

5. Once the calculation is finished, the Payout Records are available on the Rebates > Payout Records page. It is a single page with a filterable data grid.