Steps to reproduce the issue:
- Install eCommerce module
- Go to Settings
- Ensure `Product Prices` is set to 'Tax included'
- Create a new Product as storable
- Set `Sales Price` to $1.0 and `Customer Taxes` to 10.00 %
- Under `Variants` tab add an Attribute with 2 values
- Set "Price Extra" to $2.0 to one of the variants
- Go to the Shop and select the product
Issue:
The extra price badge does not include the taxes
($2.0 instead of $2.2), however the final price does.
Cause:
The price_extra field from ptav (used in the badge) does not include
the taxes.
However, when calculating the final price, we do first the sum of all
prices (including the extra prices) and then apply the taxes.
Solution:
In the template, for each 'variants', we call `_get_combination_info`
to get the variant.price_extra with taxes included/excluded
depending the `Product Prices` setting.
opw-2669871
closesodoo/odoo#81949
X-original-commit: 6f04935d14d595faa3bb8dd6ba9e0dcf1d694886
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Prior to this commit, the company of the invoices generated through the use
of the `sale.advance.payment.inv` wizzard were not forced to the one of the
related sales orders. From the compute method on account.move the company would
then be either the one of the journal or the current company.
It seems that context_keys were used 'at least in industry_fsm_sale' in order
to ensure that the company was correctly set (although the one of the task
was used instead of the one of the SO).
This commit ensures that invoices created through the wizzard now takes the company
of the SO they are generated from.
Finaly this commit adds a multicompany test in the sale module in order to ensure
that the `sale.advance.payment.inv` wizzard is not impacted by the multicompany.
task-2608812
Closes: #79926
Cache the pricelist rule used for price computation in a dedicated non
stored field, since it is used both for the price_unit and the discount
computation.
This divides by 2 the number of pricelist requests/queries when
discounts computation is enabled.
Steps to reproduce:
- Install and launch sales
- In settings: activate price lists and discount; price list based on advanced rules
- Create a new price list; based on percentage (54%)*; applicable on all products; show discount
- Make sure the Public Price List has show discount activated
- Create a new quotation
- Select the Test pricelist
- Select a product (price 0.03 eur/$/other)*
- Change the price list to Public price list
- update the prices
- change the price list to Test price list
- update the prices
-> The Discount shown is not the one defined in the price list (66.67%)*
*(values for my example)
Solution:
Use the real price and not the a posteriori-rounded price for the computation of the discount in the `update_prices` method.
opw-2677884
closesodoo/odoo#81395
X-original-commit: 986dbc20952caae9d5a1b4b7ee34cfb994dea077
Signed-off-by: yosa-odoo <yosa@odoo.com>
How to reproduce the problem:
- Install the Sales and Invoicing apps
- Create a simple SO with a product
- Create Invoice -> Down Payment (percentage) 30% -> confirm
- On the SO -> Create Invoice -> with Deduct down Payment -> confirm
- On that invoice -> Add Credit Note -> Reverse -> confirm
On the SO, the Down payment is not counted as invoiced, even tough it
was already paid and not refunded. If the user wants to create a new
invoice, the system will create one with the full price (not taking the
already invoiced Down Payment into account).
Cause of the problem : when computing the quantity to invoice for
the SO, a condition was avoiding preventing the down payment invoice
line to be taken into account in a way that it was just ignored.
I don't really understand the reason for this condition, as
it specifically ignores the down payments, while it should not be
ignored.
When creating the draft for the refund invoice, the down payment's SOL
is correctly updated as `line.untaxed_amount_to_invoice == 0` is true.
But when confirming the invoice, the values changed and the condition
is thus not met anymore.
opw-2491225
closesodoo/odoo#79572
X-original-commit: 99e8d4ad33bcdb27f7632a9ba5a5a2886d074ed5
Signed-off-by: Roose Pierre-Rodéric ( prro) <prro@odoo.com>
- Fix typo in accrued_orders.py
- Remove fields.Date.today() from purchase test
- Make more use of common resources
closesodoo/odoo#79159
X-original-commit: 31570e185dcb36145e28e42cda765284dc373294
Signed-off-by: Laurent Smet <las@openerp.com>
The invoicing target on sales team do not have to take the vendor bills into account.
When we click on Sales analysis, we only see sales details.
opw:2557852
closesodoo/odoo#77144
X-original-commit: 26871eabe3f95945c6cf2fc084e3af469ed561f6
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Configure payment stripe to be available on the web shop
- Let's consider a product with P (sales price = 100€) invoice policy based on delivered qty
- Set in the config parameter sale.automatic_invoice to True
- Create a SO with P and generate a payment link PL for 50€
- Go to PL and pay it
Bug:
An error was raised because there was no invoicable line when computing the
invoice of SO
opw:2635175
closesodoo/odoo#76735
X-original-commit: 846bc047fcd546bf5b8e7fe224b8a98e876eba21
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* order lines are now not grouped anymore by account. That allows a more detailed label on the accrual entry line, as it's now directly related to a single order line
* we now create a single accrual entry counterpart, instead of one per order previously. That reduces the 'noise' in the accrual entry, at the cost of not having the sum per ordre anymore easilly but it doesn't seem to be important to audit that account
closesodoo/odoo#76037
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Accrued liabilities, or accrued expenses, occur when you incur an expense that you haven’t been billed for (aka a debt).
For example, you receive a good now and pay for it later (e.g., when you receive the invoice). The same opposite approach for sales.
Why do accountants need such entries ?
- Accounting must give a fair view of the financial situation of a company. The loss/profit must be booked regarding the effective deliveries of goods/services, not on the paperwork only.
- On a fiscal point of view, if you want to be allowed to deduct a loss from your taxable basis, it has to be in the right period. If you didn't announce it on time, the loss might be rejected by fiscal authorities. Same goes for the augmentation of the taxable basis, it has to reflect real deliveries and not only paperwork.
was Task: 2555642
was PR #73707
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Suppose such a SO line:
- Unit Price: 541.26
- Qty: 38
- Discount: 2%
The line amount is computed thanks to application of the discount on the
price, then the multiplication of the result with the quantity. The
rounding eventually happens after these steps:
https://github.com/odoo/odoo/blob/254b2a0840d3e817cc6062c483b5213c10088af5/addons/sale/models/sale.py#L1013-L1024https://github.com/odoo/odoo/blob/b76e9ef658bde0178fa1660b6ad27b880e91632a/addons/account/models/account.py#L1138
Therefore, in the above case, we have:
```
Total = round(541.26 * 0.98 * 38)
= round(530.4348 * 38)
= round(20156.5224)
= 20156.5224
```
However, when confirming the SO and setting the delivered quantity, the
Untaxed Amount To Invoice is computed using the unit price with both the
discount and the rounding already applied:
```
Total = round(541.26 * 0.98) * 38
= round(530.4348) * 38
= 530.43 * 38
= 20156.34
```
As a result, the amount is not the same than the first one, this is
incorrect.
OPW-2525975
closesodoo/odoo#74709
X-original-commit: 014a40448ca7854646d929ab369f92c6dede1eb4
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
For data quality purposes and bug prevention, when I reverse an entry,
the reversal should always be postable on a journal having the same type
as the initial Journal Entry's journal.
closesodoo/odoo#72431
Task: 2497529
Related: odoo/enterprise#19543
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
It replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) sale.order -> note
2) sale.order.template -> note
Task Id: 2499504
X-original-commit: 6a345c2695129a5cd907e5e23e057871ebf9ebfa
Some flows of the core `sale` code (sale_order & sale_order_line)
weren't covered at all by tests.
This commit adds some tests to cover those flows, reducing the risks of
broken features/flows with future sale tasks.
closesodoo/odoo#71402
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The main company can have something else than EUR or USD, especialy when
testing localizations.
closesodoo/odoo#71171
X-original-commit: 91a3dca13c1de637b25810ed7f509dce6e66c908
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This reverts commit d89562e8fe473692296cb209651beb2ce7a715e4.
Since this commit, the taxes mapped by fiscal position wasn't managed by the _fix_tax_included_price_company method anymore.
Otherwise, some customizations exist on this method that are no longer called.
The 2527940 issue is also due to a remaining bug: the total_excluded price should be divided by the quantity but:
- what if the quantity & price_unit are both signed?
- what if the number of digits for price_unit and the currency are different? Should we skip the rounding of taxes?
Since this commit is not perfect and has a lot of dependencies in others modules, we decided to revert it.
Original PR: https://github.com/odoo/odoo/pull/68997
Revert PR: https://github.com/odoo/odoo/pull/70858closesodoo/odoo#70914
Issue: 2527940
X-original-commit: def7d7bb0231fef38e044803b245c9b990a90216
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
For customer invoices:
* do not set default date because if you prepare an invoice (and it gets
a default date), then validate it the next day, the date will be wrong
* set the date when posting if it wasn't set, because why not?
For vendor bills:
* do not set default date because you rarely encode a bill at the bill
date. Forcing the user to enter it reduces risks of user error
(duplicated vendor bill)
* do not set it when posting, same reason.
opw-2492862
Related #68368Closes#68367closesodoo/odoo#69639
X-original-commit: 41041d8016d11f017d92d28f32ab2cf42f1349a9
Related: odoo/enterprise#17866
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
- Create a product:
* Invoicing Policy: Delivered quantities
* Re-invoice Expenses: At cost
- Create a SO with the created product in Order Lines
- Make sure the subtotal of the SO line is equal to 0, by setting an Unit Price to 0
or by applying a 100% discount
- Confirm SO and create an invoice (Regular invoice)
- Post the invoice
A new line with the same product and the same delivered quantity is added to the SO.
It is not possible to invoice a SO line with a product having an expense policy and
a subtotal equal to 0, without having it reinvoiced to the SO.
This fix will prevent account move lines linked to a SO line from being reinvoiced.
opw-2479560
closesodoo/odoo#69623
X-original-commit: b41cf0077c9a6d1d74cc0c7987c0edcc58e368d1
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
Create a standard tax included in the product price.
Add that tax to a product and the down payment product.
Create a sales order (i.e. 1 line, 100$ total, 15% tax incl).
Create a percentage down payment invoice, i.e. 50%.
Post the downpayment invoice.
Go back to the sale order
The sale order line relative to the downpayment was asjusted to remove
the tax amout while this should not occur when dealing with tax included
in price
Added test
opw-2426294
closesodoo/odoo#65911
X-original-commit: 3b58b373e1c6c155f65b88c31cbb47794cb0a554
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS: MODEL CLEANING
In this commit we improve team member model to make it more usable and
aligned with current Odoo views and usability.
This commit contains notably
* add some related fields on the user: phone, mobile, company, email;
* rename "team_user_domain" to "assignment_domain";
* rename "maximum_user_leads" to "assignment_max";
* improve member views globally;
We also introduce dynamic domain computation for users and teams when seeing
team members. This allows to limit selection of users or teams depending
on already existing configuration. Purpose is to avoid having people trying
to create wrong configuration (duplicates, ...) and receiving error messages.
Also
* clean some data and demo about teams and members;
* fix some views glitches;
* improve views: add some fields in search views, improve wording of
fields or actions, ... globally improve usability and US as well as
feedback given to users;
* group sales team members by team by default as it help getting an
overview of team members distribution;
* update tests to create team members instead of writing directly on m2m
towards users;
SPECIFICATIONS: SALE_TEAM_ID FIELD ON RES.USERS
In this commit we also rewrite sale_team_id field of res.users. Previously in
crm it was simply a many2one field linking to a crm.team. It was used to compute
team membership as a standard many2one / one2many relationship. In enterprise
module ``website_crm_score`` this field was set as a related on first user
teams. Indeed scoring changed relationship between users and teams to a
many2many.
This field is now directly a computed many2one field that links to the
"main" team of the user even in multi memberships mode. As memberships can
now be de-activated we changed this field to a computed stored field. It is
based on oldest active membership of user. That way default team of documents
will be the user's oldest team considered as its "main team".
SPECIFICATIONS: LEAD_ALL_ASSIGNED_MONTH_COUNT
Improve crm_team ``lead_all_assigned_month_count`` field computation. It is
now simply the sum of assigned leads of team members. Differences may
happen if a lead in teamA is assigned to an user working in teamB. This should
not happen if team / user is correctly set at lead level which is generally
the case. However if that happens, old field counted it. New field will not
count it as it is not directly linked to a team's member.
SPECIFICATIONS: DEMO DATA
Make crm.lead demo data coherent with user_id / team_id . As demo data should
be using a mono-membership behavior for users and teams, we have to ensure
user_id and team_id effectively matches. It allows to have coherent reporting
and assignment demo flows.
Also avoid having Odoobot responsible of leads. Instead of undefined user_id
and team_id leading to Odoobot being responsible of some leads, force it
to be False. Those demo data allow to test automatic assignment of lead
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
Due to accounting custom setupclass user in environment is not admin but a
custom user having only accountant rights. This is hidden in accounting
override that changes test user and mix data creation and ACLs tests.
Current tests in sale crash when a flush is involved during data creation
as test user (accounting) has no rights to create users.
In this commit we fix locally sale data creation as fixing accounting
test structure is out of scope compared to this task.
Spotted when working on task ID-2086889
closesodoo/odoo#62672
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Nasreddin Boulif (bon)