When invoicing from dropshipping picking, choose the correct partner.
Also, change the partner on the picking to be the partner of the purchase.
Change the picking report to include the destination partner or the warehouse address on the right.
[IMP] Only put partner_id on move from purchase when really necessary
[FIX] Default value of partner on stock move should be False
[FIX] Sale should lead to invoicing
[IMP] Journal should not depend on picking type code when in dropship
Make sure drop shipment with invoicing on sale orders only, works.
Also the picking type of dropshipping should be incoming. This
makes it possible to select it on the purchase order. This also fixes#3421.
And we can create a dropship from a purchase only. (not the good way)
For this, we make the invoicing based on the shipment look at the
purchase related and not on its picking type code as the picking type
of dropshipping is changed back to incoming.
The purchase order will also show the customer address when in
a dropship case.
Closes#3421
Value of purchase_order_count and supplier_invoice_count should be coherant with
the behaviour of the button on partner form: count records for the contact of
the company as well.
Fixes#4224
When a warehouse user transfer an incoming shipment, the linked purchase order
is updated as well but the user may not have access to it.
Trigger the workflow as admin instead. opw 619775
For selection fields, name_get calls to resolve the display name are client-side initiated, and will display "Unknown" if the user does not have read access to the selected company. And the reason for using a selection widget in the first place was to prevent inadvertent creation of companies. This is now doable via the no_create option, so we can remove the selection widget.
The warehouse name and address name is often the same (name of the company).
Remove the name of the address as two warehouse may use the same address.
Fixes#4062
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
Without this better floating point handling, an extra stock move might
be created for zero quantity for some order lines upon PO confirmation,
because qty is equal to something closer to e.g 1.14e-13, but this is
larger than 0, so it creates a stock.move, which gets rounded too late
to 0.0
Closes#3346
The delivery of a purchase order was not keeping the currency and cost price
from the purchase order for the reception. This was problematic for orders where
the invoice was generated from the picking (Invoicing Control: Based on incoming
shipments). The currency of the purchase order was kept while the cost was the
one in the company's currency.
It's better to keep the currency of the purchase order to make the invoice as
it's usually the one expected (and not convert everything to the currency of the
company). opw 615555
[FIX] super of scheduler should have same params + use_new_cursor should be passed to procure orderpoint confirm
[IMP] Make sure the delivery works when doing phantom boms
[FIX] This should update the average price properly when having multiple moves with the same product
[FIX] Average price should take into account the quantities of all variants
[FIX] Make sure purchase picking type in other company works
[IMP] Views of quants and destination locations of moves
[IMP] Provide better purchase order picking type
[IMP] Possibly a better product uos handling in the sale order line
[FIX] Recreate of delivery order when sales order in shipping exception
[FIX] Delivery method should be passed to delivery order
Duplicate product filter "To Purchase" and "Can be Purchased". Same search
criteria and same name, so removing one doesn't affect people who were
referencing it (e.g. with search_default_* key in context). Left the one
named "Can be Purchased" because consistent with the equivalent sale filter
"Can be Sold".
Fixes#2718, closes#2864
To allow the on change to set the product default unit of measure when changing of product, and only in this case (not when changing price or quantity)
When generating an invoice from a stock.picking, the reference to the purchase.order.line needs to be kept (e.g. this is needed by anglo-saxon for price valuation). (opw 600767)
[IMP] Add purchase order origin on picking
[WIP] Picking type on move for location on routing
[IMP] Provide extra function for custom buttons on picking
[IMP] Action assign optim
[IMP] Push apply should take invoice_state into account. Propagation of cancel of stock moves should depend on procurement rule
At 96f038a product-related fields were removed due
to an important product.template/product.product
refactoring. As the field values were simply
dropped, they may not be nullified when upgrading an
existing database. Forcing them to False will take
care of it.
When this situation happens. the 'cost' is None and the web interface cannot handle this value, provoking a JS error. Thus, prefer to fallback on the standard way to get the cost: based on the current standard price of the product.
Fixes#1032
Before, the field purchase_ok was set as readonly on the product form if the product wasn't a variant, to avoid users to set all the products variants associated to the product template to be set as purchase able in one action.
We now consider that this can be done by the end user
* remove old 'day', 'month', 'field' and replace them by the actual
date/datetime field
* remove weird cast to char when creating the view to prevent crash
when grouping on them
* remove duplicates (such as 'creation_date' and 'create_date')
* fix typing errors (field type date defined as a datetime in the
postgres view)
* fix search view definition
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
This restriction behavior copied from the sale.order model
Moreover, the purchase.order lines state were not set to cancel when the purchase order was cancelled.
This is now the case, this behavior is also coped from the sale.order model
When the purchase order is reset to draft, we also reset the order lines state to draft