[18.0][ADD] sale_pricelist_delivery_date

[AungKoKoLin1997]

This module allows users to calculate the unit price of sale order lines based on the delivery date of the sales order.

@qrtl QT5925

[AungKoKoLin1997]

I am a bit confused about the test failures in CI. I checked the modules that fail in CI using my development environment, but the failures are not the same. In my dev environment, only the following test case fails.

2021-10-02 15:30:00,000 3068706 ERROR 5odoo183 odoo.addons.sale_order_product_recommendation.tests.test_recommendation: FAIL: RecommendationCaseTests.test_recommendations_price_origin
Traceback (most recent call last):
  File "/home/lin/ws/odoo18/sale-workflow/sale_order_product_recommendation/tests/test_recommendation.py", line 268, in test_recommendations_price_origin
    self.assertEqual(wiz_line_prod2.price_unit, 89.00)
AssertionError: 50.0 != 89.0

As far as I can see, the reason is that technical_price_unit has the same value as price_unit at creation time, even though the product’s list price is different from the assigned price_unit (89). https://github.com/OCA/sale-workflow/blob/be211dcacc8dbd39192706fd4a02d95d969dd7a6/sale_order_product_recommendation/tests/test_recommendation_common.py#L53-L60

https://github.com/OCA/sale-workflow/blob/be211dcacc8dbd39192706fd4a02d95d969dd7a6/sale_order_product_recommendation/tests/test_recommendation_common.py#L114-L135

When I reproduce the same workflow in the UI, these two fields have different values (50 and 89).

Because of this, when date_order is changed in the test case and _compute_price_unit is triggered, it does not treat the line as having a manual price (see has_manual_price), and it recalculates price_unit, which causes the test failure. https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L563-L570

I haven’t found an optimal solution yet, so any suggestions or guidance would be very welcome.

[AungKoKoLin1997]

As far as I can see, the reason is that technical_price_unit has the same value as price_unit at creation time, even though the product’s list price is different from the assigned price_unit (89).

I think this may be the case. https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1274-L1278

[yostashiro]

As far as I can see, the reason is that technical_price_unit has the same value as price_unit at creation time, even though the product’s list price is different from the assigned price_unit (89).

I think this may be the case. https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1274-L1278

Looks like it is. In that case, I suppose changing the way https://github.com/OCA/sale-workflow/blob/18.0/sale_order_product_recommendation/tests/test_recommendation_common.py creates order lines may fix the issue? The lines should first be created with no price_unit assignment, so precompute is not interfered with, and then updated later with a price_unit value.