sap vendor program management by vistex

Application Help

Document Version: 1.0 – Final Date: May 21, 2021

Public

SAP Vendor Program Management by Vistex

Application Help PUBLIC


Application Help – Version: 1.0 – Final

May 21, 2021

© 2021 Vistex, Inc. All rights reserved. 1

Table of Contents

1 Introduction ............................................................................................................................... 3 1.1 Purpose ............................................................................................................................................................. 3 1.2 Benefits.............................................................................................................................................................. 3

2 Application Services .................................................................................................................... 5 2.1 Data Objects ...................................................................................................................................................... 5 2.2 Status Flow Overview ........................................................................................................................................ 5

2.2.1 Processing Steps ............................................................................................................................... 5 2.3 Work Manager ................................................................................................................................................... 6

3 Chargebacks ............................................................................................................................. 7 3.1 Benefits of Chargebacks.................................................................................................................................... 7 3.2 Chargebacks Process ....................................................................................................................................... 7

3.2.1 Process Flow ..................................................................................................................................... 8 3.2.2 Processing Steps ............................................................................................................................... 8

3.3 Chargeback Objects .......................................................................................................................................... 9 3.3.1 Master Data ....................................................................................................................................... 9 3.3.2 Source Documents .......................................................................................................................... 10 3.3.3 Agreements ..................................................................................................................................... 11 3.3.4 Transactions .................................................................................................................................... 12 3.3.5 Bucket Overview .............................................................................................................................. 13 3.3.6 Chargeback Claims.......................................................................................................................... 14 3.3.7 Reconciliation .................................................................................................................................. 14 3.3.8 Posting Overview ............................................................................................................................. 15

4 Co-op and MDF ....................................................................................................................... 17 4.1 Benefits of Co-op and Market Development Fund (MDF) ................................................................................ 17 4.2 Co-op and Market Development Fund (MDF) Process Flow ........................................................................... 17 4.3 Co-op and MDF Objects .................................................................................................................................. 19

4.3.1 Master Data ..................................................................................................................................... 19 4.3.2 Source Documents .......................................................................................................................... 20 4.3.3 Agreements ..................................................................................................................................... 21 4.3.4 Claims for Co-op and MDF .............................................................................................................. 22 4.3.5 Reconciliation .................................................................................................................................. 23 4.3.6 Matrix ............................................................................................................................................... 23 4.3.7 Tracking ........................................................................................................................................... 24 4.3.8 Posting Overview ............................................................................................................................. 25

5 Purchasing Rebates .................................................................................................................. 27 5.1 Benefits of Purchasing Rebates ...................................................................................................................... 27 5.2 Purchasing Rebates Process .......................................................................................................................... 28

5.2.1 Purchasing Rebates Process Flow .................................................................................................. 28 5.2.2 Processing Steps ............................................................................................................................. 28

5.3 Purchasing Rebate Objects ............................................................................................................................. 29




May 21, 2021


5.3.1 Master Data ..................................................................................................................................... 29 5.3.2 Source Documents .......................................................................................................................... 30 5.3.3 Agreements ..................................................................................................................................... 30 5.3.4 Matrix ............................................................................................................................................... 32 5.3.5 Tracking ........................................................................................................................................... 32

5.4 Composite Purchasing Rebates ...................................................................................................................... 34 5.4.1 Participants ...................................................................................................................................... 34 5.4.2 Buckets ............................................................................................................................................ 34 5.4.3 Tracking ........................................................................................................................................... 34 5.4.4 Accrual and Settlement .................................................................................................................... 35

6 Data Objects ........................................................................................................................... 37 6.1 Data Objects Overview .................................................................................................................................... 37

6.1.1 Use Cases ....................................................................................................................................... 37 6.1.2 Data Cleansing Capabilities ............................................................................................................. 37 6.1.3 Data Objects Architecture ................................................................................................................ 38 6.1.4 Processing Steps ............................................................................................................................. 38

6.2 Upload/Download Data Objects ....................................................................................................................... 39 6.2.1 Upload Objects ................................................................................................................................ 39 6.2.2 Download Objects ............................................................................................................................ 39

7 Glossary ................................................................................................................................. 41




May 21, 2021


1 Introduction

SAP Vendor Program Management solution by Vistex helps companies manage incoming reimbursements and

incentive payments received from a supplier (also known as a vendor or channel partner) for various reasons, such

as volume purchasing commitments, loyalty, and purchasing growth as agreed upon between the supplier and the

purchasing company.

NOTE: Price administration and rebates to the customer are offered in separately licensed applications, SAP Channel

Program Management by Vistex and SAP Price Management by Vistex.

1.1 Purpose

Companies engage in special pricing negotiations and agreements with other companies in order to receive

purchasing rebates/chargebacks for products purchased which in turn reduces overall costs and expenses. In

addition, partners receive marketing funds to promote and co-market their name with the suppliers’ products to

provide awareness and engagement and ultimately more sales for both companies.

Research shows that the complexity of supplier funding programs is growing rapidly, increasing the need for

marketing fund, rebate and chargeback management. The resulting complexity is a natural outgrowth of a more

sophisticated sales model and competitive environment.

SAP Vendor Program Management enables companies to keep track of any funds they earn from suppliers in an

efficient and comprehensive manner.

1.2 Benefits

SAP Vendor Program Management helps you to increase supplier program efficiency through:

• Collecting all chargebacks, rebates, and funds in a single solution

• Planning, budgeting, and tracking of all funds and rebates received from suppliers




May 21, 2021


• Detailed allocation of rebates to determine true profitability

• Accrual of funds based on a percentage or value of purchases

• Complete visibility into transactions, processes, and agreements

• Managing claim submissions and partner responses to create a comprehensive audit trail



May 21, 2021

© 2021 Vistex, Inc. All rights reserved.

5

2 Application Services

2.1 Data Objects

Data cleansing is performed using the Data Objects functionality. The purpose of Data Objects is to have an

intermediate step between receiving a submission of raw data from external sources and loading that data into the

appropriate application data tables. Rather than sending the raw data directly into the system database, the data will

first be processed based on a predefined data model. Clean data then can be sent to the application in a format that

the application can understand and use.

For detailed information on Data Objects, see the Data Objects topic.

2.2 Status Flow Overview

Status Flow is a flexible approval process tool that can be managed by business users. Status Flow provides the

ability to:

• Create an approval process for creating or changing an application object

• Set an approval in the object's Status tab

• Change the approval flow from one predefined path to another either based on preset triggers or on an ad-hoc basis

2.2.1 Processing Steps

1. The process begins when an object document requires approval.

For example, when an agreement is created it must be approved by a list of users in a predefined sequence.

2. The default trigger starts the standard flow.

The connection between an application object and the status flow is the status profile that consists of a list of

triggers, each of which starts a status flow.

3. Step one in the status flow sends a communication (such as an email) to the first person who must approve

the document.

This communication may be a notification that the user should set the approval, or it may include buttons to

set the approval. The text, buttons, and links are set up in a template assigned to the activity in the status

flow step. When needed, communications can be sent to multiple recipients, all of whom must approve the

