Deals - White Paper

89
Retek ® Deals XI Whitepaper

Transcript of Deals - White Paper

Page 1: Deals - White Paper

Retek® DealsXI

Whitepaper

Page 2: Deals - White Paper

Deals - Whitepaper

Retek® Deals XI..................................................................................1

Whitepaper.........................................................................................1

1 General Forward......................................................................6

2 Bill Back Deals.........................................................................6

2.1 Deal Setup..........................................................................................................6

2.1.1 Deal Main...............................................................................................................62.1.2 Deal Component...................................................................................................152.1.3 Component Details...............................................................................................172.1.4 Deal income..........................................................................................................19

2.2 Editing Approved Deals..................................................................................27

2.2.1 Editing Deal Income.............................................................................................272.2.2 Editing Thresholds................................................................................................28

2.3 Deal Calculations.............................................................................................30

2.3.1 Actual Principles...................................................................................................302.3.2 Pro-Rated Principles.............................................................................................362.3.3 Threshold Value and Limit difference..................................................................422.3.4 Changing Thresholds............................................................................................422.3.5 Item location income distribution.........................................................................42

2.4 Create From Existing.......................................................................................42

2.5 Deal Financials................................................................................................42

2.6 Deal Invoicing.................................................................................................42

2.7 Deal Batch.......................................................................................................42

2.8 Deal Technical Tables.....................................................................................42

2.9 Deal examples..................................................................................................42

3 Off Invoice Deals....................................................................43

3.1 Create from existing........................................................................................43

3.2 Transaction Level deals...................................................................................44

4 Vendor Funded Promotions..................................................46

5 Vendor Funded Markdowns..................................................47

6 Fixed Deals.............................................................................48

7 Security...................................................................................49

3

Page 3: Deals - White Paper

Deals Whitepaper

8 Addendums............................................................................50

8.1 Batch Schedule................................................................................................50

8.2 Future Enhancements Under consideration.....................................................51

8.2.1 Billing type Enhancement....................................................................................518.2.2 Royalties...............................................................................................................518.2.3 End date................................................................................................................518.2.4 Deal class and future cost calculation...................................................................518.2.5 Receipt based deals...............................................................................................518.2.6 Sales based deals..................................................................................................528.2.7 PO Approved deals...............................................................................................52

8.3 Terminology and Definition............................................................................52

8.3.1 Bill Back Deal......................................................................................................528.3.2 Rebate Deal...........................................................................................................528.3.3 Vendor Funded Markdown...................................................................................528.3.4 Vendor Funded Promotion...................................................................................53

8.4 Data used for examples....................................................................................53

8.4.1 Calendar................................................................................................................53

8.5 GL setup...........................................................................................................53

4

Page 4: Deals - White Paper

Deals - Whitepaper

5

Page 5: Deals - White Paper

Deals Whitepaper

1 General ForwardThe intention of this document is not to be exhaustive but to give a good indication on what the new functionality is for XI. Pre-requisite knowledge of deals in RMS 10 is required. Additional information can be looked up in the attached files.

Bill Back deals will encompass Rebate Bill Backs unless otherwise specified by mentioning that it relates to Bill Backs with the rebate indicator set to ‘N’. Bill Backs with the rebate indicator set to ‘Y’ will be referenced as Rebate deals or just Rebate unless otherwise specified. VFM will stand for Vendor Funded Markdown and VFP for Vendor Funded Promotion.

2 Bill Back Deals

2.1 Deal Setup

2.1.1 Deal Main

The Deal main form will be the main set up form for Bill Backs. This form is also used for all other none fixed deal setup.

2.1.1.1 Deal Head Tab

This tab will hold general deal information that is also applicable to other deals like off invoice deals.

2.1.1.1.1 Dates

Bill Back deals can only be set up with a close date and therefore require the user to select ‘promotional’ as a value. Some retailers do also call these secondary deals.

6

Page 6: Deals - White Paper

Deals - Whitepaper

In Worksheet it is possible to move the active and close date. If reporting income periods have already been created new periods will be added or removed as the dates shift. The user will be notified in case the dates change and a period would be removed.

After approving the deal, the close date can be moved forward or backward. Similar to worksheet, the user will be notified if any periods are being deleted.

Periods that are added will have 0 turnover and income. It is not possible to move the close date earlier then the system date.

Whenever there is a change in the dates, the income will be re-calculated. This is especially important in case pro-rated calculations are used.

2.1.1.1.2 Vendor

They can be set up for a supplier, manufacturer, wholesaler or distributor. Often very large manufacturer will use local distributors or wholesalers to sell their products in specific regions but yet keep control of the price setting and the relationship with the supplier. To handle these relationships, RMS allows the user to set them up at the item supplier country level.

2.1.1.1.3 Threshold Limit

Bill Back deals allow the tracking of units or an amount. If units are selected, then the user will also have to define what the Unit of Measure (UOM) will be the threshold will track. This defaults to Each (EA) but can be any UOM defined in RMS. Items added to the deal will need to have a logical relationship to the threshold limit for it to be converted correctly. For example, it would not make much sense to have a threshold limit expressed in liters when you are tracking pounds of beef.

2.1.1.2 Bill Back Tab

2.1.1.2.1 Deal Reporting Level

The deal reporting level will determine the length of reporting periods created for income generation. For a 454 calendar, the user will be able to select week, month and quarter while for a Gregorian calendar, only month and quarter can be selected. The reporting period in the deal income screen will show you the last day of the period.

7

Page 7: Deals - White Paper

Deals Whitepaper

Selection the correct reporting period is very important since income will only be calculated ones per reporting period. It also will indicate how often an invoice can be raised.

With quarterly processing in some cases the reporting period is a lot longer then the deal close date indicates. In such a case we will reduced the reporting period to the end of month where the close date false into. This allows for faster income generation realization.

Example: Active date = 27-May-02 and the Close date = 20-Jan-03. We selected the reporting period = Quarterly.

Normally the deal reporting periods would be:30-June-02; 29-Sept-02;29-Dec-02;30-Mar-02

20-Jan-03 is two months away from the end of the quarter so we use instead the end of month which is 27-Jan-03 for the last reporting period.

2.1.1.2.2 Rebate Indicator

A Bill Back deal can be defined as a straight Bill Back (rebate indicator set to ‘N’) or as a Rebate Bill Back. A straight Bill Back will compare each even against the threshold individually, while a Rebate Bill Back will aggregate all the events and compare them in aggregate against the thresholds.

2.1.1.2.2.1 Rebate Indicator is unchecked

A straight Bill Back is only allowed against Purchases and can be done at receipt or PO approval time. Each PO and each item/loc on a receipt will individually be compared against the thresholds.

Example:Threshold $0 $10,000 10%

8

Jun-30 July-28 Aug-25 Sep-29 Oct-27 Nov-24 Dec-29 Jan-26 Feb-23 March-30

Q2 Q3 Q4 Q1

Jun-30 Sep-29 Dec-29 Jan-26

Deal Reporting Periods

Page 8: Deals - White Paper

Deals - Whitepaper

(linear) 10,001 $20,000 20%

Item A for all Locs

Item Loc ValuePO 1 A 1 $15,000 PO 1 B 2 $7,500 PO 2 A 1 $5,000

Income PO1 $3,000 Income PO2 $500 Total Income $3,500

Receipt based straight Bill Backs will only have one threshold set up against them. Capturing the total value of a receipt and compare it individually against thresholds would have increased scope and current we have not discovered a business need to compare the sum of items on an individual receipt against multiple thresholds.

A straight Bill Back deal will always be calculated Linear since most of the time Bill Back deals are single threshold level deals; a linear vs. scalar option would not have provided any different calculations.

2.1.1.2.2.2 Rebate Indicator is checked

Rebate Deals are allowed against Purchases (receipt and PO approval time) and against Sales. If the threshold limit type is set to amount, sales based Rebate deals will be calculated against their retail value not their cost value.

A Rebate deal aggregates the turnover of all item/locations applicable to the deal and compares this turnover against the thresholds.

Example:Threshold $0 $10,000 10%(linear) 10,001 $20,000 20%

Item A for all Locs

Item Loc ValuePO 1 A 1 $15,000 PO 1 B 2 $7,500 PO 2 A 1 $5,000

Turnover $2,000 Income $4,000

2.1.1.2.2.3 Growth Rebate

Growth Rebate information is available for Rebate Bill Backs only and is for reference purposes only. A buyer can set up a growth rebate deal by looking up prior receipt or

9

Page 9: Deals - White Paper

Deals Whitepaper

sales data in a data-warehouse system and then apply the growth percentage to these values to come up with thresholds that would be applicable.

Example:The supplier will reduce the cost of the items by 10% if the buyer purchases 25% more then last year.Last year’s data shows that $100,000 was bought of that particular product. Add to this 25% and the threshold Limit would look like this:

ThresholdLow Limit High Limit Value$125,000 $10,000,000 10%

2.1.1.2.3 Rebate Calc Type

A linear calculation type will apply the achieved threshold value against the entire applicable turnover.

Example:Linear

ThresholdLower 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

A scalar deal will apply each threshold value to the corresponding value in the threshold limit.

Example:Scalar

ThresholdLower 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% = $100Total Income = $200

10

Page 10: Deals - White Paper

Deals - Whitepaper

2.1.1.2.4 Purchases and Sales based calculations

