<feed xmlns='http://www.w3.org/2005/Atom'>
<title>Odoo/addons/sale/tests/__init__.py, branch 14.0</title>
<subtitle>The current checkout of upstream Odoo</subtitle>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/'/>
<entry>
<title>[REVERT] sale: Fix fiscal pos. mapping taxes to price included</title>
<updated>2021-05-17T14:12:42+00:00</updated>
<author>
<name>Laurent Smet</name>
<email>las@odoo.com</email>
</author>
<published>2021-05-17T10:08:31+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=def7d7bb0231fef38e044803b245c9b990a90216'/>
<id>def7d7bb0231fef38e044803b245c9b990a90216</id>
<content type='text'>
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 &amp; 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/70858

closes odoo/odoo#70883

Issue: 2527940
X-original-commit: c9330e4af5b034fd81090478723ee3c18be58733
Signed-off-by: Victor Feyens (vfe) &lt;vfe@odoo.com&gt;
Signed-off-by: Laurent Smet &lt;smetl@users.noreply.github.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &amp; 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/70858

closes odoo/odoo#70883

Issue: 2527940
X-original-commit: c9330e4af5b034fd81090478723ee3c18be58733
Signed-off-by: Victor Feyens (vfe) &lt;vfe@odoo.com&gt;
Signed-off-by: Laurent Smet &lt;smetl@users.noreply.github.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[FIX] sale: Fix fiscal pos. mapping taxes to price included</title>
<updated>2021-05-07T13:02:49+00:00</updated>
<author>
<name>Laurent Smet</name>
<email>las@odoo.com</email>
</author>
<published>2021-04-08T16:15:46+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=a6fe2de9b9879d918f0315982b51fba345a2addd'/>
<id>a6fe2de9b9879d918f0315982b51fba345a2addd</id>
<content type='text'>
Using a fiscal position to map a tax to a price-included tax doesn't work.

closes odoo/odoo#70382

X-original-commit: 48ea669e0e6ff0ceb2f36828457e0d3773b38487
Signed-off-by: Antoine Vandevenne (anv) &lt;AntoineVDV@users.noreply.github.com&gt;
Signed-off-by: Laurent Smet &lt;smetl@users.noreply.github.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Using a fiscal position to map a tax to a price-included tax doesn't work.

closes odoo/odoo#70382

X-original-commit: 48ea669e0e6ff0ceb2f36828457e0d3773b38487
Signed-off-by: Antoine Vandevenne (anv) &lt;AntoineVDV@users.noreply.github.com&gt;
Signed-off-by: Laurent Smet &lt;smetl@users.noreply.github.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] sale*: Remove dependency to AccountTestCommon</title>
<updated>2020-07-31T08:38:30+00:00</updated>
<author>
<name>Laurent Smet</name>
<email>las@odoo.com</email>
</author>
<published>2020-07-27T08:31:58+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=6d1e1e09ead203aae5e12af07d01735c64c7bc46'/>
<id>6d1e1e09ead203aae5e12af07d01735c64c7bc46</id>
<content type='text'>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2301180m</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2301180m</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] portal,sale: improve signature widget and move it to portal</title>
<updated>2019-01-28T09:48:32+00:00</updated>
<author>
<name>Sébastien Theys</name>
<email>seb@odoo.com</email>
</author>
<published>2019-01-28T09:48:20+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=130af96dc155fbb38ca712ca47b7ee8de35dd482'/>
<id>130af96dc155fbb38ca712ca47b7ee8de35dd482</id>
<content type='text'>
Purpose
=======

The goal is to avoid duplicate code between portal and sign (enterprise), and
also to allow the user to use the signature mode 'auto' and 'load' in portal
(before this commit only 'draw' was available in portal).

The sales order signature (currently the only portal signature) has been changed
to use this new code.

This signature widget has been improved:

Improved style:
 - better structure and use of BS classes
 - removed most of custom CSS
 - made it more responsive

Changed code to follow guidelines, added JSDoc.

Technically
===========

New widget NameAndSignature common to portal and sign (enterprise).

Reworked existing portal signature form to use new widget.

Related to enterprise PR https://github.com/odoo/enterprise/pull/3266

task-1894903

closes odoo/odoo#29453</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Purpose
=======

The goal is to avoid duplicate code between portal and sign (enterprise), and
also to allow the user to use the signature mode 'auto' and 'load' in portal
(before this commit only 'draw' was available in portal).

The sales order signature (currently the only portal signature) has been changed
to use this new code.

This signature widget has been improved:

Improved style:
 - better structure and use of BS classes
 - removed most of custom CSS
 - made it more responsive

Changed code to follow guidelines, added JSDoc.

Technically
===========

New widget NameAndSignature common to portal and sign (enterprise).

Reworked existing portal signature form to use new widget.

Related to enterprise PR https://github.com/odoo/enterprise/pull/3266

task-1894903