document before it is sent to the next status flow step.

4. If approved, the process continues to the processor(s) in the next step of the status flow.

Other outcomes assigned in the flow step will indicate what action will be performed. For example, if

rejected, a communication might be sent to the sales representative asking that person to provide additional

information. Or, the activity might be redirected to another processor.

5. If set up, the system will generate an activity document for each step in the process to track communication.




May 21, 2021


6. The process continues until the flow is complete.

The final step in the status flow might be to send a communication to the user who first created the

agreement.

2.3 Work Manager

Work Manager is the tool used to schedule jobs and sequence processing, typically for processing and posting

transactions. All jobs and their status are viewed in one central screen with drill through capabilities to see details,

follow on documents, and error messages.

For information on using Work Manager, see the related topic in the Customer Administrator Guide.



May 21, 2021

© 2021 Vistex, Inc. All rights reserved.

7

3 Chargebacks

3.1 Benefits of Chargebacks

SAP Vendor Program Management helps you to increase your chargebacks recovery rate through:

• Management of all chargeback agreements, including contract price, % off, fixed amounts, and tiered pricing

• Providing complete visibility into transactions, processes, and agreements

• Defining, documenting, and tracking processes and workflows

• Retroactively processing eligible transactions

• Determination of accurate costs of goods sold for customer and product profitability

• Comprehensive reconciliation capabilities to process disputes

• Collection of all chargebacks owed by the supplier

• Real-time reporting and advanced analytics capabilities

3.2 Chargebacks Process

The chargeback lifecycle is initiated when two parties, typically a supplier and a distributor, enter into an agreement

for end-customer contract pricing, markdowns and discounts, or price protection, and the distributor sells a product to

the customer at the price below their cost. When the distributor/retailer submits a claim for cost recoveries, it must be

recorded, validated, and paid. To recover these costs, they use tracking information to calculate the chargeback

amount. A claim is then submitted to the suppliers for the calculated chargeback amount. Distributors can also use a

claim to short pay an invoice in order to recover these costs. The chargeback lifecycle takes the perspective of the

distributor generating and sending claims to the supplier.




May 21, 2021


3.2.1 Process Flow


The Chargebacks process includes the following steps:

1. Master Data

Master data needed to calculate the Chargeback agreement includes partners/participants,

products/services, and general ledger accounts. Master data setup is lean and limited to system-required

fields, however custom fields necessary for your business can be added, as needed. Data either is fed from

the system of record or created within the solution.

2. Chargeback Agreement

The Chargebacks process varies in complexity, as agreements can involve different products, suppliers, and

validity periods. A distributor might negotiate thousands of agreements, including multiple agreements with

one channel partner or one agreement with multiple partners. The solution stores and centralizes all of a

distributor's agreements to ensure chargebacks are paid efficiently.

3. Transaction Documents

Transactions created in the system provide legacy sales data, reseller sales data, invoices, deliveries, and

POS data.

4. Buckets

Eligibility logic and derivation procedures are used on the source documents to identify any line items

eligible for chargebacks. Once identified, those transactions are placed in the appropriate bucket. Buckets

are set up at the supplier level, and contain information including the reference order and line, sell price,

quantity, cost, date of sale or order-entry date, agreement, contract price, and chargeback amount. Buckets

can be reprocessed if an agreement is changed, or if an agreement is created after a sale has occurred.

Buckets can also be created at an agreement level if claims only need to be sent for specific agreements.




May 21, 2021


NOTE: The transaction information may not specify the cost, but it can be derived in the bucket.

5. Accrual

Accrual postings are performed immediately after an item is added or reprocessed in the bucket to avoid

underreporting profit.

6. Tracking

Tracking is created based on the parameters for each supplier. The tracking information is used to generate

the submission sent to the supplier for the chargeback amount. Distributors may send the calculated

chargeback amount without making a deduction, allowing suppliers to review the calculation before

payment. Some distributors may instead deduct or short pay the supplier for their calculated chargeback

amount.

7. Partner Response

The supplier validates the distributor’s submission. During validation, If the two parties do not agree on the

claim amount, resubmissions and partner responses can be used to record the negotiations between the

distributor and supplier.

8. Settlement

Settlement completes all financial postings initiated by the accrual. If changes are made during reconciliation

that affect the settlement’s net value, the bucket will need to be re-accrued to provide visibility to the true

settlement amount.

3.3 Chargeback Objects

3.3.1 Master Data

Chargebacks collects lean (limited) master data required to perform calculations and searches. A limited number of

fields are required, but custom fields can be added, as needed.

Master data includes the following: partners, products/services, organizational data, and general ledger accounts.

3.3.1.1 Products

Products use limited master data and are received from an external system. Products can be used to set up

agreement rules and are included in chargeback calculations.




May 21, 2021


3.3.1.2 Partners

The following partner types can be defined in master data:

• Customer

• Reseller

• Supplier

• Retailer

3.3.1.3 Flexible Groups

A flexible group is a list of included and/or excluded channel partners, materials, and/or documents (purchase order,

invoice, and so on). Using flexible groups allows suppliers to create custom groups by defining the included values,

such as a range of materials and material groups combined, and then defining the exclusions, such as "except

materials W, X, and Z. Flexible groups can include "and" or "or" statements to note whether all attributes must be met

or if only one of a group has to be met (within a partner group and pricing group, or either part of the partner group or

part of the pricing group).

Flexible grouping allows you to define key attributes with the flexible group. This provides unlimited flexibility to

construct and execute complex pricing algorithms. In configuration, different types of groups can be set up using

different attributes (fields), as needed.

3.3.1.4 Membership

Membership functionality enables management of dynamic groups of partners that can be organized into multiple

hierarchies relevant to pricing and programs. Membership extends customer group and hierarchy functionality to

track suppliers and their subsidiaries, franchises and owner stores, and distributors and branches.

Membership groups can be either internally or externally managed. You can create an internal list, such as your 100

best customers, or use external lists from facilitators, such as customers with a Group Purchasing Organization

(GPO), or distributors with a buying group.

3.3.2 Source Documents

3.3.2.1 Source Document

Transactions are typically used as the source document for chargeback calculations. Data objects and claims can

also be used as source documents.

• Transactions – Legacy sales data, channel partner sales data, and subsidiary sales data can be captured via a Transaction document. Transaction documents capture the sales information for a channel partner.




May 21, 2021


• Claims – When a reseller submits a claim to the distributor to recover costs, distributors use this claim as a source document to calculate the necessary chargeback amounts.

• Data Objects – For both transactions and claims, data objects can serve as an intermediate step between receiving a raw data submission and processing the information. Rather than sending raw data directly into the system database, the data will first be processed based on a predefined data model. Clean data then can be processed for calculation and posting.

NOTE: All of these submission options can go through data objects before entering the transaction application. Data can be stored in data objects without creating a transaction if necessary.

3.3.3 Agreements

An agreement is a contract between two or more parties with mutual obligations and serves as a highly flexible

central repository. Agreements are the foundation for all chargeback processing. A chargeback agreement contains

