[IMP] rma: custom route for replace action

[sbejaoui]

RMA replacement orders currently use the default delivery route, which results in their creation under the default delivery picking type. While this behavior works, it prevents users from tracking RMA replacement orders separately from regular deliveries.

This PR introduces a new field, rma_out_replace_route_id, to the warehouse. If set, this field specifies a custom route for RMA replacement actions, allowing users to separate RMA replacement orders from standard deliveries and manage them independently. If the field is not set, the default delivery route will continue to be used.

[OCA-git-bot]

Hi @pedrobaeza, @chienandalu,
some modules you are maintaining are being modified, check this out!

[pedrobaeza]

We are going to need more routes than the a highway, hehe

[rousseldenis]

@sbejaoui Should'nt we use the mechanisms to create that route (see _get_route_values()) ?

[sbejaoui]

I believe the common use case is to use the default delivery route, which is why I didn't create or assign a custom route to the warehouse. If more people feel that having a custom route for RMA delivery by default is necessary, I will make the change.

[jbaudoux]

Why only for replace and not for all RMA deliveries?

While it's doing the job, I'm not sure it's a good approach. You can configure specific warehouse behavior by configuring a route on a product or product category. This is even more important in newer versions of odoo where you can configure a route on the carrier. If you force a route from rma, you are overriding those configurations.

From what I understood, you want to isolate the rma delivery from other deliveries. However, this is already the case as you have a dedicated procurement group for the rma delivery. The issue arise when you use the stock_picking_group_by_partner_by_carrier module that regroup deliveries for a same partner. In my opinion, a cleaner approach is to create a glue module with an option on the picking type to disable rma grouping.

[sbejaoui]

Why only for replace and not for all RMA deliveries?

The rma module differentiates between replacement and delivery actions. In the case of a replacement, the product is picked from stock, while for delivery, it’s picked from the RMA location.
To support this, there’s an existing route for delivery (rma_out_route_id). IMO, allowing the configuration of a separate route for replacements aligns it more closely with the delivery process and adds flexibility to manage both workflows.

While it's doing the job, I'm not sure it's a good approach. You can configure specific warehouse behavior by configuring a route on a product or product category. This is even more important in newer versions of odoo where you can configure a route on the carrier. If you force a route from rma, you are overriding those configurations.

I agree, the use of routes in the rma module should be reconsidered to better align with the Odoo standard. While I don’t have specific ideas yet on how to achieve this alignment, my point is that this PR follows the existing logic in the module and doesn’t introduce any new approaches or changes to the current structure.

rma/rma/models/stock_warehouse.py

Lines 23 to 30 in 9f19281

	rma_out_type_id = fields.Many2one(
	comodel_name="stock.picking.type",
	string="RMA Out Type",
	)
	rma_loc_id = fields.Many2one(
	comodel_name="stock.location",
	string="RMA Location",
	)

From what I understood, you want to isolate the rma delivery from other deliveries. However, this is already the case as you have a dedicated procurement group for the rma delivery. The issue arise when you use the stock_picking_group_by_partner_by_carrier module that regroup deliveries for a same partner. In my opinion, a cleaner approach is to create a glue module with an option on the picking type to disable rma grouping.

One reason for grouping pickings is indeed the stock_picking_group_by_partner_by_carrier, but that's not the only reason.
Another important reason is to assign deliveries to the rma picking type, which provides them with a distinct sequence number, separate from the default delivery sequence.
This differentiation is important for delivery managers, as it allows them to easily identify rma deliveries by their reference in delivery documents and in the tree view,..
Additionally, having separate sequences ensure accurate reporting, allowing rma deliveries to be excluded from standard sales delivery statistics if we analyse stock.picking data.

[jbaudoux]

The rma module differentiates between replacement and delivery actions. In the case of a replacement, the product is picked from stock, while for delivery, it’s picked from the RMA location. To support this, there’s an existing route for delivery (rma_out_route_id). IMO, allowing the configuration of a separate route for replacements aligns it more closely with the delivery process and adds flexibility to manage both workflows.

Thanks for the clarification. I had another look with your comment in mind and I do understand there is a create_replace method that creates the delivery for the replacement. However, I do not understand why this is not calling the already existing _prepare_delivery_procurements instead of _prepare_replace_procurements as this is for creating the delivery. There you can configure the route as you mentioned, so that would drop the need for another route in case of replace only.
In regards of where it is picked, it is up to you to configure the route if you want to use a specific one. The fact that the customer returns or not a faulty part should not impact how you will pick the new part from your stock, so I don't see why having 2 different routes. @mt-software-de Maybe you can clarify why you used 2 separate methods?

cc @phschmidt

[mt-software-de]

The rma module differentiates between replacement and delivery actions. In the case of a replacement, the product is picked from stock, while for delivery, it’s picked from the RMA location. To support this, there’s an existing route for delivery (rma_out_route_id). IMO, allowing the configuration of a separate route for replacements aligns it more closely with the delivery process and adds flexibility to manage both workflows.

Thanks for the clarification. I had another look with your comment in mind and I do understand there is a create_replace method that creates the delivery for the replacement. However, I do not understand why this is not calling the already existing _prepare_delivery_procurements instead of _prepare_replace_procurements as this is for creating the delivery. There you can configure the route as you mentioned, so that would drop the need for another route in case of replace only. In regards of where it is picked, it is up to you to configure the route if you want to use a specific one. The fact that the customer returns or not a faulty part should not impact how you will pick the new part from your stock, so I don't see why having 2 different routes. @mt-software-de Maybe you can clarify why you used 2 separate methods?

cc @phschmidt

Sorry @jbaudoux , but as I already wrote, I will not be contributing to the RMA Reop any more for now.
As a little help, there are two methods because the requirements are different. This was already the case before I contributed to it. My customer never used create_replace.