Steps to reproduce the bug:
On a new db, just launch:
./odoo-bin --addons-path=../enterprise,./addons --test-enable -d s11 -i l10n_be,account_accountant,stock,sale_management,purchase
An error occured in test_02_check_mto_chain due to the supplier taxes set on the product.
opw:1878341
closesodoo/odoo#27069
The `price_unit` on `stock.move` is not rounded since it is a technical
field. Therefore, the comparison might fail depending on the rate (which
happens after June 6th because of `base.rateUSDbis`).
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
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.
When creating an extra move, the price_unit field was not copied. It is
normal since the field is copy=False following rev[0].
But there was a side effect: let's say you order 1 product @ $10 and you
receive 5. The received quantity field on the purchase order line is
correctly set to 5 and the valuation inside the stock is correctly set
at $50, but on the picking there is one move line of 5 and a move a 4
and of 1, instead of one of 5. Note that in v10, the pack operation
would be split between the original move and the extra move, but in our
case the extra move is merged back in the original move, so we don't
need to split the move line. The split mechanism is there only when
working with moves without picking[1].
The issue here is that the moves are not merged because they do not have
the same price unit (5 and 0). We thus copy the unit price when creating
the extra move.
When creating a backorder, the price_unit field wasn't copied either.
It's not important when working with the classic flows (the link to
purchase_line_id is kept), but to be consistent we also copy it.
[0] https://github.com/odoo/odoo/commit/a4740861d3fdbecc8b1171b7d2072697e8a36258
[1] https://github.com/odoo/odoo/commit/561b3461a020021d911999cb41154f158b069a1d
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.
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.
It is possible that the price unit the move was created with is no
longer valid (for instance, one could change the price unit on the
purchase before validating the receipt, or the currency rate has changed
in the meantime).
Fixes#20035
The rationale for the need of a merge move mechanism is that, with the new default view,
having multiple stock move for the same products is confusing. The idea is that if a move
is confirmed in a picking already having a move with the same characteristics, we update
the existing move and unlink the new one. That’s why it’s done at the end of `_action_confirm`.
In some cases, merging moves is unwanted (backordered moves for examples). Therefore, we chose
to add a kwarg to `_action_confirm` in order do control the mechanism.
Previously mrp, stock and purchase used _run methon on procurement
group and start with a if checking for the action type. This commit
instead launch a specific method depending the rule's action's type
Also _run method and their submethod used in procurement group
was always called with a rule. Thus we choose to move this method
on the rule object himself.
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
When deliver all at once on a picking the expected date for it
was the minimum expected date between the stock move
for this picking. (same behavior as partial delivery)
This commit merge both min_date and max_date field in a single
field named shceduled_date. It replace min_date in views by
sheduled date that varies following picking move_type.
The new implementation of stock moves the cost of products from quants to
moves. So we have implemented the FIFO and average cost method based on
those moves instead of using quants.
- When average price is choosed, a field average_price is set on the
product.
- The tests have been completed with an example of how fifo work with
negative stock.
As the use of real price method is really rare, because of the rigor
required on traceability for such method, we removed this functionnality.
- The tests purchase/test/fifo_price.yml have been adapted to use the
FIFO costing method instead of real price.
The old report stock history doesn't exist anymore, and is replaced by
the move view that contains all the cost information.
The methods `get_price_unit` have been moved from the stock to
stock_account.
The methods `_set_default_price_moves` and
`set_default_price_unit_from_product` have been removed from stock.
Explaination of FIFO and average:
- In action_done for an out move in average and fifo, the price_unit and
stock_value are updated.
- For FIFO, it will use the qty_remaining on the in moves to check from
which in moves to take the stock values for the out.
- In case of negative stock in FIFO, it puts also qty_remaining on OUTs.
- In the case of average, it will take the cumulated value of the last
move and divide it by the quantity in stock.
This commit is pretty much a 'work in progress':
- Edit 'done' moves when the costing method is FIFO doesn't trigger the
replay the FIFO stack.
- The landed_costs feature doesn't work.
This commit adapt purchase to be able to edit purchase line ordered quantity
and propagate it to the related picking after the request for quotation
validation.
These are the supported use case
- When you increase the quantity on a purchase line, an extra move (and
an extra picking if they are all done or canceled) is created with the
difference between old and new value and the push rules are applied on
it.
- When you decrease the quantity of a purchase line, different behaviors
can occurs:
* If you plan to decrese the ordered quantity under the received
quantity, you get a user error saying tht you have to make some
return before.
* Else the moves not done or cancelled are decreased by starting with
move having no procurement_id. The decrease is not propagated
through push or pull rules.
* If you decreased the quantity under the invoiced quantity, a next
activity is created to remind you to do a refund.
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 a PO with a product "Control Purchase Bills" set to "On
received quantities".
- Validate the PO.
The invoice status is "Waiting Bills", while it should be "Bills
Received".
opw-726245
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
=======
Purpose
=======
There are some confusion about the use of the vendor price and the cost price.
Moreover, in the purchase app, the RFQ should take the variant vendor price, if one is set
==========
Specification
==========
Add a clear tooltip on the Cost field (standard_price) : "The cost price is used for valuate stocks or to asses the price of manufacturing a product. The purchase orders are fetching the vendor prices."
In the simplified view, add the vendor cost o2m : https://drive.google.com/a/openerp.com/file/d/0BxqHe5rtIxY0LVZHZXFWcWFHckk/view?usp=drivesdk
Variant vendor prices should be indenpendant from each other, and from the template ones.
In the purchase app, when creating an RFQ : the system fetches the variant cost price (from vendor o2m), if no price on variant, it takes the vendor price on template.
NB: fp request
When we enable in the settings 'Get 2 levels of approvals' with a
'Double validation amount', and then create a request for quotation.
When we confirm it, even if the total amount of the request for
quotation is below the amount set in the settings, the purchase order
needs to be approved.
We excpect that if a purchase order has a total amount below the
validation amount setting, the purchase order is automatically
confirmed.
So to fix it, we compare the amount when the user click on the button
confirm. And immediatly call the function 'button_approve' if the amount
is below the double validation amount set in settings.
Bug introduced in rev: https://github.com/odoo/odoo/commit/9d4efc81a
opw - 694381
Case 1: To check order date of purchase order and schedule dates of shipment and purchse order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a company level set Purchase Lead Time
Case 2: To check order date of purchase order and schedule dates of multiple purchase order line of the same purchase order,
we create two procurements for the two different product with same vendor and different Delivery Lead Time
Case 3: To check order date of purchase order and schedule dates of shipments and purchase order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a route level set delay of push rules
Detailed Use Cases
==================
Consider today's date = 2016-04-21 ( date_planned of procurement = today's date + 10 days)
CASE 01:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Configure your company data
---------------------------
Purchase Lead Time : 3.00 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 15.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-23 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 02:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Create another Product
----------------------
Name : Product B
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 2 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 10.00
Planned Date: 2016-05-01 00:00:00
Procurement Request for second product
--------------------------------------
Warehouse : YourCompany
Product : Product B
Quantity : 5.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-26 00:00:00
Schedule date of purchase order line for product A: 2016-05-01 00:00:00
Schedule date of purchase order line for product B: 2016-04-28 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 03:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Incoming shipments : three steps
Routes
------
YourCompany : Receipt in 3 steps
Push Rules:
-----------------
WH: Input -> Quality Control :-- Delay : 2 days
WH: Quality Control -> Stock :-- Delay : 2 days
Create Procurement:
-------------------
Product : Prosuct A
Quantity : 5.000
Warehouse : YourCompany
Procurement Location : WH/Input
Schedule date : 2016-05-01 10:30:43
Notes : 'Test scheduler for RFQ'
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-05-01 10:30:43
Order date: 2016-04-26 10:30:43
Incoming shipments schedule dates :--
In type :-- 2016-05-01 10:30:43
Internal type 1 :-- 2016-05-03 10:30:43
Internal type 2 :-- 2016-05-05 10:30:43
Case 1: To check order date of purchase order and schedule dates of shipment and purchse order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a company level set Purchase Lead Time
Case 2: To check order date of purchase order and schedule dates of multiple purchase order line of the same purchase order,
we create two procurements for the two different product with same vendor and different Delivery Lead Time
Case 3: To check order date of purchase order and schedule dates of shipments and purchase order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a route level set delay of push rules
Detailed Use Cases
==================
Consider today's date = 2016-04-21 ( date_planned of procurement = today's date + 10 days)
CASE 01:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Configure your company data
---------------------------
Purchase Lead Time : 3.00 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 15.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-23 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 02:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Create another Product
----------------------
Name : Product B
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 2 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 10.00
Planned Date: 2016-05-01 00:00:00
Procurement Request for second product
--------------------------------------
Warehouse : YourCompany
Product : Product B
Quantity : 5.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-26 00:00:00
Schedule date of purchase order line for product A: 2016-05-01 00:00:00
Schedule date of purchase order line for product B: 2016-04-28 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 03:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Incoming shipments : three steps
Routes
------
YourCompany : Receipt in 3 steps
Push Rules:
-----------------
WH: Input -> Quality Control :-- Delay : 2 days
WH: Quality Control -> Stock :-- Delay : 2 days
Create Procurement:
-------------------
Product : Prosuct A
Quantity : 5.000
Warehouse : YourCompany
Procurement Location : WH/Input
Schedule date : 2016-05-01 10:30:43
Notes : 'Test scheduler for RFQ'
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-05-01 10:30:43
Order date: 2016-04-26 10:30:43
Incoming shipments schedule dates :--
In type :-- 2016-05-01 10:30:43
Internal type 1 :-- 2016-05-03 10:30:43
Internal type 2 :-- 2016-05-05 10:30:43
The function field selected_seller_id is removed and must be replaced
by a direct call to method `_select_seller`. This is more conventional
than the previous 'browse with context' way of doing.
add the stock_journal property in the yml test and make python test depends from AccountingTestCase to prevent errors when launching these test without a localisation. Also raise error in code if no stock_journal is found.
-account:_fix_tax_included_price
If a fiscal position mapped an included tax on a SO or on a PO line
then the price unit of the product must be recomputed.
-purchase: onchange_product_id test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
-sale:product_id_change test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
opw:647321
code improvement
code improvement
payment_method to payment_method_id
writeoff_account to writeoff_account_id
property_account_receivable to property_account_receivable_id
property_account_payable to property_account_payable_id
property_account_expense_categ to property_account_expense_categ_id
property_account_income_categ to property_account_income_categ_id
property_account_expense to property_account_expense_id
property_account_income to property_account_income_id
property_account_expense_categ fix
sale_tax to sale_tax_id and default_sale_tax to default_sale_tax_id
purchase_tax to purchase_tax_id and default_purchase_tax to default_purchase_tax_id
ref_companies to ref_companies_ids
property_account_position to property_account_position_id
property_payment_term to property_payment_term_id
property_supplier_payment_term to property_supplier_payment_term_id
bank_accounts_id to bank_accounts_ids
payment_method fix after rebase
user_type after rebase
payment_method fix after rebase
after rebase
invoice to invoice_id
fix payment_method_id after rebase
code improvement
[IMP]user_type to user_type_id
[IMP]property_stock_account_input_categ, property_stock_account_output_categ to _id
[IMP]improve after rebase
[IMP]fix type
[IMP]Account: code improvement
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Goffin Simon