Purchase based deals with PO approval application timing will look at the approval date of each PO to see if it is applicable. At this time no correction will be made when POs are adjusted.

Receipt timed deals on the other hand will be adjusted for RTVs and receiver unit and cost adjustments. We monitor these deals by aggregating transaction code 20 (purchases), subtracting transaction code 24 ( RTVs). Receiver unit and cost adjustments are booked against the 20 transaction code as well so they are incorporated.

For both receipt and purchases based deals, income will be calculated on the off invoice cost.

Sales timed deals will monitor sales transaction without VAT and subtract returns out of them. If the stock ledger VAT inclusive retail indicator is set to ‘N’ then sales are monitored on transaction code 1 and returns with transaction code 4.

If the stock ledger includes VAT, tran_data codes 2 and 4 will be used instead. Tran code 2 represents VAT exclusive sales, while tran code 4 will contain VAT but this will be stripped before processing.

Income for sales based deals is calculated on the retail price of the sold item.

Only deals with PO approval timing will be able to monitor packs. This is because tran_date (sales and receipt based deals) does not store pack information. Packs are not broken down to their components for PO based deals either. Example: Item A is a single Can of Coke and Item B is a 12 pack of Coke (12 times item A). A PO based deal will only be able to track Item A if item A is on the PO and Item B if item B is on the PO. A Receipt or Sales based deal will only ever be able to track item A. In addition, if using a threshold value of amount off per unit, the amount off will apply to the entire pack, not the components in the pack.

2.1.1.3 Financials Tab

The information on this tab will determine when and how invoices are raised. In addition, it will control of the stock ledger is affected or not and what the deal income calculation is. Most of the values will be available to be changed up until the moment the first stock and general ledger transactions are written (stock ledger indicator and deal income calculation), or when the first invoice is raised (invoice processing logic, Bill Back period, include VAT in deal and the Billing Vendor).The estimated next invoice date and Bill Back method will stay available to be changed until the last invoice for that deal has been processed. This allows for accurate invoicing if invoice dates change.Currently they are available to be changed when submitting and approving the deal. The reason behind this is that each customer is likely to want to have different security

11

Page 11: Deals - White Paper

Deals Whitepaper

strategies around this information. Some of the financial information is very specific to finance people and may not be known by the buyer.

2.1.1.3.1 Billing Vendor

Sometimes the supplier that delivers the items is not the vendor that needs to be build. An example of this would be P&G who uses regional suppliers but yet they could be sponsoring in one region the deal. In that case the supplier whose receipts would be tracked is the regional supplier, but the vendor (manufacturer) could be the entity that will be invoiced.

2.1.1.3.2 Bill Back Period

The Bill Back period needs to be at least as large as the reporting period since we do not calculate income earlier then the end of a reporting period.

The choices for the invoice periods are: Weekly, monthly, quarterly, half year and yearly for the 454 calendar. Weekly will not be an option for the Gregorian calendar.

2.1.1.3.3 Invoice date

2.1.1.3.3.1 Estimated next invoice date

The Estimated next invoice date will initially be populated based on the Bill Back period. It will take the last day of the period that will be invoiced.

After the invoicing batch program runs, this date will be updated with a Gregorian week, month or quarter even if the calendar is set to a 454 week. The reason behind this is that invoices are usually raised on the same day and from a business perspective you are going to try to raise the next invoice as close as possible to the same day.

This date can be modified throughout the deals life time, even after approval. This allows a buyer for example to give a one month delay of payment to a supplier but after the first month everything will be billed according to the end of month system.

Please see the invoice chapter for more details on invoicing logic.

2.1.1.3.3.2 Last Invoice date

The last invoice date will be update to the last reporting period that has been invoiced.

12

Page 12: Deals - White Paper

Deals - Whitepaper

2.1.1.3.4 Invoicing Information

2.1.1.3.4.1 Bill Back Method

The invoice raised can be either a credit or a debit note. This overwrites the supplier’s default used in ReIM.

2.1.1.3.4.2 Invoice Processing Logic

In some cases retailers do not want to raise an invoice because they already received the check from the supplier but have not realized the distribution of such funds yet (Monitor Retro). In other cases the retailer may want to handle the raising of a negative income amount (with other words paying the supplier back) manually instead of sending it off. Very often suppliers forget to invoice the retailer for over delivered items, or in this case forget to ask for their money back.

To facilitate these type of business practices, the user has the following options: Raise no invoice. Raise all invoice and automatically process them in ReIM Raise All invoices but require human intervention before raising the invoice to the

supplier Raise the invoice automatically but only for positive values Raise the invoice manually, but only for positive values

Even when no invoice is raised, or only positive invoices are raised, income will still be booked or corrected (negative income) in the GL.

2.1.1.3.5 Include deal income in the Stock Ledger

This checkbox indicates if deal income will be posted to the Stock ledger in addition to the GL. Two transaction codes have been developed for this. Tran code 6 will roll up all income for sales based deals, while Tran code 7 will roll up all purchases based income.

The stock ledger only aggregates these two transaction codes but does not affect opening or closing stock nor does it in any way influence any stock ledger calculations.

For easy customization purposes these transaction codes have been pushed through into the stock ledger calculation package.

2.1.1.3.6 Include VAT in deal

Some deals will require VAT while other won’t. This indicator will add the vat code and rate to the invoice staging tables when selected. Invoice matching will calculate the appropriate VAT.

VAT is selected for each individual item and location based on the VAT Region of the location and which VAT rate is active on the date that the invoice is raised.

13

Page 13: Deals - White Paper

Deals Whitepaper

2.1.1.3.7 Deal income calculation

Income can be calculated and accrued in two ways. It can be based on actual turnover or it can be a mix between actual turnover and forecasted turnover. Each method has its con and pros.

Actual turnover has as main benefit that all accrued income is also realized when the vendor pays the bill. The major disadvantage of this method is that if the deal has multiple thresholds that are linear, it could be that income is not booked until the last period of the deal which could create huge income spikes (ex. deals expiring at the end of a year).

Pro-rated income calculations have as advantage that they will smooth out income over the length of the deal since they take into account actual turnover and forecasted turnover to calculate income and distribute this income across each period based on the actual/forecasted turnover. The major negative aspect of Pro-Rated income is that if at the end of the deal the projected threshold is not reached income needs to be backed out and so unmonitored deals could create major money outflows when they mature.

Example:

LinearThreshold

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/28/2002 $800.00 $0.00 No8/25/2002 $550.00 $35.00 No9/29/2002 $600.00 $60.00 NoTotal $1,950.00 $95.00  

14

Page 14: Deals - White Paper

Deals - Whitepaper

Turnover is realized for Period 1 for a total of $900

Actual Pro-Rated

Period End

Actual/Forecasted Turnover

Actual/Forecasted Income Actual

Period End

Actual/Forecasted Turnover

Actual/Forecasted Income Actual

7/28/2002 $900.00 $0.00 Yes 7/28/2002 $900.00 $92.20 Yes8/25/2002 $550.00 $45.00 No 8/25/2002 $550.00 $56.34 No9/29/2002 $600.00 $165.00 No 9/29/2002 $600.00 $61.46 NoTotal $2,050.00 $210.00   Total $2,050.00 $210.00  

The last period has income for $165 for the actual calculation while the pro-rated 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.

Actual Turnover is realized for P2 of $550 and $100 for P3.Actual Pro-Rated

Period End

Actual/Forecasted Turnover

Actual/Forecasted Income Actual

Period End

Actual/Forecasted Turnover

Actual/Forecasted Income Actual

7/28/2002 $900.00 $0.00 Yes 7/28/2002 $900.00 $92.20 Yes8/25/2002 $550.00 $45.00 Yes 8/25/2002 $550.00 $56.34 Yes9/29/2002 $100.00 $10.00 Yes 9/29/2002 $100.00 ($93.54) YesTotal $1,550.00 $55.00   Total $1,550.00 $55.00  

The danger of a pro-rated deal is that as the last period is reached income may need to be backed out since too much was allocated. The Actual based deal on the other hand still will have some income calculated.

2.1.2 Deal Component

After specifying the general elements of the deal the user will identify within a deal separate components. The benefit of using multiple components is that if a supplier for example gave a fixed amount (monitor Retro) to distribute over several items, it is possible to distribute this fixed amount in different ratios across items. Within the deal income screens the user will then be able to monitor the individual items receiving their income, but also the total sum of the total income.

15

Page 15: Deals - White Paper

Deals Whitepaper

2.1.2.1 Component

The component field is just an informational field.

This information is set up on the deal_comp_type table. No UI exists at this time to populate this table.

2.1.2.2 Application Order

The Application Order for Bill Back deals only applies on the visual display in the UI. This will not drive any functionality.

2.1.2.3 Cost Apply Type

Each deal can be taken into account for the calculation of an estimated future cost value. This field indicates if this value will be calculated on the net cost, net net cost or dead net cost.

Net Cost is the base supplier cost reduced by those deals that are indicated as net cost. From a business perspective this is usual the Off Invoice deals since they are applied first.

Net Net Cost is the application of the next set of deals against the Net Cost. These deals are usually Bill Back deals calculated on top of the off invoice cost.

Dead Net Cost is the application of the final set of deals against the Net Net Cost. These deals are defined as rebate deals and are calculated against the off invoice cost as well.

The form will default the cost apply type based on the deal type.

