Article: Problem of credit block recurrence in SAP.
Summary: Article includes the case study for credit block recurrence in agribusiness along with the solution delivered.
Author: Kamal Dial
Created on: 30th September, 2013
Author Bio: Kamal is a Consultant at Infosys and has over 13 years of professional work experience in SAP Sales and Distribution module. He is engineering graduate from PEC Chandigarh and post graduate in Management from Symbiosis Pune. He would like to thank his team members Amerjit Singh Mann, Satish Sivasankar, Arturo Minguer and Naveen Advani for their contribution towards this implementation.
Credit Management –Introduction
Credit is facility provided to customers so they need not pay immediately and payment can be done at a future point of time after receiving the goods or services. The amount of credit extended is determined by the customer’s credit worthiness which is called credit Limit.
Purpose:
Credit management involves managing credit limits for every customer at regular intervals which helps in keeping track of payment records for customers .It helps in increasing the sales for an organization along with risk mitigation.
Case study:
This case study is specific to agribusiness industry where problem of recurrence of credit block impacts the whole business line taking into consideration the small shelf life of seeds sold to the end customer. Its increases in the lead time of the whole process from order to invoicing involving additional approvals and unnecessary credit blocks becomes bottleneck in the delivery process.
Problem statement: After sales orders are released from credit block it may happen that after another availability check of the document, the document runs through the credit checks and is blocked.
Reason:
The credit block recurrence occurs due to changes the confirmation quantity in the order which leads to credit block again and again. It happens in the scenario where shortage occurs and before delivery system carries out another availability check which confirm more than the initial released quantity.This problem of recurrence leads to additional approvals from Credit managers increasing the lead time in the system.
Credit exposure calculation and moment of updating the same- Exposure calculation is based on the confirmed quantity and exposure is also updated in case order goes into credit block.It leads to scenario where subsequent orders are also blocked as exposure is updated by initial order of high credit value.
Hence this leads to problem of recurrence which impacts the overall delivery time and increases the lead time involved which is very critical for agribusiness industry.
SAP notes referred: SAP Note 100861, 1042857, 1324433 ,377165,751044,666587.
SAP Standard Behaviour with AS IS situation:
As per standard SAP calculation of Credit Exposure involves receivables, Spl Liability and sales Order value. Receivables are total billed transactions passed to accounting and Spl Liability includes the advance payments.
Total sales order value is summation of open Order value, open delivery value and open billing value.
– -Open order value
• The open order value is the value of all order items which have not been delivered yet.
– -Open delivery value
• The open delivery value is the value of all delivery items which have not been billed.
– · Open billing value
• The open billing value is the value of all billing items which have not been transferred to Accounting.
For below example: With ordered quality as 100EA, confirmed quality as 50 EA and credit value 10$ , Total sales order value becomes 500$
We consider business scenario where credit exposure (1000$) exceeds the credit limit
Since initially stock confirmed is 50 EA, order credit value is 500$ and Credit exposure is updated to 1500$.
If stock confirmation quantity increases to 80 EA, Order credit value becomes 800$ and order goes into check block again. Once released exposure is updated to 1800$.
Hence even after releasing the order increase in the confirmation leads to credit block again and again.
Solution implemented
1) 1) This involves changes in the standard SAP User exits RMCS1US1 and RMCS1US3.
For credit release –sales order value should be updated based on the order quantity instead of open confirmed quantity. This can be controlled via changes in the standard user exists RMCS1US1.
To make sure released credit value and update of open sales order credit value remain same, this this involves code changes in the standard user exist RMCS1US3
Restriction of behavior can be done using TVARVC variant to exclude particular business process from scope of the changes.
2) Resetting of confirmation in case of check block as per Standard SAP behavior.
Creation of new requirement routine RV07A999 and TVARVC was done to exclude particular business process from scope of the changes.
Behavior after implementation:
After implementation -order credit value is calculated based on the order quality and credit exposure is updated by total order value once released.
Hence increase in stock confirmation does not lead to another credit check since order is released initially on the total order value.
Explanation of post implementation behavior considering below scenario`s without credit block and with credit block.
Case A) Credit limit is not exceeded –Behavior is based on the standard SAP. Order release value is calculated on the Sales order value which is based upon the confirmed quantity.
Hence in below example credit exposure is increased by 50$.
Case B) Credit limit is exceeded –Behavior is based on the solution implemented. Order release value is calculated on the Total Sales order value which is based upon the ordered quantity
Hence in above example credit exposure is increased by 1000$.
Key challenges involved:
1) Changes were involved in the standard SAP functional modules hence it was very important to check the system behavior in all aspects before going live in production.
2) To deliver the expected business result without any adverse impact on the system or any other process.
3) It covered vast scope of functional testing considering all the given possible business scenarios.
4) Isolating few business lines from this change as per the business requirement.
5) User training and guidelines to be provided to adapt new ways of working.
Conclusion:
1) -After implementation - order credit value is calculated based on the order quality and credit exposure is updated by total order value once released from credit block.
2) -Increase in stock confirmation does not lead to another credit check since order is released initially on the total order value.
3) -Problem of recurrence is resolved with this change hence removing the additional credit approval in the business process.
4) -It led to removal of the bottle neck and streamlining the approval process in case order goes into the credit block.
5) -Increasing efficiency of the business process which decreased the overall lead time.
Business Benefits:
- Smooth Credit management with one time approval process.
- Enhanced delivery process with reduction in the delivery lead time.
- Reliable and rigid- delivery plans with correct scheduling arrangements.
- Reduction in manpower & effort savings.
- Customer satisfaction and repeat customer sales.
- Increase in revenues and cost optimization.
Recommendations:
1) Post implementation it is required to update /correct the incorrect credit values using the report standard SAP report- RVKRED77.This report should be used when all users are locked since it locks the standard SAP tables.
2) Implementation of new Z report Z_CREDIT_VALUE_COMPARE, This report simulates the first step in the recreation of open credit values (in accordance with report RVKRED88) and afterwards compares the results with the values that are currently in the database. The result returns a list with credit customers for whom there are incorrect open credit values. The incorrect values are highlighted in the list .This helps to identify the list of customers with the incorrect open credit values.
3) Adequate training for the end key users and credit approvers to adapt new ways of working.
- SAP Managed Tags:
21 Comments
