PGI happens for delivery even if credit limit is not there for the first time

[Former Member]

Hi All,

I have configured my Credit Control (Automatic Credit Control) -at Delivery Save and PGI level as below

CCA  RkC      CG           Credit control                                Curr.           Update

1000      Z01      02      Delivery credit check                         INR            000012

Static Check ( Reaction Type D) - Not considering Open Orders but Considering Open Deliveries.

When I create a Customer, based on CCA settings, the Automatic Limit of 1.00 INR is fixed with Risk Category = Z01.

The Problem that I am facing is as below.

I create the Order, Delivery for a customer. As per my expectation, since the limit is 1.00 INR and the Order Value = 1900 INR, so it should give me credit error on save of delivery, but even the PGI happened without credit check.

Also I realized, the credit check kicks in for the second time, but the value being shown in error message is till the last PGI which was done (for the case above, the 2nd delivery shows credit exceeded by 1899 INR instead of total 1899+100 INR = 1999; 100 being the value of 2nd delivery).

I have already checked that Subtotal A is present in my pricing procedure.

I even tried assigning the pricing procedure to delivery document to bring pricing in it but still the system behavior is same.

Please help.

[dinesh_rai]

Hello Sachin,

Can you see if FSCM is activate in your environment. If yes then this is not going to work you need to Maintain the customer credit limit in FSCM for processing check .

Please check this table and see what is the credit limit of the customer is set in FSCM : SE16N - Table : UKMBP_CMS_SGM- CREDIT_LIMIT

Please check and confirm.

[Former Member]

Hi All,

Just to update, I also analysed that structure S067 is not getting updated for my deliveries.

And I am not sure why this is not happening.

I hope once S067 starts getting updated, the issue can be resolved.

[jignesh_mehta3]

Hello Sachin,

Be it Credit check at Sales order level or Delivery level, in your case the Credit Check itself has not triggered.

Have you checked all the customization and assignments? I mean assignment / determination of Credit Control Area for the transaction, assignment of Credit Group to Delivery Type, is the Payer in the Sales order same as the one for which you have defined Re. 1 credit limit?

Also as suggested by Debarshi, the update group in Credit Control Area should be 00015.

Along with Reaction as D, also insert Tick mark in Status/Block box.

Thanks,

Jignesh Mehta

[Former Member]

Hi Jignesh Sir,

The credit check is getting trigerred else it would not have shown for the second delivery too.

Also the Tick mark is there in the status/block box already.

Still looking for guidance

[jignesh_mehta3]

Hello Sachin,

If the system it blocking the second Delivery for Credit Check, it should have blocked the first Delivery too. Is it possible that it was released by VKM4 / VKM5?

Further regarding you question about Credit exceeded amount being 1899 and not 1999, i,.e. 1899 (1st Delivery) + 100 (second delivery), can you check the Open Delivery Value in Table - S067?

Thanks

Jignesh Mehta

[Former Member]

Hi,

As you have ticked "Open Deliveries" in configuration, when you were trying to create your first delivery of 1900 INR, it did not find any open deliveries in the system and hence allowed it to proceed. When you tried to create your second delivery of 100 INR, it found an open delivery of 1900 INR in the system, which exceeds the credit limit of 1 INR by 1899 INR. And thus the message appeared in the second transaction.

My suggestion (as per your requirement) is that do not tick "Open Deliveries". Also, use Update 000015 instead of 000012.

Regards,

Debarshi  

[Former Member]

Hi Deb,

Thanks for your reply.

I tried 000015 and Removing Tick from Open Deliveries. Still Allowing PGI (save as well as PGI) for the delivery.

Also I executed the T-code : CHECK_CM for this delivery, it shows the status as A for the Static Check.