Steps to reproduce:
- Select any two storable product that has invoicing policy set on 'Delivery'
- Create a sales order lines with these two products and make sure that one of the lines should have a quantity set to 0
- Add shipping
Issue:
- The Invoice Status has changed to 'To Invoice'
Solution:
Add en extra filter to consider only lines that have not been invoiced.
opw-2750861
closesodoo/odoo#89548
X-original-commit: bfeb5f6317786edfd0fa464fe5798c7f7bc65ac9
Signed-off-by: yosa-odoo <yosa@odoo.com>
Observed Behaviour
When using a pricelist with a fixed price for all products with a different
currency than the one of the company, adding shipping cost in a sale order
using this pricelist will give a wrong value of the shipping cost
Expect Behaviour
The computed shipping cost added in the sale order should be the same as the
fixed price defined in the pricelist
Reproducibility
This issue can be reproduced using the following steps :
1. Define a pricelist PL1 with a fixed price for all products and a different
currency than the one used in the company (eg fixed price to 15KR)
2. Create a sale order and select PL1 as pricelist
3. Add a product and add a shipping cost
The shipping cost should be the defined fixed price (15KR) but it gives
another value, depending of the company currency
Fix Description
This fix remove a useless currency conversion coming from the fact that since
https://github.com/odoo/odoo/pull/86484 we get the delivery price from the SO
priceliste (using pricelist.get_product_price) giving us a price that is
already converted to the correct currency
Related issue/PR
opw-2810506
closesodoo/odoo#88861
X-original-commit: 25e2f403e88172d67ea6ce382ac1e3f5e0e37835
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
Expected Behaviour
When adding a shipping cost in a SO, with the shipping method being
associated to a product, the price should be calculated according to
the price of the product in the order's pricelist if available
Observed Behaviour
When adding a shipping cost related to a product, with a fixed price,
the public price of the product is used instead of the price defined
in the SO pricelist
Reproducibility
1. Create a product "Test Shipping" with a public price of 10
2. Create a shipping method "Test Shipping" associated with the
"Test Shipping" product
3. Create a pricelist "Test Pricelist", where the product "Test
Product" has a cost of 15
4. Create a contact "Test Contact" associated with "Test Pricelist"
5. Create a So for the "Test Contact" with "Test Shipping" as shipping
method -> Shipping cost will be 10 instead of 15.
Fix Description
The issue here was that the price computed by the delivery carrier didn't
took into account the selected pricelist. We tried to then change it in
the delivery chooser wizard, but some issue with particular case (i.e.
when the shipping cost should be 0 if the SO total is bigger than X)
appeared, leading us to add the fix directly in the delivery_carrier
classe.
Related Issues/PR
- opw-2754482
closesodoo/odoo#87028
X-original-commit: bb778cd7be835706f54e9e0f342eecf3e5e4e904
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
Some fields in the inventory tab of the product
form view had their input widget needlessly stretched
to the maximum available size.
closesodoo/odoo#84056
Task: 2654703-9
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps to reproduce:
- Let's consider a storable product P with HS code
- Create a SO with P and confirm it
- Print the delivery slip
Bug:
The header HS CODE was displayed even if the column doesn't exist in the table
opw:2744000
closesodoo/odoo#83834
X-original-commit: 7f8a6b0accea9ef0d95e4cd613aa7cabdff936d6
Signed-off-by: Simon Goffin <sig@odoo.com>
A modification made by Amazon on October 1st restricts the allowed
values for the carrier name. Since it now expects it in a formatted
state, this commit will allow Odoo to send the delivery type of the
carrier rather than its name, which can be customized by the user.
opw-2665099
closesodoo/odoo#84291
X-original-commit: 0b4530b124d4ac86dad34907c6d6b6e9ea69c7b6
Related: odoo/enterprise#24204
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Shipping insurance is a service which may reimburse senders whose parcels are
lost, stolen, and/or damaged in transit. Since most shipping connectors
provide it, it makes sense to put it in the base directory.
task-2701459
closesodoo/odoo#83896
Signed-off-by: Arnold Moyaux <arm@odoo.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When a package name is a valid SSCC number, we prefer to auto-print the
datamatrix to be used by shippers, which includes:
- the SSCC number
- the pack date (i.e. when it was put in pack)
- the weight of the package (only when less or equal to 6 digits)
Pack date field was added to accomodate this and defaults to when
package is created (e.g. when buying packaged meat at the supermarket,
it's assumed the pack date is when the package of meat was created).
SSCC datamatrix will auto-print now in 3 package reports:
- Package with contents
- Package Barcode (PDF)
- Package Barcode (ZPL)
Note if ability to create datamatrix appears to not work (only in PDF
versions) then standard 1D barcode will be used.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Upgrade PR: odoo/upgrade#3202
Part-of: odoo/odoo#82389
Before this commit, to aaccess some values of the DeliveryPackage
objects, we needed to take the value from the related picking. for
example, for the `payment country code` linked to the package, we need
to retrieve the value from the related picking or order.
To avoid passing too much data to the request objects, it is convenient
to be able to access to the order/picking related to the package
directly from the package.
Because these objects are not children of odoo.models.Model, I do not
need to follow the convention for the names, however, calling the
picking > picking_id in the DeliveryPackage suggests that the picking is
actually a odoo.models.Model child, which should be the case if it
exists.
reference-branch= https://github.com/odoo-dev/enterprise/tree/master-dhl_add_commercial_invoice-goaclosesodoo/odoo#83404
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Each delivery provider, requires some information about the packages
that need to be sent as well as about the commodities (for commecial
invoices). Since this is needed by each provider, and the required
values are very similar, these packages and commodities can be done one
step ahead: in the base delivery module.
These new `_get` functions return a list of custom objects containing
the most important values concerning packages and commodities, and can
be called directly from the child classes.
closesodoo/odoo#82891
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usually we want to create commercial invoices in case the warehouse is in a
different country than the recipient. However, some countries like India
need those documents for internal shipping as well.
The added function can easily be overriden in a dedicated module for the
countries that require such a commercial invoice.
Part-of: odoo/odoo#82084
In saas-15.1 move_lines on `stock.picking` has been rename in
move_ids.
It was miss during #81595 and it's fixed now
closesodoo/odoo#82397
X-original-commit: fd531c7b0baa742cefb7a09c557617806d8a563a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When having a shipper for a DO, if the user creates a backorder, the
information won't be sent to him.
To reproduce the issue:
(Use demo data)
1. Create a sale order SO with 2 products
2. Add Shipping: UPS US
3. Confirm SO
4. In the associated picking, deliver one of the products and create a
backorder
5. Process the backorder
Error: In the chatter, there is a label for the first picking but there
isn't any label for the backorder
When confirming the sale order, the backorder is first created and then
the initial picking is sent to UPS. As a result, considering the current
body of `send_to_shipper`, the field `carrier_tracking_ref` of both the
initial picking and the backorder is defined with the same value (i.e.,
the tracking number of the initial picking)
Therefore, when processing the backorder:
https://github.com/odoo/odoo/blob/f29da79ef64a8166e54544d1787912be5665076a/addons/delivery/models/stock_picking.py#L126-L129
`carrier_tracking_ref` is already defined, so `send_to_shipper` won't be
called
OPW-2678549
closesodoo/odoo#81599
X-original-commit: 89f9281b096e24583ff7780a1bb42f0c4b7b477e
Related: odoo/enterprise#22980
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Have a [TEST] product tracked by serial number
Create a SO with [TEST], quantity N (at least 2)
Add FEDEX int. delivery to the order
Validate and confirm delivery
On the shipping invoice the product is reported on N lines, one for each
serial number, but the price is not splitted accordingly so the total of
the invoice will be the original price multiplied by N
This commit revert f3488749eed3c4e96f1cc50a2bb2cf87b423c890
not needed anymore after
e13f048a78b41d81602e868a3b0c7ded24ce992b
opw-2703581
closesodoo/odoo#81130
X-original-commit: 1ad0e4580814bc5ef76f352ed3ed366654ce69bd
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
Before this commit, `print_label` and `propogate_carrier` fields were
visible despite the delivery methods setting is off.
This commit moved these two fields into delivery module so now these
fields will be visible once the user installed the delivery module.
task-2581265
Part-of: odoo/odoo#74695
Problem : Free Shipping is not translated in delivery
New Behaviour : Free shipping will now be translated
opw-2679727
closesodoo/odoo#79557
X-original-commit: 511bede06788ffb94308dc36d33abadc466a3168
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Steps to reproduce the bug:
- install delivery and sale_management
- Create a product with route "Buy + MTO" and a product with route "Buy"
- Create a SO with both products
- Confirm the SO
Problem:
A traceback is triggered, because in this case, we have two `stock.move`, so two` stock.rule`
therefore, when accessing the `propagate_carrier` field an error will be thrown
opw-2681427
closesodoo/odoo#79539
X-original-commit: 431fc082470df36bc2968f4e51423b41c0c08945
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behaviour :
Product of type service are accounted for when computing the quantity, weight and volume metrics used in the price computation of rule based delivery.
Planned behaviour :
Service-typed product should be excluded from such computations.
opw-2647067
closesodoo/odoo#78402
X-original-commit: 2993c82db51e16787de72cbb67f04d5ae1928b68
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Install delivery and active 'Addresses in Sales Orders' options
- Create a delivery allowed only in France
- Create a partner with two delivery address, one in France, an other in Belgium
- Create SO, select the delivery address in France
- Select the carrier
--> Change the delivery address in Belgium in the partner_shipping_id field,
recompute_delivery_price stay False.
This PR fix this issue, now the delivery is invalidate if you update the field
partner_shipping_id.
closesodoo/odoo#75762
X-original-commit: b53ff03b5cf43c2cd23039b8192f4d90d47e11d2
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit add a quick access to all the move lines of a picking
type (only transfers picking type) ready to be processed from the
Inventory dashboard
Task : 2411102
Part-of: odoo/odoo#63291
- Create a product with a kit BOM and weight
- kit components should have list price and weight as well
- Create SO with kit product
- Add shipping (fedex int. or bpost will do)
- Delivery product
A custom's form is generated but the value of the product it is not
correct as it take the valuation of the kit in the sale order
for every component of the kit, resulting in higher customs taxes for
the final customer
opw-2628309
closesodoo/odoo#75658
X-original-commit: e13f048a78b41d81602e868a3b0c7ded24ce992b
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
If you create an sale order with a section line you see the button add delivery.
closesodoo/odoo#75570
X-original-commit: 1db92688d9e7bf0843edfd248ffef89c38bb66f0
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Hook to be overridden when we need to add some field to product and use it in variable factor from price rules.
closesodoo/odoo#74561
X-original-commit: 6ec768d084da6bd7344c45750a2a5037ec366143
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Added a hook in delivery to check if an Amazon order's delivery is Amazon compliant.
task-2573260
closesodoo/odoo#73494
X-original-commit: eb23d10b22c0cafc935d01effc680aebdbdf0057
Related: odoo/enterprise#19578
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
This commit is fixing two issues:
1: make ribbon translatable
2: display ribbon below smart button
closes#68438closesodoo/odoo#69838
X-original-commit: cbed573e6146a0aab6e0e9114be515a347cd10a4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Beforehand, if two users independently opened a draft
invoice on their respective sessions, then both of them
clicked on the "Post" button, then the invoice was
posted twice.
On a more general aspect, the view currently "prevents" users
from posting moves several times, but technically speaking,
nothing stops users from posting moves several times.
Now, after checking that the user indeed has the right to post
a move, the next check is about verifying that the move is
not already posted.
opw-2479201
closesodoo/odoo#69178
X-original-commit: b7db7db283d7b9d167201b791e6282b022d59c40
Related: odoo/enterprise#17658
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
Currently, delivery packaging and product packaging share the same
model product.packaging. In this commit, we make delivery packaging
a new model stock.package.type. The code is also moved to stock
instead of delivery for compatibility reasons.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
In this commit -
1) Added new field propagate_carrier_id in stock.rule and propgate
carrier in PICK PACK and SHIP if it is ticked.
2) Allow to print Label at any stage of PICK PACK and SHIP after
validation of picking from chatter.
Task-2363484
closesodoo/odoo#62851
Related: odoo/enterprise#15148
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The problem is that the cache still thinks in the test that
it is in EUR and then it does a currency conversion for calculating the
delivery cost and the test will fail in L105 of test_delivery_stock.py
By invalidating the cache after the sql that change the currency of the
company, we solve it.
(someone should refactor those tests though)
closesodoo/odoo#67790
X-original-commit: f0a1e7c35bd8cd17149d1d54bfe5b9eec12a0814
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
For odoo-master Transifex project, no demo data
closesodoo/odoo#66500
X-original-commit: 813931ac850e5ba4181259a5957ec72226fb670c
Related: odoo/enterprise#16510
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Add suport of gift card for ecommerce.
Split the generic part to allow others modules to us it (e.g. pos)
A customer buy 1 Gift Card, he receive a code by mail and see it into the
sale order.
Another customer can now use this code in the payment step to deduce this
amount.
Product Gift card is sold by default without tax, because we don't know on wich
ecommerce, the shipping address ans sot the tax that will be used.
So the tax is deduce from the sale order that use the gift card.
We considere to be in the MPV case from:
https://www.vandelanotte.be/fr/actuel/actualites/624-les-bons-soumis-a-un-nouveau-regime-de-tva-a-partir-de-2019
Courtesy of @bvr-odoo for the email and product image
Co-Reviewed by @rde-odoo and @jke-be
task-2428004
pr-64195
closesodoo/odoo#64195
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Yolann Sabaux