Skip to Content
0

FD32 does not get updated with sales order value if the credit limit reaches 100%

Oct 16, 2017 at 11:43 AM

136

avatar image

Hi all,

I have a typical issue. Please guide further.

FD32 does not get updated with sales order value right after SO creation if the credit limit reaches 100%

Performed configuration
Defined credit control area - 6100
Defined credit groups:
01 - Credit Group for Sales Order
02 - Credit Group for Delivery
03 - Credit Group for Goods Issue

Defined risk categories
001 - High Risk
002 - Medium Risk
003 - Low Risk

Assigned credit limit check for sales order type: D (credit Check) and 02 (credit group)
Assigned credit limit check for delivery type: 02 (Dlv. credit group) and 03 (GI credit group)

Configured Automatic Credit Check only for (6100/002/02)
6100 = credit control area
002 = risk category
02 = credit group

Attaching image for automatic credit check controls in the next comment.


Test data:
Customer - 100030
Credit Limit - 70,000
1st SO - 983 (value - 11800); FD32 got updated right after SO creation with 11800;
2nd SO - 984 (value -11800); FD32 got updated right after SO creation with 23600;
3rd SO - 985 (value -11800); FD32 got updated right after SO creation with 35400;
4th SO - 986 (value - 23600); FD32 got updated right after SO creation with 59.000 (till this point, credit limit reached is 84.29%);
5th SO - 987 (23600); FD32 did not get updated right after SO creation. It still shows 59000 (credit limit used 84.29%) than 82600 (credit limit used 118%)


NOTE: I increased the credit limit to 90000, the credit limit for all first 4 sales orders (with value 59000) got changed to 65.56% (only first 4 sales orders were considered) from 84.29%
I then created 6th SO with value 11800; FD32 got updated right after this SO creation with credit limit used 78,67% (credit exposure 70800)


NOTE: still system did not consider 5th sales order value in FD32 because during 5th SO creation, credit limit crossed 100%.

10 |10000 characters needed characters left characters exceeded

Adding the image of OVA8

fd32.png (48.8 kB)
0

Is there anybody who can help me on this critical issue please?

0
* Please Login or Register to Answer, Follow or Comment.

1 Answer

G Lakshmipathi
Oct 16, 2017 at 12:38 PM
0

Did you do some analysis from CHECK_CM ??

Show 12 Share
10 |10000 characters needed characters left characters exceeded

Dear Lakshmipathi,

Please find the below link to see the attached word document talking about check_cm analysis

https://wordpress.com/post/mmakweb.wordpress.com/20

0

Dear Lakhshmipathi,

Also find MCVR report for both the sales orders (987 - not working and 1011 - working) as suggested in CHECK-CM

Please click on the below link to open word file.

https://wordpress.com/post/mmakweb.wordpress.com/27

0

You may wish to add the screenshots here directly or use a different link.

The link that you posted leads to a login page for a wordpress blog, which means that others cannot see what you meant.

0

Dear Veselina/Lakshmipathi,

Please find the document attached now (CHECK_CM)

check-cm1-for-sales-order-987-pdf-page-001.jpg
check-cm2-for-sales-order-987-pdf-page-002.jpg

0

Your order 987 was blocked for credit limit, it is normal that it won't update credit exposure until you release it from credit.

You mentioned that you increased the credit limit after order 987 was blocked - did you try rechecking or releasing it via vkm3?

0
Veselina Peykova

Dear Veselina,

Client requirement:
If the credit limit is exceeded, there should be a block at delivery document creation (not at PGI).

Correct me if I am wrong:
If I manually release 987 in VKM3, then system allows to create delivery for it. But I do not want to allow to create delivery. I want to restrict delivery creation as all credit payments have not been cleared by customer.
If FD32 was updated automatically with sales order 987, crossing 100% credit limit, I would have known the credit limit got exceeded and restriction at delivery creation will work accordingly.

If you are still not clear from my points, guide me the configuration for the client requirement

0

The problem that you describe is solved not by configuration but by educating the business.