the eligible participants, materials/products, payout or price percentage, and settlement amount or percentage.

Members/partners must be assigned as participants of the agreement.

3.3.3.1 Rules

The agreement contains the following details, which are set up as rules:

• Who is eligible? Agreement participants can include suppliers, end customers, or a specific location or region.

• What benefits are the participants eligible for? Benefits can be based on special product pricing, including contract pricing, protected costs, promotional pricing, as well as percentage or dollar-amount discounts. These benefits can be included at an overall, hierarchy, product group, or product level. Minimum and maximum benefit amounts can be specified, and scales/tiers/brackets can be defined. The payout can be a dollar amount or percentage.

• What is the expected accrual rate? Accrual rates can be set based on historical claim values.

3.3.3.2 Agreement Requests

An agreement request is initiated when an approval process is required to either create a new agreement or change

an existing agreement. The agreement request allows for one or more levels of approval in an approval

process. During an approval process the user must approve the agreement request before the changes would post to

an agreement or before the request is made into a new agreement.

3.3.3.3 Master Agreements

The master agreement brings multiple price elements, which can be across applications, into one central document

for negotiation and analysis purposes. Once approved and posted, multiple agreements and pricing records can be




May 21, 2021


created from the master agreement. Formal changes can also be tracked with full revision management and

subsequent approvals.

3.3.3.4 Template Agreements

A template agreement is a corporate guide/outline that can be reused to set up multiple similar agreements or

agreement requests. This can be used to simplify entry for similar agreements that come from suppliers or the

corporate guidelines used to propose to a supplier.

3.3.3.5 Clauses

Clauses are the distinct articles, stipulations, or provisions used in an agreement. Multiple clauses are grouped

together to form a template, which defines the clause structure (sequence of clauses). A template is assigned to an

agreement during agreement creation or maintenance. After a template is assigned to the agreement, individual

clauses may be added to or deleted from the agreement-specific clause structure, as needed.

3.3.3.6 Approvals

An agreement can be sent through a workflow approval process, if required, before becoming active in the system.

Approvals provide a way for management to ensure an agreement is within corporate guidelines.

Approvals can be triggered based on an agreement type, partner, or amount. For example, the default trigger starts

the standard flow, but a second trigger can be set up to stop the current flow and start a rush/shortened flow. A

different trigger can be started manually (when a person is on vacation, for example) or started automatically based

on configured system logic (for example, when the agreement amount is greater than a preset limit).

An approval can be performed in the system or sent as an email (SMS or Fax) and approved (or rejected) directly

from the email. Pertinent information for the approval can be attached to the email as reference, such as a copy of

the agreement. When the person who needs to approve the agreement is unavailable, such as on vacation, the

approvals can be delegated to a predetermined substitute. The emails can be redirected or deferred, if needed. When

responding to the email, comments can be added, to explain the reason why the agreement was rejected, for

example.

For more information, see the Status Flow topic.

3.3.4 Transactions

In chargebacks, almost all of the transactions are the sales/invoice information uploaded from the financial system of

record. A transaction can be submitted in a flat file such as an Excel spreadsheet or text file, or through electronic

data interchange (EDI), by fax or email.




May 21, 2021


A transaction document is used to track the user's sales and to import any partner transactional data into the system.

When a distributor submits transaction information to the supplier, those original transactions must be recorded as is.

This is done so each partner has a copy of the submitted transactions.

3.3.5 Bucket Overview

Buckets collect all of the agreement and transactional information necessary to calculate chargeback amounts.

Buckets are set up at the supplier level for chargebacks.

The information stored in calculation buckets is taken from a variety of source documents. Supported source

documents include:

• Sales document

• Billing document

• Delivery

• Purchase document

• Transaction document

• Data objects

• Claim

A configured bucket group is assigned to the calculation bucket. The bucket group stores the calculation used to

determine the agreement necessary to update the bucket line items.

3.3.5.1 Tracking Information Sources

Information sources for tracking include:

• Agreements

• Buckets

• Formulas

3.3.5.1.1 Tracking Document

Data is pulled from selected tracking information sources to create a tracking document, which is used to view

accumulated data at a specific point in time.

A notification might be triggered to notify management that final calculations are ready for review and approval. After

the tracking document is created and before offsetting payments, accruals are performed to provide source data for

posting.

NOTE: Calculations are performed when information is added to the bucket or when tracking is created.




May 21, 2021


3.3.5.1.2 Approvals

The tracking document can be sent through an approval process before the data is sent for posting. An approval can

be performed in the system or sent as an email and approved (or rejected) directly from the email. Pertinent

information for the approval can be attached to the email as reference, such as a copy of the tracking document.

When the person who needs to approve the tracking document is unavailable (on vacation, for example), the


responding to the email, comments can be added, to explain the reason why the document was rejected, for

example.


3.3.6 Chargeback Claims

The distributor sells a product to the customer at the price specified in the chargeback agreement, and this price can

be below their cost or their normal profit margin. When the distributor submits a claim for cost recoveries, it must be

recorded, validated, and paid. To recover these costs, distributors generate a claim from the tracking information, and

then send the supplier a debit memo claiming the calculated chargeback amount. Distributors can also use a claim to

short pay an invoice in order to recover these costs. The chargeback lifecycle takes the perspective of the distributor

generating and sending claims to the supplier.

A claim can be submitted in a flat file such as an Excel spreadsheet or text file, directly on the supplier’s website,

through electronic data interchange (EDI), by fax or email.

3.3.7 Reconciliation

3.3.7.1 Claim Validation

In chargebacks, the supplier performs claim validation after the distributor submits a debit memo. The response is

then sent back to be recorded and reconciled.

3.3.7.2 Partner Response

When a supplier responds to a distributor's claim, a partner response is created. The partner response must be

recorded by the distributor to maintain an audit trail. During validation, If the two parties do not agree on the claim

amount, resubmissions and partner responses are used to record the negotiations between the distributor and

supplier.

The supplier may accept the claim with or without changes or may completely reject the claim. Partner responses can

be sent using one of the following:

• Excel spreadsheet or text file Suppliers and distributors can manually submit a spreadsheet or text file in response to the claim, and this file can be loaded to the financial system.




May 21, 2021


• Web Interface Distributors can submit information via the supplier's website by entering all the information online. After the transaction is entered, the website can also be used to review the status of the submitted transaction.

• Electronic Data Interchange (EDI)

Files are submitted electronically between the supplier and distributor.

3.3.7.3 Workspace

The Workspace is where distributors manage all chargeback reconciliations and data validations. The Workspace

offers bulk-edit functionality and multi-claim reconciliation. Distributors can schedule all reconciliation jobs using the

Work Manager.

3.3.8 Posting Overview

Postings are the internal or external financial transactions which include accrual and settlement.

3.3.8.1 Accrual

The accrual process is carried out as soon as a transaction line item is added to a bucket. This is done so the

distributor avoids underreporting their profit. The accrual provides visibility to chargebacks before the chargebacks

are received. If changes are made during reconciliation that affect the settlement’s net value, the bucket will need to

