commit [1] addeed production cost account. However this account is
mandatory with real time valuation. It could be an issue during
production because we don't have an automatic way to create a new
valid account. On top of it this behavior is optional and people
could still use the classical input and output account for production.
This commit make the cost of production account optional and fallback
on previous behavior with input/output accounts
[1] commit 1eb2e7c814closesodoo/odoo#136463
X-original-commit: ea647812e76931f9193ae841f428b312b861739b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This issue occurs when the user has not provided production account and is
trying to produce the manufacturing order.
steps to produce:
- Install `mrp_production`, `account_accountant`.
- From Settings > Users > Manage Users select a user (eg: Mitchell Admin) and
under `Technical` select `Stock Accounting Automatic group`.
- Inventry > Configuration > Products > Product Categories open a category and
change it's `Inventry Valuation` (property_valuation) to Automated.
- Through Accounting > Configuaration > Settings >
Stock Valuation check `Automatic Accounting` and remove Production Account and
save it. (You will see that production account got removed from the product
category).
- Now create a manufacturing order by Manufacturing > Operations > Manufacturing
Orders
- While creating manufacturing order select the product which comes under
product category you have modified, then confirm the
manufacturing order.
- Once it is confirmed click on `Produce All`.
video: https://encr.pw/09a2c
Error: `AttributeError: 'bool' object has no attribute 'id'`
Through our commit if the user does not specify a `Production Account` then the
user will face the UserError. The error is specified in
`_get_accounting_data_for_valuation` function while checking for `account_src`
or `account_dest`.
sentry-4271608065
closesodoo/odoo#128594
X-original-commit: 9265e785dedd8943296573fc6e5218925a33c522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce
- Create Manufacturing Orders and confirm it.
- Validate the done quantities.
- Click on valuation button. It will raise trackback
Error caused by commit: a080337closesodoo/odoo#124956
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Install mrp_plm
- Create a BoM with an analytic account
- Create an ECO
- Start the revision
Problem:
The new BoM version doesn't have the analytic account from the original
one.
opw-3329901
closesodoo/odoo#125111
X-original-commit: 0210980037ccf843d73033d2a240369112899ff1
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>
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>
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>
If the stock move (consumed_moves) has more than 1 stock valuation
layers (stock_valuation_layer_ids), it will cause an expected singleton
error.
closesodoo/odoo#113764
X-original-commit: 2efe6bea6887ebd6528eba084eb3eaee8af7ab9e
Signed-off-by: Tiffany Chang <tic@odoo.com>
before this commit, the action name was not getting translated to user language.
after this commit, the action name will get translated to user language.
closesodoo/odoo#110856
X-original-commit: 6758cde0358359d76642b0cbea4c208eac57dd92
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Go to product category → set the inventory valuation to
“Automated”
- Create a BoM:
- Add a component with the cost set to 10$
- Add an analytic account
- Create a MO to produce one unit of “P1”:
- Confirm the MO:
- an analytic account line is created with the amount of $10
- Mark as done the MO:
- The amount is updated to $0
Problem:
In the case where the inventory valuation is set to “automated” we use
the analytical distribution since this commit:
https://github.com/odoo/odoo/blob/7e3403068fc3fbc40182b3cfeb80e97a9300e8ff/addons/account/models/account_move_line.py#L2326
but in the case of MO it shouldn't use it
Solution:
If we are in MO, ignore the type of inventory valuation
opw-3081877
opw-3086626
closesodoo/odoo#110478
X-original-commit: af7be17b71fc72d15149c4baabadeacdcf77cc99
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closesodoo/odoo#101012
X-original-commit: 9ec7aa9b89bc929af15473d0cc29084fd831cf94
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When invoicing a tracked product, the lots/SN delivered (or the related
quantities) are not always the correct ones displayed on the printed
invoice
To reproduce the issues:
1. In Settings, enable "Display Lots & Serial Numbers on Invoices"
2. Create a product P:
- Storable
- Tracked by lot
3. Update its quantity > 5 with lot L
Use case 01:
4. Create and confirm a SO with 5 x P
5. Process the delivery
6. Create an invoice
7. Edit the invoice line:
- Quantity: 1
8. Post and print the invoice
Error: The quantity related to lot L is 5, it should be 1
Use case 02:
4. Edit P:
- Invoicing Policy: Ordered quantities
5. Create and confirm a SO with 1 x P
6. Create and post the invoice
7. Process the delivery
8. Print the invoice
Error: There isn't any information about delivered lot L
Use case 03:
4. Create and confirm a SO with 3 x P
5. Deliver 1 x P (with backorder)
6. Invoice 1 x P + Post the invoice (-> INV01)
7. Deliver 2 x P
8. Reset, post INV01 again and print it
Error: The quantity related to L is 3, it should be 1. Moreover, if the
user then invoices the 2 others P, posts and prints this second invoice,
it won't contain any information about L
OPW-2730270
closes#81444closesodoo/odoo#89088
X-original-commit: 3598c0c8cda813efa1aebc17f041e4c0a1a29f06
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
When returning a kit, the margin of the related SO decreases
To reproduce the issue:
(Need sale_management)
1. In Settings, enable "Margins"
2. Create a Product Category PC:
- Costing Method: FIFO
3. Create two products P_kit, P_compo:
- Both:
- Type: Storable
- Category: PC
- P_compo:
- Cost: 10
4. Update P_compo quantity: 1
5. Create a BoM:
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
6. Update P_kit's cost
7. Create and confirm a SO with 1 x P_kit, unit price = $100
- Note that the margin is correct: $90
8. Process the related picking
9. Create a return R
10. Go back to the SO
Error: the margin is now $80
When computing the cost of the kit, the move linked to R are considered.
Therefore, the cost becomes $20 and thus the margin becomes $80
OPW-2679473
closesodoo/odoo#83008
X-original-commit: 2f34669f9dc3c9abfcbb13198f90f37405ffc258
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When reversing an invoice linked to a sale order, the value of the new
anglo saxon AML should be based on the value of the returned product
To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P:
- Type: Storable
- Product Category: PC
3. For C in [10, 20, 30]:
- Create a purchase order with 1 x P at cost C
- Receive P
4. Create a SO with 3 x P
5. Deliver the products one by one
6. Create and Post the invoice INV linked to SO
7. Return the second delivery
8. Add a credit note to INV01:
- Credit Method: Partial Refund
9. Set the quantity to 1
10. Post the new invoice INV02
Error: The anglo saxon lines are listed in the journal items, which is
correct, but their value is $30 while it should be $20 (i.e., the value
of the returned product)
When delivering the last product, its standard price is updated with the
new value ($30):
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L305-L307
Later on, when posting the credit note, the module gets the anglo saxon
unit price (`_stock_account_get_anglo_saxon_price_unit`). However, it
does not consider that the current account move line is reversing
another one. In the reversing process, the computation of the invoiced
quantity should be based on the invoices lines that are reversing too.
Moreover, when computing the average unit price of the returned product,
the module should use the stock moves that are returning the product.
In the use case, because of the two issued noted above,
`_compute_average_price` does not find any stock valuation layer to
compute the average unit price and uses the fallback, i.e. the standard
price of the product:
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L652-L656
That's the reason why, in the above case, the value is $30 instead of
$20.
Note: a similar use case can be reproduced with a kit
OPW-2646926
OPW-2628215
closesodoo/odoo#82978
X-original-commit: 524d0d5e8817e1c7bcc99204c4cbb90fcfb6074c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
Suppose an automated AVCO product category. When confirming an invoice,
if the associated product was a kit and if its BoM has changed during
the process, a traceback can occur.
To reproduce the issue:
(Need sale_management)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
2. Create 3 products P1, P2, P3:
- Product Type: Storable
- Category: PC
3. Update P3's quantity > 0
4. Create two bills of materials:
- BOM01:
- Product: P1
- BoM Type: Kit
- Components: 1 x P2
- BOM02:
- Product: P2
- BoM Type: Kit
- Components: 1 x P3
5. Create a sale order SO with 1 x P1
6. Confirm SO and process the delivery
7. Edit BOM02:
- BoM Type: Manufacture
8. On SO, create the invoice INV
9. Confirm INV
Error: an Odoo Server Error is displayed with a traceback: "[...] in
_compute_average_price, bom_line_data = bom_lines[bom_line] [...]
KeyError: mrp.bom.line(19,)"
On step 7, when changing the BoM type, a new BoM line is created.
Therefore, in `_compute_average_price`, the BoM associated to the move
(i.e., `bom_line`) is not one of the lines in `bom_lines` (i.e., the new
BoM lines). There is already a check in case the line has been deleted,
but not if it has been changed.
OPW-2610685
closesodoo/odoo#78917closesodoo/odoo#79293
X-original-commit: 3ae0b781bcb5c2840f848bc63b9f3f9e1b2812cb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create a Product A with Costing Method = FIFO
- Create a Product B with Costing Method = FIFO and cost of 10
- Create a BOM of product A > type = Kit
- Add product B in bom line, with qty = 1 and UoM = dozen
- Add product A in `sale.order`
- Confirm order
Problem:
The cost is 10 rather than 120 (10 * 12 = 120)
Solution:
The kit cost must be the total cost of the components multiplied by their unit of measure
opw-2631487
closesodoo/odoo#78086
X-original-commit: 6c48262c8656821aa51669bd77cdf0f35634512f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Co-authored-by: fmdl <florent.mirieu@gmail.com>
If a MO created from a MTO doesn't have a BOM with a analytic account
already assigned to it, then propagate the SO analytic account (if it
has one) to the MO.
closesodoo/odoo#77897
Task: 2648460
X-original-commit: 061037fb79f007389408136fd3ed13e5de970908
Related: odoo/enterprise#21477
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
- update MO list status colors: draft = blue, in progress = yellow +
make the WO status colors match (waiting = blue, in progress = yellow)
and make draft MO lines all blue (to follow current design standard)
- cleanup Activity in tree view (no label in tree + "Next Activity" in
column selection dropdown)
- make units of analytic accounting for WO = hours
- make quantity for move_raw_ids products (i.e. components for MOs)
always have positive analytic_account_line.unit_amount (i.e. when
changing a done move's quantity + changing a quantity twice made this
value negative)
- make "Copy Operations" on BOM open the list view in "current" instead
of "new" due to lack of hook to prevent form view (i.e. open BoM in
current view) changing when clicking on lines in the new window's
operations (also ends up being a better UX anyways since being able to
view the operations form view is desired).
Task: 2648460
X-original-commit: 65a2d478197f5b856212225319500ca61b161809
Part-of: odoo/odoo#77897
Issue: With margin enabled and avco for stock valuation, after
confirming a SO with a product variant which is a bom kit,
when we try to change the variant, there is a traceback
Steps to reproduce :
1) Install Stock, Accounting, MRP, Sale,
2) Enable Margins in settings
3) Configure a Product Category with costing method AVCO
4) Configure a Product with 2 variants and that product category
5) [Important: KIT] Create 2 BoM, one for each variant and set those
BoM to KIT
6) Create a SO for that product and one variant
7) Confirm the SO, cancel it, and set to quotation
8) Edit the SO and change the variant, save
-> Traceback
Side-Note:
This issue is due to the fact that we iterate over the stock_moves to
find the quantity of the BoM, but that stock_move correspond to
confirming at step 7, when we change the variant at step 8, the stock
move has not changed, so still contains the previous bom_line_id with
the quantity, but this doesn't reflect with the new state of the SO
which is for a different variant.
For me since the stock move is canceled, it should be taken into
consideration when computing the average price but I might be wrong,
it's up to the reviewer to decide if it makes sense
opw-2639093
closesodoo/odoo#77606
X-original-commit: c0d4ed5ac641d339a6cd4e23db9667048d35360d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When the name of a production order changes, we should update the name
and the reference of the analytic accounting lines of its work orders.
Task-2638896
closesodoo/odoo#76090
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Both mo_analytic_account_line_id and wc_analytic_account_line_id are
copied when duplicate the workorder. This is not correct.
Task-2638896
Part-of: odoo/odoo#76090
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
On BoM, a component line can be filter out depending
of the product variant to manufacture
(with "Apply on Variant" field).
Extend this feature to operation and byproduct line.
task-2614126
closesodoo/odoo#74973
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Enable Margin analysis
- Have a product [TEST] in a category with
- FIFO and Automated Valuation.
- Kit BOM with 3 items (A,B,C)
- Create a SO with [TEST] and confirm.
- Modify the BOM and remove C from the kit.
- Back to the SO, cancel it.
Traceback will show, because there no more a bom_line associated with
the move
opw-2541674
closesodoo/odoo#72696
X-original-commit: 27821b728f409d7e1a69e84d0beb5ac708e6420e
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The company is not mandatory on the analytic account, and the currency on it
is a related field to the currency of that company, if set. In case it is not
set, we should add a default fallback on the currency of the company of the
manufacturing order.
closesodoo/odoo#72482
X-original-commit: 4fc2ec31861d4602357f130066ec3507b96d8dc8
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
- Activate anglo saxon accounting
- Have a [DEMO] KIT product in a category using automated
Inventory Valuation with costing method AVCO
- The KIT is composed by C1 and C2 in the same product category
- Define a cost on both C1 and C2
- Open a POS session, order [DEMO], Invoice and complete the order
- Close Session, Validate and display Journal Items
COGS entries will be missing.
This does not occur when making the order without invoicing
opw-2481518
opw-2545758
closesodoo/odoo#72460
X-original-commit: 659b455aca7a2c7f0cb41bfd6312bca25917d8a9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
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>
In a subcontracting flow, a production order is created to reflect the
subcontractor work. An extra cost is set on this production order
corresponding to the purchase order line price unit. If the
subcontracting product is tracked, we may create some backorder to save
all the lot/serial numbers. As the extra_cost is not copied, the first
lot/serial number will have the corresponding stock valuation layer with
the correct quantity. The following ones will only have the cost of the
components as value.
closesodoo/odoo#69245
Opw: 2487450
X-original-commit: 262c2ba8773c698ccde499b095794ab0fc780699
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Some usage of `_bom_find` are performance bottleneck (one request by
product). By example, when the mrp is installed, search products
with fields compute by `_compute_quantities` (e.g. 'Negative forecasted
quantity'). it is due to the override of `_compute_quantities`
in mrp which will make (in the worst case) a `_bom_find` for each
product in the DB.
To avoid this situation the `_bom_find` method become batched
which can handle several products in once. The signature of the method
has changed and uniformize in all module.
Example performance Gain:
------------------------
In a DB with 7000 products (type 'product'), 500 locations, 1800 BoM,
9000 Stock moves, etc. Search in the tree view with filter "Negative
forecasted quantity":
Before: 10879 (nb SQL request) 12.67 +- 0.11 sec (Total RPC Time)
After: 159 (nb SQL request) 1.82 +- 0.03 sec (Total RPC Time)
task-2439019
Usecase to reproduce
- Create a KIT with COMP A (15$) COMP B (25$)
- Enable Margin on SO
- Set the cost on the KIT with compute cost button (40$)
- Create a quotation with the KIT (cost is correct 40$)
- Confirm the quotation -> Cost is updated to 15$ (first component)
It happens because the function to compute the average price doesn't
expect a kit and compute everything from the valuation layer of first
component
opw-2413246
closesodoo/odoo#65301
X-original-commit: 827f65f70634ba7a2e4175f20e5301e514ada0a0
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently when unbuild a MO, we create journal entries the same as
receiving components (add credit to input account) and deliver
finished product (add debit to output account). But since the
unbuild is just a revesal of the MO, the journal entries should
alse be revesals.
In this commit, when unbuild a MO, for the journal entry about the
component change, we add credit to the output account, and for the
journal entry of the finished product change, we add debit to input
account make sure the journal entries are also reversals.
Task 2312828
PR #58150closesodoo/odoo#60730
X-original-commit: 83a3230706e1e2f4eaf9718156647821341d192b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
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
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
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
Arnold Moyaux