Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IMP] stock: Add hybrid procure method 'mts_else_mto' #32778

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
6 participants
@arbaes
Copy link
Contributor

commented Apr 17, 2019

In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a procure_method named mts_else_mto,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this, we apply the MTS or the MTO procure_method
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:
With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.

Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:

  • MTO (procure method MTO): 2m30s to confirm the SO (800 PO Lines created)
  • MTO (procure method MTS_ELSE_MTO): 2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

@robodoo robodoo added the seen 🙂 label Apr 17, 2019

@arbaes arbaes force-pushed the odoo-dev:master-mtso-arb branch from 1b9e060 to 10fc0a0 Apr 17, 2019

@C3POdoo C3POdoo added the RD label Apr 17, 2019

forecasted_qties_dict = {}
for qty_dict in forecasted_qties:
forecasted_qties_dict[qty_dict['id']] = qty_dict['virtual_available']
forecasted_qties_by_loc[location] = forecasted_qties_dict

This comment has been minimized.

Copy link
@sle-odoo

sle-odoo Apr 17, 2019

Contributor

!!to check with the prefetching!!

products = self.env['product.product'].browse(product_ids).with_context(location=location.id)
forecasted_qties_by_loc[location] = {product.id: product.virtual_available for product in products}

@robodoo robodoo added the CI 🤖 label Apr 17, 2019

@arbaes arbaes force-pushed the odoo-dev:master-mtso-arb branch from 10fc0a0 to 025e383 Apr 17, 2019

@robodoo robodoo removed the CI 🤖 label Apr 17, 2019

@arbaes arbaes force-pushed the odoo-dev:master-mtso-arb branch 2 times, most recently from 4e57771 to d647581 Apr 17, 2019

@robodoo robodoo added the CI 🤖 label Apr 17, 2019

@inspiredbusiness
Copy link

left a comment

If draft purchase orders are not included in forecasted stock will this case work?

Initial setup:
Stock on hand = 5 units
Forecast = 5 units

Sale of 7 units confirmed
Delivery of 7 units is created (5 mts, 2 mto)
Draft PO is created for 2 units(Incoming shipment for 2 units is not created yet as PO is draft)

Stock on hand = 5
Forecast = -2

A second sale order for 7 units is confirmed
Delivery of 7 units is created (0 mts, 7 mto)
Draft PO is created /added to for 9 units (Incoming shipment for 7 units is not created yet) (goal to get forecast to zero?)

Both POs are confirmed

  • 2 incoming deliveries created for 9 units in total

Once all deliveries are completed

  • total sold = 14
  • total purchased = 11
  • total that should have been purchased = 9
  • stock on hand = 2
  • forecast = 2

If this is correct than the system will order too many units if draft PO is not included in forecast calculation. I think this may have been a limitation in the OCA version of this. Hopefully I got my numbers right.

This will be great to see this kind of feature in Odoo we have a few clients that use this kind of setup

@sle-odoo

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

@inspiredbusiness

Sale of 7 units confirmed
Delivery of 7 units is created (5 mts, 2 mto)

We chose to not split the procurement in an mts and an mto move, as explained in the commit message. If there is enough in stock, one mts move, if not, one mto move.

Delivery of 7 units is created (0 mts, 7 mto)
Draft PO is created /added to for 9 units (Incoming shipment for 7 units is not created yet) (goal to get forecast to zero?)

In this case a second po line will be added for 7 units, not 9. The MTO goal is not to reset the forecast to 0, maybe you're thinking of a reordering rule 00 ?

@arbaes arbaes marked this pull request as ready for review Apr 18, 2019

@inspiredbusiness

This comment has been minimized.

Copy link

commented Apr 18, 2019

I see, it is not like the OCA module for this at all then. The split method is key for several of our clients. While this module and some value it won't help for some of our clients as stock will just be left on the shelf until an order small enough to use what is on the shelf. Ie. If 1 unit is in stock I think then this module will ignore this until someone buys exactly 1 unit. Otherwise this module will use mto and order for each sale and not use what is in stock

Any chance this could support the same features as per this module commented on the previous PR for this feature?

#32642 (comment)

@arbaes

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

Any chance this could support the same features as per this module commented on the previous PR for this feature?

Actually all of this is a first step, we want to keep it simple for now as a splitting logic will heavily complexify the code. But the splitting logic will probably be the next step.

@inspiredbusiness

This comment has been minimized.

Copy link

commented Apr 19, 2019

It could be worth checking out the OCA code listed. They did it in a pretty simple way. I understand to do it in steps. Would be great if Odoo supports splitting

@pedrobaeza

This comment has been minimized.

Copy link
Collaborator

commented Apr 19, 2019

The problem I see with current approach is that there will always be a stock remainder that won't be shipped from warehouse unless the sales order is less or equal to that quantity. Imagine an scenario where you deal with expiry dates: you will always waste a lot of quantity. Please consider the procurement split (now that the are no more procurement.order records, it's even simpler). The only drawback I see with current implementation is that there's going to be 2 stock.move records for the same product in these cases, but very small price for having this feature. For avoiding this, a change from many2one to many2many/one2many would be needed on the "procurement" links, which I understand that is a very huge change, but the other one can be a good intermediate option.

