-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[IMP] sale_invoice_policy: Several improvements #3376
base: 16.0
Are you sure you want to change the base?
Conversation
5d59108
to
fb39a75
Compare
Don't use the 'required' parameter to compute the quantities to invoice or not. In fact, this should only depends on the invoice policy itself.
As ORM appends new depends() parameters to existing ones, simplify the writing
fb39a75
to
7b26e33
Compare
…he amount As for the 'qty_to_invoice' field, the 'untaxed_amount_to_invoice' field should not depends on the required option to compute its value
As we don't want to rewrite Odoo core method inside this module, we should not rewrite the method to compute the untaxed amount to invoice. Instead, save the product invoice policy, change it to sale order one without recomputing context, call the super() method and then, restore its former value.
…olicy With default behavior in Odoo, the invoicing policy depends on products configuration. So, include this as possible value for sale order invoicing policy. Possible values are so: - Products Invoice Policy: each product applies its invoicing policy (by sale line) - Ordered quantities: the whole sale order will apply the invoicing policy on ordered quantities - Delivered Quantities: the whole sale order will apply the invoicing policy on delivered quantities That said, the 'required' configuration is no more useful as the invoicing policy is now required on sale order level.
Don't hesitate to test it on runboat |
655eb48
to
f4ea1a1
Compare
…ecompute() To avoid marking 'invoice_policy' product field as dirty for products temporary value, use the working context manager 'protecting()' instead of deprecated 'norecompute() one. Put the whole process in its own contextmanager.
f4ea1a1
to
dd6f488
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.
Code review OK. As per your question I see no problem in allowing product configuration for sale orders' invoice policy. It adds more flexibility to the module
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.
Functionary review
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.
LGTM (code + functional review)
Thanks for the work
Hello @rousseldenis Thank you!!! |
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.
Can you add in the readme that the SO invoice policy affects only stock products. Service products continue to be invoiced based on the product invoice policy.
help="Ordered Quantity: Invoice based on the quantity the customer " | ||
"ordered.\n" | ||
"Delivered Quantity: Invoiced based on the quantity the vendor " | ||
"delivered (time or deliveries).", |
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.
Add that is applies only for stock products
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.
And generate requirement.txt
as it is not part of it in this repo
2025-01-25 16:00:20,521 417 INFO odoo odoo.modules.loading: Loading module sale_invoice_policy (66/67)
2025-01-25 16:00:20,522 417 CRITICAL odoo odoo.modules.module: Couldn't load module sale_invoice_policy
2025-01-25 16:00:20,522 417 CRITICAL odoo odoo.modules.module: No module named 'openupgradelib'
"data": [ | ||
"views/res_config_settings_view.xml", | ||
"views/sale_view.xml", | ||
], | ||
"pre_init_hook": "pre_init_hook", |
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.
"pre_init_hook": "pre_init_hook", | |
"pre_init_hook": "pre_init_hook", | |
"external_dependencies": {"python": ["openupgradelib"]}, |
depends()
Refactor:
I think the default policy that was applied on sale orders from the default product configuration (defined in sale module) was the wrong approach as it is not contextually correct (products are not sale orders).
That said, I introduced an invoice policy on sale order level more explicitly than before (void) which is 'Products Invoicing Policy'. That let the user free to choose between standard behavior or sale order level configuration.
The question is: