Thanks for your patch will try as soon as I have some time (!).
About the situation we are facing his situation for two customers:
1) one is a book editor selling to around 1500+ bookstore in Brazil. As they
are doing "consignated sale" where only books sold to the final customers
are invoiced, it's required to maintain properly the stock of every
bookstore location, same for their supplier where they buy consigned books.
2) one of our US customer is indeed #2 in what they do in the US, they are
like a 30 employees companies, but make around 500+ sales per day via two
channels: OpenbravoPOS and Magentoerpconnect (both integrated via
base_sale_mulichannels). They need to quickly do some internal moves between
sub-locations o make their pickings more efficient and minimize travel
distance when picking products.
On Tue, May 10, 2011 at 12:14 PM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:
> Hello,
>
> Here is a patch with a more efficient rewrite of the stock reservation
> algorithm. It should be much lighter in terms of time and resources,
> even with location numbers in the thousands.
>
> You may want to try this patch in a test database, and tell if that
> works for you, and with or without side effects.
>
> Side note: managing thousands of stock locations in the same OpenERP
> database indicates that you are either in a very large multi-company
> setup, or that a granularity level is missing in OpenERP to represent
> what you need (e.g. sublocations, drawers, etc.) It would be interesting
> (from R&D point of view) to know the situation you face, so that we
> could provide better features in the future :-)
>
> I am going to upload this patch as a separate bugfix branch as well.
>
> ** Patch added: "rewrite of product reservation code"
>
> https://bugs.launchpad.net/openobject-server/+bug/770243/+attachment/2122828/+files/770243.patch
>
> --
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenERP Server.
> https://bugs.launchpad.net/bugs/770243
>
> Title:
> Creating 4000+ locations slow down the mrp module installations and
> confirming sale order.
>
> Status in OpenERP Server:
> Fix Committed
>
> Bug description:
> Hi,
> We imported 4197 locations in openerp. After that installation of mrp
> modules taking hours and conforming one sale order taking more than one
> minute. The system is slowing down on the function _product_reserve which is
> in "bin/addons/stock/stock.py" in class stock_location line 362.
>
> Sometimes it is throwing the following error
> OperationalError: out of shared memory
> HINT: You might need to increase max_locks_per_transaction.
>
> The server we are using 6.0.2 stable.
> The locations we used to import is attached with this bug report.
>
> Please improve the performance of _product_reserve function so that it
> will not hang when the number of locations are in thousands range.
>
> Thank you.
>
Hello Olivier,
Thanks for your patch will try as soon as I have some time (!).
About the situation we are facing his situation for two customers: mulichannels) . They need to quickly do some internal moves between
1) one is a book editor selling to around 1500+ bookstore in Brazil. As they
are doing "consignated sale" where only books sold to the final customers
are invoiced, it's required to maintain properly the stock of every
bookstore location, same for their supplier where they buy consigned books.
2) one of our US customer is indeed #2 in what they do in the US, they are
like a 30 employees companies, but make around 500+ sales per day via two
channels: OpenbravoPOS and Magentoerpconnect (both integrated via
base_sale_
sub-locations o make their pickings more efficient and minimize travel
distance when picking products.
On Tue, May 10, 2011 at 12:14 PM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:
> Hello, /bugs.launchpad .net/openobject -server/ +bug/770243/ +attachment/ 2122828/ +files/ 770243. patch /bugs.launchpad .net/bugs/ 770243 stock/stock. py" in class stock_location line 362. per_transaction .
>
> Here is a patch with a more efficient rewrite of the stock reservation
> algorithm. It should be much lighter in terms of time and resources,
> even with location numbers in the thousands.
>
> You may want to try this patch in a test database, and tell if that
> works for you, and with or without side effects.
>
> Side note: managing thousands of stock locations in the same OpenERP
> database indicates that you are either in a very large multi-company
> setup, or that a granularity level is missing in OpenERP to represent
> what you need (e.g. sublocations, drawers, etc.) It would be interesting
> (from R&D point of view) to know the situation you face, so that we
> could provide better features in the future :-)
>
> I am going to upload this patch as a separate bugfix branch as well.
>
> ** Patch added: "rewrite of product reservation code"
>
> https:/
>
> --
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenERP Server.
> https:/
>
> Title:
> Creating 4000+ locations slow down the mrp module installations and
> confirming sale order.
>
> Status in OpenERP Server:
> Fix Committed
>
> Bug description:
> Hi,
> We imported 4197 locations in openerp. After that installation of mrp
> modules taking hours and conforming one sale order taking more than one
> minute. The system is slowing down on the function _product_reserve which is
> in "bin/addons/
>
> Sometimes it is throwing the following error
> OperationalError: out of shared memory
> HINT: You might need to increase max_locks_
>
> The server we are using 6.0.2 stable.
> The locations we used to import is attached with this bug report.
>
> Please improve the performance of _product_reserve function so that it
> will not hang when the number of locations are in thousands range.
>
> Thank you.
>