Currently ERPNext reconciles advance payments to invoices by modifying the source document’s (Payment Entry or Journal Entry) GL Entries and changing their against_voucher and in some cases even splitting the GL Entries into multiple rows.
With this current method, the information about that fact that a payment was made as an advance against a Sales Order or Purchase Order or an Unallocated Advance Payment is lost. I would assume that accountants and people who advocate for immutable ledgers would not approve this method.
So while working on improving Employee Advance I got the idea that there could be a Voucher Type (Document) that acts as the document that gets allocated with the advance payments. And instead of reposting/modifying the original GL Entries we can post GL Entries like this:
I like the fact that you think of all kinds of advance-payments alike. And I agree that the logic and workflow for all kinds should be the same. So I’d vouch for developing this not as an island solution for employee advances, but for all possible advances in general.
Can’t really judge whether the way you want to achieve that works due to lack of in-depth technical understanding, but it sounds reasonable.
Advance payments today is a big problem at erpnext.
There are related issues at github but they are not being given priority, so I don’t understand how companies that need this handle it.
Advance payments, if made from Payment Entry, create a negative balance in an account that you don’t owe.
If it is made from an accounting entry, to a Advanced Payment account as it should be in accounting, it cannot be used to connect with the payment reconciliation tool.
To this must be added the fact that credit notes on an invoice that is paid cannot be used as an advance payment.
A retailer that uses all these movements on a daily basis will be unable to carry something as simple as advance payments.
I do not know if the solution you propose is the best, but it is a serious issue that I do not know how to do to give more relevance in github.
Of course it should work with all cases. The user should be able to make payment against either SI, SO, or keep it unallocated. My point is that IF the user makes payment against Sales Order, then reconciling the Payment Entry to a Sales Invoice will not modify the Payment Entry’s GL Entries. Rather it should either modify the Sales Invoice’s GL Entries’ against_voucher only as in the example or create GL Entries from Sales Order to adjust the Sales Invoice.
Essentially the idea is that there should be no reposting, but there are some caveats to that. I’ll post about it soon.
I get this point. What i’m saying is creating SO in the Sales pipeline is not a mandatory.
So, what happens to cases where there is no SO, but only SI and Advance payment entry to be allocated to it --which is happening currently, so how is the proposed changes going to work in this use case
Only this should happen as the expected behavior and do not connect it to SO.
Currently you can create Payment Entry/Journal Entry to that Customer and do not allocate the to any document.
There could be another document that gets allocated with the advance payment… Lets call that DocType Advance Payment. Either the invoice can make the GL Entries to reconcile with the advance payment or the Advance Payment DocType can make the GL Entries to reconcile with the Invoice.
Lets discuss this in the Account Working Group call.
Currently, I am suffering from Advance payment issues. I have had clients who rejected implementing ERPNext because of this issue. Everyone is asking for the advance payments to be reflected in the “Advance payments” instead of Creditors/Debitors.
Agreed. Advance payments should be treated a a special general case. It is a liability account and nothing else. A separate ledger or advance journal or similar should be available for dealing correctly with advance payments. Advances can be paid back, transferred, allocated to more then one project or client and there is no correct accounting method at present to handle advance except by the introduction of manual journal entries which is error prone and time consuming.