Deal Billing Type Cost Apply TypeOff Invoice Net CostBill Back Net Net CostRebate Dead Net Cost

We currently assume that straight Bill Back deals and rebate deals do not overlap for the application of the future cost. So Net Net Cost and Dead Net Cost are calculated correctly on top of the Off Invoice cost.

2.1.2.4 Deal Class

All Bill Back deals are Cascade only (defaulted by the system). Unlike Off Invoice deals, this means that each individual Bill Back component is calculated on top of the off invoice cost. Bill Backs are never applied one after another but rather applied against the Net Cost.

For this reason the order of a Bill Back deal does not matter.

16

Page 16: Deals - White Paper

Deals - Whitepaper

2.1.2.5 Threshold Value

The reward for reaching the threshold limit can be an Amount Off or a Percentage Off. The Amount off can be calculated per unit or as a total for the entire threshold band. This is specified when setting up the threshold. The Percentage off can be calculated on the cost value of the units (receipt or PO based Bill Back) or on the sales values of the items (sales based Rebate).

2.1.2.6 Apply to Pricing Cost

This indicator will include the deal into the cost calculation used by RPM to calculate Margin. Since Bill Back deals do not adjust weighted average cost, the margin calculation here is based on a best case scenario.

2.1.2.7 Calc Rev To Zero

In some cases the vendor will specify that a minimum threshold needs to be reached before a discount applies. When that threshold is reached, the discount will apply against the entire threshold, including the level below the threshold.

Example calc Rev to Zero set:Scalar

ThresholdLower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

Turnover Income $ 2,500.00 2000* 10% = $200

(2500-2000.01)* 20% = $100Total Income = $300

This indicator has interesting side effects for calculations. In the above mentioned example, if the turnover would be $1,000.00, income would be $100. This is because the lowest band would then go from 0 -2000 and we have $1,000.00 turnover that applies to this. If that same indicator is turned off, then no income is generated at all, since ($1000-$1000) * 10% = 0

This indicator is not available for Off Invoice deals

2.1.3 Component Details

2.1.3.1 Item/Location

Items and locations can be set up at different levels. Items can be set up all the way from item level to company level. Adding items will be mostly done by use of item and locations list or at a department or subclass level and excluding items by means of an item list.

17

Page 17: Deals - White Paper

Deals Whitepaper

This functionality did not change from previous versions.

2.1.3.2 Thresholds

The user defines here what the lower and higher turnover limit that needs to be reached for a specific reward. If the threshold value is set to Amount Off, then the user will have the option to select if this amount is per unit or a total value for that entire bracket.

In addition to the threshold specific information the user also needs to indicated one threshold that will be the most likely to be reached. This threshold will then be used for the future cost and pricing cost calculations.

2.1.3.3 Revisions

The revisions tab will hold the original values of the threshold after approval. This form and the underlying table can be used as an Audit trail. This feature was required because of the sensitive nature of changing thresholds during the life of a Bill Back. Since changing this value will inherently re-calculate the total income of a deal, it could be used to manipulate margins. More information on how it affects the calculations in 2.2.2.

This feature is not available for Off Invoice deals.

18

Page 18: Deals - White Paper

Deals - Whitepaper

2.1.4 Deal income

This form will allow the buyer to maintain deal income forecasts. In case multiple components exist, the user can select the income data they want to review or edit. The summary tab will summarize turnover and income from multiple deal components.

2.1.4.1 Period End

This field displays the period end based on the start and end date of the deal as explained in 2.1.1.2.1.

2.1.4.2 Baseline Turnover

Baseline turnover is derived from the actual turnover values copied from another deal (create from existing) or it can be input manually. This information is based upon historical data and is optional for the correct processing of the deal. It can be used as a guideline to compare historical periods against the future budgeted periods.

The target baseline growth % field on the form allows the baseline to be uplifted or reduced automatically and populates the budgeted field.

2.1.4.3 Budget Turnover and Income

Budget Turnover and be manually input, calculated from Baseline Turnover using Target Baseline Growth Rate or just copied over from the baseline turnover. It is also optional for the correct processing of the deal.

19

Page 19: Deals - White Paper

Deals Whitepaper

Budget Turnover will be used by the buyer for planning purpose. It will generate a budgeted income that can be used in other applications to figure out what the margin is of the item, when and how income will be generated and give a gut feel check what the deal is worth to the buyer.

Since sometimes purchase decisions are based on this field, it will not be possible to change these values after the deal is submitted.

2.1.4.4 Actuals/Forecast Turnover and Income

After the deal is approved the Actuals/Turnover values will be populated with the budget values. The buyer will be able to tweak the forecasted values to create a better budget. This allows for unpredicted special events to be taken into account or if the deal’s actual turnover starts deviating wildly from the budgeted values. The budget values do not change so it will always be possible to compare the actual and forecasted values against the original plan.

The forecasts will be replaced by actual values as they come in. Actual income processing will depend on the reporting level set. Actuals can also not be modified by the user because these values represent income accrual posted to the General Ledger and are based on real values. Some income manipulation can be achieved by changing the forecasted values or thresholds. See 2.9 for more information on this.

2.1.4.4.1 Weekly Income Processing

In general, every week on the last day of the week income will be calculated. This income will be posted to the General Ledger. Late posted turnover will automatically fall in the current week and count for income in that week.The only exception will be for the last week of the month. No income will be calculated for this week until the month is being closed. The reason for this is that the last week needs to ensure that potential late posted sales are still accounted for in the month that they belong to.

Example:

A deal is set up going from 2-July-02 till 02-August-02 and weekly reporting.Last end of month date = 27-May-02

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

20

Page 20: Deals - White Paper

Deals - Whitepaper

System date = 6-July-02 and a receipt comes in for 6-July-02 for $1,200.00

View after batch ran on 07-July-02Period End

Actual/Forecasted Turnover

Actual/Forecasted Income

7/7/2002 $1,200.00 $20.007/14/2002 0 07/21/2002 0 07/28/2002 0 0

8/4/2002 0 0Total 1200 20

All income is assigned to the first week since the week is closed.

System date = 14-July-02 and a receipt comes in for 14-July-02 for $200.00

View after batch ran on 14-July-02Period End

Actual/Forecasted Turnover

Actual/Forecasted Income

7/7/2002 $1,200.00 $20.007/14/2002 $200.00 $20.007/21/2002 0 07/28/2002 0 0

8/4/2002 0 0Total 1400 40

Turnover is assigned to the second week.

System date = 20-July-02 and a receipt comes in for 10-July-02 for $300.00

View after batch ran on 21-July-02Period End

Actual/Forecasted Turnover

Actual/Forecasted Income

7/7/2002 $1,200.00 $20.007/14/2002 $200.00 $20.007/21/2002 $300.00 $30.007/28/2002 0 0

8/4/2002 0 0Total 1700 70

Record should have been assigned to week 2, but because that week is already processed, the turnover will be assigned into the current active week.

21

Page 21: Deals - White Paper

Deals Whitepaper

System date = 30-July-02 and a receipt comes in for 20-July-02 for $400.00, another receipt came in for $100 for 30-July-02 and one more receipt came in for $250 with a transaction date of 27-July-02 and we close the month.

View after batch ran on 30-July-02Period End

Actual/Forecasted Turnover

Actual/Forecasted Income

7/7/2002 $1,200.00 $20.007/14/2002 $200.00 $20.007/21/2002 $300.00 $30.007/28/2002 $650.00 $190.00

8/4/2002 0 0Total 2350 260

This last end of month date is now 01-July-02. Income for 04-August-02 will not be calculated until 04-August-02.

Each time income was calculated the appropriate records were written to the General and stock ledger. In addition, there were no intermediate calculations performed in between the displayed tables. No ‘partial’ income calculations are done.

The huge jump in income is related to the fact the deal is linear the calculation is as follow: (2350-1000) * 20% -20-20-30.

If the month would not have been closed till 05-Aug-02, then income would have been calculated for both weeks on 05-Aug-02. The 5th week would have had $20 of income.

2.1.4.4.2 Monthly or Quarterly Income Processing

Monthly and quarterly processing will only depend on the end of month where the period end date false in. Similar to weekly processing we need to ensure that income pertains to the month that the turnover is realized in. With other words, if the end of month process decides that a transaction belongs to a specific month, income will follow suite. The end of month process allows late posted transaction to only be posted into open months. An open month is defined as a month for which the end of month process has not been run for yet.

Income will be 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.

22

Page 22: Deals - White Paper

Deals - Whitepaper

Example:

First day of month5/27/2002

7/1/2002

7/29/2002

8/26/2002

The last end of month is 27-May-02. This means that until the end of month process is run for the month starting on 01-July-02 that month is open. Let’s assume for this example that today is 30-July-02. A late posted receipt is considered a receipt with any transaction date before 30-July-02. A record with a transaction date of 28-July-02 will fall in the month started on 01-July-02, while a late transaction with a date of 29-July-02 will fall into the month starting on 29-July-02.The month starting on 01-July-02 will considered to be closed and not accept any more late transactions when the last end of month is set to 01-July-02. At that point all transactions will automatically be assigned to the current open month which has a start date of 29-July-02.

2.1.4.5 Actuals/Trend Turnover and Income

Trend forecast is calculated based on the Deal to Date Growth Rate applied to the remaining forecast of the deal. Trend values will help determine the buyer how the forecasts will do for the deal if the current actual based trend continues.

Example:

