Payout Record (PYR)

Owned by Johannes Lindgren (Deactivated)
Last updated: Mar 05, 2024 by Pavel Matyasko (Deactivated)
3 min read

Payout Record is an entity that was introduced much later than Rebate Record, and is intended to solve the problem of calculating and storing the rebate accruals or payouts on an even more granular level.

There is distinction between:

  • Business term "payout" – Usually means the amount of money. BUT such "payout" money value can be calculated on either Rebate Record or on Payout Record, depending on what is better for the project implementation.

  • Technical term "PayoutRecord" – Name of the entity which you can use as a more fine-grained storage for calculated results.

  • "payoutDate" on the line item – Specifies when the rebate money should be paid to the customer.

For example, if you need to pre-calculate the rebate money not only for the whole group of customers, but also per each customer, you can use the Payout Record to store such detailed information.

Payout Records allow to store even more fine-grained rebate results than the RR. If, for example, the Rebate Record contains a group of customers and you need to store separately a rebate amount per specific customerId, you can store such numbers into the PayoutRecords.

Sample hierarchy of the objects:

  • Line item #1 – Negotiated for a group of customers with quarterly payout dates. So you will calculate and approve the rebate separately in 4 rebate records.

    1. Rebate Record – for Q1, for the whole customer group

      • Payout Record – for Q1, for customer A

      • Payout Record – for Q1, for customer B

      • Payout Record – for Q1, for customer C

    2. Rebate Record – for Q2, for the whole customer group

      • …​

  • Line item #2 – Negotiated for 2 customers with annual payouts.

    1. …​

The Payout Records can be reviewed in Rebates › Payout Records, but since their usage is optional and depends on your project needs, you might find the list empty.

payout records list

Fields

Unique Constraints: A combination of three fields – rebateRecordUN, type and name – must be unique.

name – Name of the Payout Record, unique within the scope of the RR that creates it. Sample of values from project: Q1-1, Q1-2,…​

label – Description of the meaning of this Payout Record.

startDate – First date of validity of the values stored in this record.

endDate – (DLast date of validity of the values stored in this record.

payoutDate – Date when the money should be paid to the customer.

rebateType – uniqueName of the Rebate Type, coming from the Rebate Type of the Rebate Record in whose content this Payout Record was generated.

rebateRecordUN – uniqueName of the Rebate Record to which it belongs. Set automatically while creating the Payout Record.

attribute1..100 – Keeps the rebate calculation results – any values needed for the business.

status – Status of the Payout Record. Values are defined by project needs. Sample of values from projects: Pending, Approved, Denied, Paid, …​

type/payoutType – Type of the payout. Values are decided by needs of the project, e.g. to distinguish between more types of payouts. Sample values from projects: Accrual, Summary, …​

intgStatus – String representing a status of integration of this record data to the external system. The set values will be driven by the integration tool (e.g. IntegrationManager) and the needs of the project. Sample of values from projects: Processed, Sent, Error occured, Allocated, …​

intgStatusDetail – String representing detail (explanation) of the intgStatus, possibly shown to end users.

intgStatusErpReference – String representing an ID of a document in ERP which relates to this record (or to which this record was written to). The exact usage depends on the project needs.

Found an issue in documentation? Write to us.

Â