Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
In the previous commit the analytic entries generation when posting a
move was optimized to be done in batch. The performance is break
when sale module is installed. Indeed, in case of reinvoicing a
analytic line, AAL creation will trigger a sale.line creation.
This mecanism is very inefficient because
1/ AAL creation and Sales line creation are not batched
2/ sale line creation is done after the AAL creation, and then linked
with a `write` operation. So one `create` and one `write` per AAL to
reinvoice.
3/ To determine on which Sales Order to reinvoice, many `search` can
be performed per AAL.
Also, this looks strange that AAL creation might result into a sales line
creation.
This commit changes this in order to optimize and clean the code:
- the account.move.line (that creates the AAL) will also create the
Sales lines
- SO lines creation will be done in batch
- minimize the number of `search` done during the process
- the SO line will be linked to the AAL by passing the SO line id in the
create values of AAL (no `write` operation one AAL and SOL are created).
This was the last part of legacy code of 'sale_analytic.py' that we need
to get rid of. There are still work to do, but I think now, the
business case handled here can now breathe and have a peacefull life.
Task-1911898
closesodoo/odoo#28939
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
The sale.order model has an expense_policy selection field, with values in 'no',
'cost', 'sales_price'.
However that value can also be set to False.
The code that handles that field expected the value to always be set to a value.
We explicitly treat False as if it was 'no' (the default value for that field).
opw 1915508
closesodoo/odoo#30336
This commit has several parts:
- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)
================================================================================
*** Make consistent the filtering and ordering of product variants ***
Filter & Check possibility
==========================
The first variant shown on the website should always be possible.
When activating the customize "list view of variants", we don't want to show
impossible combination on the list.
We also don't want the user to be able to add to cart an impossible variant.
Show appropriate messages when no combination is possible.
Order
=====
We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.
This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value
The general order is now: (parent,) sequence, id.
Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.
On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.
Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.
================================================================================
*** Fix product template and variant price computation ***
Move and improve the get_combination_info method:
- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset
================================================================================
*** Fix currency conversions ***
The list_price and lst_price of a product are always encoded using the currency
of the product.
The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.
The prices on an order (line) are encoded with the currency of its pricelist.
================================================================================
*** Fix dynamic variants access rights ***
Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".
This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.
================================================================================
*** Miscellaneous bugs, tracebacks and necessary improvements ***
In general:
- correctly show warning when no variant is possible
- don't let user add to cart an impossible variant (from optional product
modal or from any RPC), both in interface and controller logic
- fix as much flickering as possible by correctly pre-computing in python/views
- move business logic from controllers to models
- correctly add no_variant and is_custom values on the SO line description
Sale order:
- fix traceback when emptying the product_id field from configurator
website_sale:
- correctly compute first image / carousel, and correctly swap images when
changing variants, without duplicate image or zoom problems
- don't use list view of variants when it doesn't make sense
- added missing product info when adding a no_variant attribute to cart
- fix cart accessory product computation
website_sale_wishlist:
- fix it with dynamic variants, no_variant and is_custom
website_sale_comparison:
- fix it with dynamic variants (comparison and alternative products)
website_sale_stock:
- fix it in general (some flickering still present)
================================================================================
Authored by @seb-odoo with contribution from @awa-odoo
task-1910821
closesodoo/odoo#28079
On a sale order, when adding a line with an expensable product with a
reinvoice policy, on the linked invoiced validation, the analytic entries
are created. During this creation, the line will be reinvoiced, so a second
SO line will appears with the same product.
This should not happen, as the SO line creation from an AAL should be done
only when the amount is negative (meaning it comes from an expense or a
vendor bill).
This was introduced in 3bf8a62e0d.
When validating a vendor bill, we want the product
with expense policy set to be reinvoice on the open
sales order matching the analytic account of the invoice
line. Applying the same mecanism for customer invoice
does not make sense, as we might confirm a SO and validate
its invoice, we don't want a new SO line to appear (avoid
loop).
Unfortunately, since a long time, this is possible in Odoo,
and really make no sense. We should only take negative
analytic lines (coming from vendor bills and expense, not
the customer invoice) into account for adding SO line.
This commit correct this problem to avoid having
many null SO line created on customer invoice validation.
All test cases are correctly written, but there was no
check to prevent this mecanism to be apply on customer
invoice.
A product can be sell or expense, but for some cases the product
configuration make both flow incompatible. Indeed, when expensing
the delivered qty was computed based on the AAL total amount, and
manually editable.
Before the delivered qty refactoring, reexpensing erased the manual
value.
This came from the fact product expense policy is wrongly used: the
delivered qty of expensable product is not manually editable, which
is a problem for milestones (and other consumable product when stock is
no installed).
The new refactoring of deli qty API force the expense line to be
completely
readonly, but the problem is not completely solved; we still can't sell
properly a expensable product.
To do so, the SO line must be flag as coming from an expense or vendor
bill, and the reinvoice product policy should only be used to calculate
the price of new SO line.
This commit:
1) reinforces the readonly caracter of expense SO line, by making the
expense policy independent of the computation method for delivered qty
on SOL.
2) prevents generate picking when updating ordered quantity on a expense
SOL with a stockable product.
3) allows service to sell a task with zero hours as ordered quantity.
(it still prevents task/project creation for expense SOL).
4) does not increment anymore an existing line when expensing product
at sales price and invoicing at 'delivered qty'. The only line to be
incremented will be the expense line (and not the native SOL).
Impacted modules: sale, sale_timesheet, sale_expense, sale_stock
and sale_mrp
This commit uniformizes the API of computing the delivered quantity on a
SO line for expense, manual, service and stock lines.
The delivered qty of so line can be computed differently. This is the
role of the 'qty_delivered_method' field:
- manual: the quantity is set manually, when creating or editing the
line
- analytic: handle in sale module, the quantity is the sum of the
unit_amount of analytic lines coming from expense or vendor bills
- timesheet: handle by sale_timesheet module, the quantity of a product
service with timesheet is compute as the sum of the hours of timesheet
lines linked to the SO line.
- stock_move: handle by sale_stock module, the delivered quantity comes
from the validated pickings of the SO line, for stockable or consummable
products.
When the computing method is 'manual' the value is stored in
'qty_deliverec_manual' field. This field is 'technical' and should not
really be used, as the real field to read/write is 'qty_delivered'.
To extend the mecanism of computing delivered quantity on SO line, a
module should provide its own method for 'qty_delivered_method' and extend
'_compute_qty_delivered' method to compute the effective quantity.
When reinvoicing, an SO line should only be
incremented if the product policy is sales prices,
and in delivered qty. Otherwise, a new SO line is
created.
When installing account module, some field semantic on AAL
changed. Indeed this module modify some concept for its own
use cases.
Since analytic accounting is only used inside the company,
there is no interess to have the amounts stored in both
currencies. So the fields amount_currency, analytic_amount_currency
and company_currency_id can be removed. Doing that, we remove the
unfair related of account module.
When removing a timesheet line (on delivered quantity SO line), the delivered
quantity should decrease. This is the case when the is at least one timesheet
left, but not when we remove the last timesheet.
Forcing resetting value to zero make vendor bills flow, so adding
'sale_analytic_norecompute' key was required to force delivered
quantity.
This commit fix this bug, and provides some tests.
The main change is we use SO and not analytic account
anymore to reinvoice expense.
When encoding an expense, each employee can directly
set the SO to allow re-invoicing the expense to a
client. Before this commit, this was done by determining
the SO based on the Analytic Account (magically) on the
expense.
This solution is less confusing and more explicit for
the end user.
This commit also bring usability improvements to
improve user experience during this flow:
- better expense product view
- access group on menu items
- ...
Since this field is an analytic account and not a project, its
name should be more explicit. This commit makes the code more
understandable. Naming things correctly improve developper's
sleep.
The handling of analytic lines to sell is a little
mess. We can reinvoice analytic lines from timesheet
or expenses, or manual lines.
This commit tries to clean the code, factorize it,
make proper hook (see _sale_postprocess method)
and move specific in its corresponding modules.
Code was properly split, in order to make modules responsible
for only their own features:
- sale module handle the link of SO line to an analytic
line, and increment the delivered qty accordingly.
sale also provide the mecanism of determine magically
the SO lines of an analytic line with an expensable product
to reinvoice it at cost.
- sale_timesheet identifies the so line concerned when
timesheeting on a project directly. Also provide the domain
of analytic line when setting the SO line on AAL.
Cleaning is necessary for futher dev.
gawa-odoo