1. Administering Pricing
  2. Service Mapping

Service Mapping

Use a service mapping to integrate Oracle Pricing with inputs to pricing, objects in Pricing, and outputs from Pricing.

A service mapping is a map that creates relationships between services, sources, entities, and attributes. It specifies a group of pricing entities and attributes that a service can retrieve and update.

A service mapping is a map that integrates Pricing with inputs to pricing, objects in Pricing, and outputs from Pricing, such as priced documents. It creates relationships between sources, entities, attributes, services.

Note

  • Map sources to entities that Pricing can use to price the document. Sources include your customer data, such as from Trading Community Architecture, product data, such as from Product Information Management, and data about the transaction that Pricing must price, such as a sales order from Oracle Order Management.

  • Use entities to group attributes into hierarchies that a service can retrieve and update.

  • Use services to map inputs to outputs, prepare data for algorithms, call algorithms, then communicate the priced document to the application that requires pricing, such as Order Management for a sales order.

Here's an example.

Map entities and attributes in a declarative environment without having to write software code.

Note

  • Map entities and attributes in a declarative environment without having to write software code.

  • Use an order capture system as the source, such as Order Management or your legacy capture system.

  • Map your attributes. For example, assume you sell professional services and your legacy system refers to your customers as clients. Map the Client attribute in your legacy system to the Customer attribute in Pricing.

  • Extend entities to add your own behavior.

    For example, Pricing comes predefined to map all attributes in a sales order. You can modify the service mapping to map only some attributes. Add your own attribute to use in price calculations. For example, add a descriptive flexfield in Order Management that stores details about your own attribute, then use a service mapping to map it into Pricing.

Represent Different Types of Documents

Pricing receives requests to price documents from different applications.

Pricing receives requests to price documents from different applications.

For example:

  • Price a sales order from Order Management.

  • Price a contract from Contract Management.

  • Price a material transfer from Inventory Management.

Documents have similar characteristics.

  • They have similar pricing requirements. For example, they all need to calculate price according to pricing strategy, pricing segment, customer profile, and so on.

  • They need Pricing to calculate price consistently.

    For example, assume you create a sales order for the AS54888 desktop computer for customer Computer Service and Rentals in Order Management. Sometime later, you create a service contract for the AS54888 in Contract Management. Pricing needs to apply the strategy, segment, and discounts in the same for Contract Management that it does for Order Management.

  • They have attributes that exhibit similar characteristics. Use a service mapping to represent them with a single attribute in Pricing. This helps to simplify your pricing set up and maintenance.

    For example, assume Order Management, Contract Management, and Inventory Management each include 10 attributes there are similar to one another, resulting in 30 attributes that Pricing must process or represent. You can map all 30 into 10 attributes in a service mapping instead of representing and processing 30 attributes.

Map Inputs to Outputs

A service mapping contains entities, sources, and services. Pricing uses it to map the input SDO to the output SDO.

Here are some of the main parts of the predefined Sales service mapping. Pricing uses it to price a sales order.

some of the main parts of the Sales service mapping

You can define objects in a service mapping.

Object

Description

1. Source

The source is a mapping that specifies the relationship between the source and entities. It provides a structure so Pricing can model data in the input SDO.

For example, the predefined Sales service mapping includes the OrderTotal source, and this source includes details about the Order Header and Order Line.

  • Maps between the OrderLine source and the Header entity

  • Maps between the OrderLine source and the Line entity

2. Service

Pricing uses the PriceSalesTransaction service to price a sales order.

Here's how you use the service.

  • Reference the Java method or pricing algorithm that calculates price.

  • Map inputs to outputs. For example, the PriceSalesTransaction service references the Line entity, and it allows read and write actions on the Line entity.

A service mapping service isn't a web service.

You can use the predefined services for most implementations.

3. Entity

Reference the entities that the service mapping requires to structure the output SDO.

In this example, the output SDO includes four entities. Each entity references one or more attributes. For example, here are the attributes that the Header entity references.

  • PricingStrategyId. Allows the service mapping to map the input SDO to the pricing strategy on the output SDO.

  • PricingSegmentCode and CustomerId. Allows the service mapping to map the input SDO to the pricing segment on the output SDO.

Here are the properties you can set for an entity on a service.

  • Entity. Select the entity you require from the list.

    If you need a new one, then click Actions > Add Row. Enter a unique name, and use camel capitalization, such as MyEntityName.

  • Alias. Don't use an alias. Leave it empty.

  • Read. Enable this option when you use this entity as an input to pricing. Pricing will populate it on the input SDO.

    For example, Header.CustomerId is a read-only entity, so enable Read but don't enable Write.

  • Write. Enable this option when you use this entity as an output from pricing. Pricing will populate it on the output SDO.

    For example, you use the Charge entity to read and write, so enable Read and enable Write.

