Overwrite vendor reference only if there is a PO linked to the bill.
Otherwise, any addition of product will erase what the user just typed.
Closes#26734
Create a PO and assign any string to the Vendor Reference field. Confirm
and create an invoice.
The Vendor Reference field on the invoice is empty, while it is expected
to be filled in.
opw-1879379
- Set 'Product Price' accuracy to 5 places
- Create a PO for a product to a new supplier
- Enter price at 3.14561 / unit
Supplier info entry rounded to 3.15, while it should be 3.14561.
Closes#22253Fixes#22252
Usecase to reproduce:
- Set a product buy and MTO
- Create a SO with it and cancel it
- All the pickings are cancel
- Cancel the PO
- The picking that generate the PO is set to confirm
The picking should remain in cancel state
It happens because the button_cancel method still
consider the canceled moves.
This commit only modify destination moves if they still
require an action from the user.
Canceling the delivery order created for a "Make to order" product
cancels the related procurement.
But canceling the receipt order created for a "Buy" product" with reordering rule
didn't cancel the related procurement. In some cases, it can block the application
of the reordering rules.
Now the related procurement is canceled when the receipt order is canceled.
opw:1845345
The `active_id` when clicking on "Receive Products" on a purchase order
is the one of the purchase order.
But the action used has a context with:
```
{
'search_default_picking_type_id': [active_id],
'default_picking_type_id': active_id,
'contact_display': 'partner_address',
}
```
So the active_id should be a stock.picking.type and not a purchase
order, thus:
- we could get an error at some instance (eg. a refresh) when loading
the facet of the stock.picking.type with the ID of a purchase order
- we could erroneously show a facet for a stock.picking.type with the ID
being the same as the purchase order
So this commit uses the same action without the offending `active_id` in
context.
opw-1870687
closes#26160
Purchase creates an activity when some stock move is deleted.
Howver when two moves are merged "behind the scenes", some moves may be deleted.
As a result it creates an activity "warning: some move has been deleted" for no
good reason.
We add a hook to clean moves before the merge.
opw 1826791
3869cdf7d8 merged a fix which used a
P3-style super call, which is not compatible with Python 2.
While 11.0 is not really exactly officially supported on Python 2,
we originally decided not to break compatibility unless there were
very good reasons to do so.
Due to this commit: https://github.com/odoo/odoo/commit/ab5fcb29650349fa641c6130bf6dcbdc1ec28a07
When confirming a PO with two lines having the same product,
the stock moves were not merged anymore in the putaway
(input to stock) picking.
Reason:
When confirming the PO, odoo creates first a receipt
(vendor to input) picking and its stock moves matching the PO line.
Then it applies the push rule on each move. Both putaway
(input to stock) moves are created by copying the receipt
(vendor to input) moves, but when the second is created,
odoo check if there's another move to merge sharing same
properties to merge into it. As purchase_line_id is now copied
in both cases, both putaway moves include a different
purchase_line_id and won't be merged together, since this field
is in _prepare_merge_moves_distinct_fields() on stock.move.
opw:1854387
Steps to reproduce the issue:
- change the demo user settings -> use Sales: User: All Documents only
- create a stockable product with dropship feature on and a supplier
- connect as the demo user
- create a sales order with this product
- confirm the order
- as the admin user, confirm the purchase order generated through dropship
- connect as the demo user
- open the confirmed SO
- add a line with this product
- save the SO
Bug:
An access rights error was raised.
opw:1866015
When a PO is confirmed, cancelled, set back to draft and confirmed
again, the push rules don't apply because the PO lines have
move_dest_ids. So we remove those move_dest_ids from PO lines, to allow
push rules to be applied on the newly confirmed PO.
OPW-1859363
Usecase to reproduce:
- Create 2 sequence for PO(one for each company)
- Create a product with dropshipping
- Connect on the demo user with an active company different than the
admin company
- Create a SO for this product
It will create a PO with the admin's company sequence.
It happens because _run_buy use a sudo since SO user don't always
have the purchase and inventory rights. However the company is not
forced and thus the used company for sequence is the admin company.
opw-1860802
Let's consider a Sales user U with no access to Purhcase
Steps to reproduce the bug:
- Create a SO with one line with the drop shipping route
- Validate the SO
Bug:
A access error was raised because the user has no access right on
Purchase.
opw:1851301
- Create a product FIFO / Real-Time valuation
- Create a PO with 1 unit, validate, receive the picking
- Create the corresponding vendor bill, but do not validate
- Unlock the picking and change the received quantity to 0.0
- Validate the invoice
A traceback because of a zero division occurs.
When searching for the stock moves linked to the PO, we should filter
out the ones with a zero quantity.
opw-1843543
Steps to reproduce the bug:
- Enable multi companies and multi-currencies
- Multi company: Your Company and Test
- Users: Admin and Demo
- Login as admin user with the current company: Your Company
- Allowed companies: Your Company, Test
- Login as Demo user with the current company: Test
- Allowed companies: Test
- From the admin user with the current company: Test, do the following configuration in the product,
- product: iPad mini, select vendor: Delta PC with price $100 with company: test, currency: USD
- Change the admin's company from Test to Your Company, do the following configuration in the vendor,
- vendor: Delta PC, set supplier currency: EUR and payment terms: 30 Daya Net Payment
- Log in with the demo user
- Create SO for that product by selecting routes: Make to order and Confirm it.
- Open the PO which is generated from this SO
Bug:
The Currency and payment terms were set with the data set for Your Company
Excpected behavior:
Nothing is set for supplier currency and Payment terms as nothing is set for the company: Test
Closes#24564
opw:1841379
The error before this pr could be reproduce with the steps,
- Create two warehouse WA and WB
- Create Route to get: Purchase in WA and transfer to WB
- Create product with Route created before
- Create orderpoint to WB
- Run scheduler
If there is no purchase created the `_run_buy` method tries to create a
PO, but if there is no `group_id`, a traceback occurs.
Closes#24353
opw-1838384
When computing the amount of the anglo saxon entry, if it's a vendor
bill only consider IN move, if it's a credit note only consider out move
(the returns).
opw-1819353
Steps to reproduce:
-Create company A
-Create company B
-Admin user with both companies but currently in company B
-Create Demo user only with company B
-Create fiscal position A to company A
-Create fiscal position B to company B
-Create vendor with fiscal position A with company A and the same vendor with fiscal position B in company B
-Create product and add the vendor created before
-Set like Create a draft purchase order
-Logging with Demo user
-Create sale order with one sale order line with route make to order
-Validate sale order
Bug:
The purchase order created by sale order had the fiscal position company A.
Backport of this commit: 5bb6517072Closes#23561
opw:1825098
Steps to reproduce the bug:
- Create a stockable product P
- Create PO and confirm it
- Cancel the PO
- Reset the PO to Draft and reconfirm it
- Validate shipment order
Bug:
- The "Receive product" button is still displayed but every shipment orders of the
PO have been treated.
NB: The field is_shipped is only used to display the button "Received product".
opw:1838539
Since procurement group is passed by the optional values
in the procurement proccess it should be considered as optional
MPS do not use procurement group because they will add the
planification in an existing RFQ it will fail because purchase search
for the key 'group_id' in values
opw-1833060
Steps to reproduce:
-Create company A
-Create company B
-Admin user with both companies but currently in company B
-Create Demo user only with company B
-Create fiscal position A to company A
-Create fiscal position B to company B
-Create vendor with fiscal position A with company A and the same vendor with fiscal position B in company B
-Create product and add the vendor created before
-Set like Create a draft purchase order
-Logging with Demo user
-Create sale order with one sale order line with route make to order
-Validate sale order
Bug:
The purchase order created by sale order had the fiscal position company A.
Closes#23561
opw:1825098
When you have a receipt in multiple steps and cancel the generated RFQ
the following internal move stay in waiting another operation.
We recompute its state and pass it in waiting.
OPW-1832176
There was no Quality check entry for backorders
when the user did a partial shipment.
We move the logic of the backorder creation to the _create_backorder function.
This function was defined but not called anymore due to a refactoring.
We clean some of its unnecessary overrides which were not used anymore.
opw-1816845
Steps to reproduce the bug:
- Set your company in anglo-saxon
- Create a product P in a category which is in real price and perpetual
- Create a PO with P at 500$ and validate it
- Change the unit price of P in the PO line and set 100$
- Receive the product
Bug:
The two journal entries generated for the goods were created with the price unit
500$ instead of 100$.
Fix:
Now the right price is taken into account to generate the journal entries.
opw:1813946
Use case to reproduce:
- Create a Product MTO that should be buy
- Create a SO with this product and confirm it
- Confirm the RFQ
- Increase the ordered quantity on the SO
- Confirm the new RFQ
- Receive product from the 2 PO
-> Unable to reserve the quantity on the destination moves
It happens because the link between the reception move from the second PO and the delivery move is missing.
Update the quantity on the SO will create a new move with the missing quantity that will generate the new RFQ
then this move is merged in the main move. However the reception move is only created when the RFQ is confirm
and the move_dest_ids is stored on the purchase order line during this time.
Thus merge moves will unlink the new move with its reference on the purchase order line and the link is lost.
This commit do not merge move that have different RFQ/PO in order to avoid losing MTO information.
Nicolas Martinelli