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
missing bit from rev[0] and [1]
[0] 7ef11e3
[1] d6c8c34ef6539dad110f1e502eaee2c03d968797
closesodoo/odoo#42621
X-original-commit: 5096e724643ca77568ce2f09a40b138561f4c20f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The valuation stat button was shown only at validation of the manufacturing
order. If an intermediary inventory is posted. A part of the stock moves
are validated so some stock valuation layer are generated.
This commit shows the valuation button as soon as some valuation layers
are linked to those validated stock moves.
Task : 54665
X-original-commit: 7f67af93299c449ba80489a84ed0b13930edff90
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>
When marking as done a MO, we use SUPERUSER to create analytic line
as an MRP user does not always have access to analytic items. There
is however a default value for company analytic line defined to the
user's context company, so we need to use the current company of the
real user instead.
closesodoo/odoo#39209
X-original-commit: 14aade9341bf9d61cd21de948755fc339ae512ea
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
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
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
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
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>
Fabien Pinckaers