Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[15.0][ADD] account_reconcile_sale_order #666

Open
wants to merge 1 commit into
base: 15.0
Choose a base branch
from

Conversation

hbrunn
Copy link
Member

@hbrunn hbrunn commented Jun 7, 2024

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
.

Copy link

@gjotten gjotten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functional review, LGTM

@hbrunn hbrunn marked this pull request as draft June 18, 2024 14:34
@hbrunn
Copy link
Member Author

hbrunn commented Jun 18, 2024

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

@gjotten
Copy link

gjotten commented Jun 19, 2024

@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
Copy link

jans23 commented Jun 19, 2024

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
Copy link
Member Author

hbrunn commented Jun 19, 2024

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
Copy link
Member Author

hbrunn commented Jun 21, 2024

@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

@hbrunn hbrunn marked this pull request as ready for review June 21, 2024 08:51
@gjotten
Copy link

gjotten commented Jul 1, 2024

@hbrunn go right ahead with squashing this.

@hbrunn
Copy link
Member Author

hbrunn commented Jul 19, 2024

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

@gjotten
Copy link

gjotten commented Jul 22, 2024

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

@hbrunn hbrunn force-pushed the 15.0-account_reconcile_sale_order branch from dadfa14 to 0a6e743 Compare July 22, 2024 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants