- 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.
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
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
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
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
Before this commit, the uom defined on the sale order line and on the
purchase order line was propagated to the moves. This is not the
behaviour of v8-10 and may confuse the stock operator (one time he's
working in dozen, another time in units for example). It also leads to
rounding issues if the configuration is not adapted correctly (product's
uom is in units, sale order line is in dozen, the rouding precision on
the uom is left to their defaults, now if a dozen is partially available
there's a good chance converting back and forth form dozen to units will
break).
An ir.config_parameter was added to restore the behaviour before this
commit.
Steps to reproduce the bug:
- Create a new RFQ
- When it's in draft state, log an internal note using the 'mail.compose.message' dialog.
Bug:
- RFQ is now in 'sent' state.
The fix allows to inherit from mail_purchase_order_on_send method to change the base behavior.
opw:801549
Use case to reproduce:
- Create a SO with a product MTO and confirm the PO
-> PO -- Stock -- SO
- Cancel the SO
-> PO -- Stock canceled SO
- Set the quotation to draft and confirm it again
-> PO -- Stock
RFQ -- Stock -- SO
- If the user cancel the RFQ we will get this diagram:
-> PO -- Stock
Stock -- SO
The user can't reserve the chain correctly. Also a new RFQ will be
generated each time the user delete the existing one even if the PO
already exists.
It happens because the move keep the procure methode MTO although
the moves origin and destination links are broken.
This commit changes the move destination from purchase order
line to MTS if the RFQ is deleted. This implies that RFQ are
not automatically generated by the scheduler.
When a picking is created from a purchase order, a message is logged in
the chatter: "This transfer has been created from: POXXX: XX$".
Ideally, an inventory user should not have access to the purchase
orders. Sadly, removing the access right brings a lot of access right
issues, so this commit only remove the amount from the logged message
We adapt the name_get that always displayed the total amount of the
purchase order since rev[1], as a message was logged in the chatter when
a picking is created from a purchase order and the message contained this
value.
We implement a context key to display the total amount in the name_get,
as it is used when linking a vendor bill to a purchase order.
[1] 0c618d79ff
Graeme Gellatly