Managers can use trade planning to create and allocate sales quotas, evaluate past offers and create new ones. Sales Representatives use the account planning area of trade planning to monitor offer and retailer performance. Account planning tools include the Activity Summary, Offer Evaluator, Discount Calculator and Offer Worksheets. See Set Up Account and Activity Planning for more details.
Discount planning is also an integral part of trade planning. It involves setting discounts that encourage customers to buy products, while at the same time providing the desired return on investment. By offering discounts, organizations can improve sales, achieve sales targets, and gain competitive advantage. Different types of discounts can be offered based on varying business conditions and scenarios.
Offers in Oracle Channel Revenue Management simplifies the process of discount planning, execution, and tracking. You can plan and create different kinds of offers depending upon the requirements and the results that you want to achieve.
This chapter describes the tasks required to implement and administer trade planning. Implementation tasks are one-time procedures performed during or shortly after installation. Examples include setting profile options, creating and verifying lookup values, and creating users. Administrative tasks are repetitive operations performed post-installation. Examples include creating claim types and reasons, configuring a budget threshold, and creating custom setups.
Sales activities of large manufacturing organizations usually span many territories and regions. Before planning for sales activities, organizations must analyze and set targets for the current year, as well as plan the products and territories to target.
Sales Force Automation tools in Oracle Channel Revenue Management include Quota Allocation and Account Manager Dashboard:
Quota Allocation: Quota Allocation enables manufacturing companies to create and allocate quotas based on realistic data and sales figures of previous years. Sales Management can define markets and products that the sales teams must focus on selling.
Account Manager Dashboard: The Account Manager Dashboard serves as a starting point for sales activities, and a central point of access for real-time information on reports, and statistics. It includes customer reports and statistics that for organizing resources to reach targets. Tools such as Offer Evaluator and Offer Worksheet enable you to create and evaluate offers to obtain the desired return on investments.
The public API, Quota Creation Based on Existing Territory Hierarchies strengthens support for integration with any third party system in any industry.
Oracle Channel Revenue Management provides efficient and cohesive budgeting and financial processing. This eliminates wasteful spending and ensures trade funding is allocated and utilized as intended. You can plan and track fund usage, and ensure that resources are deployed effectively. It offers access to historical sales and pricing information, which you can use to plan for budgets based on facts.
The budgets functionality also supports Oracle Partner Management business flow. Special Pricing, Soft Funds, and Referral compensation requests that are created in Oracle Partner Management can source funds from budgets in Oracle Channel Revenue Management.
Budget management gives organizations a comprehensive tool for planning as well as tracking actual spending, whether accrued or immediately incurred, of sales, marketing and partnering activities. Budget Management includes the budget checkbook view.
You can use the budget checkbook to view actual budget usages, such as expenses or accruals. Companies using Oracle Channel Revenue Management generally write their own reports for specific reporting needs. Oracle Channel Revenue Management enables you to easily create these reports using the materialized views that collect budget utilization data. You can then use this data to create different reports.
Data is collected by
All customer levels - party, account bill to site, account ship to site
Budget attributes - budget, budget category
Time - month, quarter, year
You can also perform the following tasks.
Update General Ledger account when in draft status
Associate General Ledger accounts with budget adjustment type
Review the Budget Public Adjustment and Utilization API
You can use the Oracle Channel Revenue Management dashboard as a single entry point for the iterative selling process. In an iterative sales model sales representatives manage customer accounts and sell products on a continuous and repetitive basis. The features in the Oracle Channel Revenue Management Dashboard that address the iterative selling process include the following:
Features | Description |
---|---|
Offer Worksheet for Lump Sum and Scan Data | Use the worksheet to create lump sum and scan data offers as well as off-invoice, accrual and trade deal offers. |
Account Plan and Dashboard Summary Exposing Budget Information | Without navigating to budget summary, a sales representative can access the dashboard to see his customer accounts’ budget utilized, earned, paid and outstanding accrual balance. The budget information a sales user can see is limited to the customers (accounts and/or sites) within his territory. This information will be exposed both on the dashboard summary view as well as from within an account plan. |
Configurable Related Links | Quick links are configurable by an administrative user. There is also a “Report” link that brings you to Oracle Discoverer. |
Trade planning in Trade Promotion Management encourages customers to buy products, and at the same time produces the desired ROI. By offering discounts, organizations can improve sales, achieve sales targets, and gain competitive advantages.
Trade planning tools simplify the process of discount planning, execution, and tracking. You can create different kinds of offers depending on the requirements and the results you want to achieve. You can associate offers with products or campaigns, predict the performance of new offers, and create adjustments to active offers. You can also track and monitor costs and revenues for active offers.
Oracle Channel Rebate provides comprehensive support for all types of promotional agreements. Sales users can create and monitor offers on the Account Manager Dashboard. Additionally, sales administrators, marketing managers, pricing managers and partner managers who have full exposure to set advanced pricing and eligibility rules can also create and monitor offers on the Account Manager Dashboard.
Oracle Channel Rebate includes enhanced flexibility in creating, maintaining, and monitoring volume offers and also offers support for point of sales in volume offers.
Volume offers, whether on an off invoice or accrual basis, are frequently used incentives to customers, buying groups or partners, based on their cumulative purchase volume over a period of time.
To synchronize with modifiers in the Oracle Pricing application Oracle Channel Rebate includes the profile option OZF: Global Flag on Pricing Related Objects.
Feature | Description |
---|---|
Creation for Multiple Customers and Products | Reduces the number of volume offers a user has to create and maintain. In a single volume offer, users can enter different sets of rates for different product categories and products. For more information see Set Up Volume Offer. |
Indirect Sales Support | Oracle Trade Management handles all payment requirements both directly or indirectly, based on Point of Sale data. Volume offers can apply on both direct and indirect sales or a combination of both. |
Expose Pricing Formula | Pricing formula, created in Advanced Pricing, is exposed on volume offers to provide flexibility in handling highly complex pricing and promotion scenarios. |
Org-striping involves segregating areas based on operating units. In real-time scenarios, companies set up different operating units (OU) or business entities for different reasons. These operating units have their own business rules and they function independently. This means that the business transactions of one OU may or may not be accessed by another OU.
You can enable Oracle Multiple Organization Access (MOAC) and use a single responsibility to access multiple operating units. For more information, see the Oracle Channel Revenue Management Implementation and Administration Guide.
The following table lists and describes how Oracle Channel Rebate uses operating units:
Oracle Trade Management Module | Use of Operating Unit |
---|---|
Offers | To synchronize with Modifiers in the Oracle Pricing application, offer in Oracle Channel Rebate and Point-of-Sale Management include the OZF: Global Flag for Pricing Related Objects profile option. |
Budgets | Budgets in Oracle Channel Rebate and Point-of-Sale Management uses Operating Units in the following manner:
|
Price Lists | In Oracle Channel Rebate and Point-of-Sale Management the OZF: Global Flag on Pricing Related Objects profile option determines whether a price list has the global flag checked in the background. The price list header screen contains the global flag for price lists |
Quota | You can use the OZF:Trade Planning Territories Limited to Operating Unit profile option to create and maintain territories for Channel Revenue Management thus enabling you to segregate territories by operating unit. This eliminates the requirement of setting up all territories with account sites as matching attributes. You can set this profile option at the site level. This profile option can handle either org-specific or non-org specific quota allocation. |
Dashboard | The OZF:Trade Planning Territories Limited to Operating Unit profile option enables the Trade Management dashboard to expose sales orders within one or multiple operating units. The account’s account site for all operating units (plus any other matching attributes) will be derived for the territory, and sales data will be based on those sites. |
Org striping enables you to restrict offers, budgets, and price lists to the respective operating units. By org-striping offers, budgets, and price lists, you can:
Apply offers to orders within the same operating unit as the offer
Use budgets for funding trade promotion activities within the same operating unit as the budget
Apply pricelists to products within the same operating unit as the pricelist.
In org-striped offers, budgets, and pricelists, the operating unit details are derived from the MOAC profile options, MO:Default Operating Unit.
Note: Org-striping does not affect offer security. Offer ownership and group access determine the offer security.
Offers, budgets, and price lists include global flags that determine whether an offer, budget, or pricelist can be applied only within the same operating unit or not. You can control the global flag by setting the OZF: Global Flag on Pricing Related Objects profile option at site, application, responsibility, and user levels. The profile option and the global flag work together with the QP: Security Control Profile that is set in System Administrator > Profile > System. The profile option is owned by Advanced Pricing.
You can set the OZF: Global Flag on Pricing Related Objects profile option to determine whether the global flag will be checked by default for an offer, budget, or pricelist. For the values of this option refer to the Profile Options for the Trade Planning Category section.
Only administration users within the AMS: Admin Group can view and update this flag.
The following table describes the impact of org-striping on different offer types.
Offer Type | Direct Sales | Indirect Sales |
---|---|---|
Accrual, Off-invoice, Trade Deal, Order Value, Terms Upgrade, Volume Accrual, Volume Off-invoice, Promotional Goods offer | The offer applies to orders in different operating units, except in the following cases:
|
Same as the conditions that apply for direct sales. The Global flag on each modifier or price list should be checked. |
Lump sum, Scan Data offer | No impact on offer execution or performance activity validation. The performance activity specified in a Lump Sum or a Scan Data offer automatically validates order volumes before claims are settled. The offer and the claim are specific to an operating unit, and hence validation takes place only on orders of that particular operating unit. |
No impact on offer execution or performance activity validation. The offer utilization does not vary based on indirect sales data. The performance activity for a Lump sum or a Scan Data offer does not have the ability to validate indirect sales data. |
Net Accrual offer | If QP profile is set to On, and the global flag in the Net Accrual offer is:
|
-NA- |
Offers created for Oracle Partner Management purposes | If the offers created for Oracle Partner Management purpose should be global, then either the QP: Security Control profile at the site level should be set to Off, or the OZF: Global Flag on Pricing Related Objects profile option at the application level for PRM should be set to Yes. | -NA- |
Org-striping has no effect on Fixed Budgets, and budget integrations with Oracle Marketing and Oracle Partner Management.
Org-striping has the following impact on Fully Accrued Budgets:
Fully Accrued Budget - Sales:
The total balance is accrued based on the offers and orders that are executed in the same operating unit as the fully accrued budget. The budget balance can be used to fund trade promotion activities in other operating units. Org-striping does not have any impact on budget-offer validation.
Fully Accrued Budget - Customer, Liability Flag ON:
The total balance is accrued based on offers and orders that are executed for customers in the same operating unit as the fully accrued budget.
Accrual offers or volume offers are created automatically based on whether the customers place single purchase orders or cumulative purchase orders. In these cases, the impact on the budget is the same as the impact of org-striping on accrual and volume offers.
Fully Accrued Budget - Customer, Liability Flag OFF:
The total balance is accrued based on offers and orders that are executed for customers in the same operating unit as the fully accrued budget. Only the customer specified on the budget can claim the accrued money.
Only users with the Administrator responsibility can view the global flag on OZF: Allow updates to Price Lists Created in Advanced Pricing from Trade Management. Regardless of the global flag setting of a pricelist, the organization of a product is not validated when the product is added to the pricelist.
In Oracle Channel Revenue Management, territories are not org-specific; an operating unit can span multiple territories. Org-striping quota allocations and account manager dashboard enables you to:
Segregate territories by operating units for quota allocation:
Irrespective of the territories, sales data of the same operating unit as the quota, is used for quota allocation. This option is useful for companies that have multiple operating units and segregate sales activities by operating unit rather than territories.
Display sales data within the respective operating unit:
Sales data within the respective operating unit is displayed on the dashboard. The data specific to the operating unit is used for target allocation.
Details of the default operating unit are derived from the MOAC profile option, MO: Default Operating Unit.
OZF: Trade Planning Territories Limited to Operation Unit
The OZF: Trade Planning Territories Limited to Operation Unit profile option enables you to make quotas and account manager dashboard org-specific. You can set this profile option at the site level with either of the following values:
Yes: Territories are segregated by operating units. This ensures that:
Quota allocations are based on the past sales orders that are executed in the operating unit specified in the territory hierarchy.
The account manager dashboard displays sales data of customer accounts in the specific operating unit across territories.
No: Territories are not org-specific. Quota allocations and the sales data displayed on the account manager dashboard are based on the past sales orders of products irrespective of the operating unit.
Use this profile option in scenarios where territories are defined with non-org specific matching attributes such as customer accounts. For org-specific matching attributes such as customer account site, the operating unit by default restricts the matching attribute list of values.
Org-striping enables you to allocate quota based on sales data of specific operating units rather than territories.
For example, Vision Industries has two operating units, Vision A and Vision B. The quota allocation is based on the territory hierarchy that is created under Vision A. A customer of Vision Industries, Bigmall, has two accounts, Account A1 in Vision A, and Account B1 in Vision B. The following table describes the manner in which the historical data is used based on whether the OZF: Trade Planning Territories Limited to Operation Unit profile option is set to either Yes or No.
Profile option Setting | Territory Transaction Matching Attributes | Historical Sales Data Used |
---|---|---|
Yes | Bigmall | Sales data of Account A1 |
Yes | Account A1 | Sales data of Account A1 |
No | Bigmall | Sales data of Account A1 and Account B1 |
No | Account A1 | Sales data of Account A1 |
Important: In the above example, if the profile option is set to Yes, then the customer account--Account B1 is not included in the territory hierarchy that is defined in Vision A. This is because the LOV of the matching attribute, "Account Site" is restricted by operating unit.
Org-striping has no effect on quota creation or quota access. The OZF: Trade Planning Territories Limited to Operation Unit profile option does not determine access levels. Even if the profile is set to Yes, users with the Administrative responsibility can access quota allocations in the respective territory hierarchy.
The OZF: Trade Planning Territories Limited to Operating Unit profile option determines whether data of a specific operating unit or all operating units should be displayed on the dashboard.
Note: Regardless of the profile option setting, if a territory has org-specific matching attribute such as a customer account site, then the territory is defined exclusively for a specific customer account. In such scenarios, sales data is derived based on the account site and any other matching attribute.
The Oracle Trade Management account manager dashboard can display budget data. Along with access to budgets that they own, dashboard users can also view balances of budgets created by other owners and teams.
For example, the marketing department in Vision Industries creates a budget to execute a campaign. All customers are eligible to participate in this campaign. The marketing department is the owner of the budget. For security reasons, Julie, a trade management sales representative, cannot be a team member of this budget. However, Julie can view budget balances of customers that are assigned to her.
Oracle recommends that you set certain system profile options so that Channel Rebate functions properly. Select the settings that meet your business requirements. This section lists the profile options used for budgets, offers, and price lists. by profile option category. For more information on profile option categorization, see the Oracle Channel Revenue Management Implementation and Administration Guide.
Profile options enable an organization to configure the application to suit business requirements. Some profile options are required and some are optional. Most profile options have preset default values that you can change as needed.
To implement budgets for Trade Management, set the profiles listed in the following table. For the specific procedure for setting up system profile options, see Setting Profile Options in the Oracle Channel Revenue Management Implementation and Administration Guide.
Profile Name | Required | Level | Setting | Default | Description |
---|---|---|---|---|---|
OZF : Allow committed budget to exceed total budget | No | Site Appl Resp User |
Yes/No | No | If set to Yes, the committed amount for a budget can exceed its total budget amount. Set it to yes if you intend to use “budget” for initial sourcing but do not want to impost strict control over its usage. In such cases, the committed amount serves as an estimate for how much you will spend. Using this profile value, a budget may become negative. For example, there is more money spent/utilized than there is available. If set to No, the committed amount may not exceed the total budget amount. Set to no if you intend to use budget not just for sorting but also for imposing financial control over budgetary usage. |
OZF : Allow Recalculation of Committed Budget | No | Site | Yes/No | No | Re-Calculated Committed is an option to re-calculate the necessary funding level based on the actual sales performance of a promotion (for example, offer). Funds can be increased or decreased. If the promotion performs well, funding can be automatically increased, and vice versa. If set to Yes the concurrent process (for recalculate commit) will perform re-calculation of offers' committed amounts. If set to No re-calculation will not be performed. Users are still able to see the Re-Calculated Committed budget column, it will simply be equal the Committed column. |
OZF : Budget Adjustment Grace Period in Days | No | Site Appl Resp User |
Enter any integer (for number of days) | 10 | Reconciliation is a way to return the following money at the completion of an offer: Adjusts previously committed, but unutilized funds - transferring them from the Committed column to the Available column (“Reconcile Unutilized”). Adjusts previously utilized, but unpaid funds, - thus adjusting the Utilized column accordingly as well as transferring it from the Committed column to the Available column (“Reconcile Unutilized and Unpaid Earnings”). Budget reconciliation may be performed manually or automatically. If automatic: The Release Committed Budget Amount After Grace Period concurrent program is used to reconcile budgets. This program waits before reconciling the sourced budgets of an object after the closing date of the object. If manual:The offer is evaluated on a case by case basis. Use automatic if you would like to systematically reconcile the budgets. |
OZF: Budget has Grace Period | No | Site Appl Resp User |
Yes/No | Yes | Yes indicates that budgets can have grace periods. |
OZF: Create GL Entries for Orders | Yes | Site | Shipped Invoiced |
USD (United Sates Dollar) | Default value is Shipped. This is used to drive order-related accruals in Trade Management for GL entries. |
OZF : Currency Conversion Date for Rollup View. | Yes | Site Appl Resp User |
% | This date is used while converting budget rollup amounts to the user profile currency. | |
OZF : Currency Conversion Type | No | Site Appl Resp User |
Corporate | Used across Oracle Trade Management for default conversion between currencies. This is the currency conversion rate. |
|
OZF : Default Period In Days for recalculating committed budget | No | Site Appl Resp User |
Enter any integer (for number of days) | 1 Day | This profile specifies how often the application recalculates committed budgets. Enter any number greater than or equal to one. For example:
|
OZF : Global Start Date (mm/dd/yyy) | No | Site Appl Resp User |
Suggested Value: "01/ 01/1997" | This profile contains the earliest date you want to populate time structure from. Note that GL calendar should have data from that date onwards, without any breakages. It sets the absolute start date for Trade Management data. All data loaded into the Trade Management transaction tables, which refer time Structure tables, is collected as of this date. Historical data is maintained in Trade Management from this date forward. | |
=ZF : Highest Period Level of Budget Utilization Payment Details | Yes | Site User |
MTD | This profile option determines if month-to-day (MTD), quarter-to-day (QTD), and year-to-day (YTD) funds columns are hyperlinked to transactional details. If the profile value is YTD, then MTD, QTD, & YTD fund columns are hyperlinked to details. If the profile value is QTD, then MTD & QTD fund columns are hyperlinked to details. YTD fund columns display the totals but do not have a hyperlink to details. If the profile value is MTD, then MTD fund columns are hyperlinked to details. QTD & YTD fund columns display the totals but do not have links to details. | |
OZF : Period Type | Month | This profile contains the name of the period as defined in GL, for example ’Month’. Period Type sets the default period type for Trade Management. NOTE: ’x’ Periods make a Quarter and 4 Quarters make a Year. Warning: The value in this profile cannot be ’Year’ or ’Quarter’. Suggested Value: Month. | |||
OZF : Start Day of Week | Monday (2) | This profile sets the starting day for a week (for example, Sunday or Monday). For example, if you select 2 the Week starts every Monday. Note: Name of week always has end date of week. Suggested Value: 2 | |||
OZF : Source From Parent Object | No | Site | Yes/No | Yes | This applies to the following objects:
|
OZF : Universal Currency for Budget Rollup View | Yes | Site | Choose any valid currency from a list of available currencies | USD | This profile determines the currency for the roll-up view. It allows the roll-up view of a budget to display correctly by converting all entries to a single currency. Different users will, however, be able to see the Rollup View in different currencies based on the user level profile option JTF_PROFILE_DEFAULT_CURRENCY. (In other words, the universal currency profile is simply for storage in the background). Once set, the profile should not be changed. |
OZF: Validate market and product eligibility between object and budget | No | Site Resp |
Choose a Value | No validation for customers and products. | Values are: No validation for customers and products. Validate customer and products by each budget. Validate customer by each budget, product by all budgets. Validate product by each budget, customer by all budgets. |
The table below lists profile options for the System Defaults category of OZF_SYSTEM_DEFAULTS that relates to Channel Rebate.
Profile Name | Required | Level | Setting | Default | Effect/Limitation |
---|---|---|---|---|---|
OZF : Default "Accrue To" for Volume Offer | Yes | Appl Resp Site User |
Enter a correct value. | Account | Value to default for the "Accrue To" market option for a Volume offer. |
OZF : Default Budget For a Person | Yes | Appl Resp Site User |
Choose a budget name from the list of available budgets | Valid budget name | During budget request for all objects, users may decide to source from a Budget or from a Person. When sourcing is made to a person, the system will automatically default the budget name specified on this profile on to the budget request. Users will be able to change it on screen. |
OZF: Default Partner Budget | No | Appl Resp Site User |
Choose a budget name from the list of available budgets. | Valid budget name | Default budget for a partner. |
OZF : Default Price List for ROI Calculation | Yes | Appl Resp Site User |
Valid price list defined in the system | Corporate | The value specified here will be used in calculating the default Return on Investment for a given offer forecast. |
OZF : Default Team for Offers | Optional | Appl Resp Site User |
Select the team from the LOV in the profile option. | Valid team name | This profile option indicates the team that can access an offer. If this option is not set, then offer users can select the teams that can access the offer. |
OZF : Default Tracking Level for Volume Offer | Appl Resp Site User |
Account | Value to default for the "Volume Tracking Level" market option for a Volume Offer. | ||
OZF : Default value for "Combine Discount Tables" in Volume Offer | Appl Resp Site User |
No volume | Value to default for the "Combine Discount Tables" market option for a Volume offer. | ||
OZF : Default value for Retroactive Flag in Volume Offer | Appl Resp Site User |
No | Value to default for the "Retroactive Flag" market option for a Volume offer. | ||
OZF : Default View of Customer's Budgets | No | Appl Resp Site User |
Yes/No | No | If set to Yes, you can see the Budget Customer View button from the Budget summary page. |
OZF : Scan Data UOM | Yes | Appl Resp Site User |
One of the available UOMs | Each | The default UOM value for discount rules for Scan Data offers. For example, if you choose Each, then all empty discount rules in Scan Data offers will display the UOM of Each. |
The following table lists and describes the system profile options that must be set for Trade Planning to function properly. Select the settings that meet your business requirements. Most offers, except for lump sum and trade deals) leverage Advanced Pricing.
For the specific procedure for setting up system profile options, see the Setting Profile Options section in the Oracle Channel Revenue Management Implementation and Administration Guide.
Profile Name | Required | Level | Setting | Default | Effect/Limitation |
---|---|---|---|---|---|
Common Currency for Trade Management | Yes | Site | Currency Code | USD (United States Dollar) | Required to perform quota allocations based on a territory hierarchy. |
OZF: Common Unit of Measure for Trade Management | Yes | Site Resp |
Set appropriate- ate value | Each | Required to perform quota allocations based on a territory hierarchy. Select the appropriate value. All automatic currency conversions use the rates defined in the conversion type entered in this profile. |
OZF: Dashboard Baseline Sales Source | Yes | Select the correct value | Source of Baseline Sales for Account Manager Dashboard | ||
OZF: Days from Offer End Date to Start Auto Payout | 10 Days | This is the default number of days to wait after Offer's completion. | |||
OZF : Default Currency Code | No | Enter the correct value. | USD (United States Dollar) | Budgets can be created in multiple currencies. Oracle Trade Management automatically performs currency conversion based on the rates defined in this profile option. | |
OZF: Default Forecast Period Type | Month | A profile option on which forecast time spread calculation is based. | |||
OZF : Degree of Parallelism-Src | Enter a positive integer. | 1 | This profile is used for performance reasons. For example, running Oracle Trade Management on multiple servers saves processing time. Enter a positive integer such as 1, 2, 5 to reflect the number of processes that you want to run simultaneously. The suggested value is 1. | ||
OZF: Global Flag on Pricing | Global Flag checked | Global flag Checked | Offers, budgets, and pricelists include global flags that determine whether an offer, budget, or pricelist can be applied only within the same operating unit or not. You can control the global flag by setting this profile option, at site, application, responsibility, and user levels. The profile option and the global flag work together with the QP: Security Control Profile that is set in System Admin > Profile > System. The profile option is owned by Advanced Pricing. You can set this profile option, to determine whether the global flag will be checked by default for an offer, budget, or pricelist. The consequences of this option are:
Important: If the QP:Security Control profile is set to OFF, the offer, budget, or pricelist can be applied across all operating unit regardless of whether the global flag is checked. To restrict offers, budgets or pricelists to transactions in a specific operating unit, you must first set the QP:Security Control profile to ON. The global flag only provides an additional level of control. |
||
OZF : Global Start Date (mm/dd/yyy) | Site Appl Resp |
Suggested Value: "01/ 01/1997" | This profile contains the earliest date you want to populate time structure from. Note that GL calendar should have data from that date onwards, without any breakages. It sets the absolute start date for Trade Management data. All data loaded into the Trade Management transaction tables, which refer time Structure tables, is collected as of this date. Historical data is maintained in Trade Management from this date forward. | ||
OZF : Keep historical data for Baseline Sales and Promotional Lift Interface Tables | No | A profile option to determine whether to keep historical data for Baseline Sales and Promotional Lift. | |||
OZF: Number of months to trend ship to volume for baseline calculations | Insert correct value between 0 and 100 months. | 12 months | Use this profile option to override using a value between 0 and 100 months. If a new product has no ship-to history (or the profile option is set to zero for all products), then the baseline is distributed evenly among the ship-tos. | ||
OZF: Period Type | Month | This profile contains the name of the period as defined in GL, for example ’Month’. Period Type sets the default period type for Trade Management. NOTE: ’x’ Periods make a Quarter and 4 Quarters make a Year. Warning: The value in this profile cannot be ’Year’ or ’Quarter’. Suggested Value: Month. | |||
OZF: Process Net Accrual In Batch Mode | Yes | Site | Yes or No. | No | Default value is No. This profile determines if the Net Accrual Engine should generate accruals once for every time the program is run or for each transaction. |
OZF: Start Day of Week | Monday | Start_day of week: OZF_TP_START_DAY_OF_WEEK. The day of the week selected here is the day on which your financial week will begin. Only values of 1-7 are valid; they correspond to the days of the week, Sunday through Saturday. For example, choosing 2 means that the week starts on Monday (which is the suggested value). | |||
OZF : Store Date in Qualifiers | Yes | Site | Yes or No | Yes | Specifies the location to store date qualifiers in offers. If set to Yes, the date qualifier (for example, shipping date) is stored in the qualifier. If set to No, the date qualifier is stored in the header. |
OZF: Territories Limited to Operation Units | Yes | Site | Yes/No | Yes | Use this profile option to determine whether quota allocation will be org-specific or non org-specific. The default is set to No to ensure that all quota/dashboard functions work the same. This profile enables you to create and maintain territories for Trade Management purposes so that you do not have to set up all territories with account sites as matching attributes simply to work around the issue of not being able to segregate territories by operating units. Using this profile you can create and maintain territories for Trade Management purposes enabling you to segregate territories by operating unit. This eliminates the requirement of setting up all territories with account sites as matching attributes. For more information see How Oracle Trade Management Dashboard Uses Operating Units and How Oracle Trade Management Dashboard Uses Operating Units. |
OZF: Third Party Accrual Price List (Formerly: OZF: Offer Override Flag in QP |
Yes | Appl Resp Site User |
Enter correct value. | Corporate | This flag specified if offer overriding is allowed in Advanced Pricing.
|
OZF: Treat Discount as an Expense | Yes | Use this profile to determine is a Discount should be treated as an expense for ROI Calculation. | |||
OZF: Validate market and product eligibility between object and budget | No | Site Resp |
Set correct value | No | Validate market and product eligibility between object and budget. Values are: No validation for customers and products. Validate customer and products by each budget. Validate customer by each budget, product by all budgets. Validate product by each budget, customer by all budgets. |
Quota Allocation By | Quarterly | Use this profile option to determine whether Quota allocation can be done by Quantity or by Amount at a particular site. |
Set the following profile options for Oracle Trade Management UI Defaults:
Profile Name | Required | Level | Setting | Default | Effect/Limitation |
---|---|---|---|---|---|
OZF: Default Amount Formula | Yes | Site | Formula supported in Advanced Pricing | A valid formula from Advanced Pricing | Sets the default formula for a discount rule where Discount Type = Amount. |
OZF : Default Bucket for discount rules | Yes | Appl Resp Site User |
A value from Advanced Pricing Lookup PRICING_ GROUP_ SEQUENCE | Base Price | The default value for the discount rule default bucket. Order in which the modifiers are evaluated. Pricing buckets determine whether multiple offers and Advanced Pricing modifiers cascade from one another. Example: Product A regularly sells for $100. Two offers are created in Trade Management. One gives a 10% discount; the other a 15% accrual. How these offers are calculated in regard to the base price of $100 is based on this profile option setting. For example, the accrual could be calculated based on the net price of $90 (net of the discount offer). |
OZF: Default Forecast UOM | No | Appl Resp Site User |
One of the available UOMs | Each | The default unit of measure (UOM) displayed on the Forecast page |
OZF: Display KPI Alert | Yes | ||||
OZF: Default Offer Activity | Optional | Appl Resp Site User |
Select the required activity from the LOV in the profile option. | Trade Management Activity_Deal | This profile option indicates default offer activity that should be populated on the offer creation page. If this option is not set, then offer users can select the offer activity on the offer creation page. |
OZF : Default Offer Formula | No | Appl Resp Site User |
A pricing formula in Advanced Pricing | A valid formula from Advanced Pricing | The value selected here will be defaulted on offers created in Trade Management. An example of using a pricing formula is to handle discount rules for product categories when the unit of measure is not specified. Handles discount rules for product categories when the unit of measure is not specified. |
OZF : Default Percent Formula | Yes | Site | A formula supported in Advanced Pricing | A valid formula from Advanced Pricing | Sets the default formula for a discount rule where Discount Type = Percent. For example, if the value is set to Handling, then when changing the Discount Type to Percent the value of formula is set to Handling. |
OZF : Default phase for Line Group level discounts | Yes | Appl Resp Site User |
A value derived from Event phase setup in Advanced Pricing | All lines adjustment | The default value for phase for all discount rules with a discount level of Group of Lines. Please see OZF : Default phase for Line level discounts above for a description of phase. |
OZF : Default phase for Line level discounts | Yes | Appl Resp Site User |
A value derived from Event phase setup in Advanced Pricing | All lines adjustment | The default value for phase for all discount rules with a Line discount level. The phase in Advanced Pricing determines the timing of when offers and other modifiers apply, e.g. whether they apply during order booking or shipping. This option also determines how to resolve multiple conflicting offers or modifiers, e.g. by a better price or by precedence |
OZF : Default phase for Order level discounts | All lines adjustment | Pricing Phase ID for Order Level Discount. | |||
OZF : Default Value for incompatibility group | No | Appl Resp Site User |
Choose an incompatibility group from a list of available incompatibility groups set up in Advanced Pricing. | Exclusive Group | Incompatibility Group is setup Advanced Pricing, it determines how promotions will be grouped together and which ones will be applied together with other promotions. A fully accrued budget creates an offer in the background, and that offer will by default have this incompatibility group, so this concerns a fully accrued budget. Users can change this defaulted value while setting up the fully accrued budget. |
OZF: Default value for print on invoice | Yes | Site | Yes/No | Yes | The default for all discount rules. |
OZF : Default value for product precedence | Yes | Appl Resp Site User |
User Defined | 5,000 | The default for all discount rules. Precedence is one of the criteria that can be used to determine which offers or modifiers are to be used when there are conflicts. Precedence is used to resolve incompatibility. Precedence controls the priority of modifiers and price lists. If a customer qualifies for multiple modifiers that are incompatible with each other, precedence determines the discount that the customer is eligible for based on the precedence level of the modifier. Precedence is the final tiebreaker for the determining which offer to apply. A lower value has higher precedence than a higher value. |
OZF: Offer Discount | Yes | Appl Resp Site User |
Line Group of Lines |
Line | The default value for offer discount level. Example: if set to Line, and minimum volume is 5, then each order line must have a minimum quantity of five to get a discount. If set to Group of Lines, then multiple order lines with the same product will be evaluated together to determine whether the offer applies to the order. |
OZF : Root Section For Price List Report | Root |
A quota allocation is a sales goal that must be met within a specific period of time. Quotas are assigned by upper management down a sales team hierarchy based on territory structures that you create.
Quotas can be assigned as a monetary value or by quantity. For example, Ben Johnson, a Sales Representative for ABC Corp., may have to sell $25,000 worth of product during ABC Corp.'s third quarter if he has a quota based on monetary value. If his quota were quantity-based, he might have to sell 1,000 cases of product A and 500 cases of product B during that quarter.
You can also create threshold rules that trigger alerts sent to Sales Representatives (reps) regarding their quotas. These alerts are designed to help keep reps aware of their actual sales performance in relation to their quota.
Before you set up quota allocations and alerts, you must set up the Time Dimension Structure. For more information, See budget profile options for this procedure..
To set up quota allocations and alerts:
To set up territories for quota allocations, follow the instructions listed under Setting Up Territory Manager for Oracle Channel Revenue Management and Setting Up Territories for Budgets.
Guidelines
Territory type = Offer.
We recommend:
Assigning an owner to each territory.
Limiting owner assignment to one hierarchy per person.
If a person owns more than one hierarchy, then there should be no overlap. For example, if a person owns the California hierarchy, containing San Francisco and Los Angeles and also owns the Western Cities hierarchy, the Western Cities hierarchy, cannot also contain Los Angeles.
Owners are referred to as Resources in the Territory Manager instructions referenced above. To designate a resource as the quota owner for a particular level of the hierarchy, select the Primary Contact check box.
These are the three parts of the setup for Quota Allocations:
Set Site level system profile to select amount or quantity
Set System Profiles for currency, unit of measure, and conversion type
Run a concurrent program to update order sales information
As a prerequisite, you should set up territories for quota allocations, before setting up quota allocations.
Important: When a quota allocation that is based on territory hierarchy is published or updated, a workflow notification is sent to the primary contact of the territory node. Therefore, you should assign workflow responsibilities the primary contact of each territory node used for quota allocation. See Creating the Implementation User, Oracle Channel Revenue Management Implementation Guidefor the detailed procedure.
Log into Oracle Forms and select the Oracle Trade Management Administrator responsibility.
Navigation: Setup > Profiles
Profile = Quota Allocation By
Default Value: Quantity
Description: This profile option allows you to choose whether Quota allocation can be done by Quantity or by Amount at a particular site.
Quota allocation type: If you select Amount, then quotas are allocated in the currency specified by the system profile OZF: Common Currency for Trade Management, Oracle Channel Revenue Management Implementation Guide. If you select Quantity, then quotas are allocated based on the unit of measure specified by the profile option OZF: Common Unit of Measure for Trade Management., Oracle Channel Revenue Management Implementation Guide
Log into Oracle Forms and select the Oracle Trade Management Administrator responsibility.
Navigation: Setups > Profiles.
Notes:
System profiles values: Search for the following profiles and assign values to them based on your business needs.
OZF: Common Currency for Trade Management
OZF: Common Unit of Measure for Trade Management
OZF: Currency Conversion type
Concurrent Programs:
Run the Refresh Materialized View for Order Sales concurrent program to update order information. Then run the Refresh Account Manager Dashboard program.
Threshold rules are created to trigger alerts that are sent to salespeople regarding their quotas. These alerts help keep salespeople aware of their actual sales performance in relation to their quota. Based on this knowledge, salespeople can make changes to their account plans to meet their goals.
Threshold rules can be set based on various conditions including:
Month-to-date, quarter-to-date, or year-to-date sales
Total shipments possible
Outstanding, current, future and back orders
As a prerequisite, Oracle recommends that you set up thresholds and quota allocations before creating threshold rules for quota allocation alerts.
Log into Oracle Trade Management.
Navigation: Administration > Trade Management > Thresholds.
Notes:
Threshold type: Quota
Run concurrent programs: Set up the OZF-TM: Validate Budget and Quota Thresholds concurrent program,, to run on a daily basis. See Running Concurrent Programs for this procedure.
When creating a budget, the list of values for the Business Unit field comes from the organizations defined in the HRMS application. For budgets, business units are used:
To classify budgets, and are selected during budget creation
When setting up budget approval rules
To create business units, log on with HRMS Super User responsibility.
Create Organizations of type "Business Unit".
To verify that you have successfully created business units complete the following steps:
Navigate to the budget creation page in Oracle Trade Management.
Open the Business Unit drop-down list and verify that the business units you have created appear in the list.
Budgets can be created in multiple currencies. Although the budget may reflect multiple currencies, Oracle General Ledger postings use the functional currency defined by the set of books specified on the system parameters page. Trade Management automatically performs currency conversion based on the rates defined in the system.
Users can transfer funds to different budgets or request money from budgets in any currency. The source budget are not required to be in the same currency. When users request money in one currency, they will also see an approval notification and money transfer in the same currency. Similarly when the budget owner receives a request, the system automatically converts the requested amount to the budget currency. The budget owner then approves the amount in the budget currency.
Currency conversion for each transaction is recorded based on the currency conversion type specified by the OZF: Currency Conversion Type profile option. This profile is set at the site level. When viewing the budget, you will see both the transaction currency and the budget currency amounts.
For Fully Accrued Budget:
If the global flag is checked- The evaluation order is user, responsibility, application, and site. When passed to Advanced Pricing , the underlying modifier should have this flag checked so that the budget is applicable for all operating units. The default for profile at the site level is to have global flag checked.
If the global flag is unchecked - The evaluation order is the same as above. If the global flag is unchecked and the Advanced Pricing Security Control profile option is set to On, then the budget will be considered only for the sales orders in the operating unit that created the budget to begin with.
When you create a new budget in Oracle Trade Management you must associate a Ledger (Set of Books) with the budget you are creating. This ledger value drives the General Ledger accounts and the accounting for the budget.
Note: The information in this section is valid for both Fixed and Fully Accrued Budgets.
In Oracle Trade Management, the ledger ID values listed in the ledger LOV field on the budget creation screen are controlled by the data access set associated with the responsibility. A data access set is assigned to a responsibility to control which ledgers and balancing and management segment values you have access to when you log onto a responsibility.”
The Organization ID on the sales order against which the accruals are generated is validated against the Organization ID associated with the Ledger on the budget. If the two Organization IDs do not match, the system rejects the record and does not create any utilizations.
Once the budget is active, the ledger ID field is frozen for all users except Oracle Trade Management Administration users who can change the accounts on an active budget. They can change General Ledger accounts within the same ledger ID.
When you create accruals, the Organization ID is determined as follows:
Offer Type | Organization ID |
---|---|
Accrual, Off Invoice, Trade Deal, Terms Upgrade, Promotional Goods, Order Value, Volume Offer, or Net Accrual | When you create a sales order in Oracle Order Management, the Organization ID is stamped on the sales order. |
Scan Data, Lumpsum | The Organization ID is associated in Trade Management when you crate an offer. |
The following information explains how to set up budget categories and budget thresholds. These are required steps for creating a budget.
Budget categories are used for the following: purposes:
Classification
Approval rule setups
General Ledger account defaults
Specifying multiple sets of books
To create categories for budgets, log in to Oracle Trade Management.
Navigation: Administration > Trade Management > Setup > Category > Create.
Notes:
Created for: Select Budget.
Enabled: Select to make the category available.
Sales/Expense/Charge Account, and Liability Account: These accounts are used for GL postings. The Sales/Expense/Charge Account and the Accrual Liability Account are account flexfields. For information on the Ledger field see Associating a Ledger With a Budget.
Prefix: The prefix you enter is added to the budget numbers that are generated automatically.
Channel: Optional. Activities are created using the activity page under the Administration tab. For more information, see Creating Activities.
Budget thresholds enable companies to:
Set budget rules
Send budget alert notifications
Inform users of fund usage
Inform user of depletion at various level
These rules and parameters defined in the budget threshold are assigned to a budget.
Threshold Example: if a promotion has just started and has already used up 90% of a budget, more funds may need to be transferred in.
Threshold Rule Example: A rule may be set up to send e-mail alerts to budget owners when actual expenditure is >= 90% of committed.
Budget thresholds can be based on the following amount types:
Planned
Committed
Re-Calculated Committed
Utilized
Earned
Paid
Budget balance (Available - Committed)
To set up a budget threshold, use the following procedure, log in to Oracle Trade Management.
Navigation: Administration > Trade Management > Setup > Thresholds > Create.
Notes:
Threshold type: Select Budget.
Name: The name of the budget threshold will appear on the budget details page threshold LOV and can be assigned to a particular budget.
Start and End Periods: These are periods defined in the Accounting calendar. If specified, they will limit the start and end dates that can be entered below.
Owner: Defaults to the user creating it. This is for used for tracking purposes only.
Threshold Rules:
Off Baseline: Values available are determined by the value limit you select.
Period Type: Select Days, Weeks, Months, Quarters and Years.
Together with Frequency, these define how often the budget owner will receive the notification within the Start and End dates of the line, once the threshold condition is met. If you enter Frequency = 2 and Period Type = Weeks, it means a budget owner will get a notification once every two weeks once the threshold condition becomes true, until the end date of the threshold line.
When you make adjustments to a budget you can specify the sales and liability account that you want to use for a particular budget adjustment type. The Budget Adjustment Type details screen contains the Sales/Expense Charge Account LOV and the Accrual Liability Account LOV.
The accounts defaulting mechanism is applied in Oracle Trade Management as follows:
For every adjustment created to a budget, the General Ledger accounts used for accounting purposes will be defaulted in the following order:
Budget adjustment type
Budget
System Parameters
The following information explains how to set up budget approval rules in Oracle Trade Management. It also explains budget system status and user status in Oracle Trade Management.
Approval rules are created to determine who approves budgets and under what circumstances. Approval rules for budget/root budget requests and transfers are evaluated based on the following:
Organization = 5
Approval Object Type = 3 (budget category)
Custom Setup = 1
The higher the number, the more important the parameter is in determining which approval rule will apply to a particular budget.
Root budget approval is always required unless 1) a child budget is submitted for approval and the owner also owns the parent budget, and 2) the sole approver is the budget owner.
Request: A budget or offer requests fund from another budget.
Transfer: A budget or offer is transferring money to another budget.
Approval requirements are based on custom setups. Approval notifications are routed regardless of the responsibility the users have to access the notification. E-mail notifications can be used.
Two types of budget approval rules can be created:
Rules where the budget request or transfer must always be approved. These rules are defined in the user interface.
Rules where budget requests and transfers can be approved automatically if they are under a certain amount.
Use the following procedure to create budget approval rules.
Log into Oracle Trade Management.
Navigation: Trade Management: Administration > Trade Management > Setup > Approval Rule.
Click Create.
Select a value for the Approval Rule for field:
Root Budget Request to define a rule for root budget request approvals.
Budget Request to define a rule for budget request approvals.
Budget Transfer to define a rule for budget transfer approvals.
The page redraws and the fields might change.
Complete the page as required for your business needs.
Start Date: The date when the rule becomes effective.
End Date: The date when the rule will no longer be used.
Organization: Displays a list of operating units
Setup Type: Custom setups created for budgets
Click Create.
The page refreshes and an Approvers table appears.
In the Approvers table, specify the individuals who must approve this type of budget request or transfer.
Order: Enter any integers in ascending order.
Type: Select Function (for customized approval process), Role (defined for Trade Management and assigned to Resources - there can only be one person assigned to a Role), or User.
User/Role: Depending on the Type selected above, you will see a list of functions, roles or users.
Start Date: The date when the approval rule becomes active. Within the range of the approval rule, each line can also have a start date and end date.
End Date: The date when the approver is no longer active.
Click Update.
Ensure that the following concurrent processes are run. They find the correct rule and route the approval notification.
Workflow Background Process: Marketing Generic Approval (for root budget approvals)
Workflow Background Process: Marketing Approval (for budget request and transfer approvals)
The page redraws and the fields might change.
For more detailed information about budget approval see the section titled Budget Approval Process in the Trade Management User Guide. That section also describes the different statuses that a budget can go through.
Users can set rules for themselves in Workflow to automatically approve budgets under a certain amount.
To create automatic budget approval rules in Oracle Forms, log into Oracle Forms and select the Workflow responsibility.
Navigation: Notification Rules > Create Rule.
Steps:
Select AMS: Marketing Generic Approvals
Select approval Required: [Approval Subject]
Click Respond.
In the Approved Amount field, enter an amount (no commas). All budgets under this amount will be approved automatically by this individual.
Action = Approve.
Workflow Background Process: Marketing Generic Approval (for root budget approvals)
Workflow Background Process: Marketing Approval (for budget request and transfer approvals)They find the correct rule and route the approval notification.
For additional information about Approval Rules, see Budget Approval Process in the Oracle Channel Revenue Management User Guide.
A budget goes through the following main system statuses:
Draft: Amounts are entered but not approved
Pending Approval: Being reviewed but needs approval to become active.
Active: Has been activated and can be used to fund activities.
Approval rules are used to determine the route from Draft to Active. Approval rules are highly configurable and multiple ones can be created based on the budget's characteristics.
The following table lists budget statuses used in Trade Management and a description of each.
Status | Description |
---|---|
Draft | Budgets in draft status can be updated at any time in any way. Draft status may be updated to Pending Approval or Cancelled. It can also be updated to Active directly in case the budget owner is also the owner of the parent budget, and the parent budget is already Active. |
Pending Approval | The budget has been submitted for and is awaiting approval. After all approvers have responded positively, a budget may become Active or On Hold. If approvers reject the budget it will become Rejected. |
On Hold | On Hold is an interim status that is used when a budget has already obtained approval, and is just not completely ready to be made active. At On Hold status, a user can then manually change it to Active or Closed. |
Rejected | Budget approvers have rejected the budget. From Rejected, the status can be manually changed back to Draft. |
Active | The budget has been approved and is ready to fund various activities and promotions. From Active, the status can be changed to Closed and Cancelled. |
Cancelled | Indicates that the budget has been aborted. From Cancelled, the status can only be changed to Archived. |
Archived | Indicates that the budget can no longer be used. This cannot be changed to any other status. |
Closed | From On Hold or Active, the Budget status can be manually changed to Closed. It indicates that the budget has ended and is no longer available to fund activities and offers. |
The following information provides the Oracle Trade Management setup information for budget allocation.
Budget allocation enables a company to allocate money to each sales territory for the salespeople to spend. Allocation can be based on:
Even Distribution: This is derived by dividing the total allocation amount by the number territories selected.
Manual: Enters any number manually.
Prior Year Sales: A proportionate split is calculated to allocate the money for the current year.
To set up budget allocation based on Prior Year Sales, run the OZF : Refresh Materialized Views for Order Sales concurrent program. Budget allocation makes use of Territories set up in Territory Manager, so it is also necessary to import the territories for Trade Management purposes.
For more information about setting up Territories see the chapter titled Setting Up Territories in the Oracle Territory Manager Implementation Guide.
For more information about concurrent programs, see the Concurrent Programs for Channel Rebate section..
Important: When a budget allocation that is based on territory hierarchy is published or updated, a workflow notification is sent to the primary contact of the territory node. Therefore, you should assign workflow responsibilities to the primary contact of each territory node used for budget allocation. See Creating the Implementation User, Oracle Channel Revenue Management Implementation and Administration Guide in this manual for the detailed procedure.
Budget amounts allocated from management down to lower levels is a top-down budgeting process. Budget amounts rolled up from lower levels to management, is a bottom-up budgeting process.
Oracle Trade Management enables you to automate the time-consuming budget process by facilitating communication between management and sales people at all levels in the sales hierarchy.
Top-down Bottom-up Budgeting the budget is allocated to various users within a territory hierarchy based on the territory's historical sales data. The budgeting process in Oracle Trade Management also enables users to submit feedback or negotiate a different allocation
For more information on Top-down and Bottom-up budgets see the section titled Top-down Bottom-up Budgeting in the Oracle Trade Management User's Guide. This section explains the entire top-down bottom up budgeting process, starting from creating a budget and allocating it, to reviewing inputs and activating the allocation.
The following sections describe information required to setup budget offer validation, budget requests, and budget adjustment types.
Budget-offer validation validates that the market and product eligibilities of an offer fall within the targets of the budget. This option ensures that funds set aside for specific customers and products are used appropriately.
To set up budget-offer validation, set the OZF: Validate market and product eligibility between object and budget profile option to one of the following values at the site and responsibility levels.
No validation for customers and products: validation does not happen.
Validate customer and products by each budget: market and product eligibilities for the budget and offer must match.
Even if different parameters are used for defining eligibility. In the case where a budget uses Territories, but the offer uses Customer, the validation procedure can determine whether the offer meets budget criteria. For example, a budget says “US West” territory, but the offer says “Business World”. The procedure can determine whether or not the US West territory includes the customer Business World.
Validate customer by each budget, product by all budgets:
This validation option is useful in the following scenario. A sales representative is responsible for selling multiple products to a single customer account. These products belong to different brand managers, and each brand manager has his own budget, so if the sales representative wants to request funding for his promotion, he may request funds from multiple brand managers.
In such cases, it does not make sense to mandate that each brand manager's budget must cover all of the products in the promotion. Each budget should cover some products, but in total, all of the brand managers' budgets should cover funding for all products in the promotion. For example, a sales representative who sells regular cola and sports drinks to Bigmart, may in addition to his own funds also request the brand manager for regular cola to fund his promotion as well. The system should not fail the validation because the regular cola budget does not cover sports drinks.
Validate product by each budget, customer by all budgets:
In this scenario, a sales representative is promoting a particular product to multiple accounts in his territory and is requesting funding from budgets created specifically for some bigger accounts. For example, he is promoting product X to both Goodway and Bigmart, and in addition to funding it from his own budget, he may also request money from a bigger budget set aside for Bigmart nationally. In this case, the system should not fail the validation simply because the Bigmart national budget does not cover Goodway.
Validation occurs at the same time for both market and product eligibilities. If validation fails, an error message is sent to the offer owner. The status of the offer reverts to Draft.
The Funds Accrual Engine program handles Accrual Management capabilities in Oracle Trade Management.
This engine enables you to calculate Budget Accrual Liability. All features listed below are implemented through the same concurrent process. Ability to calculate budget utilization and earnings based on ship confirmed orders.
Ability to calculate budget utilization and earnings based on booked orders and ship confirmed orders.
In case of Fully Accrued type of budgets with accruing to Customer, the Budget, Committed and Earned columns are to be updated with the accrued amount. But in case of budgets that accrue to Sales; only the Budget column is updated. Committed and Earned are not populated. This allows users to transfer money from a fully accrued budget to any other fixed budgets.
Ability to reconcile budget utilization and earnings when an order is cancelled. When an order is cancelled, running the concurrent process reconciles the already adjusted budget amount.
Ability to reconcile budget utilization and earnings when an order is returned When an order is returned, running the concurrent process reconciles the already adjusted budget amount.
Volume Offers, whether on an off invoice or accrual basis, are frequently used incentives to customers, buying groups or partners, based on their cumulative purchase volume over a period of time. Volume offers are common in all industries and can apply on both direct and indirect sales data.
The Oracle Trade Management Volume Offer feature reduces the number of volume offers you need to create and maintain. Using a single volume offer you can accomplish the following:
Enter different sets of rates for different product categories and products.
Enter different customers, with the option to either track their volume together (as in a buying group scenario) or maintain volume tracking separately for each customer.
Pre-qualify a customer included in the offer to a higher volume tier. A multiple tier offer begins applying the next higher tier rate as soon your volume crosses the threshold. You will not be eligible for the increased benefit of a higher tier until your volume moves into the next higher tier. For example, your discount is 5% on volume that falls within 1 to 100 units but will increase to 6% when volume falls within 1-1 to 200 units.
Apply volume offers on indirect sales data or a combination of both.
An Discount Table in Oracle Trade Management supports volume ranges, discounts and product and category selections.
Note: One volume offer can support multiple discount tables.
Discount Tables include the following features:
You can define one or more discount tables may be defined for each volume offer.
At draft status, you can add, delete or copy discount tables.
You can copy a Discount Table and give it a new name.
In the following example you can use one volume offer to cover multiple discount tables for different products.
In this example, Company Z sells 4 product lines to thousands of customers. With each of its top 100 customers, its sales managers negotiate an annual volume rebate promotion. These promotions may factor in sales growth objectives. For example, a customer’s purchase volume last year may be $5 million; to incentivize the customer to exceed that volume, a volume rebate may be created that offers an extra rebate if volume exceeds $5 million.
Although each customer’s promotion is similar to all the others, each customer gets a different set of rates for different product lines. Ideally Company A would like to create just one volume offer per customer. The following table shows how Company A can create one volume offer to cover the scenario described above.
If Product is | Volume falls within: | Offer Discount: |
---|---|---|
A | $1-$5 million $5-$6 million |
3% 4% |
B | $1-$10 million $10 million + |
3.5 % 4% |
C and D combined | 1-150,000 cases 150,001-175,000 cases 175,000 cases + |
$0.25 per case $0.30 per case $0.35 per case |
Promotional offers to customers may span multiple fiscal periods. During the changeover of fiscal periods, new budgets will be established, while the old ones reach end date. Since the offers may not be fully utilized in the old period, they will continue to be executed. Utilizations of these offers that happen in the new period should be tracked in the budgets in the new period.
Run the OZF-TM : Unutilized Commitment Mass Transfer concurrent program to automatically create new budgets for the next fiscal period and optionally transfer all unutilized budgets to the new budget. You can use several parameters to define their query criteria to pick up the budget.
You can use budget mass transfers to:
Define query criteria through personalization for mass transfer budgets
Select a budget for transfer from saved query or budget lists
Create a new budget for itself or its hierarchy
Create new budget with the same budget amount or zero budget amount
Activate a new budget automatically when the old budget's end date is reached and new budget is still in draft status
Transfer an unutilized budget automatically when the old budget end date is reached
Activate new budgets manually
View the link between the old budget and the new budget
The concurrent program automatically creates new budgets for the next fiscal period and optionally transfers all unutilized budgets to the new budget. You can use several parameters to define their query criteria to pick up the budget.
When you open a next year's budget by running the above concurrent program. He can change the budget amount of the new version and submit it for Approval.
While running above concurrent program, if the old budget's end date is reached and new budget is still in "Draft" status, the new budgets will be activated automatically with budget amount zero.
While running above concurrent program, if the old budget's end date is reached and new budget is in Active status, the unutilized budget amount from old budget will be transferred to new budget. If the old budget's end date is reached and new budget's budget amount is zero, the transferring unutilized will occur depend on the profile setting.
When you use the Budget Public Adjustment and Utilization API you must create different adjustment types if you want to distinguish original accrual versus subsequent adjustments. The adjustment type name can handle X characters.
This API prorates the adjustments among the budgets from which the offer is sourced. For example, when an offer is sourced from multiple budgets and the adjustment record does not refer to any one particular budget as a target for the adjustment, the API will identify the budgets used to source the offer and allocate accordingly the adjustment among these budgets.
When using the Budget Public Adjustment and Utilization API you must have at least one active offer/price list created in Trade Management. You also need to create adjustment types.
For accounting purposes, when earnings are affected by the adjustment and the Post to GL flag is checked in system parameters, the following occurs:
The Budget Public Adjustment and Utilization API requires inputs from both a debit and credit General Ledger account.
When earnings are affected by the adjustment and the Post to General Ledger flag is checked in system parameters, but no General Ledger accounts are passed to the API, the appropriate account is derived using defined Account Derivation Rules.
A new adjustment type updates the Paid column. In the Budget Public Adjustment and Utilization API, adjustment records that update the paid column are always associated with a utilization, an accrual record or another adjustment record, regardless of whether they are created manually or from the API. Only the paid column is affected by this adjustment.
The pay over earnings threshold does not need to be enforced by API because it is on a claim. However, since this type of adjustment is considered in the total paid balance it does affect other claims' threshold checking.
As an example, if the earned column equals $100, the paid column equals $100 and the threshold is set to $10. If you use the API to create an adjustment record that increases the paid column to $11, a claim user will not be able to pay over the earnings because the threshold is already reached.
The budget adjustment types you create allow budget owners to manually adjust budget checkbooks. For example, budget owners can adjust (decrease) the earnings committed to customers who fail to meet offer performance requirements. The funds they free up can then be allocated to other activities.
When creating adjustment types, you can utilize a different set of Oracle General Ledger accounts for budget adjustments than the ones originally used for accruals. This functionality allows you to skip the Account Derivation Rules that you defined for simple Oracle General Ledger postings.
Example: A customer's accruals are not paid at the end of the month. Instead, an adjustment is made to the offer. Based on the adjustment type, the funds are put into a single pool—a common set of Oracle General Ledger accounts used for all offer adjustments.
If you plan to use different Oracle General Ledger accounts for budget adjustments, then as a prerequisite, those accounts must be set up in Oracle General Ledger before creating budget adjustment types.
To set up budget adjustment types, log in to Oracle Trade Management.
Navigation: Administration > Trade Management > Budget > Adjustment Types.
The following table lists and describes the Budget Adjustment types:
Type | Description |
---|---|
Decrease Committed Amount | You can decrease a commitment if funds have been already committed for that activity. A validation is performed - budget commitments can be decreased only to the extent of the balance left after budget utilization. Negative commitments and earnings are not allowed. |
Decrease Committed and Earned Amount | In addition to the above validation, earning validations listed below would also be performed. To post negative earning against a budget a positive earning must exist. If no earning exists for the budget, the user will receive an error message. |
Decrease Earned Amount | Allows earning decreases against any budget. Amount cannot exceed the balance left after budget utilization. May be done because a customer fails to meet the performance criteria of an offer. |
Increase Earned Amount | Allow earning increases against any budget. |
This functionality recalculates the funding level based on the sales performance of a promotion. Funds can be increased or decreased. If the promotion performs well, funding can be automatically increased, and vice versa. This ensures that funds do not run out for promotions that are performing well.
The committed amount determines the maximum allowed Utilized amount. The relationship is reversed for Re-Calculated Committed. If Re-Calculated Committed is implemented then the Utilized amount determines what Re-Calculated Committed amount should be.
Re-Calculated committed amount can be higher or lower than committed or total amount
Subsequent budget requests from offers will increase the committed amount of the budget - not the Re-Calculated Committed.
For example, Budget A has the following numbers:
Total = $10,000
Planned = $0
Committed = $5,000
Re-Calculated Committed = $12,000
Utilized = $6,000
Offer A then requests money from Budget A. Offer A is for $2,000. The user submits Offer A for budget approval for $2,000 from Budget A. Offer's status is now at Pending Budget Approval. As a result, Budget A's numbers are updated as follows:
Total = $10,000
Planned = $2,000
Committed = $5,000
Re-Calculated Committed = $12,000
Utilized = $6,000
Once the budget request for offer A is approved, Offer A has Active status. Budget A is updated as follows.
Total = $10,000
Planned = $0
Committed = $7,000
Re-Calculated Committed = $12,000
Utilized = $6,000
Budget reporting uses Oracle Discoverer. This is a tool used for querying, reporting, analysis, and web publishing. With the appropriate security access, users can view information stored in their database for various activities. They can build reports and graphs to dissect the information.
Not every user can update or view a budget. The table below explains the different access levels for budgets.
Security Level | User Name | Security Level Access |
---|---|---|
1 | AMS: Admin Group | Update all fields:
|
2 | Owner | Update all fields:
|
3 | Team members with Edit Metrics | Update all fields:
|
4 | Team members without Edit Metrics | View budget only |
5 | Everyone else | No access, no view |
Based on the responsibility of the user creating the budget, budgets are created with an organization ID (or operating unit ID). This ID does not drive update or view access to a budget.
From any Budget Request screen, the list of values for available budgets displayed follows the security levels described above. This means that, a budget requestor will only be able to request money from budgets for which he is either an owner or a team member.
Unlike claims which are org-striped, budgets are not org-striped. They are, however, stored with the organization ID (according to the responsibility of the user who created the budget). Budget Utilization is org-striped.
The following table describes the various access levels of objects (such as offers, campaigns, events) and as they relate to which users can access the Budget cue card with each object. Not everybody with access to an object will automatically have access to the Budget cue card or the Budget Request function.
Number | User Name | Security Level Access |
---|---|---|
1 | AMS: Admin Group | Update all fields:
|
2 | Owner | Update all fields:
|
3 | Team members with Edit Metrics | Update all fields:
|
4 | Team members without Edit Metrics | Update all fields:
|
5 | Everyone else, regardless of operating unit | View only |
With the Oracle Trade Management Customer budget view you can collect customer earnings and payment, and the outstanding earning balance by budgets. Using this type of data you can give companies access to accurate aggregate data to monitor fund usage. Although Oracle Channel Revenue Management provides the data for this information you will have to use a type of reporting tool to view the information.
Concurrent Process for Data Collection
Oracle Channel Revenue Management uses the Refresh Materialized Views (for the parameter Customer Budget View) concurrent process to collect data.
View by Dimension
You can use Oracle Trade Management to write meaningful budget reports containing, the balances described in the previous section. These balances are available for a variety of dimensions listed below. Each dimension is available in IDs and is stored in Materialized View tables. You must provide ID names at the time of report generation.
Dimensions
Time
Calendar period is equal to the month, quarter and year periods defined in the AMS: Marketing Calendar profile option.
Budget category
Budget
Budget security
Owner or team member
Customer party
Customer account
Customer account bill to site
Customer account ship to site
Operating unit (of the utilization record)
To set up budget reconciliation run the OZF_TM:Release Committed Budget Amount After Grace Period concurrent program.
Budget roll-up view displays a budget's own amount plus all numbers of its descendent budgets.
Budgets can be allocated and arranged in a hierarchy, the roll-up view gives an organization a “birds-eye” view of all budget balances summed up to each level. Activities and usages can be viewed by drilling down into different numbers such as committed, utilized. When drilled down from a roll-up view, the details will show for the budget itself and all of its child budgets.
For example, if a budget called “California” has committed amounts of $10,000 and a budget called “Oregon” has $20,000 and their parent budget “Western US” funds no other activities, the roll-up view committed is $30,000.
To set up budget roll-up views, log into Oracle Forms with the System Administrator responsibility.
Notes:
Profile options:
Set the OZF: Universal Currency for Budget Roll-up View profile option .
For each user set the “JTF_PROFILE_DEFAULT_CURRENCY” at user level. This determines what currency a user will see his budget roll-up view in.
Note: The roll-up view converts all budgets to the profile currency as set up above. Because the profile is set at the user level, different users will see the roll-up view accordingly.
Self View only shows amounts for the parent budget whereas Roll-up view shows amounts summed for the parent budget, as well as its child budgets.
Budget reconciliation is a way to return money at the end of an offer. It can be done manually or automatically.
Manual Reconciliation: Using the Reconcile button on the button cue card for offers.
Automatic Reconciliation: Running the Release Committed Budget Amount After Grace Period program.
The Account Manager Dashboard displays data for all the accounts in the territories owned by the logged in user. Dashboard data is current as of the last time the Refresh Account Manager Dashboard concurrent program was run.
Use the following high level procedure to setup Account Manager Dashboard. As a prerequisite, quota must be allocated for the user.
Schedule the Workflow Background Engine with the parameter OM Order Line. This process closes orders and refreshes the MTD, QTD, and YTD KPI data in the My Accounts and My Products regions.
Run the Refresh Materialized View for Order Sales concurrent program. This program refreshes sales information and the sales performance graphs in the dashboard.
Run the OZF: Refresh Account Manager Dashboard concurrent program. This program refreshes the data on the dashboard.
Salespeople use the account planning functionality to plan and execute the activities they will use to meet their quotas. It is also used to monitor the performance of their retailers and active offers. Whatever you see in your account is based on the territories to which you are assigned. Tools provided include Gantt charts, sales graphs, and the following:
Tool | Description |
---|---|
Account Manager Dashboard | Displays the performance of all of the account manager's customer accounts. |
Account Summary | Displays the summary of all trade activities planned or being executed for a customer account for a given time period. |
Offer Evaluator | Enables sales representatives to evaluate the performance of past and current offers. |
Discount Calculator | Determines what discount will be beneficial to both the manufacturer and the retailer before actually creating an offer. |
You can personalize the Trade Management Dashboard by clicking the Personalize Page button and going to the Related Links region. You can rearrange the order of the links, add additional links or hide links. Configurations are defined at the responsibility level by the Trade Manager Responsibility level. You can configure the following internal dashboard options in the Trade Management dashboard:
Notifications (Workflow)
My Tasks (CRM tasks)
Calendar (CRM calendar)
Offer Evaluator
Offer Worksheet Summary
Audit Retail Conditions (Renamed from Capture Retail Price)
Discoverer Reports
Discoverer Reports (links to Discoverer application. No reports are seeded)
XML Publisher reports (links to XML Publisher application. No reports are seeded)
Claim Summary
Quota Summary
Budget Summary
Products (links to Oracle Trade Management Product page)
Customers (links to Oracle Trade Management Customer page)
Baseline and lift factors enable you to predict the performance of offer and promotional activities so you can reach your sales objectives. They help you to better understand past promotion performance, determine the best offers to make, and forecast future sales.
Baseline Data: Defined as non-promoted sales or what the volume would be if the promotion is not executed. You should define baselines at the lowest level of the Offers using the data. For example, if offers are always defined at the account level then you should provide the baseline data at the account level. Many offers are defined at the ship-to level, a baseline level commonly used.
Lift Factors: Defined as percent lift as a percent price discount. You can calculate lift factors from direct shipment data and their associated price discounts as recorded in Oracle Order Management. You can define lift factors for customers, products, period, marketing activity, and offer type.
Trade Management contains an interface table which you can populate with baseline and promotional lift data in different dimensions including time, product, customer, offer type, offer activity, and territory.
First, load pre-translated baseline data into a .csv file. Keep this file in a specific location as described in the Setting Up Directory Object section. Oracle recommends translating this data into the following standards:
Map Retailers/market names to Forecasting territory’s ID or Names.
Translate products into Inventory Item Ids or Name.
Translate periods into standard start and end date formats.
Translate baseline quantities into Forecast UOM.
Translate baseline amounts into functional currencies.
Source data is often provided at the market (geography) level. Territories are set up to map specific ship-tos to markets. Depending on the level at which the source data is provided, the upload concurrent program, Refresh Materialized Views, determines the ship-tos that map to the source data. An allocation process, such as Quota Allocation distributes the baseline value among the ship-tos in proportion to historical shipments.
Follow these steps to upload third party Baseline and Lift data into Oracle Trade Management:
Manually create a directory object in the same environment as your Oracle Trade Management database. A directory object is a database object that stores the absolute path of a physical directory on the database node.
Name this object OZF_BASELINE_SOURCE_DIR, and verify that the database server can read and write from the location identified by the directory object.
For example, create the directory object in APPS as follows: CREATE or replace DIRECTORY OZF_BASELINE_SOURCE_DIR AS '/emslog/tm'
If the object is not in APPS, you must also grant read/write access to APPS as follows
Grant READ access on directory OZF_BASELINE_SOURCE_DIR TO apps
Grant WRITE access on directory OZF_BASELINE_SOURCE_DIR TO apps
For complete information on setting up territories see the Oracle Territory Manager Implementation Guide. Set up Territories in Territory Management corresponding to the territories in the data:
Add the respective Sales Accounts and Geography in the Matching Attributes of these Territories.
Run the following two concurrent programs to pull territory setup in Trade Management.
Import Territory Hierarchy
Generate Party List for Market Qualifiers
Set up products in Oracle Trade Management corresponding to the products in the data. For more information see the Oracle Inventory User's Guide.
Set up all trade mediums and activities, corresponding to the set up mentioned in the data.
Log into Oracle Trade Management with Trade Management User responsibility.
Go to Trade Management:Administration >Setup.
Click on the Activity cue card under Setup.
Click Create button.
Select Deal from the Channel Category LOV.
Select the Marketing Medium Cue Card under Setup.
Click Create and associate the activity you created in Step 4.
Trade mediums are defined as promotional sales activities such as Aisle Displays, Coupons, Shelf Talker, and newspaper advertisements.
Typically, vendors provide lift data with varying combinations of activities which may include in-store Displays, Features, and marketing media (advertising) as shown in the following examples.
To support User-defined lift activities, you must decide which activities you want to use. During offer forecasting, the offer's trade mediums will be mapped to these activities to determine the lift multiplier to use. You can provide names for the activities and determine which trade mediums activities belong to each group. An example of activity types and the typical members (trade mediums) would be:
Activity #1 Display
Trade Medium: End Aisle Display
Trade Medium: In Aisle Display
Secondary Location
Activity #2
Coupons
Banners
The administrator should define and name the activity types that will be used, determine the precedence order of the activity types that will control how lifts are calculated and define and load Trade Medium choices into the appropriate activity “buckets” during the lift data load process.
To set up the Data Source Lookup use the lookup OZF: Baseline Sales and Promotional Lift Data Source(OZF_BASELINE_DATA_ SOURCE). To seed the data use values similar to Code: ACN Meaning: AC.Nielsen.
You can use this seeded code in data_source column code in the baseline data csv file as well as in the lift factors csv file.
Set up the following profiles:
OZF: Number of months to trend ship to volume for baseline calculations
OZF: Currency Conversion Type
OZF: Keep historical data for Baseline Sales and Promotional Lift
OZF: Common Currency for Trade Management
OZF: Common Unit of Measure for Trade Management
OZF: Global Start Date (mm/dd/yyyy) – This must be already set while populating Time Structure. If you change it, you must re-run time structure and dashboard refresh as well.
OZF: Quota Allocation by (Set it to Amount or Quantity) You must set this profile before doing setup for Quotas.
QP: Item Validation Organization (Note this is an Oracle Advanced Pricing profile.)
Create your baseline sales data files and store them in the same location to which OZF_BASELINE_SOURCE_DIR is pointing.
The following table list the column description of the 3rd Party Baseline Sales flat file:
Name | Status | Description |
---|---|---|
DATA_SOURCE | Required | Lookup code as entered by the implementor in the extensible lookup for Data Source for Baseline Sales and Promotional Lift Factor Data . |
MARKET_TYPE | Required | Customer identifier - same as TERRITORY. |
MARKET_ID | One of the two, id or name is required. | Id as in the customer identifier. For example, territory Id. |
MARKET_NAME | One of the two, id or name is required. | Name as in the customer identifier. For example, Territory Name |
ITEM_LEVEL (required) This is the | Required | Product identifier - same as 'PRICING_ATTRIBUTE1'. |
ITEM_ID | One of the two, id or name is required. | Id as in the product identifier. For example, inventory item Id |
ITEM_NAME | One of the two, id or name is required. | Name as in the product identifier. For example, concatenated_segments . |
TRANSACTION_FROM_DATE | Required | Start Date for the Data |
TRANSACTION_TO_DATE | Required | End Date for the Data |
BASELINE_QTY | One of the two, quantity or name is required. | Baseline Sales in Quantity in UOM_CODE |
UOM_CODE | Required if quantity is present | UOM_CODE for Baseline Sales in Quantity |
BASELINE_AMT | One of the two, quantity or name is required. | Baseline Sales in Amount in CURRENCY_CODE |
CURRENCY_CODE | Required if amount is present | CURRENCY_CODE of Baseline Sales in Amount |
As an example, your baseline sales data could appear as follows:
"IRI","TERRITORY",,"Name of My Territory","PRICING_ATTRIBUTE1",,"CM18759","20061001","20061231","1000","Ea",,""
"IRI","TERRITORY","1924",,"PRICING_ATTRIBUTE1","149",,"20060301","20060531","","","12000","USD"
Create your promotional lift factors Data Files and keep them in the location to which OZF_BASELINE_SOURCE_DIR is pointing:
Name | Status | Description |
---|---|---|
DATA_SOURCE | Required | Lookup code as entered by the implementor in the extensible lookup for Data Source for Baseline Sales and Promotional Lift Factor Data . |
MARKET_TYPE | Required | Customer identifier - same as TERRITORY. |
MARKET_ID | One of the two, id or name is required. | Id as in the customer identifier. For example, territory Id. |
MARKET_NAME | One of the two, id or name is required. | Name as in the customer identifier. For example, Territory Name |
ITEM_LEVEL | Required | Product identifier - same as 'PRICING_ATTRIBUTE1'. |
ITEM_ID | One of the two, id or name is required. | Id as in the product identifier. For example, inventory item Id |
ITEM_NAME | One of the two, id or name is required. | Name as in the product identifier. For example, concatenated_segments . |
TRANSACTION_FROM_DATE | Required | Start Date for the Data |
OFFER_TYPE | Required | Offer_code of the type of offer ACCRUAL - Accrual DEAL - Trade Deal LUMPSUM - Lumpsum OFF_INVOICE - Off Invoice OID - Promotional Goods ORDER - Order value TERMS - Terms Upgrade VOLUME_OFFER - Volume Offer |
ACTIVITY_ID | Trade Activity ID | |
ACTIVITY_NAME | Trade Activity name | |
TRADE_TACTIC_ID1 through TRADE_TACTIC_ID10 | Trade Medium Id | |
TRADE_TACTIC_NAME1 through TRADE_TACTIC_NAME10 | Trade Medium name. | |
TPR_PERCENT | Required | Trade promotion discount percentage for the product. |
LIFT_FACTOR | Required | Lift Factor as a multilplier (for example, 0.10 for 10% lift) For example, "IRI","TERRITORY",,"My Sales Territory","PRICING_ATTRIBUTE1",,"CM18759","20061001","20061231","",,,,,,,,,,,,,,,,,,,,,,,10,0.12 "IRI","TERRITORY","1924","","PRICING_ATTRIBUTE1",201,"","20061001","20061231","",,,,'End Aisle Display',,"Banner",,"TV Ad,,,,,,,,,,,,,,,10,0.12 |
For example your data could appear as follows:
"IRI","TERRITORY",,"My Sales Territory","PRICING_ATTRIBUTE1",,"CM18759","20061001","20061231","",,,,,,,,,,,,,,,,,,,,,,,10,0.12
"IRI","TERRITORY","1924","","PRICING_ATTRIBUTE1",201,"","20061001","20061231","",,,,'End Aisle Display',,"Banner",,"TV Ad,,,,,,,,,,,,,,,10,0.12
The following information lists the steps for running the Baseline Sales request set and the Lift Factors request set:
Load Third Party Baseline Sales:
Baseline Sales and Promotional Lift Factors Flat Files Upload Preprocessing
Baseline Sales Flat File Upload Table Creation
Name of Directory Object Containing the file
Name of Baseline Sales flat file
File name to store the log
File name to store all bad records
File name to store all discarded records
Baseline Sales Flat File Upload - Pass 1
Data Source (Choose ‘IRI’ from the dropdown)
Baseline Sales Flat File Upload - Pass 2
Data Source
Load 3rd Party Promotional Lift Factors:
Baseline Sales and Promotional Lift Factors Flat Files Upload Preprocessing
Promotional Lift Factors Flat File Upload Table Creation parameters:
Name of Directory Object Containing the file
Name of Promotional Lift Factors flat file
File name to store the log
File name to store all bad records
File name to store all discarded records
Promotional Lift Factors Flat File Upload - Pass 1
Data Source (Choose ‘IRI’ from the dropdown)
Promotional Lift Factors Flat File Upload - Pass 2
Data Source
Check the log file for errors. Correct the CSV file and the errors and re-run the request set.
Trade Management collects and summarizes budget balances for use in creating reports. Budget utilized, earned and paid columns can all be tied specifically to a customer’s transactions regardless of how the budget was “committed”. Earned minus paid is the actual accrual balance. The customer budget view is now based on the transactions of the customer. Companies can easily view the information using any reporting tool such as Oracle Discover.
The following table describes Utilized budget balances available in Trade Management:
Utilizations | Description |
---|---|
Order related utilizations (positive), such as those for accrual and off-invoice offers | Utilizations for orders booked but not shipped, invoiced or closed. These utilizations are not the same as “earned” balances. |
Return related utilizations (negative) | Utilizations for return orders booked but not invoiced (credited) or closed. |
Non-order related utilizations. For example, those for lump sum and scan data offers, as well as utilizations created by net accrual offers, partner activities or indirect sales purposes. | There is no difference between utilized and earned. |
The following table describes Earned budget balances available in Trade Management:
Utilizations | Description |
---|---|
Order related (positive) | Earned balances for orders shipped, invoiced or closed |
Return related (negative) | Earned balances for return orders invoiced (credited) or closed. |
Non-order related utilizations and utilizations created by net accrual offers, partner activities or indirect sales purposes. | Identical to Utilized |
The following table describes Paid budget balances available in Trade Management:
Utilizations | Description |
---|---|
Off-invoice types of utilizations such as off-invoice, order value and promotional good offers | Paid amounts are the same as earned amounts. |
For accrual types of utilizations such as accrual, lump sum and scan data offers. | Paid amounts are claim amounts associated to the accruals. |
All adjustments to the paid amount, whether manually created, created by public API or system generated. |
The balances described in the previous tables are available for the following dimensions. Each dimension must have a unique ID. For performance reasons only IDs can be stored in MV (Materialized Views) tables. You must provide names for these IDs at the time of report generation.
Time - Calendar period equals month, quarter and year periods defined in the AMS: Marketing Calendar profile option
Budget category
Budget
Budget security - Owner
Customer party
Customer account
Customer account bill to site
Customer account ship to site
Operating unit (of the utilization record)
In addition to the simple reports administrators can also build reports with cross drill down from one dimension to another as shown in the following examples:
Time > budget
Time > customer party >budget
Time > customer party > account > bill to site > ship to site > budget
Trade Management captures price and facing data by account ship-to category. Trade Management can also capture user defined promotional activities for products (as well as their competitors) in retail store locations. Follow these steps to capture user defined promotional activities:
Define store condition metrics you want to track by determining what specific product data to track.
Establish territory-store relationships by determining the specific stores to include in your retail coverage territory.
Capture store specific field data by collecting store-product data for stores in the territory and track that data over time.
View store conditions by viewing current store-product status.
Trade Management defines two different types of stores:
Direct Store Delivery (DSD) - Retail stores who supply product directly from the vendor.
Direct Distribution (DC)- Product is supplied through the retailers Distribution Center.
Using Oracle Trade Management the Account Manager can define all of the DSD and DC stores for which he is responsible even if they fall outside of his territory.
An example of a DSD model is a soda distributor who services all of Kroger’s stores with their own delivery trucks. This type of setup makes each store a Ship-To site. Each store now has a retail outlet where they can track retail conditions, and a ship-to site for distribution.
In the following example the cookie manufacturer delivers through the retailer’s distribution chain and the retailer is centrally managed. All transactions are processed through central billing and all deals are negotiated at Headquarters. From an Oracle Trade Planning Management perspective, stores are data points where the retailer in-store performance is tracked for compliance.
An address (party-site) is defined for each DC store location associated to a retail customer. Set the Usage to “Store"
Ship-to’s represent DSD store locations.
The Retail Audit Condition Capture and Retail Condition status screens have a Location LOV containing a customized list of DSD and DC stores relevant for each territory.
The OZF: Generate Party List for Market Qualifier process collects all Stores (DC/DSD) for each customer in the account manager’s territory. Each time you run this process it adds new Stores in the Territory to the list. The resulting list includes the Store party-sites and Ship-to’s in the territory for each customer.
Follow these steps to edit the retail store list in Trade Management:
Select a Territory in the Territory LOV to retrieve the current store list. The Administrator has access to all Territories.
Select a customer from the customer LOV. The LOV lists all customers in the territory.
Click Search to list all of the customer stores tied to the territory.
(Optional Step). Add a Store to Retail Territory by clicking Add Another Store icon. All Stores for this Customer are displayed and you can select the stores to add to your current Territory list.
(Optional Step). To remove or delete a store from the Retail Territory list, click the Remove icon.
The Activity Summary displays all the Offers and Campaign Schedules. The Offer Evaluator displays all offers and their forecasted and/or actual sales information.
As a prerequisite, offers and campaigns must exist in the system.
To set up activity summary and offer evaluator, run the Refresh Trade Management Activities (Offers and Schedules concurrent program.
This program populates de-normalized (flattened structure of all the information in a table) tables with current information for new and changed Offer and Schedules. Both the Activity Summary and Offer Evaluator data is current as of the last time this concurrent program was run.
All of the activities in the account plan and Offer Evaluator are current as of the last time the Refresh Trade Management Activities (Offers and Schedules) concurrent program was run.
The following information describes the required setups for implementing offers.
For accrual-type offers, the offer owners can specify:
The date to automatically pay the beneficiary , or the number of days from the offer end date upon which to pay the beneficiary.
The payment method (check or on-account credit, on-account debit, or accounting only).
Note: Supplier Ship and Debit and Price Protection both use on-account debit payment for settlement of accruals. In addition, internal ship and debit claims use the Accounting Only payment method. For more information on supplier ship and debit offers and claims, see the Oracle Supplier Ship and Debit User Guide. For details on price protection claims, see the Oracle Price Protection User Guide.
The beneficiary to be paid.
To implement this functionality, you must:
Verify the following lookups:
OZF_AUTOPAY_METHOD
Meanings are Issue Credit and Account Credit
OZF_AUTOPAY_CUST_TYPES
Meanings are Customer Name; Customer - Bill To; Customer - Ship To
Set up the OZF : Claims Autopay concurrent program to run every day.
The Autopay program checks to see which offers meet the pay out date specifications. When an offer meets this criteria, the Funds Accrual Engine is invoked, a claim is created, and the claim is settled. The offer owner is notified when payment is made.
Theme approval functionality allows businesses to require upper management approval for promotional ideas prior to allocating budget resources. Use of this functionality is optional.
To implement theme approval for offers, you must verify the lookup OZF_OFFER_STATUS.
Offer theme approval functionality is enabled and disabled by selecting an option called Theme Approval when you create custom setups for offers. For more information on custom setups, see the Creating Custom Setups section in the Oracle Channel Revenue Management Implementation and Administration Guide.
You can configure Oracle Trade Management to transfer General Ledger (GL) postings for offers from the Trade Management interface to the Oracle General Ledger interface table.
Posts to Oracle General Ledger occur when:
Lump sum or Accrual offers update the budget utilized column
Claims or deductions for an offer are settled
The utilized amount for lump sum and accrual offers increases or decreases due to an adjustment of the utilized column
Off invoice postings are done when updating the budget utilized column. The Create Oracle General Ledger entries for off-invoice discount option must be enabled on the System Parameters page.
Posts will not occur to Oracle General Ledger when the following offers are associated with an order:
Promotional goods
Order value
Terms Upgrade
If posted to the budget checkbook, the Utilization and Paid columns will reflect the value.
To configure Oracle Trade Management to transfer Oracle General Ledger (GL) postings for offers, run the Create Accounting concurrent program with the Transfer to GL and Post to GL parameters set to Yes.
This program creates accounting entries in Oracle Subledger Accounting first and then transfers these journal entries to Oracle General Ledger posting them from Oracle General Ledger's interface to General Ledger tables.
To transfer these accounting transactions from Oracle General Ledger's interface, you can also run the Journal Import and/or Post to Oracle General Ledger programs from General Ledger with Source equals Channel Management option.
To set up Oracle Trade Management to post offers to Oracle General Ledger, follow these steps:
Log in to Oracle Forms and select the Oracle Trade Management Administrator responsibility.
Run the Create Accounting concurrent program and select to transfer the accounting entries to Oracle General Ledger.
While running this program, you can submit journal import at the same time. Or, you can wait for the request to finish and then:
Switch to the General Ledger responsibility.
Run Journal Import separately for the Marketing source from the Run Journal Import screen in Oracle General Ledger.
Switch to the General Ledger responsibility and navigate to Journals > Enter.
Query the journal entries using the source Marketing.
Review the journal details.
Post the journal batch by navigating to More Actions > Post Batch.
Once posting is complete, the batch status changes to Posted, and the respective account balance is updated.
You can source individual offers from either a campaign (parent) or a budget directly. This allows offers the flexibility to define its funding source. When a campaign is the funding source of an offer, the campaign acts like a “mini-budget”. The offer can only source up to the available amounts the campaign contains.
Sourcing funds for offers from a campaign or budget functionality allows the sales manager to create multiple campaigns from a single budget and assign owners to specific campaigns. These functions enhance the manager's ability to monitor spending. These functions also permit the sales person to source funding for Trade Deal type offers from either a campaign or a budget, which simplifies the offer execution process.
This functionality is based on the profile OZF : Source from Parent Object. See Profile Options for Trade Planning for details.
Manufacturers must often alter the original conditions of an offer while it is still active. You can adjust discount terms and product groups by using Oracle Trade Management's backdating functionality. Using the backdating functionality in Trade Management, you can enter an active offer and adjust the discount terms and product group involved.
Manufacturers must often alter the original conditions of an offer while it is still active. You can adjust discount terms and product groups by using Oracle Trade Management's backdating functionality.
For backdating, the Offer Adjustment Function is available for user-defined role. Access to the “Offer Adjustment” page is determined by the user's role and responsibility.
You can use Offer Adjustment, when active, for planned, active, and draft versions of the following offer types:
Off-invoice
Accrual
Trade Deal
Order Value
Promotional Goods
Use the backdating concurrent process to initiate a search for all postings relating to the specific offer, sort by customer and product and calculate the corresponding differential.
The differential is posted to the checkbook by product. The posting is categorized as a backdating adjustment and the Oracle General Ledger posting occurs in the same month that the concurrent process is run. Backdating adjustments, as well as adjustments of all types made to an offer, are reflected in the Claims Association Offer Summary view.
The Funds Accrual Engine concurrent process creates the backdated adjustment accruals.
You can use the forecast functionality in Oracle Trade Management for evaluating and considering the historical data of past offers to create successful new offers. To access this functionality click the Forecast side navigation link from the details page of any offer.
The Offer Forecast can be based on one of the following:
Last Year Same Period
Custom Date Range
Offer Code
Baseline driven forecasting options. This information depends on the data source you created earlier in the section - Setting Baseline Sales Data.
You can create Forecasts for all types of offers and any offer status. The exception to this is for Order Value. Order Value offer does not have any product specification.
To create a forecast you need at least one customer and one product selected in the Offer. Forecasts support multiple customers and products.
You can update a Forecast before it is frozen. After it is frozen, a Forecast and product combination cannot be changed, regardless of changes in the Offer's customer and product selection. A frozen Forecast cannot be deleted. New Forecast versions can be created after a previous one is frozen. Forecasts are created in quantity, not monetary value.
Forecasts are created at Offer or Campaign level. If created at Offer level, it looks up the historical sales data for the customers and products selected for that given Offer. If created at the Campaign level, it sums up for the different campaigns.
For Offer Forecasting, Trade Management uses an API from Inventory called CST_COST_API.get_item.cost. The list price of the item is fetched using the Advanced Pricing API called QP_preq_grp.price_request. When you input the inventory item ID and org ID, they are passed on to the API, which returns the cost of goods sold.
To implement Forecasts for Offers, use the following high level procedure.
Run the Refresh Materialized Views for Order Sales concurrent program.
Because Forecasts are done based on historical sales data, there must be historical sales data in the system.
Set the OZF: Default Forecast UOM profile option at the user level.
This profile option determines the default unit of measure (UOM) used for calculating forecasts. If historical sales data are in different UOMs, they will all be converted to the UOM specified here.
Ensure that the Forecast flag is checked as Available Attributes in the corresponding Campaign or Offer Custom Setup.
You can set up Other Costs for an item in addition to the cost of goods retrieved by the API CST_COST_API.get_item_cost.
For each item and event "oracle.apps.ozf.forecast.OtherCosts" is raised. Subscribe to this with a phase between 1 and 99 so that the subscription will be executed synchronously. This subscription should have a function that returns the other costs for the item.
To subscribe to the Event, log into Self Service Applications as System Administrator. Select the Workflow Administrator Web Applications responsibility.
Select Business Events under Administer Workflow.
Enter oracle.apps.ozf.planning.OtherCosts in the Search Criteria.
Click the Subscription icon for the Event.
Click Create Subscription.
Enter all of the required information.
Make sure that Phase = Between 1 and 99
These parameters are sent in the Event:
Name | Description |
---|---|
P_OBJ_TYPE | Calling object code. WKST if called from Offer Worksheet Discount Calculator. OFFR if called from Offer - Forecasts |
P_OBJ_ID | Calling objects Id. If P_OBJ_TYPE is WKST then OZF_WORKSHEET_HEADERS_B.WORKSHEET_HEADER_ID If P_OBJ_TYPE is OFFR then OZF_OFFERS.QP_LIST_HEADER_ID |
P_PRODUCT_ATTRIBUTE | Attribute of the discount line. For product: PRICING_ATTRIBUTE1 For Category: PRICING_ATTRIBUTE2 |
P_PRODUCT_ATTR_VALUE | Id of the Attribute. For product: Inventory_Item_Id For category: Category_Id |
P_UOM | Unit of Measure for Other Costs |
P_OTHER_COSTS | The subscription should set value of other costs to this parameter. Application will read this value and add to Cost of Goods. Note: Should always be a NUMBER |
Code Example
Users can write the generate function in the subscription as follows:
Generate Function in the Subscription
Enable this option to ensure that customer and product targets for promotional offers match those specified in the budget from which it is sourcing money. This option ensures that funds planned for certain customers and products are used appropriately.
For example, a company may create a budget used for California Retailers and Orange Juice only. If the validation is turned on, an offer created for Oregon Retailers and Milk will not be allowed to source from that budget.
To enable this functionality, set the OZF: Validate market and product eligibility between object and budget profile option. Set this option at the site and responsibility levels.
The values for this profile option are:
No validation for customers and products
Validate customer and products by each budget
Validate customer by each budget, product by all budgets
Validate product by each budget, customer by all budgets.
If validation fails, the revert status process reverts the status of an object (such as an offer) from Submitted or Pending back to the previous status, for example, draft. A notification is sent to the object owner.
In the consumer goods industry, manufacturers frequently enter into trade commitments with customers that span months, quarters, or even an entire calendar or fiscal year. These commitments may also surround special trade events such as new product introductions. Trade commitments are commonly referred to as Performance Programs, Purchase Contracts or National Agreements.
The goal of a volume offer is to provide an enticement to purchase. The incentive covers the cumulative purchases of the specified goods, and accrues as the manufacturers ships their goods to the customer.
Typically the commitment provides multiple performance tiers for the customer. For example, an offer may be executed for one quarter with the following structure:
Purchase $100,000 receive 3% incentive
Purchase $200,000 receive 4% incentive
Purchase $300,000 receive 5% incentive
Oracle Trade Management accommodates volume offers. The following table lists the columns in the Offer Checkbook that describe the financial and budgeting details of an offer.
Column | Description |
---|---|
Utilized | Updated after the offer applies on an order, which is determined by QP's Event Phase setups. If offer is set as Retroactive, additional updates to Utilized will be made on previous orders as well. |
Earned | Updated as determined by profile option OZF: Create GL Entries For Orders |
Paid | Claim/Deduction is settled |
Volume Offer Seeded Values
Volume Type Seeded Values: Amount or Quantity
Discount Type Seeded Values: Amount and Percent
Calculating Volume Offer
The Volume Offer considers actual shipments within the date range of the offer, not booked orders for the product(s) specified in the Product Profile table. Actual shipment values are derived from Order Management.
When you use indirect sales data for volume offers, identifying the seller and buyer are important for market eligibility rules. The following information applies to Indirect Sales for Volume Offers.
Seeded qualifiers are required to support the ability to identify indirect sellers and buyers.
A seller/buyer can be an account or an account site but both need to be seeded as Quoting (QP) qualifiers.
A seller account is an actual valid account site defined in Accounts Receivable. Although the seller is a seller from the indirect sales transaction’s perspective, it is still a customer from the company’s perspective. For example, a distributor that a company sells to, is a customer from the company’s perspective. However, if this distributor submits its sales transactions to the company, these transactions become indirect sales transactions that will be imported into Oracle Trade Management. From that perspective the distributor is a seller.
Additionally, indirect seller and buyer account sites are valid customer account sites defined in Oracle Trading Community Architecture.
The “Sold By” IDSM (indirect Sales Modifier) qualifier supports the following contexts and values :
Context Attribute | Value |
---|---|
Channel | Direct and Indirect Sales |
Distributor Name | Distributor Name |
Distributor Segment | Distributor segment name |
Distributor List | Distributor List Name |
Distributor Territory | Trade Management territory name |
The Pricing formula, created in Advanced Pricing, is shown on volume offers. The pricing Formula provides great flexibility in handle highly complex pricing and promotion scenarios.
Oracle Trade Management also provides currency support for Volume offers.
In Trade Management you no longer have to enter the market eligibility from the first fully accrued budget creation page. You can enter market eligibility at any time and it will passed to the “market eligibility” page. After you enter market eligibility the “market options” page will display a corresponding line.
Notes:
Budget Utilization and Earning - All accruals and adjustments will be created in the same manner as direct sales. All accruals and adjustments will be created for volume offer in the same way they are created for a regular accrual offer when indirect data is used.
Accrual Parameters - The accrual parameter page contains Market, Retroactive Flag, and Territory Level fields.
Accrual dropdown :In the Accrual dropdown on the Accrual Parameters page you can select either Customer or Sales. If you select Sales, the accrual is assigned to the budget owner and the “Accrue To” and “Beneficiary” field on the Market Options become unavailable.
Scan data offers are a common promotional tactic executed by companies in most all consumer goods industries. Common examples of scan data promotions are coupons or consumer rebate programs, which may be received by a manufacturer as an import file from a POS system.
The process works as follows:
Manufacturer sponsored rebate programs or discounts coupons are redeemed at retail by the consumer.
The programs or coupons are processed through a third party clearing house.
The third party clearing house passes the data to the manufacturer.
The manufacturer then makes payment to the retailer.
In some cases, the retailer may submit the scan data directly to the manufacturer. In that situation, the manufacturer validates the data and remits payment to the retailer.
Trade Management accepts such scan data from a third party source. The collected data can then be researched, verified and resolved so payment can be made to the appropriate retailer and the open liability settled. In some cases, the retailer may submit the scan data directly to the manufacturer. In those cases the manufacturer validates the data and remits payment to the retailer.
Utilized: Total offer amount updates Utilized when offer goes Active.
Paid: Claim/Deduction is settled
Use the following steps to set up a scan data offer.
Set the following profile options in Oracle Forms:
OZF: Invoke Workflow for Manual Scan Data Adjustments
OZF: Scan Data UOM
See the Trade Planning profile options,for more information.
Log in to Oracle Trade Management and navigate to Administration > Trade Management >Setup >Activity.
Create an activity by associating the appropriate marketing media using the table.
The values displayed for Marketing Media are predicated on the Activity selected. You can create and customize additional Activity /Trade Medium relationships as needs arise or you can define the values during setup.
Log in to Oracle Forms and select the General Ledger Super User responsibility.
Navigate to GL Posting for Accrual.
At the same time a Scan Data offer updates the budget utilized column, if Oracle General Ledger postings created by Trade Management are used based on a profile, Trade Management writes a debit and a credit accounting entry into its interface to be transferred to Oracle General Ledger.
Per line in the offer, in this case per scan data profile line, the following entries are created:
Sales Expense
Liability
Customize GL accounts.
The Oracle General Ledger accounts are taken first from the Budget, then Budget Category, then System Parameters. You can also define Account Derivation Rules to derive the Oracle General Ledger accounts for each offer line. For information on setting up account derivation rules, see the Oracle Subledger Accounting Implementation Guide.
Note: An option is provided that allows the reversal of product family accruals for Lump sum and Scan Data offers. It is selected when creating custom setups for Scan Data offers. For more information, see. the Creating Custom Setups section in the Oracle Channel Revenue Management Implementation and Administration Guide.
In addition to offers made to customers tied to specific product transactions (for example, $1.00 off per case), a supplier may pay customers for other services and expenses. These include payments to secure shelf space (slotting allowances), events (new store opening activities), and payments to reimburse customers for advertising costs, for example. For these situations, the vendor uses a Lump sum offer to issue a check or credit to the customer for a specific amount.
To set up Lump sum offers, log into Oracle Trade Management.
Navigation: Trade Planning > Offers.
Notes:
Setup type: Select Lumpsum.
Start date and end date: The lumpsum is earned throughout the active date range.
Distribution type: See Guidelines.
Activity type: Select Budget or Campaign as the source for the Lump sum offer. Check the Source from Campaign box to source from a campaign that has its own budgets. Available budgets in the list of values are determined by the Activity type selected. Only member campaigns are available in the campaign list of values. Campaigns with multiple budgets are drawn against in proportion to the budget amounts.
Payment type: If you select a payment type of Issue Check or Credit Memo, a claim request is created automatically and settled immediately. No workflow approval is required. This function mimics the Autopay function.
Reusable: Select if you want to use the offer in multiple campaigns.
Confidential: If you want the offer team to be able to review and edit the offer, leave the Confidential box unchecked.
Owner: The owner controls the team member list and security.
Qualifiers: Add From and To performance dates that affect the earning of the Lump sum. Performance Dates are for documentation purposes only, for example, to show when the customer is expected to perform in exchange for the lumpsum (which, for example, is used to pay for a POP display July 4th week).
Discount rules: Create discount rules for specific items. Discount rules show how the sum will be accrued by the products. The rules can be amounts, quantities, or a percentage of the sum. Percentages must add up to 100%).
Exclusions: Use to make specific exclusions to a rule.
Guidelines
If you select a distribution type of Percentage, the value(s) entered in Distribution Value under Discount Rules must equal 100% when an offer is in Active status. If you selected a distribution type of Amount, the total of the amounts entered in the Distribution Value field(s) under Discount Rules must equal the amount in the Lump Sum Amount field in the header.
When any offer is in Draft status, amounts may vary below 100%. If percentages are greater than 100% at any time in either Draft or Active status, an error message is created.
When the lumpsum becomes active, the total amount is Committed.
During the time when the lumpsum is active, the funds are utilized at a rate in proportion to the total days of the offer. For example, a lumpsum of $12,000 for a three month quarter is utilized as $4,000 per month.
The Net Accrual offer type bypasses Advanced Pricing and directly processes order transaction data. Accruals are applied based on the net sales of a specific customer and product, rather than on invoiced sales. Net accrual offers can be used to establish price protection programs. They create utilization on sales that occurred in the past.
To implement net accrual offer types, run the following concurrent programs in this order:
Refresh Trade Management Activities (Offers and Schedules)
Net Accrual Engine
Net accrual rules are used to determine the net sales of product on which an accrual discount can be applied. These rules contain all the deductions that need to be considered on total sales of any product to arrive at the Net Sales.
For example, a Sales Representative sets up a deal with a customer that gives the customer a promotion of 5% based on sales to them in the previous quarter. As a part of the terms of this promotion, the Sales Representative wants to exclude the credit memos given to the customer in the previous quarter so as to arrive at a net sales figure. He can achieve that by creating net accrual rules and group them as a net accrual rule set. This rule set can be specified on an Offer of type Net Accrual.
Log in to Oracle Trade Management.
Navigation: Administration > Trade Management > Trade Planning > Net Accrual Rules.
Notes:
Transaction source: Supported sources are Account Receivables, Order Management Returns, and Trade Management Offers.
Transaction type and Transaction identifier: Shows valid values based on the transaction source.
Net accrual rule sets are a grouping of Net Accrual rules. A rule set must be specified while creating a Net Accrual offer. The rules in the rule set will be used in arriving at the Net Sales of a product on which and accrual discount can be applied.
Creating Net Accrual Rule Sets
As a prerequisite, Net Accrual Rules must be created.
Log in to Oracle Trade Management.
Navigation: Administration > Trade Management > Trade Planning > Net Accrual Rules.
Notes:
Rule set header: A Rule set header is created when you create a rule. A table is displayed to capture the rules. Select the Net Accrual Rule from the list of values.
Verifying Net Accrual Rule Sets
As a prerequisite, Net Accrual Rule sets must have been set up.
Log in to Oracle Trade Management.
Navigation: Trade Planning > Offers > Create.
Notes:
Offer type: Select Net Accrual. The List of Values for Net Accrual Rule Set should display of all the rule sets you defined.
If your business requirements call for the need to post promotional accruals (for accrual, lump sum offers) to Oracle General Ledger you can customize the derivation of this account in Oracle Subledger Accounting.
Customization defines the value of a certain segment of the whole account.
For example:
Account structure = company-account type-customer-product-spare
Base account = 01-0001-0002-0000-000
Customized = 01-0001-8888-2344-000 (e.g. changed based on the customer and product derived from an order)
You can use the following attributes for customization:
Account Type
Claim ID
Budget ID
Offer ID
Line ID
Inventory Item ID (seeded)
Price Adjustment ID
Customer ID
Order Category
Org ID
For more information on using the Account Derivation Rules, see the Oracle Subledger Accounting Implementation Guide.