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>
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>
If we're to change the invoice policy of a product we'd provoke a
chained computation of every sale line and sale order containing such
product. This change goes along with the policy of applying such changes
only to future orders, as stated here: https://github.com/odoo/odoo/pull/61135closesodoo/odoo#64641
X-original-commit: 806da3d67a5cf9919c6c0f5042b3e00c69825faa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A based on rules shipping method with the "Free if order amount is above" field enabled is not correctly applied.
To reproduce the error:
(Need website_sale)
1. Go to Settings > Website
2. Enable "Shipping Costs"
3. Go to Website > Configuration > eCommerce > Shipping Methods
4. Create a new one
- Select "Based on Rules"
- Enable "Free if order amount is above"
- Set the corresponding amount
- In pricing, add a line
5. Save & Publish (Click on "Unpublished")
6. Go to website's shop
7. Add the product set in the shipping method to your cart
- Select an amount sufficient to exceed the threshold amount set in step 4
8. Process Checkout
=> The shipping method is shown, but the associated amount is "No price rule matching this order[...]"
The shipping method price should be 0.
(This error also happens when creating a SO)
OPW-2383258
closesodoo/odoo#62290
X-original-commit: 393b7ad7b7dff1cbf830374c76ef0a681a71be6a
Signed-off-by: adwid <adwid@users.noreply.github.com>
Fine-tune of #59524.
If the delivery address doesn't have any delivery method assigned, you get an
undesired change of behavior: no delivery method is populated in that cases.
Note that the delivery method is not a commercial field that is propagated from
parent to children.
With this patch, we get a very similar behavior, which is fallbacking to the
commercial partner's delivery method if there's no delivery method in the delivery
address.
The only different behavior will be if the order partner is different from the
commercial partner of the delivery address.
closesodoo/odoo#60881
X-original-commit: 682b2e6c214b73f67e849df927bd4bda0af31d5a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps:
* Create a delivery method (1) restricted to Spain (any country would do)
* Create a delivery method (2) restricted to Madagascar (same)
* Create a partner, main company, whose country is Spain and the default
delivery method is the first one.
* Create a delivery address for that customer with Madagascar as country and the
default delivery method as the second one.
* Now place a new quotation with such partner and set the delivery address to
the one of Madagascar (multiple addresses setting must be on).
Before:
* The delivery method for the quotation is set to the one restricted to Spain
although we're sending it to Madagascar.
After:
* The delivery method for the quotation is set to the one restricted to
Madagascar.
---
opw-2348336
closesodoo/odoo#59890
X-original-commit: 535d429960a0347d01c528c2440c2b8e9ff2fb51
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Ensure that the provider of "The Poste" delivery method is "Based on Rules".
- Create a quotation with "The Poste" as shipping method.
- Confirm, then click on "Delivery" stat button.
- Click on "Put in Pack" and create a "Delivery Packaging".
- Save, go back to quotation and duplicate it.
- Confirm, then click on "Delivery" stat button.
- Click on "Put in Pack".
The "Delivery Packaging" created previously is not available.
Solution
If 'current_package_carrier_type' is equal to 'fixed' or 'base_on_rule',
replace it by 'none' since there are the equivalents in
'package_carrier_type' for 'delivery_type'.
Related fix : https://github.com/odoo/odoo/pull/37427
opw-2310258
closesodoo/odoo#57444
X-original-commit: 5898d31025eacad3e8c37f7a105e20c81831ed17
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
When creating a new delivery method with a provider based on rules, if the base list_base_price was equal to x.8, that ended to a float with endless decimal. (eg: 2.8000000000003)
This fix modify the display to show a rounded value.
closesodoo/odoo#54177
Task-id: 2272472
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit extends the delivery slip so that products added as a kit
component to a stock.picking are grouped together by kit (or non-kit)
when at least 1 kit exists. Kit grouping occurs for products from a kit
without a package assigned. Non-kit section appears only when no
packages are assigned.
Implementation notes:
- Sub-kits (i.e. kits within kits) of kits are purposely not included
- Duplicate product names with different BOMs will be merged into one
since there is no straightforward way to distinguish them within
current db structure
- There are some cases where this doesn't work as expected and may lead
to components being grouped together under the same kit even if they
are from different kits (e.g. kit1 has bolts and so does kit2 => on
slip bolts will only show under kit1 section). Two cases where this
happens is when kits are added before 'Operation Type' is specified
and 'Operation Type = Manufacturing'
This completes subsection 1 of overall Improve delivery slip task.
Task: 2039720
This commit makes it so if a delivery slip contains 1 or more packages
then move lines will be split by package (and non-package) groups with a
"section line" between them. This only applies to when a stock.picking
is 'State=Done'.
In order to accomodate complexity of splitting by package + grouping by
product unless printing serial numbers/lots + template inheritance,
reoccurring parts of the template are split into their own templates and
called. Relevant inheritance has been updated to match.
Additionally, picking.shipping_weight calculation has been updated so if
a pack.weight = 0 then calculation will default to the calculated
product weight. This prevents inconsistency between the "Total Weight"
at the top of the Delivery Slip and the package sections' displayed
weights. To distinguish which value is being used, package sections that
use the total product weight rather than the pack.weight have
"(estimated)" after it.
This completes subsection 3 of overall Improve delivery slip task.
Task: 2039720
This commit makes it so move_lines with the same product+description+uom
are grouped together ONLY WHEN serial numbers/lots are not to be
printed. This is the case when the setting "Display Lots & Serial
Numbers on Delivery Slips" is not active or when there are no
lots/serial numbers assigned in the picking. This is only applicable for
stock.pickings that are 'state=Done'.
In order to implement this, some clean up of lots/serial numbers printing
was also done.
This completes subsection 2 of overall Improve Delivery Slip task.
Task: 2008609
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In case `carrier_tracking_url` is `False`, a `TypeError` is raised and
not catched.
opw-2232268
closesodoo/odoo#49083
X-original-commit: a4b5bd7770bca3f2e4327c65de673e2fcc00e7e5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* Avoid reading all lines invoice_status when the SO isn't confirmed.
* Do not use _default_product_id to discern down_payment lines, use is_downpayment instead
(one ref = one query less by compute call)
* Do not consider display_type lines for SO invoice_status.
X-original-commit: 76a6d0475872f9ffa21cb917f13bc553c720eafd
Before this commit, on a picking, when we want to put in pack, we can't
select packages created with no package carrier type as they had a
confusion between `package_carrier_type` and `delivery_type` when we
pass the value in the context (value who is reused to the package
domain, making some package unfindable).
closesodoo/odoo#46992
X-original-commit: 21f054731e8635b9e3681e673a7cbf627ad49cca
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When a picking is validated with the delivery prices based on rules, you
can face an error, if you are not inventory manager or sales manager.
First, because you don't have access rights to see the sales orders used
to compute the price.
And then you don't don't have access rights on the delivery.price.rule
object to apply the formulas.
As the computation of the price of a delivery should not depends on
access rights other than the ones that let the user validate the
picking, as 'sudo' is called.
OPW-2209148
closesodoo/odoo#46947
X-original-commit: b68139bf2fec8fd2a79e1a578d126f260891c4f6
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- The volume field of stock.picking extended in delivery was unused,
-> remove it.
- The commit 2ff3749064, add
the 'check_packages_are_identical', which is never used.
- Remove useless variable 'res' of print_return_label in stock_picking
task-2201168
closesodoo/odoo#46516
Related: odoo/upgrade#866
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce:
- install sales and easypost shipping
- have a delivery order of multiple packages with easypost
- click "send confirmation email"
previous behavior:
the template does not handle multiple package references
and the associated link is wrong
current behavior:
each reference is set in a separated link
opw-2167037
closesodoo/odoo#45507
X-original-commit: 65eaa3e7daf0b547ae2bb98e335fc5941cb200a6
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
In order to prevent `CacheMiss` errors.
Closes#45242closesodoo/odoo#45550
X-original-commit: 6b5c5124c34245ca93716131c6496d1d4dea72a2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If the shipping weight is changed on a package, we want to update the
shipping weight on the picking to be consistent.
We also want to be able to set a shipping weight on a package that has
no carrier packaging, as we'll use the default one set on the carrier.
Use the 'Volume' decimal precision on all `volume` fields.
Complement of commit c1a5221ba2
opw-2185374
closesodoo/odoo#44473
X-original-commit: dc0111d6cdf4032fa840f9ff95f4fa687d33f77c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a delivery method DM with fixed price of 10€ and a margin of 20%
- Let's consider a storable product P
- Create a SO for P and get the rate (12€) but don't add it on the SO
- Confirm the SO and process the delivery
Bug:
A SO line was created for the freight cost without the margin. So it was 10€
instead of 12€.
opw:2144894
closesodoo/odoo#43279
X-original-commit: 621dac802ddddc3a4dd58f7370250386e1031598
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Since new ORM in Odoo, the compute methods should always return values.
In the case of return label in delivery, nothing was returned when there
was no carrier on picking.
So we are now setting the field to False when there are no carrier on
picking.
ISSUE-43270
closesodoo/odoo#43452
X-original-commit: 9bf52959a5afad01970f1ef39a64d6b3694abcc8
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
length is a reserved attribute in JavaScript, and may cause problems
when returning the object to the JS framework.
This commit is to rename the field.
PR
Task 2152050
closesodoo/odoo#43222
Related: odoo/enterprise#7686
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Set the company currency in USD
- Create a pricelist in EUR
- Create a SO with the EUR pricelist
- Add a stockable product
- Click on 'Add Shipping'
- Select 'Normal Delivery Charges' which has a fixed price
The price is not updated according to the USD - EUR exchange rate.
This happens because no company is set on the delivery method, so no
conversion is performed.
We fall back on the order company, then the current environement
company.
opw-2159838
closesodoo/odoo#43167
X-original-commit: 6a6a7e6e64a7e3727a6de1ca8d35361112d99de8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Using the debug mode on carrier and validate a picking with a
carrier will block and run until request's timeout.
It happens because log_xml create a new cursor and a new environement.
So it should be flush before the ir.logging creation since it's in
another env.
closesodoo/odoo#40561
X-original-commit: cdc09f5b70ad200014ac38f314bf1ec53cd5b8ca
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
When you are adding a line on your sale order that is a delivery line,
the carrier is not always set on the sale order which means that when
the carrier is not explicitly set on the sale order, the carrier won't
be set on picking created from the sale order.
When you are using the wizard on sale order, it works, but when the
carrier is selected on the e-commerce, it is not set on the sale order.
To avoid such difference in behavior, we are writing the carrier_id of
sale order in the function 'set_delivery_line' insread of the wizard and
e-commerce.
closesodoo/odoo#35855closesodoo/odoo#38740
Original-signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
X-original-commit: a15f9921fa1ce92c41c263a8a2c6a32342a8cb1b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
-Create a sales order.
-Add product E-COM11 (invoicing policy "Delivered quantities").
-Add Delivery method "Normal Delivery Charges".
-Confirm Sale.
-Sale Order Invoice Status = "Nothing to Invoice" (OK).
-Now Open Sales Order again in Edit mode.
-Add Choose "Add a note" in the order line section and add a random note and
don't save yet.
-Check the "Invoice Status" in the "Other Information" tab.
Before this commit:
-The status of the invoice changed to "Fully Invoiced".
-If you save the invoice with the new note, the status changes to "To Invoice".
After this commit:
The status stays "Nothing to Invoice" in both cases.
closesodoo/odoo#38097
Opw: 2078581
X-original-commit: 86301d36fa7b0b6f7f524fff2623077c4366273a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When real cost invoice policy is active in a delivery carrier, the
delivery price is set after validating the delivery. When there is
margin, the estimated price is calculated with margin but when the
delivery is validated, the price set in the delivery line does not
include the margin. This commit fixes this behavior by setting the price
of the delivery line with appropriate margin.
closesodoo/odoo#37178
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Be in multi-company, with shared products, let P be a product in company C.
Suppose there are stock moves or pickings in company C'.
Suppose a non-admin writes on P: it triggers an access error.
Stock moves are not shared across companies in all cases.
So fields that depend on product_id might trigger a recompute on stock.moves
that are in another company, and thus trigger a spurious ACL error while
simply writing product attributes.
Note that _cal_move_weight depends on product_qty, however it is not sufficient
to only put that field in compute_sudo; the product_qty has already been marked
as todo, and so it is recomputed in the initial environment.
opw 2066691
forward port of 7d4d8fa18aecb3b78c8d359434a165c1de71a9b4
closesodoo/odoo#36838
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The carrier argument passed to the _create_delivery_line function
can be different to the carrier already existing in the sale order
so we should use the correct setting of carrier where we are calling
the function.
closesodoo/odoo#36424
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If the chosen delivery method has free_over active, and if the cost
of the sale over exceeds the free_over amount, the delivery line
should have price_unit of zero.
When you are adding a line on your sale order that is a delivery line,
the carrier is not always set on the sale order which means that when
the carrier is not explicitly set on the sale order, the carrier won't
be set on picking created from the sale order.
When you are using the wizard on sale order, it works, but when the
carrier is selected on the e-commerce, it is not set on the sale order.
To avoid such difference in behavior, we are writing the carrier_id of
sale order in the function 'set_delivery_line' insread of the wizard and
e-commerce.
closesodoo/odoo#35855
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The user can already send a confirmation email when the
Stock Picking is done. It'd be great to communicate the
same information by SMS.
In addition, the current mailing tool requires a manual
action. The idea is to automate the process via a
Setting instead.
id=1972567
closesodoo/odoo#35662
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
yhu-odoo