Price Approval System

[Former Member]

This document deals with the requirements in a price approval process and different features of

R/3 that helps achieving these. The document intends to list the key areas which are not

sufficiently covered and requiring custom developments. It also covers the key considerations that

would also help make the solution complete.

1. Need for a Price Approval system

Price management, being a key area for the business, always has scope for enhancements to support

the newer requirements of the business around establishing transparency, control and better

analytics/reporting.

Lack of control in price updates (creation/modification) will have adverse effects on the customer

satisfaction and profitability of the transactions. While authorisation/security can address controlling

the user access to the price data, it will not be adequate as there is still a dependency on an

individual user and the data he feeds. Thus the business would need an approval mechanism which

can validate at one or more levels if the price is suitable for the customer and the business, before it

is used in transactions. It will delight the business if they can also be provided with an option to have

a view of the impact on the final price. This can also help the approvers validate the price before

finally approving it and additionally it equips the sales force to handle negotiations with the

customers. Once the final net price could be calculated it would help comparing it with a threshold

price (Cost + minimum margin = Least Net Price or Threshold Price, below which the business does not wish to sell the

product).

2. Basic Flow of a Price approval function

An advanced process could include Mobility feature allowing approvers to access the application and approve the Price record remotely from a mobile device.

3. Price approval requirements:

Basic requirements:

• Condition records created should be available for pricing only after they are approved.
• An approval workflow to route the requests to different approvers based on a set of pre-defined criteria.

           Nice to have requirements:

• A function to calculate the net price to see the impact of this record on the current net price
• Comparison of net price with a Threshold price
• Only approved prices should be created in the production system.

4. An Overview of Relevant features existing in SAP:

• Condition tables with “release status” allow controlling the release of condition records for pricing. Processing statuses can be maintained for condition records and release statuses assigned to these control the usage of the record.

• Pricing condition type can be configured as Statistical – can be used to store the threshold prices and retrieve them for comparison.
• Workflow can be maintained under Business Transaction Event 00503303. Workflow would allow approval of records thereby releasing them for pricing.
• V_NL price simulation available to calculate the net price using the records that are not approved and only released for simulation.

• “BAPI_SALESORDER_CREATE” function module can simulate Sales order creation and return the condition records that are determined during the pricing. With inputs in Order Header, Partner and Item structures, the conditions determined are returned in the output.

   

• “PRICING” function module with inputs of KOMK and KOMP, can return the price elements determined.

5.    Few Known Limitations with the Price Simulation in SAP:

1. V_NL  Net price Simulation using invoice creation method, requires specific inputs like Plant, billing type, item category etc. possible for only 1 material at a time, does not provide details of the condition values.
2. When the condition records are created with release status (released for simulation), though V_NL considers such records, the output does not provide the details of the records determined, depriving us the visibility on the price elements that contributed to the net price.
3. When Sales order creation is possible to be simulated using standard bapi, the price calculated does not consider the records released for simulation only.
4. Create condition tables with release statuses and maintain condition records with release statuses as required.
5. Configure BTE/workflow to approve price records and release it for pricing.
6. Introduce a net price calculation function.
7. When triggered, Sales order is simulated with basic inputs (customer, material, Qty, UoM, pricing date, Sales document type and Sales area) to return with the details of price conditions determined.
8. In order to allow the unreleased records to be considered for simulation, modify LV61AA29 to change conditionally the value of CALL_MODUS from “A” to “C”, so that the SD_COND_ACCESS function module considers the records available for simulation.

6.     Possible solution using a mix of these features overcoming the limitations

• Create condition tables with release statuses and maintain condition records with release statuses as required.
• Configure BTE/workflow to approve price records and release it for pricing.
• Introduce a net price calculation function.
• When triggered, Sales order is simulated with basic inputs (customer, material, Qty, UoM, pricing date, Sales document type and Sales area) to return with the details of price conditions determined.
• In order to allow the unreleased records to be considered for simulation, modify LV61AA29 to change conditionally the value of CALL_MODUS from “A” to “C”, so that the SD_COND_ACCESS function module considers the records available for simulation.

7. Different Architecture Options:

The following section covers a few different options to build the Price approval solution and brings out the advantages of going for an all-SAP solution that eliminates any need for interfaces and integration with external systems.

7.1 Custom application integrated with SAP

Choice of Middleware and the platform for the custom application development can be made based on the current market offerings and its ability to meet the needs. The above fig is a representation of the architecture and does not insist or recommend any particular middleware system.

Assumptions:

• Only approved records allowed to be created in the production system
• Threshold price comparison only against the net price
• Mobility solution required
• All mobile devices will be of the same model – requiring single application development