be re-accrued in order to accurately offset the accrual and debit the credit account.

3.3.8.2 Settlement

Creating posting documents is the final step in settling a claim with a supplier. Using the information obtained from

tracking, the distributor submits a debit memo to the supplier to obtain their calculated chargeback amount. The

supplier settles the claim by transferring the agreed-upon chargeback to the distributor. Financial postings data is

posted to the general ledger from the posting document. The parameters for posting documents are determined on a

partner basis (see below) but posting documents can be created with a set frequency or contain a set of aggregated

information.

3.3.8.3 Parameters

Parameters are set up at the supplier level or the agreement level to indicate the accrual and settlement rules and

frequency (when and how often settlement is performed) when using Accounts Payable or Accounts Receivable to

offset invoices. Claims can also be aggregated by supplier or by agreement as necessary. Date-based parameters




May 21, 2021


are used to maintain multiple sets of parameters, with each assigned to a different date range. Assigning date ranges

allows different parameters to go into effect as of a certain date. Parameters cannot be created with overlapping

dates, however.

Parameters defined for a supplier can be changed at the agreement level. The agreement parameters always take

precedence over the standard parameters.




May 21, 2021


4 Co-op and MDF

4.1 Benefits of Co-op and Market Development Fund

(MDF)

The Co-op and MDF functionality helps you increase the effectiveness of your promotional allowance programs

received from your suppliers by:

• Utilizing earned/variable funds (Co-op) or discretionary/fixed funds (MDF)

• Managing of funds through budgeting, including release, reserve, and earmarking functions

• Planning one or multiple promotional activities to be executed at a future time using Master Agreements

• Proposing and executing marketing activities through agreements and agreement requests

• Defining scheduled or ad hoc claim and point-of-sale (POS) submissions

• Managing claim submissions and partner responses to create a comprehensive audit trail

• Viewing fund balances and activities to track earnings and payouts across programs

• Securing funds to be spent on promoted products

4.2 Co-op and Market Development Fund (MDF) Process

Flow

Funds are typically a predefined fixed amount from the supplier, or a variable amount that is earned based on sales

or purchases from the supplier. Fixed funds are typically called MDF and variable funds are typically called Co-op or

earned funds. Programs are defined by the supplier with the rules and guidelines around the fund usage (defined

activities, requirements needed to prove an activity was completed, payout percentages for each activity, etc.) and

the fund amounts. At times, the supplier will not specify an amount ahead of time and will only approve project

requests after receiving a project proposal. Even if fund amounts are defined, an approval process for the activities

may need to occur. There different types of Co-op and MDF agreements can be managed with varying levels of

complexity and control.

Fixed Fund Agreements

1. Fixed fund agreements with defined amounts that do not require Proof of Performance (POP).

This should be treated as rebates and can be managed with a fixed amount rule or through schedules.

Please see the Rebates topic for more information.

2. Fixed-fund agreements with defined amounts utilizing POP parameters.

o Schedules can be used to track the fixed fund amounts. As the activities are performed, a

transaction document is created to claim full or partial payments from the supplier and deplete the

requested amount in the schedule upon approval/payment.

o A matrix data table (viewed using the grid-based application UI), can also track the fixed fund

amounts. The matrix acts as a checkbook which will track the deposits and payments which is

stored outside the agreement and shows an aggregate picture across suppliers and programs.




May 21, 2021


There is no hard stop when using the matrix, which allows for more funds to be requested than

granted if further negotiation is needed.

o True fund management is also available which gives the most control including budgeting.

However, because the distributor does not have control over the fund’s budget, fund agreements

offer more complexity than what is necessary for supplier funding programs. For more detailed

information on using funds and budgeting, please refer to the SAP Channel Program Management

user documentation.

Note: If no amount is defined up front, this process will still be used, and each agreement will be a stand-

alone fund amount for tracking purposes.

Variable Funds

1. Variable fund agreements that do not require POP.

This should be treated as rebates and can be managed with a percentage or per unit amount rule. Please

see the Rebates topic for more information.

2. Variable fund agreements that require POP.

The execution of this is the same as a fixed fund but will include the accrual of the fund amount. This accrual

will be done similar to rebates, but will be posted to the schedule, matrix, or fund instead of sending a debit

memo to the supplier.




May 21, 2021


4.3 Co-op and MDF Objects

4.3.1 Master Data

Co-op and MDF collects lean (limited) master data required to perform fund calculations and perform searches. A

limited number of fields are required, but custom fields can be added, as needed. Master data is defined in a source

system or through an interface with an ERP system.

4.3.1.1 Products

Products use limited master data and are received from an external system. Products can be used to set up

agreement rules and are included in fund calculations.

NOTE: Products are only needed for Co-op/earned scenarios or if funds spent need to be allocated to the products

that are promoted/marketed.




May 21, 2021


4.3.1.2 Activities

An activity is a marketing element designed to drive a specific behavior in a target audience. These can include direct

mailings, trade shows, funded head, advertisements, as well as many other marketing events. Activities structured in

master data can be used to set the budget and proof-of-performance requirements for fund agreements.

NOTE: Activities are stored as products and can be set up directly within the solution.

4.3.1.3 Partners


• Customer

• Supplier (formerly Vendor)

• Reseller


A flexible group is a list of included and/or excluded suppliers, materials, and/or documents (purchase order, invoice,

and so on). Using flexible groups allows suppliers to create custom groups by defining the included values, such as a

range of materials and material groups combined, and then defining the exclusions, such as "except materials W, X,

and Z. Flexible groups can include "and" or "or" statements to note whether all attributes must be met or if only one of

a group has to be met (within a partner group and pricing group, or either part of the partner group or part of the

pricing group).




NOTE: Flexible groups are only needed in a Co-op/earned fund scenario.



Transactions are the source document for Co-op calculations. Some example source documents are invoices and

sales transactions which will be used as a reference for the fund accrual amounts.

• Transactions – System-of-record sales data, reseller sales data, and subsidiary sales data can be captured via a Transaction document.

• Data Objects – For transactions, data objects can serve as an intermediate step between receiving a raw data submission and processing the information. Rather than sending raw data directly into the system




May 21, 2021


database, the data will first be processed based on a predefined data model. Clean data then can be processed for calculation and posting.

NOTE: All of these submission options can go through data objects before entering the transaction application. Data

can be stored in data objects without creating a transaction, if necessary.

NOTE: Transactions will also be used to send proof of activity completion to the supplier. They will be a different

transaction document type.

4.3.3 Agreements

Usually, before Co-op and MDF funds are paid out, an agreement is set up between the supplier and distributor

regarding the factors used to calculate the fund. The agreement is a central repository for fund details, summarizing

the fund conditions and settlement parameters. Each agreement pertains to one supplier. Agreements can be

national, local, or limited to a specific partner location.

Agreements are highly flexible, enabling one or more fund options to change frequently and be modified retroactively.

4.3.3.1 Rules


• Who is eligible? Participants can be specifically assigned or dynamically determined.

