Steps to reproduce:
1- install sale, accounting
2- create a fiscal position fp that maps
tax inc t1 to any other tax t2
3- create a delivery product dp with t1 and mark it "can be sold"
4- create a new delivery method with dp
5- in a new sales order, choose fp, click on add delivery
6- the unit_price is wrong, it hasn't mapped t1 to t2
7- try adding the delivery as a product in a new sales order line
8- the unit_price is correct and the taxes are correctly calculated
Bug:
`_create_delivery_line` is not using the same logic used
when normally adding a sales order line although technically
delivery product is still a product
Fix:
use `_get_tax_included_unit_price` to get the correct unit_price
OPW-2806965
closesodoo/odoo#96874
X-original-commit: 03bb18d12606447faaed0de04bb83dde5de53b96
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
This commit does a couple of small related improvements:
- adds new delivery options: "Local Delivery".
We replace the existing "Normal Delivery Charges" with the new "Local
Delivery" since it is now redundant.
- Originally a "Local Pickup" demo option was going to be added, but
this appeared redundant with the "[On Site Pick]" added in
odoo/odoo#87636 . Regardless, an additional `carrier_description`
field has been added so users can include extra instructions (e.g.
address to pick up from, when pickup can occur, etc) to sales orders/
confirmation emails (emails only via ecommerce sales).
- adds option to filter based on zip prefix rather than the previous zip
"range" option, which was too restrictive in some cases (e.g. in the
UK where zips can have letters in them). Note that users can view/edit
zip prefixes in menu under settings when debug mode is active. Note:
- prefixes are ordered by name so its easier to read large numbers
prefixes
- prefixes are always capitalized to avoid duplicate prefixes that
differ by case + avoid capitalizing all prefixes every time the
`_match_address` logic is called
Task: 2706451
Upgrade PR: odoo/upgrade#3384closesodoo/odoo#84620
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commodity now uses product county of origin code instead of
country of origin field directly since its a res.country model
and breaks the request if set on a product
closesodoo/odoo#93195
X-original-commit: 980d103050fee552a9f68421cf119c119397bbe2
Signed-off-by: Arnold Moyaux (arm) <arm@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>
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>
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>
- 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>
Now we hide the generate return label if this option is not available for the current carrier.
Before this fix, we could set the field to true even if the option was not available for this particular carrier.
Task-Id: 1956970
closesodoo/odoo#35178
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Clicking on 'install more providers' should only show module of external
carrier. In the previous domain, we get delivery_barcode and
website_delivery_ups in the domain which is not intended.
Task: 1942231
Co-Authored-By: Hetal Dhanak <hdh-odoo@users.noreply.github.com>
The commit 9a9cb9e refactored the way delivery carrier price
are added on sale orders. The management of free delivery price
was not taken into account past then.
This commit put the free price message directly on the sale order line
and on the wizard. The carrier price is showed on the wizard but is 0 on
the SO.
Task : 1943480
closesodoo/odoo#31315
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Some customers need to have a float instead of a in for the percentage
of the margin taken on the delivery. So we modified the integer value
into a float.
Until now, only fedex was providing return label printing, and as we
want to integrate it with other carriers, we have mande a generc
mecanism to easily implement it with new ones.
We've also added an option that allow to print return label from portal
if one has been generated on delivery.
The delivery carriers get a new field to specify the invoicing
policy. The two cases are :
- Estimated cost: the delivery price is charged directly on
the sale order based on the estimated fee
- Real cost: the delivery price is estimated from the sale order
but not added in the delivery line (we get a line with quantity=1 and price = 0).
Once the delivery is validated, the delivery price is recomputed.
The new price depends on the integration level. If it's 'rate', the price is
the estimated one (carrier.rate_shipment()). If it's 'rate_and_ship, the price
is the one given by the carrier at the delivery
The bases carriers (fixed_on_rule and base) always use 'Estimated Cost'
as their price should not be changed between the sale order creation
and delivery validation
Task : 1908654
Go to 'delivery methods', edit a delivery method.
Click on 'install more providers'.
You land on the 'Apps' app, already filtered on the 'delivery_' modules.
Click on 'more info' of a module: nothing happens.
It should open the form view of the module.
What happens is that the action doesn't contain 'form',
so the framework fails to open the form view from the kanban view.
opw 1928711
closesodoo/odoo#30437
After removing the company from a delivery method, every checkout done
in website fails due to odoo trying to convert the price to the
company currency.
This PR fix the bug by doing the conversion only when there is a
company set on the delivery method.
opw-1905466
closesodoo/odoo#28626
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
With a fixed price delivery method, the error message was not displayed when
the address doesn't match.
Inspired from function base_on_rule_rate_shipment
The error message was not clear enough.
opw:1879204
In this way the name of a delivery method can be translated on a SO line.
Inspired from function 'product_id_change' in model 'sale.order.line' where
the description of a SO line must be in the language of the partner.
opw:1849656
Steps to reproduce the bug:
- Set your company currency to USD
- Set multicurrency on your user
- Create a delivery method with a fixed price to 50$
- Create a SO with a pricelist in EUR
- Set the delivery method and check the price
Bug: It displayed 50€ while this amount should be converted
opw:1817666
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
momegahed