Possibility to use `origin` in move templates

Would it be possible add a keyword for an invoice origin where [at least] the party, invoice number, reference and total could then be used by some reference in the template (like invoice => origin, number = invoice.number, et cetera)?

What is the exact problem/usecase you would like to solve?

Well, an extremely common case is ‘assignment of receivables’ to a bank.
It’s sorta like a temporary (poor man’s) form of subrogation.

The idea is to be able to select the invoice in the origins, and create the move with a given date.
The move involves fixed accounts, but it needs the party, the amount, and description/number/etc.

When the invoice is paid the move is simply cancelled as the bank statement will reconcile with the original invoice.

Currently it is rather tedious as all these bits must be collected and entered manually.

Another use case is when a subcontractor (supplier) is paid directly by the client (mandatory in public works projects), as part of payment of the client invoice.
It would be therefore be nice to be able to select the suppliers invoice on the paid date then create a move to be able to reconcile it with the related client invoice with the payment received.

IMHO account move templates are too generic for this use case.
The problem is the missing keyword type for reference fields and the possibility to re-use variables (“description/number/etc”) of a given reference field which sounds hard to implement. Also there is some mechanism (“[move] cancelled as the bank statement will reconcile”) on reconciliation for which is the move template the wrong place, IMHO.

But I wonder if it wouldn’t be better to search for a solution

  • based on the invoice payment wizard and invoice payment/write-off methods, or
  • based on the payment module series

The benefit would be that it is close to the invoice, payment processing, reconciliation and all data is available.

It would be interesting to see the exact account moves for the complete processing for later automated testing.
The steps over time would be interesting: Invoice move, assignment of receivables move, customer payment, assignment of receivables cancellation move. And the change of reconciliation over time.

The exact account moves for the second example are also interesting.
Additionally we should collect which other examples are similar.
Hopefully there is a general pattern to serve them all.

I’m glad to have discussion, which is healthy process.

As to the first observation, I’m also mixed, but I like the straight-forward means to do the moves based upon a template (quite intuitive, that is, for accounting department).
I hope to have a bit of time in the upcoming weeks, I’ll tinker with some ideas and report back.

In my opinion, it is more ‘finance’ than ‘receivables’ payment management, though naturally related.
For example, in true subrogation (via a Factor), it is normally a one-shot operation as the third-party takes over the receivables management, for the most part.

As to the second, I’ll come back with an example from Lefebvre Mémento Comptable, one of the leading bibles in French accounting references.

I will mention that properly speaking, reconciliation doesn’t really change over time, but there moves created, when considered with compensation, are effectively such until the move is later cancelled.

I’ll do the same for direct payments of subcontractors/suppliers…

Hopefully this week-end for the examples.

Cheers,

Ok, finally got around to this again.

In the following capture, the account examples are French PCG.

I present below 3 examples as more or less thus presented in Lefebvre, where the examples use a guarantee of 20% leaving 80% drawable for advancement or discounting of funds.

We have [had] both examples 1 and 2, but never encountered example 3 which is more akin to subrogation.

The steps presented are distinct moves where the first move with a ‘*’ (mobilisation of receivables) is what we’d like to streamline in this move template discussion. Naturally cancelling the move is intuitive.
Client payment in example 1 is easily handled via a invoice payment method.

Since subrogation and factoring are in a separate topic, I’ll continue there for those move examples and invoicing ‘payment to’ particularities.

1 Like