• What benefits are the participants eligible for? Benefits can be what activities are allowed, the amount or reimbursement for the activity and the amounts to be spent. For co-op/earned scenarios, they will also include the earning logic and rates. These benefits can be included at an overall, hierarchy, product group, or product level. Minimum and maximum benefit amounts can be specified, and scales/tiers/brackets can be defined. The payout can be a dollar amount or percentage.

4.3.3.2 Schedules

Schedules in agreements are used to maintain Advances, Min. Guarantees, and Lump Sum Amounts.

In order to cater to Rights and Royalty requirements, Schedule For is introduced with the below values:

• A - Payments Only: Use this option for Fees/Advance Payments without Recoupment

• B - Payments with Recoupment: Use this option for Fee/Advance Payments with Recoupment. This option tracks the portion of a schedule item amount that is recouped.

• C - Reservation Only: Not supported. The use case doesn't exist.

• D - Reservation with Consumption: Use this option to capture reservation and liquidation amounts. When royalties are calculated based on applications, some amount is set aside as Reserves for a certain period to handle returns of items. Once the reserve period is complete, then the amount is liquidated and considered for royalties’ calculation in subsequent periods.

• E - Consumption Only: Use this option to process Minimum Guarantees or for On-Demand Claims consumption.




May 21, 2021




an existing agreement. For Co-op and MDF agreements, agreement requests are submitted when requesting funds

for an activity. The agreement request allows for one or more levels of approval in an approval process. During an

approval process the supplier must approve the agreement request before the changes would post to an agreement

or before the request is made into a new agreement. An example of an agreement request is to propose an activity to

utilize the funds to the supplier for approval before executing it.

4.3.3.4 Approvals












example.


4.3.4 Claims for Co-op and MDF

The Co-op and MDF lifecycles are initiated when a supplier and a distributor enter an agreement for a marketing

activity. When users submit a claim or debit request for cost recoveries, it must be recorded in the supplier’s

system. The Co-op and MDF lifecycles take the perspective of the distributor’s submission of the claim(s) to the

supplier.

Claims can be used request funds for promotional activities, and to resolve disputes during claim reconciliation.

Claims for marketing activities can be submitted before or after payment.

In Co-op and MDF, claims are created manually in a transaction document. Once approved internally, the claim can

be submitted in a flat file such as an Excel spreadsheet or text file, directly on the supplier’s website, through

electronic data interchange (EDI), by fax or email for validation and approval.




May 21, 2021


4.3.5 Reconciliation

4.3.5.1 Claim Validation

In Co-op and MDF, the supplier performs claim validation after the distributor submits a debit request. The response

is then sent back to be recorded and reconciled.

4.3.5.2 Partner Response

When a supplier responds to a distributor's claim, a partner response is created. The partner response must be

recorded by the distributor to maintain an audit trail. During validation, if the two parties do not agree on the claim

amount, resubmissions and partner responses are used to record the negotiations between the distributor and

supplier.

The supplier may accept the claim with or without changes or may completely reject the claim. Partner responses can

be sent using one of the following:

• Excel spreadsheet or text file Suppliers and distributors can manually submit a spreadsheet or text file in response to the claim, and this file can be loaded to the financial system.

• Web Interface Distributors can submit information via the supplier's website by entering all the information online. After the transaction is entered, the website can also be used to review the status of the submitted transaction.

• Electronic Data Interchange (EDI)

Files are submitted electronically between the supplier and distributor.

4.3.5.3 Workspace

The Workspace is where distributors manage all fund reconciliations and data validations. The Workspace offers

bulk-edit functionality and multi-claim reconciliation. Distributors can schedule all reconciliation jobs using the Work

Manager.

4.3.6 Matrix

A matrix is a table that holds data used to create complex planning models and can be used for fund agreements.

Characteristics (who to track) and key figures (what to track) are used to define a particular matrix for a time period

specified in the attached agreement. A matrix contains all historical fund data, and this information is stored without

the supporting transaction information to save space.

Subsets of a matrix are used to manage and maintain selected data from the matrix. For example, the matrix might

contain data for all partners and fund activities. A subset could be defined to manage data only for a few partners and




May 21, 2021


one activity. For each subset, you define versions/usages, which contains a list of members, layouts, and functions

for the version, and indicate the data sources to be used when uploading data to the matrix.

4.3.7 Tracking

Tracking is a way to visualize how the activities in the agreement are performing, to make sure that the agreement is

driving behavior as expected.

Data is pulled from various sources to create a tracking document, which is used to view the accumulated data at a

specific point in time for a partner. From the tracking screen you can view all the source information, such as the

agreement and transaction documents.

In the case of Co-op, it is to track the amount of funds earned. In the case of POP, it will be used to trigger the fund

payment request to the supplier.



• Agreements

• Buckets

• Formulas

4.3.7.1.1 Buckets

The information stored in calculation buckets is dependent on the configured bucket types. A bucket type can be

defined for each application and source document combination. Supported types of source documents are:

• Sales document



A configured bucket group is assigned to the calculation bucket. The bucket group stores the calculation used to

determine the agreement necessary to update the bucket line items. Buckets are only needed for Co-op scenarios to

aggregate sales and purchase information. Buckets can also be used if allocation to a product level for the fund is

needed on financial postings.

4.3.7.1.2 Tracking Document




the tracking document is created and before offsetting payments or fund postings, accruals can be performed to

provide source data for posting.




May 21, 2021


4.3.8 Posting Overview

Creating posting documents is the final step in settling a claim with a partner. Using the information obtained from

tracking, the supplier settles the claim by transferring the necessary funds to the distributor. Financial postings data is

posted to the general ledger using an outbound posting document. The parameters for posting documents are

determined on a partner basis (see below) but posting documents can be created with a set frequency or contain a

set of aggregated information.

4.3.8.1 Accrual

Accrual is the process of recording the amount to be claimed. The accrual process is performed so users can

determine their financial position before the transfer of funds takes place. The accrual provides visibility to the claim

until it is paid. Accounting accuracy after accrual is essential since it reflects the difference between the actual funds

currently available and those that will be available after settlement takes place. When creating a fixed or variable fund

agreement, an accrual is created to provide visibility for the financial system. When the distributor submits a claim,

suppliers use the claimed amount to deplete the accrual.

4.3.8.1.1 Internal Posting

Internal posting is the process by which distributors record their expenditures to be claimed from the supplier. Internal

posting documents record all of these expenses in a bucket that is later used to calculate the accrual amount. In

some cases, funds may be given upfront and internal postings will track the actual spend against the fund.

4.3.8.2 Settlement Overview

Settlement is performed to reflect the transfer of funds between the supplier and the partner receiving the fund. This

process completes the financial postings initiated by the accrual and depletes the fund. Financial posting data is

posted to the general ledger using an outbound posting document.

4.3.8.3 Parameters

Settlement parameters are set up at the distributor level to indicate the rules for settlement. For Co-op and MDF, the

partner receiving the fund is considered the distributor. The settlement parameters defined for the supplier govern the

settlement process.

Date-based parameters can be used to maintain multiple sets of settlement parameters, each assigned to a different

