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>
This commit keeps the sales related fields together in a contact form view
by moving 'property_delivery_carrier_id' field at last, instead of after
'user_id' (Sales Person).
Task Id : 2445997
closesodoo/odoo#65030
Related: odoo/enterprise#15946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
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>
Purpose of the task, is to prevent users from inadvertently
creation/opening countries from country_id fields.
Countries should be managed from their dedicated menu item.
so in this commit, we have set both no_open and no_create to True
so user should not update and create a country from the many2X fields.
closesodoo/odoo#63773
Taskid: 2241677
Related: odoo/enterprise#15464
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since commit https://github.com/odoo/odoo/commit/3ad4abe171e8e7e86ed0e7b7f000e734d8a2ad92
the default invoicing policy of a product is set to 'delivery'. This is
not ok for the delivery products: a delivery product is never delivered.
This is confusing to end users, because they do not realize that a
delivery line is not included in an invoice. This is especially true if
the delivery is free.
This commit sets the default policy to 'order' for master data and for
newly created products from the shipping form view.
opw-2387437
closesodoo/odoo#62357
X-original-commit: 4c2768846809f6687d03eb0d7f501e57c2c93a90
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
Because the barcode app bypasses the detailed operations for receipts
(with default settings set), an error was being thrown when doing "put
in pack" when a carrier is set (saving during the delivery package
wizard) because the picking move lines are incorrectly selected. This
commit adds in a check for when the wizard is accessed via the barcode
app so that the error does not occur and the same behavior as when no
carrier is assigned is followed.
Related Enterprise PR: odoo/enterprise#9808closesodoo/odoo#59792
Task: 2039720
X-original-commit: 945b5f6791ae890498ef9a34828eaf91dc1457e2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
"Print Return Label" button on a Transfer is showed when `is_return_picking` field is True.
But `is_return_picking` is True for any picking that is a return of another picking, making
the button visible for the return of a return, when it should not as it is an outgoing picking.
opw-2312425
closesodoo/odoo#59387
X-original-commit: f54f485cc6b0eb6c25a2753ca2c764a32eb18f66
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@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>
This commit sets up the logic and adds the button for "Put in Pack"
action that already exists in stock.picking. Reuse/extension of logic
from stock.picking reused where possible, including extension of pack
wizard to handle products with different destination.
Note that logic to handle "Delivery Packaging" wizard when "Delivery
Methods" is active was purposely not extended to work correctly in batch
pickings due to complexity of adding in a new module just to handle
conflicting carrier_ids across pickings in the same batch. It is
expected that this use case will not occur except in case of user error.
Additionally, stock.picking implementation of 'put_in_pack' method has
been renamed to 'action_put_in_pack' to have consistent naming (and
support enterprise level code).
Part of "1. Improve Batch Pickings" specification of overall barcode
improvements task.
Task: 1884520
Enterprise PR: odoo/enterprise#12086Closes: odoo/odoo#55096
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.*
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
When a fields default value depends on another default, this value
should be computed in a default_get override, not in a default method
specified on the field itself.
Furthermore, the management of default_ context keys() should be left to
the orm level (better code understanding, localizing a behavior in one
place instead of multiple places).
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>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
closesodoo/odoo#54444
--task: 2296213
Related: odoo/enterprise#11833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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.
Florian Damhaut