[15.0][ADD] account_reconcile_sale_order

[hbrunn]

This module allows a workflow where you don't invoice sale orders until
you've received a payment.

That's useful ie for webshops with non-instant payment like wire
transfer, where you might have a lot of customers not doing the payment
after all, which results in extra work for cancellation of the
invoices/orders involved.

Configuration

To configure this module, you need to:

1. Go to Invoicing/Configuration/Reconciliation Models
2. Create a model of type Rule to match sale orders

Usage

To use this module, you need to:

1. Have a payment on a bank statement matching the amount of an
   invoicable sale order
2. Enter the reconciliation screen
3. Observe that the sale order is offered as reconciliation counterpart

Note the reconciliation only works if fully invoicing the sale order
yields an invoice over the order's total amount. Usually this means that
all products in the sale order must have invoicing policy Ordered
quantities.

[gjotten]

Functional review, LGTM

[hbrunn]

@gjotten note the customer asked for a few changes, so I demoted this to a draft meanwhile

[gjotten]

@gjotten note the customer asked for a few changes, so I demoted this to a draft meanwhile

@hbrunn we're already looking into porting this to 16.0

What's the roadmap for changes here?

[jans23]

Answering on behalf: The mentioned changes should be done soon, in best case this Friday. Afterwards we are going to use it in production and see how well it works or if any other issue emerges.

[hbrunn]

yet to do:

• only return one match when using the reconciliation model
• we encountered it proposing already invoiced/paid SOs
• match substrings of transaction text/search box with SO's name, SO's partner's name

That's all small things in the backend, and I expect most work for the migration to be moving the JS part to owl, so it seems fine to me to already start with that.

[hbrunn]

@gjotten now I consider this done with some refactoring for easier extension, customer comments pending though. Pushed this as a fixup commit to make it simple for you to add to your migration. Please ping me when I can squash this

[gjotten]

@hbrunn go right ahead with squashing this.

[hbrunn]

@gjotten for your migration the latest commit will fix weird unbalanced errors when your customer uses inclusive taxes

[gjotten]

@hbrunn unfortunately our part here is moot since with EE users, we couldn't go forward with introducing OCA reconciliation.

[github-actions]

There hasn't been any activity on this pull request in the past 4 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 PR 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 pull request in the past 4 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 PR to never become stale, please ask a PSC member to apply the "no stale" label.

[jans23]

It's working for us well in production for over a year. Would be great to have this merged.

[github-actions]

There hasn't been any activity on this pull request in the past 4 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 PR to never become stale, please ask a PSC member to apply the "no stale" label.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