date range. Assigning date ranges allow different parameters to go into effect as of a certain date. Parameters cannot

be created with overlapping dates, however.




May 21, 2021


Parameters defined for a supplier can be changed at the agreement level. The agreement settlement parameters

always take precedence over the standard settlement parameters.




May 21, 2021


5 Purchasing Rebates

5.1 Benefits of Purchasing Rebates

The Purchasing Rebates application provides organizations with valuable tools required to model, administer, track,

analyze incoming payments from suppliers for achieving volume commitments and spend growth goals. Purchasing

Rebates helps you maximize your rebate programs through:

• Tracking quantity, percent, and flat-tiered volume and growth purchasing rebates

• Improvements to accuracy by including or excluding customer sales in rebate calculations

• Adjusting program criteria midstream and retroactively recalculating amounts due

• Recording pre-determined objectives and achievements to align with supplier payments

• Maximizing payments with optimal purchasing volumes

• Gaining granular allocation of rebates to determine true profitability




May 21, 2021


5.2 Purchasing Rebates Process

5.2.1 Purchasing Rebates Process Flow


The purchasing rebate process initiates only after the distributor purchases and/or sells a product from a supplier with

whom a rebate agreement has been created. Purchase orders typically constitute the purchasing source documents

that serve as proof of purchase.

The main steps in the purchase rebate process flow include:

1. Master Data

Master data needed to calculate the Chargeback agreement includes partners/participants,

products/services, and general ledger accounts. Master data setup is lean and limited to system-required

fields, however custom fields necessary for your business can be added, as needed. Data either is fed from

the system of record or created within the solution.




May 21, 2021


2. Purchasing Rebate Agreement

The purchasing rebate process begins with creating a purchasing rebate agreement with the supplier.

Creating the agreement, which contains the rules and guidelines for the partners on the agreement and the

amounts to be paid, creates a condition contract as well as the calculation bucket that will store the source

document line items.

3. Source Documents

Transactions created in the system provide legacy sales data, purchase orders, distributor sales data,

invoices, deliveries, and POS data.

4. Tracking

Tracking is created based on the parameters for each supplier. The tracking information is used to generate

the debit memo sent to the supplier for the rebate amount.

5.3 Purchasing Rebate Objects

5.3.1 Master Data

Purchasing Rebates collects lean (limited) master data required to perform rebate calculations and perform searches.

A limited number of fields are required, but custom fields can be added, as needed.

Master data includes the following: partners, products/services, organizational data, territories, and general ledger

accounts.

5.3.1.1 Products

Products use limited master data and are received from an external system. Products are used to set up agreement

rules and are included in rebate calculations.

5.3.1.2 Partners


• Customer

• Supplier (formerly Vendor)

• Business partner

• Contact person




May 21, 2021



A flexible group is a list of included and/or excluded channel partners, materials, and/or documents (purchase order,

invoice, and so on). Using flexible groups allows suppliers to create custom groups by defining the included values,

such as a range of materials and material groups combined, and then defining the exclusions, such as "except

materials W, X, and Z." Flexible groups can include "and" or "or" statements to note whether all attributes must be

met or if only one of a group has to be met (within a partner group and pricing group, or either part of the partner

group or part of the pricing group).






Transactions are typically used as the source document for purchasing rebate calculations. Claims and data objects

can also be used as source documents.

• Transactions – System-of-record purchasing, and sales data, channel partner sales data, and subsidiary sales data can be captured via a Transaction document.

• Data Objects – Data objects can serve as an intermediate step between receiving raw transaction information and processing the information. Rather than sending raw data directly into the system database, the data will first be processed based on a predefined data model. Clean data then can be processed for calculation and posting.

NOTE: Transactions can go through data objects before entering the transaction application. Data can be stored in

data objects without creating a transaction, if necessary.

5.3.3 Agreements

Usually, before purchasing rebates are paid out, there is an agreement set up between the channel partner and the

supplier regarding the factors used to calculate the rebate. The agreement is a central repository for rebate details.

An agreement summarizes the pricing conditions of the rebate and houses the settlement parameters. Each

agreement can pertain to many partners or just one partner. Agreements can be national, local, or limited to a specific

partner location.

Agreements are highly flexible, enabling one or more purchasing rebate pricing factors that can be defined at any

level. Purchasing rebate pricing can be specified as a dollar amount or percentage, and can depend on various

combinations such as sales, sales area, purchasing, netting include/exclude, customer, material, or a combination of

the above. These rules can change frequently and be modified retroactively.

The net result of an agreement is determined by a calculation flow. Calculation flow is a collection of steps defined in

a sequence where each step will calculate some results, and all of the steps together calculate the overall result.




May 21, 2021


5.3.3.1 Rules


• Who is eligible? Participants can be specifically assigned or dynamically determined.

• What benefits are the participants eligible for? Rebates can be based on growth, revenue, and non-sales metrics such as shelf space or market share. Benefit rates can be a fixed bonus, or a percentage of the amount purchased. Minimum and maximum benefit amounts can be specified, and scales/tiers/brackets can be defined. The payout can be a currency amount or percentage.



an existing agreement. The agreement request allows for one or more levels of approval in an approval

process. During an approval process the channel partner must approve the agreement request before the changes

would post to an agreement or before the request is made into a new agreement.

5.3.3.3 Master Agreements

The master agreement brings multiple price elements, which can be across applications, into one central document

for negotiation and analysis purposes. Once approved and posted, multiple agreements and pricing records can be

created from the master agreement. Formal changes can also be tracked with full revision management and

subsequent approvals.

5.3.3.4 Template Agreements

A template agreement is a corporate guide/outline that can be reused to set up multiple similar agreements or

agreement requests. This can be used to simplify entry for similar agreements that come from suppliers or the

corporate guidelines used to propose to a supplier.

5.3.3.5 Clauses

Clauses are the distinct articles, stipulations, or provisions used in an agreement. Multiple clauses are grouped

together to form a template, which defines the clause structure (sequence of clauses). A template is assigned to an

agreement during agreement creation or maintenance. After a template is assigned to the agreement, individual

clauses may be added to or deleted from the agreement-specific clause structure, as needed.




May 21, 2021


5.3.3.6 Approvals












example.


5.3.4 Matrix

A matrix is a table that holds data used to create complex planning models. Characteristics (who to track) and key

figures (what to track) define a particular matrix, for a specified time period. Different views of the matrix data can be

set up for different audiences. Business defined functions can be used to maintain matrix data, for example to set

targets. The solution provides a series of pre-delivered distribution functions, and custom functions can be created.

All historical purchasing rebate data, which is data stored without supporting transaction data (to save space), is

stored in a matrix.

Subsets of a matrix are used to manage and maintain selected data from the matrix. For example, the matrix might

contain data for all buyers and all product lines. A subset could be defined to manage data only for a few buyers and

a limited number of product lines. For each subset, you define versions/usages, which contains a list of members,

layouts, and functions for the version, and indicate the data sources to be used when uploading data to the matrix.

Uploading data into the matrix table is performed from the following:

• Data sets, which are used to select the data to be pushed into the matrix

