Each order does necessarily have the same confirmation template.
And `_get_confirmation_template` is `ensure_one` so it raises when self holds multiple records.
closesodoo/odoo#128743
Forward-port-of: odoo/odoo#128551
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Previously, customers were not allowed to sign a draft quotation.
We consider that if the customer has access to the quote, he should be able to sign/pay it (instead of getting some strange feedback that the order is not in a state requiring signature/payment)
task-3340541
closesodoo/odoo#124486
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When creating a Vendor Bill, the default Sales Team & Person of the company is
assigned to the Vendor Bill. The field isn't even displayed, it's hidden, you
can only display it with Studio and can't even change it.
The fact is : purchases and sales are two completely different roles and
business in companies. This has the indirect consequence that any user that
follows the default Sales Team will get notified of any new Vendor Bill created
in Accounting, which he very likely does not need/want to see.
This PR correct that by adding a condition on the filling of these fields. These
fields will be filled when the move is a sale document.
closesodoo/odoo#120628
Task-id: 3279233
Related: odoo/enterprise#44034
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Since 7bd93cc64b, we add the amounts to
invoice from sales order to the credit limit warning. When looking at
the credit amount on a partner from an accounting perspective, it is
not correct though that sales orders to invoice are considered as well.
In this change we split the credit amount from invoices and from sales
orders to invoice. On the partner we only show the credit amount from
invoices. In other places we add both.
task-3375260
closesodoo/odoo#128158
X-original-commit: 94eae9b73995dbf2175ecee65548ace5a382f5f8
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Issue:
The `_compute_amount_to_invoice` computation wasn't taking
into account the fact that invoices have a direction (i.e. either
going outbound(+) or coming inbound(-) (cf. `_compute_direction_sign`)).
This, in turn, makes the value of `amount_to_invoice` incorrect
for sales order with a credit note.
Solution:
In `_compute_amount_to_invoice`, multiply the value of
`invoice_amount_currency` with the opposite of the
`direction_sign` of the invoice, to account for the invoice direction.
opw-3360439
X-original-commit: 06ef17f2eefe89abfca64721185ac053fa8de820
[FIX] sale: fix amount to invoice for credit notes
Issue:
The `_compute_amount_to_invoice` computation wasn't taking
into account the fact that invoices have a direction (i.e. either
going outbound(+) or coming inbound(-) (cf. `_compute_direction_sign`)).
This, in turn, makes the value of `amount_to_invoice` incorrect
for sales order with a credit note.
Solution:
In `_compute_amount_to_invoice`, multiply the value of
`invoice_amount_currency` with the opposite of the
`direction_sign` of the invoice, to account for the invoice direction.
opw-3360439
closesodoo/odoo#127914
X-original-commit: d258774f120fb470d969e68c05cf0d8da0c4557a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since odoo/odoo@2b1e2abda3 user need at least 'Account / Billing'
access to read payment.transaction, that not the case for most salesman.
So for user that don't have 'Account / Billing', this commit do:
- compute the 'amount_paid' as superuser
(fixing "Generate Payment Link" wizard access errors)
- hide "Payment Transaction" smart-button on invoice
closesodoo/odoo#127835
X-original-commit: ad2c3a873a926ac8c94d014af24ed400b493493e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
Brazilians don't expect to see tax-related info on quotations. This
modifies the quotation PDF and online quotation views. Adding t-ifs
with position="attributes" was considered but doesn't play well with
other modules who would want to modify the same elements in some way.
Therefore a similar approach to account.report_invoice was
taken. Small functions on sale.order will determine what views will be
used. This allows l10n_br_sale to dynamically return its own
primary=True views when Brazilian records are shown.
task-3325740
closesodoo/odoo#122987
Signed-off-by: Josse Colpaert <jco@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
It's not a specific state, it should be considered separately,
as a boolean.
This allows to reduce code complexity (flows should not rely (much) on
the locked logic) and to have a clearer flow.
Task-3163931
Part-of: odoo/odoo#115871
The whole contextual price of products relies on multiple context keys:
* uom
* pricelist
* quantity
* date
The related logic has already been partly removed/deprecated on products,
but the computation of discounts for events/event booths are still relying
on that logic, though imperfectly.
This commit makes sure this hacky logic (relying on those contextual keys)
is as clear and reliable as possible.
We factorize and harmonize the remaining use cases, with a dedicated constant
and specific methods, making sure:
* currency conversion
* price & discount computations
are coherent, while clearly explaining that it should not be used for
any new feature/logic/code.
We also restrict context updates as much as possible (there won't be
any discount when the pricelist is configured to hide the discount from the customer)
closesodoo/odoo#123848
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When a SO has several downpayment, they all have the exact same
description "Down payment" which does not provide much information.
This commit adds the invoice reference and the date.
task-3299805
Part-of: odoo/odoo#120972
An error occurs because to convert the amount in sale order line company is
required.
when user remove the company and tries to add a new product in sale order line
error occur.
applying these changes will resolve this issue.
sentry-4090085761
closesodoo/odoo#125575
X-original-commit: c04bc8026eae79c01fb9315d8063b12d3a1e2fa8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Smit Nagar (smna) <smna@odoo.com>
Since d88409e8e5ce77ff3ec3b24fcdc108d8df380994, taxes from different companies
are forbidden on sale.order.line records (which is the expected behavior).
Nonetheless, this highlighted some flows where the taxes were not properly
set/recomputed, especially re-invoicing, which is fixed by the current commit.
Fixes#123675closesodoo/odoo#125434
X-original-commit: 6ce4019968bd0a1a11475910d35aa2ccfc2c6a9a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Issue:
------
When a cart is created via ecommerce, an email is sent to the salesperson
(defined in Settings/Website/Assignment).
This email contains a subtitle with the amount of the sale order.
This price is always 0.00.
Cause:
------
The email is sent during the creation of the sale order
and not after it has been updated with the product information.
Solution:
---------
Use a key in the context to prevent sending the price of a sale order.
Remark:
The email sent in this case is an assignment email only.
Mentioning the price in this case would not be relevant
if the customer subsequently updates their cart.
opw-3329722
closesodoo/odoo#125378
X-original-commit: ea883e75343e50a1603b37c5f82f8e620418c883
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
It's currently not possible to know which `pos.order` is linked to a
`sale.report`
Solution:
Add a field `order_reference` on model `sale.report`. This field refers
to either a "sale.order" or a "pos.order" record.
The field `order_reference` is used to count the number of distinct
orders. We cannot simply use count_distinct on the `order_id` because
there can be multiple sale.report with the same `order_id` but related
to different models (sale or POS order).
Part-of: odoo/odoo#116830
When user change the move_type of account_move to 'entry'. And when user try to
access 'partner_credit' field from the form view using debug mode.
The error will be generated.
Steps to Produce:-
1. Install 'account_accountant' and 'sales' module
2. Change move_type of account_move to 'entry'
3. Go to 'Edit View : Form' of Journal Entries in account_accountant using
debug mode
4. Add field 'partner_credit' to the form or tree view and click on save
5. Click on any Journal Entry
Trace-back will be generated.
Applying these changes will resolve this issue.
Sentry-4222621594
closesodoo/odoo#124515
X-original-commit: 94c1f20aaeb89cc07bb21cab2e19da67fd10f603
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Preksha Chouhan (prec) <prec@odoo.com>
So that we can in the future harmonize more easily the discount
computation between sale, point_of_sale, e-commerce, ...
closesodoo/odoo#123849
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The value of custom ptavs is store on the sale order line.
Currently, they are ordered by ptav id but they are ordered by the ptav
sequence everywhere in Odoo.
Now, on the sale order line, custom ptav are ordered by ptav sequence.
opw-3234669
closesodoo/odoo#122206
X-original-commit: fa25206634e11ce1fd9030508772a1802ef86fa2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
- Create a Deferred Revenue Model on a Current Liability account
- Create a Sale Order yourself (User 1), with Salesperson User 2
- Create the invoice from it
- Remove the salesperson from the invoice and add User 3 instead
- Change the account to the Revenue Model's one
- Post the invoice
- Post the deferred revenue created
=> User 2 is follower of the entries generated
The problem is that the context comes from the sales order, and
contains a `default_user_id` in the context.
The solution provided is to remove it from the context given, as
it serves no purpose (the invoices are already created).
opw-3141495
closesodoo/odoo#121581
X-original-commit: c3df8fc0da2f359ac0a47695ef37aa8869063092
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When creating payment links for the customer, the user can now decide on a partial amount to be
paid at the time.
Use case: when the customer cannot pay the SO amount with one payment, e.g. limit on the credit
card, the user will now have the possibility to set a partial amount on the payment links.
The order will be automatically confirmed when the amount chosen is equal to the remaining amount
to be paid.
Additionally, the customer will be notified by email for each payment done instead of only at the
confirmation of the order, which will happens only once the total amount is paid.
Task - 2672713
closesodoo/odoo#109661
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Horacio Tellez <hote@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
Bug:
When the `sale_loyalty_taxcloud` is installed and 'Lock Confirmed Sales'
is enabled, confirming a SO impossible.
Setup:
- install `sale_management` and `sale_loyalty_taxcloud`
- activate Taxcloud (with test credentials)
- enable 'Lock Confirmed Sales' in the settings
Steps to reproduce:
- create a quotation, fill the necessary fields and add a product
- in the 'Other Info' tab, set the fiscal position to
'Automatic Tax Mapping (TaxCloud)'
- attempt to confirm the quotation
You should be met with a message stating that you can't modify the tax
on a locked order.
Cause:
This issue was introduced by odoo/enterprise@ea954b818b
Enterprise PR: odoo/enterprise#40880
opw-3289657
closesodoo/odoo#121410
X-original-commit: d676498902adf2dcd8fa4530fc21e84fb940aad2
Related: odoo/enterprise#41060
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Since 15.0, it is no longer possible to have partnerless transactions.
Nonetheless, migrated databases could contain transactions without a
`partner_id` set.
This commit cleans existing rules to make those transactions are not
accessible to unwanted users.
We take the opportunity to clean the security of payment.transaction
records globally.
Now only admin and accounting users have access to payment.transaction
records. The code of different applications has been adapted accordingly.
Task - 3102824
closesodoo/odoo#113515
Related: odoo/upgrade#4564
Related: odoo/enterprise#40939
Signed-off-by: Masereel Pierre <pim@odoo.com>
Since e6415be5ce6077702836779cf784e16f7e72a9c7, it is
forbidden to use taxes on Sales Order Lines from another company
than the Sales Order one (it was breaking later in the flows anyway).
Nevertheless, in some flows, modifying the company of an existing SO
can make sense, but you wouldn't be able to save the change if taxes
were set on the lines (unless you trigger the 'Update Taxes' button).
This commit will make sure that taxes are automatically recomputed
on company change, s.t. the user doesn't face multi-company errors.
It'll magically change taxes & amounts, but we consider that it's
an expected behavior when modifying the order company (and an
advanced flow for which users must be aware of the consequences).
Anyway, the user will always be able to discard the changes (company
& company-based recomputations) if needed.
opw-3234905
closesodoo/odoo#121258
X-original-commit: e37386a14430174961126ec1b8caf24d67011730
Related: odoo/enterprise#40991
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, Fields Sales are struggling to create quotations or sale
orders directly from the customer place. One of the issues is that it
is not easy to quickly add products to the SO. Products must be added
one by one and, in mobile, it requires completing a form with
quantities, ... for each new line.
This commit introduces a catalog view that allows users to select
products in a faster and easier way than before, both in desktop and
mobile view.
Task - 3062080
closesodoo/odoo#106382
Related: odoo/enterprise#37915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: chevalierv <vcr@odoo.com>
When tracked changes happen on a sale order, they are logged in the
chatter. These changes are not relevant to be shown in the chatter as
they can be excessive when the sale order is in a draft state,
especially for e-commerce orders since they are modified step-by-step
by the customer.
After this commit, changes will be logged only if the sale order is not
in a draft state.
Task - 3062080
Part-of: odoo/odoo#106382
When triggering the CRON "Sale Subscription: generate recurring invoices
and payments", invoices are created from subscriptions, the emails and
xml attachments are sent to the recipients.
Similarly, the CRON "automatic invoicing: send ready invoice" should go
through the Send and Print wizard to be able to create the xml
attachments.
task-3299540
closesodoo/odoo#121075
X-original-commit: 79770f1b5abc79bcf0feb12b4316fc864ba291dd
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
When the user set some sale credit, while creation of invoice of multiple sale
order which exceed the sale credit of a partner the user will get singleton
error.
steps to produce:-
- Install 'sale'
- Go to 'Setting' and enable the Sale Credit
- Create two sale order with same customer and product which has
ordered quantities
- 'Conform' both the sale orders
- Select both the sale orders
- Go to actions and click 'Create Invoice'
- Traceback is generated
Applying this commit will fix this issue.
sentry-4109773100
closesodoo/odoo#120600
X-original-commit: 565d1ad4c679d47e391cea7badf60d85ac2aa9ca
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- create an expense product, re-invoice: "at cost"
- create a sale order with the product and set an analytic account
- create a purchase order with the expense product and the same analytic account
- create the bill
-> a new line on the SO is created with the same "Quantity Delivered" as the "Quantity Invoiced" for the purchase order
- for the bill, create a Credit Note of x unit
-> the purchase order has the Quantity Invoiced diminished of x
Issue:
- the Sale Order has not taken into account the new quantity after refund
- Since the line is an "analytic" one, the quantity delivered cannot be changed even if we wreate a credit note for the invoice
Solution:
During the processus of creation of new analytic lines, instead of creating new so lines we adapt the analytic line
closesodoo/odoo#120660
X-original-commit: 5258e2ce7d2df915eff02218636aa3272a7d9faf
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
# Steps to reproduce
* create two 17% sales taxes. We'll call those taxes `17a` and `17b`.
* set rounding method to global
* create a SO with the following 2 lines:
* Price = `50.4`, Taxes = `17a`
* Price = `47.208`, Taxes = `17b`
* note that the total tax amount on the SO is `16.59`
* confirm and invoice the SO.
You should see that the total tax amount on the invoice is `16.60`. The
invoice and SO should have the same tax amount.
opw-3179228
closesodoo/odoo#120224
X-original-commit: 715d0e269c3d42a5e25f8ddf648d275069354aaa
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
Co-authored-by: Yolann Sabaux <yosa@odoo.com>
When new records are used to precompute some fields, the computations
are expected to use the "right" values for floats, in particular float
fields are expected to be rounded.
closesodoo/odoo#118518
Signed-off-by: Raphael Collet <rco@odoo.com>
Step to reproduce :
- create a service product with 'create project & task'
- set the invoice policy on either 'invoice on TS', 'invoice on
milestone', 'prepaid'
- create a new SO with the product and confirm.
- update the price of the sol (e.a. from 10 to 20)
- go to project_updates
The project profitability panel is still showing 10 instead of the
updated price of 20
After this fix, the project profitability is correctly showing 20
task-3236240
closesodoo/odoo#118728
X-original-commit: 847313c3bccc31449bc441d21304b71648a7f429
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Create a Field Service Task
Assing a customer, in Timesheet tab add a line with Hours Spent 00:20
Mark as Done
Sale Order will be created with a sale order line
Total of the line and Total of the order will not match
This occurs because the sale order line has been created with an
unrounded quantity of 0.333333
opw-3184468
closesodoo/odoo#118628
X-original-commit: ca72697042687e205fb288a97ec4717a97c89664
Related: odoo/enterprise#39799
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
task-1962182 introduce the field back in 12.5
but did not added any logic with it.
The tooltip suggested the need for it tho:
"Check this box if you send quotations to your customers
rather than confirming orders straight away."
related to 0d2be38333
opw-3198202
closesodoo/odoo#115031
Related: odoo/upgrade#4449
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Activate analytic accounting
- Create a Sale Order, with an analytic account for the whole order
- Add a line with a distribution containing the same account (100%)
- Create Invoice From this Order
=> The distribution on the account for the invoice is of 100% and
not 200% (the sum of the order's account and distribution).
The problem is that on the dict that we're returning, the key is a string
closesodoo/odoo#116617
X-original-commit: 9ecf263d4124b186b55e50ab025acb7541043d3a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit when in a multi-company environment an user
could assign a company to the sale order and use taxes related
to a different company for the sale order lines.
This is a functional error and also provoques that taxes are not
shown for some users when in a multi-company environment.
After this commit a ValidationError will be raised whenever the
company of the taxes in the sol and the so do not match.
opw - 3117352
closesodoo/odoo#115162
X-original-commit: 295c408568bb623f0b0ead3f18493ba339b87161
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
A header in the mail gives the amount and the validity date of a
quotation. Its means the quotation will expire at this date, and is not
related to any missing payment. The validity date has no meaning on a
confirmed sale order and is therefore removed.
task-3185072
closesodoo/odoo#115752
X-original-commit: 89ebc9ad4f0524109fd4846156448692d1d20a44
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
When trying to invoice undelivered quantities the error message
was somewhat misleading: it indicates as a possible solution a
Stock app feature even when Stock is not installed.
After this commit the message will be more appropriated.
opw - 3206001
closesodoo/odoo#115033
X-original-commit: a6ae8fae9f0db559880e04caa8446e57f7733c85
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Horacio Tellez (hote)