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.
Tests have been migrated to the new api to prepare the migration of the
mail module itself. Moreover tests have been cleaned: redundant tests
and unnecessary tests have been removed.
As the base test class in mail is used in other addons, other addons
have been updated :
- portal
- project
- portal_project
- website_project_issue
- sale
- purchase
Future commits will come with somes fixes for issues detected when cleaning
the tests.
This reverts commit 5f9280e854.
These tests have been introduced in 7.0/saas-3, but can no longer be applied in 8.0, as they uses models that do not exist anymore in the new wms.
if such tests do not exist yet in Odoo 8.0, then these tests needs re-work, they cannot be applied like that
Conflicts:
addons/purchase/tests/test_average_price.py
xmo-odoo