I would like to share a requirement from one of our clients and how its achieved in standard!
One of our client mainly uses value contract for services. The services contract contains specific services and the corresponding unit rates. Users can refer these contracts in the work order or in PR. The process simple and is standard SAP functionality itself.
Now, the requirement came from department to fix the price in service PR for services selected from the contract. Means, if the services are selected from contract, the unit rate should not be changeable. If services are entered manually, price should be changeable. I have checked the common options in standard, like:
- Make field selection for PR document type – The price is in services tab and hence this option not applicable.
- Make field selection for services in ML90 and hide the “price” field. – it will make the field greyed out for all cases, irrespective of whether the services are selected from contract or manually entered.
I couldnt find any other direct option in standard and planned go for customizing. But the client was so adamant and refused the proposal of development and they wanted it in standard SAP itself!!!
I tried other possibilities and at last found an option through service pricing! The approach is explained below:
- The back bone of the approach is the concept of service conditions which will affect the gross price directly.
- If there is a condition type in the service PR / PO which is affecting the gross price, the gross price field will be greyed out in the “services” tab (in PR & PO)
The configuration steps are as follows:
1. In OLMSRV – Maintain Conditions for Services – create new condition table with “transaction/event” as a field. I have selected this field, since we can differentiate the condition record based on transactions – for example, “1” for PR.
2. In OLMSRV – Maintain Conditions for Services – create new access sequence and assign the condition table:
3. In OLMSRV – Maintain Conditions for Services – Create two condition types as below:
- Two condition types are created, since we need to nullify the amount.
- Percentage condition is maintained as negative.
- Assign access sequence (created in step 2) to both condition types.
- Exclusion indicator is X for PRSX condition type – control data 2 and condition exclusion “N” in PRS condition type *Major step*
4. Condition category as V (Price Component):
- Maintain the condition category as “V”, price component for both the new condition types:
- No routine assigned to PRS and PRSX
- If the value is automatic, (from contract or from condition record), PRS will be active, which makes PRSX inactive since both are base price conditions.
- Now, based on the routine 6, ZC00 and ZC01 will be active only if there is no condition type with exclusion X. That means, conditions ZC00 and ZC01 will be active if PRSX is inactive.
5. Maintain condition record for the condition types in ML51:
Condition ZC00: Contract Adjust ➕
- Maintain any value greater than 0
Condition ZC01: Contract Adjust ➖
- Always maintain 100% ➖ , which will nullify the ZC00 value.
6. Test the scenario:
- Create PR and refer services from contract:
- Conditions ZC00 and ZC01 will be active now. Based on the condition record value, both conditions will be nullifying the effect as shown below:
- Since its affecting the gross price directly, the price field will be greyed out and no changes can be made: 🙂
- Enter service item manually, without selecting from service contract:
- Now, PRSX condition (manual price) will be active and hence the custom conditions will be inactive (due to the requirement type 6 assigned against the conditions in pricing)
- Since there is no conditions affecting gross price, the gross price will be changeable as shown below: 🙂
- Service price wont be changeable in PR if the services are selected from contract or PRS condition is triggered. 🙂
- The gross price will be editable for any manual service items in PR.
- Same can be achieved in release order as well, with ML51 condition record setting for PO.
- Since there is no account keys / direct account postings for service conditions, there is no impact on accounting. 🙂
I have tested the end to end scenario with the above config and found its working perfectly. You may check the scenario and revert back in case any further assistance required.
Thanks for reading the document and thanks for your time.