RMS Deals Overview Whitepaper 19.0

Oracle Retail Merchandising
System
Deals Overview
February 2020 | Release 19.0

Copyright © 2020, Oracle and/or its affiliates
Disclaimer
This document in any form, software or printed matter, contains proprietary information that is the exclusive property of
Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle software
license and service agreement, which has been executed and with which you agree to comply. This document and
information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without
prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any
contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation
and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and
should not be relied upon in making purchasing decisions. The development, release, and timing of any features or
functionality described in this document remains at the sole discretion of Oracle.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this document
without risking significant destabilization of the code.
.
1 Deals Overview Release 19.0

TABLE OF CONTENTS
Disclaimer 1
Overview 3
Introduction 3
Business Rationale 3
Merchandising Deal Management 3
Off Invoice Deal 3
PO Specific Deal 3
Bill Back Deal 4
Bill Back Rebate (BBR) Deal 4
Vendor Funded Promotion (VFP) 4
Vendor Funded Markdown (VFM) 5
Fixed Deal 5
Deal Definition 6
Manual Deal Entry 6
Deal Head 6
Bill Back 8
Financials 10
Comments 12
Deal Components 12
Buy/Get Item Details 15
Item/Locations 16
Thresholds 17
Revisions 17
More Actions 18
Batch Deal Entry 19
Future Cost Calculation 20

Off Invoice Deal Application 21
Income Calculations 22
Bill Back and Bill Back Rebate Income Calculation 22
Deal Performance Screen 23
Amount threshold limit and amount off unit threshold value 29
Number of Units threshold limit and percentage off threshold value 29
Item Location Income Distribution 32
Skipping a Threshold 33
Fixed Total Calculation 34
VFP Income Calculation 34
VFM Income Calculation 34
Editing Approved Deals 36

Editing Deal Income 36
Editing Thresholds 37

Overview
Introduction
A deal is a set of one or more agreements that take place between the retailer and a vendor. A vendor can be an active
supplier, wholesaler, distributor or manufacturer, and from the vendor, the retailer is entitled to receive discounts or rebates
for goods that are either purchased or sold. A deal consists of a set of discounts and/or rebates that are negotiated with the
supplier and share a common start and end date.
Deals can cover a specified period of time. For example, a special deal might be set up based on a promotion or have an
open-ended timeframe (such as when a retailer might get 5% off on all merchandise ordered from a specific supplier).
After a deal has been successfully negotiated, it needs to be defined within Merchandising in order to have discounts on
purchase orders applied or in order to recover rebates from the supplier. This deal definition is carried out in terms of its
components, which include the following: item/locations, thresholds, discounts and funding percentages. Once this setup is
complete, the deal can be approved.
Updates in this Version of the Paper

 Updated workflow for Vendor Funded Promotion (VFP) and Vendor Funded Markdown (VFM)
Business Rationale
The following points summarize the business principles that support the creation of deals:
 Suppliers propagate deals based on sale volumes and offer discounts to retailers as incentives in order to maintain a
constant need for their products.
 The sale of “slow-moving” goods can be catalyzed by vendor funded promotions and markdowns which involve both
the supplier as well as the retailer. In the grocery segment, nearly every promotion that the consumer sees is driven by a
deal from a vendor.
 Deals can incentivize bulk buying.
 Product launches accompanied by deals can increase their success probability.
Merchandising Deal Management

Within Merchandising, the user can create the types of deals described in this section.
Off Invoice Deal

This type of a deal is set up between a retailer and a vendor where the retailer is provided a discount on purchase orders
raised with the vendor when certain threshold criteria are met by the purchase order. The discount amount gets directly
deducted from the cost of the item present in the order, and the retailer is required to pay only the discounted cost. The
immediate reduction in the weighted average cost (WAC) and carrying cost for the merchandise makes this type of a deal
much more measurable and less complicated from an operation standpoint.
Deals that are set up for a manufacturer, distributor or wholesaler can be applied for a supplier-level purchase order (PO) as
long as the supplier is linked to the manufacturer, distributor or wholesaler as a hierarchy level at the item/supplier/country
level for items on the order.
While creating a PO manually within Merchandising, there is an option provided to the user to select whether any deals
relevant to the order should be applied immediately online or offline by the batch process. For orders originating from an
automated process such as replenishment or through integration from an external application, an offline batch process is
used post order approval.
PO Specific Deal
In addition to annual and promotional deals, a supplier might also offer certain deals which are specific to a purchase order.
This type of a ‘PO Specific Deal’ can be set up within Merchandising using an option that is available in the PO item setup
screen. For such a deal, the ‘Deal Timing’ gets populated with ‘PO Specific’, and the order number gets auto-populated. Only
a single PO specific deal can be attached to a purchase order, and this will always be applied last in the sequence when
calculating the deal totals.

PO specific deals take other annual and promotional deals into account only if they are not exclusive. The calculation for the
discount is then based on whether the PO specific deal was set up as cascade, cumulative or exclusive.
Note: These deals get purged with the PO to which they are linked, rather than the deal
purge process.
The table below gives a detailed view of the impact of other deal types in a setup having PO-specific deals.
Case # PO Specific Deal Components Impact
1 Transaction Level - Cumulative Other deals can be applied to a PO in addition to

only a PO specific deal
2 Transaction Level - Cascade Other deals can be applied to a PO in addition to

only a PO specific deal
3 Transaction Level - Exclusive Exclusive – No other deals included

only
4 Multiple Transaction Level – Other deals can be applied to a PO in addition to

a PO specific deal
Cumulative and Cascade deals
Bill Back Deal

This type of a deal is based on an agreement with a supplier or partner over a fixed or variable duration and has one or more
components comprising of merchandise items, locations, thresholds and discounts. The deal definition captures the
different thresholds that are set up for the items/locations present in the deal and the related discounts that the retailer is
eligible to receive on successfully meeting the thresholds.
The thresholds can be based on either purchases or receipts. A regular Bill Back compares each purchase event against the
threshold individually, whereas receipts are compared in the aggregated form.
Bill Back Rebate (BBR) Deal

Bill back rebate deals are similar to the bill back deals described above, but these aggregate all the events and compare them
against the thresholds in the aggregated form. Furthermore, bill back rebate thresholds can be based on sales in addition to
purchases or receipts.
Vendor Funded Promotion (VFP)

In order to reduce outstanding inventory or compete against another retailer during certain periods of the year, a retailer
may institute a temporary price reduction by creating a promotion in Oracle Retail Pricing. To keep profit margins intact, the
retailer often negotiates a deal with the supplier wherein the supplier funds part or the entire promotion. This type of vendor
funding is created as a Vendor Funded Promotion (VFP) within the Merchandising system.
While setting up the deal, the user can link the one or more promotions and specify the contribution percentage of the
vendor for each of them. These promotions need to have their start and end dates within the deal timeframe and at least
one offer that is not in the Completed or Cancelled status. The promotion can also be created at a later point when a formal
plan has been built and then attached to the deal. After setting up the above information, the deal can be approved within
Merchandising for income generation. Merchandising drives the entire creation and invoicing logic for this deal type.

Note
 Merchandising does not allow the user to enter budgeted or forecasted values, and
the deal income is based on the vendor-supplied contribution percentage.
 Two types of promotions can be attached to a deal. One is referential only (accessed
via More Actions) while the other generates income (accessed through the
Promotion button). It is possible to view the attached promotions and promotion
components that have been attached. However, these values are controlled by
Pricing and no addition/deletion is possible from the Merchandising end. Further,
the existence of a promotion on the screen is not enough to guarantee that income
will be generated. The system only gives an indication of all the promotions and
contribution percentages that the buyer thought would be assigned to the deal
when the promotion is approved.
 VFP deals can be uploaded using the batch upload process without promotion
details but income will get generated only after one or more promotions are linked
to the deal manually.
Vendor Funded Markdown (VFM)