A deal is set up going from 2-July-02 till 20-August-02 and monthly reporting.Last end of month date = 29-July-02

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

23

Page 23: Deals - White Paper

Deals Whitepaper

System date = 30-July-02 End of month was processed and 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/2002 $1,100.00 $1,400.00 $1,400.00 $10.00 $40.00 $40.00 Yes8/25/2002 $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

2.1.4.6 Form Usability

2.1.4.6.1 Apply

The apply block will update individual cells in the spreadsheet. It is not possible to update actual values.

2.1.4.6.2 Apply totals

Apply totals will update all cells based on two different algorithms. If all cells are equal to 0, the total filled in will be spread out evenly across all periods. Any rounding leftovers will be assigned to the last period.If on the other hand some turnover is already assigned to each cell, the difference between the old total and the new total will be spread out proportionally. Actuals will not be updated.

Example:

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting.

LinearThreshold

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/2002 $0.00 $0.00 8/25/2002 $0.00 $0.00 9/29/2002 $0.00 $0.00 Total $0.00 $0.00

24

Page 24: Deals - White Paper

Deals - Whitepaper

Change Total to $1,200.00

Period End

Budget Turnover

Budget Income

7/28/2002 $400.00 $0.00 8/25/2002 $400.00 $0.00 9/29/2002 $400.00 $20.00 Total $1,200.00 $20.00

Change 8/25/2002 to $800

Period End

Budget Turnover

Budget Income

7/28/2002 $400.00 $0.00 8/25/2002 $800.00 $20.00 9/29/2002 $400.00 $40.00 Total $1,600.00 $60.00

Change Total to $1,800.00

Period End

Budget Turnover

Budget Income

7/28/2002 $450.00 $0.00 8/25/2002 $900.00 $35.00 9/29/2002 $450.00 $45.00 Total $1,800.00 $80.00

Notice, period 1 and 3 received each $50 while Period 2 received $100 of the $200 change.

2.1.4.6.3 Fixed Indicators

When the fixed indicator is select adjustments to an individual cell or by batch programs when actual turnover is calculated will try to keep the totals for budget or Actual/Forecasts fixed. The difference will be spread proportional over each open period.This can be used to adjust a specific period where the buyer thinks he will be purchasing more (ex. Christmas), but at the same time lock in the total amount of how much will be bought for the duration of that deal.

The total turnover will go above the fixed value if Actuals come in for more then the fixed value. The assumption here is that the buyer does not want to miss out on potential income since the total fixed turnover is an estimate. If for some reason that total should never go above the fixed value to generate income, the threshold limits should be set up for that fixed value.

25

Page 25: Deals - White Paper

Deals Whitepaper

Example:

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting.Last end of month date = 29-July-02

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

Starting Position:

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,100.00 $10.00 $10.00 No8/25/2002 $200.00 $200.00 $20.00 $20.00 No9/29/2002 $400.00 $400.00 $40.00 $40.00 NoTotal $1,700.00 $1,700.00 $70.00 $70.00  

Total is fixed for actual forecast and $1250 actual turnover came in for period 1.

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,250.00 $10.00 $25.00 Yes8/25/2002 $200.00 $150.00 $20.00 $15.00 No9/29/2002 $400.00 $300.00 $40.00 $30.00 NoTotal $1,700.00 $1,700.00 $70.00 $70.00  

The total for the actual/forecast columns stayed the same and that both Period 2 and 3 were reduced.

Total is fixed for actual forecast and $550 actual turnover came in for period 2.

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,250.00 $10.00 $25.00 Yes8/25/2002 $200.00 $550.00 $20.00 $55.00 Yes9/29/2002 $400.00 $0.00 $40.00 $0.00 NoTotal $1,700.00 $1,800.00 $70.00 $80.00  

The total was adjusted to reflect real actual turnover, but the final period was set to 0 since the total actual turnover was larger then the fixed total.

26

Page 26: Deals - White Paper

Deals - Whitepaper

2.2 Editing Approved Deals

2.2.1 Editing Deal Income

Only the forecast of an approved deal can be changed. Changing the forecasts or totals will have no impact on the Actual turnover or the income calculated for these Actuals. When changing a single turnover field or a total field, the turnover difference between the old and new value will be proportionally spread out over the forecasted periods if the total is fixed.

Example:An actual came for the first period and the total is not fixed

Start position:

Period End

Actual/Forecast Turnover Actual

7/28/2002 $1,350.00 Yes 8/25/2002 $400.00 No 9/29/2002 $800.00 No Total $2,550.00

Change Total to $2,850.00

Period End

Actual/Forecast Turnover Actual

7/28/2002 $1,350.00 Yes 8/25/2002 $500.00 No 9/29/2002 $1,000.00 No Total $2,850.00

Fix total and change 8/25/2002 to $800

Period End

Actual/Forecast Turnover Actual

7/28/2002 $1,350.00 Yes 8/25/2002 $700.00 No 9/29/2002 $800.00 No Total $2,850.00

27

Page 27: Deals - White Paper

Deals Whitepaper

2.2.2 Editing Thresholds

It is possible to change threshold values after approval. This will impact the deal when calculating new income values, but will 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:

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting.

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

Start Position:

Period End

Actual/Forecast Turnover

Actual/Forecast Income Actual

7/28/2002 $1,350.00 $35.00 Yes 8/25/2002 $500.00 $50.00 No 9/29/2002 $800.00 $245.00 No Total $2,650.00 $330.00

Change threshold from 10% to 15%Linear

ThresholdLower Upper Value $ 1,000.00 $ 2,000.00 15% $ 2,000.01 $ 3,000.00 20%

Period End

Actual/Forecast Turnover

Actual/Forecast Income Actual

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

Income for Period 2 and 3 are re-calculated based on the new thresholds. Period 1 on the other hand stays the same.

28

Page 28: Deals - White Paper

Deals - Whitepaper

The total stayed the same in both examples because we have a linear deal. The top bracket of 20% was applied against the entire applicable turnover in both cases. Yet it did cause an effect for both period 2 and 3 since Period two now has income based on 15% not 10% and period 1 was ‘undervalued’. This increased income for Period 2 decreased Period 3’ income.

29

Page 29: Deals - White Paper

Deals Whitepaper

2.3 Deal CalculationsIn this section we will go deeper into the calculations and will explain all the values and where they come from. The following examples all assume the deal is approved. In addition, they are not run to their respective ends since the calculations will be identical to those listed. Each example will have an actual coming in, a change to a total and a threshold change.

Additional completely worked out examples can be found in the attached spreadsheet.

OINDIUNSIOUFDNOSIFUNSDOFI

2.3.1 Actual Principles

For each period we will calculate income based on the turnover applicable up to that point. Income generated from previous periods will be subtracted out of this total year to date income. 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 pro-ration mechanisms.

Rebate income for period X (Ix) is calculated as follow:

First apply all turnover up to the current period against the thresholds to get the total income to date.

In = applied against the thresholds.

Take the sum from prior period income

In-1 =

Subtract from deal to date income previous accrued income.

Ix = In - In-1

2.3.1.1 Rebate Actual Linear

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting. Back to zero indicator is set to N.Last end of month date = 29-July-02

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

30

Page 30: Deals - White Paper

Deals - Whitepaper

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,100.00 $10.00 $10.00 No8/25/2002 $200.00 $200.00 $20.00 $20.00 No9/29/2002 $400.00 $400.00 $40.00 $40.00 NoTotal $1,700.00 $1,700.00 $70.00 $70.00  

31

Page 31: Deals - White Paper

Deals Whitepaper

7/28/2002 (1100 – 1000) * 10% = $10 (1100 reaches the first threshold so 10% on the difference between 1100 and 1000)

8/25/2002 ((1100+200) – 1000) *10% - $10 = $30 - $10 = $20

(1300 reaches the first threshold so 10% on the difference between 1300 and 1000 minus the income assigned to P1)

9/29/2002 (($1,100+$200+$400) – $1,000) * 10% - $10 – $20 = $40

(1700 reaches the first threshold so 10% on the difference between 1700 and 1000 minus the income assigned to P1 and P2)

Actuals came in for $1,500.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $10.00 $50.00 Yes8/25/2002 $200.00 $200.00 $20.00 $20.00 No9/29/2002 $400.00 $400.00 $40.00 $150.00 NoTotal $1,700.00 $2,100.00 $70.00 $220.00  

32

Page 32: Deals - White Paper

Deals - Whitepaper

7/28/2002 (1500 – 1000) * 10% = $50

8/25/2002 ((1500+200) – 1000) *10% - $50= $70 - $50 = $20

9/29/2002 (($1,500+$200+$400) – $1,000) * 20% - $50 – $20 = $150

Change total to $2,400.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $10.00 $50.00 Yes8/25/2002 $200.00 $300.00 $20.00 $30.00 No9/29/2002 $400.00 $600.00 $40.00 $200.00 NoTotal $1,700.00 $2,400.00 $70.00 $280.00  

$2,400- $2,100 = $300

$200+$300 * $200/ ($200+$400) = $200 + $100

$400+$300 * (($200+$400)/($200+$400))-$100 = $400 + $200 = $600

7/28/2002 No calculation since this is an actual

8/25/2002 (($1,500+$300) – $1,000) *10% - $50= $80 - $50 = $30

9/29/2002 (($1,500+$300+$600) – $1,000) * 20% - $50 – $30 = $200