4. Attribute

Reference the attributes that the service mapping requires to structure the output SDO. Each service mapping fulfills a finite purpose.

For example, the Sales service mapping prices a sales order, so it references attributes that a typical sales order includes, such as ItemId so it can identify the item in the sales order, and UnitPrice so it can multiply unit price by quantity, and do other calculations.

Here are the properties you can set for an attribute on an entity on a service.

  • Attribute. Select the attribute you require from the list. The list displays all attributes that the entity contains.

  • Alias. Don't use an alias. Leave it empty.

  • Read. Enable this option when you use this attribute as an input to pricing. Pricing will populate it on the input SDO.

  • Write. Enable this option when you use this attribute as an output from pricing. Pricing will populate it on the output SDO.

Read and Write on the attribute are independent of Read and Write on the entity. For example, if you enable Read and disable Write on entity y, but enable Read and Write on attribute x, then Pricing will populate attribute x on the input and the output SDO.

Other service mappings might reference an entirely different set of attributes. For example, Order Management uses the SoldToPartyId attribute to identify the customer, but Contract Management uses PartyId. You can use a single attribute in the service mapping, such as HeaderId, to represent SoldToPartyId and PartyId, then use the same service mapping to price sales orders and contracts.

Example

Here's how you map between the Header entity and the OrderHeader source.

the map between the Header entity and the OrderHeader source

If the Order Entry Specialist enters a value in the Customer attribute, then Pricing uses the PriceSalesTransaction service because this service references the Price Sales Transaction algorithm that identifies the strategy, and it uses the OrderHeader source because the Customer attribute is part of the order header where the Order Entry Specialist enters the customer name.

Sources

A source is the data source that Pricing uses to create the input service data object when it calls the service on a service mapping.

A source is the data source that Pricing uses to create the input service data object when it calls the service on a service mapping.

Pricing comes predefined with sources for Order Management and Contract Management, and these sources already include entities and attributes. For example, the OrderHeader source includes entities and attributes that represent attributes you find on the order header, such as CustomerId to represent the Customer attribute on the header, and SellingBusinessUnitId to represent the Business Unit attribute.

Here are some of the more important sources you use to price a sales order.

Source

Description

CalculateSalesTotals

Calculate price totals on the sales order.

CreateRollupCharges

Calculate roll up charges on the sales order.

GetSalesPricingStrategy

Determine the default pricing strategy.

PriceSalesTransaction

Price a transaction in the sales order.

PricingResultsPresentation

Display the price breakdown.

SalesOrderTotalsPresentation

Display the totals breakdown.

ValidateSalesPrices

Validate prices on the sales order against pricing guidelines and other pricing rules.

Services

Pricing uses its own services to price a document. Some services are internal. The reside inside Oracle Pricing. Others are external. They reside outside of Oracle Pricing.

Internal Services

Pricing uses its own internal services to populate values in the pricing algorithm.

Pricing uses its own internal services to populate values in the pricing algorithm.

Note

  • The term internal means Pricing calculates these values entirely within Oracle Pricing and doesn't share them with the calling or any other application, such as Order Management.

  • The term external basically means any processing that happens outside of Oracle Pricing, such as rendering price in the price breakdown of a sales order in Order Management.

  • PriceRequestInternal is an example of an internal service. It comes predefined with entities and attributes that Pricing uses to populate values in the algorithm.

  • The child attributes of an entity inherit the Internal value from the entity. For example, if the Charge entity is Internal, then all child attributes of Charge are internal.

Customer and Item Data

Pricing uses the PartyAttribute entity and the PartyOrganizationProfile entity of the Sales service mapping to store data about your customer who purchases the item.

Pricing uses the PartyAttribute entity and the PartyOrganizationProfile entity of the Sales service mapping to store data about your customer who purchases the item.

Pricing gets this data from the set up you do in the application you use to store customer data, such as Trading Community Architecture.

Pricing uses the ItemAttribute entity to store data about the item you need to price.

Pricing uses the ItemAttribute entity to store data about the item you need to price.

Pricing gets this data from the set up you do during design time in Product Information Management. For example, if you set the value for the item as AS54888 in Product Information Management, then the Item Number attribute of the ItemAttribute entity in Pricing contains AS54888 at run time.

Profiles, Segments, and Strategies

Pricing uses profiles, segments, and strategies in all pricing scenarios. It stores profile data in the CustomerPricingProfile entity. It uses your design time set up on the Manage Customer Pricing Profiles page to determine the attributes to use, such as Cost to Serve, and the value to use for each attribute, such as Medium.