In simple words, credit exposure represents how risky it is from value perspective to fulfill a subsequent order for a customer.

Until an order is approved automatically or released manually the risk of a customer not paying you because he has not enough money, is not changed.

When you create an order that exceeds the credit limit if your system is configured with reaction 'C', the user will see a popup with a message that credit limit has been exceeded and the value by which the credit value exceeded the current limit, but he can still save the order, which will end up with overall status 'B'. In some organizations credit clerks use VKM4 to review orders and from there they can see the reason why an order was blocked, what is the credit limit for the credit account, what is the credit value of the order and make a decision. In other companies (where the number of documents is lower), they use workflows and supply the most important information - like credit limit, payment terms, credit value in the work item that is sent to the person responsible for credit control. If a blocked order had updated the credit exposure this could potentially lead to wrong decisions.

It is interesting though that you set up reaction 'D' and you were able to save the order. Normally, this would result in an error and inability to save the document. Did you make any changes in configuration or master data between tests?

One minor remark - it is not a good approach to use credit group 02 for orders, when in standard it is designated for deliveries. It can be confusing for the consultants that will support the solution after you leave the project and you will end up with naming convention problem if you decide to have different treatment for order and for delivery processing at a later time. It is better to have Z1 instead of 02 for orders and use more appropriate descriptions in OVA8.

0
Veselina Peykova

Dear Veselina,

I really appreciate you to understand my issue. I have been struggling to find people to identify it. And finally today you got it.
On your note "It is interesting though that you set up reaction 'D' and you were able to save the order. Normally, this would result in an error and inability to save the document. Did you make any changes in configuration or master data between tests?"
I did not make any changes between my testing. Kindly share input to correct this standard behavior.

Noted that I will change the credit group 02 to Z1.

0
Noted that I will change the credit group 02 to Z1.

I do not know at what stage is your project: if this is used in productive environment - this means a significant change. Please make sure to inform all departments that have anything to do with the process. When you change configuration you need to run certain reports to adjust the documents. Please read carefully the documentation related to changes to credit management configuration and master data. I have never changed credit group assignment of documents in a live environment and I made just a very brief test in a sandbox, so I cannot tell what you could potentially break by doing this.

The standard behavior that I know for reaction D is if you are in creation mode and you have issue with credit limit for example, you cannot save the order. If the order already exists, you change the credit limit and recheck the order - it will be blocked. If you have an order that was not blocked initially, but you changed the price and as a result exceeded the credit limit - it will be blocked.

If there is not enough available stock when you take the order - checks are normally done on available quantity, it is possible that your order will not be blocked, but when it becomes available and you recheck the order, it will be blocked.

TLDR: If SAP can prevent document creation for reaction D - it will do so. If the document exists already the only possible way for the system to react is to block the document.

Sometimes credit problems are difficult to track. The most important part is to start with fresh data - new customer, that has no SD documents and no open items, do not change pricing or credit master data between tests, do not change configuration until you finish testing, make sure that you have enough stock so that it is easier to investigate, make simple cases without additional confirmation blocks, a single item and the same material. If you have gone through the checklist for CM notes and everything seems correct and if you are certain that there are no custom developments potentially influencing pricing, ATP or credit behavior and if the case is easily reproducible - you may consider contacting SAP.

0

Dear Veselina/Lakshmipathi,

Please find the attached files - 2 pages of (CHECK_CM)

check-cm1-for-sales-order-987-pdf-page-001.jpg
check-cm2-for-sales-order-987-pdf-page-002.jpg

0

Dear Veselina/Lakshmipathi,

Please find the attached files - first 2 pages of (MCVR)

mcvr-1st-page-for-sales-orders-987-not-working-and.jpg
mcvr-2nd-page-for-sales-orders-987-not-working-and.jpg

0

Dear Veselina/Lakshmipathi,

Please find the attached files - last 2 pages of (MCVR). As there are total 4 pages of MCVR report.

mcvr-3rd-page-for-sales-orders-987-not-working-and.jpg
mcvr-4th-page-for-sales-orders-987-not-working-and.jpg

0