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
Purpose
=======
Currently the discount mechanism is not implemented in the purchase module.
This limitation is could be avoided if the _compute_amount arguments could
be overwritten.
While waiting the feature to be implemented in master, we simply introduce
a hook method to allow an easy inheritance of the argument values.
Closes#11235
PS: Also move compute methods under the fields definition to follow
the coding guidelines
The action 'account.action_invoice_tree2' has been changed into a server action, so we want to open the tree view of invoices by modifying some values of the action we should now use the xml reference 'account.action_vendor_bill_template'.
Additionally, the help tooltip is now completed as would do the server action
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
purchase_requisition install stock, but when doing services you might
still want the option. This option was only display when stock
is installed. This commit changes this to make it visible when
purchase is installed.
The option is better visible and installing a new apps, then
hidden (or difficult to find).
Purpose
=======
The method _name_search and _search add support to search as another user.
All the overrides of name_search and search redefine the behavior of the search.
This bring inconsistencies as the result of a call to _name_search and name_search
could differ on certain modules, which is not acceptable.
Specification
=============
Example:
~~~~~~~~
If the name_search method is overridden to search also on the driver name,
then calling name_search with a label 'JF' will return all the cars with a name containing
'JF' or all the cars with a driver name containing 'JF'. Let's say that we have a ir.rule
preventing a user to read the cars of another company. Then the call to name search only returns
the cars satisfying the previous condition AND belonging to his company.
Now, we want to overpass this constraint. We call _name_search with the attribute name_get_uid=1.
Then the call to _name_search returns all the cars from all the companies with a name like 'JF',
but nothing is done about the driver_name.
Example of wrong search redefinition on a model
-----------------------------------------------
@api.model
def name_search(self, name, args=None, operator='ilike', limit=100):
domain = args or []
domain = expression.AND([domain, [('name', 'ilike', name)]])
partners = self.env['res.partner'].search([('name', operator, name)])
if partners and name:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partners.ids), ('driver_id', '=', False)]])
rec = self.search(domain, limit=limit)
return rec.name_get()
Example of correct search redefinition on a model
-------------------------------------------------
@api.model
def _name_search(self, name, args=None, operator='ilike', limit=100, name_get_uid=None):
domain = args or []
domain = expression.AND([domain, [('name', operator, name)]])
partner_ids = self.env['res.partner']._search([('name', operator, name)], access_rights_uid=name_get_uid)
if partner_ids:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partner_ids), ('driver_id', '=', False)]])
rec = self._search(domain, limit=limit, access_rights_uid=name_get_uid)
return self.browse(rec).name_get()
The same logic should be applied on the overrides of the search method.
We want to break the dependency between stock and purchase
for our furtur developpement. For more modularity, a new
bridge module 'purchase_stock' is created.
This commti move part of business code, views, data, ...
related to stock management from purchase into purchase_stock
without changing any feature.
Task #47927
Before that, the following scenario (tested in purchase/tests/test_anglosaxon_valuation_reconciliation.py) failed:
- create a PO
- change of currency rate
- create and validate vendor bill in foreign currency
- receive goods
- change of currency rate
- return the goods
- change of currency rate
- refund the bill
At the end of it, both invoices (bill and refund) were not in 'paid' state, but they should have been! The anglosaxon stock valuation code had some issues in the way it managed currency rates. The main one was that we converted the computed valuation_price_unit variable in company currency using the date of the invoice as a reference, which was wrong in case the invoice was a refund, as it should then use the date of the valuation for this. This problem caused the code to detect an exchange rate difference between refund and valuation as a price difference, hence generating a line in the price difference account, which caused the debtor account line of the associated account.move to be wrong, and hence impacted the residual field of the invoice ("amount due", in GUI). Finally, as this field contained an inconsistent value, the refund invoice was not marked as paid after reconciling it with the original one.
Solving this needed to refactor the code quite a bit, so that we don't convert everything in invoice currency in the end, but rather do it directly everytime we compute a part of valuation_price_unit. The test had also to be partly re-written as it was too naive in the way it used currency rates, we needed something closer to a real utilisation of the program.
On purchase orders, the scheduled date is mantadory. This date is computed from
the purchase order lines and hidden. If there is no purchase order line, the date
stays empty and it's not possible to save the PO.
This commit uses the order date as scheduled date if there are no PO lines
Before that, the following scenario failed due to FIFO handling of stock:
- make PO 1 for 10 x product A at 10€/piece, receive and invoice everything
- make PO 2 for 10 x product A at 20€/piece, receive and invoice everything
- refund and send back PO 2
=> With FIFO handling, it means the valuation corresponding to the return of product A consists of the first received products, hence 10x10=100€. The credit note, though, was made with the price of the invoice (200€) and did not (because of a too simple check) use the price difference account to post the missing amount (100€).
Test test_fifo_anglosaxon_return (purchase/tests/test_stockvaluation.py) failed because of that.
- 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
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
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
This adds the possibilty to select another account.invoice object in a vendor bill or credit note, to automatically copy its lines.
When the purchase app is installed, the same field can be used for auto-completion and users can choose between vendor bills or purchase orders (preferably PO)
Co-authored-by: dat@openerp.com
Christophe Simonis