Solution

• Custom application to handle price creation and change.
• Initial Price extracted from SAP and loaded in the database of custom application.
• Master data synchronisation with SAP through interfaces.
• Net price calculation triggers RFC call to SAP
• Approval workflow configured within Custom application.
• Upon approval prices sent to SAP and updated.

Advantages

• Friendly User interface.
• Offers better flexibility and can overcome the limitations of the package systems.
• Increased Reporting capability.
• Users who are just approvers need not have to access SAP.
• Custom application may offer better mobile capabilities.
• Key advantage: A single application can manage price approval in multiple SAP instances.

7.2      SAP Price approval solution (Release Status based) in SAP Production client

Assumptions:

• Mobility solution required
• All the condition tables are maintained with Release status
• For those condition tables without release status, approvals are not required and the records can be maintained directly
• Threshold price comparison only against the net price
• All mobile devices will be of the same model – requiring single application development

Solution

• Condition records are created with a status that does not disturb the regular pricing.
• The workflow for approval is triggered. The approver will “release” or “block” the record, using the status.
• Net price calculation will also be possible using the same BAPI internally.
• Net price calculation will consider the new records and provides the new net price (eliminating extrapolation from the current price)
• Threshold price maintenance; comparison while submitting and approving.
• For mobility, a middleware integration like Sybase platform can allow mobile devices to interact with SAP. An application will be created for the mobile devices.

Advantages:

• No external application requiring replication, maintenance of master data.
• Not necessary to copy/replicate the validity date management rules of SAP.
• No external configurations/ replication of pricing procedure
• Approved records are directly released for use in SAP pricing, no integration required.
• Eliminates Latency around data updates.
• SAP features (Material search, customer search, product hierarchy, net price simulation, UoM conversion, currency conversion) are re-used and not to be built.

7.3 SAP Price approval in a different client than the Production

Assumptions:

• Only approved records allowed to be created in the production system
• Threshold price comparison only against the net price
• Mobility solution required
• All mobile devices will be of the same model – requiring single application development

Solution

• In a different client meant for Price approval maintenance - Condition records are created with a status that does not disturb the regular pricing.
• Standard interfaces (message types) to update master data in the price approval system.
• The workflow for approval is triggered. The approver will “release” or “block” the record, using the status.
• Net price calculation will also be possible using the same BAPI internally.
• Net price calculation will consider the new records and provides the new net price (eliminating extrapolation from the current price)
• Threshold price maintenance; comparison while submitting and approving.
• Approved records are transferred to the production system (ALE transfer)
• For mobility, a middleware like Sybase integration will allow mobile devices to interact with SAP. An application will be created for the mobile devices.

Advantages:

• No date management
• No external configurations for pricing procedure
• Approved records are directly released for use in SAP pricing, minor integration with no middleware requirements as the data exchange between the SAP clients are using ALE.
• SAP features (Material search, customer search, product hierarchy, net price simulation, UoM conversion, currency conversion) are re-used and not to be built.

7.4 Comparison of Different Solution Options

Solution  Features	Custom Application	SAP Solution in Production Client	SAP Solution in non-Production Client
Integration requirements	Heavy	None	Simple – ALE integration
Development complexity	High	Low	Low
Database	Separate	Common	Separate
Flexibility	High	Low	Medium
Re-Use of SAP functions	Low – only price simulation is used	High – material search, customer search, Validity date management, Product hierarchy, Currency and UoM conversions	High - material search, customer search, Validity date management, Product hierarchy, Currency and UoM conversions
Mobility	High	Medium	Medium
Reporting	Good	Good	Good
Accuracy	Medium -  complex to achieve	High – due to high re-usability	High - due to high re-usability
No of SAP instances supported	Multiple	Only One	Limited
Control on Approval Function	High – as it can be tailor made to meet the requirements	Within the limitations of SAP workflow administration	Within the limitations of SAP workflow administration
Maintenance	High	Medium	Medium
Cost of Ownership	High	Low	Low
SAP licenses	Non SAP users can create/approve Prices	All users in SAP	All users in SAP

8 Key Constraints:

Knowing these following constraints will help estimating the additional development effort required to mitigate them.

8.1 Price Update through inbound message – (with SAP solution)

1. Inbound Idocs of standard message for price records COND_A always creates a new price record. Changes made to a record in the approval system cannot have the same change effect on a particular record in the production system.

8.2 Constraints with EDIT Condition record – (with SAP solution)

