-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
Introduced by f7f18ba5b1
The lang of the customer must be used.
In the drop shipping use case (order.location_id.usage == 'customer'), the customer
is in the destination address of the order (order.dest_address_id).
opw:647628
When a move is creating from a purchase order line and the destination
of the order("location_id") is "customer", the description of the created
move must be the name of the product. To avoid that the supplier description
of the product appears on the customer invoice because in "drop shipping",
the customer invoice line is created with this created move by the function
"_get_invoice_line_vals".
opw:647628
When a product is in "dropshipping" with one supplier and with a few SO
created for the same customer, the origin of the resulting PO must
include all the SO names.
opw:647409
Before this fix, a PO line was set as invoiced if all associated invoices were
validated. This is an issue if the invoice_method of a PO is set on 'picking',
and that only a partial quantity is received and invoiced. Indeed, in this case
it was never possible to meet the condition, and the PO could not be set to
'done'.
After this fix, the PO line invoice state is calculated from the invoice state
of the related moves, if the invoice_method of a PO is set on 'picking'. This
is more logical, and moreover this makes possible to set a PO line as invoiced
as soon as all the related moves are done or cancelled.
opw-644399
When a purchase order line doesn't have a product_id, the current onchange
method would return False as uom_id since b675ff1, thus introducing an issue
since uom_id is required and the field may be not shown (so not changeable).
closes#7770
opw-646088
When a PO is created automatically from a procurement, the fiscal position is
not chosen correctly. We need to choose the fiscal position in the same way if
the PO is created manually or automatically.
Follows commit 1062905acbFixes#3863
opw-643916
Returning `picking_id` can be useful for overrides.
In addition, when there is no return statement,
the method basically returns None.
As this is a public method (not beginning with '_'), it can
be called with an xmlrpc call, and `None` is not an
accepted return value for the xmlrpc protocol.
Closes#1714
Fixes the impossibility to invoice purchase order lines, which were never
invoiced but set to invoiced by validating a first invoice created by invoice
control "manual".
When a PO line is deleted, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
In case of a partial delivery of the products to receive, the procurement is
not considered as done since procurement.purchase_line_id.order_id.shipped is
false.
opw-641503
Canceled lines must be excluded from most of the operations done on a purchases orders.
The check has been done in some places but some of the loops on the order lines do not do it.
This commit correct them.
This is related to revision 65d7cc524d
The `order_line` field of `purchase.order` is readonly within states
aprroved, done. See the field definition. This means it should be
possible to remove lines of a `purchase.order` when the PO is in
any other state than approved or done.
Therefore, the deletion of lines shouldn't be prevented
when the PO is not in state approved or done
opw-634538
Update:
When an existing purchase order line is updated, for example if a new procurement was required,
we check if the sum of existing running linked procurements is larger than the quantity in the
purchase order. If it is the case, we update the quantity and the unit price accordingly.
Without this fix, we systematically add the procurement quantity (or the provider minimum quantity)
to the purchase order line, even if the sum of the procurements is smaller than the ordered
quantity.
Cancel:
When a procurement is cancelled, we recompute the unit price of the associated purchase order
according to the quantity and make sure the provider minimum quantity is met. If the required
quantity is zero, we cancel and unlink the purchase order line.
opw: 632175 and 632176
Make sure the purchase order is marked as invoiced only when fully invoiced.
If the invoices are generated on delivery order (invoice_method picking), make
sure all products are delivered before setting it as invoiced.
opw 614256
When creating a pickign from a purchase order, do not use the schedule date
('date_planned') to specify the creation date ('date') of a picking.
There is already field called Scheduled Date ('min_date') and Max Expected Date
('max_date') that can display this information, this is redundand.
Fixes#4352
After discussing with jco, we decided to keep it simple and have a coherent behavior between different versions, we then changed the behavior from the one of jbefficient PR at 92adf673f7.
The name must be changed when changing of product,
but not for other changes, quantity for instance.
The 'or not uom_id' is just for retro-compatibility concerns
uom_id being False actually means we just changed of product,
and the name must therefore be changed
name as been set as False in the onchange call in the view
for the product_id field, in this rev.,
so the name being False now means th change of product
Nevertheless, existing databases for which the view
is not up to date won't have this change
and we therefore have to rely on something else to know
when the product has been changed or not.
fixes#5295
opw-628138
The seller_id field is a related that is read administrator so it would fetch
the first line, whatever the company specified.
Setting related_sudo=False would not be enough as creating purchase orders
through the scheduler makes the computation done as administrator.
Use the company of the procurement (required) to search for a supplier.
If no result, fallback on the first one as before.
Fixes#3833, opw 618809
This rev. is related to 8381d47543
The action action_purchase_line_product_tree is used in both
product templates and product variants forms.
Therefore, the default_product_id: active_id in the context
cannot be used,
As sometimes it will active_id will be a product template,
sometimes it will be a product variant.
I believe two different window actions should be used,
instead of sharing a common one and making hacks.
Nevertheless, as we avoid taking risks in stable releases
This should be done in master.
Do not write on the function field when you are writing on the function field.
- Now you do know what orders is right?
- I think I know...
- Orders is orders.
- I guess no one ever taught you not to use the word you're defining in the definition.
~~Lucky Number Slevin
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
Goffin Simon
Nicolas Martinelli
Nicolas Lempereur
Christophe Simonis
Daniel Dico
czoellner
sve-openerp
Guewen Baconnier
Olivier Dony
Denis Ledoux
Martin Trigaux
Josse Colpaert
David Monjoie
jbeficent
Jeremy Kersten
Martin Trigaux