Rms 132x Deals

Oracle Retail
Deals Overview
Release 13.2
October 2013
Note: The following is intended to outline our general
product direction. It is intended for information purposes

only, and may not be incorporated into any contract. 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 for Oracles products
remains at the sole discretion of Oracle.
Contents
Contents ............................................................................................................................. ii
1 Overview ....................................................................................................................... 1
Introduction ............................................................................................................................. 1
Business Rationale .................................................................................................................. 1
RMS Deal Management.......................................................................................................... 1
Off Invoice Deal ............................................................................................................... 1
PO Specific Deal ............................................................................................................... 2
Bill Back Deal .................................................................................................................... 2
Bill Back Rebate (BBR) Deal ............................................................................................ 2
Vendor Funded Promotion (VFP) ................................................................................. 3
Vendor Funded Markdown (VFM) ............................................................................... 4
Fixed Deal ......................................................................................................................... 4
2 Deal Definition .............................................................................................................. 5
Manual Deal Entry .................................................................................................................. 5
Deal Head ......................................................................................................................... 5
Bill Back ............................................................................................................................. 8
Financials ........................................................................................................................ 10
Audit ................................................................................................................................ 12
Comments ....................................................................................................................... 12
Deal Components .......................................................................................................... 12
Item/Location ................................................................................................................ 16
Thresholds ...................................................................................................................... 17
Revisions ......................................................................................................................... 17
Menu Options................................................................................................................. 17
Batch Deal Entry.................................................................................................................... 18
3 Future Cost Calculation ............................................................................................ 21
4 Off Invoice Deal Application ..................................................................................... 23
5 Income Calculations .................................................................................................. 25
Bill Back and Bill Back Rebate Income Calculation .......................................................... 25
Deal Performance Screen .............................................................................................. 27
Amount threshold limit and amount off unit threshold value................................ 32
Number of Units threshold limit and percentage off threshold value ................... 32
Item Location Income Distribution ............................................................................. 34
Skipping a Threshold .................................................................................................... 36
Fixed Total Calculation ................................................................................................. 37
VFP Income Calculation....................................................................................................... 37
VFM Income Calculation ..................................................................................................... 37
ii
6 Editing Approved Deals ............................................................................................ 39

Editing Deal Income ............................................................................................................. 39
Editing Thresholds................................................................................................................ 40
7 Deal Financials ........................................................................................................... 43
8 Deal Invoicing............................................................................................................. 45
9 Fixed Deals ................................................................................................................. 47
Online Setup .......................................................................................................................... 47
Merchandise Fixed Deal................................................................................................ 49
Non Merchandise Fixed Deals ..................................................................................... 51
Income Calculation ............................................................................................................... 51
Promotions ............................................................................................................................. 52
Financials................................................................................................................................ 52
Invoicing................................................................................................................................. 52
10 Appendix..................................................................................................................... 53
Definitions .............................................................................................................................. 53
Future Cost Types .......................................................................................................... 53
Bracket Costing .............................................................................................................. 53
Deal Income Calculation: Actual Principle........................................................................ 54
Deal Income Calculation: Pro-rated Principle................................................................... 56
Negative Income calculation for a non-rebate deal .......................................................... 57
Processing Multiple Weeks in a Single Run for Rebate Deals ........................................ 59
Franchise Deal Pass Through .............................................................................................. 60
Deal Lifecycle......................................................................................................................... 61
Process Definitions ........................................................................................................ 61
Diagrammatic Representations .................................................................................... 63
Deal Batches ........................................................................................................................... 63
iii
1
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 a 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 RMS 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.
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.
RMS Deal Management

Within RMS, 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.
Overview 1
RMS Deal Management
While creating a PO manually within RMS, 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 RMS 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 autopopulated. 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
Transaction Level - Cumulative

only
Other deals can be applied to a PO in addition to

a PO specific deal
Transaction Level - Cascade only

a PO specific deal
Transaction Level - Exclusive

only
Exclusive No other deals included
Multiple Transaction Level

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.
2 Oracle Corporation
RMS Deal Management
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 Price Management (RPM). 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 system. RPM and RMS work together to support this type of
deal.
Vendor Funded Promotions (VFP) can be set up either in RMS or in RPM. Depending on
the application in which they are set up, different steps must be followed by the user.
Note: RMS does not allow the user to enter budgeted or
forecasted values, and the deal income is based on the

vendor-supplied contribution percentage. This percentage is
added in RPM and indicates how much the vendor
contributes towards the promotion.
RMS defined VFP

Creating a VFP in RMS first allows the buyer to slowly build up and negotiate the deal
with the vendor before having to create the promotion. The promotion can be created at a
later point when a formal promotion plan has been built and attached to the deal. It must
be noted that RMS is the keeper of the invoicing logic. RPM can set up this information,
but RMS drives the invoicing functionality. After setting up the above information, the
deal can be approved in RMS. The system does not require that a deal be attached to a
promotion in RPM. However, without approving the deal, no income is generated for it.
After the deal has been created in RMS, RPM allows the user to pull in the deal
information and supplier, as well as to attach the deal and deal component to a
promotion and promotion component. The user in RPM attaches a contribution
percentage to the supplier. The user can only add the items and locations that have been
added to the deal. After the items, locations, and discount details have been added, and
the contribution percentage defined, the promotion can be submitted and approved.
Note: Two types of promotions can be attached to a deal.
One is referential only (accessed through the menu) 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 RPM controlled and no addition/deletion is
possible from the RMS 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 he or she approved the promotion.
RPM defined VFP