Similar to a VFP, a Vendor Funded Markdown (VFM) can be used if a vendor agrees to fund a specific percentage of the
markdown. The vendor can support the retailer either by contributing a percentage of the retail price discount for each item
on hand or by giving a fixed amount for all the items that still remain in stock. In such scenarios, integration between the
regular or clearance price changes (in Pricing) and VFM deals (within Merchandising) is essential.
While setting up the deal, the user can define a contribution value or percentage against each component. For values, the
amount that is specified will be considered in terms of the currency selected for the specific deal. The user defined values for
vendor contribution will be held with the deal even after it is exploded to the item/location level. When a price change or
clearance markdown goes active on its effective date within Pricing and it executes a markdown within Merchandising, the
backend processing will analyze all active VFM deals in order to identify any item/location combination impacted by the
markdown and record income generated. Any price reduction based on a clearance or a price change would be considered.
Fixed Deal
Fixed deals allow the user to capture ‘one-off’ payments or a series of payments from a vendor to the retailer. This type of
deal caters to certain business setups that require the vendor to give the buyer a fixed amount of money in return for
advertising their products for promotional reasons, for in-store demonstrations, or for displaying their merchandise in prime
shelf space. A fixed deal comes with a defined amount, duration, billing frequency, and invoicing method. There is built-in
logic to auto-generate billing requests for such amounts based on the billing frequency.
For all the above types of deals, there are screens dedicated to creation and maintenance. Additionally, new deals or
modifications to existing deals can also be received through a batch upload process. Once the deals are approved and
active, they can be applied to purchase orders and/or used to accrue income. The income that is accrued gets sent to
Invoice Matching for generating the invoice. Additionally, Merchandising calculates the impact of the off invoice, bill back
(BB) and bill back rebate (BBR) deals on the future cost of items. This future cost information is used for margin calculations.

Deal Definition
For users setting up Off Invoice, Bill Back, Bill Back Rebate, VFM and VFP type of deals, this section provides a brief
description of the procedure that needs to be followed and some important parameters that need to be specified. Fixed
deals’ setup is covered in detail in a separate section that follows.
A deal can be defined by the user either through online access of the Deals Management forms within Merchandising or by
uploading the deal details into the system via a batch process. In either case, the deals are entered in the system in the
“Worksheet” status and must be approved within Merchandising before they can be processed or applied.
There might also be certain deals exclusive to a purchase order (PO). Such PO-specific deals are entered and edited using
the purchase order forms within Merchandising, and these can only be viewed in the deal maintenance dialog.
Manual Deal Entry

A series of online screens allows the user to create a deal, define its main components and add the proof of performance
(POP) terms, where applicable. Deals can be created from scratch or copied from an existing one. When created from
existing, the user selects an existing deal which is to be copied and the system creates a new deal using the items, locations
and general deal setup information from the existing one.
This section covers the important fields that are provided by the user or populated by the system based on user inputs,
while performing a manual deal definition.
Deal Head
Deal ID
A unique deal identifier gets assigned to every new deal by the system, and this value cannot be edited by the user.
Status
This field is used to capture the specific state of the deal within the workflow. Available options include the following:
 Worksheet (W): Initial status associated with a deal while it is still being defined.
 Submitted (S): Deal assigned to the approval authority.
 Approved (A): Deal has been approved and can get applied to relevant transactions (sale, PO or receipt) based on the
deal definition.
 Rejected (R): The deal has been rejected by the approver and is not valid for application.
 Closed (C): The deal has reached its close date and is no longer valid.
Deal Timing
A timeframe needs to be defined that addresses when a deal is active. This step helps the system determine the exact set of
deals that needs to get applied during the processing of an order or an invoice. The following options are valid for the timing
of a deal:
 Promotional (P): Deals that are applicable for a specific time frame only are created as ‘Promotional’. In such a scenario,
a ‘Close Date’ needs to be defined on which the deal would get closed automatically.
 Annual (A): On the other hand, a retailer might want to have an annual deal with a partner. In such a case, no close date
is required, and the deal can be manually closed by the user or get automatically closed on creation of a new deal for the
same partner.
Note: On selection of ‘Annual’, the Billing Type gets defaulted to ‘Off invoice’, and the field is
disabled since this is the only possible type of annual deal.

Active and Close Dates
Active Date
The active date is set to the day from which the deal will start being applied within the system. This date may be before the
current date. However, the system does not go back and calculate income based on past orders, receipts or sales for Bill
Backs and Bill Back Rebates. Only off-invoice deals support a process of recalculating orders which have been approved
prior to the deal creation but are within the active date set in the deal definition.
Close Date
The close date is the last day of the deal. As noted above, this is required only for promotional deals.
As long as the deal is in the “Worksheet” status, the user can modify the active and close dates. If the income reporting
periods for the deal have already been created, there will be new periods added or removed based on the date modification.
After a deal has been approved, only its close date can be modified. If needed, any reporting periods are deleted based on
this date modification. However, the close date of a deal cannot be moved before the current date.
Billing Type
This field is used to define the type of deal being created. As described above, the valid options for billing type are: Off
Invoice, Bill Back, Bill Back Rebate, Vendor Funded Promotion or Vendor Funded Markdown.
Vendor
This field is used to hold the supplier, manufacturer, wholesaler or distributor details with which the deal was created. For
the vendor type of supplier, the supplier must be in the active status for selection. All supplier sites for the selected supplier
are covered by the deal. Deals cannot be set up within Merchandising at the supplier site level, regardless of whether the
system is configured for supplier sites. However, because costs are maintained at the supplier-site level, the deal data is
exploded to that level, and final deal income is posted at the supplier site level.
Deals that are set up for a manufacturer, distributor or wholesaler can be applied for a supplier level PO as long as the
supplier is linked to the manufacturer, distributor or wholesaler as a hierarchy level at the item/supplier/country level.
Currency
The deal currency defaults to the primary currency of the vendor but can be modified.
Threshold Limit Type and UOM

Certain deal types such as Off Invoice and Bill Backs allow the tracking of the threshold limit in terms of units or an amount.
If units are selected, the user also has to define the Unit of Measure (UOM) that the threshold tracks. This can be any UOM
that can be defined within Merchandising.
Items that are added to the deal must have a logical relationship to the threshold limit for correct conversion and deal
application. For example, it would be incorrect to have a threshold limit expressed in liters when the deal is for meat ordered
in pounds. This does not get enforced by the system and would need to be taken care of manually during the setup.
For ‘PO Specific’ deals, if the Transaction Level Discount is set to ‘Y’, the threshold limit type is always ‘Amount’, to represent
the total monetary amount of the order.
Note: Thresholds do not apply for VFP and VFM.
Recalculate Approved Orders

This indicates whether approved orders should be recalculated based on the current deal parameters and applies only in
case of an off-invoice deal. If this is checked, any approved order currently in the system that meets the deal criteria is
recalculated based on the new deal once it is approved.
Order No.
This field gets populated with the Merchandising order number for a PO specific deal.

Security
This indicator can be used to implement user-based security for the deal that is currently being created. In case this has
been set for a deal, the deal details can be viewed or edited only by users who have the same or higher privileges compared
to the deal creator. For example, if the user who created the deal can create deals for class A, which is in department B, then
only those who have security privileges to allow for creating or updating deals in class A or department B or another level of
the hierarchy above department B can update the deal.
Bill Back
This container is enabled for VFP, VFM, Bill Back and Bill Back Rebate type deals. It holds all the reporting level information
along with the rebate information applicable for the bill back deal.
Deal Reporting Level

The deal reporting level determines the length of the reporting periods that would be created for income generation. The
options provided to the user depend on the calendar type that is being used in the Merchandising instance. For a 4-5-4
calendar, this can be “Week”, “Month” or “Quarter”, while for a Gregorian calendar, only “Month” or “Quarter” can be
selected. Income is calculated once per reporting period. The reporting level also indicates the maximum frequency at which
an invoice is raised against the income accrued by the deal.
If quarterly processing is chosen, based on the end date for the deal, Merchandising may change the date of the final
reporting period to an end of month date instead, if the end of the quarter is more than a month away, to allow for faster
income realization. For example, if the end date of the deal is set for 17-Jan, but the end of the quarter is 30-Mar,
Merchandising changes the last reporting period to 26-Jan, which is the nearest end of month date.
Note: The Deal Reporting Level is the only attribute on this container that is applicable for
VFM and VFP.
Growth Rebate Indicator

The Growth Rebate information is available only for Bill Back Rebate deals and is for informational/reporting purposes.
Selecting this indicator enables the ‘Historical Period’ fields and allows a buyer to set up a growth rebate deal by looking up
prior receipt or sales values in the data warehouse system. The growth percentage can then be manually applied to these
values to come up with thresholds that would be applicable for the current deal.
Pack Level Tracking

For receipt-based Bill Back (BB) and receipt or sales-based Bill Back Rebate (BBR) deals, the indicator for tracking the deal at
the pack level is enabled. Checking this indicator generates income for purchase orders which involve receiving at the pack
level or sales occurring at the pack level and the same can be sent to the invoicing system.
Purchases and Sales Based

