Cash Receipts Entry Error

We are trying to process a Cash Receipt for a customer and are getting this error:

This appears once we type in or choose a customer ID and it only pops up for 2 customers that we’ve found (1 is a national account and the other is an individual account belonging to the latter). We don’t have any BPMs turned on for Cash Receipts so not really sure what could be causing something like this. Created an EpicCare ticket, but have not found any resolution yet. If anyone has suggestions, that would be great! Thanks!

Field Customer.ValidPayer…helptext says you can’t process cash receipts without it.

image

We’ve got that box checked for both of the issue customers. I forgot to mention that before this issue came up, we had processed cash receipts using that national account just a few hours before with no issue.

Uh-oh. :frowning:

I’m at a loss…especially if you posted to one of the two accounts earlier.

Error detail looks a little generic (comm failure retry)…and last record in the stack trace shows InvokeInvoiceSearch. Is it choking on too many records or something in the search?

Maybe check the Terms on the customer account. Seems to be looking for something missing there.
Did someone update Terms maintenance related to the customer?
image

1 Like

Sorry, got pulled away into some other things. Doesn’t look like any terms have changed. Our issue has been submitted to the development team so I will let you all know what they come back with (hopefully soon).

So the development team claims that there was an issue caused by the InvcSched.PayDueDate field not having a time value equal to 00:00:00. They provided a data fix for us that resolved the issue.

However, we have plenty of invoices where the time value of its PayDueDate field is not 00:00:00 so not really sure that’s the whole issue. But the data fix did allow us to process this cash receipt and free up that national account as well. Going to try and put something in to ensure this doesn’t happen again, but if any of you need a solution for this issue, looks like the PayDueDate could be the place to look!