In this case, the user first creates the promotion in RPM. The user does not add a deal and
its component to the promotion, but adds the supplier information. Once this
information is added, the deal must be associated with it.
Overview 3
RMS Deal Management
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/Clearance price changes (in RPM) and VFM deals (in
RMS) is essential.
A Vendor Funded Markdown (VFM) slightly differs from a Vendor Funded Promotion
(VFP) from a creation standpoint. A VFM must be created first within RMS. If a deal does
not exist, it cannot be attached to the markdown in RPM. After the information is set up,
the deal must be approved in RMS. RPM only allows approved deals to be attached to a
clearance markdown.
After the VFM deal has been created in RMS, the user can attach the deal and deal
component(s) to the markdown within RPM, and a contribution value or percentage is
added for all the locations and items attached to the markdown. In case a value is added,
it is expressed in the local currency of the location. The markdown can be submitted and
approved after the user has added the item, the locations and the markdown
contribution percentage.
Note: It is possible to add more items and locations to the
markdown than are specified in the deal, but only locations

and items specified in the deal generate income.
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.
There are screens dedicated to the creation and maintenance of all the above types of
deals. 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 ReIM for invoicing. Additionally, RMS 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 in Retail Price Management (RPM) for margin
calculations.
2
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 RMS 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 in RMS 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 RMS, 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.
Deal Definition 5
Manual Deal Entry
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.
PO Specific Deals (O): This type of deal is unique to a purchase order and is entered
and edited using the PO screens and can only be viewed in the Deal Maintenance
dialog. PO specific deals always have a billing type of off-invoice, and these override
all other deals applicable to the items of the purchase order as long as these deals are
not exclusive.
Vendor Funded Markdown (M): The vendor agrees to fund a specific percentage of
the markdown provided by the retailer on a set of goods. The vendor can support the
retailer by contributing a percentage of the retail price discount for each item on
hand. This type of timing cannot be selected from the UI and is set from the
background on the creation of such a 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.
Manual Deal Entry
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, all supplier sites for the
selected supplier are covered by the deal. Deals cannot be set up in RMS 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 in RMS.
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 RMS 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.
Deal Definition 7
Manual Deal Entry
Bill Back
This tab 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 RMS 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, RMS 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, RMS
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
tab that is applicable for VFM and VFP. The other

information, related to how the income calculation is done is
held in RPM for these types of deals.
Rebate Indicator
The rebate indicator is used to differentiate between a bill back and a bill back rebate.
While setting up a Bill Back Rebate (BBR) deal, the user can either select BBR from the
Billing Type dropdown under Deal Head (in which case this indicator becomes checked
and disabled) or select Bill Back from the Billing Type dropdown under Deal Head and
check this indicator manually.
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.
Track at Pack Level

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.
Manual Deal Entry
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%.
Deal Definition 9
Manual Deal Entry
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 tab determines the manner in which invoices are to be raised for
VFM, VFP, Bill Back and Bill Back Rebate deals. This tabs information also controls
whether the Stock Ledger is affected and whether VAT is included in 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.
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.
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
Manual Deal Entry
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 deals 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 suppliers default setup in ReIM. 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
documents 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 ReIM 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 ReIM regardless of the claim amounts being positive or
negative. Once these get approved in ReIM, the above process follows.
Automatic Positive Values - This creates debit memos or credit note requests in the
Approved status in ReIM, 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 ReIM.
Manual Positive Values Only - Debit memos or credit note requests are created in
the Submitted status in ReIM, provided the claim amount is positive. If the claim
amount is negative, it is written to the General Ledger but not sent to ReIM.
No Invoice Processing - This will not have claims staged for ReIM, 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 and Manual
for invoice processing.
This field remains editable until the first invoice has been raised against the deal.
Deal Definition 11
Manual Deal Entry
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
(-$60 + $20 = -$40)
Week 4
Receive
1500
$150
Supplier is invoiced for an income of $110

(-$60 + $20 + $150)
Include 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 Deal:

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, ReIM calculates the appropriate VAT amount. This field remains editable
until the first invoice has been raised against the deal.
Audit
This tab displays important dates and user IDs related to the deal, including input date
and ID, approval date and ID, reject date and ID (if the deal is rejected) and close ID.
Comments
This tab 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.
Manual Deal Entry
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 ID: A system defined sequence that is used to track the components
added to the deal.
2.
Application 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.
Component 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 in RMS 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 per unit -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.
Deal Definition 13
Manual Deal Entry
5.
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.
6.
Calc Rev to Zero: 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.
7.
Deal Class: This indicates the way in which calculations would be performed in case
of multiple deal components.
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.
Manual Deal Entry
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 order of a Bill Back deal
does not matter.
Consider the same example where the unit cost of the item is $100, and it has
three discounts of 2%, 5% and 10% applicable.
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.
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 deals only.
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
8.
Cost Apply Type: Every deal can be taken into account 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: RMS 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.
9.
Include Deal in Pricing Cost

This indicator defines whether the deal is to be used in the pricing cost calculation
used by RPM to determine the margin on the items linked with the deal.
10. Default Contribution %
Deal Definition 15
Manual Deal Entry
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 in RMS, this value is maintained within
RPM only. Any change made to the initial value will not be communicated back to
RMS.
Item/Location
This tab 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 Exclude item/loc from deal? indicator is selected.
For VFP and VFM, the item/location information is shared with RPM. The promotion or
markdown setup is restricted in RPM based on the information that is pulled in from the
component detail, if a VFP or VFM deal is attached. However, RPM allows promotion
creation to item/location combinations that are not a part of the deal created in RMS.
For instance, in the case where there is a set of item/location combinations i1/l1, i1/l2 as
part of a VFP or VFM, the RPM user is not allowed to create promotions for these.
However, the RPM user is allowed to create promotions for other item/location
combinations such as i1/l3, i1/l4, that are not a part of the VFP or VFM.
Manual Deal Entry
Thresholds
This tab 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
This tab 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.
Menu Options
Referential 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 RPM, which means that if
RPM 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 RPM.
Deal Definition 17
Batch Deal Entry
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 in RMS.
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
Batch Deal Entry
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 RMS screens. Deals uploaded
through this process are always created in Worksheet status and must be approved
online in RMS.
Deal Definition 19
3
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 RMS, 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-suppliercountry-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 RMS, 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 RPM. As described above, RMS 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.
Future Cost Calculation 21
4
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.
Off Invoice Deal Application 23
5
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 take into account 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 Turnover
Actual/Forecasted Income
Actual
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.
Income Calculations 25
Actual
Period End
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
Period End
Actual
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
Pro-rated
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
Period End
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
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.
Component Tab
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 RPM 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 taken into account or to handle
scenarios where the deals 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 dealinc batch. See the RMS
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
End
Budget
Turnover
Actual/
Forecasted
Turnover
Trend
Turnover
Budget
Income
Actual/
Forecasted
Income
Trend
Income
Actual
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
Apply Section
Apply: This is used to update individual cells in the table. However, actual values
cannot be updated.
Apply totals: This updates rows in the table based on the two different algorithms
described above. If all cells are equal to zero, the total filled in is spread out evenly
across all periods. Any rounding leftovers are assigned to the last period. On the
other hand, if some turnover is already assigned, the difference between the old total
and the new total is spread out proportionally. Again, actual values are not 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:

Period End
Budget Turnover
Budget Income
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:

Period End
Budget Turnover
Budget Income
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:

Period End
Budget Turnover
Budget Income
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 End
Budget
Turnover
Actual/ Forecasted
Turnover
Budget
Income
Actual/
Forecasted
Income
Actual
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.
Period End
Budget
Turnover
Actual/ Forecasted
Turnover
Budget
Income
Actual/
Forecasted
Income
Actual
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.
Period End
Budget
Turnover
Actual/ Forecasted
Turnover
Budget
Income
Actual/
Forecasted
Income
Actual
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.
Threshold Limit Type
Threshold
Value
Type
Amount Off
Percent Off
Quantity Threshold
Amount Threshold
Unit based turnover figure: Unit

based income calculation
Revenue based turnover figure: Unit

based income calculation requires
entry of forecasted units
Unit based turnover figure : Unit

Revenue based turnover figure:
based income calculation - requires Revenue based income calculation
entry of forecasted turnover
On the Deal 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, RMS 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 Turnover
Actual/Forecast Income
Actual
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

Period End
Actual
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
Turnover
Actual/ Forecasted
Turnover
Budget
Income
Actual/ Forecasted
Income
Actual
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
Turnover
Actual/ Forecasted
Turnover
Budget
Income
Actual/ Forecasted
Income
Actual
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
Summary Tab
The Summary tab 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 deals
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.
Deal Info Tab

This tab provides the header level info for the current BB or BBR deal. This is a read-only
view and gets updated based on the changes taking place in the deal.
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 Turnover
Actual/ Forecasted Income
7/7
$1,200.00
$20.00
7/14
7/21
7/28
8/4
Total
$1,200.00
$20.00
Next, an actual turnover of $1,000 comes in for item B.

Period End
7/7
$1,200.00
$20.00
7/14
$1,000.00
$220.00
7/21
7/28
8/4
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 ReIM 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 gained
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
7/7
$1,200.00
$20.00
7/14
7/21
7/28
8/4
Total
$1,200.00
$20.00
Next, actual turnover of $1000.00 comes in for the second period.

Period End
7/7
$1,200.00
$20.00
7/14
$1,000.00
($20.00)
7/21
7/28
8/4
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.
VFP Income Calculation
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
vendors contribution percentage. The Sales Upload (posupld) batch processes each
promotion record individually when sales are processed by RMS 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.
Note: The Sales Upload (posupld) batch process looks at the
RPM database tables for all relevant information such as the

vendor contribution percentage which is required for the
calculation of the deal income generated by the VFP. RMS
only holds informational data in this case whereas RPM
holds the most accurate information.
VFM Income Calculation

After approval, this type of deal starts accumulating income when the markdown
information is extracted to RMS. 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 in RMS 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 on 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.
Note: RPM works in terms of the selling unit of measure
(UOM) while the stock on hand is held in RMS in the

standard unit of measure (UOM). This means that if a selling
unit of measure is different from the standard unit of
measure, the conversion must be performed.
6
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 RMS 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
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
7/28
$1,350.00
Yes
8/25
$500.00
No
9/29
$1,000.00
No
Total
$2,850.00
Editing Approved Deals 39
Editing Thresholds
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:
Period End
Actual
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%
Editing Thresholds
Period End
Actual
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 recalculated 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.
Editing Approved Deals 41
7
Deal Financials
For bill back, bill back rebate, VFP and VFM deals, financial records are booked on the
day the income is calculated. Deals with a reporting level of monthly and quarterly can
perform this operation before or after the month is closed. Weekly deals, on the other
hand, post to the financials at the end of each week except for the last week of the month.
This last week stays open until the month is closed.
General Ledger (GL) records are always posted, while Stock Ledger records are only
posted if the deal is specifically flagged.
All GL records are posted in the local currency while the deal income displayed to the
user is in the deal currency in RMS. This can lead to small discrepancies when the
conversion changes over time. The conversion rates get refreshed each time the deal
income is calculated, and thus there might be scenarios where the conversion increases or
decreases due to the conversions moving the totals into a different threshold.
Example
Linear Threshold
Lower
Upper
Value
$1,000.00
$2,000.00
10%
$2,500.00
$3,000.00
20%
Let the exchange rate be: 1 = $1.3

Actual Turnover for Period 1
Reporting Period
Location
Item
Currency
Turnover
Income
7/28
1001
12029393
USD
$500
$22.2222
7/28
1011
12029393
EU
1000
44.4444
Total Income generated = $500+ 1000 * 1.3 = $1800 $800 * 10% = $80
Income for location 1001 80 * 500/1800 = $22.2222
Income for location 1011 80*(1000*1.3)/1800 = $57.7778 $57.7778/1.3 =