closes odoo/odoo#29453</pre>
</div>
</content>
</entry>
<entry>
<title>[MERGE] forward port branch 12.0 up to 3e4138deaa2</title>
<updated>2019-01-09T15:56:53+00:00</updated>
<author>
<name>Christophe Simonis</name>
<email>chs@odoo.com</email>
</author>
<published>2019-01-09T15:44:05+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=8aa8548d8ab68feb13f3bde51c557db84877e809'/>
<id>8aa8548d8ab68feb13f3bde51c557db84877e809</id>
<content type='text'>
closes odoo/odoo#30045</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
closes odoo/odoo#30045</pre>
</div>
</content>
</entry>
<entry>
<title>[FIX] product,(website_)sale(*): fix product configurator</title>
<updated>2018-12-18T16:21:32+00:00</updated>
<author>
<name>Sébastien Theys</name>
<email>seb@odoo.com</email>
</author>
<published>2018-12-18T16:21:32+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=f8dad1bb4b712d8f34035420ef1f6e484c638f5b'/>
<id>f8dad1bb4b712d8f34035420ef1f6e484c638f5b</id>
<content type='text'>
This commit has several parts:

- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
	and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)

================================================================================

*** Make consistent the filtering and ordering of product variants ***

Filter &amp; Check possibility
==========================

The first variant shown on the website should always be possible.

When activating the customize "list view of variants", we don't want to show
impossible combination on the list.

We also don't want the user to be able to add to cart an impossible variant.

Show appropriate messages when no combination is possible.

Order
=====

We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.

This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value

The general order is now: (parent,) sequence, id.

Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.

On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.

Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.

================================================================================

*** Fix product template and variant price computation ***

Move and improve the get_combination_info method:

- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset

================================================================================

*** Fix currency conversions ***

The list_price and lst_price of a product are always encoded using the currency
of the product.

The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.

The prices on an order (line) are encoded with the currency of its pricelist.

================================================================================

*** Fix dynamic variants access rights ***

Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".

This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.

================================================================================

*** Miscellaneous bugs, tracebacks and necessary improvements ***

In general:
 - correctly show warning when no variant is possible
 - don't let user add to cart an impossible variant (from optional product
 	modal or from any RPC), both in interface and controller logic
 - fix as much flickering as possible by correctly pre-computing in python/views
 - move business logic from controllers to models
 - correctly add no_variant and is_custom values on the SO line description

Sale order:
 - fix traceback when emptying the product_id field from configurator

website_sale:
 - correctly compute first image / carousel, and correctly swap images when
 	changing variants, without duplicate image or zoom problems
 - don't use list view of variants when it doesn't make sense
 - added missing product info when adding a no_variant attribute to cart
 - fix cart accessory product computation

website_sale_wishlist:
 - fix it with dynamic variants, no_variant and is_custom

website_sale_comparison:
 - fix it with dynamic variants (comparison and alternative products)

website_sale_stock:
 - fix it in general (some flickering still present)

================================================================================

Authored by @seb-odoo with contribution from @awa-odoo

task-1910821

closes odoo/odoo#28079</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit has several parts:

- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
	and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)

================================================================================

*** Make consistent the filtering and ordering of product variants ***

Filter &amp; Check possibility
==========================

The first variant shown on the website should always be possible.

When activating the customize "list view of variants", we don't want to show
impossible combination on the list.

We also don't want the user to be able to add to cart an impossible variant.

Show appropriate messages when no combination is possible.

Order
=====

We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.

This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value

The general order is now: (parent,) sequence, id.

Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.

On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.

Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.

================================================================================

*** Fix product template and variant price computation ***

Move and improve the get_combination_info method:

- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset

================================================================================

*** Fix currency conversions ***

The list_price and lst_price of a product are always encoded using the currency
of the product.

The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.

The prices on an order (line) are encoded with the currency of its pricelist.

================================================================================

*** Fix dynamic variants access rights ***

Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".

This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.

================================================================================

*** Miscellaneous bugs, tracebacks and necessary improvements ***

In general:
 - correctly show warning when no variant is possible
 - don't let user add to cart an impossible variant (from optional product
 	modal or from any RPC), both in interface and controller logic
 - fix as much flickering as possible by correctly pre-computing in python/views
 - move business logic from controllers to models
 - correctly add no_variant and is_custom values on the SO line description

Sale order:
 - fix traceback when emptying the product_id field from configurator

website_sale:
 - correctly compute first image / carousel, and correctly swap images when
 	changing variants, without duplicate image or zoom problems
 - don't use list view of variants when it doesn't make sense
 - added missing product info when adding a no_variant attribute to cart
 - fix cart accessory product computation

website_sale_wishlist:
 - fix it with dynamic variants, no_variant and is_custom

website_sale_comparison:
 - fix it with dynamic variants (comparison and alternative products)

website_sale_stock:
 - fix it in general (some flickering still present)