BB Deals are always based on purchases, while BBR deals can be based on either purchases or sales.
Deal Application Timing

The options for Deal Application Timing depend on whether the deal is purchase or sales based. Purchase-based deals can
have this set to the ‘PO Approval’ or ‘Receiving’ timing. Purchase based deals with PO approval application timing look at the
approval date of each order to determine whether it is applicable. Receipt timed deals on the other hand are based on the
date of the receipt and are adjusted for Returns to Vendor (RTVs) and Receiver Unit and Cost Adjustments. For both receipt
and purchases-based deals, income is calculated based on the invoice cost, which includes any off-invoice deals.

Sales based deals do not have timing specified since they are driven by sales records and are applied only when a sale
occurs. Sales timed deals monitor VAT exclusive sales transactions and subtract returns. Income for sales-based deals is
calculated on the retail price of the item sold and is only available for Rebate deals.
Add Deal Reporting Days

This is used to capture the number of extra reporting days that should be added to the Deal actual forecast data to cater to
the late postings of the transactions after the deal close date. These days are added after the deal close date and further
reporting periods are added in order to accommodate these within the deal life-cycle.
Rebate Calculation Type

This field determines the method in which the comparison of thresholds is performed against the actual turnover figures.
Here the term ‘turnover’ refers to the total revenue generated for a period across the merchandise hierarchy for which the
deal is applicable. This is defaulted to ‘Linear’ and disabled for a BB deal, while for a BBR, the user can set it to ‘Linear’ or
‘Scalar’.
A “linear” calculation type applies the achieved threshold value against the entire applicable turnover. Consider the following
example where the income calculation for the entire turnover of $2,500 is performed on the basis of the higher threshold of
20%.
Linear Threshold
LOWER UPPER VALUE
$ 1,000.00 $ 2,000.00 10%
$ 2,000.01 $ 3,000.00 20%
TURNOVER INCOME
$ 2,500.00 (2500 - 1000) * 20% = $300
Total Income = $300

A “scalar” deal applies each threshold to the corresponding value in the threshold limit as described in the example below.
Here for a $2500 turnover, the income generation for $2000 is performed on the basis of the first threshold of 10%, and for
the remaining $500 is performed on the basis of the second threshold of 20%.
Scalar Threshold
LOWER UPPER VALUE
$1,000.00 $2,000.00 10%
$2,000.01 $3,000.00 20%
TURNOVER INCOME
$2,500.00 (2000 - 1000) * 10% = $100
(2500 - 2000.01) * 20% = $100
Total Income = $200
Financials
The information on this container determines the manner in which invoices are to be raised for VFM, VFP, Bill Back and Bill
Back Rebate deals. This information also controls whether the Stock Ledger is affected and whether VAT is included in the
deal.
Bill Back Period

This period determines how frequently the vendor is billed and needs to be at least as large as the reporting period because
income calculation is performed only at the end of a reporting period. For the 4-5-4 calendar, the choices for the invoice
periods are: Week, Month, Quarter, Half Year or Annual. The same choices apply for Gregorian calendar, except “Week”. This
field remains editable until the first invoice has been raised against the deal.
Billing Vendor
This field indicates the vendor to be billed for the specific deal, which can be different from the vendor specified for the deal
in Deal Head. This difference may be in cases where the supplier delivering goods is not the supplier that needs to be billed,
such as a manufacturer who uses regional suppliers and is sponsoring a deal in one region. In this case, the supplier whose
receipts would be tracked is the regional supplier, but the manufacturer is the entity that is invoiced. This field remains
editable until the first invoice has been raised against the deal.
Invoice Dates
Estimated next invoice date

The Estimated next invoice date gets populated initially based on the Bill Back period. It takes the last day of the period that
will be invoiced. After the invoicing batch program Vendor Deal Invoicing (vendinvc) runs, this date is updated with a
Gregorian week, month, or quarter, or the 4-5-4 week setup based on the calendar configuration in the system. This date
can be modified throughout the deal’s lifetime, even after approval until the last invoice against the deal has been
processed.

Last Invoice date
This field is updated to hold the last reporting period that was invoiced.
Invoicing Information
Bill Back Method

This indicates whether invoices raised for this deal are in the form of a credit note or a debit note. The option selected here
overwrites the supplier’s default setup in Invoice Matching. This field remains editable until the last invoice against the deal
has been processed.
Deal Income Calculation

For BB and BBR types of deals, the user has the option of calculating the deal income based on the actual values earned
until the current date, or of using the method of proration on the forecasted amount. There are certain examples around
proration in this document’s Income Calculations chapter. However, in case of VFP and VFM, the only option is to calculate
based on the actual earned values.
Invoice Processing Logic

This defines how invoices will be raised for this deal. The user has the following options available in the case of BB and BBR
type of deals:
 Automatic All Values - This creates debit memos, credit notes, or credit note requests in the Approved status in Invoice
Matching regardless of the claim amount being positive (the deal has earned income during the billing period) or
negative (the deal has generated a loss during the billing period). The debit memos flow automatically to Accounts
Payable for deducting or crediting payment. The credit note requests (CNR) are sent automatically through the EDI
process to the vendor provided they are configured appropriately.
 Manual All Values - Debit memos, credit notes or credit note requests get created in the Submitted status in Invoice
Matching regardless of the claim amount’s being positive or negative. Once these get approved in Invoice Matching, the
above process follows.
 Automatic Positive Values Only - This creates debit memos or credit note requests in the Approved status in Invoice
Matching, provided the claim amount is positive. If the claim amount is negative, it is written to the General Ledger via
Transaction Data (TRAN_DATA) but not sent to Invoice Matching.
 Manual Positive Values Only - Debit memos or credit note requests are created in the Submitted status in Invoice
Matching, provided the claim amount is positive. If the claim amount is negative, it is written to the General Ledger but
not sent to Invoice Matching.
 No Invoice Processing - This will not have claims staged for Invoice Matching, though they will post income or loss to
the General Ledger.
For a VFP or VFM type of deal, the user only has the options of ‘Automatic All Values’ and ‘Manual All Values’ for invoice
processing.
This field remains editable until the first invoice has been raised against the deal.
Note: This dropdown will be enabled only for supplier-based deals, and not the ones linked
with the other partner types such as distributor, manufacturer, and so on.
Below is an example of how invoicing would work if the Invoice Processing logic was set to ‘Automatic Positive Values Only’.
Period Process Quantity Income Reported Value
Week 1 Receive 800 $80 Supplier is invoiced for the $80 income
Week 2 Return 600 -$60 Invoicing process is skipped because of a

negative income
Week 3 Receive 200 $20 Invoicing process is skipped because the

cumulative income is still negative

Period Process Quantity Income Reported Value
(-$60 + $20 = -$40)
Week 4 Receive 1500 $150 Supplier is invoiced for an income of $110 (-

$60 + $20 + $150)
Deal Income in Stock Ledger

This checkbox indicates whether the deal income is posted to the Stock Ledger in addition to the General Ledger. Deal
Income – Sales (transaction code 6) rolls up all income for sales-based deals, while the Deal Income – Purchases (transaction
code 7) rolls up all purchases-based income. The Stock Ledger only aggregates these two transaction codes. However, this
does not affect the opening or closing stock, nor does it influence any Stock Ledger calculations. This checkbox can be
edited until the first Stock Ledger and General Ledger transactions are written.
Include VAT
In a VAT ON environment, if this indicator is selected, it will add the Value Added Tax (VAT) code and rate to the invoice
staging tables. The applicable VAT amount would be selected for each individual item and location, based on the VAT
Region of the location and the VAT rate that is active on the date that the invoice is raised. Using this information, Invoice
Matching calculates the appropriate VAT amount. This field remains editable until the first invoice has been raised against
the deal.
Comments
The field in this container can be used to add any referential data or comments for a specific deal.
Deal Components
After defining the header level details, the user must specify one or more components within the deal. Multiple components
can be added to help distribute the discount amount provided by the vendor. The discount amount can be spread across the
individual line items based on user defined ratios.
Once the components have been defined, the income generated against each component as well as the total income that
gets generated can be monitored within the Deal Income screen.
1. Component: A system defined sequence that is used to track the components added to the deal.
2. Display Order: Indicates the order in which the deal components should be displayed in the Deal Maintenance screen.
This also determines the order in which deal components are applied as part of deal calculations for Off Invoice deals,
but the same does not hold true for Bill Back and Bill Back Rebate types of deals.
3. Type: This field is for informational purpose only as a way to describe the component. Deal component types are user
defined and held on the DEAL_COMP_TYPE table. There is no screen within Merchandising from which this table is
populated; it must be populated via a database script. This is the only piece of information that is specified for a VFM
deal at the component level.
4. Threshold Value Type: This field is used to capture the incentive type that would be received on attaining the
threshold limit of the deal. This can be any of the following:

a. Amount Off -Indicates that the discount or income generated by this deal component is based on an amount off
per unit based on the thresholds defined for the deal component.
b. Percentage Off per unit -Indicates that the discount or income generated by this deal component will be based on a
percent off per unit based on the thresholds defined for the deal component.
c. Get Units for Fixed Price -Indicates that a specified discounted cost will be paid for each item on meeting the deal
threshold. This is applicable only for off invoice deals.
d. Buy/Get Free or Discounted Items -This is applicable only for off invoice deals. If this category of threshold value
type is selected, the retailer would be eligible to get certain items free or discounted based on purchasing certain
items. In this case, if the ‘threshold buy quantity’ on a target item is exceeded, the retailer would receive another
item, termed as the ‘get’ item, either free or at an amount/percentage off or at a fixed price.
On selection of this option, additional information needs to be added for the deal, such as defining the ‘buy’ and ‘get’
items, along with the threshold buy target and the quantity to be received. The screen below is used to capture the
details of the buy/get items.
Note: If the bonus stock item is not on an order when the deal is applied, it is not
automatically added. It needs to be done manually.
5. Deal Class: This indicates the way in which calculations would be performed in case of multiple deal components. In a
situation where the deal class is not specified, it is treated as cascade and follows the calculation logic explained below.
a. Cumulative - In this case, the discounts are added together and then applied to arrive at the final discounted unit
cost.
For example, if the unit cost of an item is $100 and there are three discounts of 2%, 5% and 10%
applicable.
Total cumulative discount = 2% + 5% + 10% = 17%
Discounted unit cost = $100 – (17% of $100) = $83
This is applicable for all Off-Invoice Deals. Bill Back and Bill Back Rebate deals also work in the
cumulative mode, but these get applied against the Net Cost.
b. Cascade - In a cascade scenario, each discount gets applied to the result of the previous discount. As discussed
above, each BB deal component is calculated on top of the off-invoice cost. BB deals are never applied one after
another but rather all are applied against the Net Cost. For this reason, the class of a Bill Back deal cannot be
cascade. The class of a Bill Back Rebate deal will however be defaulted to cascade against the Dead Net Cost.
Consider the same example where the unit cost of the item is $100, and it has three discounts of 2%, 5%
and 10% applicable.
Using the cumulative method, the Total discount = $100 – (2% of $100) – (5% of $100) – (10% of $100)
Discounted unit cost = 100 – 2 – 5 – 10 = $83
For off invoice deals, the order in which cascaded discounts are applied is defined at the system level,
where it can be specified if annual or promotional deals should be applied first or if older or newer deals
should be applied first. The system options DEAL_TYPE_PRIORITY and DEAL_AGE_PRIORITY guide
the process and determine how deals are applied in relation to each other.
Within a deal, the component application order is maintained so that it is clear which discount should be
taken first.
Consider the same example where the unit cost of the item is $100 and it has three discounts of 2%, 5%
and 10% applicable.
Using the cascade method, the Total discount = ((Unit cost - 2%) - 5%) - 10%.
Discounted unit cost = $100 – (2% of $100) = $98.00
$ 98 – (5% of $98) = $93.10
$ 93.10 – (10% of $93.10) = $83.79
c. Exclusive - This is used when a special promotional discount has been negotiated with the partner that overrides
all the other deals. It should be noted that only a single ‘exclusive’ discount can be applied to an item at a time and
priority is given to the lowest merchandise level. For example, in the case of a discount at the department as well as
the subclass level, the one at the subclass level gets precedence, and the discounted unit cost would be calculated
accordingly. Exclusive is applicable for off invoice and Bill Back Rebate deals.
Consider the case where the unit cost of the item is $100 and having three discounts of 2%, 5% and 10%
applicable. Out of these, 10% is the exclusive discount.
Total Discount = Unit cost - 10% (Exclusive discount).
Discounted unit cost = $100 – (10% of $100) = $90
6. Cost Apply Type: Every deal can be considered for the calculation of an estimated future cost value for the item(s)
involved in it. The ‘Cost Apply Type’ field indicates whether the deal component impacts the Net Cost, Net-Net Cost or
Dead Net Cost on the FUTURE_COST table. The Appendix section of this document provides the definitions of these
different cost types.
Note: Merchandising currently assumes that there is no overlapping in the set up of BB deals
and BBR deals for the application of the future cost. As long as BBs and BBRs are not active
at the same time, Net-Net Cost and Dead Net-Net Cost are calculated correctly on top of the
Off-Invoice cost.
7. Transaction Level Discount: This indicator applies to PO Specific off invoice deals. If this checkbox is checked on the
screen, the deal component applies to an entire PO, receipt or sale transaction. This field can only be checked if the
vendor is a supplier (because other vendor types cannot be assumed for all items on an order). Because these deals
apply to the entire order, items and locations are not added to transaction level deals.
8. Calculate Income from Zero Threshold: This indicator is used in cases where the vendor has specified that a minimum
threshold needs to be reached before a discount applies and when that threshold is reached, the discount applies
against the entire threshold, including the level below the threshold.
For example, let the lowest level threshold indicate that if 100-1000 units are purchased, a discount of 10% will apply.
Here, if this indicator is set to ‘Y’ and if 120 units were purchased; the discount would apply to all 120 units on the order.
If it is set to ‘N’, then a purchase of 120 units would only have the discount applying to (120-100) = 20 units.
Note: This flag is not applicable for off invoice deals.
9. Deal in Price Cost: This indicator defines whether the deal is to be used in the pricing cost calculation used by Pricing to
determine the margin on the items linked with the deal.
10. Default Contribution %: This percentage is for VFP only and is used to set the initial default contribution of the vendor
towards the promotion when the deal is attached to a promotion or markdown in RPM. After the initial setup within
Merchandising, this value is maintained within Pricing only. Any change made to the initial value will not be
communicated back to Merchandising.

Buy/Get Item Details
While defining the deal component, if the Threshold Value Type is selected as ‘Buy/Get Free or Discounted Items’ then
there is additional information that needs to be specified for details of the buy/get items in the screen shown below.
This screen has different section for Buy and Get items to capture following respective information.
1. Buy Item: This identifies the item that must be purchased over the threshold quantity to get the specified item either
free or at an amount/percentage off or at a fixed price. This field is always required when Threshold Value Type is
selected as ‘Buy/Get Free or Discounted Items’.
2. Threshold Target Buy Item Quantity: This identifies the quantity of the threshold buy item that must be ordered to
qualify for the free item. This field is always required when Threshold Value Type is selected as ‘Buy/Get Free or
Discounted Items’.
3. Threshold Purchase Order Quantity: This indicates the targeted purchase quantity for all locations on a purchase
order. This is the target level that is used for the calculation of net future cost. This field is always required when
Threshold Value Type is selected as ‘Buy/Get Free or Discounted Items’.
4. Threshold Location Quantity: This indicates the average targeted purchase quantity per location on the deal. This
value is used in future cost calculations. This field is always required when Threshold Value Type is selected as ‘Buy/Get
Free or Discounted Items’.
5. Recurring for All Buy Quantity: This indicates if the quantity threshold discount is only for the first buy amount
purchased (for example, for the first 10 purchased, get 1 free), or if a free item will be given for every multiple of the buy
amount purchased on the order (for example, for each 10 purchased, get 1 free). This value is required for quantity
threshold-type discounts with a get type of free. Valid values are Y for yes or N for no.
6. Get Type: This identifies the type of the get discount for a buy/get discount. Valid values include Free – get units free,
Percent – get units a % off cost, Amount – get units at amount off cost and Fixed Amount – get units for fixed price.
They are held on the codes table under code type of DQGT. This field is always required when Threshold Value Type is
selected as ‘Buy/Get Free or Discounted Items’.
7. Get Item: This identifies the item which the retailer gets on purchase of buy item over the threshold quantity either free
or at an amount/percentage off or at a fixed price. This field is always required when Threshold Value Type is selected
as ‘Buy/Get Free or Discounted Items’. If the get item is not on an order when the deal is applied, it is not automatically
added. It needs to be done manually.
8. Unit Cost: This identifies the unit cost of the get item that will be used in calculating the prorated discount. It will default
to the item/supplier cost, but can be modified based on the agreement with the supplier. It must be greater than zero as
this is the cost that would normally be charged for the goods if no deal applied. This is required and enabled when Get
Type is Free – get units free.

