Converging financial / cash discount modules for v15.0

[grindtildeath]

Following discussions on OCA/account-financial-tools#1040 it would be great to work together on providing a single module for v15.0 to provide discounts on early payments.

At the moment we have following modules either merged or in the process of being migrated to v14.0:

• account_financial_discount (by camptocamp, available for v13.0 in PR above with migration in progress for v14.0)
• account_cash_discount (by Acsone, available at https://github.com/OCA/account-payment/tree/14.0/account_cash_discount_base)
• account_cash_discount_payment (by Acsone, available at https://github.com/OCA/account-payment/tree/14.0/account_cash_discount_payment)
• account_payment_term_discount (by OSI, available at https://github.com/OCA/account-payment/tree/14.0/account_payment_term_discount)

To avoid duplicating work, it would be great to converge all the modules together for v15.0.

I can mostly talk about account_financial_discount since it's the module we did and is used in prod for a while at one of our biggest customers. Here are what we have in this module.

• Configuration of discount per payment term
• Storage of discount information on the account.move.line linked to the payment term
• Multicurrency
• Support automatic write-offs in the "Register payment" wizard for single and multiple invoices
• Support automatic write-offs from the bank statements in the reconciliation widget.

Last two points are the "critical" ones in the sense that:

• supplier invoices are usually paid using "Register payment" to generate account.payment and be able to export a SEPA file.
• customer invoices are usually paid and reconciled directly from bank statement lines after importation of CAMT files.

This module of course has its limitations, (stated here https://github.com/OCA/account-financial-tools/pull/1040/files#diff-427ccfc78b333e526364e3533ee8a1b7635cfc7c0145ffc9f36c0f6b8b653d2dR35-R45 for v13.0) and as the reconciliation widget was moved to enterprise for v14.0 I'm not finished with migrating it (although I'll be soon able to open a PR with full support of register payments).

From what I've seen about the other modules:

• account_cash_discount_payment relies on account_payment_order
• account_cash_discount_base doesn't depend on account_payment_order, but having discount information stored on the account.move instead of account.move.line linked to payment term doesn't help to use the reconciliation widget.
• account_payment_term_discount provides similar features but the scope is smaller from what I've seen

@sbidoul @pedrobaeza @max3903 @dreispt you're welcome to join the discussion.

[luc-demeyer]

We have also made such a module in the past and have ported it up to 10.0, cf. https://github.com/luc-demeyer/noviat-apps/tree/10.0/l10n_be_cash_discount

In Belgium we have specific tax implications on cash discount, hence we'll end up with a generic module + localisation module in l10n-belgium.

[dreispt]

@grindtildeath I'm totally for converging.

IIIUC your account_financial_discount is more complete than the other options, and ideally should be the one to carry forward. We can try evaluating it and see how well it does covering our customer needs.

[dreispt]

@grindtildeath Can you link us to a account_financial_discount 14.0 migration PR please?

[grindtildeath]

@dreispt Thanks for the feedback.

I opened today the PR in this repository for account_financial_discount which is functional but doesn't cover the reconciliation part: #464

I also opened another PR for the unmigrated part to bridge with the reconciliation widget: OCA/account-reconcile#421

Edit: reconciliation model is broken to generate write off in foreign currency and I submitted an OPW to Odoo about it.

[grindtildeath]

FTR: I updated #464 with the migration of reconciliation model.

I some JS wiz wants to take over OCA/account-reconcile#421, I'd be happy to help.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.