We were requested to verify variance on RFx's. The Basic concept is to check that prices supplied by suppliers does not jump massively between RFx's and PO's.
So the requirements:
-> Validate at the point of the accept button being pushed on an RFx Response if the price is X% more than the average for the previous 3 months prices of PO's.
-> If it is more than X% then throw an error so that the RFx response cannot be accepted.
-> The user accepting the response must then type in the reason for the increase in price (such as fuel increase, weak currency ect) into the header text field.
-> The error must then change into a warning so that the RFx response can be accepted yet still show there was an error.
Our consideration:
-> We firstly thought of using an RFC call to find the last 3 months average price in real time. The issue with this is that you are reading ECC tables such as EKKO for ECC PO's
-> We do not want to slow down the process by having slow RFC validations done multiple times a day
-> We needed to consider the currency to compare, you cannot compare USD and EUR directly there needs to be a conversion
-> What proof is there that the custom validation is working in terms of ROI to business
-> We considered reading the last 3 months RFx prices in SRM for the material but realised that if a contract just expired there would not be any RF'x in the last three months so we needed the PO price.
-> The validated time period and the X% would need to be changeable to ensure we can tweak the process as needed to ensure the right validations and not pick up general inflation.
Our decisions
So what did we decide. Firstly we did not make use of an RFC instead we made use of a report in ECC. We wrote a quick report to pull out all the materials we require validations to be done on. This report then generates a 'csv' file output onto an SFTP. We then wrote an upload program in SRM to retrieve the information out of the file and store it in a custom table in SRM. Now when someone clicks accept it is a quick validation into this custom table in SRM to check the average price for the last three months. At this point when the validation is done it also does the necessary conversions so that EUR is compared to EUR and so on.Then to ensure there was some way to ensure ROI we logged all errors produced due to fluctuating prices and then also logged all reasons provided so that business could have a report on these. We also did a quick easy maintainable table to activate and deactivate the validation as well as the x% to validate Below is a very short and simple overview of how it was implemented:
Advantages of this design:
1. Any material not in the custom table in SRM would not be validated so the report in ECC could be filtered to ensure only those materials we want validation to be done for could be.
2. No Slow RFC calls in real time
3. Easy changing x% and activation and deactivation
4. Provides easy access to reports
5. Can be scheduled so no manual report running, and EKKO table reads could be done outside work hours
6. The time period for averaging can easily be be changed by changing the variant in the ECC report with no impact on the SRM side.
Disadvantages of this design:
1. The design requires an SFTP server to be available
2. Only daily averages not real time averages
3. A large amount of customization
4. Use of only the header text for reasons, so it is not per line item and if the header text field is used for anything else it would by-pass the validation
5. Manager responsible for seeing the warning and checking an acceptable reason has been provided.
This really was a nice implementation there are some flaws and places the design could be improved such as maybe using an RFC but not real time on a scheduled basis. So schedule an RFC in SRM to fetch the lastest averages directly from ECC every hour lets say. This would also remove the SFTP server portion. Also validating per line item and requiring a reason per line item could be advantageous but in our implementation business did not require per line because the reasons would typically affect all line items. Another nice improvement would be to have a dropdown with common reasons not just free text . Have around 5 common reasons and then have an other with free text. This way much better reports could be generated. This validation protects the company from both finger trouble when prices are entered as well as from suppliers over charging.
I hope this helps someone else and that you feel it is a worthwhile effort.
- SAP Managed Tags:
1 Comment