================================================================================

Authored by @seb-odoo with contribution from @awa-odoo

task-1910821

closes odoo/odoo#28079</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] sale: reflection refund of invoices from SO in all cases</title>
<updated>2018-11-19T08:29:08+00:00</updated>
<author>
<name>jem-odoo</name>
<email>jem@openerp.com</email>
</author>
<published>2018-10-23T08:19:45+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=255816c03539147a930d79f44476c08e10832714'/>
<id>255816c03539147a930d79f44476c08e10832714</id>
<content type='text'>
When creating a credit note from an invoice coming from a Sales Order,
only the "modify" mode links the refund lines with the sale lines. This
link make the invoiced quantity decreased on the sale line, which is
a willing behavior.
The 2 other modes ("cancel", and "create") does not do that link.
As the behavior of the "modify" mode was introduced as bugfix years
ago, it was time to clean that !

This commit
- extends the behavior to every mode: all refund lines are now
linked to their origin sale lines, so the invoiced quantities
are correctly applied
- clean the bricolage used to determine the invoice of the
sales order (`_get_invoiced` method) by avoiding searching
on the document source field.
- provides some tests. The old one was moved and extended.

Task-1859308

closes odoo/odoo#28471</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When creating a credit note from an invoice coming from a Sales Order,
only the "modify" mode links the refund lines with the sale lines. This
link make the invoiced quantity decreased on the sale line, which is
a willing behavior.
The 2 other modes ("cancel", and "create") does not do that link.
As the behavior of the "modify" mode was introduced as bugfix years
ago, it was time to clean that !

This commit
- extends the behavior to every mode: all refund lines are now
linked to their origin sale lines, so the invoiced quantities
are correctly applied
- clean the bricolage used to determine the invoice of the
sales order (`_get_invoiced` method) by avoiding searching
on the document source field.
- provides some tests. The old one was moved and extended.

Task-1859308

closes odoo/odoo#28471</pre>
</div>
</content>
</entry>
<entry>
<title>[MERGE] forward port branch saas-11.4 up to 639bd896353</title>
<updated>2018-11-09T13:51:55+00:00</updated>
<author>
<name>Christophe Simonis</name>
<email>chs@odoo.com</email>
</author>
<published>2018-11-09T13:51:55+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=3e4b9d4d66c18cb620a3b6a8be76018d4ce177ec'/>
<id>3e4b9d4d66c18cb620a3b6a8be76018d4ce177ec</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] sale: new test cases for sale</title>
<updated>2018-05-22T09:52:51+00:00</updated>
<author>
<name>Hiral Bhavsar</name>
<email>hbh@odoo.com</email>
</author>
<published>2018-01-31T13:37:59+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=0ccf63cae4e66c8e3736e3d2f72f27753e01f7ad'/>
<id>0ccf63cae4e66c8e3736e3d2f72f27753e01f7ad</id>
<content type='text'>
This commit provides a test suite for sale flow and unit tests.
We split tests in different files to try regrouping them by
testing purpose:

1/ test_access_rights.py checks employee, sale person, sale manager
and portal access rights. It is executes in post-install mode to be
sure other addons does not break the security rules.

2/ test_onchange.py checks the onchange using the SFF mecanism in
order to simulate what a sale person really does in its day-to-day
job.

3/ test_sale_pricelist.py execute a sale flow with different pricelist,
as this is a delicate aspect.

4/ test_sale_to_invoice.py contains tests about refund, discount and
downpayment, as none of those were tested.

Task #43928
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit provides a test suite for sale flow and unit tests.
We split tests in different files to try regrouping them by
testing purpose:

1/ test_access_rights.py checks employee, sale person, sale manager
and portal access rights. It is executes in post-install mode to be
sure other addons does not break the security rules.

2/ test_onchange.py checks the onchange using the SFF mecanism in
order to simulate what a sale person really does in its day-to-day
job.

3/ test_sale_pricelist.py execute a sale flow with different pricelist,
as this is a delicate aspect.

4/ test_sale_to_invoice.py contains tests about refund, discount and
downpayment, as none of those were tested.

Task #43928
</pre>
</div>
</content>
</entry>
<entry>
<title>[MOV] sale: 'test_product_id_change' to 'test_onchange'</title>
<updated>2018-05-22T09:52:44+00:00</updated>
<author>
<name>Hiral Bhavsar</name>
<email>hbh@odoo.com</email>
</author>
<published>2018-02-12T11:21:25+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=ef37686b2ac54353ecf6c5ec23367026b732cde0'/>
<id>ef37686b2ac54353ecf6c5ec23367026b732cde0</id>
<content type='text'>
Renaming this file as, in next commits, we
will add more tests about onchange in that
file.

Task #43928
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Renaming this file as, in next commits, we
will add more tests about onchange in that
file.

Task #43928
</pre>
</div>
</content>
</entry>
</feed>
