Application Help SAP Channel Program Management by Vistex 2.0

Application Help Public
Document Version: 2.0 – Final

Date: February 28, 2022
SAP Channel Program Management by Vistex

Application Help PUBLIC
Table of Contents
1 Introduction ............................................................................................................................... 5
2 Application Services .................................................................................................................... 6

2.1 Data Objects ...................................................................................................................................................... 6
2.2 Status Flow ........................................................................................................................................................ 6
2.2.1 Processing Steps ............................................................................................................................... 6
2.3 Work Manager ................................................................................................................................................... 7
3 Billbacks ................................................................................................................................... 8
3.1 Benefits of Billbacks .......................................................................................................................................... 8
3.2 Billbacks Process .............................................................................................................................................. 9
3.2.1 Process Flow ..................................................................................................................................... 9
3.2.2 Processing Steps ............................................................................................................................... 9
3.3 Billback Objects ............................................................................................................................................... 10
3.3.1 Master Data ..................................................................................................................................... 10
3.3.2 Source Documents .......................................................................................................................... 11
3.3.3 Agreements ..................................................................................................................................... 12
3.3.4 Accrual Overview ............................................................................................................................. 13
3.3.5 Claims for Billbacks.......................................................................................................................... 15
3.3.6 Transactions .................................................................................................................................... 16
3.3.7 Reconciliation .................................................................................................................................. 17
3.3.8 Posting Overview ............................................................................................................................. 17
4 Co-op and MDF ....................................................................................................................... 19

4.1 Benefits of Co-op and Market Development Fund (MDF) ................................................................................ 19
4.2 Co-op and Market Development Fund (MDF) Processes ................................................................................ 19
4.3 Co-op and MDF Objects .................................................................................................................................. 21
4.3.1 Master Data ..................................................................................................................................... 21
4.3.3 Agreements ..................................................................................................................................... 22
4.3.4 Tracking ........................................................................................................................................... 24
4.3.5 Claims for Co-op and MDF .............................................................................................................. 26
4.3.6 Transactions .................................................................................................................................... 27
4.3.7 Funds Overview ............................................................................................................................... 27
4.3.8 Reconciliation .................................................................................................................................. 28
4.3.9 Posting Overview ............................................................................................................................. 29
4.3.10 Channel Tracking ............................................................................................................................. 30
5 Sales Rebates ......................................................................................................................... 32

5.1 Benefits of Sales Rebates ............................................................................................................................... 32
5.2 Sales Rebates Process ................................................................................................................................... 32
5.2.1 Process Flow ................................................................................................................................... 32
5.2.2 Processing Steps ............................................................................................................................. 33
5.3 Sales Rebates Objects .................................................................................................................................... 33
SAP Channel Program Management by Vistex February 28, 2022

Application Help – Version: 2.0 – Final © 2022 Vistex, Inc. All rights reserved. 3
5.3.1 Master Data ..................................................................................................................................... 33

5.3.3 Agreements ..................................................................................................................................... 35
5.3.4 Matrix ............................................................................................................................................... 37
5.3.5 Evaluations ...................................................................................................................................... 37
5.3.6 Tracking ........................................................................................................................................... 38
5.4 Sales Rebates Processing............................................................................................................................... 39
5.4.1 Participants ...................................................................................................................................... 39
5.4.2 Buckets ............................................................................................................................................ 40
5.4.3 Tracking ........................................................................................................................................... 40
5.4.4 Accrual and Settlement .................................................................................................................... 40
6 Data Objects ........................................................................................................................... 43

6.1 Data Objects Overview .................................................................................................................................... 43
6.1.1 Use Cases ....................................................................................................................................... 43
6.1.2 Data Cleansing Capabilities ............................................................................................................. 43
6.1.3 Data Objects Architecture ................................................................................................................ 44
6.1.4 Processing Steps ............................................................................................................................. 44
6.2 Upload/Download Data Objects ....................................................................................................................... 45
6.2.1 Upload Objects ................................................................................................................................ 45
6.2.2 Download Objects ............................................................................................................................ 45
7 Glossary ................................................................................................................................. 46

1 Introduction
SAP Channel Program Management by Vistex offers an efficient, highly automated approach to managing trade and
channel programs, with sophisticated tools to administer vital processes from start to finish. Advanced reporting tools
provide important insight into program and partner performance, and powerful analytics provide visibility into spend,
effectiveness and ROI, letting you drill down to see the numbers by customer, product, supplier, geography, and
other dimensions. The solution optimizes your programs, maximizes spend effectiveness, minimizes profit leakage,
improves administration efficiency, cuts processing costs, reduces errors, improves cash flow, enhances customer
and partner satisfaction, and, most importantly, increases your profitability. Take control of your trade programs with
an automated, end-to-end solution to manage your inventory, claims, and rebates.
Channel Program Management covers three primary topics: Billbacks, Co-op and MDF, and Sales Rebates.
SAP Channel Program Management by Vistex Documentation, version 20.1 February 28, 2022
2 Application Services
Application services are optional services that provide extended functionality within Channel Program Management.
Application services include data objects, status flow, and the work manager.
2.1 Data Objects
In Channel Program Management, data cleansing is performed using Data Objects. The purpose of data objects is to
provide an intermediate step between receiving raw data from external sources and loading that data into the
appropriate application data tables. Rather than loading the raw data directly into system data tables, the data is first
processed and cleansed 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.
2.2 Status Flow
Status Flow is a flexible tool that enables users to manage various approval processes. Status Flow provides the
ability to:
• Create an approval process for creating or changing agreements or transactions
• Approve or reject documentation
• Change the approval flow from one predefined path to another
2.2.1 Processing Steps
1. The status flow process begins when a 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 initiates a status flow. All steps within
the status flow are initiated by triggers, and these can be configured as necessary.
For example, the default trigger starts the standard flow, but a second trigger in the status profile 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).
3. The first step 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 or 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 the document or transaction is approved, the process continues to the next step of the status flow.
Other outcomes assigned in the flow step will indicate what action will be performed. For example, if the
document or transaction is 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 to do so, the system will generate an activity document for each step in the process to track
communication.
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.

