Le 30/05/2015 09:13, Cédric Krier a écrit :
On 29 May 18:52, Raimon Esteve wrote:
2015-05-29 17:05 GMT+02:00 Cédric Krier <[email protected]>:
On 29 May 16:47, Raimon Esteve wrote:
2015-05-29 13:28 GMT+02:00 Cédric Krier <[email protected]>:
On such operational error, trytond retries 5 times per default [1] if it
is not enough for your setup you should increase it.
Or maybe you have a too long transaction keeping the lock, in such case
you must reduce the time of this transaction.

Yes, it is => A transaction is very longer. For example, try assing
500 shipments it will be spent some long time (~ 10 o 15 minuts) and
stock.move is locked.

This is crazy.

It's real life ;)

You do what you want with your life but personnaly I tend to avoid doing
crazy stuff.

In this case, increase retries option can't work.

Yes if you put a very very high number :-)

Yes, but some times is 10 repeats, other 20 repeats or 999 repeats

It was sarcasm.

I think we could do transaction in blocks (for example, each 10
shipments) to lock/unlock table and other transaction could do some
task.

No this is not the proper design.
You must make a request for each shipment with a loop to retry etc.

But any way, if you need to assign at once 500 shipments, you clearly
don't use the right worflow design. This is something else but I can not
help more with knowing the business context.

For example,

at 10 AM you recived 1000 sales requests. 700 sales are confirmed =
generated 700 shipments out.

Only have stock available to packed 200 shipments (200/700 shipments).
The rest, 500 shipments, you do a new purchase at "Fast Supplier".
Those products you don't have stock and you will recived at 15 PM.

At 16 PM, you need to "assign" the last 500 shipments because you have
stock available.

Finally, at 19 PM, a carrier, he picking all 700 shipments. Tomorrow,
700 shipments delivered at customer home.

Next day, repeat operation. Also, at weekend ;)

Conclusion:
it's necessary to lock table (mysql not lock) in stock.move but when
there are a long operation (a longer transaction) there are a
"conflict" with other user do stock.move with "manual" operation
because lock table.

I disagree with this conclusion.
In the all process, I see no actual needs to make assignation if you
have a good warehouse argonisation (which is required with such
numbers).
Assignation is there to tell the user where to pick the product, you can
skip this by knowing in advance where to pick them. (and also avoid user
conflict)


I do not agree with this last statement, especially if you have a large warehouse, you must specified where is the products to be prepared. In addition, the order picker may come from temporary agency, they do not know the warehouse. Finally, inventory turnover may require that the location is provided to the preparer.


--
Christophe
http://adiczion.com

Reply via email to