9. Discount: This identifies the value of the discount on the get item when Get Type is other than Free – get units free.
This value is considered percent or amount based on whether the get type is % off cost or amount off cost or fixed
amount. This is required and enabled when Get Type is other than Free – get units free.
10. Discount Apportion %: This value identifies what percentage of the total discount should be apportioned from the get
item’s unit cost where buy item is not same as the get item. The remaining will be apportioned from the buy item’s unit
cost. For example: If the discount is 100 and Discount Apportion % is 60, then discount amount applied on get item will
be 60% and buy item 40%. This field is always required when Threshold Value Type is selected as ‘Buy/Get Free or
Discounted Items’.
11. Threshold Get Item Quantity: This identifies the quantity of the identified get item that will be given at the specified
discount or fixed cost or free if the buy item is purchased over the threshold quantity. This field is always required when
Threshold Value Type is selected as ‘Buy/Get Free or Discounted Items’.
Example
Here is an example of how a deal could be set up using these attributes and how it would be applied to a purchase order.
Deal Setup:
 Buy Item
 Threshold Buy Quantity: 10
 Unit Cost: $100
 Recurring for all buy quantities: Y
 Get Item
 Get Type: Free – get units free
 Threshold Get Quantity: 2
 Unit Cost: $50
 Discount Apportion: 60%
Purchase Order:
 Buy Item
 Quantity: 40
 Total Cost before deal applied: $4000 (40*100)
 Get Item
 Quantity: 8
 Total Cost before deal applied: $400 (8*50)
 Discounts Applied
 Buy Item = $160 (400*(1-60%))
 Total Cost after deal applied = $3,840
 Get Item = $240 (400*60%)
 Total Cost after deal applied = $160
 Total Discount = $400
Item/Locations
This container defines the items and locations that are to be a part of a particular component on the current deal. The user is
allowed to define the deal at any level of the merchandise hierarchy (starting from the Company level) as well as
organization hierarchy (starting from the Chain level). Users can also use item and location lists. Within a hierarchy if there
are certain item/locations that are not to be included as a part of the deal, they are added to the deal and the ‘Excluded’
indicator is selected.

Thresholds
This container is used to define the lower and upper limits that need to be reached in order to receive the benefits that are
defined as part of the current deal. Multiple thresholds or bands can be defined for a deal.
If the threshold value type that was defined for the deal component is set to Amount Off, the user has the option to select
whether the specified amount needs to be applied per unit or as a total value for the entire threshold band. For example, a
vendor might offer the retailer a discount of $1 per unit or a total discount of $50 on buying in excess of 100 quantities.
Each component added to the deal can be used as the target level around which cost calculations need to take place. The
user must indicate the threshold band that is to be treated as the targeted level for a deal component. This threshold band is
then used for the future cost and pricing cost calculations.
Revisions
Revisions can be accessed using the button present in the Thresholds container and holds the original values of the
threshold limits in case of any changes made by the user after the approval of the deal. This can be used as an audit trail.

More Actions
Referenced promotions
Referential promotions allow the user to attach any open promotion to the deal. These do not drive any real functionality
and only serve to tie a promotion to a deal. The information attached in this table gets shared with Pricing, which means that
if Pricing adds a referential promotion, it is displayed in the deals screens as well. This functionality is available for all deal
types.
Note: Referential promotions are different from Vendor Funded Promotions attached
through Pricing.
Proof of Performance (Deal Performance) Terms

The Proof of Performance (POP) screen is used to define the performance requirements at the deal level, component level,
or at the item/location level. This allows the buyer to identify what needs to be done in order to receive the deal discount,
which might be an advertisement, coupon distributions or ‘in store’ demonstrations of the product. The requirements are
defined by the partner that offers the deal. POP details are included in the EDI flat file and the Deal batch upload. POP terms
are used only for informational purposes within Merchandising.

Batch Deal Entry
Deals can also be defined by uploading a flat file supplied by a trading partner using the Deal Upload (dealupld) batch. This
flat file contains the deal parameters that are required by the system, as defined above. After the batch run is successfully
completed, the set of deals present in the flat file can be accessed using the Merchandising screens. Deals uploaded through
this process are always created in ‘Worksheet’ status and must be approved online within Merchandising.

Future Cost Calculation
Whenever a deal is approved, unapproved or closed, processing occurs either as part of the batch cycle or through a
synchronous process. This deal processing involves the calculation of the future costs of the constituent items from specific
suppliers and origin countries at the respective locations. The costs calculated include the net cost, net-net cost, dead net
cost and acquisition cost based on the deal definition. These costs are calculated based on the applicable deals, as well as
projected into the future based on indicated target levels.
Within Merchandising, the item cost levels get recalculated based on the approved deals and their start and close dates.
These costs are then stored by active date at the item-supplier-country-location level.
Apart from deals, there are events such as cost changes, reclassifications and new item/supplier/origin country
relationships which trigger the calculation of future cost. The cost calculations are carried out on the base cost of the item (in
its target bracket, if bracket costing is used) minus any deal discounts. The start dates associated with future cost enable
retailers to analyze the manner in which the pending supplier cost changes and reclassifications influence the item costs in
the future. In Merchandising, this information is used by the investment/forward buying process in order to determine the
correct time to buy. The acquisition cost is also used in the calculations of wholesale/franchise costing.
Deal processing also calculates pricing cost which is used when making pricing decisions in Pricing. As described above,
Merchandising provides flexibility to indicate which deals should be included in pricing cost calculations. For example, with a
long-term deal, the cost savings are more likely to be passed on to the consumer through a lower regular price, so the
retailer may define a deal as impacting the pricing cost. In case of a short-term deal, the cost savings are more likely to be
passed onto the consumer through a short-term promotion or more likely that the cost savings remain with the retailer as
higher margin.

Off Invoice Deal Application
After an off-invoice deal is approved, it is eligible to be applied to purchase orders. Deals are said to match purchase orders
if the order has the same vendor, same item/location combinations as the deal, and the deal start and end dates overlap
with the “not before date” of the PO. Deals get applied to all qualifying POs, whether they are created manually, from an
external system, or via replenishment.
Deals can also be applied to purchase orders before approval, such that the impact of deals on the order can be evaluated
and the PO can be altered to qualify for further discounts. When the user chooses to apply deals prior to approval, it can be
done real time or as part of the batch cycle. If the user chooses to apply deals as part of the batch cycle, the order is flagged
as awaiting deals application. This means that the user does not see the result of the deal application until the batch cycle is
run successfully. Deals are always applied during the PO approval phase in order to ensure that any changes made to the
purchase order are reflected in the deals that are applied to it.
Points to Note:
 Any manual cost override that may have occurred during the creation of the purchase order affects the deal application
process. When deals are applied, the user has the option of keeping manual cost overrides or applying deals to the base
cost (in the current bracket, if bracket costing is being used). However, if the deal application is carried out using the
batch, for any item/location that has had its cost manually overridden, deals are not applied.
 The discounts that are offered in most deals depend on the value or number of units on a purchase order; hence the
application of the deal must occur after processes that impact the quantity and value, such as rounding to case packs,
scaling to truck sizes and application of bracket costs. Therefore, the deals application process performs these tasks
before beginning the deal evaluation.

Income Calculations
This section addresses in more detail the complex set of calculations that are performed during deal processing for bill back,
bill back rebate, vendor funded promotion, and vendor funded markdown types of deals.
Bill Back and Bill Back Rebate Income Calculation

Income can be calculated and accrued in two ways: it can be based on actual turnover or a mix of actual turnover and
forecasted turnover. Each method has its advantages and disadvantages.
 The main benefit of using the actual turnover is that all the accrued income is also realized when the vendor pays the
bill. However, if the deal has multiple thresholds that are linear, it could be that the income is not booked until the last
period of the deal which could create large spikes in income (for example, deals expiring at the end of a year).
 The advantage of prorated income calculations is that they smooth out the income figures over the length of the deal
because they consider the actual turnover and forecasted turnover to calculate income and distribute this income
across each period based on the actual/forecasted turnover. The disadvantage of this approach is that if the projected
threshold is not reached at the end of the deal, the income must be backed out, which could create major money
outflows for unmonitored deals at the time of maturity.
Example
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 10%
$2,000.01 $3,000.00 20%
Start position
PERIOD END ACTUAL/FORECASTED ACTUAL/FORECASTED ACTUAL