[IMP] stock: Add hybrid procure method 'mts_else_mto'
In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a `procure_method` named `mts_else_mto`,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this,  we apply the MTS or the MTO `procure_method`
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:

With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.
Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:
MTO (procure method MTO):
2m30s to confirm the SO (800 PO Lines created)
MTO (procure method MTS_ELSE_MTO):
2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

@arbaes arbaes force-pushed the odoo-dev:master-mtso-arb branch from d647581 to 691e894 Apr 24, 2019

@robodoo robodoo removed the CI 🤖 label Apr 24, 2019

@sle-odoo

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

@pedrobaeza Hi,
Having two stock moves for the same product is functionally ugly:

  • one move of product1 initial demand 13
  • another move of product1 initial demand 17
  • one is reserving the other not, why?
  • i want to process a single move line of 30 and the system proposes me to do a backorder, why?

We think this is too confusing with the current interface. Anyway this branch is a starting point and will do more good than bad. I created an internal feedback with what you said, we'll definitely think about it. I also don't think we need a change in the models to handle it, just pushing another dict of move values with what's missing would do the trick.

robodoo r+

robodoo pushed a commit that referenced this pull request Apr 24, 2019

[IMP] stock: Add hybrid procure method 'mts_else_mto'
In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a `procure_method` named `mts_else_mto`,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this,  we apply the MTS or the MTO `procure_method`
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:

With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.
Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:
MTO (procure method MTO):
2m30s to confirm the SO (800 PO Lines created)
MTO (procure method MTS_ELSE_MTO):
2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

closes #32778

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
@pedrobaeza

This comment has been minimized.

Copy link
Collaborator

commented Apr 24, 2019

Thanks for considering it, Simon! Indeed 2 stock.move are not the ideal, but it was my deduction about the problem for implementing directly the split. If you have other thing in mind, then great and eagering to see it. I agree any way that this one is a good improvement over current situation.

@robodoo robodoo added merged 🎉 and removed merging 👷 labels Apr 24, 2019

@robodoo

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

Merged, thanks!

@robodoo robodoo closed this Apr 24, 2019

Deiber pushed a commit to xoe-labs/odoo-dev that referenced this pull request Apr 30, 2019

[IMP] stock: Add hybrid procure method 'mts_else_mto'
In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a `procure_method` named `mts_else_mto`,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this,  we apply the MTS or the MTO `procure_method`
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:

With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.
Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:
MTO (procure method MTO):
2m30s to confirm the SO (800 PO Lines created)
MTO (procure method MTS_ELSE_MTO):
2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

closes odoo#32778

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Deiber pushed a commit to xoe-labs/odoo-dev that referenced this pull request Apr 30, 2019

[IMP] stock: Add hybrid procure method 'mts_else_mto'
In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a `procure_method` named `mts_else_mto`,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this,  we apply the MTS or the MTO `procure_method`
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:

With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.
Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:
MTO (procure method MTO):
2m30s to confirm the SO (800 PO Lines created)
MTO (procure method MTS_ELSE_MTO):
2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

closes odoo#32778

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Deiber pushed a commit to xoe-labs/odoo-dev that referenced this pull request Apr 30, 2019

[IMP] stock: Add hybrid procure method 'mts_else_mto'
In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a `procure_method` named `mts_else_mto`,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this,  we apply the MTS or the MTO `procure_method`
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:

With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.
Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:
MTO (procure method MTO):
2m30s to confirm the SO (800 PO Lines created)
MTO (procure method MTS_ELSE_MTO):
2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

closes odoo#32778

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Deiber pushed a commit to xoe-labs/odoo-dev that referenced this pull request Apr 30, 2019

[IMP] stock: Add hybrid procure method 'mts_else_mto'
In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a `procure_method` named `mts_else_mto`,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this,  we apply the MTS or the MTO `procure_method`
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:

With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.
Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:
MTO (procure method MTO):
2m30s to confirm the SO (800 PO Lines created)
MTO (procure method MTS_ELSE_MTO):
2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

closes odoo#32778

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

blaggacao added a commit to xoe-labs/odoo-dev that referenced this pull request May 4, 2019

[IMP] stock: Add hybrid procure method 'mts_else_mto'
In some occasions, products can be available in a location,
but are still ignored when the MTO is set on those products.
(e.g.: When a product is returned)

To avoid this, we add a `procure_method` named `mts_else_mto`,
allowing procurement to reserve the products if enough of them
are available in his source location.
In order to achieve this,  we apply the MTS or the MTO `procure_method`
on the moves from the procurement depending on whether or not there are
enough quantities of the needed products in the source location
('All or nothing' logic).

Quick performance test:

With a Sale Order of 800 differents products set as MTO+Buy,
Half of these products available in stock.
Before the patch :
2m30s to confirm the SO (800 PO Lines created)

After the patch:
MTO (procure method MTO):
2m30s to confirm the SO (800 PO Lines created)
MTO (procure method MTS_ELSE_MTO):
2m26s to confirm the SO (400 PO Lines created)

TaskID: 1831347

closes odoo#32778

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.