Threshold changes from $20% to 15%

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 15%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $10.00 $50.00 Yes8/25/2002 $200.00 $300.00 $20.00 $30.00 No9/29/2002 $400.00 $600.00 $40.00 $130.00 NoTotal $1,700.00 $2,400.00 $70.00 $210.00  

7/28/2002 No Changes

8/25/2002 (($1,500+$300) – $1,000) *10% - $50= $80 - $50 = $30

9/29/2002 (($1,500+$300+$600) – $1,000) * 15% - $50 – $30 = $130

33

Page 33: Deals - White Paper

Deals Whitepaper

2.3.1.2 Rebate Actual Scalar

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting. Back to zero indicator is set to N.Last end of month date = 29-July-02

ScalarThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

34

Page 34: Deals - White Paper

Deals - Whitepaper

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,100.00 $10.00 $10.00 No8/25/2002 $200.00 $200.00 $20.00 $20.00 No9/29/2002 $400.00 $400.00 $40.00 $40.00 NoTotal $1,700.00 $1,700.00 $70.00 $70.00  

35

Page 35: Deals - White Paper

Deals Whitepaper

7/28/2002 (1100 – 1000) * 10% = $10 (1100 reaches the first threshold so 10% on the difference between 1100 and 1000)

8/25/2002 ((1100+200) – 1000) *10% - $10 = $30 - $10 = $20

(1300 reaches the first threshold so 10% on the difference between 1300 and 1000 minus the income assigned to P1)

9/29/2002 (($1,100+$200+$400) – $1,000) * 10% - $10 – $20 = $40

(1700 reaches the first threshold so 10% on the difference between 1700 and 1000 minus the income assigned to P1 and P2)

Actuals came in for $1,500.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $10.00 $50.00 Yes8/25/2002 $200.00 $200.00 $20.00 $20.00 No9/29/2002 $400.00 $400.00 $40.00 $50.00 NoTotal $1,700.00 $2,100.00 $70.00 $120.00  

36

Page 36: Deals - White Paper

Deals - Whitepaper

7/28/2002 ($1,500 – $1,000) * 10% = $50

8/25/2002 (($1,500+$200) – $1,000) *10% - $50= $70 - $50 = $20

9/29/2002 (($1,500+$200+$400) – $2,000) * 20% = $20 ($2,000 - $1,000) * 10% = $100 $100+$20 - $50 - $20 = $50First calculate how much the total income is, in this case $100 is rated at 20% and

$1000 is rated at 10%. Then subtract income from previous periods, respective $50 and $20.

Change total to $2,400.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $10.00 $50.00 Yes8/25/2002 $200.00 $300.00 $20.00 $30.00 No9/29/2002 $400.00 $600.00 $40.00 $100.00 NoTotal $1,700.00 $2,400.00 $70.00 $180.00  

37

Page 37: Deals - White Paper

Deals Whitepaper

$2,400- $2,100 = $300

$200+$300 * $200/ ($200+$400) = $200 + $100

$400+$300 * (($200+$400)/($200+$400))-$100 = $400 + $200 = $600

7/28/2002 No calculation since this is an actual

8/25/2002 (($1,500+$300) – $1,000) *10% - $50= $80 - $50 = $30

9/29/2002 (($1,500+$300+$600) – $2,000) * 20% = $80 ($2,000-$1,000) * 10% = $100 $100+$80-$50-$30

Threshold changes from $20% to 15%

ScalarThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 15%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $10.00 $50.00 Yes8/25/2002 $200.00 $300.00 $20.00 $30.00 No9/29/2002 $400.00 $600.00 $40.00 $80.00 NoTotal $1,700.00 $2,400.00 $70.00 $160.00  

7/28/2002 No Changes

8/25/2002 (($1,500+$300) – $1,000) *10% - $50= $80 - $50 = $30

9/29/2002 (($1,500+$300+$600) – $2,000) * 15% = $60 ($2,000-$1,000) * 10% = $100 $160–$50-$30 = $80

2.3.1.3 Actual calculation for Non-Rebate Bill Back

Non-rebate Bill Back calculations are different from Rebate calculations in that they are calculated individually per event against the threshold. So the previous calculations would still apply, but each PO or receipt would be individually calculated against the thresholds.

For forecasted and budgeted values the assumption was made that only one PO or receipt would be acknowledged per period. Ex If for one period a turnover of $1000 is budgeted, this could in reality be two POs or receipts, but for the forecasted values, this is considered to be only one PO/receipt.

38

Page 38: Deals - White Paper

Deals - Whitepaper

Example:

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting. Back to zero indicator is set to N.Last end of month date = 29-July-02

LinearThreshold

Lower Upper Value $ 500.00 $ 2,000.00 10%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,100.00 $60.00 $60.00 No8/25/2002 $200.00 $200.00 $0.00 $0.00 No9/29/2002 $600.00 $600.00 $10.00 $10.00 NoTotal $1,700.00 $1,900.00 $70.00 $70.00  

7/28/2002 ($1100 – $500) * 10% = $60 ($1,100 reaches the minimum threshold so 10% on the difference between $1,100 and $500)

8/25/2002 $200 is smaller then the lowest threshold so no income for Period 2

