Another bug in bank reconciliation v13

The transaction matching in the bank reconciliation is flawed. The code expects the ledger transaction amount to always be less than or equal to the bank transaction.

This is fine in scenarios for example where a customer has several sales invoices and pays them all at once.

But consider the scenario the customer has one invoice and pays it in multiple instalments, which is what the Payment Terms Template is designed to allow.

My actual scenario is multiple bank transactions reconciling against a single Journal Entry (Payroll). But there are a lot of scenarios in bank transactions that the current reconciliation code does not cater for, e.g. typos.

You could argue the above Sales Invoice scenario is covered by making a Payment Entry for the invoice. I would argue the Bank Transaction/Reconciliation code should be able to cater for all scenarios without a Payment Entry being required, since the Bank Transaction has a child Bank Transaction Payments table specifically designed for this. And Payment Entries are only applicable to Invoices (so not Journal Entries).

Reading between the lines I think the intention is to deprecate the Payment Entry doctype since there appears to be nothing that couldn’t be done with a Journal Entry anyway.

I suggest extending the transaction ranking idea in the reconciliation, and removing the SQL transaction where clause for the amount:

Culprit code get_queries

Changes also required in reconcile_vouchers and preferably code moved to

	if total_amount > transaction.unallocated_amount:
		frappe.throw(_("The sum total of amounts of all selected vouchers should be less than the unallocated amount of the bank transaction"))

I certainly hope not! :grimacing: I thought Payment Entry was a step in the right direction, and that we needed to expand on that.

With the gradual fall of the monolith, I feel that soon, we’ll have a bolt-on App just for Bank Reconciliation. I’ve met a few ERPNext businesses that would be interested in such a thing, because they’re unable to use the v13 Bank Reconciliation, as it is today.

If I do any work in this area, I will keep you posted, @casesolved-co-uk

Can you explain why? Journal Entry does everything afaics, though I haven’t looked at what specific reporting there is around Payment Entries, maybe Account Receivable/Payable? Nothing that couldn’t be changed. Naming based on the JE type might be a good change.

I’m fixing it as we type. It seems every time I touch something I need to fix it first :roll_eyes:

Mostly because many Users I’ve encountered are not comfortable (or even familiar) with double-entry accounting. They don’t care (or fully understand), when to use debits and credits, which offset accounts to choose, how Accounts Payable/Receivable works, etc.

They just want to record a payment for something:

Customer ABC sent us a check for 100.00, and we cashed it.

Payment Entry works well for this. The workflow is very linear:

  1. Choose “Receive”
  2. Choose “Check” (which can automatically set the offset account in the GL)
  3. Choose which Customer.
  4. Enter the amount.
  5. Submit.

Could they have done the same thing with a Journal Entry? For sure! It just doesn’t feel as natural to some of them.

I also like how Payment Entries make it easy to match Invoices and Payments together, and add things like taxes (something else that not every User would know how to record via a JE)

On the other hand. One of my clients has a very experienced accountant. They’re able to use Journal Entries to “skip steps”. Instead of:

  • Creating a Payment Entry
  • Creating an Invoice
  • Reallocating costs/expenses to other accounts (because Reasons)

They can do all 3 of those things above, in a single Journal Entry, the debits and credits work perfectly, and it’s beautifully simple.

So I think we need both.

(I’m actually creating a third option for my home office. I want an even-simpler DocType that creates both Invoice and Payment -simultaneously- as a pair, with as few button-clicks and options as possible. But also makes it easy to record the expense in a particular “bucket”, like airfare, hotel, office supplies, training materials, membership fees, etc.)

You and I are living the same life, I think. :smile:

I would argue your scenarios shouldn’t be justification to create a whole new doctype/db table and all the complication this adds to things like back reconciliation, but could be done with a dialog or page that submits a Journal Entry in the background.

Are you sure this hasn’t already been done? The Invoices have an is_paid checkbox that allows you to add payment details inside the invoice. Each invoice item already has an expense account, so your buckets are just CoA accounts.

I think we need to have a virtual beer sometime :joy: :sob:

That would absolutely work. I’m just looking for a simplified/different UI, to accomplish similar end results.