TURNOVER INCOME
7/25 $800.00 $0.00 No
8/29 $550.00 $35.00 No
9/26 $600.00 $60.00 No
TOTAL $1,950.00 $95.00
Let us assume that a Turnover is realized for Period 1 for a total of $900.
ACTUAL
Period end Actual/forecasted turnover Actual/forecasted income Actual
7/25 $900.00 $0.00 Yes
8/29 $550.00 $45.00 No
9/26 $600.00 $165.00 No
TOTAL $2,050.00 $210.00

PRO-RATED
7/25 $900.00 $92.20 ((900/2050) * 210) Yes
8/29 $550.00 $56.34 ((550/2050) * 210) No
9/26 $600.00 $61.46 ((600/2050) * 210) No
TOTAL $2,050.00 $210.00
The last period has income for $165 for the actual calculation while the pro-rated income curve is more smoothed out. At the
same time, the pro-rated also has some income calculated for Period 1 based on the fact that some turnover was generated
for that period.
Let us assume that the Actual Turnover is realized for Period 2 of $550 and $100 for Period 3.
ACTUAL
7/25 $900.00 $0.00 Yes
8/29 $550.00 $45.00 Yes
9/26 $100.00 $10.00 Yes
TOTAL $1,550.00 $55.00
PRO-RATED
Period End Actual/Forecasted Turnover Actual/Forecasted Income Actual
7/25 $900.00 $92.20 Yes
8/29 $550.00 $56.34 Yes
9/26 $100.00 ($93.54) Yes
TOTAL $1,550.00 $55.00
The risk of a pro-rated deal is that on reaching the last period, income may need to be backed out since too much was
allocated in earlier periods. Actual based deals, on the other hand, continue to have some income calculated.
Deal Performance Screen

The Deal Performance screen, which is accessed from the Deal Income button on the Deal Maintenance screen, allows the
buyer to maintain deal income forecasts. In case a deal has multiple components, the user can select for which component
the income data that is to be reviewed or edited.

Periods
Period End
This field displays the period end based on the start and end dates of the deal reporting period.
Baseline Turnover
Baseline turnover is derived from the actual turnover values copied from existing records (create from existing), or it can be
input manually. This information is expected to be based upon historical data and can be used as a guideline to compare
historical periods against the future budgeted periods. This field is optional for the processing of the deal and hence is not a
mandatory one in the system.
The Target Baseline Growth % field on the screen allows the baseline to be uplifted or reduced automatically and populates
the Budget Turnover field.
Budget Turnover and Income

The Budget Turnover field can be manually input, calculated from the Baseline Turnover using the Target Baseline Growth
Rate, or just copied over from the baseline turnover. The field is optional in the system but is important for the processing of
the deal.
The Budget Turnover is used by the buyer to generate a budgeted income that can be used in Pricing to determine the
margin of the item, as well as the time and manner of income generation; it also provides an overall perspective of the worth
of the deal to the buyer.
These values cannot be modified after the deal is submitted, as purchase decisions can be based on this field.
Actuals/Forecast Turnover and Income

After a deal is approved, the Actuals/Forecast Turnover values are populated with the budget values. The buyer is able to
manipulate the forecasted values to create a better budget, which allows for unpredicted special events to be considered or
to handle scenarios where the deal’s actual turnover starts deviating wildly from the budgeted values. The budget values
remain fixed, thus making it possible to compare the actual and forecasted values against the original plan.
The forecasts get replaced by the actual values as they come in based on the reporting level set up. Because the actual
values represent the income accrual posted to the General Ledger and is based on real values, they cannot be modified by
the user.
 Weekly Income Processing
Generally, weekly income calculation takes place on the last day of each week and gets posted to the General Ledger.
Late posted turnover automatically falls in the current week and adds on to the income in that week. The only exception
is the last week of the month. No income gets calculated for this week until the month is closed. However, the income
generation for an unclosed month can be controlled using an end of month (EOM) parameter as part of the Calculate

Weekly/Monthly Income Based on Turnover (dealinc) batch. See the Merchandising Operations Guide – Volume 1 for
more details on this process. The reason for this logic is that the last week needs to ensure that all potential late posted
sales are accounted for in the correct month.
Note: Applicable records get written to the General and Stock Ledger each time the income
gets calculated. No intermediate/partial calculations are performed in between.
 Monthly or Quarterly Income Processing

The Monthly and Quarterly income processing depends on the end of month in which the period end date falls. Similar
to the weekly processing discussed above, it is essential that income pertains to the month in which the turnover is
realized. In other words, if the end of month process decides that a transaction belongs to a specific month, income
should follow suit.
The end of month (EOM) process allows late posted transaction only to open months, which is one for which EOM
process has not been run yet. Income is calculated on the day the month is closed based on the turnover assigned to
that month. From a technical perspective, income is calculated right before the month is closed.
Actuals/Trend Turnover and Income

Trend forecast is calculated based on the Budget Growth Rate applied to the remaining forecast of the deal. Trend values
help the buyer determine how the forecasts do for the deal if the current actual based trend continues.
Example:
A rebate deal is set up from 2-July until 20-August and monthly reporting.
Last end of month date = 29-July
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 10%
$2,000.01 $3,000.00 20%
Let us assume that on 30-July, after the end of month was processed, the user updated the forecast from $200 budgeted to
$300.
PERIOD BUDGET ACTUAL/FORECASTED TREND BUDGET ACTUAL TREND ACTUAL

END TURNOVER TURNOVER TURNOVER INCOME FORECASTED INCOME
INCOME
7/28 $1,100.00 $1,400.00 $1,400.00 $10.00 $40.00 $40.00 Yes
8/25 $200.00 $300.00 $381.82 $20.00 $30.00 $38.18 No
TOTAL $1,300.00 $1,700.00 $1,781.82 $30.00 $70.00 $78.18
Budget Growth Rate % = ($1400/$1100) -1 = 27%

Trend Turnover = $300 * (1 + 27%) = $381.82

Edit Period
The user can select any of the periods and use the Edit icon to update the Baseline and Budget turnover values in the pop up
below. The Actual values cannot be updated.
Example:
A rebate deal is set up from 2-July-13 until 20-August-13 and monthly reporting.
Last end of month date = 29-July-13
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 10%
$2,000.01 $3,000.00 20%
Start position:
PERIOD END BUDGET TURNOVER BUDGET INCOME
7/28 $0 $0
8/25 $0 $0
9/29 $0 $0
TOTAL $0 $0
Change total to $1,200:
7/28 $400.00 $0
8/25 $400.00 $0
9/29 $400.00 $20.00
TOTAL $1,200.00 $20.00

Change the value for 8/25 to $800:
7/28 $400.00 $0
8/25 $800.00 $20.00
9/29 $400.00 $40.00
TOTAL $1,600.00 $60.00
Change the total to $1,800:
7/28 $450.00 $0
8/25 $900.00 $35.00
9/29 $450.00 $45.00
TOTAL $1,800.00 $80.00
Period 1 and 3 receive $50 each while Period 2 receives $100 due to the $200 change, as the change is prorated across all the
periods based on budget turnover.
Fixed Indicators
When the fixed indicator is selected, the adjustments to an individual cell or by batch programs when the actual turnover is
calculated attempts to keep the totals for Budget or Actual/Forecasts unchanged. The difference in amount due to the
adjustments is spread proportionally over the open periods. This can be used to adjust a specific period where the buyer
thinks there will be increased purchasing. However, at the same time, it can lock in the total amount of available for buying
for the duration of that deal.
Example
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 10%
$2,000.01 $3,000.00 20%

Start position:
PERIOD BUDGET ACTUAL/ BUDGET ACTUAL/ ACTUAL

END TURNOVER FORECASTED INCOME FORECASTED
TURNOVER INCOME
7/28 $1,100.00 $1,100.00 $10.00 $10.00 No
8/25 $200.00 $200.00 $20.00 $20.00 No
9/29 $400.00 $400.00 $40.00 $40.00 No
TOTAL $1,700.00 $1,700.00 $70.00 $70.00
Total is fixed for the actual forecast and an actual turnover of $1250 came in for period 1.

TURNOVER INCOME
7/28 $1,100.00 $1,250.00 $10.00 $25.00 Yes
8/25 $200.00 $150.00 $20.00 $15.00 No
9/29 $400.00 $300.00 $40.00 $30.00 No
TOTAL $1,700.00 $1,700.00 $70.00 $70.00
The total for the actual/forecast columns stayed the same and that for both Periods 2 and 3 was reduced.
Total is fixed for the actual forecast and an actual turnover of $550 came in for period 2.