9/29/2002 (($600 – $500) * 10% = $10

($600 reaches the first threshold so 10% on the difference between $600 and $500)

Actuals came in for $1,500.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $60.00 $100.00 Yes8/25/2002 $200.00 $200.00 $0.00 $0.00 No9/29/2002 $400.00 $600.00 $10.00 $10.00 NoTotal $1,700.00 $2,300.00 $70.00 $110.00  

7/28/2002 ($1,500 – $500) * 10% = $100

8/25/2002 $200 is smaller then the lowest threshold so no income for Period 2

9/29/2002 (($600 – $500) * 10% = $10

39

Page 39: Deals - White Paper

Deals Whitepaper

Change total to $2,400.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $60.00 $100.00 Yes8/25/2002 $200.00 $225.00 $0.00 $0.00 No9/29/2002 $400.00 $675.00 $10.00 $17.5.00 NoTotal $1,700.00 $2,400.00 $70.00 $117.50  

$2,400- $2,300 = $100

$200+$100 * $200/ ($200+$600) = $200 + $25

$600+$100 * (($200+$600)/($200+$600))-$25 = $600 + $75 = $675

7/28/2002 No calculation since this is an actual

8/25/2002 $225 is smaller then the lowest threshold so no income for Period 2

9/29/2002 (($675 – $500) * 10% = $17,5

Threshold changes from $10% to 15%

LinearThreshold

Lower Upper Value $ 500.00 $ 2,000.00 15%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $70.00 $100.00 Yes8/25/2002 $200.00 $225.00 $0.00 $0.00 No9/29/2002 $400.00 $675.00 $10.00 $26.25 NoTotal $1,700.00 $2,400.00 $70.00 $126.25  

7/28/2002 No Changes

8/25/2002 Still below lowest threshold

9/29/2002 (($675 – $500) * 15% = $26.25

2.3.2 Pro-Rated Principles

Pro-rated deals will only calculate the total income for the entire deal based on actual and forecasted turnover. This total income will then be pro-rated 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 follow:

40

Page 40: Deals - White Paper

Deals - Whitepaper

First apply all turnover against the thresholds to get total income.

In = applied against the thresholds.

Take the sum from prior period income

Ix-1 =

Take the sum of turnover up to the current period

Tx =

Take the sum of deal all turnover

Tn =

Subtract from deal to date income previous accrued income.

Ix = In * (Tx/ Tn) – Ix-1

2.3.2.1 Pro-Rated Linear

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting. Back to zero indicator is set to N.Last end of month date = 29-July-02

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

41

Page 41: Deals - White Paper

Deals Whitepaper

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $900.00 $45.2941 $101.7391 No8/25/2002 $200.00 $500.00 $8.2353 $56.5218 No9/29/2002 $400.00 $900.00 $16.4706 $101.7391 NoTotal $1,700.00 $2,300.00 $70.00 $260.00  

42

Page 42: Deals - White Paper

Deals - Whitepaper

Total income for deal ($2,300 – $1,000) * 20% = $260

7/28/2002 $260 * ($900/$2,300) = $101.7391(Total deal income times the weight of the turnover in relation to the total turnover for the first period.)

8/25/2002 $260 * (($900+$500)/$2,300) - $101.7391 = $56.5218

(Total deal income times the weight of turnover for the first two periods divided by the total turnover for the deal minus the income generated for the first period.)

9/29/2002 $260 * (($900+$500+$900)/$2300) – $101.7391 – $56.5218 = $101.7391

(Total deal income minus the income distributed in period 1 and 2.)

Actuals came in for $1,500.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $45.2941 $196.5517 Yes8/25/2002 $200.00 $500.00 $8.2353 $65.5173 No9/29/2002 $400.00 $900.00 $16.4706 $117.9310 NoTotal $1,700.00 $2,900.00 $70.00 $380.00  

43

Page 43: Deals - White Paper

Deals Whitepaper

Total income for deal ($2,900 – $1,000) * 20% = $380

7/28/2002 $380 * ($1,500/$2,900) = $196.5517

8/25/2002 $380 * (($1,500+$500)/$2,900) - $196.5517 = $65.5173

9/29/2002 $380 (($1,500+$500+$900)/$2,900) - $196.5517 - $65.5173 = $117.9310

Change total to $2,400.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $10.00 $196.5517 Yes8/25/2002 $200.00 $321.4286 $20.00 $15.9483 No9/29/2002 $400.00 $578.5714 $40.00 $67.50 NoTotal $1,700.00 $2,400.00 $70.00 $280.00  

44

Page 44: Deals - White Paper

Deals - Whitepaper

$2,400- $2,900 = ($500)

$500+($500) * $500/ ($500+$900) = $500 - $178.5714 = $321.4286

$900+($500) * (($500+$900)/($500+$900))-$178.5714 = $900 - $321.4286 = $578.5714

Total income = ($2,400-$1,000) * 20% = $280

7/28/2002 No calculation since this is an actual

8/25/2002 $280 * ($1500+ $321.4286) / $2400 – $196.5517 = $15.9483

9/29/2002 $280 * ($1500+ $321.4286 + $578.5714) / $2400 – $196.5517 - $15.9483 = $67.5

Threshold changes from $20% to 15%

LinearThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 25%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $45.2941 $196.5517 Yes8/25/2002 $200.00 $321.4286 $8.2353 $69.0733 No9/29/2002 $400.00 $578.5714 $16.4706 $84.3750 NoTotal $1,700.00 $2,400.00 $70.00 $350.0000  

Total income = ($2,400-$1,000) * 25% = $350

7/28/2002 No Changes

8/25/2002 $350 * (($1,500 + $321.4286)/$2,400) - $196.5517 = $69.0733

9/29/2002 $350 *(($1,500+$321.4286+$578.5714)/$2,400)- $196.5517 – $69.0733 = $84.375

2.3.2.2 Pro-Rated Scalar

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting. Back to zero indicator is set to N.Last end of month date = 29-July-02

ScalarThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 20%

45

Page 45: Deals - White Paper

Deals Whitepaper

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,200.00 $53.3333 $53.3333 No8/25/2002 $200.00 $200.00 $8.8889 $8.8889 No9/29/2002 $400.00 $400.00 $17.7778 $17.7778 NoTotal $1,700.00 $1,800.00 $80.00 $80.00  

46

Page 46: Deals - White Paper

Deals - Whitepaper

Total income for deal ($1,800 – $1,000) * 10% = $80

7/28/2002 $80 * ($1,200/$1,800) = $101.7391(Total deal income times the weight of the turnover in relation to the total turnover for the first period.)

8/25/2002 $80 * (($200+$1,200)/$1,800) - $53.3333 = $8.8889

(Total deal income times the weight of turnover for the first two periods divided by the total turnover for the deal minus the income generated for the first period.)

9/29/2002 $80 * (($400+$200+$1,200)/$1,800) - $53.3333 - $8.8889 = $17.7778

(Total deal income minus the income distributed in period 1 and 2.)

Actuals came in for $1,500.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $53.3333 $85.7143 Yes8/25/2002 $200.00 $200.00 $8.8889 $11.4286 No9/29/2002 $400.00 $400.00 $17.7778 $22.8571 NoTotal $1,700.00 $2,100.00 $80.00 $120.00  

47

Page 47: Deals - White Paper

Deals Whitepaper

Total income for deal ($2,000 – $1,000) * 10% = $100

($2100-$2000) * 20% = $20

$100+$20 = $120

7/28/2002 $120 * ($1,500/$2,100) = $85.7143

8/25/2002 $120 * (($200+$1,500)/$2,100) - $85.7143 = 11.4286

9/29/2002 $120 * (($400+$200+$1,500)/$2,100) - $85.7143 - 11.4286 = $22.8571

Change total to $2,400.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $53.3333 $85.7143 Yes8/25/2002 $200.00 $300.00 $8.8889 $49.2857 No9/29/2002 $400.00 $600.00 $17.7778 $45.0000 NoTotal $1,700.00 $2,400.00 $80.00 $180.00  

48

Page 48: Deals - White Paper

Deals - Whitepaper

$2,400- $2,100 = $300

$200+$300 * $200/ ($200+$400) = $200 + $100

$400+$300 * (($200+$400)/($200+$400))-$100 = $400 + $200 = $600

Total income for deal ($2,000 – $1,000) * 10% = $100

($2400-$2000) * 20% = $80

$100+$80 = $180

7/28/2002 No calculation since this is an actual

8/25/2002 $180 * (($1,500+$300)/2,400) - $85.7143= $49.2857

9/29/2002 $180 * (($1,500+$300+$600)/ $2,400) - $85.7143 - $49.2857 = $45

Threshold changes from $20% to 15%

ScalarThreshold

Lower Upper Value $ 1,000.00 $ 2,000.00 10% $ 2,000.01 $ 3,000.00 15%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $53.3333 $85.7143 Yes8/25/2002 $200.00 $300.00 $8.8889 $34.2857 No9/29/2002 $400.00 $600.00 $17.7778 $40.00 NoTotal $1,700.00 $2,400.00 $80.00 $160.00  

Total income for deal ($2,000 – $1,000) * 10% = $100

($2400-$2000) * 15% = $60

$100+$60 = $160

7/28/2002 No Changes

8/25/2002 $160 * (($1,500+$300)/2,400) - $85.7143= $34.2857

9/29/2002 $160 * (($1,500+$300+$600)/ $2,400) - $85.7143 - $34.2857 = $40

2.3.2.3 Pro-Rated calculation for Non-rebate Bill Back

Similar to the linear non-Rebate Bill Back calculations are different from Rebate calculations in that they are calculated individually per event against the threshold and that each forecasted value is considered to be a single event.

49

Page 49: Deals - White Paper

Deals Whitepaper

Example:

A deal is set up going from 2-July-02 till 30-August-02 and monthly reporting. Back to zero indicator is set to N.Last end of month date = 29-July-02

LinearThreshold

Lower Upper Value $ 500.00 $ 2,000.00 10%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,100.00 $40.5263 $40.5263 No8/25/2002 $200.00 $200.00 $7.3684 $7.3684 No9/29/2002 $600.00 $600.00 $22.1053 $22.1053 NoTotal $1,700.00 $1,900.00 $70.00 $70.00  

Total income ($1100-$500) * 10% + ($600-$500) * 10% = $70

7/28/2002 $70 * ($1100/ $1900) = $40.5263 8/25/2002 $70 * ($1300/$1900) - $40.5263= $7.3684$200 is smaller then the lowest threshold but because of pro-ration rules, it still would get an income assigned.

9/29/2002 $70 * ($1100+$200+$600/$1900) - $40.5263 - $7.3684 = $22.1053

Actuals came in for $1,500.00 (spread over three POs, 750, 500 and 250)

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $40.5263 $22.8261 Yes8/25/2002 $200.00 $200.00 $7.3684 $3.0435 No9/29/2002 $400.00 $600.00 $22.1053 $9.1304 NoTotal $1,700.00 $2,300.00 $70.00 $35.00  

Total income ($750-$500) * 10% + ($600-$500) * 10% = $35(The other POs and forecasts are below the threshold)

7/28/2002 $35 * ($1500/ $2300) = $22.8261 8/25/2002 $35 * ($1700/$2300) - $22.8261= $3.04359/29/2002 $35 * ($2300/$2300) - $22.8261 - $3.0435 = $9.1304

50

Page 50: Deals - White Paper

Deals - Whitepaper

Change total to $2,400.00

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $40.5263 $22.8261 Yes8/25/2002 $200.00 $225.00 $7.3684 $7.7208 No9/29/2002 $400.00 $675.00 $22.1053 $11.9531 NoTotal $1,700.00 $2,400.00 $70.00 $42.5000  

$2,400- $2,300 = $100

$200+$100 * $200/ ($200+$600) = $200 + $25 = $225

$600+$100 * (($200+$600)/($200+$600))-$25 = $600 + $75 = $675

Total income ($750-$500) * 10% + ($675-$500) * 10% = $42.5

7/28/2002 No calculation since this is an actual

8/25/2002 $42.5 * ($225+$1,500)/$2,400) - $22.8261 = $7.7208

9/29/2002 $42.5 * ($675+$225+$1,500)/$2,400) - $22.8261 - $7.7208 = $11.9531

Threshold changes from $10% to 15%

LinearThreshold

Lower Upper Value $ 500.00 $ 2,000.00 15%

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 $1,100.00 $1,500.00 $40.5263 $22.8261 Yes8/25/2002 $200.00 $225.00 $7.3684 $11.5812 No9/29/2002 $400.00 $675.00 $22.1053 $26.25 NoTotal $1,700.00 $2,400.00 $70.00 $63.75  

Total income ($750-$500) * 15% + ($675-$500) * 15% = $63.75

7/28/2002 No calculation since this is an actual

8/25/2002 $63.75 * ($225+$1,500)/$2,400) - $22.8261 = $11.5812

9/29/2002 $63.75 * ($675+$225+$1,500)/$2,400) - $22.8261 - $11.5812 = $17.9297

2.3.3 Threshold Value and Limit difference

51

Page 51: Deals - White Paper

Deals Whitepaper

In case the threshold value and threshold limit are different a conversion needs to be made between units and amount or amount and units.

Threshold Limit TypeQuantity Threshold Amount Threshold

Threshold Value Type

Amount Off Unit based turnover figure : Unit based income calculation

Revenue based turnover figure : Unit

based income calculation – requires entered forecasted

units Percent Off Unit based turnover

figure : Unit based income calculation -