3 Billbacks
3.1 Benefits of Billbacks
Channel Program Management’s Billbacks functionality helps users gain control of billback agreements and increase
profitability by:
• Gaining visibility into which products, distributors, customers and geographies are most profitable
• Validating billbacks with a complete audit trail
• Calculating and accruing billbacks for financial reporting and full profitability analysis
• Recording accruals and billbacks in full compliance with financial regulations
• Reducing claim processing costs, errors, disputes and delays

3.2 Billbacks Process
3.2.1 Process Flow
The Billbacks process includes the following steps:

1. Master Data
Master data needed to process the billback agreement includes partners/participants, products/services, and
general ledger accounts. Master data setup is lean, limited to system-required fields, however custom fields
necessary for the business or industry can be added, as needed. Data can be fed from the system of record
or created within the solution.
2. Billback Agreement
The Billbacks process varies in complexity as it can involve different products, customers, and validity
periods. A supplier might negotiate thousands of agreements including multiple agreements with the same
channel partner or a single agreement that includes multiple channel partners. Or, a supplier might negotiate
a special price with a partner who is also part of a buying group. The application stores and centralizes all of
a supplier's agreements to ensure efficient claim processing and resolution.
Agreement information includes the header, eligibility rules, and relevant benefits/payments. Agreements
can use flexible groups to combine eligibilities and exclusions.
3. Transactions
Transaction documents created in the system provide sales data, invoices, deliveries, and point-of-sale
(POS) data.

4. Claims
The system selects the eligible agreements and applies rules and agreement parameters. After eligibility
and exclusion checks are performed, the amounts are calculated and compared to the claim amount
submitted by the partner. If there are discrepancies, the claim is reconciled.
5. Buckets
Buckets aggregate all of the transactional information for a particular distributor or agreement in order to
offset the amount calculated for the expected accrual. This amount will be paid to distributors when the claim
is settled.
NOTE: Buckets are only necessary for processing expected accruals (see below).
6. Expected Accrual Processing
At this stage, the supplier may calculate and set aside an estimated amount of money (expected accrual) to
provide financial visibility to future incoming claims, without knowing exactly what the claim amount will be.
Source documents for expected accruals can be billing documents (for shipment based expected accruals)
or internal claims (for volume-based expected accruals). Source document line items are mass processed
into calculation line items.
7. Claim Validation
After the channel partner sells products to an end customer, the partner files a claim to recover money from
the supplier per their agreement. The billback reconciliation process can be used to resolve any discrepancy
between the claimed amount and the system-calculated billback amount. After the amount is finalized, a
settlement is created and can be posted.
8. Postings
Financial postings data is posted to the general ledger using an outbound posting document. A file is
generated to send to the financial system of record for posting.
9. Reporting and Analytics
A reporting and analytics tool is included in the solution.
3.3 Billback Objects
3.3.1 Master Data
Master data needed to process the billback agreement includes partners/participants, products/services, and general
ledger accounts. The billbacks process 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 partners, products/services, organizational data, territories, and general ledger accounts.
3.3.1.1 Products
Products in Channel Program Management use limited master data that is received from an external system.
Products are used to set up agreement rules and are included in billback calculations.
3.3.1.2 Partners
The following partner types can be defined in master data:

• Distributor
• End customer

• Channel partner
• Business partner
• Contact person
3.3.1.3 Flexible Groups
In Channel Program Management, 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 X, Y, 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 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 customers
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 a Group Purchasing Organization (GPO).
3.3.2 Source Documents
Claims are typically used as the source documents for billback calculations. Transactions and data objects can also
be used as source documents.
• Claims – Claims provide the necessary information to verify partners' rebate calculations and to ensure
partners receive the amount they are owed based on the agreement terms. Please refer to Claim Validation
for further information.
• 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.
• 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
system files, the data will first be cleansed 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
A billback agreement summarizes the pricing conditions, terms, dates, and other qualifying information for the billback
program. This information includes the billback dollar amount or percentage, eligible distributors and/or end
customers, eligible materials/products, and the eligible sales area(s). 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?
Participants can be specifically assigned or dynamically determined.
• 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.
Each rule in an agreement is date driven. The overall agreement has a validity period, and each rule can have its own
validity period within the overall agreement date range. Rules can be back-dated or future-dated within the overall
agreement dates.
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
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 is a corporate guide/outline that can be reused to set up multiple similar agreements or agreement
requests. For example, a program might be created for a specific promotion that applies to multiple partners. In the
program, predefined prices/discounts are entered (on the Rules tab), ensuring that all agreements created from the
program contain identical prices for the promotion.
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 (on vacation, for example) , the
approvals can be delegated to a predetermined substitute. 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 Accrual Overview
Accrual is the process of recording the expense or posting the expense. The accrual process is performed so the
user can determine their financial position before the actual transfer of funds takes place between themselves and
their channel partners. The accrual provides visibility to payments before they occur. This process helps the user
determine their financial position after all the billback claims are settled.

