6Define Revenue Management
This chapter contains the following:
Source Document Types
The source document type represents the source of the originating document that is imported into Revenue Management. Document types can include sales orders, service contracts, receivable invoices, and more.
Source document types are used to:
-
Identify the external applications and Oracle Cloud applications from which the data is imported. The downstream Revenue Management processing uses the internal identifier to identify the original source.
-
Assign a satisfaction measurement model.
-
Assign a satisfaction plan when the satisfaction measurement model is set to Period.
-
Assign the default satisfaction measurement model, revision intent, and performance satisfaction plan modeling attributes.
Revenue Management contains predefined source document types for the Oracle Applications Cloud and Oracle E-Business Suite Applications applications that can be integrated with Revenue Management. You can also define additional source document types. For example, you can use a source document type to identify documents that come from your order management application.
System Options
Revenue Management system options define key configuration, integration and accounting options at the application level, including currency conversion rate types, source document and transaction source extraction start dates, and revenue accounting and thresholds.
On the Manage Revenue Management System Options page, you can define system options for the following:
-
Currency conversion
-
Integration
-
Revenue accounting and thresholds
Currency Conversion
Use the following system option to define the currency conversion rate:
System Option | Description |
---|---|
Conversion Rate Type |
Defines the conversion rate type to be used by Oracle Fusion General Ledger to convert the local currency line transaction amounts into ledger currency amounts. |
Integration
Use the following system options to specify the source applications that are integrated with Revenue Management:
System Option | Description |
---|---|
Source Document Type |
Defines the type of source documents to be imported into the application, along with:
|
Oracle Fusion Receivables Transaction Sources |
Defines the Receivables transaction source to be imported into Revenue Management. The start date of integration for a transaction source is the date on which data will begin being imported into Revenue Management. |
Revenue Accounting and Thresholds
Use the following system options to specify accounting and thresholds.
System Option | Description |
---|---|
Accounting |
Defines the general ledger's contract liability, contract asset, price variance, contract discount account, and revenue clearing account to be used when creating journal entries for Revenue Management. |
Threshold Amounts |
Define the lower limit amount to be applied in determining the transaction price, discount allocation exemptions, and whether a contract's transaction price requires manual review:
|
Performance Satisfaction Plans
Create satisfaction plans to determine the number of periods and the amount of revenue to recognize in each period for a performance obligation.
There are four types of satisfaction plans that you can create when the satisfaction measure model is Period.
Performance Satisfaction Plan Type | Description |
---|---|
Daily revenue rate, all periods |
Prorate revenue recognition using a daily rate for all periods. This rule type requires that the rule start date and end date be specified in the transaction data. For example, if a performance obligation is for a 12-month cloud subscription service starting January 1, 2017, the satisfaction plan will use the following daily rates revenue recognition schedule: January = 31 days, February = 28 days, March = 31 days, April = 30 days, and so forth until the end of December 2017. Note: The number of days in a period depends on the accounting
calendar defined in General Ledger.
|
Daily revenue rate, partial periods |
Prorate revenue recognition using a daily rate only for partial periods. The whole periods are prorated evenly. This rule type requires that the rule start date and end date be specified in the transaction data. |
Fixed schedule |
Prorate revenue recognition over a predefined number of periods and predefined percentages of the revenue amount. For example, you can specify three periods for 30 percent, 30 percent, and 40 percent. When you use this rule, the application derives the duration from the rule. |
Variable schedule |
Prorate revenue recognition over a number of periods. This rule type requires that the rule start date and end date be specified in the transaction data. |
Contract Identification Rules
Use contract identification rules to create contracts based on source data imported from multiple source applications. Configure rules to determine which source document types should be processed by the rule and how the data should be grouped into an accounting contract. For example, data can be grouped by customer party, time frame, customer purchase order number, or other common identifiers such as opportunity ID or salesperson.
Revenue Management provides three predefined contract identification rules:
Rule | Description |
---|---|
Identify customer contract based on party (and time duration) |
This rule identifies all source documents created for a party within a 30-day time frame as a customer contract. |
Identify customer contract based on source document |
This rule groups all lines of a source document into a single accounting contract. |
Identify customer contract based on source document line |
This rule identifies each source document line as an individual accounting contract. |
Rules are executed in the order of priority.
To ensure that the Identify Customer Contracts program can process all lines correctly, all lines in the unprocessed pool and every source document line are part of a customer contract. These contracts can be either newly identified customer contracts or existing customer contracts.
Performance Obligation Identification Rules
A performance obligation is a distinct promise in the contract to transfer goods or services to the customer. Revenue recognition is based on the satisfaction of a contract's performance obligations rather than billing. It is important to correctly identify and create performance obligations for revenue recognition.
Revenue Management uses performance identification rules to determine how to automatically group source document lines into performance obligations within an accounting contract. The rules specify the matching attributes that provide a common link for grouping the source document lines into performance obligations. The rules also determine how revenue recognition is handled, including the satisfaction method and allocation exemption that will be used.
Revenue Management provides three predefined performance obligation identification rules:
Rule | Description |
---|---|
Identify performance obligation based item |
This rule groups source document lines as a performance obligation based on the item number on the line. |
Identify performance obligation based on item classification |
This rule will group source document lines as a performance obligation based on the item classification on the line. |
Identify performance obligation based on source document line |
This rule identifies each source document line as performance obligation. |
Rules are executed in the order of priority.
Performance Obligation Templates
Use performance obligation templates to group items together which are sold in bundles.
For example, if you normally sell a set of goods or services as a standard bundle, you can enter all of these goods or services in a performance obligation template. Then all of the items in the standard bundle are automatically associated with the appropriate standalone selling price profile. You calculate or load standalone selling prices at the template level, instead of by individual items within a template.
For each performance obligation template, a priority number is assigned, which determines the order in which the template is applied. Because performance obligation templates are specific to each business, there are no predefined performance obligation templates.
Allocate Revenue Based on Extended Standalone Selling Prices
If you use performance obligation templates, you can optionally use component selling prices (the price of an item or service when its sold as part of a bundle) to allocate revenue within a performance obligation using the extended standalone selling price amount.
To allocate revenue based on component selling prices:
-
Enable the Derive pricing dimension combination option in the Create Performance Obligation Template page.
-
Select Extended SSP amount for the allocation basis. The Identify Customer Contract process distributes the performance obligation-level allocated revenue to the underlying promised detail lines for the obligation using the ratio of the promised detail line's component selling prices.
You must then upload the component selling prices for a performance obligation template and item combination, for a particular pricing dimension, effective period, and currency.
Additional Considerations
When using this feature you can modify the Allocation Basis option. Note that:
-
The default value is blank.
-
The Allocation Basis option changes take effect from the time the changes are saved, and are applied to all processing from that point forward.
-
Changes aren't applied retrospectively.
If you change the Allocation Basis option from blank or Selling amount to Extended SSP amount:
-
The Identify Customer Contracts process applies the new logic from that point forward.
-
Changes apply only to new performance obligations created for the template.
-
The Identify Customer Contracts process distributes performance obligation revenue to promised detail lines based on the ratio of the component selling prices.
-
For each line associated with a bundle, the value in the Unit SSP column represents the component selling price and not the standalone selling price of the item or service.
-
For performance obligations with promised detail lines in which the component selling price can't be assigned or is missing, the Identify Customer Contracts process:
-
Marks the promised detail line as Missing SSP.
-
Sets the Contract Allocation Status to Not Allocated with an Allocation Pending Reason of SSP Not Available.
-
If you change the Allocation Basis option from Extended SSP amount to Selling amount or blank:
-
The Identify Customer Contracts process applies the new logic from that point forward.
-
Changes apply only to new performance obligations created for the template.
-
The Identify Customer Contracts process ignores the component selling prices on the promised detail lines.
-
The Identify Customer Contracts process distributes performance obligation revenue to promised detail lines based on the ratio of the promised detail line selling amount.
Pricing Dimension Structures and Value Sets
You can segregate standalone sales into sets of similar transactions called pricing dimensions. You identify the pricing dimensions by analyzing the pricing policies of your goods and services. The pricing policy takes into account multiple factors when determining customers' discount eligibility, such as the deal size and customer type. Pricing dimensions are used to categorize the standalone selling prices.
After you identify your pricing dimensions, you group them as segments of a pricing dimension flexfield structure. Define as many pricing dimension structures as you need by creating unique groups of pricing dimensions. Pricing dimension structures are shared by all of the goods and services that use the pricing dimensions included in the structure.
The pricing dimension values are included by default in all sales transactions imported into Revenue Management. The combination of pricing dimension values assigned to a transaction is called a pricing dimension combination. Pricing dimension combinations are used to categorize standalone sales. The transactions are segregated in the standalone sales pool using the pricing dimension combinations. All transactions in the sales pool that have the same pricing dimension combination are grouped into one set for calculation and establishing the standalone selling price.
When determining the standalone selling price for a transaction that's part of a performance obligation, Revenue Management first assigns the pricing dimension combination to the transaction and then derives the standalone selling price based on the pricing dimension combination.
Example:
The following table shows an example of a pricing dimension structure with three pricing dimensions:
Geographic Region | Customer Type | Deal Size | Standalone Selling Price |
---|---|---|---|
North America |
Government |
1,000,000 USD to 4,999,999 USD |
17% |
North America |
Government |
5,000,000 USD to 9,999,999 USD |
21% |
North America |
Commercial |
1,000,000 USD to 4,999,999 USD |
17% |
North America |
Commercial |
5,000,000 USD to 9,999,999 USD |
21% |
North America |
Commercial |
10,000,000 USD or more |
32% |
In the example, each pricing dimension must have a set of pricing dimension values. The table shows that the Customer Type pricing dimension has two unique values: Commercial and Government. The standalone selling price is established using a 17% discount for the following pricing dimension combination:
-
Geographic region: North America
-
Customer type: Government
-
Deal size: 1,000,000 USD to 4,999,999 USD
Similarly, standalone selling prices are established for the other four pricing dimension combinations.
Create a Pricing Dimension Structure and Value Sets
The Pricing Dimension Structure in Revenue Management allows organizations to model pricing dimensions as a flexfield structure for use in establishing standalone selling prices.
The price of a product can vary based on factors like:
-
Geographic location
-
Selling quantity
-
Type of customer
These factors typically influence how the company determines or sets the selling price of the product. An organization with multiple lines of business may use different sets of dimensions for each line of business.
An organization should analyze how products are priced in each of its lines of business and compile the list of unique groups of pricing dimensions used. Each unique group of pricing dimensions should be defined as a pricing dimension structure.
Consider the following when determining the structures you need:
-
Analyze pricing policies across all your products and services and identify all of the pricing dimensions being used.
-
Identify the price bands you need for the pricing dimensions.
-
Identify distinct groupings of price dimensions.
-
Define a pricing dimension flexfield structure for each distinct grouping of pricing dimensions.
-
Assign segment labels to the dimensions that have price bands.
-
Create only one structure instance for each pricing dimension flexfield structure.
Identify Source Document Attributes:
-
Use pricing dimension combinations to help determine standalone selling prices for a source document line.
-
Use pricing dimension assignments to help you to enter the pricing dimension values automatically for the document lines imported into Revenue Management.
-
Identify the document attributes that capture the pricing dimension values.
-
Assign the document attributes to the pricing dimensions for each source document.
Your organization has three tiers of pricing for hardware drives and software licenses:
-
Tier 1 hardware and software products that are available to non-US customers.
-
Tier 2 hardware and software products that are only available to customers in the US.
-
Tier 3 software products that are specific to only Japan and the United Kingdom.
Define Value Sets and Assign Values
The following table provides an example of how you would configure the pricing dimension structure and assign the value sets:
Pricing Structure Name | Value Set Name | Segment Order |
---|---|---|
WG_VRM_Structure |
Customer Classification |
1 |
|
Quantity Band |
2 |
|
Geographic Region |
3 |
|
Country |
You assign values but don't assign it as a segment. |
-
Based on the table, create the value set Customer Classification.
-
Assign the following values for Customer Classification:
-
Tier 1
-
Tier 2
-
Tier 3
-
-
Create the value set Quantity Band.
-
Assign the following values for Quantity Band:
-
1-100
-
101-500
-
500-999,999
-
-
Create the value set Geographic Region.
-
Assign the following values for Geographic Region:
-
Europe
-
North America
-
Asia Pacific
-
-
Create the value set Country
-
Assign the following values for Country:
-
US
-
Canada
-
UK
-
Japan
-
-
Create a structure, name it WG_VRM_Structure, and assign the following segments:
-
Segment 1: Customer Classification
-
Segment 2: Quantity Band
-
Segment 3: Geographic Region
-
-
Compile the structure and click Save and Close.
-
Create Pricing Dimension Assignments using the following table for each of the documents:
Document Segment 1 Segment 2 Segment 3 Projects
Customer Classification
Line Quantity
Bill-to Customer
Sales Orders
Customer Classification
Line Quantity
Bill-to Customer
Service Orders
Customer Classification
Line Quantity
Bill-to Customer
Receivables
Customer Classification
Line Quantity
Bill-to Customer
-
Create Pricing dimension bands for the following:
-
Quantity band for hardware
-
Quantity band for software
-
Set band and select countries and region
-
-
Create the following items:
-
Hard drives
-
Licenses
-
-
Create the standalone selling price profile and select the following:
-
Structure
-
Representation Type (discount percentage)
-
Pricing Dimension Assignments
-
Band Assignments:
-
For item licenses assign software quantity band
-
For item hard drives assign hardware quantity band
-
-
Pricing Dimensions
Organizations use multiple pricing models to sell their goods and services. Each good or service has a specific pricing model, applied consistently to all sales of that good or service. The goods or services are categorized by different dimensions for the purpose of pricing. These categorization are called pricing dimensions.
You can, for instance, categorize transactions based on:
-
Country
-
Customer type
-
Quantity sold
-
Total deal value
The price of the same good or service varies based on the category. Categorization parameters aren't fixed. They vary from organization to organization, and within an organization, they vary from good to good or service to service.
For the purposes of standalone selling price analysis (either calculated standalone selling price or estimated selling price), pricing consistency is checked within each pricing dimension value. Therefore, the standalone selling price for a good or service also needs to be established separately for each pricing dimension value.
Pricing Dimension Structure
Pricing dimensions are implemented using the key flexfield infrastructure. You can define multiple structure definitions for the Pricing Dimension key flexfield. Pricing dimensions are captured as segments in the pricing dimension structure.
Pricing dimension structures:
-
Can have up to 30 segments
-
Are assigned to a standalone selling price profile
-
Can vary from item to item
Each segment of the key flexfield represents a pricing dimension.
Standalone Selling Prices
Standalone selling prices for a good or service are calculated for each combination of segment values of the pricing dimension structure. For example, if a pricing dimension structure assigned to the good or service has three segments and each segment has five values, then the good or service can have up to 125 standalone selling prices.
Values for pricing dimensions can be individual values or a range of values. For example, a pricing dimension named Country will have individual values such as:
-
United States
-
Canada
-
France
-
Germany
A pricing dimension named Quantity Sold will typically have different value ranges, such as:
-
0 to 100
-
101 to 500
-
501 to 1000
Each range is a value for the segment. Pricing dimension structures support both individual values and ranges of values to determine the standalone selling price. Pricing dimensions flexfield segments with either individual values or a range of values use a value set of type Independent. In the second case, each range is defined as a value in the value set, and the range details are stored separately as pricing dimension bands.
Assign Pricing Dimension Values
When you run the Identify Customer Contracts process, it extracts source data from the source applications, then automatically runs the Assign Pricing Dimension subprocess. This subprocess analyzes source data and assigns values for the pricing dimensions.
Based on the item in the transaction line, the pricing dimension structure is derived from the standalone selling price profile. The pricing dimension values are analyzed and attached to this line.
Pricing dimension value assignments are based on the user defined attribute mapping. The assignment of values is required for each applicable segment of the pricing dimension structure for every transaction line. If a value for a segment isn't available, then a default value, if defined, is assigned.
For pricing dimensions that are of type Range, Revenue Management reads the detail value provided and assigns the applicable parent value to the pricing dimension.
You can review and update the pricing dimension values assigned by the Assign Pricing Dimension subprocess.
Pricing Dimension Bands
Price bands are assigned as pricing dimension segment values to the document lines and help in categorizing the sale for the purposes of establishing standalone selling prices.
Revenue Management provides the following three types of pricing bands:
-
Quantity band
-
Amount band
-
Set band
Quantity Band
Use the quantity band when the price of the product depends on the number of products sold.
The following example shows a sample pricing policy that has four quantity bands and the corresponding list price per unit.
Quantity Band | List Price Per Unit |
---|---|
0 - 99 |
USD 1000 |
100-499 |
USD 900 |
500-999 |
USD 800 |
1000 or more |
USD 700 |
You should also use the quantity band when the discount percentage is based on the quantity sold, rather than on the list price.
Revenue Management uses the quantity of the transaction line to determine the band the quantity falls in, and automatically assigns the band name as the pricing dimension value.
Amount Band
The amount band is similar to the quantity band, except that the amount band is used when the price of the product depends on the total value sold rather than the quantity sold.
The following example shows a sample pricing policy that has four amount bands and the corresponding list price per unit.
Amount Band | List Price Per Unit |
---|---|
0-9,999 |
USD 100 |
10,000-49,999 |
USD 90 |
50,000-99,999 |
USD 80 |
100,000 or more |
USD 70 |
You should also use the amount band when the discount percentage is based on the total value sold, rather than on the list price.
Revenue Management uses the line amount of the transaction line to determine the band the amount falls in, and automatically assigns the band name as the pricing dimension value.
Set Band
Use the set band type of pricing dimension when you want to assign set names as the pricing dimension value instead of individual values within the set. For example, you can use the set band to assign pricing dimension values by geographic region.
You can define sets and their individual values. You can configure your setup to automatically determine the set name for a transaction using any attribute value of the transaction as the detail value.
The following example shows a set band that is being used for geographic regions:
Document Attribute | Document Attribute Value | Geography Dimension Value |
---|---|---|
Bill-to Customer |
Germany |
Europe |
Bill-to Customer |
France |
Europe |
Bill-to Customer |
Canada |
North America |
Bill-to Customer |
United States |
North America |
In the example, the Bill-to Customer document attribute stores the host country name of the customer who is buying your products. In this case, you configure Revenue Management to use the Bill-To Customer Country attribute value as the basis to determine the value of the Geography pricing dimension. For example, if the bill-to customer country for a transaction is Germany, then Revenue Management automatically assigns Europe as the value of the Geography pricing dimension.
Item Groups
If you have large numbers of items that share common pricing policies, then you can group those items into item groups and establish standalone selling prices at the item group level. All of the items in a group share the value established at the group level.
You can group items into an item group if they satisfy two conditions:
-
All items in the group share a common pricing policy.
-
The standalone selling price for each item is usually established in the form of a percentage. For example, a discount percentage.
For example, InFusion Company has the following hardware systems price list for its commercial customers:
Product Description | Model | Price Per Unit |
---|---|---|
Big Data Appliance |
1187 |
1,200,000 |
Super Cluster |
1902 |
175,000 |
Database Appliance |
1243 |
250,000 |
Virtual Computer Appliance |
1150 |
55,000 |
Storage Appliance |
1102 |
125,000 |
InFusion's discount policy states that they offer automatic discounts based on the total value purchased in a single order, as shown in the following table:
Order Size Range | Discount |
---|---|
Less than 1,000,000 |
8 percent |
1,000,000 to 4,999,999 |
10 percent |
5,000,000 to 9,999,999 |
12 percent |
10,000,000 or more |
15 percent |
In the example, all of the items in the list:
-
Use the discount pricing policy
-
Have the same eligibility criterion for discounts
-
Use the Discount Percentage of Unit List Price as the revenue price representation type
Because the hardware products satisfy all of these conditions, you can group them into an item group and establish the standalone selling price at the item group level.
Standalone Selling Price Profiles
Standalone selling price profiles are user-configurable profiles. The profiles contain the details Revenue Management uses to derive the standalone selling price for the item, item group, memo line, or performance obligation template.
Use standalone selling price profiles to define the following for the item, item group, memo line, or performance obligation template:
Name | Description |
---|---|
Pricing dimension assignments |
Specifies the pricing dimension assignment to which the standalone selling profile is attached. |
Minimum standalone sales |
Assesses whether the observed standalone selling price calculated by the application is valid, based on whether the minimum number of standalone sales is met. |
Item classifications |
Defines the category of the item, memo line, or performance obligation template. |
Price tolerances |
Specifies the standalone selling price tolerance usage, which can be Median, High, or Low. |
Coverage |
Specifies the number of months covered for the calculation of observed standalone selling price. |
Effective period range |
Specifies the effective start and end period for the item, item group, memo line, or performance obligation template that's assigned to the standalone selling price profile. |
Standalone Sales Pool Exclusion Rules
Revenue Management uses standalone sales pool exclusion rules to automatically exclude standalone sales lines from the sales pool used to calculate observed standalone selling price values.
The Calculate Observed Standalone Selling Prices program uses these rules to determine if any sales pool lines are to be excluded from the calculation of the standalone selling price.
For example, a supplier may want to single out some older versions of computer accessories, such as printers and headsets, and place them for sale at a low price. The supplier may decide not to include these sales in the calculation of observed standalone selling prices.
FAQs for Define Revenue Management
What's an item group?
An item group identifies a group of items that share the same pricing policies and a common standalone selling price.
Items inherit the standalone selling price from the item group if they are assigned to an item group. Usage of item groups is recommended when the representation type is Discount Percentage.
Item groups allow you to establish standalone selling prices for groups of items, which allow you to substantially reduce the number of standalone selling prices you need.
What's an implied performance obligation template?
Implied performance obligation templates are templates you use to define rules for creating implied performance obligations. The rules are used to automatically create implied performance obligations in customer contracts.