Steps to reproduce:
- Create a manufactured product P with AVCO valuation
- On the bom of the previous product add a component C with unit cost 5$
- Manufacture product P (Unit cost correct so far 5$)
- Change component cost to 0 and manufacture again
- Unit cost of P is still 5$ were it should be 2.5$
Bug:
since the move unit price is 0 the standard price of the product P is
used insted for the valuation of the newly created qty
Fix:
force unit price to 0 in the case of manufacturing
opw-3374462
closesodoo/odoo#132047
X-original-commit: f6c2b5368e3abdc292e66dc04efc4031eb12f742
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: "C1", cost: $100
- Create a Manufacturing Order to produce 1 unit of "P1":
- Set any analytic account
- Confirm and validate the MO
- An analytic account line is created for $100 of C1.
- Change the quantity of the component to 0.
- Try to save
Problem:
A traceback is triggered, because the `amount` and `unit_amount`
variables are used without assignment.
Solution:
Assign “0” value to both variable in the beginning of the function,
therefore the analytic account line will be deleted.
opw-3257240
closesodoo/odoo#128495
X-original-commit: 513e3dea2c838bb6f805c567069ea39406c6634e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
* Create an analytic account
* Create MO with Analytic Account
* Create WO on MO
* Create Time Tracking on WO
* Delete the WO
Bug:
The analytic line related to the work duration remains on the Account
Fix:
Remove the lines when the WorkOrder is deleted
opw-3174736
closesodoo/odoo#124014
X-original-commit: 59ebf21d126d9d5c93e97e6b404b23270050aa6f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Upon changing/removing/adding the analytic account on a manufacturing order, only the analytic lines due to the raw material moves are updated, but not the ones for workcenter costs.
To reproduce:
- Create an MO with a workorder on a workcenter which has an operating cost set
- Complete time on this workorder to generate the [WC] AALs on this MO
- Change the analytic account on the MO (or delete it)
Bug: The [WC] AALs never get correctly updated.
This fix builds on https://github.com/odoo/odoo/pull/79614 to correct this behaviour and also take into account changes for the workcenter cost AALs when the analytic_account of a manufacturing order is changed.
Community PR: https://github.com/odoo/odoo/pull/117308closesodoo/odoo#122396
Task: 3252742
X-original-commit: 35e3af77051d1dfdf54600b607acfb593aa49e34
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Claeys Pieter (clpi) <clpi@odoo.com>
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
Currently, when a specific capacity is defined for a product in a
workcenter, if a setup / cleanup time is given, it will be added to the
existing setup / cleanup time of the workcenter.
What we want instead is to be able to fully define what the
setup/cleanup time is for this specific product. So the given times in
the specific capacity override the times defined in the workcenter for
that specific product.
To help with that, we set the workcenter's setup/cleanup time as a
default for their related specific capacities, since if not changed,
they will follow the workcenter times.
Updated the tests so their specified capacities match the new behaviour.
closesodoo/odoo#119212
Related: odoo/upgrade#4576
Signed-off-by: Tiffany Chang <tic@odoo.com>
Related enterprise PR: odoo/enterprise#39669
Steps to reproduce:
Install mrp_workorder
Create Product P1, Workcenter W1
Edit W1 > Specific capacities > Add line: Product = P1, Start time = 5, End time = 5
Create BoM > Product: P1, Operations tab > Add line: Workcenter = WC1, Default duration = 60:00 min > Save
Click on overview stat button
Issue:
The created operation has expected time of 60:00, instead of 70:00. The workcenter start and stop times are considered in this calculation, so the workcenter capacities should be considered too.
Solution:
Use `_get_expected_duration` to compute the expected duration.
opw-3229485
closesodoo/odoo#121060
X-original-commit: 7b5a30fb3e51434154050052ec39ed299c6094d3
Related: odoo/enterprise#40905
Signed-off-by: Tiffany Chang <tic@odoo.com>
account
1. We introduced a new Production Cost account that can be set on
locations with Production type. When products move into/out of a
production location. The account entry will be post on this account
instead of previous Stock in/out account.
2. On the accounting setting page, we can now set the default values for
all stock accounts. Users can also disable automatically accounting for
stock there.
Task-3046333
closesodoo/odoo#113973
Related: odoo/enterprise#37653
Signed-off-by: Tiffany Chang <tic@odoo.com>
When a product category valuation is set to `real_time`, we use the
stock accounts. However, in the code, to know which account we
should use, we do: "use stock accounts if defined, else use basic
ones" (the best should be "use stock accounts if `real_time`" but
this refactoring task will be done in master). So, here, we need to
ensure that stock accounts are not defined when the valuation is manual.
This is the case when installing `stock_account` module: the
valuations will be set to manual, so we need to force the stock
accounts to `False`. Same when creating a new company, we also need to
ensure that the stock accounts are not defined. This explains the
changes in `_post_load_data`
About changes in `_check_valuation_accouts`, the explanation is in
the method body: the defined values directly depends on the value of
`property_valuation`
Note about test modification: for the tests in `stock_landed_costs`
module, we set the categ to auto so the stock accounts are defined.
Otherwise, when validating the landed costs, it will lead to an error
https://github.com/odoo/odoo/blob/9cd316f038dc95051814ede9474f8f15f7d165df/addons/stock_landed_costs/models/stock_landed_cost.py#L396-L397
OPW-2746384
X-original-commit: 2780c37cfdb8560ac7c725fd27f4fe272f1d3072
Part-of: odoo/odoo#119564
Current behaviour:
Cannot add a Work Order to a Manufacturing Order
if the analytic account linked to the MO doesn't
have an associated company.
Expected behaviour:
Should be able to add a WO to a MO even
if the linked analytic account doesn't have
an associated company.
Steps to reproduce:
1. Activate analytic accounts
2. Activate work orders
3. Create an analytic account without company associated
4. Create a Manufacturing Order
5. In miscellaneous, link the analytic account
6. Try to add a WO line
7. Error log
Reason for the problem:
When trying to add a WO line, if the MO has been linked
to an analytic account, it checks for the currency in
the company in the analytic account, which was not
existent, since the company didn't exist.
Fix:
When trying to access currency, if the company in the analytic
account doesn't exist, it defaults to the company in the WO.
opw-3210708
closesodoo/odoo#117708
X-original-commit: f0d8f5e82e62e0bcfc05e25dac2504f8f07537f4
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Add the group 'mrp.group_mrp_routings' on the main user to make field
'workorder_ids' visible in the form view of 'mrp.production'. Many
tests use that view, and require the subviews of that field to be
present in order to create records.
closesodoo/odoo#116779
Related: odoo/enterprise#38858
Related: odoo/documentation#3968
Signed-off-by: Raphael Collet <rco@odoo.com>
Adapt tests for other moudules to use
ENT PR odoo/enterprise#33399
X-original-commit: 88cad50cac8130e1ff66a21ab63d53b41488a74a
Part-of: odoo/odoo#106007
Adapt community to make it possible to add employee cost when calculate
bom cost.
closesodoo/odoo#105645
X-original-commit: a239802249b2af2cc3fc2b3bb9fdfd0a408d887a
Related: odoo/enterprise#33898
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Steps to reproduce:
- set time effeciency of a workcenter to less than 100
- on a product page with a BoM using that workcenter
- for the cost click on compute price from BoM
Bug:
workcenter effeciency is not taken into consideration
Fix:
included time_effeciency in computing the expected duration
addepted tests to take it into consideration aswell
opw-3033672
closesodoo/odoo#104566
X-original-commit: 1dcd9dbef0a5e6d9bd2c5e52a42cff9aec98f1d0
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This task will:
- Clean the code (e.g. the production's moves are now created directly)
- Have the same behavior when creating object in the UI or directly in
backend
It's mainly on the `mrp.production` object and most of the computed
stored field are used as default value or act like an onchange on draft
production. Once the production order is validated, it's only modify
by direct write
Task-2709753
closesodoo/odoo#83576
Related: odoo/enterprise#24405
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Currently, when changing qty_producing on a MO, consumed number of each
component will always be updated. In this commit, we add a new boolean
field manual_consumption to bom.line. If checked, that line won't be
updated when changing qty_producing.
The same but invisible field manual_consumption is also added to each
line on MO. It will use the value on BOM as defualt value. When user
manually set the consued qty, it will be checked automatically. Also,
when user manually update the SML, the field on SM will also be set to
true.
Task-2687494
closesodoo/odoo#80118
Related: odoo/enterprise#25607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Analytic Accounts can be defined in the MO and can be changed in any MO stage. So the analytic account line will also have to be updated to be linked to the new AA
opw-2674347
closesodoo/odoo#79955
X-original-commit: 65a18382c1712968148898998e3778b77f199dea
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- The "BoM Structure & Cost" takes now in account
the subcontracting cost.
The subcontracting cost depends of the best supplier info in product
and subcontractor register in the BoM.
- Also add this subcontracting cost (to the cost field) when we click on
"Compute Price from BoM" in the product view.
task-2486811
Part-of: odoo/odoo#75041
Add analytic accounting for MO.
Post expense entries for:
1. raw material cost (change with consumed)
2. work center cost (change with real duration on work order)
Task-2469742
PR #68708
For improved cost analysis, byproducts can now have a "cost share" (out
of 100%) indicated. This cost share will by multiplied by the total BoM
cost (i.e. components + operations costs) and reflected in the stock
valuation. The final product will also have the byproducts cost
subtracted from its final stock valuation. This is of course only
applies when costing methods are appropriate (i.e. non-standard price).
Additionally, we can now "Compute Price from BoM" for byproducts (via
its product form) and the BoMs that it is a byproduct of are now counted
towards its # BoMs smart button (we will now also see these BoMs when
clicking on the smart button). Of course when there is no cost share for
byproducts then clicking on "Compute Price for BoM" will not change the
a byproduct's cost and if there are multiple BoMs the prodcut is a
byproduct of, the calculation will only be based on the first BoM it
finds (i.e. same as current logic for manufactured products).
BoM Cost report has been updated to include byproducts with cost shares
(byproducts with cost share = 0 will not show up in report).
Additionally we update the report to display operations only costs now
that BoMs are allowed to have no components in them.
Part 1 of Task: 2440068
Upgrade PR: odoo/upgrade#2727
Related ENT PR: odoo/enterprise#20169
Part-of: odoo/odoo#74951
Previous fix f056254d1c5153467b10d9581214ff6d1348be76 didn't take the
situation when production location has its own valuation accounts into
consideration. Fix it in this commit.
opw-2476417
closesodoo/odoo#71064
X-original-commit: 60e83f03b871605b7aa281503269f66ac3ea940b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Yuchen Huang <yhu-odoo@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This doesn't make sense anymore: when we record production on a WO, in
any cases everything is processed as we make backorders.
Part of: https://github.com/odoo/odoo/pull/54283
task-2278147
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
The inventory button was shown or hide depending of the product valuation.
As the valuation was previously stored on the stock moves and posting
split the stock moves. Fifo and Avco valuation was not well computed.
The migration to stock valuation layer fixed this behavior. This
commit shows the post inventory button as soon as there are some
finished move to be posted.
task : 54665
closesodoo/odoo#41781
X-original-commit: 5dfa3f817d3a9f47a863a587569a862a40c7d159
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Overwrite the method ``write`` of the model ``product.product``.
When we write on ``standard_price``, if
- the context key ``disable_auto_svl`` is not set
- the ``cost_method`` is not "fifo"
We automatically compute ``stock.valuation.layer``
(before we needed to manually call ``_change_standard_price``)
Task #2031422closesodoo/odoo#41265
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Some tests (test_00_workorder_process, ...) are executed several times, only
because we extend a test class to retrieve the setUp (or setUpClass) instead
of creating a common class.
This could lead to issues, (like for test_00_workorder_process) depending on the
installed modules.
A finished move is considered as an incoming move and will pass by
_create_in_svl. We thus compute the price_unit that will be set on the
valuation layer.
We also set a stat button on the MO displaying the valuation
layers, similar to the one on the picking.
task-1875873
Change the use of Inventory Adjustment, notable changes are:
- Removed filter field: When user creates a new inventory
adjustment, he can set one or multiple locations and/or products.
An inventory adjustment will worry only about defined
locations/products, but if neither product or location was set,
it'll manage all stock.
- Inventory Adjustment Lines have their own view instead of be
listed on the Inventory Adjustment form view.
Inventory adjustment lines have new color legend:
- Red: The quantity is outdated.
- Blue: There is difference between the on hand quantity and the
counted quantity.
New inventory lines created by the user are written in bold.
- User can't modify already existing inventory lines, except for the
counted quantity.
- When an inventory line is outdated, the user has the possibility
to select and update it, that'll recompute the on hand quantity.
- When an inventory adjustment is validated, it will take in account
only the difference between the theoretical quantity ('On Hand
Quantity') and the counted quantity to adjust the quants.
- When an inventory adjustment is canceled, it will keep its
inventory lines and won't regenerate them when re-started.
- When an Inventory Adjustment generates Account Moves, user can now
find them in a stat button in the Inventory Adjustment form view.
Also, made some changes in demo data to match new requirement.
Task #1935921
Merges mrp_bom_cost into mrp_account since they have both the same
depedences.
Task #1964809closesodoo/odoo#32722
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This is a preliminary work to handle the price of subcontracting. We put
this field in the generic `mrp_account` module because we also want to
support adding an extra cost on a finished move without having to work
with the wokorders, on a future task.
task 1831382
Walid