3.3.4.1 Expected Accruals
Standard accruals are calculated as a fixed percentage of the actual sales to a distributor, based on historical claim
data. For example, 3% might be set aside for all sales to a certain distributor, which could be based on historical
claims from that distributor.
The following types of accruals are provided:
• Expected accruals calculated using a fixed percentage (defined in the agreement rules) on actual sales (or a
sales forecast), but with the ability to easily adjust the accrual amount (due a rate change, for example)
without changing the source document (invoice).
• Expected accruals based on the amount calculated by applying the valid agreement over historical sales
data (or a sales forecast). For example, if 20% of a distributor's sales are historically to a certain customer,
for sales to that distributor apply the customer contract over 20% of the sale.
• Expected accruals are automatically calculated using historical data and data science.
Implementation of Expected Accruals

Expected accruals can be implemented using the following source documents for calculation:
• Shipments to the distributor (internal sales)
• Shipments made by the distributor (point-of-sale information)
• Anticipated volume
Shipments to the Distributor

If the user decides to post accruals based on each shipment to the distributor, then the billing document (customer
invoice) is used as a source document. Source document line items are aggregated and multiplied by the accrual
rate.
Financial postings are carried out against the assigned general ledger accounts for provisional liability and, thus, the
funds are set aside for claims expected in the future.
Shipments made by the Distributor

If the user decides to post accruals based on shipments made by the distributor, the transaction document is created
from the distributor’s POS information. Source document line items are aggregated from various sources and placed
into a bucket. Accrual can then be performed directly in the bucket.
NOTE: Distributor sales can leverage data objects and go directly to the bucket from the data object.
Anticipated Volume
If a user decides to post accruals based on anticipated volume, an internal transaction is created for expected sales.
Accrual can be performed directly on the transaction.
3.3.4.2 Expected Accrual Tracking
Tracking analyzes transactional information to determine if the information is relevant for an expected accrual or for
creating a posting document. Data is aggregated 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.
Tracking Information Sources

Information sources for tracking include:
• Agreements

• Buckets
• Formulas
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
• Billing document
• Delivery
• Purchase document
• Claim
• Transaction document
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.
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. This
notification is sent after the tracking document is created and before payment accruals are performed to provide
source data for posting.
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 (on vacation, for example), the
approvals can be delegated to a predetermined substitute. When responding to the email, comments can be added,
to explain the reason why the document was rejected, for example.
3.3.5 Claims for Billbacks
The billback lifecycle is initiated when two channel partners enter into an agreement for end-customer contract
pricing, markdowns and discounts, or price protection. When the partner submits a claim for cost recoveries, it must
be recorded, validated, and paid. The billback lifecycle takes the perspective of the supplier’s receipt and processing
of the distributor’s claim(s).
Billback claims are used to recoup the difference between the distributor’s initial acquisition price and the actual
agreed upon price for products/services sold to a specific end customer or partner. Claims can also be used to
recover costs from suppliers, to record deductions when the partner short pays an invoice with the claim, and
consequently to resolve disputes when reconciliation takes place.
A claim can be submitted in the following ways:
• Excel spreadsheet or text file
When a partner submits a claim in a flat file (spreadsheet or text file), the file can be uploaded to the user’s
financial system. Claim uploads use a configured document template to create the claim documents from
the uploaded data or can be used to dynamically create the claim document.

• Supplier's website
Claims can be submitted using the user's website by having the channel partner enter all the information
online. After the claim is entered, the partner may also use the website to review the status of the submitted
claim.
• Data objects
The purpose of data objects is to have an intermediate step between receiving a submission of raw data 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 cleansed based on a predefined data model. Clean data then can
be sent to Claims application in a format that the application can understand and use.
NOTE: All of these submission options can go through data objects before entering the Claims application.
• Fax or email
If the partner faxes the claim, then the claim must be created manually.
When a claim is created in the system, the claim is checked to ensure the authenticity of the submitted data. If the
claim contains errors or an invalid material, a rejection reason will be entered on the corresponding line item(s) before
the claim is posted. A posted claim is eligible to be used as a source document for calculation line items. The claim is
further validated to ensure that the claim amounts are correct, and within or outside a configured tolerance.
Approvals
When the person who needs to approve the claim is unavailable (on vacation, for example), the approvals can be
delegated to a predetermined substitute. When responding to the email, comments can be added, to explain the
reason why the claim was rejected, for example.
3.3.6 Transactions
Transaction documents are used to track the user's sales and to import any partner transactional data into the
system. A transaction can be received in a flat file such as an Excel spreadsheet or text file, directly on the user's
website, through electronic data interchange (EDI), by fax, or by email.
A transaction document is used to record internal sales information or to record a partner’s incoming external
transactions in the system. A partner’s original transactions must be recorded exactly as they are received so that the
supplier has a copy of the submitted transactions. A transaction is similar in architecture to a claim; however, a
transaction is more flexible because it allows materials and quantities to be made optional through configuration. A
transaction can be used for sales or purchasing transactions.
Transactions can be transmitted in the following ways:
When a partner submits a transaction as a spreadsheet or text file, the file can be uploaded to the users’
financial system. The transaction can be created using a template, or it can be manually created from the
uploaded data.
• Supplier’s Website
The partner can submit a transaction through the supplier's website by entering all the information online.
After the transaction is entered, the partner may also use the website to review the status of the submitted
transaction.
• Data objects
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 transaction application in a format that the application can
understand and use.

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.
• Fax or email
If the partner faxes the claim, then the claim must be created manually.
3.3.7 Reconciliation
Claim Validation
Claim Validation is used to view multiple claim documents, perform checks and controls, and to resolve discrepancies
between the partner's claim amount and the system calculated amount. As claims are received, claim documents are
created. Claim validation can be performed, and inventory pools may be used to track and validate goods sold into or
within the channel at a wholesaler/distributor/end customer.
Pre-delivered validation checks include duplicate submissions, valid agreement, valid master data, and cross
references (partner, material, unit of measure, and agreement) to compare incoming data with existing data in the
system. Configurable validation checks include incomplete claims, duplicate claim items, pricing discrepancies,
address matching to check whether a customer is in the system, inventory pools, discrepant claims, and evaluations.
In addition, claim validation can include:
• Customer lists to perform checks over a customer group, such as all branches in a state.
• Error notification (status codes, adjustment codes, and rejection reasons) set at the line item level based on
validations.
• Automatically setting posting blocks if a check fails.
The Claim Validation transaction typically is used before settlement.
Various procedures can be performed in Claim Validation, including:
• Displaying Claims
• Mass Changing Claims
• Posting Claims
• Repricing Items
• Reprocessing and Re-exploding Items
• Resubmitting Claims
• Transferring Claim Document items
• Searching and Replacing Claim Data
3.3.8 Posting Overview
Creating posting documents is the final step in settling a claim with a partner. In billbacks, posting information
indicates the cost and profit centers for a particular agreement. Using the information obtained from tracking, the
supplier settles the claim by transferring the billback amount to the partner. 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.

3.3.8.1 Accrual
The accrual process is performed so users can determine their financial position before the actual transfer of the
billback takes place between the supplier and the channel partner. The accrual provides visibility to payments before
they occur and allows you to gauge the difference between the actual funds currently available and those that will be
available after settlement takes place.
3.3.8.2 Settlement
Settlement is the final step in the posting process. Using the information obtained from tracking, the distributor
submits a debit memo to the supplier to obtain their calculated billback amount. The supplier settles the claim by
transferring the agreed-upon billback or claim amount 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 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 partner level to indicate the settlement rules and frequency when Accounts Payable or
Accounts Receivable is used to offset invoices. Date-based parameters can be used to maintain multiple sets of
parameters, each assigned to a different date range. Assigning date ranges allows different parameters to go into
effect as of a certain date; however, parameters cannot be created with overlapping dates.
Parameters defined for a partner can be changed at the agreement level. The agreement parameters always take
precedence over the standard parameters.

4 Co-op and MDF
4.1 Benefits of Co-op and Market Development Fund

(MDF)
The Co-op and MDF topic in Channel Program Management helps the user increase the effectiveness of promotional
allowance programs 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
• Validating and checking all submitted claims against available funds, duplicate submissions, valid
agreements, valid master data, and cross references
• Viewing fund balances and activities to track earnings and payouts across programs
• Allocating funds to products being promoted by channel partners
4.2 Co-op and Market Development Fund (MDF)

Processes
Co-op and MDF programs occur in four different ways:

NOTE: All of these fund processes occur independently of budgeting. For more information on budgeting refer to
Funds topic.
1. In discretionary-fund MDF agreements, the channel partner is provided with a set fund amount paid on a
scheduled basis. Payments can occur up-front with periodic amortization to recognize the expense over
time, or payments can occur periodically (with accrual and settlement being synchronized). Payment can
also occur at the end of a period with periodic accruals along the way. These funds do not use a claim and
are paid on a defined schedule.
2. Earned accrual Co-op agreements give channel partners money based on a per-unit or percentage rate
applied to their purchased volume. These funds do not use a claim and are paid automatically on a specified
schedule.
3. In fixed-fund MDF agreements, the channel partner is provided with a set fund amount. The channel partner
submits a claim for reimbursement for a marketing activity, and the claim is paid from the fund. Users will
check the proof of performance (attachment provided by retailer or confirmation from sales rep or broker)
prior to payout. The availability of sufficient funds is the sole system check for payout.
NOTE: For fixed-fund MDF agreements, the channel partner may have to submit their proposed activity for

pre-approval before the activity occurs or the fund is paid.
4. Variable Co-op agreements allow payout based on a channel partner's purchased volume (percentage of
sales, for example). The supplier accrues into a fund based on sales to the channel partner. The channel
partner submits a claim for reimbursement for a marketing activity, and the claim is paid from the fund.
Users will check the proof of performance (attachment provided by retailer or confirmation from sales
representative or broker) prior to payout. The availability of sufficient funds is the primary system check for
payout. Some clients allow going over the earned fund with the expectation that the fund will eventually
catch up.
NOTE: For variable Co-op agreements, the channel partner may have to submit their proposed activity for
pre-approval before the activity occurs or the fund is paid.

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 on-premise 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.
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
• Reseller
• Distributor
• Retailer
In Channel Program Management, 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 users 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).

4.3.1.5 Membership
The 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.
Typically, the Claim is used as the source document for Co-op and MDF calculations. In some Co-op agreements,
invoices, transactions, and additional sources can be used.
• Claims – Claims provide the necessary information for fixed/discretionary funds, including proof-of-
performance information and details on the promotional activity. Please refer to Claim Validation topic for
further information.
system files, the data will first be processed based on a predefined data model. Clean data then can be
4.3.3 Agreements
Usually, before Co-op and MDF funds are paid out, an agreement is set up between the company and channel
partner 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 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 fund options to change frequently and be modified retroactively.
4.3.3.1 Rules

• What is the expected accrual rate?
Accrual rates can be set based on historical claim values.
• What is the fund amount when the conditions are met?
The fund can either be a fixed or variable amount.
Each rule in an agreement is date-driven. The overall agreement has a validity period, and each rule can have its
own validity period within the overall agreement date range. Rules can be back-dated or future-dated within the
overall agreement dates.
an existing agreement. For Co-op and MDF agreements, agreement requests are submitted by a channel partner
when requesting approval of allocation of funds to be spent on a potential activity or event. The agreement request
allows for one or more levels of approval in an approval process. During an approval process the department, team,
or individual assigned to each level of the approval process must approve the agreement request before the changes
would post to an agreement or before the request is made into a new agreement.
Agreement requests are optional, however, and any changes can be made directly on the agreement itself.
Master Agreements are used to create Co-op and MDF agreements from a list of available promotional activities. To
carry out one of the promotional activities included in the master agreement, channel partners submit an agreement
request to obtain the funds necessary for that activity. The supplier then approves the request to generate an
agreement. When the activity is completed, channel partners submit a claim for the fund amount with proof-of-
performance, and the fund is depleted accordingly.

4.3.3.4 Approvals
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 agreement. When the person who needs to approve the agreement is unavailable (on vacation, for example), the
to explain the reason why the agreement was rejected, for example.
4.3.4 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. For Co-op and MDF agreements, tracking is only applicable to the calculation of the
variable funds.
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.

4.3.4.1 Tracking Information Sources

• Agreements
• Buckets
• Formulas
4.3.4.2 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
• Sales from distributor/channel partner
4.3.4.3 Tracking Simulations
Run simulations to review possible changes to the fund after making entries into eligible fields. For example, by
changing the fund calculation rate users can review the difference in the fund amounts.
4.3.4.4 Tracking Document
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.
4.3.4.5 Approvals

4.3.5 Claims for Co-op and MDF
4.3.5.1 Overview
The Co-op and MDF lifecycles are initiated when two channel partners enter an agreement for a marketing activity.
When a channel partner submits a claim for cost recoveries, it must be recorded validated and paid. The Co-op and
MDF lifecycles take the perspective of the user’s receipt and processing of the channel partner’s claim(s).
Claims are used to disburse funds to channel partners, and to resolve disputes during claim reconciliation. Claims for
marketing activities can be submitted before or after payment.
A claim can be transmitted in the following ways:
When a channel partner submits a claim in flat file (spreadsheet or text file), the file can be uploaded to the
users’ financial system. Claim uploads use a configured document template to create the claim documents
from the uploaded data or can be used to dynamically create the claim document.
• Supplier’s website
The channel partner can submit a claim using the user's website by entering all the information online. After
the claim is entered, the partner may also use the website to review the status of the submitted claim.
• Data objects
model. Clean data then can be sent to Claims application in a format that the application can understand
and use.
NOTE: All of these submission options can go through data objects before entering the Claims application.
• Fax or email
If the channel partner faxes the claim, then the claim must be created manually.
When a claim is created in the system, the claim is checked to ensure the authenticity of the submitted data. If the
claim contains errors or an invalid activity, a rejection reason should be entered on the corresponding line item(s)
before the claim is posted. A posted claim is eligible to be used as a source document for calculation line items. The
claim is further validated to ensure that the claim amounts are correct, and within or outside a configured tolerance.
Calculations are performed to read agreement rules and apply any necessary adjustments to the claim amount.
4.3.5.2 Approvals

4.3.6 Transactions
Transactions are used to bring sales and purchasing information into the system. A transaction can be received in a
flat file such as an Excel spreadsheet or text file, directly on the user's website, through electronic data interchange
(EDI), by fax or email. When the transaction is submitted using a flat file, fax, email, the transaction must be entered
in the user's system.
A transaction document is used to record the partner's incoming sales and purchasing data in the system for any
purpose. When a partner sends in transactions, then those original transactions must be recorded as is in the system.
This is done so that the user has a copy of the original transactions submitted by the partner. A transaction is similar
in architecture to a claim; however, a transaction is more flexible because it allows materials and quantities to be
made optional through configuration. A transaction can be used for sales or purchasing transactions.
Transactions can be transmitted in the following ways:
When a partner submits a transaction as a spreadsheet or text file, the file can be uploaded to the users’
financial system. The transaction can be created using a template, or it can be manually created from the
uploaded data.
• Website
The partner can submit a transaction using the user’s website by entering all the information online. After the
transaction is entered, the partner may also use the website to review the status of the submitted
transaction.
• Data objects
model. Clean data then can be sent to the transaction application in a format that the application can
understand and use. 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.
• Fax or email
If the partner faxes the transaction the transaction must be created manually.
4.3.7 Funds Overview
The purpose of the Funds functionality is to allow suppliers to control the spending and allocation of marketing and
promotional funds. Accrual (or settlement without accrual) is performed against valid funds allocated to the
agreement.
4.3.7.1 Components of Funds
Funds includes the Fund Manager as well as Budgets and various budget statuses. The Budgets process is optional,
and when it is not used, the available fund amount begins in the Released status.
4.3.7.2 Fund Manager
The Fund Manager is where a fund budget is allocated and updated as business needs dictate. Fund balances and
history can also be viewed within this location.