TURNOVER INCOME
7/28 $1,100.00 $1,250.00 $10.00 $25.00 Yes
8/25 $200.00 $550.00 $20.00 $55.00 Yes
9/29 $400.00 $0 $40.00 $0 No
TOTAL $1,700.00 $1,800.00 $70.00 $80.00
The total was adjusted to reflect the actual turnover, but the final period was set to 0 since the total actual turnover was
larger than the fixed total.

Apply Totals
In the case where the threshold value type and threshold limit type are different for a deal, a conversion factor needs to be
defined between the units and the amount or vice versa.
On the
THRESHOLD LIMIT TYPE Deal
QUANTITY THRESHOLD AMOUNT THRESHOLD
Threshold Amount off Unit based turnover figure: Unit Revenue based turnover figure: Unit
value type based income calculation based income calculation – requires
entry of forecasted units
Percent off Unit based turnover figure : Unit Revenue based turnover figure:
based income calculation - Revenue based income calculation
requires entry of forecasted
turnover
Performance screen, the user must specify the number of units represented by a certain amount of money or units
respectively. Although this calculation can be performed by the system, in the case of multiple items with different costs,
Merchandising would not know the manner in which these items are distributed across the deal. The forecasted values are
applied by pressing the Apply Totals button.
If there are no forecasted units or amount filled in by the user, a one-to-one relationship is assumed: 1 currency value equals
1 unit or vice versa. It is important to note that this value is used for forecast calculations only. When real numbers come in,
the actual numbers are used to calculate actual income. The forecasted values continue to use the calculated ratio.
Also, the forecasted value can only be defined when the deal is in the “Worksheet” status. At the time of approval, the ratio
between the turnover and the forecasted value is locked. As forecasted turnover changes through the accumulation of
actual turnover or by changing forecasts, the forecasted units or amount change (as well) to keep the ratio of amount to
units consistent.
When the deal is in input status the ratio is calculated on the total budget turnover, but when the deal is approved, the total
actual/forecast turnover is used. The actual turnover is very likely to have a different ratio than the estimated one for the
forecasts, so a weighted average between the actual ratio and the forecasted ratio is made to achieve a more accurate value.
Amount threshold limit and amount off unit threshold value

If the threshold limit is “Amount” and the threshold value is “Amount off”, the ratio is calculated by dividing the
Actual/forecasted units by the total Budget Turnover.
Number of Units threshold limit and percentage off threshold value

If the threshold limit is “Units” and the threshold value is “Percentage off”, the ratio is calculated by dividing the
Actual/forecasted amount by the total Budget Turnover.

Example
Let us examine a case where the Threshold limit is set at units and the threshold value is set as a % off an amount.
LINEAR THRESHOLD
LOWER UPPER VALUE
1,000 2,000 10%
2,001 3,000 20%
Start position:
Forecasted Amount = $0
PERIOD END ACTUAL/FORECAST ACTUAL/FORECAST ACTUAL

TURNOVER INCOME
7/28 800 $0 No
8/25 700 $50.00 No
9/29 600 $170.00 No
TOTAL 2,100 $220.00
Forecasted Amount = $4,200

TURNOVER INCOME
7/28 800 $0 No
8/25 700 $100.00 No
9/29 600 $340.00 No
TOTAL 2,100 $440.00
 Ratio: Amount/Unit = 4200/2100 = $2 per unit

 Income for the period ending 7/28  Turnover of 800 units does not reach the threshold, so no income is calculated.
 Income for the period ending 8/25  1500 units of which 500 units will generate income = 500 units * 2 $/unit = $1000
 $1000 * 10% = $100
 Income for the period ending 9/29  2100 units of which 1100 will generate income = 1100 units * 2 $/unit = $2200 
($2200 * 20%) - $100 = $340

After Approval:
Forecasted Amount = $4,200
Forecasted Units for period ending 9/29 changes from 600 to 800.
PERIOD END BUDGET ACTUAL/ BUDGET ACTUAL/ ACTUAL

TURNOVER FORECASTED INCOME FORECASTED INCOME
TURNOVER
7/28 800 800 $0.00 $0.00 No
8/25 700 700 $100.00 $100.00 No
9/29 600 800 $340.00 $420.00 No
TOTAL 2,100 2,300 $440.00 $520.00
The calculations occur in the following manner:

 To keep the ratio constant with the total forecasted turnover changes, the units will change as well.
 ($4200/2100) * 2300 units  Forecasted Amount = $4,600
 Income for the period ending 7/28 No change
 Income for the period ending 8/25 No change
 Income for the period ending 9/29  (2300-1000) * 20% * 2 $/unit - $100 = $420
Forecasted Amount = $4600 based on increase in step 1
Next, let us assume that an actual comes in for 1,200 units and a total value of $2100.
PERIOD END BUDGET ACTUAL/ BUDGET ACTUAL/ ACTUAL

TURNOVER FORECASTED INCOME FORECASTED INCOME
TURNOVER
7/28 800 1,200 $0.00 $35.00 Yes
8/25 700 700 $100.00 $130.789 No
9/29 600 800 $340.00 $476.437 No
TOTAL 2,100 2,700 $440.00 $642.226
 New ratio = 2700 * ($4600/2300) = $5,400

 $2/unit
 New ratio for the period ending 7/28
 ($2100/1200)
 $1.75/unit
 (1200-1000) * 10% * $1.75/unit = $35
 ($2100+ (700 * $2/unit)) / (1200+700) = $1.8421/unit
 (1900-1000) * 10% * $1.8421/unit - $35 = $130.789
 (2100 + (700 + 800) * $2/unit) / (1200 + 700 + 800) = $1.8889/unit
 (2700-1000) *20% * 1.8889 = $476.437

Totals
The Totals table provides an overview of the turnover and income from multiple deal components over the total time span
of the deal delineated in terms of the deal’s reporting period.
This implies that deals set up with a weekly reporting period would display income figures at a weekly level with the end-of-
week date as the row header per week for the time frame for which the deal is valid.
Item Location Income Distribution

Deal income gets distributed to each individual item/location when the batch processes the accrued actual turnover. For
correct margin calculations, the income assigned to each item should represent the contribution of that item towards the
deal. For non-rebate deals, the process is straightforward: each PO is individually compared against the threshold, whereas
the receipts are compared in the aggregated form. With rebate deals where the turnover of individual items is rolled up over
the length of the deal and income is calculated for each period, the contribution may be different in the beginning of the
deal and as it progresses.
Example
Let us examine a case based on actual calculations and set up for two items (A and B) and one location.
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 10%
$2,000.01 $3,000.00 20%
An actual turnover of $1,200 comes in for item A.
PERIOD END ACTUAL/ FORECASTED ACTUAL/ FORECASTED INCOME

TURNOVER
7/7 $1,200.00 $20.00
7/14 0 0
7/21 0 0
7/28 0 0
8/4 0 0
TOTAL $1,200.00 $20.00
Next, an actual turnover of $1,000 comes in for item B.

TURNOVER
7/7 $1,200.00 $20.00
7/14 $1,000.00 $220.00
7/21 0 0
7/28 0 0

TURNOVER
8/4 0 0
TOTAL $2,200.00 $240.00
Here item B is responsible for the $1,000.00, and the inclination may be to assign the $220 income to item B, but this item
could be of an entirely different department. The margin would then be heavily weighted towards the items selling later,
since that item made the income jump into the next threshold level.
The system will take the total turnover of $2,200 and pro-rate the total income $240 over both items for period 2:
Item A = $1,200/$2,200 * $240 = $130.9091 - $20 = $110.9091
Item B = $240 - $130.9091 = $109.0909
Because item A has already booked an income of $20 in the first period, its income in period 2 is reduced by $20.
Some observations:
 This calculation could lead to individual items having negative income, especially with pro-rated deals where income
was distributed upon reaching a threshold.
 All the information is sent to the GL and also to Invoice Matching to ensure both accounts are balanced appropriately.
 It is possible to generate income in a period when an item does not have turnover.
 Deal components do not have to be set up at a subclass or department level to generate accurate income, since it is pro-
rated based on the turnover weight of the item within the deal component.
Skipping a Threshold
When skipping a threshold level for a rebate deal, the calculations could back out earned income. At first, this could be
interpreted as an incorrect calculation but this backing out of income is because no income is expected for this turnover
level.
Example
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 10%
$2,500.00 $3,000.00 20%
Assume that an actual turnover of $1,200.00 comes in for 7/7.
PERIOD END ACTUAL/ FORECASTED ACTUAL/ FORECASTED

