[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).

sale-workflow/sale_order_product_recommendation/tests/test_recommendation_common.py

Lines 53 to 60 in be211dc

	cls.prod_2 = cls.product_obj.create(
	{
	"name": "Test Product 2",
	"type": "service",
	"list_price": 50.00,
	"categ_id": cls.cat_b.id,
	}
	)

sale-workflow/sale_order_product_recommendation/tests/test_recommendation_common.py

Lines 114 to 135 in be211dc

	cls.order2 = cls.env["sale.order"].create(
	{
	"partner_id": cls.partner.id,
	"partner_shipping_id": cls.partner_delivery.id,
	"locked": "True",
	"date_order": "2021-05-03",
	"order_line": [
	(
	0,
	0,
	{
	"product_id": cls.prod_2.id,
	"name": cls.prod_2.name,
	"product_uom_qty": 50,
	"qty_delivered_method": "manual",
	"qty_delivered": 50,
	"price_unit": 89.00,
	},
	),
	],
	}
	)

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.

[AungKoKoLin1997]

Close this PR since it shares the same behavior with existing one.
#4159