It stores profile data in the CustomerPricingProfile entity. It uses your design time set up on the Manage Customer Pricing Profiles page to determine the attributes to use, such as Cost to Serve, and the value to use for each attribute, such as Medium.

Price Lists

The ChargeCandidate entity contains runtime values according to your design time set up on the Manage Price Lists page.

The ChargeCandidate entity contains runtime values according to your design time set up on the Manage Price Lists page.

For example, at design time, assume you set up a price list for customer Computer Service and Rentals, and add item AS54888 with a base price of 2500 and calculation method of Price. Here's what pricing does at run time.

  • Sets the Base Price attribute of the ChargeCandidate entity to 2500.

  • Sets the Calculation Method attribute to Price.

  • Uses values from the price list to set all the other attributes.

  • Calculates ChargeCandidate each time that you add an order line, and uses these values to create charges and charge components.

Other Lists

Other lists, such as discount lists, work the same way.

Other lists, such as discount lists, work the same way.

Note

  • If you set up a discount list on the Manage Discount Lists page, then Pricing uses design time values from the discount list to populate attributes on the DiscountCandidate entity at run time.

  • If you set Item Level on the discount list to Item, then Pricing sets the ItemLevelCode attribute of the DiscountCandidate entity to Item.

  • Pricing also uses the TermSetup entity to store details about the discount, such as AdjustmentAmount.

Inherit Attributes from Other Services

Some service mappings inherit their entities and attributes from another service mapping. For example, the Header entity of the PriceSalesTransaction service mapping doesn't include any attributes. But don't worry. It inherits header attributes from the PriceRequestHeader service instead.

Some service mappings inherit their entities and attributes from another service mapping.

Note

  • Click Inherit from Services to view the list of services.

  • PriceSalesTransaction comes predefined to inherit the entities and attributes that these services reference. For example, PriceRequestHeader references the AllowCurrencyOverrideFlag attribute, so PriceSalesTransaction inherits AllowCurrencyOverrideFlag.

  • This set up enables you to make modifications in one service, PriceRequestHeader, then use them in PriceSalesTransaction, or any other service mapping that inherits from PriceRequestHeader.

  • Inheritance includes the Read and Write set ups from the parent. For example, if Read is enabled and Write is disabled on AllowCurrencyOverrideFlag in PriceRequestHeader, then Read usage is enabled and Write usage is disabled on AllowCurrencyOverrideFlag when you use it in PriceSalesTransaction.

  • PriceSalesTransaction also comes predefined to inherit from other services, such as PriceRequestLine for all the entities and attributes that an order line contains.

  • Inheritance saves you time and maintenance because you do most of your entity and attribute set up in a single parent service instead setting up entities and attributes in a bunch of services, then having to manage all of them.

Here's the relationship between the parent and child.

relationship between the parent and child

  • Modify the parent and you're done. Your modifications are automatically available in the child. You don't need to do any other set up.

  • The child inherits all the entities and attributes from the parent. Use them as if you set them up on the child.

PriceRequestInternal

PriceRequestInternal inherits entities and attributes from other services. If you must modify behavior that one of these other services control, then modify it instead of modifying PriceRequestInternal. For example, modify CalculateSalesTotals to change behavior that Pricing uses to calculate the sales order total.

PriceRequestInternal inherits entities and attributes from other services. If you must modify behavior that these other services control, then modify it instead of modifying PriceRequestInternal.

Output

Here are the entities where Pricing writes data into the view object it uses to communicate output details back to Order Management after it finishes pricing.

Here are the entities where Pricing writes data into the view object it uses to communicate output details back to Order Management after it finishes pricing.

Here's the structure it uses. The structure reflects the structure of a sales order.

Header
  Line
    Charge
      Charge Component
      Charge Component
      Charge Component
      Charge Component

Dot Notation

The service mapping uses dot notation.

Service.Entity
    Entity.Attribute

where

  • Service is the name of the service.

  • Entity is the name of the entity that the service contains.

  • Attribute is the name of the attribute that the entity contains.

For example:

PriceSalesTransaction.Header
    Header.CustomerId

where

  • PriceSalesTransaction.Header identifies the Header entity in the PriceSalesTransaction service.

  • Header.CustomerId identifies the CustomerId attribute of the Header entity that resides in the PriceSalesTransaction service.

For another example.

PriceSalesTransaction.Line
    Line.InventoryItemId

where

  • PriceSalesTransaction.Line identifies the Line entity in the PriceSalesTransaction service.

  • Line.InventoryItemId identifies the InventoryItemId attribute of the Line entity that resides in the PriceSalesTransaction service.

Examples of Using Service Mappings

Get detailed instructions about how to use service mappings to meet your business requirements.

Related Topics