4.3.7.3 Funds
Although budgeting is optional for funds, when it is used the budgeted amount is the starting fund amount available
for a combination of fund elements during a certain period. Key fields define the budget, and budgets are structured
in a hierarchy. For example, users can create a hierarchical budget using partner types, brands, product lines,
regions, channels, etc. within a hierarchy. Each quarter companies could budget an amount for a particular region,
and with smaller amounts budgeted for trade shows and funded head at lower levels in the budget hierarchy.
NOTE: If not using the Budget process, start with the Release process.
Fund Statuses
• Released
If using the budget process, release carries forward the amount from the budget. If not using the budget
process, this is the initial fund amount.
• Open for Releasing
The fund amount open for releasing is the budgeted or initial fund amount minus any funds that have
already been released.
• Reserved
The reserved amount indicates budgeted funds that have not yet been released.
• Open for Reservation
Funds open for reservation indicate the amount of funds released minus any funds already reserved for a
different portion of the budget.
• Earmarked
Earmarked funds display the claim amounts that have not yet been paid.
• Open for Earmarking
Funds open for earmarking indicate the amount of funds set aside to pay claims that have not already been
earmarked.
• Consumed
Consumed denotes the claim amounts that have already been paid.
• Open for Consumption
Funds open for consumption indicate the total claimed amount minus any consumed funds for claims that
were already paid.
4.3.8 Reconciliation
4.3.8.1 Claim Validation
During Claim Validation, the partner’s submitted claim is reviewed to ensure the authenticity of the submitted data. If
the claim contains errors or an invalid marketing activity, a rejection reason can be entered on the corresponding line
item(s). The claim is further validated to ensure that the claim amounts are correct and fall within or outside a
configured tolerance. Calculations are used to read agreement rules and apply any necessary adjustments to the
claim amount.
Other pre-delivered validation checks include duplicate submissions, valid agreement, valid master data, and cross
references (partner, activity, and agreement) to compare the partner’s incoming data with existing data in the system.
Configurable checks include incomplete claims, duplicate claim items, ROI information, inclusion of invoice
attachments for proof-of-performance, pricing discrepancies, discrepant claims, and evaluations.
In addition, claim validation can include:

• Error notification (status codes, adjustment codes, and rejection reasons) set at the line item level based on
validations.
• Automatically setting posting blocks if a check fails.
The Claim Validation typically occurs before settlement.
Various procedures can be performed in Claim Validation, including:
• Displaying Claims
• Mass Changing Claims
• Posting Claims
• Resubmitting Claims
• Transferring Claim Document items
• Searching and Replacing Claim Data
4.3.8.2 Approvals
When the person who needs to approve the claim is unavailable (on vacation, for example), the approvals can be
delegated to a predetermined substitute. When responding to the email, comments can be added, to explain the
reason why the claim was rejected, for example.
4.3.9 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 depleting the fund and transferring this amount to the channel partner.
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.9.1 Accrual
Accrual is the process of recording the expected claim amount. 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 channel partner submits a
claim, the claimed amount is used to deplete the accrual.

4.3.9.2 Settlement Overview
Settlement is the final step in the posting process. Settlement is performed to reflect the fund depletion, and the
transfer of this amount between the company paying from the fund and the partner receiving the fund. This process
completes the financial postings initiated by the accrual. Financial posting data is posted to the general ledger using
an outbound posting document.
4.3.9.3 Parameters
Settlement parameters are set up at the channel partner level to indicate the rules for settlement. For Co-op and
MDF, the partner receiving the fund is considered the channel partner. The settlement parameters defined for the
channel partner 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.
4.3.10 Channel Tracking
4.3.10.1 Channel Tracking Overview
The Channel Tracking topic encompasses all functionality related to partner participation, communications, external
portal, account balance/payment info (Benefit Statement), as well as the global payments. Channel Tracking
streamlines partner experience by:
• Using inventory pools to validate claim pricing and quantities for accuracy
• Processing partner data automatically, including POS, inventory, and claims
• Compiling inventory reports on moving inventory and current inventory status
• Using inventory levels to estimate price protection liabilities and mitigate overpayment of claims
4.3.10.2 Pools
Pools are used to track inventory usage to ensure claims are validated accurately. Specifically, Pools verify a channel
partner's purchased quantity and purchased price against the claimed quantity and price. Pools are configurable with
approval and rejection limits for claim validation, and they provide a total inventory at the partner level. Suppliers can
then reconcile channel inventory using positive or negative adjustment claims.
Pool inventory is controlled at the agreement level (FIFO/LIFO), and inventory can be updated or reported using the
base sales unit. Additional key figures, including Sold-To, Ship-To, Cost, Weight, etc., can also be used with Pools.

4.3.10.3 Process Flow
4.3.10.4 Data Objects
In Channel Program Management, data cleansing is performed using Data Objects. 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.

5 Sales Rebates
5.1 Benefits of Sales Rebates
Sales Rebates functionality provides the ability to streamline sales rebate agreement management by:
• Forecasting, planning, and tracking quantity, percent, and flat tiered volume and growth sales rebates
• Calculating member payments based on buying group behavior and vice versa
• Improving value by incentivizing customer performance with rebates tied to measurable objectives
• Performing midstream evaluation to optimize agreement performance and retroactively recalculate amounts
due
• Communicating payout thresholds to spur additional revenue opportunities with partners
5.2 Sales Rebates Process
5.2.1 Process Flow

The Sales Rebates process includes the following steps:

1. Master Data
Master data needed to calculate the rebate agreement includes partners/participants, products/services, and
general ledger accounts. Master data setup is lean, limited to system-required fields, however custom fields
necessary for your business can be added, as needed. Period profiles are defined to tell the system when to
track or settle. Data either is fed from the system of record or created within the solution.
2. Sales Rebate Agreement
The Sales Rebate process begins with creating a rebate agreement with your partners. Possible agreement
types include: flat (simple percentage or amount), target rebate paid if established targets of
products/services are attained, GPO rebate paid/earned if GPO members buys goods in specified
agreements, or growth rebate paid if a customer exceeds previous year's purchases. In the agreement you
enter the header information, eligibility rules, and benefits/payments. Drivers, which have rules and tracking
attached to them, are used to drive certain behaviors. Flexible groups are used to combine eligibilities and
exclusions. Participants can be added in the agreement.
3. Source Documents
Transactions created in the system provide legacy sales data, distributor sales data, invoices, deliveries,
and POS data.
4. Tracking
The system pulls data from multiple sources to create a tracking document, which is used to view and
approve accumulated data for a partner at a specific point in time.
5. Posting Documents
Financial postings data is posted to the general ledger using an outbound posting document.
6. Reporting and Analytics
A reporting and analytics tool is included in the solution.
5.3 Sales Rebates Objects
5.3.1 Master Data
Sales rebates 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, 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
• Business partner
• Contact person
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 channel partners 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).
5.3.1.4 Membership
The Membership solution 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 channel partners and their subsidiaries, franchises and owner stores, and distributors and branches.
Transactions are typically used as the source document for billback calculations. Claims and data objects can also be
used as source documents.
• Claims – Claims are used as a source to capture the amount paid from the rebate calculation.
system files, the data will first be processed based on a predefined data model. Clean data then can be