1. If the approval system is in Production client, the Condition record modification will have to be necessarily done by creating a new record, as otherwise the existing record will cease to be available for pricing until the change is approved.
2. If the approval system is different than the production, then the changes can be done on the same record, however, the transfer of that record to production will result in creation of a new record.
3. Validity date changes may not be subjected to approval, as otherwise there is a risk of incomplete updates as in the case of validity reduction. The change (Reduction) of validity period of a record, when handled with creation of a new record, will leave an unwanted residual part.
4. When the price approval system is same as the production system, if every change is effected by means of a new record, the change log will be scattered. But if the price approval resides in a different client, the change log in that system can be relied upon. However, making changes to the same record and upon the change being rejected, the record itself may be parked as inactive and the original price (before change) may be lost.
5. Warning messages (in case of overlapping conditions), that makes the user aware of existing records that may be overwritten, will be suppressed in this solution as the status change from “simulation” to “Released” will update the database in the background.
6. Additional developments maybe required to address such issues.

8.3 Constraints with Price simulation:

1. For a sales order simulation to take place, the header (customer) information along with material and quantity details are required. For condition records whose key combination does not have a customer, a representative value for customer field should be fed to make the sales order simulation possible.
2. Same applies for those records that do not have a material in the key combination. However, if any of the material attributes (like material price group, Material group, Product hierarchy etc.) will be part of the key combination, then the material selection should be considering these parameters. Such a selection could result in more than 1 material and the simulation can be done for all those materials to see the price impact for each of them.
3. The objective of net price comparison with threshold price would be to validate that the least possible net price does not fall below the threshold price. For records maintained with scales, the least possible price will be determined for the highest scale quantity. Therefore, the simulation should always be done for the highest scale quantity to have the best price and best discount applied for the calculation.

9 Other Technical Information relevant for understanding

          Environment from which SD_COND_ACCESS is called up

The use of condition technology for Pricing can be carried out in three different sessions, which can lead to different results (condition records found). The following sessions are possible:

• In the Pricing ('A') session, the released condition records, that go through Pricing in the documents are retrieved.
• In the Planning ('B') session, the released condition records (for CO-PA) are retrieved, that have been released for planning.
• In the Simulation ('C') session, condition records that have been released for simulation (for example, for the net price list) are retrieved.

If several condition records are found at the access with different release statuses, the following priorities apply: 

• Pricing:

only for the release status released

• Simulation:

  first released for simulation 

then released for planning and simulation

then released

• Planning:

then released for planning and simulation

then released

Determination of Call modes based on Events in Condition Processing:

Different Call Modes

A             Pricing

B             Planning

C             Simulation

Events in Condition Processing:

01           Sales price calculation

02           Purchase price simulation

03           Purchasing document

04           Goods receipt

05           Invoice receipt

06           Master conditions maintenance

07           Profitability analysis

08           Price simulation in Sales and Distribution

09           Vendor billing document (agency business)

10           Payment document (agency business)

Standard usage of call modes for different Events is as shown below:

Event	Call mode
07 Profitability analysis	B (Planning)
08 Price simulation in Sales and Distribution	C (Simulation)
all other events	A (Pricing)

Only in V_NL, the simulation Call mode is determined. In this Billing document simulation takes place.

In other sales order simulation functions, the price determination takes place with released records and price simulation does not happen.

10 Other considerations

1. If Price details are extracted and loaded in BI, impact of this solution on the reporting to be studied – this concern may be valid only in case of having the price approval solution in the SAP production client.
2. Regulatory/ compliance requirements -  SoX, data security etc..
3. When the approved record is transferred to the production system, the whole family of valid records for that VARKEY can be sent, so that the production system gets the complete update for the entire period. This may result in more number of records in the database.
4. On existing systems, where the condition tables do not have Release status included, additional condition tables will have to be created and migration of records will be required. SAP offers the option of converting old condition records without a release indicator into new condition records with a release indicator. The report SD_MOVE_A004_TO_A304 can be used as an example report for the condition tables (For other tables you can copy the report and enter the source and destination table in the source text). The report run deletes the old records and creates new ones with the release status set as released. When you set the report you can restrict conversion for specific condition types.

11 Summary

This document focussed on highlighting the internal capability within R/3 to host the price approval function. Key focus was on

1. Basic expectations from a price approval application
2. Achieving the net price simulation which is not adequately served by the V_NL transaction and the sales order simulation function modules.
3. Constraints with the price record update and the net price simulation
4. Highlighting advantages of SAP solution
   1. Re-use standard capabilities like price calculation, UoM conversion, Currency conversion
   2. Eliminate parallel master data management
   3. Eliminate need for multiple interfaces