# Goods product replacement

**URL:** https://discuss.tryton.org/t/goods-product-replacement/7608
**Category:** Feature
**Tags:** stock
**Created:** [August 26, 2024, 2:46pm UTC](https://discuss.tryton.org/t/goods-product-replacement/7608 "2024-08-26T14:46:05Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [August 26, 2024, 2:46pm UTC](https://discuss.tryton.org/t/goods-product-replacement/7608/1 "2024-08-26T14:46:05Z")

</div>

## Rational

It may happen that a goods is no more available at the supplier (This is often the case in the spare parts business).  
But usually there is a replacement goods that is equivalent.

Currently in such case, the user has to find all the draft outgoing moves and replace the product on it, deactivate the old products (or at least make it unsalable).  
He may also need to update the draft incoming moves for the purchase that the supplier has changed.

There are few issues with this process:

- it is not error prone
- products can not be deactivated if there are still stock
- existing stock will not be consumed first
- there is no history record about the replacement

## Proposal

We provide a wizard to replace a product of type goods by another product of type goods. It stores on the replaced product the link to the new one (it must have the same category of unit of measures).

The record name search of the product is extended to search also on the replaced products codes.

A task is created that search for active replaced products that have no more stock in storage location. It deactivates the products (active, salable, purchasable) and replace on all the draft/staging stock moves.  
When a stock move with a replaced product is done, the task is queued for the products. The task is also run periodically (daily).

Once a replaced product is deactivated, it can not be reactivated.  
When sale and purchase creates stock moves for a replaced product that is also deactivated, they replace the product (this is to avoid having stock move created after the update if the processing is delayed). Idem for BOM explode

_The user will be left responsible to change the supply configuration to avoid purchase again a replaced product._

## Implementation

- [Manage to replace products (!1734) · Merge requests · Tryton / Tryton · GitLab](https://foss.heptapod.net/tryton/tryton/-/merge_requests/1734)

---

<div class="post-metadata">

### Author: ![acaubet](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/acaubet/32/1493_2.png) [@acaubet](https://discuss.tryton.org/u/acaubet)
#### Post date: [August 27, 2024, 10:30am UTC](https://discuss.tryton.org/t/goods-product-replacement/7608/2 "2024-08-27T10:30:42Z")

</div>

Generally, I like the proposal, but I have another use case for what some assertions are not valid, or maybe I did not understand the assertion.

What you call equivalent replacement good, we usually called substitute products.

- **CASE 1.** The product is available to buy, but a equivalent product is cheaper, so we buy and produce using the equivalent for some time. (while is cheaper)
- **CASE 2.** The product is out of stock for some time. So the equivalent is our only choice while supply is coming. But when the principal product will be available, I will prefer to have again the principal.

> Once a replaced product is deactivated, it can not be reactivated.

Why? In both cases, I will try again to buy in the future the replaced product.

Interesting things to do with substitute products:

- Allow the definition of substitute products directly within the BOM. Each input could have a list of approved substitutes, ranked by cost / preference.
- Set conditions to switch to a substitute product, depending on the lead time and delivery date. Or by suggesting equivalent products with lots with a near Expiration Date.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [August 27, 2024, 1:05pm UTC](https://discuss.tryton.org/t/goods-product-replacement/7608/3 "2024-08-27T13:05:04Z")

</div>

> [@acaubet](#):
>
> - **CASE 1.** The product is available to buy, but a equivalent product is cheaper, so we buy and produce using the equivalent for some time. (while is cheaper)
> - **CASE 2.** The product is out of stock for some time. So the equivalent is our only choice while supply is coming. But when the principal product will be available, I will prefer to have again the principal.

Those are temporal substitution. I think it should be managed differently (and not by this proposal) by a rule system but of course there will be hijacking the same way the orders to create stock move of substituted products.

> [@acaubet](#):
>
> > Once a replaced product is deactivated, it can not be reactivated.
> 
> Why?

Because we do not want to launch again the task to deactivate the product.  
But indeed I would see no problem to reactivate the product if the replaced link it removed.

> [@acaubet](#):
>
> Interesting things to do with substitute products:
> 
> - Allow the definition of substitute products directly within the BOM. Each input could have a list of approved substitutes, ranked by cost / preference.
> - Set conditions to switch to a substitute product, depending on the lead time and delivery date. Or by suggesting equivalent products with lots with a near Expiration Date.

Those would be solved by match-pattern of the rule engine.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [September 3, 2024, 10:11am UTC](https://discuss.tryton.org/t/goods-product-replacement/7608/4 "2024-09-03T10:11:55Z")

</div>

> [@ced](#):
>
> We provide a wizard to replace a product of type goods by another product of type goods.

I did not restricted to only goods as it may be useful for other type.

> [@ced](#):
>
> It deactivates the products (active, salable, purchasable)

I just deactivate the product. I do not think it is necessary to remove the other options. User may decide when they want to stop them.

> [@ced](#):
>
> replace on all the draft/staging stock moves.

I decided to deleted those moves. And let the system recreate them with different product. This is mainly because with the lot module, a lot may be also set which will be incompatible with the new product.

> [@ced](#):
>
> Once a replaced product is deactivated, it can not be reactivated.

I did not enforce this. But if the user reactivate the product, it will be deactivate again by the scheduled task. Instead I allowed to clear the “Replaced By” in case of mistake.

> [@ced](#):
>
> When sale and purchase creates stock moves for a replaced product that is also deactivated, they replace the product

Instead I modified the `Move.create` method to replace the product automatically. This has the benefit to avoid the need to extend every modules.