• External files, uploaded to the matrix

5.3.5 Tracking

Tracking is a way to visualize how the participants in the agreement are performing, to make sure that the agreement

is driving behavior as expected. Tracking information is also included in the calculation flow.

Data is pulled from various sources to create a tracking document, which is used to view the accumulated data at a

specific point in time for a partner. From the tracking screen you can view all the source information, such as the

agreement and transaction documents.

Within the agreement, drivers are assigned to tracking methods, which control what drivers are shown on the tracking

screen. For example, if Growth and Revenue are drivers assigned to an agreement, Growth can be assigned to one




May 21, 2021


tracking method and Revenue assigned to another tracking method, or both drivers can be assigned to the same

tracking method.



• Agreements

• Formula calculations

• Matrix

• Aggregation

• Bucket

• Evaluations

5.3.5.1.1 Aggregation

Data is aggregated in buckets to consolidate the rules/calculation document data used in tracking.

5.3.5.1.2 Evaluations

Data from an evaluation can be displayed in tracking.

5.3.5.2 Tracking Document




the tracking document is created and before financial postings, accruals are performed to provide source data for

posting.

5.3.5.2.1 Approvals

The tracking document can be sent through an approval process before the data is sent for accrual and settlement.

An approval can be performed in the system or sent as an email and approved (or rejected) directly from the email.

Pertinent information for the approval can be attached to the email as reference, such as a copy of the agreement.

When the person who needs to approve the tracking document is unavailable, such as on vacation, the approvals

can be delegated to a predetermined substitute. The emails can be redirected or deferred, if needed. When




May 21, 2021


responding to the email, comments can be added, to explain the reason why the document was rejected, for

example.


5.4 Composite Purchasing Rebates

5.4.1 Participants

A participant is the entity to whom the final amount is being paid or from whom the final amount is received.

Participants in a rebate may be suppliers, distributors, retailers, customers, agreements, and materials.

Participation can be versioned, allowing users to perform a "what-if" analysis.

5.4.2 Buckets

The information stored in buckets is dependent on the configured bucket types. A bucket type can be defined for

each application and source document combination. Supported types of source documents are:

• Sales document


• Sales from distributor/channel partner


A configured bucket group is assigned to the calculation bucket. The bucket group stores the calculations used to

determine the agreement necessary to update the bucket line items.

5.4.3 Tracking

Use Tracking to review the performance of a selected participant. Tracking can be used for accrual, settlement, or

alerts. Composite Tracking leverages mapping and formulas in order to perform those calculations.




May 21, 2021


5.4.4 Accrual and Settlement

5.4.4.1 Composite Accrual and Settlement

Accrual is a process that involves financial postings against an expense account and a clearing account. During

accrual, there is no physical transfer of funds between the accounts. The accrual process helps the company to

predetermine what its financial position will be after the expenses of a plan have been processed.

In the Composite model, accrual and settlement take place at the participant level rather than at the document or

bucket level. Accrual and settlement can be initiated manually or run automatically based on the settlement calendar

assigned to either the deployment code or the participant.

5.4.4.1.1.1 Accounting Levels

Based on deployment code version configuration, financial accounting for composite plans can be done at the

following levels:

• Subcomponent Accounts for the entire amount as it relates to each subcomponent, such as brand or material group, to retain tracking of the amount for each subcomponent.

• Bucket line item Use of a summarization profile is recommended.

• Participant (not recommended) Full amount is accrued and settled. No profitability analysis is available.

5.4.4.1.2 Examples

5.4.4.1.2.1 Period-to-Date (PTD) Plan

If a plan is set up as a Period-to-Date (PTD) plan, then all data depends on the cumulative totals of all previous

periods. This example covers three months:

• Month 1, the administrator accrues $100 for that month. The company owes the customer $100, so $100 is the settled amount.

• Month 2, the administrator accrues a new amount of $180, which is the cumulative amount for months 1 and 2. The system reverse accrues the $100 from the previous month. Since the customer has already received $100, the company owes the customer a remaining amount of $80, which is the amount settled for month 2.

• Month 3, the administrator accrues $250, then reverse accrues the old amount of $180. The final settled amount is $70.

Month Accrual Reverse Accrual Settlement

Month 1 $100 $100

Month 2 $180 -$100 $80

Month 3 $250 -$180 $70




May 21, 2021


NOTE: When settlement occurs, the formula looks at the agreement and pulls the information before calculation.

5.4.4.1.2.2 Current Period (CPD) Plan

If a plan is set up as a Current Period (CPD) plan, then all data depends on the totals of the current period. In this

example, the customer receives all the billbacks due at the end of the period and no amounts are carried forward to

the next period. The Current Period Plan is on a month-to-month accrual and settlement basis. Each month the plan

will accrue and settle without any reverse accrual for previous months.

Month Accrual Settlement

Month 1 $100 $100

Month 2 $80 $80

Month 3 $70 $70

5.4.4.2 Composite Accrual and Settlement Processing

Composite accrual and settlement processing is performed using the Work Manager.




May 21, 2021


6 Data Objects

6.1 Data Objects Overview

The purpose of data objects is to have an intermediate step between receiving a submission of raw data from

external sources and loading that data into the appropriate application data tables. Rather than sending the raw data

directly into the system database, the data will first be processed based on a predefined data model. Clean data then

can be sent to the application in a format that the application can understand and use.

Data objects functionality has been integrated into the following applications, allowing you to create documents within

these applications:

• Agreement

• Agreement request

• Claim, transaction

• Master request

• Customer list

• Product list

• Supplier list (formerly Vendor list)

• Membership

6.1.1 Use Cases

Data objects can be used in many business processes, such as:

• Agreement upload

• GPO membership roster submission

• Distributor sales feeds

• Retail POS transactions

• Industry data (IRI or Nielsen, for example)

• Royalty IP exploitation

• Managed care utilization

6.1.2 Data Cleansing Capabilities

Raw data submitted from an external source may require one or more of the following types of data cleansing before

it can be loaded into application data tables:

• Formatting, such as changing numeric values formatted with a negative sign after the value (1-) to values formatted with the negative sign before the value (-1)

• Transformation, data scrubbing such as removing a prefix that is not relevant




May 21, 2021


• Derivation, data cleansing capability to derive data values, such as performing a partner lookup

• Enrichment, for example splitting an address into multiple fields

• Validation, to cross reference a customer for example

6.1.3 Data Objects Architecture

The organization of a data model includes the following:

• Fields Fields can be domain/application-specific or global (available for use in all domains). Fields are grouped into sections.

• Versions A version consists of multiple sections, such as header, items, partners, and materials, which can be nested. Raw data imported into the system is stored as the initial version. Subsequent versions of the data are created as the data is cleansed/processed. The cleansed version contains the data that will be loaded into the application files.

Predefined mapping controls the flow of data from (source) version to (target) version, section to section, and field to

field when a new version is created. Logic defined in data object rules can be applied as the data is mapped.


1. Data file is received from the external source, such as a customer, channel partner, or distributor.

2. Upload the raw data as is, using a file template to map the data to a predefined data model designed to

