-
-
Notifications
You must be signed in to change notification settings - Fork 694
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
[13.0]]ADD] Add account_invoicing_mode #755
Conversation
e463d8f
to
14ff383
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functional test, looks good. Thx for the job
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some remarks (typo, refunds)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some additional remarks to be compatible with the module https://github.com/OCA/stock-logistics-workflow/tree/13.0/stock_picking_group_by_partner_by_carrier
account_invoice_base_invoicing_mode/tests/test_base_invoicing_mode.py
Outdated
Show resolved
Hide resolved
I think this module is not correctly focused by several reasons:
IMO, you should extend that module for adding the monthly/dayly mechanism, but using the same base methods. |
account_invoice_mode_at_shipping/tests/test_invoice_mode_at_shipping.py
Outdated
Show resolved
Hide resolved
In previous comments there has been a suggestion by @pedrobaeza to include this into Moreover the proposed change would also make this pr much more complex and maybe its UI element less intuitive to use. And I personally think that this pr gives a good base to add different invoicing mode in the future. |
I don't remember right now my suggestion and the context, so I can't give you now an answer, but if you point me to it, I can agree or not on this. |
@pedrobaeza It is about this comment #755 (comment) on the same PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG, a rebase to keep one commit / module is welcome
OK, as you prefer then. I still encounter some common points:
What about the naming, being |
Well the base module is just a field on the partner really, so it is about invoicing first. So it could be used to invoice other things than a sale order if the business model requires that. I would really like to keep the naming like it is. |
What about partner_invoicing_mode then? If not, I won't block it. |
I actually like that name better, shorter and more explicit. |
Add three modules helping on automatically invoicing customers. The base module `account_invoice_base_invoicing_mode` does not actually do anything but adds a selection field on partner to allow assigning an invoicing mode to a customer. And a checkbox to choose regrouping invoices. The two other modules add specific invoicing mode. The module `account_invoice_mode_monthly` creates monthly invoices for customer on a specific day (configuration is in Accounting Settings) The module `account_invoice_mode_at_shipping` creates invoices on the shipping of the goods. Those modules use queue_job to generate and validate invoices.
Sales order with different payment term are not grouped into the same invoice anymore. This grouping can be easily changed by overriding the coresponding method. During this change the parameter of the job generating the invoices has changes and is now the sale_order_ids to process.
If we group several sales in the same procurement group, we'll invoice only one sale order. Tracing back to the sales through the stock moves ensure we invoice all of them.
Through the stock moves
Add few changes from reviews. Use sudo to post the invoice.
@simahawk I squashed the commit and added the roadmap as discussed |
@TDu check the build pls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jbaudoux @mmequignon good for you?
class AccountMove(models.Model): | ||
_inherit = "account.move" | ||
|
||
@job(default_channel="root.invoice_validation") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the @job decorator deprecated?
OCA/queue#274
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it is, but it still works for v13.
It will be changed on the v14 migration.
/ocabot merge patch |
What a great day to merge this nice PR. Let's do it! |
/ocabot merge patch |
This PR looks fantastic, let's merge it! |
@simahawk your merge command was aborted due to failed check(s), which you can inspect on this commit of 13.0-ocabot-merge-pr-755-by-simahawk-bump-patch. After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red. |
let's try again |
This PR looks fantastic, let's merge it! |
Congratulations, your PR was merged at 5faf8c4. Thanks a lot for contributing to OCA. ❤️ |
The related PR on the OCA is * OCA/account-invoicing#755 BSCOS-466
Add three modules helping on automatically invoicing customers.
The base module
account_invoice_base_invoicing_mode
does not actuallydo anything but adds a selection field on partner to allow assigning an
invoicing mode to a customer.
The two other modules add specific invoicing mode.
The module
account_invoice_mode_monthly
creates monthly invoices forcustomer on a specific day (configruation is in Accounting Settings)
The module
account_invoice_mode_at_shipping
creates invoices on theshipping of the goods.
Those modules use queue_job to generate and validate invoices.