TURNOVER INCOME
7/7 $1,200.00 $20.00
7/14 0 0
7/21 0 0
7/28 0 0

TURNOVER INCOME
8/4 0 0
TOTAL $1,200.00 $20.00
Next, actual turnover of $1000.00 comes in for the second period.

TURNOVER INCOME
7/7 $1,200.00 $20.00
7/14 $1,000.00 ($20.00)
7/21 0 0
7/28 0 0
8/4 0 0
TOTAL $2,200.00 $0
The reason for this is that a threshold value of 0% is defined for $2,200, so the total deal income is $0. Hence the second
period generates an income of -$20 to bring down the total to zero.
Fixed Total Calculation

It is possible to define a fixed value as the deal income using the ‘Fixed’ checkbox in the ‘Apply Totals’ section of the Deal
Performance screen. This income gets divided over the reporting period/item/locations that are attached to the deal based
on their turnover. Only ones with such a total will be distributed when that threshold is hit.
This feature can be used in scenarios where the retailer has already received the amount from the supplier but now wants to
distribute this income across a range of items and locations. It is possible to use fixed deals for this, but the lowest level of a
fixed deal is a subclass. Using the complex deals dialogue for this calculation has an added benefit that the detail distribution
is based on real turnover and not a general ratio.
VFP Income Calculation

VFP income is calculated on the promotional markdown taken multiplied by the vendor’s contribution percentage. The Sales
Upload (posupld) batch processes each promotion record individually when sales are processed by Merchandising and add it
to the deal income tables. Income will be assigned to the period where it is realized except if that period is closed, similar to
how income is assigned for bill backs. It will be displayed in the deal income screen after the week, month or quarter has
been closed.
VFM Income Calculation

After approval, this type of deal starts accumulating income when the markdown information is extracted to Merchandising.
Each item/location/vendor combination on the markdown is validated against either item/supplier (ITEM_SUPPLIER for
suppliers) or item/supplier/country (ITEM_SUPP_COUNTRY for partners) information within Merchandising to ensure that
income is calculated only for valid combinations.
Note: No income is generated in case a clearance or markdown is extracted after the deal is
closed.

For a fixed amount funded markdown, the fixed amount is considered as the deal income for each location multiplied by the
stock on hand position on the day of the extraction by the markdown. Percentage-based revenue is calculated by
multiplying the stock on hand position on the day of the extraction by the markdown and the contribution percentage.
Income is assigned to the period when it is realized, except if that period is closed (similar to bill backs). It is displayed in the
Deals Income screen after the week, month or quarter has been closed.

Editing Approved Deals
An approved off invoice deal can be moved back to the worksheet status as long as its active date is greater than the
Merchandising vdate. For Bill Backs and Bill Back Rebates, this operation is possible only until the first transaction against
the deal has been posted. The user is allowed to add or modify the close date of the deal and the number of extra reporting
days to cater to the late postings of the transactions which occur after the deal close date.
Editing Deal Income

The user is allowed to change only the forecast value of an approved deal. Changing the forecast values or totals does not
have any impact on the Actual turnover or the income calculated for these actuals. On changing a single turnover field or a
total field, the turnover difference between the old and new value is proportionally spread out over the forecasted periods if
the total is fixed.
Example
An actual came for the first period and the total is not fixed.
Start position:
PERIOD END ACTUAL/FORECAST TURNOVER ACTUAL
7/28 $1,350.00 Yes
8/25 $400.00 No
9/29 $800.00 No
TOTAL $2,550.00
Change total to $2,850:
PERIOD END ACTUAL/FORECAST TURNOVER ACTUAL
7/28 $1,350.00 Yes
8/25 $500.00 No
9/29 $1,000.00 No
TOTAL $2,850.00
Fix total and change 8/25 to $800
PERIOD END BUDGET TURNOVER ACTUAL
7/28 $1,350.00 Yes
8/25 $800.00 No
9/29 $700.00 No
TOTAL $2,850.00

Editing Thresholds
It is possible to change threshold values after approval. For Off Invoice deals, if the thresholds are updated, the user is
alerted that no further changes are allowed until after the updates have been processed by the batch. If the user tries to re-
access the screen prior to the batch process completing, the deal can only be viewed.
For BB and BBR deals, this logic impacts the deal when calculating new income values, but does not affect the income
generated for the old periods. An audit trail is generated for each change so the customer can create custom reports or look
up why a change was made.
Example
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 10%
$2,000.01 $3,000.00 20%
Start position:

TURNOVER INCOME
7/28 $1,350.00 $35.00 Yes
8/25 $500.00 $50.00 No
9/29 $800.00 $245.00 No
TOTAL $2,650.00 $330.00
Change threshold from 10% to 15%:
LINEAR THRESHOLD
Lower Upper Value
$1,000.00 $2,000.00 15%
$2,000.01 $3,000.00 20%

TURNOVER INCOME
7/28 $1,350.00 $35.00 Yes
8/25 $500.00 $92.50 No
9/29 $800.00 $202.50 No
TOTAL $2,650.00 $330.00

Due to the change in the threshold, the income values for periods 2 and 3 get re-calculated based on the new threshold
conditions. On the other hand, period 1 stays the same because the actual had already been generated. The top bracket of
20% gets applied against the entire applicable turnover in both cases. Both periods 2 and 3 get affected because period 2
has income based on 15% (and not 10%) and period 1 was ‘undervalued’. The total remains unchanged because this is a
linear deal, and thus the increased income for Period 2 causes a reduction in the income for Period 3.

CONNECT WITH US
Call +1.800.Oracle1 or visit oracle.com
Outside North America, find your local office at oracle.com/contact
blogs.oracle.com facebook.com/oracle twitter.com/oracle

Copyright © 2020, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without
notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties
and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed
either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without
our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC
International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The
Open Group. 0120

RMS Deals Overview Whitepaper 19.0

Uploaded by

Document Information

Original Title

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

RMS Deals Overview Whitepaper 19.0

Uploaded by

Copyright:

Available Formats

Oracle Retail Merchandising

February 2020 | Release 19.0

1 Deals Overview Release 19.0

Future Cost Calculation 20

Editing Approved Deals 36

2 Deals Overview Release 19.0

Updates in this Version of the Paper

Merchandising Deal Management

Off Invoice Deal

3 Deals Overview Release 19.0

Case # PO Specific Deal Components Impact

1 Transaction Level - Cumulative Other deals can be applied to a PO in addition to

2 Transaction Level - Cascade Other deals can be applied to a PO in addition to

3 Transaction Level - Exclusive Exclusive – No other deals included

4 Multiple Transaction Level – Other deals can be applied to a PO in addition to

Bill Back Deal

Bill Back Rebate (BBR) Deal

Vendor Funded Promotion (VFP)

4 Deals Overview Release 19.0

Vendor Funded Markdown (VFM)

5 Deals Overview Release 19.0

Manual Deal Entry

6 Deals Overview Release 19.0

Threshold Limit Type and UOM

Note: Thresholds do not apply for VFP and VFM.

Recalculate Approved Orders

7 Deals Overview Release 19.0

Deal Reporting Level

Growth Rebate Indicator

Pack Level Tracking

Purchases and Sales Based

Deal Application Timing

8 Deals Overview Release 19.0

Add Deal Reporting Days

Rebate Calculation Type

LOWER UPPER VALUE

$ 1,000.00 $ 2,000.00 10%

$ 2,000.01 $ 3,000.00 20%

$ 2,500.00 (2500 - 1000) * 20% = $300

Total Income = $300

9 Deals Overview Release 19.0

LOWER UPPER VALUE

$1,000.00 $2,000.00 10%

$2,000.01 $3,000.00 20%

$2,500.00 (2000 - 1000) * 10% = $100

(2500 - 2000.01) * 20% = $100

Total Income = $200

Bill Back Period

Estimated next invoice date

10 Deals Overview Release 19.0

Bill Back Method

Deal Income Calculation

Invoice Processing Logic

Period Process Quantity Income Reported Value

Week 2 Return 600 -$60 Invoicing process is skipped because of a

Week 3 Receive 200 $20 Invoicing process is skipped because the

11 Deals Overview Release 19.0

(-$60 + $20 = -$40)

Week 4 Receive 1500 $150 Supplier is invoiced for an income of $110 (-

Deal Income in Stock Ledger

12 Deals Overview Release 19.0

Note: This flag is not applicable for off invoice deals.

14 Deals Overview Release 19.0