5.3.3 Agreements
A sales rebate is paid based on an agreement set up between the company paying the rebate and the customer
receiving the rebate. The agreement summarizes the pricing conditions of the items and the rebate parameters for
the participants. Each agreement can pertain to many customers or just one customer. Agreements can be national,
local or limited to a specific customer location.
Agreements are highly flexible, enabling one or more sales rebate pricing factors that can be defined at any level. Sales
rebate pricing can be specified as a dollar amount or a percentage and can depend on various combinations such as
sales area, customer, material, or a combination of the above. These rules can change frequently and can 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.
5.3.3.1 Rules
Each rule in an agreement is date-driven. The overall agreement has a validity period, and each rule can have its
own validity period within the overall agreement date range. Rules can be back-dated or future-dated within the
overall agreement dates.
5.3.3.2 Drivers
Drivers are assigned to rules to drive behavior of the agreement by defining which components the agreement will
point to. For example, drivers for Sales Rebates might be based on the following:
• Growth
• Revenue
• Shelf Space
• Number of promotions run
• Market share
Within the agreement, drivers are assigned to tracking methods, which control what drivers are shown on the tracking
screen. For example, if Margin and Revenue are drivers assigned to an agreement, Margin can be assigned to one
tracking method and Revenue assigned to another tracking method, or both drivers can be assigned to the same
tracking method

an existing agreement. The agreement request allows for one or more levels of approval in an approval process. The
agreement request must be approved before the changes would post to an agreement or before the request is made
into a new agreement.
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.5 Template Agreements
A program is a corporate guide/outline that can be reused to set up multiple similar agreements or agreement
requests. For example, a program might be created for a specific promotion that applies to multiple partners. In the
program, predefined condition records are entered (on the Rules tab), ensuring that all agreements created from the
program contain identical condition records for the rebate.
5.3.3.6 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.
5.3.3.7 Approvals
Approvals provide a way for management to see and check that the rebate agreement is within corporate guidelines.
Approvals can be triggered based on an agreement type, customer, or amount. For example, the default trigger starts
the agreement. When the person who needs to approve the agreement is unavailable (on vacation, for example), the

to explain the reason why the agreement was rejected, for 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. Different views of the matrix data can be set up
for different audiences. Business-defined functions can be used to maintain matrix data and, for example, to set sales
targets. The solution provides a series of pre-delivered distribution functions, and custom functions can be created.
All historical 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 partners and product lines. A subset could be defined to manage data only for a few partners 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 Evaluations
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:
• Contextual validation
Data complexity can make it difficult to validate whether an agreement is complete and accurate.
Evaluations can perform complex checks and verifications.
• Outcome based contracting:
• Census recording, to enter data collected at customer sites, such as characteristics of the customer's
business or the customer's use of the product sold. This data can be used to determine eligibility or
compliance to agreement terms.
• Compliance checking, to record compliance data, which can be combined with configured system logic
to calculate a compliance score that determines the subjective incentive amount. A button appears on
the screen to rerun the check after the evaluation data is maintained.
• Suitability
An evaluation can be designed as a questionnaire whose answers help select applicable agreements.
5.3.5.1 Evaluation Components
Evaluations consist of the following components:

• Evaluation element, such as textboxes, dropdown menus, and multiple-choice questions.
• Evaluation template used to arrange individual elements and groups of elements into a display view.

• Evaluation type, used to link a template to an object, and define how frequently an evaluation can be
performed. An evaluation type then can be linked to a specific object type (agreement type, for example).
5.3.5.2 Evaluation Document
The system uses data either from evaluations or from an outside system, to create an evaluation document.
Individual evaluation documents can be accessed from the agreement. Data from an evaluation can be displayed in
tracking.
5.3.6 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
tracking method and Revenue assigned to another tracking method, or both drivers can be assigned to the same
tracking method.
More data is available than can be viewed on the screen. Supporting detail is available in a report that can be
accessed from the tracking screen.
5.3.6.1 Tracking Components
One or more user-defined components can be defined to control the individual calculation elements. For Sales
Rebates, examples of components are:
• Revenue
• Volume
• Shelf Space
• Number of promotions run
• Market share
A component, in turn, is a collection of the key figures that are being tracked for the agreement. Key figures such as
guaranteed payments and rank can influence the calculation of rebate amounts. The actual key figures can be
compared against the targets to determine the level of performance achieved.
5.3.6.2 Tracking Information Sources

• Agreements
• Formula calculations
• Matrix
• Aggregation
• Bucket
• Evaluations
Data from calculation documents is aggregated, to consolidate the rules/calculation document data used in tracking.
Data from an evaluation can be displayed in tracking.
5.3.6.3 Tracking Simulations
Run simulations to review possible changes to the payout after making entries into eligible fields. For example, if a
large order is coming into the system and you want to see what the rebate will be after that order is recorded.
5.3.6.4 Tracking Document
accumulated data at a specific point in time for a partner.
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 financial postings, accruals are performed to provide source data for
posting.
Approvals
For example, the final rebate calculation might be reviewed and approved by the manager.
5.4 Sales Rebates Processing
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 deployment code may be customers, channel partners, brokers, agreements, and materials.
Participation can be versioned, allowing users to perform a "what-if" analysis.