requires entered forecasted turnover

Revenue based turnover figure : Revenue based

income calculation

On the deal income form the user will need to enter how many units or how much money a certain amount of money or units respectively represent. The argument can be made that this is something the system can calculate, but if multiple items with different costs are added the RMS would not know how these items are distributed across the deal.

If no forecasted units or amount is filled in, the form assumes a one to one relationship. So 1 dollar equals 1 unit or vise versa. The forecasted values will be applied by pressing

52

Page 52: Deals - White Paper

Deals - Whitepaper

the apply totals button. This value is only used for forecast calculations. When real actual numbers come in, the actual numbers will be used to generate income.

The forecasted value can only be defined when the deal is in input status. At the time of approval the ratio between the turnover and the forecasted value will be locked in. As forecasted turnover changes through the accumulation of actual turnover or by changing forecasts, the forecasted units or amount will 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 will be used instead.Since the actual turnover will very likely have a different ratio then the estimated one for the forecasts, a weighted average between the actual ratio and the forecasted ratio will be made to achieve a more accurate value.

Example:

Threshold limit is set at units and the threshold value is set as a % off an amount. This example is based on an actual calculation.

LinearThreshold Units

Lower Upper Value 1,000.00 2,000.00 10% 2,001.00 3,000.00 20%

Start positionForecasted Amount = 0

Period End Budget Turnover Budget Income Actual7/28/2002 800.00 $0.00 No8/25/2002 700.00 $50.00 No9/29/2002 600.00 $170.00 NoTotal 2,100.00 $220.00  

Forecasted Amount = $4200

Period End Budget Turnover Budget Income Actual7/28/2002 800.00 $0.00 No8/25/2002 700.00 $100.00 No9/29/2002 600.00 $340.00 NoTotal 2,100.00 $440.00  

Ratio: Amount/Unit = $4200/2100 $2 per unit

53

Page 53: Deals - White Paper

Deals Whitepaper

7/28/2002 800 turnover does not reach the threshold so no income is calculated.

8/25/2002 1500 units of which 500 units will generate income = 500 units* 2 $/unit = $1000 $1000 * 10% = $100 income

9/29/2002 2100 units of which 1100 will generate income = 1100 units * 2 $/unit = $2200 ($2200 * 20%)-$100 = $340

After approval:Forecasted Amount = $4200Change Period 3 to 800 units

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 800.00 800.00 $0.00 $0.00 No8/25/2002 700.00 700.00 $100.00 $100.00 No9/29/2002 600.00 800.00 $340.00 $420.00 NoTotal 2,100.00 2,300.00 $440.00 $520.00  

Ratio: To keep the ratio constant the total forecasted turnover changes, the units will change now as well. $4200/2,100 * 2,300 units Forecasted Amount = $4,600

7/28/2002 No change

8/25/2002 No change

9/29/2002 (2300-1000) *20% * 2$/unit - $100 = $340

Forecasted Amount = $4600Actual comes in for 1200 units and a total value of $2100

Period End

Budget Turnover

Actual/Forecasted Turnover

Budget Income

Actual/Forecasted Income Actual

7/28/2002 800.00 1,200.00 $0.00 $35.00 Yes8/25/2002 700.00 700.00 $100.00 $130.789 No9/29/2002 600.00 800.00 $340.00 $476.437 NoTotal 2,100.00 2,700.00 $440.00 $520.00  

New Ratio 2,700 * $4,600/2,300 = $5,400 2$/unit

7/28/2002 New ratio for P1 $2100/1200 1.75 $/unit (1,200-1,000) * 10% * 1.75 $/unit = $35

8/25/2002 New ratio for P2 ($2100+700* 2$/unit)/ (1,200+700) = 1.8421 $/unit (1900-1000) * 10% * 1.8421$/unit - $35 = $130.789

9/29/2002 New ratio for P3 ($2100+ (700+800) * 2$/unit)/ (1,200+700+800) = 1.8889 (2700-1000) *20% * 1.8889 = $476.437

54

Page 54: Deals - White Paper

Deals - Whitepaper

In the attached spreadsheet, scenarios 1 thru 3 are examples of different threshold value and limits.

2.3.4 Item location income distribution

2.4 Create From Existing

2.5 Deal Financials

2.6 Deal InvoicingDate discussion

2.7 Deal Batch

2.8 Deal Technical Tables

2.9 Deal examples

55

Page 55: Deals - White Paper

Deals Whitepaper

3 Off Invoice Deals

3.1 Create from existing

RMS XI introduced the ability to copy off invoice deals that are in progress or closed. In the deal find form the user can select create from existing.

Figure : Off Invoice Deals create from Existing

After filling in the Deal ID, a start and end date needs to be specified for the deal. It should not be required to fill in an end date if the deal is an annual deal.

If the user does not know the Deal ID, a bunch of criteria can be entered to narrow down the search. The start and end date will be used to copy the old deal into after selecting the desired deal from the search list.

Order Specific Off Invoice deals can not be created from existing since they are specific to an order and are usually one of deals confirmed with the supplier for a specific promotional event.

It is not possible to change the vendor for Off Invoice deals. Item validation is very important for such deals and this is not build out for XI. In addition, off invoice deals are rarely identical for different vendors.

56

Page 56: Deals - White Paper

Deals - Whitepaper

3.2 Transaction Level deals

Suppliers can offer retailers PO specific deals in addition to the standard generic annual and promotional deals. Sometimes these deals are very simple and tell the buyer to take10% off the entire PO in addition to the other promotional or annual deals set up.

To facilitate such simple deals, transaction level deals can be set up. These deals do not require the user to set up any merchandise or organizational hierarchies. They can be set up directly as an off invoice deal or they can be set up as a PO-specific deal.

PO specific deals will only take into account other generic deals (annual, promotional) if the PO specific deal only contains components at transaction level. Only a single PO specific deal can be attached to each order and this will always be applied last to the order when calculating the deal totals. The calculation for the discount will then be based on whether the PO specific deal was set up as cascade, cumulative or exclusive.

If at least one of the components of the PO Specific Deal is not at transaction level (e.g. at item / location level), then the PO specific deal will be exclusive. In this case, it is assumed that the buyer has a specific agreement with the supplier for a specific item or group of items with a discount above and beyond all other deals combined.

PO specific deals are only non-exclusive when either cascade or cumulative transaction level discounts are the only discount defined.

Annual and promotional deals will be applied to the order based on existing functional criteria (held at system level – based on deal type and age of highest priority).

Where a PO specific deal exists with only the cumulative or cascade transaction level components (and therefore considers other deals), the PO specific deal will be processed last out of all the applicable deals.

Example PO Specific Deal Components Impact on Other Deals Calculation

57

Create Purchase Order

Create PO Specific Deal: Apply PO Specific Deal(on-line or batch)

Page 57: Deals - White Paper

Deals Whitepaper

1 Transaction Level Cumulative only Include other deals2 Transaction Level Cascade only Include other deals3 Transaction Level Exclusive only Exclusive – no other deals applied4 Non Transaction Level only Exclusive – no other deals applied5 Non Transaction Level plus any Transaction

Level *Exclusive – no other deals applied

6 Multiple Transaction Level Cumulative and Cascade deals

Include Other deals

Table 1* any deal with a non-transaction level component will make the PO specific deal exclusive, irrespective of the type of transaction level component included.

There can only be one exclusive transaction level component on a deal.

Example:

PO specific deal #101Component 1 : Cascade PO specific transaction level deal (10%) – applies to all locations and items across the order

Annual or Promotional deal #201Component 1: Cumulative deal on item 1 and 2 (20%) in department 1

- A transaction level cascade will apply the PO specific deal after all other deals (promotional, annual) and based on the net cost (base cost minus all off invoice deals applied thus far).

Step Deal Applied Item Base Cost after Deal Comments1 #201 1 $10 $8 20% discount1 #201 2 $20 $16 20% discount

Subtotal $30 $242 #101 1 $8 $7.20 10% discount

#101 2 $16 $14.40 10% discountTotal $21.60 ($24 - $2.40)

58

Page 58: Deals - White Paper

Deals - Whitepaper

4 Vendor Funded PromotionsDeal setup

Income calculation

Deal Financials

59

Page 59: Deals - White Paper

Deals Whitepaper

5 Vendor Funded MarkdownsDeal setup

Income calculation

Deal Financials

60

Page 60: Deals - White Paper

Deals - Whitepaper

6 Fixed Deals

61

Page 61: Deals - White Paper

Deals Whitepaper

7 Security

62

Page 62: Deals - White Paper

Deals - Whitepaper

8 Addendums

8.1 Batch Schedule1) Ditinsrt.pc needs to run after the creation and approval of a Deal.

2) Daily Processing

a. Salstage, salapnd will move tran_data records into the deal_perf_tran_data.

b. Dealex.pc will extract Bill Back deals into deal_item_loc_explode.

c. Dealact.pc will take records from deal_perf_tran_data and update deal_actuals_item_loc.

d. Vendinvf.pc will process fixed deals and create records in stage_fixed_deal_detail/head for invoice match to pull data from.

e. Vendinvc.pc will process Bill Back deals and create records in Stage_complex_deal_detail/head for invoice match to pull data from.

3) End of week processing:

a. Run daily process

b. Salweek.pc and prepost.pc post salweek needs to run to keep week_data correct every 7 days and before running salmth.pc

4) End of month processing:

a. Run the daily process except vendinvc.pc

b. Prepost dealinc pre, Dealinc.pc need to run at the end of the month and will create income in deal_actuals_item_loc and generate tran_data records 6 and 7 in tran_data_temp.

c. Dealfct.pc will run next and update deal_actuals_item_loc, deal_detail and deal_head with totals and forecasted values.

d. Vendinvc.pc can run now to update the invoice match staging tables.

e. Prepost.pc pre dealday, dealday.pc and prepost post dealday will summarize data in tran_data_temp to tran_data_sum, and move records into tran_data (6, 7) for GL posting. In addition they will move the summary records into daily_data for SL processing.

f. Salweek.pc, prepost salweek post, salmth.pc and prepost post salmth need to run to update week_data and month_data correctly.

63

Page 63: Deals - White Paper

Deals Whitepaper

8.2 Future Enhancements Under consideration

8.2.1 Billing type Enhancement

For ease of use the additional option of BB - Rebate should be added to this drop down. This would then check the rebate indicator. The rebate indicator should stay disabled at all times. For regular bill backs the rebate indicator would not be checked and disabled as well.

8.2.2 Royalties

It would be a very easy modification to add royalties to the BB dialogue. A new type should be created under the Billing Type, and a new invoice type should be added. In addition, the rebate indicator would be disabled and the deal would default to a sales based deal. This deal should not generate income, but a new tran_code should be created for it to book the expenses to the GL. It is not required to book this to the stock ledger so that indicator should be disabled as well. Finally, only one threshold should be allowed for royalties and the deal income screen would be limited to just displaying the cost. All labels would have to change to not indicate income but rather an expense.

This modification would truly enhance the dialogue to be a one stop place for all buyer’s needs to generate income or pay expenses to the supplier.

8.2.3 End date

Currently it is always required to fill in an end date. For Bill Backs without a rebate indicator set, it would be a good enhancement to have the additional option to not define an end date (annual deal). The batch processes would just keep adding periods when no future period exists until the deal ends. Some restrictions should be put around this. For example it would not make business sense to allow such a deal to be pro-rated.

8.2.4 Deal class and future cost calculation

The assumption in the current design is that the deal class is always cascade and that no Bill Back and Rebate deals overlap for the future cost calculation. This assumption is not always correct and as such it would be better if in the future Bill Back deals have an option defined that indicates that they are calculated on top of the net cost, and not the net net cost or dead net cost.

Cascade implies that you take the previous cost and calculate your Bill Back on this. Bill Back and Rebates are always calculated on top of the off invoice cost. The default of cascade implies that you take the previous discounted value and calculate your deal on top of this. So for the net net cost (Bill Back) we are fine with the cascade option, but if you create a Rebate deal, the assumption is that you calculate the reduction on top of the net cost (off Invoice) and apply this to the net net cost (Bill Back) to come up with the dead net cost. Cascade on the other hand implies you take the net net cost and apply your discount on that to come up with the dead net cost.

Since this is a forecasting instrument anyway, at this time there is not much impact, but for business consistency it would be better to define this new fourth option of deal class.

8.2.5 Receipt based deals

Due to scope reduction it is not possible to define multiple threshold levels against receipt based Bill Back Deals. For consistency purposes this should be enhanced. This will also require the evaluation of the entire receipt, not just the item/loc against the Bill Back deals thresholds.

64

Page 64: Deals - White Paper

Deals - Whitepaper

Currently we do not track the Purchase Order number for receipt based Bill Back or Rebate deals. For more complete reporting we should store the PO that each receipt belongs to.

8.2.6 Sales based deals

Sales based deals are currently calculated on the retail value of the sold units. Ideally in the future we should include an option to calculate income based on the retail value of the sold units or their cost value.

8.2.7 PO Approved deals

Deals based on PO approval currently are not adjusted when corrections are made to the PO. For a future enhancement this should be corrected so that just as with receipts and sales the NET value is taken into account.

8.3 Terminology and Definition.

8.3.1 Bill Back Deal

This is a deal set up by the buyer to receive money back from the supplier calculated on top of the off invoice price. This is often done because the supplier has a fixed sales price and does not want to lower the off invoice price for compliance reasons or price protection reasons.

Very often this is a straight percentage or amount off per unit (only one threshold). To a large extend a Bill Back deal could be compared to an off invoice deal calculated and charged at a later time. For this reason also, the calculation type is only linear.

It often improves the operational margin of the buyer by reducing the cost.

Other Name: Retro deal

8.3.2 Rebate Deal

A rebate deal (also know as a performance deal) requires the buyer to reach certain goals before the deal kicks in. The supplier tries to improve turnover of its products by giving incentives to the buyer to buy more of its products. The income of these deals does not affect the margin of an item directly and are often setup on a category level.

These deals have often complex thresholds set up.

Other Name: Overrider

8.3.3 Vendor Funded Markdown

Sometimes goods have depreciated too much or the end of a season is reached so the retailer has trouble turning these units over. Instead of having them all returned to the vendor, the vendor often will support the retailer in discounting the merchandise.

65

Page 65: Deals - White Paper

Deals Whitepaper

This practice is done for high end fashion items or fast depreciating items like technology based merchandise (computers for example).

The vendor can either support the retailer by contributing a percentage of the retail price discount for each item on hand, or by giving him a fixed amount for all the items he still has in stock.

8.3.4 Vendor Funded Promotion

8.4 Data used for examples

8.4.1 Calendar

First Day Year Month WeekReporting

day Week1 Week2 Week3 Week4 Week5 Quarter

4/1/2002 2002 4 4 4/28/2002 4/7/2002 4/14/2002 4/21/2002 4/28/2002

4/29/2002 2002 5 4 5/26/2002 5/5/2002 5/12/2002 5/19/2002 5/26/2002

5/27/2002 2002 6 5 6/30/2002 6/2/2002 6/9/2002 6/16/2002 6/23/2002 6/30/2002 Q2

7/1/2002 2002 7 4 7/28/2002 7/7/2002 7/14/2002 7/21/2002 7/28/2002

7/29/2002 2002 8 4 8/25/2002 8/4/2002 8/11/2002 8/18/2002 8/25/2002

8/26/2002 2002 9 5 9/29/2002 9/1/2002 9/8/2002 9/15/2002 9/22/2002 9/29/2002 Q3

9/30/2002 2002 10 4 10/27/2002 10/6/2002 10/13/2002 10/20/2002 10/27/2002

10/28/2002 2002 11 4 11/24/2002 11/3/2002 11/10/2002 11/17/2002 11/24/2002

11/25/2002 2002 12 5 12/29/2002 12/1/2002 12/8/2002 12/15/2002 12/22/2002 12/29/2002 Q4

12/30/2002 2003 1 4 1/26/2003 1/5/2003 1/12/2003 1/19/2003 1/26/2003

1/27/2003 2003 2 4 2/23/2003 2/2/2003 2/9/2003 2/16/2003 2/23/2003

2/24/2003 2003 3 5 3/30/2003 3/2/2003 3/9/2003 3/16/2003 3/23/2003 3/30/2003 Q1

3/31/2003 2003 4 4 4/27/2003 4/6/2003 4/13/2003 4/20/2003 4/27/2003

4/28/2003 2003 5 4 5/25/2003 5/4/2003 5/11/2003 5/18/2003 5/25/2003

5/26/2003 2003 6 5 6/29/2003 6/1/2003 6/8/2003 6/15/2003 6/22/2003 6/29/2003 Q2

6/30/2003 2003 7 4 7/27/2003 7/6/2003 7/13/2003 7/20/2003 7/27/2003

7/28/2003 2003 8 4 8/24/2003 8/3/2003 8/10/2003 8/17/2003 8/24/2003

8/25/2003 2003 9 5 9/28/2003 8/31/2003 9/7/2003 9/14/2003 9/21/2003 9/28/2003 Q3

9/29/2003 2003 10 4 10/26/2003 10/5/2003 10/12/2003 10/19/2003 10/26/2003

10/27/2003 2003 11 4 11/23/2003 11/2/2003 11/9/2003 11/16/2003 11/23/2003

8.5 GL setupWe do not have much documentation around this, but basically what needs to happen is the following:

FIF_GL_SETUP needs to be populated. The value of the data does not matter

FIF_LINE_TYPE_XREF needs to contain at least the following:ITEM;Item;ITEMTAX;Tax;TAX

FIF_GL_ACCT needs to be populated as follow:

66

Page 66: Deals - White Paper

Deals - Whitepaper

Primary_account is a unique numberAttribute1…x needs to hold some information, I usually put in position 1, department, position 2, class etc …

You do need to create two records on this table, one for debit and one for credit.So the table could look like this:

Primary Account = 1000Attribute 1 = 12 Attribute 2 = 123Attribute 3 = 1234 Attribute 4 = 10000001Attribute 5 = Debit Primary Account = 1001Attribute 1 = 12 Attribute 2 = 123Attribute 3 = 1234 Attribute 4 = 10000001Attribute 5 = Credit

Then you go online to the GL cross Reference screen (under the finance section), there you define the department, class, subclass, location, tran_code and select Cost for Cost/Retail.

Then you type in EXACTLY (lower and upper case need to be identical) Segment 1… segment 5 in my example.After you have typed in all the Debit side, press search, then do the same with the credit side and you are ready to go. The tran_code I believe is 8 that should be set up.

67