Issue:
-------------------
When creating invoices for two sales orders with the same customer the field amount_to_invoice is wrongly calculated and it shows a negative value when it should be zero
Steps to reproduce:
-------------------
1. Go to Sales -> sale orders
2. Create two sale orders with the same customer
3. Confirm the SO’s and delivery the items
4. Create the invoices for both SO’s
5. The field amount_to_invoice is negative
Cause:
-------------------
The method _compute_amount_to_invoice considers the value of all sale orders without any filter, but in this case we have two different sale orders and we only have to consider the value for the respective SO.
OPW-3437237
closesodoo/odoo#132859
X-original-commit: e2ec9e6c86949f5781d03a7dbb1065ef8af3196a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The salesperson is not added to the following list of invoice that is generated from a sales order.
1. Create a sales order by assigning a salesperson.
2. Confirm the order and generate the invoice.
Current Behavior:
The salesperson is not added to the message following list of invoice.
Expected Behavior:
The salesperson should be in the message following list of invoice.
OPW-3439198
closesodoo/odoo#130930
X-original-commit: d9cb66e22fc9f8cfa1c00a2808294fe1178ffaa1
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
A new way to add products in sale orders, through a catalog, was
introduced in commit 216fa84fbe. The precision of the price shown in the
catalog was the currency's precision, but the product price precision
should have been used.
closesodoo/odoo#132046
X-original-commit: 37b5626f58284e13ecfe113842134fe5006f5517
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Summary
-------
Currently, the credit limit feature does not correctly take currencies
into account.
Steps to reproduce
------------------
* install `sale_managment`
* enable 'Sales Credit Limit' in the settings
* on a partner's form view, in the accounting tab, enable
`Partner Limit` and set a limit of 50
* have a currency `C` that's weaker than your company currency (we'll
call it `Q`). Let's say that here, `1 Q = 10 C`.
* have a price list in currency `C`
* create a quotation using the partner and price list mentioned above
* add a product with a price of 5, and no tax.
You should be met with a warning indicating that the customer has
reached his credit limit.
opw-3441361
closesodoo/odoo#130652
X-original-commit: f57653a6dcea04f0bca4e5ca73df3e1075e0fe98
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
To reproduce:
- Create a Distribution model, with an analytic distribution
and an effect on Partner A
- Create a Sale Order, for Partner A
- Confirm it
- Add a line on this Sale Order
=> The new line does not get the distribution of the model
It couldn't be done before 16.0 because a compute would trigger when posting the sale order, because date_order was used for the default rules, and so would trigger it at wrong times.
Distribution Models don't use this date anymore, so the compute won't happen at wrong times.
task-3355886
closesodoo/odoo#130597
X-original-commit: 22fd34b0d8b944a7afd031b894d750a8291d0aba
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Simplify model custom code when dealing with phone and sms by using helpers
and standard behavior defined on all models.
'_sms_get_partner_fields' was introduced at odoo/odoo@bdebcab0ce to have a generic
implementation of finding partners on a record. Since then another version
has been added directly in 'mail' module, using '_mail_get_partners'.
'_sms_get_number_fields' was introduced at the same time to have a generic
implementation of finding numbers on a record. Since then a generic and
improved version has been added directly in 'phone_validation' module, see
'_phone_get_number_fields'.
Those method can therefore be removed, and replaced by the generic ones
available on BaseModel.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
For sale orders, if the invoice status is set to "Fully Invoiced", the mount to invoice is forced to zero.
task-3347812
closesodoo/odoo#124777
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
A recent trend in report design in Odoo has been to dynamically set the
report template to call using a python method. This was used e.g. to
detect that a document should use an alternative report layout created
by a localization package.
Unfortunately, doing so 'breaks' the new report editor, as it runs
without an underlying record, and therefore cannot call python methods
to determine what the template id to call actually *is*.
This commit removes this mechanism from the Sales app and the Brazilian
localization, relying instead on 'normal' qweb directives and
inheritance to generate the proper layout.
This commit does not introduce any functionnal changes, it simply makes
the templates compatible with the new report editor. No visible change
should occur.
X-original-commit: cd26f77adecc7036c845ed1d7c7094b63987a1a1
Part-of: odoo/odoo#129492
Setup:
------
1) Install website_sale module
2) Product:
One product with:
- Sales Price: 100
- Customer Taxes: 10% included
3) Fiscal position
Two fiscal positions:
- Country: France - 10% included --> 20% excluded
- Country: Netherlands - 10% included --> 15% included
Steps to reproduce:
-------------------
- without being logged in, go to ecommerce;
- add the produt to cart;
without information on the tax position, we have:
90.91 + 9.09 = 100 --> this is correct
- process checkout;
- Enter an address with the country France;
France:
90.91 + 18.18 = 109.09 --> this is correct
(100 : (1 + 10%)) * (1 + 20%) = 109.09
- edit the billing address;
- use the country Netherlands;
Netherlands:
104.55 + 20.91 = 125.46 --> this is wrong
instead of:
90.91 + 13.64 = 104.55
(100 : (1 + 10%)) * (1 + 15%) = 104.55
(This is just one example)
Issue:
------
There is inconsistency in the application
of taxes according to tax position.
Cause:
------
To calculate the product's price unit, we apply
tax position mapping via the
`_get_tax_included_unit_price` method.
Modifying the `price_unit` field in the
sale order line will trigger the
compute method `_compute_amount`.
This recalculates the amounts,
but without taking into
account the tax position mapping.
We therefore use a value for the `price_unit`
field which is not in line with the taxes.
Solution:
---------
Recompute sales order line taxes
when a change in fiscal position is detected.
opw-3318971
closesodoo/odoo#129440
X-original-commit: cdb9819b0e199f95d489e8cfe4217cf6de6362b3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
- Install website_sale, contact, l10n_ch
- make sure your company is in Switzerland and has all the address information
- in settings, activate QR
- in Accounting/Journals/Bank:add a bank account (iban: CH4431999123000889012; qr-iban: CH11 3000 5228 1308 3501 F)
- install and enable the provider "Wire Transfer"
- From the Website, create an order and make sure the customer set an Invoicing address in Switzerland (address + Country)
- Validate the order
- In Website/unpaid orders: select your order and Confirm the order
- Create and confirm the invoice
- Print the invoice
Issue:
User Error is raised
Cause:
With Swiss QR code you need to have a valid payment reference. That is, an ISR reference such as in
https://github.com/odoo/odoo/blob/c6631df1c5b0b6d4c2268a826ca150edd0ca653e/addons/l10n_ch/models/account_invoice.py#L90
But when you create an order from the website, it creates an automatic reference "SO0001" which, when converted to an invoice, stays the same.
Since the reference is prepoluted, the `_compute_l10n_ch_isr_number` will not be triggered and therefore will raise an error when trying to print the invoice.
Solution:
Check if the Customer Invoice Journal uses the swiss reference model, then we know that the swiss loca is installed and can call the correct function to compute the reference/
Note:
In the test we check that `payment_custom` is installed. It is because the `_set_pending` method checks taht the payment_provider.code is "custom"="wire_transfer" in which case the sale order reference is computed
https://github.com/odoo/odoo/blob/b4ed9537895ecee48ed146add4257af0aebeb3f4/addons/sale/models/payment_transaction.py#L54-L56
opw-3334534
closesodoo/odoo#127338
X-original-commit: dfa4844e57b67d16b181e1e58813cdbbc7efa956
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Co-authored-by: flvr-odoo <flvr@odoo.com>
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>
Matheus Leal Viana (malv)