capture all the necessary information for your system. Alternately, an IDOC can be used to import the file.

3. Analyze the data, by running a predefined run profile, to identify trends and decide what cleansing is

required.




May 21, 2021


4. Create a cleansed version of the data. The system will process (cleanse and reformat) the source data,

based on predefined groups of rules (rule profiles).

If needed, you may compare the initial version to the clean version to review the differences.

5. Load/post the clean data into the appropriate application files. Partial postings can be performed from the

Object Workbench, if configured for the data model.

6.2 Upload/Download Data Objects

6.2.1 Upload Objects

Use Upload Objects to upload the initial version of a partner data file from either a desktop or file server.

To perform an upload, you need to specify the following information:

• data object types

• file source (desktop or file server)

• file name

• data model file template name or submitter

• submission date

If specifying a submitter, you may use the data model configuration to define upload parameters for that submitter,

including the default file template, based on the submission date. File templates are created to control the fields and

format of files during upload.

The version number will default based on the data model.

6.2.2 Download Objects

Use Download Objects to download selected data objects to a specific file on a desktop or file server. For large

downloads, this transaction can be run as a background job using Work Manager.

You must specify a file template for the download. File templates are used to control the fields and format of files

during download.




May 21, 2021


7 Glossary

Term Definition

Activity An activity is a marketing element designed to drive a specific behavior in a target audience. Activities can include direct mailings, trade shows, funded head, advertisements, as well as many other marketing events. Activities are structured in master data as products and can be used to set the budget and proof-of-performance requirements for fund agreements.

Actual Accruals Total net values of the accrual line items.

Adjustment Code Codes are used to specify the reasons for adjustments. When an adjustment is carried out, the corresponding adjustment code is displayed at the line item level in the document.

Agreement An agreement is a contract between two or more parties with mutual obligations. It serves as a highly flexible central repository and is the foundation for all processing in the solution.

Agreement Request An agreement request is initiated when an approval process is required to either create a new agreement or change an existing agreement.

Agreement Type The agreement type is how condition records are grouped together using agreements.

Approval Code Managers assign an approval code before accrual and settlement can occur.

Approval Status After an approval code is entered, the system assigns an internal approval status.

Attribute Attributes define the allowed values for an organizational object or external person.

Bucket Stores lean data from source documents related to an agreement and/or partner. Calculated information is stored in the calculation line items, which are visible in the calculation run and tracking. Bucket documents can be created either manually or automatically from agreements or settlement parameter groups.

Bucket Type Controls all fields to be stored in the calculation bucket. Configured for each application/source document type. A calculation bucket type is assigned to the agreement type.

Calculation Engine Performs all calculations, such as bucket line item calculations.

Calculation Path Tells how the system will read the condition table for transactions.

Channel Partner A distributor, retailer or customer who purchases products or services in a business-to-business (B2B) transaction.

Chargeback A chargeback is the process of a distributor claiming compensation from one of its suppliers. It manages the process of them "charging back" for expenses they have incurred on the paying company's behalf.

Claim 1. The process of asking for compensation from a partner. 2. A document in the solution that stores the data relevant to process the request for compensation from a partner. That data typically includes, but is not limited to, a subset of the following: materials, quantities, partners, requested amount, reference/related pricing records, requested and calculated agreements supporting the request, and partners related to the initial transaction. The claim can also be used to validate and clean up the data and reconcile the amounts requested versus the amounts calculated.

Claim Status The status of a claim is indicated by a status code defined in configuration.

Clause Distinct articles, stipulations, or provisions in a legal document, such as a contract. From a system standpoint, a clause is the text created for a distinct article, stipulation, or provision.

Cross Reference Cross references link the current system records (materials, partner, unit of measures, agreements) with the incoming record numbers so the records can be matched, and incoming documents can be processed. Cross reference mapping may be performed in memberships, claims, transaction documents, price sheets, and price types.

Data Model Data is processed based on a redefined data model that is designed to capture all the necessary information for the system.

Data Object An intermediate step between receiving a submission of raw data from external sources and loading that data into the appropriate application data tables.




May 21, 2021


Dataset Used for accounting at the composite line item level. The dataset defines the formula or criteria used to push all applicable line items into financial allocation tables for processing a composite plan.

Delegation Substitute who approves documents when the original person is on vacation or otherwise unavailable.

Domain (Data Objects)

A domain is a set of fields that are available for assignment to a data model. Global fields are domain independent and can be assigned to multiple data models.

Driver Drivers are business drivers tied to incentives and contains the calculations necessary to process the applicable rebate. Drivers are assigned to rules to affect the agreement behavior.

Evaluation Evaluation is a data collection tool similar to a survey. Each evaluation consists of a set of fields and/or grids used to record and track data. The global evaluation tool can be used for various situations, such as: outcome-based contracting (census or compliance), MBO evaluation, contextual evaluation, or suitability (using a questionnaire).

Expected Accrual Setting aside funds for claims expected in the future, based either on actual shipments or anticipated volume.

Field (Data Objects) Part of the organization of a data model, fields can be domain/application-specific or global (available for use in all domains).

Field Type In Data Objects, a custom classification used to assign common characteristics and fixed values to a group of fields. For example, a custom field type can be assigned to 20 fields that have the same technical characteristics, such as data type and number of decimal places. If no custom field type is assigned when creating a field, the system will generate a field type.

File Template Re-usable template that controls the fields and format of files during upload and/or download.

Organizational Object

Organizational objects are groupings of departments, positions, roles, and individuals (employees and external persons) used to store additional information about customers, suppliers, and employees. This functionality provides the flexibility to maintain HR resources at all levels of the organizational tree, including employee personal data, job responsibilities, position, and pay grade information.

Outstanding Accruals

Dollar amount for the expected accruals not yet accrued. Calculated as: Expected Accrual - Actual Accruals + Adjusted Accruals

Outstanding Settlement

Dollar amount for the actual accruals not yet settled. Calculated as: Actual Accruals - Settlement Amount.

Posting Period Period within a fiscal year for which transaction figures are updated.

Protected Cost Cost for the distributor to buy a product for a specific customer.

Protected Price Agreed-upon price for a customer to buy a specific product.

Reconciliation Process used to resolve the discrepancy between the claimed amount and the accepted amount.

Reverse Accrue Process of reversing the postings of the original accrual. An accounting document is created to reflect the reversal.

Rule (Data Object) Logic defined in data object rules can be applied as the data is mapped.

Search Profile (Data Objects)

The data object mass processing transactions do not have standard selection criteria. Instead, a user-defined set of selection fields, called a search profile, is used to fetch and display data across data objects.

Section Each section of the data model is a collection of fields.

Settlement Process of paying participants of a plan, depending on qualifying eligibility and calculations. Postings are made to Finance GL accounts.

Submission Submission or claim submission refers to the debit memo distributors submit to suppliers indicating their calculated chargeback or rebate amounts.

Subset A subset is used to define the set of data to be loaded into a matrix table.

Supplier A manufacturer, vendor or other seller of products and services in a business-to-business (B2B) transaction.