When creating a vendor bill from a PO, the payment term configured in
the PO was lost due to function _onchange_partner_id.
When creating a vendor bill, the field payment term was invisibile if
there was no payment term set on the vendor.
opw:744714
Default value is out_invoice aka an invoice of type sale. However here
we would like to test invoices of type purchase. Otherwise extending
tests for specific purchase-related invoice code is not possible. This
is done using the magical context key type.
Closes#15886
In v9 the right filter to use is based upon the message_needaction
field coming from mail.thread . Indeed this gives records containing
messages demanding an action which is the right way to use the
needaction mechanism in 9, like done in all other addons inheriting
from mail.thread.
Closes#16769 .
With the settings:
- Anglo saxon accounting
- real price on product, perpetual accounting,
- multicurrency
- a product with a very small uom (like gram or kilograms and you want to sell many of them, like 500kg)
Flow: purchasing something in another currency
Before this commit, the rounding of the unit price took place right at the conversion level
which led the rounding errors to be amplified by the quantities when the total price was computed
After this commit, the conversion is done on the unit price but is not rounded yet
Only the prices are rounded, as late as possible
OPW 742293
Closes#17015
Let's consider a stockable product P with a product category PC with costing method = real price,
valuation = perpetual, stock valuation account = SVA and price diff account = PDA.
The cost defined for P in product.template is equal to 1$.
Steps
-Create a PO for P with a price unit = 5$
-Confirm PO and generate the invoice
-Update the qty for P in the invoice and validate it(price unit is still 5$)
Bug:
In the general ledger: a move with a debit of 1$ is created for SVA and a debit of 4$
is created for PDA which is wrong. The expected result is: just a move of 5$ created
for SVA and nothing for PDA because the difference between the purchase price and the
invoiced price is 0.
This commit fixes this problem.
NB: in real price and average price, the considered cost must be the purchase price
and not the cost defined in the product template.
opw:740879
- Create a PO with a line scheduled 2017-07-01
- Validate the PO => the expected date of the related stock move is
2017-07-01.
- Modify the PO line date to 2017-07-15 => the expected date of the
related stock move is not updated.
Since we allow the modification of the scheduled date, we should make
sure that the related information is changed accordingly.
opw-741815
Commit 9d4efc8 added the sequence field on model
'purchase.order.line' and added this field in the
tree view (with 'handle' widget), to allow to
re-order the purchase order lines in the purchase
order form view.
However, for this to actually work, the default order
on the model should be on sequence field, otherwise
the rows will still be ordered by id even if the user
changes their sequence value by re-ordering them.
- Create an article with one supplierinfo (with a delivery delay and a
min. quantity > 0) and a customer delivery delay
- Trigger the creation of a PO by a procurement order for this article
The supplier delivery delay is not taken into account in the date order
of the PO because the seller is not selected.
This is because the procurement quantity is not sent to the seller
selection.
opw-16702
Closes#16702
- Create 5 PO with 40 lines each for Partner A
- Create an invoice
- Add each PO thanks to the field "Add Purchase Order"
The process takes more and more time for each PO.
Most of the time is spent in the recomputation of the secondary fields
(in the `onchange` method of "models.py"). The root cause is the cache
invalidation due to the relational fields recomputed as superuser by
default.
opw-740485
When we have purchase orders and we return some products to the
supplier, we now have the possibilty to set those moves as 'to refund'
and so the quantity received is decreased.
Because the feature 'to refund' already exists on the sale orders, we
will generalize it in the module 'stock_account' which is a dependency
of both 'sale_stock' and 'purchase' which are the both module that use
the feature 'to refund'.
- Create 2 companies (A & B)
- Create a product shared between companies
- Add a reordering rule in each company
- Add a supplier for each company
- Run the scheduler (from the cron)
The supplier selected is always the supplier with the smallest sequence,
since it is run in sudo mode.
opw-728346
Olivier Dony