Hi,
My Client want to be able to tag overpayments to a specific invoice rather than just close the Invoice and keep the payment entry open.
Out functional consultant has suggested following:
"When the user applies payment to an invoice, allow them to enter an amount in ‘amount to apply’ even if it is larger than the Remaining Amount in Invoice i.e. bypass the standard error "Amount to Apply must not be larger than Remaining Amount". When they do this, pop up a warning “You are applying an overpayment of {$amount} to {document type document number}, please confirm”. If they confirm, then let the full amount including the overpayment be applied to that invoice. In the resulting customer ledger entry, make the payment entry close and the invoice should show a -ve remaining amount equal to the overpayment, and open=yes."
I am bit hesitating doing this change as this may impact the base core NAV functionality and I am not sure if standard NAV has taken care of -ve Remaining Amount.
Your suggestions/opinions are most welcome. Thanks.
0
Comments
you are right, this would affect core NAV functionality at very sensible locations in CU12, depending on how it's implemented. I wouldn't recommend to do this.
If there has to be a solution, I would propose this way:
- Amount to apply would accept higher amounts, but the application would only apply the remaining amount.
- The remaining amount to apply would be posted as a separate detailed entry on the invoice and on the payment. This would have to be done in ApplyVendLedgEntry() after the normal application has taken place.
- Depending on what you want to see, you could use a separate entry type for this ("tagging of overpayment") or just application. InsertDtldCVLedgEntry() accumulates those of the same type, though.
This would take care of it. There are some other things to be considered:
- The remaining amount would have the wrong sign for the document type. Tampering in this place can damage payment discount and payment tolerance functionality.
- The unrealized/realized gains/losses logic would have to be honoured for the additional "tagging" too, but with the properties of the payment entry (posting date, currency?). Mixed-currency applications should be disabled in this case. The amount remains open on the closed invoice, and any Adjust Exchange Rate would have to deal with it.
- Unapply must be aware of this, too. Must at least be checked if it's safe for this type of application.
That's a large change to do. I would budget weeks for implemeting/testing this. Not sure if it's worth the trouble.
with best regards
Jens
In your suggestion also, won't the Remaining Amount would be -ve in Cust. Ledger Entry. Suppose I add new Entry Type "Over Payment" in Detail CLE and create 2 detail entry for excess "Amount to Apply" - one for Invoice with -ve amount (like application entry) and one for Payment with +ve amount. Doing this will make the Remaining Amount = -ve (Open) in Invoice CLE and Remaining Amount = Zero (Close) in Payment CLE.
Isn't it the same thing I posted in my original post:
"In the resulting customer ledger entry, make the payment entry close and the invoice should show a -ve remaining amount equal to the overpayment, and open=yes."
I am bit confused here. Correct me I did not understand it correctly. Thanks.
As to the recommendations from your consultant :-#
I don't think so. The payment is applied "normally" (with two detailed entries, depending on the entry type you use) and closed. The invoice is fully applied (as in closed), but has a remaining amount showing the overpayment and is marked open. There is no new resulting customer ledger entry.
with best regards
Jens
With resulting CLE, I mean the Payment CLE which is created when you post Cash Receipt Journal.
So, The Invoice is already posted and we are posting over payment that applies to that Invoice from Cash Receipt Journal. System creates a new CLE for Payment and ideally 3 Detail CLE (Initial Entry for Payment and 2 Application entries one for Payment and one for applied Invoice). whcih keeps the Payment CLE Open as this is overpayment and Close the Invoice CLE.
Now, for our case, we are creating 2 Detail CLE with Entry Type = Over Payment. One for Payment (to close the Payment CLE) and other for applied Invoice (to show Invoice CLE as overpayment Entry with -ve remaining amount).
Correct me if get your point correctly.
Is there any way that we can implement overpayment to a Invoice in standard NAV with no customization or very less customization. If anyone has done this before. Please suggest. Thanks.
yes, looks like we mean the same. I have attached two screen shots of the resulting detailed entries (Correction of Remaining Amount is the overpayment). The link to the payment would be in "closed by entry no." (CLE) and in "applied entry" (DCLE).
I'm afraid there is no easier way to do this. Tagging the overpayment violates the standard NAV applying logic, IMO. You could use an extra table for the tagged amount and show it with an extra flow field, but that would leave your invoice without a remaing amount which could be applied again.
with best regards
Jens
If we create a new CLE with same Invoice no., how the user will identify if this is a Overpaid Invoice. And BTW, do you mean new CLE with -ve Amount. And how the Payment entry will get applied to the original Invoice and new Invoice. Do you mean I should write a code to create Application Detail CLE that points to the New Invoice CLE alongwith other Detail CLEs for Payment transactions.
I think David's suggestion with creating a new CLE for the overpayment is better. It avoids a lot of issues. The assignment to the original invoice would be through the document no. As this is a new entry, you can use the description to point to the invoice.
with best regards
Jens
I did remove the 2 lines of code in the customer ledger (RTC 2009) that allows the Applied amount to be greater than Remaining and posted the over payment to the invoice. The payment was Closed out and the invoice remained open with a negative. I then simulated the next batch of payments and consumed the negative on the overpaid invoice and applied the rest of the payment to over invoices. Everything posted and looked OK, however I AGREE this is not a solution. I have put all code back to standard logic.
I was looking to see if anyone has actually code in any of the posting codeunits to solve this issue.
But with training and using the notes/comments/payment descriptions they were able to handle it the new way with little to no AR mods.
http://www.BiloBeauty.com
http://www.autismspeaks.org