Issue
- Create a Price list and set 'Discount Policy' as
"Show public price & discount to the customer "
- Create an SO
- Add a multiple product with at least one with price unit = 0
- Change the pricelist and update prices
Cause
Division by zero when calculating discount.
Solution
Calculate discount only if there is a price_unit.
opw-2393790
closesodoo/odoo#63218
X-original-commit: 9f70f405bc453ce56b75d22a318c9fd72e8bd496
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a product P with sale UOM = Unit and unit price = 10€
- Create a SO and add a sale.order.option SOO with P and Dozen as UOM
Bug:
The unit price was 10€ instead of 120€
opw:2413237
closesodoo/odoo#62992
X-original-commit: 880555b38dee0c3e3b364c19bb6b0db983bf8aa0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
Steps to reproduce the bug:
- Let's consider a configuration with two languages L1 and L2
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Define a default text T1 and save
- Create a new customer invoice, T1 is displayed in the field narration
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Change T1 to T2 for L1, L2 and save
- Create a new customer invoice
Bug:
T2 was displayed in the field narration
opw:2388353
closesodoo/odoo#62270
X-original-commit: 98d36b80ed1b4f11491301d3b7b5818d81edf542
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
STEPS:
* activate Product Configurator
* create 3 attributes with custom values option
* create a quotation with a product having all 3 attributes and custom values
* select the custom values for attributes in different orders for each SO line
BEFORE: Product description get random order for the custom attributes list
AFTER: Order is fine
---
opw-2379778
closesodoo/odoo#61869
X-original-commit: 57eb05071a08251171dcfdb2308feb13c3281fa7
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Behavior prior to the commit:
- when setting the customer (partner) on a sales order, the sales team
is set based on the partner's sales person. If there is no sales person
on the partner then the team defaults to the first team in sequence for
the company.
- the team set on the partner is not used (by default, this field is not
visible, but it can be set from server action or added via studio). In
Odoo 12.0 the team set on the partner was used as a fallback, but this
was removed in commit 242be00429
Behavior after the commit:
- the partner's team is used as fallback when the partner is updated
- when the salesperson is updated on the quote, we also use the current
team as fallback (since presumably this was set either from the partner,
or using the existing default rule, there is no reason to change it)
- in debug mode, the field `team_id` is shown on the partner view (under
the `Sales & Purchases` tab)
Note:
- Change in existing installation is expected to be minimal since it only
affects the customers who are making use of the partner.team_id field, not
populated or displayed by default, but there is a risk for a customer who:
1. has that field populated on existing partners (maybe upgraded from
an old install where it was displayed?)
2. is relying on the new (as of v13.0) behavior of assigning the default
sales team based on the sequence
opw-2351868
closesodoo/odoo#61827
X-original-commit: 7683e1907f6eb1fde4626927957df4eede49b8ca
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Configure card payment provider (stripe, Authorize, etc) in test mode
Allow the customer to decide if saving payment info
Go to web shop, fill cart and checkout
Select provider and check "save payment method"
After payment the card info is not saved:
the related check variable is overridden in the process.
Note: this occur only when using the provider site.
S2S payment via Odoo follows a different flow
opw-2335237
closesodoo/odoo#61351
X-original-commit: dc18fdba1d4e0d38df0ebce4eed46f8ad08f4821
Related: odoo/enterprise#14597
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Revert "[FIX] sale: correct _get_to_invoice_qty depends"
This reverts commit cfc9abe14689db82acf1872fa8d358662fc7e123.
While the field is indeed in the list of records, it's a big change of
behaviour.
Retroactively changing the invoicable lines of sale.order that are
closed is dangerous and can lead on unexpected behaviours.
Performances can also be bad when changing the product configuration
on a database with a lot of sale orders.
Changing the product configuration should only apply to future orders,
not past.
closesodoo/odoo#61168
X-original-commit: be13bc94c2ff51b99a4399be44a765d0b28202eb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
`product_id.invoice_policy` dependency was missing.
When changing the policy from "delivery" to "order" of a product, the
quantity of invoiceable products was not recomputed and remained 0
Closesodoo/odoo#60674closesodoo/odoo#61026
X-original-commit: cfc9abe14689db82acf1872fa8d358662fc7e123
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create SO 1:
- Section A, sequence 10
- Product A, sequence 11
- Create SO 2:
- Section B, sequence 10
- Product B, sequence 11
- Select both SO
- Create the invoice
The resulting invoice lines are organized as follow:
- Section A, sequence 10
- Section B, sequence 10
- Product A, sequence 11
- Product B, sequence 11
This is obviously not expected as it messes up the organization of the
lines.
This happens because the sequences of the SO lines are kept at invoice
creation, while it is necessary to resequence the invoice lines to keep
them organized.
To do so, we loop on the invoice lines before their creation in order to
assign a sequence corresponding to the order in which they have been
added in the list. Since the invoice lines are added one SO after the
other, this allows us to keep the appropriate ordering.
Note that we only resequence if there are less invoices to create than
SO, meaning that several SO have been merged. Indeed, in case a single
invoice is created from a single SO, there is no need to resequence.
This assumption is not completely true: if not all selected SO were
invoiceable, the number of invoices created is also smaller than the
number of SO. However, resequencing should be safe so in the worst case
we might resequence an invoice while it was not necessary.
We also leave the possibility for third-party addons to alter the
resequencing thanks to the `_get_invoice_line_sequence` method.
opw-2363443
closesodoo/odoo#60789
X-original-commit: 97c2f5ea51a669830b3e6d6d2d7d857742a41481
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
change
Configure taxcloud, 2+ delivery carrier, card payment
Go to the website shop
Add product to cart
Checkout with USA address
On the Confirm Order page, the tax is computed via TaxCloud and shown on the right.
Pay via payment acquirer site
The Subtotal (without taxes) is sent to the Payment Acquirer instead of the Total
This occur because when selecting delivery carrier coupon lines are
recomputed. To be on the safe side with taxcloud, taxes are excluded before
recomputing coupon lines, but never added in this specific flow.
opw-2338103
opw-2362493
opw-2353048
closesodoo/odoo#60570
X-original-commit: f220e66d707654ee76dc343685dee8c2dda68dd5
Related: odoo/enterprise#14351
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Enable discounts on sales order lines
Create a service type product with invoicing based on timesheet and
task in sales order's project
Create so for 6 hours and deliver 8 hours.
Create 2 invoices: One for 6 hours with the regular price and 2 hours
h 100% discount.
Invoice status of the order will be Fully Invoiced
Go to Sales>Reporting>Sales Analysis report will show the untaxed amount
associated with 2nd invoice as still to invoice which is incorrect
This occur because when saving the invoice the untaxed amount is
calculated on the amount invoice after discount
opw-2338564
closesodoo/odoo#59638
X-original-commit: be5ec58d0a1a71fc84ca790555cac02a6be5b67a
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider two pricelist PL1 and PL2 with discount_policy = 'without_discount'
- Let's consider a product P
- PL1 has 10% on P and PL2 has 20% discount on P
- Create a quotation Q with PL1
- Add P on Q (the 10% discount is correctly applied)
- Change PL1 to PL2 and click on Update pricelist
Bug:
The 20% discount on P was not applied.
opw:2352577
closesodoo/odoo#59541
X-original-commit: 9f1280e275fd851fce17bf82c603fdc50a8ef94e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Go to Invoicing > Configuration > Taxes
- Create a Tax and enable "Included in Price" in Advanced Options tab
- Go to Sales and create a Quotation:
* Add an Order Line with the created Tax
- Save & Confirm
- Edit the Quotation to set a delivery quantity, then save
- Go to Sales > Reporting > Sales:
* Display row by "Order #"
* In Measures, add "Untaxed Amount to Invoice"
- Check the values for the create SO
The amount for "Untaxed Amount to Invoice" is the amount with taxes included.
It is due to the fact that untaxed_amount_to_invoice field of sale.order.line is computed
from price_reduce field.
As price_reduce is computed from price_unit, if there is a tax that is included in the price,
price_reduce will also contain the tax in its value.
opw-2347571
closesodoo/odoo#59334
X-original-commit: 8c54ed42eef16817f198f10697820eddcc7d0c74
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
1. Lead to loose the tour: Remove the step of the tour that asks
to set an address (the address is auto-completed at free trial
based on domain name).
2. Bug: At step 3, it redirects to the
invoice settings to select a localization, when you click on
"install more packages", you are sent back to the sales app.
--> this bug is related to res_config_settings.js from base addon.
I tried to fix this bug by adding a data-attribute "discard" in the
res_config_settings_views and checking this additional condition in
the js.
3. Bug: Tour blocks at last step "send by email" on quotation.
After clicking on "sent" on the pop-up, there should be rainbow
effect to mark the end of the tour.
4. Bug: Sale order line: fix the blue color on Invoiced Quantity
only, instead of the full line
5. Put the "sample product" in active= false (it's necessary for
the sample invoice but should not be visible to the user, they
should create their own)
6. Merge the 2 dates fields related to expected delivery on sale.order
--> since other modules extends this module, I made the field
expected_date invisible and put the same value in both fields. This
value is the max of the order_lines.expected_date
closesodoo/odoo#59261
Taskid: 2277314
X-original-commit: 0f81816d4ddb0febd28f6c6bb5dd50ae570333e1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the terms and conditions could not be html formatted text.
closesodoo/odoo#56512
Taskid: 2304199
Related: odoo/upgrade#1689
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Let's consider a product P with three variants red, yellow and blue
- Let's set a customer lead time on P = 10 days
- Set Order Grid Entry on P
- Create a quotation Q and add P
- In the grid entry matrix add 1 red, 1 yellow and 1 blue
Bug:
The customer lead time of these three variants were not set on the lines.
opw:2337049
closesodoo/odoo#58675
X-original-commit: 0eae213d6c8a656ab2c045995e1f0643ff65df51
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
If an user that only has access to accounting but not to sale, tries to
validate an invoice created from a sale order, an access error will be
raised. That's because, when the invoice status changes, the invoiced
quantity on the related sale order is recomputed using the current user,
which may not have access to read sale order lines.
This commit fixes the above by ensuring the recomputation is performed
with superuser access rights.
closesodoo/odoo#58304
X-original-commit: 0bf30e1b5907997ae22d27cc420c3533940d634f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a SO
- Add a line with a lead time != 0, e.g. 7 days
=> the Expected Date is today + 7 days
- Add a note or a section on the SO
The Expected Date is today
This happens because we do not filter out notes and sections when
computing the minimum date.
opw-2340419
closesodoo/odoo#57792
X-original-commit: d3a6afe51fc4b864368acbc40a86ac6974d328dd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a rental product RP with variants
- Configure product configurator
- Create a rental order
- Select RP and set a quantity in the product configurator
- Click on Add
Bug:
When the rental.wizard was opened, the quantity was not taken into account and was reset
to 1.
opw:2321357
closesodoo/odoo#56913
X-original-commit: afe0f0d5566df9bccc28535e85dec98d3c7587b4
Related: odoo/enterprise#12871
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce
Enable optional products in sale order
Make a sale order with optional products for a portal customer
with taxcloud fiscal position. Validate the order.
Tax will be calculated on the sol.
Access the sale order as the portal user.
Add the optional product, verify the order and pay.
The optional product will get the taxcloud data
AFTER the order has been verified and possibly paid. As this should not
occur this add the override to calculate taxcloud data right after
adding the optional product
opw-2310614
closesodoo/odoo#56110
X-original-commit: a7a91d5de55817b7580f3cd3d262a9dcce7496e7
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: agr-odoo <agr@odoo.com>
Currently, if users try to send invoices / quotations / purchase orders to
themselves in order to look at final result, they can't do so because our
default chatter protection prevents sending mails to authors themselves.
This commit uses 'mail_notify_author' context key and allows users to send
mails from the header buttons available on SO / PO / invoices to themselves
if they are in recipients.
This commit targets only those buttons as this is the main case where we
want to allow people to send emails to themselves. In order to avoid
side effects no other use case is supported.
Task ID-2294130
closesodoo/odoo#56370
X-original-commit: 08c0dc929da38595e29a9d1db93065547cd98ad1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
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.*
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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,... )
It was removed here https://github.com/odoo/odoo/pull/32303 but readded
later. We still don't want it for the same reasons.
Having it on related (non stored) is enough.
By specifying the with_company at a higher level:
1) The risk of multi-company conflicts decreases
2) We allow customizations to use _prepare_* methods to potentially
create records in other companies when needed.
closesodoo/odoo#55192
X-original-commit: 33c767e1778d2b1fc83aaaea92c3c2aa008b9520
Related: odoo/enterprise#12105
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The payment.transaction type field allows filtering some potential
payment methods down the line of a transaction being created; e.g. if a
subscription product is present in a quote, the payment's type should be
`form_save` to save the payment token for future use on the subscription
that will be created at confirmation.
The transaction that got created by sale flows did not set the type of
the transaction correctly, and this value was not propagated to the
rendering values of the acquirer. It now is.
This is necessary as part of task 2275051, where we need to know which
payment methods to enable in Stripe depending on a need for tokenization
or not (since some methods are not tokenizable).
closesodoo/odoo#54426
X-original-commit: 09dbbd77d83332c48f62b1c36c3b33ddbfa3a4eb
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
- Turn on Sales Product Configurator
- Create a product template with an attribute and an attribute value defined as "is custom".
- Create a new quote, add the template, and configure the product, entering a custom value.
- Save.
- Duplicate the Quote
Custom value missing.
Cause
Custom value (field product_custom_attribute_value_ids) not duplicated.
Solution
Add attribute 'copy=True' to field product_custom_attribute_value_ids.
opw-2279933
closesodoo/odoo#53827
X-original-commit: 0ca092361819bb198c87ca6772ec0e93a2158018
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Support two new syntaxes with `_()` method:
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. "Foo %s" translated "Foo s%").
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
closesodoo/odoo#52155
Task-id: 1853119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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.
Issue
- Install Sales
- Enable discounts & pricelists
- Create a product
- 2 variants:
- first with "create variant" set to Always
- second set to Never
- Create a SO
- Pricelist setting "without_discount"
- Add the product with product configurator
The line price is not correct (only Always taken in account)
Cause
When the variant has Create Variant set to Never
we pass the extra money in the context.
When we have a pricelist with "without_discount"
this context is not propagated correctly and it's lost
Solution
Pass the product directly if it's not empty which
have the context set.
OPW-2246102
closesodoo/odoo#53216
X-original-commit: 68628206c5883adc614045706fcc2ea085efd252
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Create a SO, Validate it.
Create Invoice: down payment (fixed amount) and validate invoice
Now back to the SO. Create Invoice: Invoiceable lines (deduct down payments).
A draft invoice is created. Try to delete it.
User gets an error, this occur because the second invoice creation bind
another invoice_line to the downpayment sale order line (first line was
added when making the downpayment). When the user delete the invoice
the sale order line should be deleted as well, but is still linked to an
invoice so the error raise.
Unlinking only unbinded sol fix the issue
opw-2258218
closesodoo/odoo#53144
X-original-commit: 7c7275b8a943196975182a8e66cef0e82f87b21d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
current expression implies that any payment of a quote from the portal (/my/quotes) will try to save a token whenever the user says they want the customer to pay online, which seems bizarre. Normally you'd only want that for quotes with subscription products, and there is an override of that method in sale_subscription for that specific case.
closesodoo/odoo#53024
X-original-commit: 47f7230cd38c4e5a2f644a04f87fa0b5a844f73b
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
A sales order on the website will have as salesperson:
- the contact salesperson, and if not set
But if it's not a new address, the "Online orders" > "Salesperson" is
not used.
With this changeset, the "Online orders" > "Salesperson" is used by
default if there is no salesperson on the partner as was the intention.
opw-2274665
closes#52933closesodoo/odoo#52939
X-original-commit: 957361a5c44b3797318657ce2486a3eff2a3f651
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Nasreddin (bon)