Participation Hierarchies
A hierarchy of participants can be created to view root level and lower level participants in a plan. For example, in a
buying group plan, the amount to be paid to the buying group is dependent on the results of directly assigned
distributors.
The participation can be based on the organization structure already in place or can be entered and controlled
directly by user input. If the hierarchy is dedicated to a specific plan, the participant hierarchy is entered manually in
the Participation application. Changes made to a re-usable hierarchy are reflected automatically in all places where
that hierarchy is used.
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
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.
Formulas
Formulas run behind the scenes to calculate complex rebates. Formulas can be assigned at a participant, plan,
component, or subcomponent level.
5.4.4 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.
Accrual and settlement take place at the participant level rather than at the document 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 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.
• Deployment code (not recommended)
Full amount is accrued and settled. No profitability analysis is available.
5.4.4.2 Examples
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
NOTE: When settlement occurs, the formula looks at the agreement and pulls the information before calculation.
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.3 Accrual and Settlement Processing
Accrual and settlement processing are performed using Work Manager.

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
• Channel Partner 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

• 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.

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 application, 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
The version number will default based on the data model.
• 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.
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.

7 Glossary
Term Definition
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 application
processing.
Billback A billback is the process of a supplier validating claims for compensation from one of
its channel partners. It manages the process of a partner "billing back" for expenses
they have incurred on the paying company's behalf.
Bucket Buckets are used to aggregate data from calculations.
Calculation Element Identifies the type of pricing, for example, flat rate, surcharge, percentage, and
discount.
Channel Partner A distributor, retailer or customer who purchases products or services in a business-
to-business (B2B) transaction.
Driver By indicating which deployment code and which deployment code components a rule
points to, drivers determine how rules and agreements will perform and how their
performance is tracked.
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).
Evaluation Element Evaluation elements are individual elements, such as text boxes, dropdown menus,
and multiple-choice questions, that appear in evaluations.
Post Process financial entries for accrual, settlement, or internal settlement.
Settlement Process of paying participants of an agreement, depending on qualifying eligibility
and calculations. Postings are made to Finance GL accounts.
Supplier A manufacturer, vendor or other seller of products or services in a business-to-
business (B2B) transaction.
Transaction Orders, sales traces, and POS information are all examples of transactions, which
are the source documents for billback and rebate processing.


Application Help SAP Channel Program Management by Vistex 2.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Help SAP Channel Program Management by Vistex 2.0

Uploaded by

Copyright:

Available Formats

Application Help Public

Document Version: 2.0 – Final

SAP Channel Program Management by Vistex

2 Application Services .................................................................................................................... 6

4 Co-op and MDF ....................................................................................................................... 19

5 Sales Rebates ......................................................................................................................... 32

SAP Channel Program Management by Vistex February 28, 2022

5.3.1 Master Data ..................................................................................................................................... 33

6 Data Objects ........................................................................................................................... 43

SAP Channel Program Management by Vistex February 28, 2022

2.1 Data Objects

2.2 Status Flow

2.2.1 Processing Steps

1. The status flow process begins when a document requires approval.

SAP Channel Program Management by Vistex February 28, 2022

2.3 Work Manager

SAP Channel Program Management by Vistex February 28, 2022

3.1 Benefits of Billbacks

SAP Channel Program Management by Vistex February 28, 2022

3.2 Billbacks Process

3.2.1 Process Flow

3.2.2 Processing Steps

The Billbacks process includes the following steps:

SAP Channel Program Management by Vistex February 28, 2022

3.3 Billback Objects

3.3.1 Master Data

The following partner types can be defined in master data:

SAP Channel Program Management by Vistex February 28, 2022

3.3.1.3 Flexible Groups

3.3.2 Source Documents

SAP Channel Program Management by Vistex February 28, 2022

3.3.3.2 Agreement Requests

3.3.3.3 Master Agreements

SAP Channel Program Management by Vistex February 28, 2022

3.3.3.4 Template Agreements

3.3.4 Accrual Overview

SAP Channel Program Management by Vistex February 28, 2022

3.3.4.1 Expected Accruals

Implementation of Expected Accruals

Shipments to the Distributor

Shipments made by the Distributor

3.3.4.2 Expected Accrual Tracking

Tracking Information Sources

SAP Channel Program Management by Vistex February 28, 2022

3.3.5 Claims for Billbacks

SAP Channel Program Management by Vistex February 28, 2022

SAP Channel Program Management by Vistex February 28, 2022

3.3.8 Posting Overview

SAP Channel Program Management by Vistex February 28, 2022

SAP Channel Program Management by Vistex February 28, 2022

4 Co-op and MDF

4.1 Benefits of Co-op and Market Development Fund

4.2 Co-op and Market Development Fund (MDF)

Co-op and MDF programs occur in four different ways:

SAP Channel Program Management by Vistex February 28, 2022

pre-approval before the activity occurs or the fund is paid.

SAP Channel Program Management by Vistex February 28, 2022

4.3 Co-op and MDF Objects

4.3.1 Master Data

The following partner types can be defined in master data:

4.3.1.4 Flexible Groups

SAP Channel Program Management by Vistex February 28, 2022

4.3.2 Source Documents

SAP Channel Program Management by Vistex February 28, 2022