Hi,
On Apps 10 UPD16 the system defined event CUSTOMER_PMT_RECEIVED is firing for customers when we have an unallocated payment on their account. When they have this payment, but prior to it being allocated, the sum of payment + outstanding orders > credit limit - so the corresponding action will fire.
When the payment is allocated shortly after they are below the limit, but it has still fired.
Has anyone else experienced this issue / found a way around it.
Do you mean they are being credit blocked while still under their credit limit?
No blocking occurs - when the Check Cashing Proposal is created it puts it as a Debit on the account. Which is Credited when it acknowledged. This additional Debit can cause the event action to fire - as Calculate Credit Info is not running they do not go on block - but if it was ran between Creating and Acknowledgement it would not surprise me if they do go on block
eg. Credit Limit = £5,000
Balance £2,600 Debit
Customer Pays £2,600 via Bank Transfer which is logged by Finance
CUCHECK £2,600 Debit - Generated at Creating of Check Cashing Proposal and the event fires
CUCHKPO £2,600 Credit - Generated at Acknowledgment of Check Cashing Proposal.
We are using the event to alert finance to a payment from a customer that is over their Credit Limit - so at the moment they are getting a lot of garbage notifications!
Thanks,
Matt
Can you try using credit control messages within the credit management basic data?
Hi,
Thanks for suggestion - but I don’t think that will work. In Apps 10 it says ‘Customer: Payment Received for Credit Blocked/Credit Exceeded’ - interesting to note the difference with your screen shot.
Am I correct in thinking yours is from IFS Cloud?
If so - perhaps this is a case of IFS having discovered something doesn’t work and rather than fix bug they’ve just taken it away! Or I could just be too much of a cynic.
You are correct - we are working in IFS Cloud.
As for APPS10, we have been successfully using the credit messages. It is always possible a bug has surfaced.
Can you attempt to rewrite the event around a different trigger?
Just to update - IFS identified this as a bug and fixed it, to an extent.
It now fires correctly - but sends two messages when it does fires. Two steps forward, One step back.
It has left the questioning due-diligence on coding.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.