Commit 72a17bafba6e7 force the PO `date_order` to be >= at ` today() to
ensure the select_seller method take the right seller price. This
introduces an error in the MPS module that may need to create PO in the
past.
Instead, this commit patch the call to `_select_seller` to take at least
`today()`
closesodoo/odoo#134217
Opw: 3167094
X-original-commit: a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When a product is purchased and received, valuation layers are created.
if we created a bill for the PO and change the product price, when the
account move is posted, `_apply_price_difference` creates new SVLs to
correct the product value.
Before this commit, the above scenario did not work with subcontracted
products, mainly because the valuation layer is linked to the finished
product move of the MO and not the incoming move of the PO.
This is fixed in `_get_valued_in_moves` where if the move is_subcontract
the orig move is the one linked to the valuation layer.
Now that we have the valuation layer, another issue arises, in the aml
`_generate_price_difference_vals` when the difference is calculated.
the `unit_valuation_difference` is not properly calculated because the
value in the layer includes the components value, so its incorrect to compare
it to the AML price, so we use `_get_layer_price_unit` to get the layer_price_unit
relevant to the AML, which in this case is the price of subcontracting (price on the PO)
Also for automated inventory valuation, when the inventory correction entry is
created it must credit the stock input account since the value of the
subcontracted product is corrected.
closesodoo/odoo#131565
Taskid: 3449931
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Minor cleanup after odoo/odoo#104741 thanks to edge-cases and the fun
complexity of logistics code. Fixes include:
- removing some readonly=False that were added on computed/stored fields
that already have an inverse func or were already not readonly (i.e.
redundant => cleanup)
- fixed visibility of qty to prod in subcontractor portal view of a MO
(i.e. yay they know how much they're supposed to make again)
- remove unused imports
- adding back in readonly functionality of default dest of repair
operation type (and removing the now useless field override that used
to add in the readonly functionality)
- adding back in the `_set_product_qty` inverse function since it was
probably removed by mistake (and is still important to have)
unrelated to viewpocolypse change, also fixed:
- mobile view of PO was for some reason allowing products to be changed
in already confirmed/done POs, which could lead to some inconsistent
data => made this consistent with existing desktop view behavior
closesodoo/odoo#133502
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
entry wrong when resupply subcontractor
In case product is using standard price and automated inventory valuation.
We post account entries in price difference account when the price on
purchase order is different from the cost of product. However, when we
do subcontracting and resupply our subcontractor, the cost is not just
the price on purchase order, but also the cost of the components we sent
to the subcontractor. Currently, we didn't take the components cost in
to account when post price difference entries. Fix it in this commit.
Task-3223451
closesodoo/odoo#132282
X-original-commit: e771535b487e76f4e5a23b767d220d7f640292a6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
Prerequisites -->
1) Login with a user with just Inventory/User access rights
2) Product A with purchase policy set to `on ordered quantities`
3) Product category of A set to `AVCO` costing method
Steps -->
1) Create+confirm a PO with product A and create and confirm vendor bill
2) Switch to Inventory/User user
3) Try to validate picking
4) Access right error
This occurs due to the fact that `Inventory/User` does not have access to s`tock.valuation.layer` or `account.move.line`.
Solution -->
Add sudo to the lines where accesses to SVL and invoice lines are made.
opw-3357028
closesodoo/odoo#130929
X-original-commit: 8d2a77d1bdbe8f865d8f7177801786617e10058f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Receiving a kit's component will fail in AVCO + multi-uom
To reproduce:
1. Create a product category PC
- Costing Method: AVCO
2. Create two products P_compo, P_kit
- P_kit:
- In Units
- P_compo:
- In L
- Storable
- Category PC
3. Create a BoM
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
4. Create and confirm a PO with 1 x P_kit
5. Process the receipt
Error: When validating the receipt, a user error is displayed: "The
unit of measure L defined on the order line doesn't belong to the
same category [...]"
When processing the SM, we create the in-SVL. To do so, at some
point, we need the unit price of the SM, and here is where the error
comes from:
https://github.com/odoo/odoo/blob/708c3d063482e365e49a04f633c83e90e6fa4356/addons/purchase_stock/models/stock_move.py#L39
`self.product_id` is P_component, but `line.product_id` is P_kit,
hence the error with the UoM1
And there will be some similar errors with the `if` block, L40 (we
compare some SM quantities and some POL quantities: we are mixing
components and kit)
For now, in case of a kit, we will always use the `else` block (i.e.,
the unit price of the POL). This will be improved in master
OPW-3357685
closesodoo/odoo#128386
X-original-commit: 3a81eb79cad7f25843315e39da421efa2c34aaf1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
When a RR updates the qty of a POL, the qty to order of that RR will
be incorrect
To reproduce the issue:
1. Create a product
- Storable
- With a vendor
2. Create a RR:
- Min 0
- Max 0
- Factor 1
3. Confirm a delivery with 1 x P
- It should create a PO
4. Confirm a second delivery with 1 x P
- The POL of the PO should be updated
5. Open the Replenishment page
Error: The qty to order of the product is 1 while it should be 0
`qty_to_order` is a computed field and one of the `depends` is the POL
related to the product. This explains why, after step 3, everything
is ok: the compute is triggered (because of the new POL) and the qty
to order becomes 0. However, step 4, the POL qty is updated -> it
does not concern any `depends` -> the compute is not triggered,
hence the error
OPW-3292297
closesodoo/odoo#128279
X-original-commit: 80521431601323c1eb7c85cafbf08e8ae0adbdd6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
On-time-rate is a non-stored computed fields that can take
some time to load because some partners may have lots of
related purchase_orders. The compute function in itself
is relatively difficult to optimize further. This commit
introduces a new system parameter to reduce the timerange of
orders to consider when computing On-Time Delivery Rate.
That way, if for some customers the on_time_rate computation takes too
much time (leading to a slow FormView loading), they can reduce
the accuracy of the estimation to speedup the field's computation.
closesodoo/odoo#128199
X-original-commit: 2e766f11024e9bb905f8e98d7218cf924c43a0c9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Before this PR, the incoterm location was not present in the account module.
This pr does multiple things:
- Add the Incoterm Location field in Accounting on Customer Invoices and Vendor
Bills. The field already exists on Sale Orders and Purchase Orders. When you
create an Invoice from a Sales Order, or a Vendor Bill from a PO, copy the value
of the field on the invoices.
- Update the PDF to display the field value if present, and remove the useless
duplication
- Remove incoterm setting on sale
- Remove useless xpath since now it is displayed directly on invoice when
incoterm field is fill.
Task-id: 3273460
Part-of: odoo/odoo#118954
layer.account_move_id may not be defined on 'manual' valuation.
Use layer.create_date instead which is equal to layer.account_move_id.date.
# HOW TO REPRODUCE:
- Create a product P, storable in AVCO !! MANUAL !!
- Set 'Control Policy' under Purchase to 'Ordered Quantity'
- Create a PO for 10 units of P with for $1 each.
- Create Vendor Bill -> Confirm
- Receive 5 unit of P: Create backorder
- Validate backorder
==>> Traceback
OPW-3383833
closesodoo/odoo#127218
X-original-commit: b1351ee348207283dcdf7118440b31c03f0d0b4b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
If a bill has a price difference with the PO, and if the user
refunds it, it will create some errors in the inventory valuation and
the accounting entries
To reproduce the issue:
(Need account_accountant)
1. Create a product category PC
- Costing method: FIFO
- Inventory valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Confirm a PO with 1 x P at $10
4. Receive P
5. Bill it at $15
- It should create a price diff SVL, see inventory valuation
6. Refund
Errors: The inventory valuation is not impacted, it is still valued
at $15. Because of the refund, it should be $10 (i.e., the price
difference should be cancelled). Then, suppose the user creates a
new bill at $20, it won't do anything (the stock valuation will not
be impacted).
Long story short: the price difference feature, which is supposed to
impact inventory valuation/account entries, does not work if there
is a (partial/full) refund in the flow.
Now, let's think about a more complicated use case:
- Receive 12 products in several times
- Bill in several times (with different quantities than the receipts)
It could give something like (where `x` are products):
```
SVL01 SVL02 SVL03
/---------------\/---------\/------------------\
x x x x x x x x x x x x
\-----------/\-----/\--/\---------------/\------/
B01 B02 B03 B04 B05
('B' means Bill)
```
We observe that
- a bill could impact several layers
- a layers could be impacted by several bills
And here is the issue: currently in the code, we don't have a relevant
link between layers, account move lines and the quantity that links
both. The only thing we have is a link between the price difference SVL
and the account move line that has generated that SVL (see field
`account_move_line_id` on `stock.valuation.layer`). But this is
clearly not enough and is really problematic: if I refund BILL04, how
should it impact SVL02 ? Then, what if I return a part of the third
delivery before refunding BILL04 ? What if I deliver a part of the
received products before refunding several bills ? What if I refund
B02, B05, then I bill 4 products ?
-> You get the idea: we definitly need a clear link between account
move lines and stock valuation layers and that link has to give a
quantity.
Moreover, it is difficult to create an order between bills. We have
their name, their ID, but the posted time is actually a date. So, if
we mix reset & repost, a draft bill and a draft partial refund, and
so on, and if this mix happens the same day, it is very difficult to
define a clear order. But, considering the above schema, we see that
the order does matter (switch BILL02 and BILL03, the remaining
values of SVL01 and SVL02 will not be the same)
-> So, we also need a way to order the links between account move lines
and stock valuation layers.
Now, about the solution.
First, a **disclaimer**: We are in stable, we are limited by the stable
policy, and we can't let the above use cases unresolved. So, we took
some decisions to fix them and to repesct all the constraints we had.
**This is clearly a (big) patch, it should be considered as such and
will be replaced by a cleaner/better solution on master as soon as
possible**.
About the link between SVL and AML, we had the possibility to create
a new model in a new module. But this would have decreased the
impact of the fix deployment, would have created some
complications for support (different behaviours depending on whether
the module is installed or not) and would have make testing more
complicated (again, different behaviours depending on whether the
module is installed or not).
This is the reason why we decided to "replay the receipts and the
bills". That way, we know which layer is impacted by which invoices,
and vice versa. And, to set the order between all of them:
- For the layers, we use their `create_date`
- For the bills, we use a hack: each time an account move is posted,
because its state is tracked, a tracking value is posted on the
chatter, and this tracking value has a `create_date` (remind the
constraints explained above and the disclaimer...)
OPW-3217215
closesodoo/odoo#126536
X-original-commit: b5e0e1057b81f7333e73ef06e88e8943709119cc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
To reproduce:
1. Create a storable product with ordered quantities policy for purchase and with a category set as FIFO automated
2. Create a purchase order in a different currency and set quantities for partial deliveries
3. Create a partial delivery
4. Fully invoice the purchase order
5. Create the delivery of the complementary units
6. Check the stock valuation layer
The valuation of backorder is wrong.
The value on valuation layer is in company's currency, while the value
on invoice line is in the PO's currency. When create valuation line for
backorder, we didn't convert them to same currency.
opw-3300266
closesodoo/odoo#125206
X-original-commit: c2de679fcba7f153201dde5b3aa989eb3f329910
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
before this commit, the field incoterm_id is defined
twice in purchase.order model, i.e., in purchase and
purchase_stock modules
after this commit incoterm_id field is removed
from purchase_stock module
closesodoo/odoo#123602
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
With this commit:
========================
- Added a new field `forecasted_qty` in replenishment to display the
forecasted qty based on a selected warehouse in the wizard
- Changed the `route_ids`(m2m) field to `route_id`(m2o) so that
we can apply a specific route for the
replenishment instead of the product's default routes
- Reduced the width of all the fields
- Remove the time from the scheduled date and make the unit field not editable.
- Can see vendor information with info icon field when buy is selected
- Hide the Dropship route from the Route
TaskId : 2579425
closesodoo/odoo#96948
Related: odoo/upgrade#3796
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Turn the call to filtered after the search on purchase.order.line
into a call to _search. This allows to remove filtered by adding
an additional leaf in the search domain.
Add read calls to fetch fields from db and store them in cache
on recordset batches.
Example speedup: partner with 136555 POL 6.33s -> 3.42s
opw-3277299
closesodoo/odoo#122218
X-original-commit: b3e81b092864c71a9d5d097fbfa965319acf4fba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@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
After uninstalling the stock module on a database which also has the purchase
(and purchase_stock) module installed, the qty_received_method is removed for
purchase order lines handling the reception of the products through the stock
module (qty_received_method = 'stock_moves'). Because of this, a recompute
is triggered on the qty_received, setting it to zero.
This leaves the purchase order in an invalid state (the received quantity did
not change through the uninstallation of the stock module), additionally the
problem cannot be corrected, since the receiving method is not set to manual.
Functionally, the uninstallation shouldn't update the purchase orders, instead
they should be decoupled from the associated stock moves. To this end, an
ondelete handler is added for the stock_moves selection option.
Steps to reproduce:
- Install Purchases app
- Install Inventory app
- Create a purchase order with purchase lines and quantity > 0
- Confirm the purchase order
- Click on receive products
- Click on validate
- Uninstall Inventory app
- Check that the purchase order lines have the received field set to zero and
it is not editable
opw-3006951
closesodoo/odoo#121549
X-original-commit: cedd0603a24aa0c0e6716c2e0f49e89c870eae04
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Co-authored-by: Pedro Manuel Calheiros Lima de Sousa (peso) <peso@odoo.com>
AttributeError "account.move.line" object has no attribute "purchase_line_id"
occurs in `stock_account` when we confirm vendor BILL or REFUND with product
costing method "first in first out" or "average cost".
With the recent reflacted changes in commit[1], the `purchase_line_id`
field is used and it belongs to `purchase`, but it is not installed and does
not depend, so it causes an error.
The above issue is solved by removing some code in commit[1] from
`stock_account` and adding it to `purchase_stock`.
committ[1] - https://github.com/odoo/odoo/pull/99411/commits/e9ce88a9372843abef7cf8fc94c4dbe5f16c5fa3#diff-e6134a1a5a13058e35f86426a96db0acac44553fa3b0ca26716390f7b19fc96cR318
sentry-3975529425
closesodoo/odoo#121070
X-original-commit: 23ba3c6684e388bcfe317e7ab9f4c9008622e2b4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
Currently, automatically PO is generated in that PO buyer field is empty.
So in this commit, we added buyer field in partner form view, when rfq is
generated automatically and vendor has a specific buyer then at creation
of rfq, the PO buyer field will be set according to that.
TaskID - 3151213
closesodoo/odoo#113709
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a Storable Product “P1”:
- Route: buy
- Reorder Rules: Min 5, Max 0
- Set up a user with only Inventory / User Access Rights
- Using INV User, create a Delivery Order (Delivery 1) so the amount
of Product On Hand is below the Reorder Rule Minimum
--> this will genreate a PO created by Odoo bot
- Using the same INV User, create a new Delivery Order (Delivery 2)
so that the amount purchased on the PO will need to be changed
Problem:
This is done by the user who created the need and not Odoo bot and
as the INV User does not have Access Rights to edit Purchase Order
Lines, an Access Error is triggered.
opw-3255007
closesodoo/odoo#119866
X-original-commit: 32c48924e5045b2cad4f6fda2f0222be0683c22a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
Problem:
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
closesodoo/odoo#119172
X-original-commit: 227d038efbadf25e3a7be7cceedd9159b71162a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Use case to reproduce:
- Set "receive good in input and then stock" on the warehouse.
- Set two suppliers on a product. one from a partner (higher priority)
and one from a child partner (lower priority).
- Set the child partner as the vendor on the replenishment report.
- Order a replenishment for the product.
It happens due to an hack that use a field on `stock.move` in order
to temporaly store the partner among the moves until the RFQ.
But this field is a many2one on `res.partner` model and not on
`product.supplierinfo`
`_run_buy` receive a partner and still use `_select_seller` with the
partner in order to find the best pricelist. But it won't use the
specific supplier price list set on the orderpoint.
In order to fix, we don't store anymore the price list partner on the
intermediate move. In run_buy we receive the orderpoint if it's the
origin of the procurement. On the orderpoint the supplierinfo is set.
So we take it from there.
opw-3180945
closesodoo/odoo#119063
X-original-commit: 3cd5b9b7688ef7e6c6fa4fce1c0ad319fb577745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- route: dropship
- Create a purchase order:
- customer: Azure interior
- Deliver to: Dropship
- Dropship Address: any address
- Receipt Date: Tomorrow
- Product: “P1”
- Conform the Picking
- Go to the dropship transfer:
- Validate the picking
- Go to the Scheduled Action > Purchase reminder
- Run Manually
Problem:
The reminder email for the delivery is sent While the picking is in the
'done' status.
When we run the Scheduled action, the `_send_reminder_mail` function is
triggered in which we get the orders with the `_get_orders_to_remind`
function but we filter the purchase orders which have an "effective_date"
already set:
https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase_stock/models/purchase.py#L279
but as in drop-shipping, the dest location is customer and the
"effective_date" is not set:
https://github.com/odoo/odoo/blob/16.0/addons/purchase_stock/models/purchase.py#L53
opw-3246218
closesodoo/odoo#118507
X-original-commit: 1495b54aa452498c79f4178c2e38426b1b423e66
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
1-create a weight unit 'jm' bigger than reference
ratio 2.47541 rounding 0.001
2-create a stored product uom:'jm' / purchase_uom: 'kg'
3-set valuation method to automated (fifo)
4-create a replenishement for 200 (jm)
5-confirm and recieve the products
6-valuation for that stock move is null
Bug:
computations in the stock module are done with rounding method (half-up)
when computing the unit price the recieved quantity is computed with up
rounding which leads to a mismatch
Fix:
applied the same rounding method on all the Steps
opw-3213997
closesodoo/odoo#118251
X-original-commit: c305942958c73414def47ebd299227999841c6ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
_create_or_update_picking() is a time-consuming method.
On some Purchase, all the purchase.order.line may be written with 'product_qty' in 'values', even though it did not change.
OPW-2978569
closesodoo/odoo#117387
X-original-commit: 5575fe2dedfae2e9d558ca29884d2ebead3c8bbe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
When editing a purchase order line which is not in the company currency
the price_unit on the stock.move is overwritten with the price_unit in
the currency of the purchase order.
Secondary issue this causes is that if any further quantity changes
occur on a purchase.order, any new stock.moves may not be merged. If the
quantity is reduced this results in a negative stock.move quantity which
Odoo helpfully inverses the location and destination locations.
closesodoo/odoo#116620
X-original-commit: e7dfe10c81e69e3eb82b209db25483f29eb557e6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Kit were not reconcile because the `_stock_account_anglo_saxon_reconcile_valuation`
method try to match `account.move.line` and `stock.move` base on the
product field. However in kit case, the moves are exploded in mutliple
moves containing the kit's components. Due to that the matching is not
made.
To fix this issue we use the `purchase.order.line` that is share between
the `stock.move` and `account.move.line` to retrieve them.
closesodoo/odoo#114987
X-original-commit: f594c837c8a347abb48015d4e9bb0d5109228539
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behaviour:
If you have a confirmed SO, with a `sale.order.line` that has a
`product_packaging_id`, and you write a new `product_packaging_id`,
the "Delivery Order" has 2 lines, 1 move with the old qty and the old
packaging, and another line with the difference of qty and the new packaging.
Same behaviour is present on purchase side.
Expected behaviour:
If you have multiple `stock.move.line` from the same `sale.order.line`,
they should be able to merge, when you changed the `product_packaging_id`.
Ex: If you edit an SOL from 1 pack of 10 to 1 pack of 20, we should have
1 move line with qty 20 in packs of 20, instead of 2 lines, one with qty 10
in packs of 10, and another line with qty 10 in packs of 20.
Same behaviour is expected on purchase side.
Steps to reproduce:
- Install Sales and Inventory
- Activate "Product Packaging" in Settings
- Create a new product with 2 types of packaging
- PackOf10 with quantity of 10
- PackOf20 with quantity of 20
- Create a SO with a new line that product, quantity 10
- Confirm the SO
- Edit the SOL with 1 pack of 20 (`product_uom_qty`=20)
- The "Delivery Order" has 2 lines, instead of 1 with the new packaging
Reason for the problem:
When saving the SO/PO, a new `procurement` is created which will create
a new `stock.move.line` with the new packaging. This will prevent the
lines to merge correctly, because they have different packaging.
Fix:
When writing the `product_packaging_id` on a `sale.order.line`/`purchase.order.line`,
we directly write the package on the `stock.move.line`,
before any `procurements` are created, so the generate move lines
can correctly be merged.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3002612
closesodoo/odoo#114866
X-original-commit: 87ed4b2f6c9c36202a1a4f3de143f638cf38d047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
To reproduce the issue:
1. In Settings:
- Days to Purchase: 10
2. Create two products P01, P02:
- Storable
- With the same seller
- Delivery Lead Time: 1.0
3. On replenishment page, create a new line:
- Product: P01
- Min Qty: 1.0
4. Order once
- a RfQ is created and the order deadline is in ten days
5. Time travel to the next day
6. Repeat steps 3-4 with P02
Error: a second RfQ has been generated. However, as the first one is
still in draft state, the POL of P02 should be added to that first RfQ
When processing the orderpoint of P02, at some point, we try to find
an existing RfQ with its order deadline equal to `today + 10 days`.
Since we are the next day (step 5), the order deadline of the first
RfQ is `today + 9 days`, so we don't find it.
OPW-3047931
closesodoo/odoo#113982
X-original-commit: 8bf7f9038915be520488b2602c20929ca115a033
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Version 16.0 removed the price different account following this pull request #99411
This decision has been made because it was only used anymore by standard cost method and real time valuation.
We thought that standard was not a valid accounting method and we didn't want to maintain code for it.
But:
- Standard could be valid if you manualy complete the accounting entries
by yourself (e.g. employees/machines cost in mrp).
- It's also valid if you record the difference between standard price and
vendo price (price diff)
If you want to have an estimation of your cogs (benefits and loss) during an
accounting period. People just do a manual correction at the end but they have
a real time reporting on the situation.
It's a too big regression to be acceptable. We apologize and reintroduce it for
16.0 and future version.
This PR reintroduce the fields in purchase and the fix module in 16.0 is
not needed anymore.
closesodoo/odoo#109924
Related: odoo/upgrade#4315
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase to reproduce:
- Set the warehouse as 3 steps receipt
- Put a security delay of 3 days for purchase
- Set a product with a vendor and 1 days as LT
- Replenish with the orderpoint
You expect to have a schedule date for tomorrow that contains all the
product needed in the incoming 4 days.
Currenly the internal transfer from QC -> Stock is for tomorrow (ok).
The transfer from Inpur -> QC is plan for 2 days in the past. (not ok)
The PO date is plan for 5 days in the past. (not ok)
It happens because the system check at each `stock.rule` application if
purchase is part of the route. If it's then it applies the security lead
time. It's a mistake because we should apply it only the first time.
To fix it we directly set it when the orderpoint run and not during
`stock.move` creation.
However for MTO it's not that easy. We don't want to deliver too
early the customer. So we keep applying the delay during the
`stock.move` creation but only when it goes under the warehouse stock
location.
X-original-commit: 97f52bd40d97109a7983549d252476959ddceada
Part-of: odoo/odoo#112325
Have a product P configured with:
* Product Type: Storable Product
* Product category:
* costing method: standard
* Inventory Valuation Automated
* Price Difference Account: "500000 Cost of Goods Sold"
* Cost $100
Activate Multicurrency:
* USD main currency, CZK foreign currency
* On CZK set the rates
* date1, Unit per USD: 30
* date2, Unit per USD: 25 (date2 > date1)
* date3, Unit per USD: 26 (date3 > date2)
Create a purchase order:
* Date: date2
* Currency: CZK
* Order line:
* Product P
* Quantity 10
* Unit price 3000
Confirm, receive product on date2 (svl needs to be in date2)
Create the vendor bill with:
* Bill date: date 1
* Accounting date: date 3
Confirm the bill
Issue
Check the bill journal items. Price difference account is debited with 4000 czk.
This amount is not correct.
The valuation layer price unit is 100$
At the receipt date the price unit should be 2500czk
The price unit difference 3000-2500 = 500czk
Price difference 500*10 = 5000czk
The issue occur because the price difference unit is converted at bill
accounting date, resulting in 4000czk
opw-3063809
closesodoo/odoo#111199
X-original-commit: bbc0b003f6ff08a50196e07b66083ee7e8896150
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase to reproduce:
- Create a product with real time valuation and AVCO or FIFO
- Create an invoice for this product without stock.move
- Validate the invoice
Traceback
It happens because it tries to check if there is a difference between
the invoice line value and the value of associated stock.move. However
in this case there is no purchase line to do the link.
Since we can't associate a picking to an invoice line magicaly. We skip
this part and let the user do his own journal entries
closesodoo/odoo#110906
X-original-commit: 8ea41cba3911fb8bcc351a4c53d2aa6c5bf7bdde
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Usecase to reproduce:
- Product A with Vendor supplier lead time=1day
- Product B with same Vendor supplier lead time=4days
- Launch the replenishment report for both products at the same time
Current Behavior:
The expected arrival is correct but the order date deadline is today - 3
days
Wanted Behavior:
Same but the order date dead line is today
It happens because it does the minimum of expected arrivals - max of
supplier delays. However the supplier delays are already correctly
apply on each procurement (correct expected arrival). To know the
correct order deadline we should instead take the minimum date planned
with the related supplier delay.
opw-2822588
closesodoo/odoo#110779
X-original-commit: 9364f4fbc3966373a33c32b1325b3b22cc6c5f2e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Setup product (
cost 10$
Storeable Product
Standard Price Accounting
automated valuation
add account for price difference
)
- Purchase product in foreign currency (set a different price)
- Receive the product
- Create and validate Bill
Bug:
The reception JE is for the cost amount set on the product ($10)
debit and credit value are correct but the amount in currency
is wrong (purchase cost)
After creating the bill the Journal items are not correctly matched
since reconciliation is done on currency amount in the case fo foreign
currency transaction
Fix:
Set the correct amount (cost configured on product page)
in currency amount if costing method is standard
opw-2822366
closesodoo/odoo#110628
X-original-commit: 9f5025d99ec490eb2a45b9dbf1a8a43e8fc3162b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*:purchase_stock,stock_account
To reproduce the issue:
1. In Settings, enable 'Multi-Step Routes'
2. Create a product category PC:
- Method: FIFO
- Valuation: Auto
3. Create two products P_compo, P_finished
- Both:
- Type: Storable
- Category: PC
- With a positive cost
- P_finished:
- Vendors: a new vendor V
4. Create and confirm a SO with one order line:
- Product: P_finished
- Route: Dropship
5. Confirm the PO and process the dropship
6. Accounting > Accounting > Miscellaneous > Journal Items
Error: There are a lot of lines and most are incorrect
When marking the dropship SM as done, we check how we should
value it:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L244-L252
Here is one issue: `_is_dropshipped` returns `True`, which is
correct because the source is the subcontractor location and the
destination a customer:
https://github.com/odoo/odoo/blob/8276a9b51b7c5fc0ae6dd557ae88a9c31f1d1962/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L14-L20
However, `_is_out` will return `True` too. To get this value, we
check if the source and destination locations have to be valued:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L99-L100
Again, since the source location is the subcontractor one (which is
an internal one) and the destination location is the customer one,
we will consider that we have to value this SM. As a result, we will
apply `_create_out_svl` and `_create_dropshipped_svl` on the same SM
(this explains some incorrect AMLs are generated).
Then, there is another issue. In `_create_dropshipped_svl`, we
create an in-SVL and an out-SVL for P_finished. However, when
processing the MO, an in-SVL will also be generated for P_finished.
The issue comes from `_create_dropshipped_svl`: it creates an in-SVL
but the source location is not outside from the company, so it
should not create the incoming layer.
Finally, when creating the SVL in `_create_dropshipped_svl`, we use
the unit price of the SM to define the value of the SVL. This is an
issue: suppose the unit price of the POL is $10 and the costs of
P_compo is $1, the unit price of the SM is then $10 (and so does the
value of the SVL) but the actual value of the delivered P_finished
is $11. Howver, when calling `_action_done` on a SM, we first
process it and only then we will process the MO:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L33-L36
So, in `_create_dropshipped_svl`, we can't know the actual cost of
P_finished. This is the reason why we have to create a compensation
layer once the MO is processed (i.e. in the override from
`mrp_subcontracting_dropshipping`)
Similar issues will happen if we return the
dropshipped/subcontracted product.
OPW-3078499
closesodoo/odoo#110390
X-original-commit: 200aac56771fd1ef759f73b277a6808d96ee5f31
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Version 16.0 removed the price different account following this pull
request #99411
This decision has been made because it was only used anymore by
standard cost method and real time valuation. We thought that standard
was not a valid accounting method and we didn't want to maintain
code for it. But:
- Standard could be valid if you manualy complete the accounting entries
by yourself (e.g. employees/machines cost in mrp).
- It's also accepted as legal inventory valuation if you record the
difference between invoice and standard price + regular update of
the standard price to match the reality
- If you want to have an estimation of your cogs (benefits and loss)
during an accounting period. People just do a manual correction at
the end but they have a real time reporting on the situation.
Since delivery/receipt interim accounts already exists we could say
that user could simply reconcile them by himself. It could be but
it would be a pain to know what part of the account is already invoiced
and need a correction vs the part not yet invoiced.
It's a too big regression to be acceptable. We apologize and
reintroduce it for 16.0
This module is a fix module and will not be there anymore in 16.1
closesodoo/odoo#108513closesodoo/odoo#109814
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This reverts commit f1d8f7b43c29342aecb69f233fdd7702b4e4d913.
The previous commit shouldn't been merged to maintain the integrity
of runbot testing. It will be merge soon in the same time than the
migration script
Part-of: odoo/odoo#109814
Problem case :
- Create a product with MTO and Buy route activated.
- Create a Sale Order containing this product.
- Confirm the Sale Order, this will generate a Purchase Order for this
product.
- Go to Alternatives -> Create Alternative -> Select another vendor &
select "Copy products".
The alternative PO won't be linked to the Sale Order, as this link is
done through the relation `created_purchase_line_id` <-> `move_dest_ids`
respectively on the `stock.move` and the `purchase.order.line`.
The only way to enable multiple Purchase Order to be linked to a single
move is to extend the number of `created_purchase_line_id` linked to a
move, hence changing it to a Many2Many relation.
Then, when an alternative PO is created, we link the original PO lines
`move_dest_ids` to the newly created PO lines, which correctly links the
SO and the alternative PO.
closesodoo/odoo#106411
Related: odoo/upgrade#4116
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Version 16.0 removed the price different account following this pull request #99411
This decision has been made because it was only used anymore by standard cost method and real time valuation.
We thought that standard was not a valid accounting method and we didn't want to maintain code for it.
But:
- Standard could be valid if you manualy complete the accounting entries
by yourself (e.g. employees/machines cost in mrp).
- It's also valid if you record the difference between standard price and
vendo price (price diff)
If you want to have an estimation of your cogs (benefits and loss) during an
accounting period. People just do a manual correction at the end but they have
a real time reporting on the situation.
It's a too big regression to be acceptable. We apologize and reintroduce it for
16.0 and future version.
This PR reintroduce the fields in purchase and the fix module in 16.0 is
not needed anymore.
closesodoo/odoo#108736
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In multi-steps receipt, when running a procurement, using "Buy" as
preferred route does not always work because the route is not
correctly configured
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming: 2 steps
3. Create a product P:
- Type: Storable
- Vendors: a vendor V
- Routes:
- Manufacture
- Buy
4. Update on hand quantity:
- -1 at WH/Stock
5. Open the Replenishment page
- There should be a line with 1 x P
6. Set the Preferred route to "Buy"
7. Order Once
Error: a user error is displayed "There is no Bill of Material of
type manufacture [...] Please define a Bill [...]". This is
incorrect, it should generate a PO
The problem is simple: the Buy route is composed of one rule:
- Action: Buy
- Source Location: /
- Destination Location: WH/Input
But, when running the procurement, we first look for a rule to
fulfill the need at WH/Stock. We prioritize the rules of the
preferred route, but as explained above, the route does not contain
such a rule. Therefore, we use the other routes of the product:
https://github.com/odoo/odoo/blob/ba3bb9b701a382c4052ddb57392baeee32625937/addons/stock/models/stock_rule.py#L461-L466
And, because of step 3, it then finds the manufacture rule. This is
the reason why it tries to create a MO and why an error is raised
because of the missing BoM
OPW-3006960
closesodoo/odoo#109302
X-original-commit: 40a20d995d8613d3c82b7a2d62cde80eaad85bad
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Stock moves don't have a `partner_id` if they are created before setting
the picking's `partner_id`
Steps to reproduce (from v15):
1. Create a new transfer with operation type 'Delivery Orders'
2. Add a move, then a delivery address and save
3. Mark as todo and validate
4. Print the delivery slip
5. The warehouse address is printed but it should be the delivery
address
Solution:
Replace `onchange_partner_id` of `stock.picking` by a compute method in
`stock.move`. It assigns the partner_id of the `stock.move` to its
picking's partner_id if the move is part of the picking's
`move_ids_without_package` (in purchase_stock, also check that it is not
a dropshipping)
Problem:
When creating a picking, its moves' `partner_id` is only set if the
picking's `partner_id` was already set in the form
opw-3091139
closesodoo/odoo#107625
Signed-off-by: Tiffany Chang <tic@odoo.com>
William Henrotin