44.4444
Period End
Actual
7/28
$1,800.00
$80.00
Yes
8/25
$300.00
$30.00
No
9/29
$600.00
$200.00
No
Total
$2,700.00
$280.00
For the second period, the exchange rate shifts to 1 = $2
Deal Financials 43
Editing Thresholds
Actual Turnover for Period 1

Reporting Period
Location
Item
Currency
Turnover
Income
7/28
1001
10000123
USD
$500
$22.2222
7/28
1011
10000123
EU
1000
44.4444
8/25
1001
10000123
USD
$100
$54.9207
8/25
1011
10000123
EU
100
96.9842
Total Income generated = $500 + 1000*2 + $100 + 100*2 = $2800 $1800 * 20% =
$360
Income for location 1001 ($360 * 600/2800) - $22.2222 = $54.9207
Income for location 1011 ($360 * 2200/2800) - (44.4444 * 2) = $193.9683

$193.9683/2 = 96.9842
Period End
Actual
7/28
$1,800.00
$80.00
Yes
8/25
$2,800.00
$280.00
Yes
9/29
$600.00
$40.00
No
Total
$5,200.00
$400.00
The reason that deals make use of the most current currency rate is that technically the
deals income should be calculated against the currency values at the deal end when the
total performance is known. The accruals that happen during the deals lifetime and
currency adjustments continue to occur until the deal is closed.
8
Deal Invoicing
Charge backs are raised when the following three conditions are met:
The system date (vdate) is greater or equal to the estimated invoice date.
Un-invoiced income exists for the deal. This could include more than one reporting
period(s).
The invoice income fits the invoice processing criteria.
After the deal invoice information has been raised, the estimated invoice date is updated
by adding to the bill back period until the estimated invoice date is greater than the
system date. The increment of this value is based on the Gregorian calendar or the 4-5-4
calendar based on the type of calendar set up in the system.
For monthly and quarterly deals, income is generated only when the Stock Ledger is
closed for the month. The invoice is sent that same night from ReIM, so it is possible that
the charge back is raised to the supplier before the retailers organization has paid for the
invoices.
Weekly processing is slightly different in that the invoices are raised on the day that the
week comes to an end, except for the last week of a month. This last week is not invoiced
until the month is closed in order to allow all late posting transactions to be processed.
The invoice is sent that same night from ReIM.
The invoice staging tables are populated by ReIM using the first and last dates of the
period for which the invoice applies.
Currency
Income details are given to the financial system for the deal currency as well as the local
currency. This allows the financial system to tie the income exactly back to the accrued
income values in the General Ledger.
As noted above, RMS generates accrued income records in the currency of the location,
but displays income information using the deal currency in the online screens. This can
lead to small discrepancies between what is invoiced and what is displayed online to
users. The RMS invoice program takes the item/location information which is in the
local currency and converts this into the deals currency on the day that the invoice is
raised. The information that is displayed to the user in RMS was converted into the deals
currency on the day that this income was calculated. If the invoice is raised that same day
then they will be in sync, but if there is a delay in raising the invoice and calculating
income, currency conversion discrepancies can occur.
Deal Invoicing 45
9
Fixed Deals
Certain business setups require the vendor to give the buyer a fixed amount of money in
return for advertising their products for promotional reasons, setting up in-store
demonstrations or displaying their merchandise in prime shelf space. Such fixed
monetary values can be tied to a specific item category or merchandise hierarchy at
times, but there might also be scenarios where this tie-up is not possible.
Fixed deals in RMS allow the user to capture such one-off payments or a series of
payments from a partner (supplier, manufacturer or distributor) to the retailer.
Note: Fixed deals in RMS are only entered online; there is no
batch process for uploading this type of deal.
Online Setup
RMS provides a set of screens that can be used to view and edit fixed deals associated
with a partner.
To start the creation of a fixed deal or to edit/view an existing fixed deal, a user must
search for existing deals for a partner, optionally entering collection dates or currency as
additional search criteria. On performing the search operation, the list of fixed deals
associated with the Partner is displayed. The user can choose to edit/update an existing
record or add a new fixed deal. In order to create a new deal, the following information
must be provided:
Deal Description: Used to identify the deal.
Collect By: The interval period between billing cycles, which can be Date, Monthly,
Quarterly, or Annually. This period is based on the agreement between the partner
and the retailer. The collection occurs based on the First Collect Date and the
Fixed Deals 47
Online Setup
Collect Periods specified by the user. For example, there might be one-time
advertisement fees but monthly shelf space charges.
Note: The Date option must be selected for single collection
entries. In such a scenario, the Collect Periods field is

defaulted to 1 and disabled.
First Collect Date: The date of the collection of the first amount decided as part of
the fixed deal.
Collect Periods: The number of times the collection date is to be repeated after the
First Collect Date. On each collection date an invoice may be raised based on the
invoicing options selected for the deal.
Last Collect Date: Auto-populated by the system based on the First Collect Date,
Collect By, and Collect Periods. The collection date is increased on the basis of
the Gregorian calendar or the 4-5-4 calendar based on the type of calendar set up in
the system.
For example, if the first collect date was 25-Jan, the collect by was quarterly and the
collection periods was 3, the first collection period will be on 25-Jan, and the next two
will be on 25-April and 25-July.
Amount: The sum of money per collection. For example, if the amount were $1,000,
then $1,000 would be assumed per collection. All amounts entered here must be
positive. It is assumed that any negative amounts, or payments to the vendor, would
be handled in an accounts payable system where more control and audit processes
can be added.
Status: Status of the fixed deal. It will very likely be Active, but for deals created
for record keeping purposes the user can also immediately make it Inactive.
Invoicing only occurs for active deals.
Note: For fixed deals, there is no submission and approval
process for flexibility and quick entry purposes.
Type: Reason for the payment. This does not drive any functionality but allows the
quick grouping of fixed deals for custom reporting. This data is held in the
CODE_HEAD table under the code type of FXDT.
Invoicing Processing Logic: This can have three possible values - Automatic, Manual
and No Invoice Processing. If the user selects Manual or Automatic, the type of
invoice that needs to be raised must also be mentioned. This can be a Credit Note
request or a Debit Memo. The Manual option raises invoices in the Submitted state
whereas the Automatic option raises approved invoices.
Note: If the user selects No Invoice Processing, it is
assumed that invoicing is performed outside of RMS/ReIM.
Merchandise Indicator: This is used to tie the fixed deal to a merchandise hierarchy.
Based on its selection, the Merchandise button on the screen is enabled to allow the
user to specify the departments, classes and subclasses associated with the deal.
VAT Indicator: This checkbox is used to indicate whether a fixed deal includes value
added tax (VAT) or not. In case it does include a VAT amount, the VAT code and its
respective rate % must be specified in the pop-up screen.
Online Setup
Note: The VAT amount added to the invoice is per the rate
that is active on the day on which the fixed deal is created. If

