on 03-11-2014 12:05 AM
Need validation if the process recommended in following scenario is appropriate & any advise would be appreciated:
We have a few contract accounts where the incoming payment was posted to worng contract account. Then instead of reversing the doc & moving it to clarification & posting to correct account , the cashier assuming the customer has made payment in error , initiated a refund & an outgoing payment doc was generated after payment run. In some cases the check was issued to the customer.
What we think the right process would be as under:
1. Reset clearing on outgoing payment doc. The incoming payment doc will now be open. There will be additional debit entry of equivalent amount for the reset clearing.
2. Reverse the incoming payment doc & post it to clarification. From Clarification , post it to correct contract account.
3. For the debit entry on the contract account, there are 2 possible scenarios for clearing:
sceanrio 1: In case the check was sent to customer , get the customer to make the payment. This incoming payment will clear the debit entry.
Scenario 2: If the check was stopped in time , a credit posting of equivalent amount should be posted to bring account back in balance. For standard incoming payments we use doc type IC. In this case as this is credit entered to balance account (not truly an incoming payment) can the same doc type be used or a different doc type is recommended.
I am not a FICA consultant & this might be a very basic question
Thanks in advance for any recommendations.
Satish
Hi Satish
step 1, 2 is fine.
for step 3, GL posting have to be observed.
It can exist as a reversal or a separate adjustment posting thru some means e.g. payment lot
Tom
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you elaborate on Step 3.
If I understand correctly if the check was received by the customer , than when the customer pays back the money (incorrectly issued) , it can be posted as incoming payment.
But if the check was not issued , than how do you address the outstanding debit on contract account due to reset clearing. I tried reversing the document but system does not allow it.
Appreciate if you can provide insight on GL postings.
Hi Satish,
For reset clearing, option 'retain distribution to accounts' should be used. If you create a new open item. you cannot reverse it.
For GL posting, it depended on your finance posting requirement in related to bank reconciliation. A reversal may be OK. In case you need a CR posting to offset, you need to set it up by any means.
Regards,
Tom
Hi Tom
Appreciate if you can look at the attached document. I have attached screenshots so that you can guide me if i am missing something.
I selected the option 'retain distribution to account' in reset clearing. But it generated a new reset clearing document 17000153211 which i am unable to reverse.
My thinking was that the original incoming payment doc & the outgoing doc would be open.
We have implemented an enhancement preventing reversals of outgoing payment doc. This is as per governance rules set in the organization.
In such a scenario what is the best way to tackle this issue.
Hi Tom
Could this be the answer to my problem
http://help.sap.com/saphelp_erp60_sp/helpdata/en/84/4d9837af31f822e10000009b38f8cf/content.htm
Define a reason for adjustment of receivable & process the adjustment to a separate revenue account for doubtful receivables.
Appreciate your input.
Receivable adjustment works like this:
Current situation:
Customer Revenue Receivable
----------------- --------------- ------------------
100 | | 100 100|
After receivable adjustment, it looks like this:
Customer Revenue Receivable Bad Debt Expense
----------------- --------------- ------------------ ----------------------------
100 | | 100 100| |
100 100
Receivable adjustment does not adjust the customer balance/open items. It only takes $ from the receivables and moves them to a separate g/l account.
User | Count |
---|---|
13 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.