the VAT rate changes before the end of the fixed deal, the
old rate is used for the calculation. If there is a change
during the life of the deal, the deal must be closed and
recreated to change.
Org Unit: This is used to indicate the identifier of the organization unit related to the
fixed deal. The application also supports the setting up of fixed deals without any
association with location or merchandise. In case the Multiple Sets of Books (MSOB)
is enabled, such deals should be associated with an Org ID at the deal header level in
order to enable the deal income to be posted to the right set of books.
Merchandise Fixed Deal

In scenarios where the deal income is tied to a merchandise hierarchy, the user should
check the merchandise checkbox, and the user is required to add merchandise and
location hierarchy information. This step is necessary so that RMS can post the deal
income to the correct GL accounts. This action is performed in the Fixed Merchandise
screen accessed via the Merchandise button from the main Fixed Deals screen.
Fixed Deals 49
Online Setup
Locations
For each merchandise hierarchy record added to the fixed deal, the user must specify one
or more locations for which it applies, as well as how much that location receives by
adding a ratio value.
Income Calculation
Non Merchandise Fixed Deals

There might be cases where a fixed deal cannot be traced back to a specific group of
merchandise. One such example is a new store opening offer, where a vendor pays the
retailer to stock their new store. In such scenarios, the user does not check the
merchandise indicator and instead selects a non-merchandise code. These codes are held
in RMS in the NON_MERCH_CODE_HEAD table and are interfaced to ReIM. They
allow invoice matching to map the income out of the fixed deal to the correct account(s)
in the General Ledger.
Income Calculation
For fixed deals, the income amount is first divided equally over the set of merchandise
hierarchies and then pro-rated over the locations based on their ratio values. In case the
Fixed Deals 51
Promotions
sum of the individual records does not add up to the income that needs to be distributed
within a hierarchy due to rounding errors, the difference in amount is assigned to the last
location.
Example
A department is added with one class and two subclasses (1, 2).
In addition to this, two locations (S1, S2) are added one with a ratio of 2 and one with a
ratio of 3.
Fixed deal amount = $10,000
The first $10,000 is equally divided across subclasses 1 and 2, with each getting $10,000/2
= $5,000. Next, the amount $5,000 will be prorated across the set of locations. A
contribution ratio is calculated to equally distribute across locations, if the ratio does not
add up to 1. For example:
Contribution ratio = 1/ (2+3) = 0.2
Based on the contribution ratio, the following will be the prorated incomes at the location
level
Subclass 1/Location S1 = 2*0.2 * $5,000 = $2,000
Promotions
A fixed deal can be attached to one or more promotions similar to the other deal types
described above. These promotions are referential in nature only.
Financials
Merchandise fixed deals can be interfaced to the GL using the Deal Fixed Income
(dealfinc) batch. This program books the accrued income directly into the GL staging
tables (STG_FIF_GL_DATA). The posts are made using the transaction code 8 from
TRAN_DATA and require this transaction code to be set up in the GL Cross Reference
form in RMS. Non-merchandise fixed deals cannot be accrued in the GL through RMS,
but ReIM has facilities that allow the mapping of a non merchandise code to GL
accounts.
Invoicing
The Vendor Deal Invoicing (vendinvf) batch places the income information into the fixed
deal staging tables (STAGE_FIXED_DEAL_HEAD and STAGE_FIXED_DEAL_DETAIL)
during its nightly run. A process within ReIM checks the staging tables and pulls out all
the inserted records. At that time, based on the selections made in the fixed deals screen,
ReIM raises an invoice with this information and automatically processes it or places it in
a manual waiting status until a user approves it.
10
Appendix
Definitions
Future Cost Types
Base Cost is the starting cost of an item prior to any processing. This cost is stored at
the item-supplier-country or the item-supplier-country-location level.
Net Cost is based on the base supplier cost reduced by those deals that are indicated
as net cost. From a business perspective, these are usually Off Invoice deals.
Net-Net Cost is determined after the application of the next set of deals against the
Net Cost. This set of deals usually contains Bill Backs which get calculated on top of
the off invoice cost.
Dead Net Cost is arrived at after the application of the final set of deals against the
Net-Net Cost. These deals are usually defined as Bill Back rebate deals and are also
calculated against the off invoice cost.
In RMS, the cost apply type will default based on the deal type, but can be changed.
Deal Billing Type
Cost Apply Type
Off Invoice
Net Cost
Bill Back
Net-Net Cost
Rebate
Dead Net Cost
Vendor Funded Markdown
Dead Net Cost
Vendor Funded Promotion
Dead Net Cost
Bracket Costing
This refers to a discount to the Supplier Cost of an item based upon the quantity
purchased against an order. In order to use this, the Bracket Costing flag for the supplier
needs to be enabled. The default bracket levels can be set up at any of the following
levels:
Supplier
Supplier/Dept
Supplier/Location
Supplier/Dept/Location
Bracket Costing only applies to warehouse POs. The PO item cost and ELC are calculated
using the Bracket Cost.
Appendix 53
Deal Income Calculation: Actual Principle
Note:
Bracket costs can be manually applied to an order and then

reviewed prior to the order approval.
If bracket costs have not been manually applied to an order
and exist for the items on the order, they will automatically
apply to the order during the order approval process.
For orders that are ordered via replenishment, the system
automatically applies the bracket costs to the purchase
order.

The income calculation for each period is based on the turnover applicable up to that
point based on the deal reporting level parameter. The income values generated from the
previous periods get subtracted from this total period-to-date income to identify the
income generated for the current period.
This method of calculation guarantees that at the end of a deal, income is calculated on
the entire turnover. It also reduces the risk of rounding errors and the complexity in
relation to proration mechanisms.
Mathematically, the rebate income for period X (Ix) is calculated as shown below.
1.
First, apply the entire turnover up to the current period against the thresholds to get
the total income to date.
n
Income to date (In) =

2.
Turnover
i =1
applied against the thresholds.
Next, determine the total income generated until the previous period.
n 1
Income until prior period (In-1) =

3.
Income
i =1
Finally, subtract the previously accrued income from the deal to date income.
Income for current period (Ix) = (In) (In-1)
Below is an example of how this concept would apply to a Linear Threshold rebate
deal.
Deal Start: 2-July
Deal End: 30-Aug
Assume Back to zero indicator is set to N and monthly reporting.
Linear Threshold
Lower
Upper
Value
$1,000.00
$2,000.00
10%
$2,001.00
$3,000.00
20%
Prior to the end of the first period, assume the following the forecasted turnover and
income is as follows:
Period
End
Budget
Turnover
Actual/
Forecasted
Turnover
Budget
Income
Actual/
Forecasted
Income
Notes
7/28
$1,100.00
$1,100.00
$10.00
$10.00
For this period (P1), $1,100 reaches the

first threshold, so the income gets
calculated as 10% on the difference
between $1,100 and $1,000.
(1,100 1,000) * 10% = $10
8/25
$200.00
$200.00
$20.00
$20.00
For the period (P2), $1,300, which is the

forecast to date, reaches the first
threshold, so the income gets calculated
as 10% on the difference between $1,300
and $1,000 minus the income for P1.
((1,100 + 200) 1,000) * 10% - 10 = $20
9/29
$400.00
$400.00
$40.00
$40.00
For the period (P3), $1,700, which is the

forecast to date, reaches the first
threshold, so the income gets calculated
as 10% on the difference between $1,700
and $1,000 minus the income for periods
P1 and P2.
((1,100 + 200 + 400) -1,000) * 10% - (10 +
20) = $40
Total
$1,700.00
$1,700.00
$70.00
$70.00
At the end of the first period, let us assume that Actual Turnover of $1,500 came in for
the period.
Period
End
Budget
Turnover
Actual/
Forecasted
Turnover
Budget
Income
Actual/
Forecasted
Income
Notes:
7/28
$1,100.00
$1,500.00
$10.00
$50.00
Actual income is calculated as

($1,500 - $1,000) * 10% = $50
8/25
$200.00
$200.00
$20.00
$20.00
Forecasted income is recalculated as:

((($1,500 + $200) - $1,000) * 10%) -$50 =
$20
9/29
$400.00
$400.00
$40.00
$150.00
Forecasted income is recalculated as:

((($1,500 + $200 + $400) -$1,000) * 20%) (50+20) = $150
Total
$1,700.00
$2,100.00
$70.00
$220.00
Other notes on this process:
If the total forecasted turnover is changed, it is prorated across the periods based on
the change. If this occurs after an actual value is posted in one of the periods, only
those periods that have not posted an actual are impacted by the proration.
If one of the threshold values is changed, this change is reflected only in the turnover
and income for periods that have not yet posted actual.
Appendix 55
Deal Income Calculation: Pro-rated Principle
Non-rebate Bill Back calculations are different from Rebate calculations because the
former are calculated individually per event against the threshold. This implies that
the previous calculations would still apply, but each PO or receipt would be
individually calculated against the thresholds. For forecasting/budgeting purposes,
RMS assumes only one PO or receipt per period.
Deal Income Calculation: Pro-rated Principle

Prorated deals calculate the total income for the entire deal based on actual and
forecasted turnover. This total income is then prorated over each individual period based
on the turnover up to that period minus the already allocated income.
Rebate income for period X (Ix) is calculated as follows:
1.
First, apply the entire turnover up to the current period against the thresholds to get
the total income.
Income to date (In) =

2.
applied against the thresholds.
Next, calculate the sum from prior period income.

n 1
Income until prior period (In-1) =

3.
Income
i =1
Determine the sum of the entire deal turnover.
Turnover to date (Tn)

4.
Take the sum of turnover up to the current period.

x
Turnover to date (Tx) =

5.
Turnover
i =1
Finally, subtract the previously accrued income from the deal to date income in order
to obtain the income for the current period.
Income for current period (Ix) = (In) * (Tx / Tn) (In-1)
Below is an example of this concept based on a pro-rated scalar rebate deal.

Deal Start Date: 2-July
Deal End Date: 29-August
Assume monthly reporting and total income of the deal of ($1,800-$1,000)*10% = $80
Scalar Threshold
Lower
Upper
Value
$1,000.00
$2,000.00
10%
$2,000.01
$3,000.00
20%
Negative Income calculation for a non-rebate deal
Period
End
Budget
Turnover
Actual/ Forecasted
Turnover
Budget
Income
Actual/
Forecasted
Income
Notes
7/28
$1,200.00
$1,200.00
$53.3333
$53.3333
Income calculation:
$80 * ($1,200/$1,800) = $53.3333
8/25
$200.00
$200.00
$8.8889
$8.8889
Income calculation:
($80* (($200 + $1,200) / $1,800) $53.3333 = $8.8889
9/29
$400.00
$400.00
$17.7778
$17.7778
Income calculation:
($80 *(($400 + $200 + $1,200) /$1,800) ($53.333 + $8.8889) = $17.77778
Total
$1,800.00
$1,800.00
$80.00
$80.00
Let us assume that an Actual Turnover of $1,500 came in for the period P1. Therefore the
total income generated is now (($2100-$2000) * 20%) + (($2000-$1000) * 10%) = $120.
Period
End
Budget
Turnover
Actual/
Forecasted
Turnover
Budget
Income
Actual/
Forecasted
Income
Notes
7/28
$1,200.00
$1,500.00
$53.3333
$85.7143
Income calculation:
$120*($1,500/$2,100) = $85.7143
8/25
$200.00
$200.00
$8.8889
$11.4286
Income calculation:
($120*(($200+$1,500)/$2,100)-$85.7143
= $11.4286
9/29
$400.00
$400.00
$17.7778
$22.8571
Income calculation:
($120*(($400+$200+$1,500)/ $2,100)($85.7143+$11.4286) = $22.8571
Total
$1,800.00
$2,100.00
$80.00
$120.00
Other notes on this process include the following:
If the total forecasted turnover is changed, it is prorated across the periods based on
the change. If this occurs after an actual value is posted in one of the periods, only
those periods that have not posted an actual are impacted by the proration.
If one of the threshold values is changed, this change is reflected only in the turnover
and income for periods that have not yet posted actual.
Non-Rebate Bill Back calculations are different from Rebate calculations because of
the fact that they are calculated individually per event against the threshold and that
each forecasted value is considered to be a single event.

A system option CALC_NEGATIVE_INCOME exists to give users flexibility in the way
negative income will be handled for non-rebate BB deals.
If CALC_NEGATIVE_INCOME is set to N:
RMS does not calculate the negative income in case the total turnover is negative.
If CALC_NEGATIVE_INCOME is set to Y:
Appendix 57
For receipt based deals, the income is calculated on the total turnover (total of all
receipts) for a reporting period.
There can be multiple thresholds per deal, thereby allowing the system to
compare the Return to Vendor (RTV) quantity with the threshold levels and
select the appropriate one for calculating income.
For periods with negative revenue figures, the system reviews the prior periods
for the deal beginning with the most recent and keeps adding the revenue from
each period to the total, until the total comes to a positive value. This combined
total is used for calculating the adjusted income value.
If the negative income is greater than the total positive incomes of all the past
periods (generated by comparing all the PO receipts), the total adjusted income is
considered as zero because the total income for the deal can never be negative.
At that time, the income already booked for the prior periods is subtracted from
the adjusted total to give the current period adjustment.
In case the income has already been posted in the financial system for a past
period, that period need not be corrected. Instead, a negative income needs to be
posted as a credit note.
For deals applied at the time of PO approval, the deal income is not calculated
for returns.
Examples:
Let us consider the following thresholds for the income calculation:
Threshold 1: 0 $500: 5%
Threshold 2: $500 $1000: 10%
Scenario #1:
Period
Process
Revenue
Threshold
Income
Adjustment
Period 1
Receive
$400
5%
$20
-$15 ( Income calculated on $100

turnover, i.e. $400+$400-$700)
Period 2
Receive
$400
5%
$20
-$20 ( Net turnover is -$300, i.e. $400$700)
Period 3
Return
$700
-$35
In this example, the net Income is $5 on a net turnover of $100 calculated using the
threshold of 5%.
Scenario #2:
Period
Process
Revenue
Threshold
Income
Adjustment
Period 1
Receive
$800
10%
$80

turnover, i.e. $800-$200)
Period 2
Return
$200
-$20
threshold of 10%.
Processing Multiple Weeks in a Single Run for Rebate Deals
Scenario #3:
Period
Process
Revenue
Threshold
Income
Adjustment
Period 1
Receive
$600
10%
$60

turnover, i.e. $600+$400-$200)
Period 2
Receive
$400
5%
$20
-$20
Period 3
Return
$800
-$70
threshold of 5%.
Scenario #4:
Period
Process
Revenue
Threshold
Income
Adjustment
Period 1
Receive
$800
10%
$80

turnover, i.e. $800+$200-$400)
Period 2
Receive
$200
5%
$10
-$10
Period 3
Return
$400
-$30
threshold of 10%.
Scenario #5:
Period
Process
Revenue
Threshold
Income
Adjustment
Period 1
Receive
$800
10%
$80
-$60 ( Income calculated on $400 turnover,

i.e. $800+$200-$400-$200)
Period 2
Receive
$200
5%
$10
-$10
Period 3
Return
$400
-$30
Period 4
Return
$200
-$40
threshold of 5%.
Processing Multiple Weeks in a Single Run for Rebate Deals

The deal income batch is equipped to handle data corresponding to multiple weeks in a
single run for rebate deals.
Examples include the following:
Consider a rebate deal (receipt based) with weekly reporting and the following two
thresholds:
Threshold 1: $0 1000: 10%
Threshold 2: $1000 2000: 20%
Scenario #1:
For this deal, assume that on the End of Month (EOM) date, there is revenue of $0
generated resulting in an income of $0. On the following day (1st day of the next month),
a late receipt gets processed for a revenue of $800. Again on the 5th day, there is a receipt
processed for revenue of $800. At the end of the week (7th day) when the deal income
batch is run, it will post an income of $80 for the revenue amount of $800 of the last week
Appendix 59
Franchise Deal Pass Through
of the previous month. Also, there will be an income posted for $240 for the first week of
the next month based on the following logic.
Total revenue generated for the two weeks = $800 + $800 = $1600
Total income (based on the threshold) = 20% of 1600 = $320
Income already posted = $80
Remaining income = $320 - $80 = $240
Scenario #2:
Month
Week
Revenue
Threshold
Total Income
Posting Details
Month 1
$400
10%
$40
$40 (10% of $400) income gets posted for the

Week 4 of Month 1
Month 2
$1200
10%
$280
Total revenue for the two weeks = $400 +

$1200 = $1600
Total income (based on threshold) = 20% of
$1600 = $320
Income already posted = $40
Remaining income = $320 - $40 = $280
Hence, an income of $280 gets posted for
Week 1 of Month 2
Franchise Deal Pass Through

The retailer might want to pass on a percentage of the deal income to a franchise
customer. This functionality is termed as Deal Pass Through which allows the user to
set a percent value for a department/supplier/warehouse/location. These values are
used to calculate the acquisition cost for the franchise stores.
Consider a scenario where a supplier has defined an off invoice deal of 10% for a source
warehouse W1 and there are two Franchise stores FS1 and FS2 that are serviced by it. The
retailer and franchise have agreed on a deal pass-through of 20% for FS1 and 25% for
FS2.
In this case, if the unit price of an item is $10, the retailer would receive this item at $9
and the franchise stores FS1 and FS2 would have $0.20 (20% of $1) and $0.25 (25% of $1)
passed on to them. The system takes the base cost for the source warehouse and
subtracts the savings resulting from a deal pass-through.
Deal Lifecycle
Deal Lifecycle
Process Definitions
Batch Deal Application
If the user chooses to apply deals as part of the batch cycle, the order is flagged as
awaiting deals application. The batch program orddscnt.pc (using the library
liborddeal.so) processes all of the orders that are waiting for deals to be applied. This
means that the user does not see the result of the deal application until the batch cycle is
run successfully (which is usually the next day).
The actual application of the deal lowers the cost of items at the order/item/location
level. After the deals have been applied, the user is able to view the exact set of discounts
that have combined to lower the unit cost.
The advantage of the batch deal application is its speed in handling huge amount of
records for which the manual process can be a time consuming one. A better business
process for retailers might be to exclusively use the batch deal application process based
on their retail setup around the deals functionality.
Appendix 61
Deal Lifecycle
Online Deal Application

If the user chooses to apply off invoice deals as part of the online process, deals for the
items/locations on the current order are applied to the PO. This means that the purchase
order screens display the results of the deal application immediately, and the user knows
the true cost of items on the PO before approving it.
The actual application of the deal lowers the cost of items at the order/item/location
level. After the deals have been applied, the user is able to view exactly which discounts
have combined to lower the unit cost.
However, this process can have performance impacts for large volumes of data.
Deal Clean Up
The batch process dealprg.pc periodically removes outdated deals and proof of
performance terms from the system based on the Deal History Months setting in the RMS
System Variables (system_options.deal_history_months).
Deal Batches
Diagrammatic Representations
Deal Lifecycle
Technical Workflow of a Deal
Deal Batches
The Dealex batch explodes Bill Back deals to their item/location components. It
needs to be run daily.
The Salstage batch posts relevant sales and receipt transactions for the Dealact
batch to process.
The Dealact batch takes all valid POs and transaction data and summarizes it.
These programs must be run daily as well.
Appendix 63
Deal Batches
The Dealinc batch calculates income based on the turnover summarized by the
Dealact batch. This program must run weekly and monthly.
The Dealfct batch runs after the Dealact and summarizes the created income. It
also calculates the forecasted values for the deal.
The Dealday batch, along with its pre and post processing, posts all the income
records to the Stock Ledger and the General Ledger.
Finally, the Vendinvc batch runs after Dealinc and adds the required information
for invoice matching to the invoice staging tables in order to generate invoices.
Note: For more information on all these batch processes, see
the RMS Operations Guide, Volume 1.
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Primary Author: Somsuvro Chandra
Copyright 2013, Oracle. 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, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle
Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.

Rms 132x Deals

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

Rms 132x Deals

Uploaded by

Copyright:

Available Formats

Oracle Retail

Note: The following is intended to outline our general

product direction. It is intended for information purposes

6 Editing Approved Deals ............................................................................................ 39

The sale of slow-moving goods can be catalyzed by vendor funded promotions

Deals can incentivize bulk buying.

Product launches accompanied by deals can increase their success probability.

RMS Deal Management

Off Invoice Deal

RMS Deal Management

linked, rather than the deal purge process.

PO Specific Deal Components

Transaction Level - Cumulative

Other deals can be applied to a PO in addition to

Transaction Level - Cascade only

Other deals can be applied to a PO in addition to

Transaction Level - Exclusive

Exclusive No other deals included

Multiple Transaction Level

Other deals can be applied to a PO in addition to

Cumulative and Cascade deals

Bill Back Deal

Bill Back Rebate (BBR) Deal

RMS Deal Management

Vendor Funded Promotion (VFP)

forecasted values, and the deal income is based on the

RMS defined VFP

One is referential only (accessed through the menu) while

RPM defined VFP

RMS Deal Management

Vendor Funded Markdown (VFM)

markdown than are specified in the deal, but only locations

Manual Deal Entry

Submitted (S): Deal assigned to the approval authority.

Manual Deal Entry

Active and Close Dates

Manual Deal Entry

Threshold Limit Type and UOM

Recalculate Approved Orders

Manual Deal Entry

Deal Reporting Level

tab that is applicable for VFM and VFP. The other

Growth Rebate Indicator

Track at Pack Level

Manual Deal Entry

Purchases and Sales Based

Deal Application Timing

Add Deal Reporting Days

Rebate Calculation Type

(2500 - 1000) * 20% = $300

Manual Deal Entry

(2000 - 1000) * 10% = $100

Bill Back Period

Manual Deal Entry

Manual Deal Entry

Supplier is invoiced for the $80 income

Invoicing process is skipped because of a

Invoicing process is skipped because the

Supplier is invoiced for an income of $110

Include Deal Income in Stock Ledger:

Include VAT in Deal:

Manual Deal Entry

Threshold Value Type

deal is applied, it is not automatically added. It needs to be