understanding stock
lists.j...@symetrie.com
I'd like to better understand how Stock works.
1. Seems there should be only one Warehouse for a company with only one building and address. If false, when should there be another warehouse ?
2. If the company has some stock in an external logistical service, a new root location of type Storage should be created, isn't it ?
3. With another root storage location, how is it possible to have a view of the total of products (both external storage and in-house warehouse) ? I don't see how to build a view location that would supersede both. Or maybe a warehouse can be in second level in the tree ?
Thanks.
Jean-Christophe Michel
--
Symétrie
livres et partitions, édition multimédia
30 rue Jean-Baptiste Say
69001 LYON (FRANCE)
tél +33 (0)478 29 52 14
fax +33 (0)478 30 01 11
web www.symetrie.com
Bertrand Chenal
"lists.j...@symetrie.com" <lists.j...@symetrie.com> a écrit :
> Hi,
>
>
> I'd like to better understand how Stock works.
> 1. Seems there should be only one Warehouse for a company with only
> one building and address. If false, when should there be another
> warehouse ? 2. If the company has some stock in an external
> logistical service, a new root location of type Storage should be
> created, isn't it ? 3. With another root storage location, how is it
> possible to have a view of the total of products (both external
> storage and in-house warehouse) ? I don't see how to build a view
> location that would supersede both. Or maybe a warehouse can be in
> second level in the tree ?
Hi,
1. As soon as you want to manage two places for receiving/sending goods
you will need two warehouse, even in the same building.
2. In this case I would create another warehouse, but it's difficult to
say without more details.
3. Just create a location of type "view" and use it as a common parent.
HTH
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: bertran...@b2ck.com
Website: http://www.b2ck.com/
Dr. Axel Braun
> > I'd like to better understand how Stock works.
> > 1. Seems there should be only one Warehouse for a company with only
> > one building and address. If false, when should there be another
> > warehouse ? 2. If the company has some stock in an external
> > logistical service, a new root location of type Storage should be
> > created, isn't it ? 3. With another root storage location, how is it
> > possible to have a view of the total of products (both external
> > storage and in-house warehouse) ? I don't see how to build a view
> > location that would supersede both. Or maybe a warehouse can be in
> > second level in the tree ?
>
> 1. As soon as you want to manage two places for receiving/sending goods
> you will need two warehouse, even in the same building.
Question from my side: in some ERP, a warehouse can have a separate valuation
for the materials stored there - whereas different locations within a
warehouse (storage locations) have the same, but may be treated different in
terms of requirements management (MRP)
How does Tryton deal with that?
Cheers/Axel
--
Dr.-Ing. Axel K. Braun
Mobile: +49.173.7003.154
VoIP/Skype: axxite
PGP Fingerprint: CB03 964D 1CFA E87B AA63 53F3 1BD6 F53A EB48 EF22
Public Key available at http://www.axxite.com/axel....@gmx.de.asc
This mail was *not scanned* before sending.
It was sent from a secure Linux-Desktop:
IBM ThinkPad Z60m
OS: openSUSE 11.3 (i586)
Kernel: 2.6.34.10-0.6-desktop
KDE: 4.6.5 (4.6.5) "release 8"
Cédric Krier
> Am Freitag, 27. Januar 2012 schrieb Bertrand Chenal:
>
> > > I'd like to better understand how Stock works.
> > > 1. Seems there should be only one Warehouse for a company with only
> > > one building and address. If false, when should there be another
> > > warehouse ? 2. If the company has some stock in an external
> > > logistical service, a new root location of type Storage should be
> > > created, isn't it ? 3. With another root storage location, how is it
> > > possible to have a view of the total of products (both external
> > > storage and in-house warehouse) ? I don't see how to build a view
> > > location that would supersede both. Or maybe a warehouse can be in
> > > second level in the tree ?
> >
> > 1. As soon as you want to manage two places for receiving/sending goods
> > you will need two warehouse, even in the same building.
>
> Question from my side: in some ERP, a warehouse can have a separate valuation
> for the materials stored there - whereas different locations within a
> warehouse (storage locations) have the same, but may be treated different in
> terms of requirements management (MRP)
What do you mean by "separate valuation"?
What do you mean by "requirements management"?
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
lists.j...@symetrie.com
Le 27 janv. 2012 à 17:19, Bertrand Chenal a écrit :
> Le Fri, 27 Jan 2012 JC Michel a écrit :
>> 2. If the company has some stock in an external
>> logistical service, a new root location of type Storage should be
>> created, isn't it ?
>
> 2. In this case I would create another warehouse, but it's difficult to
> say without more details.
I tried with this solution. An inconvenient of this is that now, on each sale, the warehouse has to be specified. I could try to add a default warehouse in my custom module, but before, I'd like to understand what are the advantages of having a second warehouse ? I receive in this second storage place some suppliers shippings and need to plan some internal movements : I think I can do this already with a simple storage location type.
Jean-Christophe Michel
lists.j...@symetrie.com
Le 27 janv. 2012 à 12:12, lists.j...@symetrie.com a écrit :
> I'd like to better understand how Stock works.
On the same subject, I'm perplex on the purpose of stock.period.
There's nothing on it in the stock/doc.
Is it only for caching quantities ?
Is it needed to define at least one period ? (I think it's not after code reading)
Why is there only a date and not two (begin/end) to define a period ?
What impact does closing a stock period have, beyond making all moves frozen ?
Jean-Christophe Michel
lists.j...@symetrie.com
Sorry to insist.
Le 27 janv. 2012 à 17:19, Bertrand Chenal a écrit :
>> I'd like to better understand how Stock works.
In stock/doc/index.rst, the sentence
> There are six types of locations:
is followed by only 5 types : seems 'production' type is missing.
This type is not used in any place of the stock module.
Cédric Krier
> >> I'd like to better understand how Stock works.
>
> In stock/doc/index.rst, the sentence
>
> > There are six types of locations:
>
> is followed by only 5 types : seems 'production' type is missing.
> This type is not used in any place of the stock module.
Thanks to fill an issue to improve the documentation.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
> Hi,
>
> Le 27 janv. 2012 à 12:12, lists.j...@symetrie.com a écrit :
> > I'd like to better understand how Stock works.
>
> On the same subject, I'm perplex on the purpose of stock.period.
> There's nothing on it in the stock/doc.
Thanks to fill an issue to improve it.
> Is it only for caching quantities ?
Caching and side effect to prevent move before the date.
> Is it needed to define at least one period ? (I think it's not after code reading)
No.
> Why is there only a date and not two (begin/end) to define a period ?
Because it is a period from -∞ to date.
> What impact does closing a stock period have, beyond making all moves frozen ?
Nothing else.
Dr. Axel Braun
Am Samstag, 28. Januar 2012 schrieb Cédric Krier:
> On 28/01/12 08:52 +0100, Dr. Axel Braun wrote:
> > Am Freitag, 27. Januar 2012 schrieb Bertrand Chenal:
> > > > I'd like to better understand how Stock works.
> > > > 1. Seems there should be only one Warehouse for a company with only
> > > > one building and address. If false, when should there be another
> > > > warehouse ? 2. If the company has some stock in an external
> > > > logistical service, a new root location of type Storage should be
> > > > created, isn't it ? 3. With another root storage location, how is it
> > > > possible to have a view of the total of products (both external
> > > > storage and in-house warehouse) ? I don't see how to build a view
> > > > location that would supersede both. Or maybe a warehouse can be in
> > > > second level in the tree ?
> > >
> > > 1. As soon as you want to manage two places for receiving/sending goods
> > > you will need two warehouse, even in the same building.
> >
> > Question from my side: in some ERP, a warehouse can have a separate
> > valuation for the materials stored there - whereas different locations
> > within a warehouse (storage locations) have the same, but may be treated
> > different in terms of requirements management (MRP)
>
> What do you mean by "separate valuation"?
The internal value (COGS) of the stock can be different between the WHS - due
to different purchasing prices, freight charges etc in case of a moving
average price. Or just because the standard price is set different.
> What do you mean by "requirements management"?
Demand management, MRP, MPS,....
In certain cases you want to exclude some storage locations from the MRP
calculation. That may be inbound or outbound areas, buffer locations,
whatever. So there is a different view on stock between finance and plannig.
Yes, I know that tryton's MRP module is still under development...
Best,
Mindaugas Kašalynas
> On the same subject, I'm perplex on the purpose of stock.period.
> Is it only for caching quantities ?
Caching and side effect to prevent move before the date.
> Why is there only a date and not two (begin/end) to define a period ?
Because it is a period from -∞ to date.
> What impact does closing a stock period have, beyond making all moves frozen ?
Nothing else.
Cédric Krier
> So if I freeze stock.moves with closing periods, new calculations (during
> stock.move Assign/done process) will not include moves before closing date?
moves.
> We have an issue with stock move locking during assigning / run / done
> process because of 5-10 users working parallel (we use huge amounts of
> products (around 10k periodic ones)) and do not use stock period closing
> still. So process takes long time (few minutes) and during that time other
> users try to do parallel tasks.
(and so the locking time).
Also you should look if you really need the assignation process because
on large warehouse, assignation is probably not the best management
solution. Instead using fix places for products can be much more faster
and user will only record the quantity picked without prior assignation.
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Jesús Martín Jiménez
On 2015-09-17 04:18, Mindaugas Kašalynas wrote:
> So if I freeze stock.moves with closing periods, new calculations (during
> stock.move Assign/done process) will not include moves before closing date?
It will but only using the cached value and not by summing all the old
moves.
> We have an issue with stock move locking during assigning / run / done
> process because of 5-10 users working parallel (we use huge amounts of
> products (around 10k periodic ones)) and do not use stock period closing
> still. So process takes long time (few minutes) and during that time other
> users try to do parallel tasks.
That's precisely the goal of the period reduces the computation time
(and so the locking time).
Also you should look if you really need the assignation process because
on large warehouse, assignation is probably not the best management
solution. Instead using fix places for products can be much more faster
and user will only record the quantity picked without prior assignation.
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
--
Mindaugas Kašalynas
> So if I freeze stock.moves with closing periods, new calculations (during
> stock.move Assign/done process) will not include moves before closing date?
It will but only using the cached value and not by summing all the old
moves.
> We have an issue with stock move locking during assigning / run / done
> process because of 5-10 users working parallel (we use huge amounts of
> products (around 10k periodic ones)) and do not use stock period closing
> still. So process takes long time (few minutes) and during that time other
> users try to do parallel tasks.
That's precisely the goal of the period reduces the computation time
(and so the locking time).
Also you should look if you really need the assignation process because
on large warehouse, assignation is probably not the best management
solution. Instead using fix places for products can be much more faster
and user will only record the quantity picked without prior assignation.
Cédric Krier
> > > We have an issue with stock move locking during assigning / run / done
> > > process because of 5-10 users working parallel (we use huge amounts of
> > > products (around 10k periodic ones)) and do not use stock period closing
> > > still. So process takes long time (few minutes) and during that time
> > other
> > > users try to do parallel tasks.
> >
> > That's precisely the goal of the period reduces the computation time
> > (and so the locking time).
> > Also you should look if you really need the assignation process because
> > on large warehouse, assignation is probably not the best management
> > solution. Instead using fix places for products can be much more faster
> > and user will only record the quantity picked without prior assignation.
> >
> >
> Assignation helps to make warehouse qty's exact. And we will pay the price
> or that. Quite important in our business.
location (user goes to pick a product that is picked by someone else)
but what garantee the right quantities the correct input of the users.
Cédric Krier
> Hi,
>
> 2015-09-17 15:02 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
>
> > On 2015-09-17 04:18, Mindaugas Kašalynas wrote:
> > > So if I freeze stock.moves with closing periods, new calculations (during
> > > stock.move Assign/done process) will not include moves before closing
> > date?
> >
> > It will but only using the cached value and not by summing all the old
> > moves.
> >
> > > We have an issue with stock move locking during assigning / run / done
> > > process because of 5-10 users working parallel (we use huge amounts of
> > > products (around 10k periodic ones)) and do not use stock period closing
> > > still. So process takes long time (few minutes) and during that time
> > other
> > > users try to do parallel tasks.
> >
> > That's precisely the goal of the period reduces the computation time
> > (and so the locking time).
> > Also you should look if you really need the assignation process because
> > on large warehouse, assignation is probably not the best management
> > solution. Instead using fix places for products can be much more faster
> > and user will only record the quantity picked without prior assignation.
> >
>
> Is there any module that implements that way of working?
there is a module to remove the assignation (maybe it could be a
standard option).
Mindaugas Kašalynas
> So if I freeze stock.moves with closing periods, new calculations (during
> stock.move Assign/done process) will not include moves before closing date?
It will but only using the cached value and not by summing all the old
moves.
Cédric Krier
>
>
> > So if I freeze stock.moves with closing periods, new calculations (during
> >> > stock.move Assign/done process) will not include moves before closing
> >> date?
> >>
> >> It will but only using the cached value and not by summing all the old
> >> moves.
> >
> >
> Hello Again,
>
> We have checked situation when Assign process is compared to the not closed
> periods (we have checked Internal shipment with 140 lines), with closed
> period (180k move lines "closed" and 33k "open") it was made in roughly
> 83seconds and without closed period it was made in 87 seconds (when all
> 213k moves were "open"). So 4,5% improvement...
>
> Which is not so much :)
> However we have quite a numbers of moves, roughly around 250 k
> While not redoing the Assignation process, what would be ideas to speed up
> the process? Which part of Server should be altered?
write/copy. The write could probably be optimized to be combined but
hardly the copy.
Also the call to assign could be done at the end with all the moves.
Finaly, the search of child location inside the loop could be
externalized with a cache.
Mindaugas Kašalynas
> We have checked situation when Assign process is compared to the not closed
> periods (we have checked Internal shipment with 140 lines), with closed
> period (180k move lines "closed" and 33k "open") it was made in roughly
> 83seconds and without closed period it was made in 87 seconds (when all
> 213k moves were "open"). So 4,5% improvement...
>
> Which is not so much :)
Normal you have optimized one call made by Move.assign_try.
> However we have quite a numbers of moves, roughly around 250 k
I don't understand for me you should have 180k + 33k = 210k.
> While not redoing the Assignation process, what would be ideas to speed up
> the process? Which part of Server should be altered?
The drawback is that the Move.assign_try is doing a lot of single
write/copy. The write could probably be optimized to be combined but
hardly the copy.
Also the call to assign could be done at the end with all the moves.
Finaly, the search of child location inside the loop could be
externalized with a cache.
Cédric Krier
https://bugs.tryton.org/issue5033
I did not measure the improvement, it will be great if you can do it on
your setup.
Thanks,
Mindaugas Kašalynas
As I was already there, here is the patch:
https://bugs.tryton.org/issue5033
I did not measure the improvement, it will be great if you can do it on
your setup.
--
Cédric Krier
First, what do you measure? Is it from the client (between click and
refresh)? If yes, how much time to you need to open the shipment form?
Second, how is the result? Is there a lot of moves that are splitted?
Mindaugas Kašalynas
> corrected data:
>
> Inventory Move 144 lines
> no patch / no closed period
> around 120 seconds
> no patch / closed period
> around 113-114 seconds
> patch / no closed perods
> 120 seconds
> patch / closed periods
> 110 seconds
>
> so all in all around 8-9% improvment. Which is not much. However I have
> tested on different server that same shipment and times where around 90-95
> seconds.
Could you give more information about your test.
First, what do you measure? Is it from the client (between click and
refresh)? If yes, how much time to you need to open the shipment form?
Second, how is the result? Is there a lot of moves that are splitted?
Cédric Krier
database up to date?
Mindaugas Kašalynas
> I measure from client between click and refresh. (in controlled idle
> server), it takes around 2-3 seconds to open the form.
> Result was without any splits.
Do you have slow queries in the database log? Is the statistic of the
database up to date?
--
Cédric Krier
Cédric Krier
> > > server), it takes around 2-3 seconds to open the form.
> > > Result was without any splits.
> >
> > Do you have slow queries in the database log? Is the statistic of the
> > database up to date?
> >
>
> sent you database logs.
that after each update of stock_move I see between 5-15 more queries
which are clearly for validation. This means that the write was not
grouped as my patch does.
By the way, it looks like you have customise the Model res.group to have
a default order by name. This has a cost on performence because it is a
translated field which means it has to generate a not so optimized
query.
[1] https://bugs.tryton.org/issue5033
Raimon Esteve
> On 2015-10-14 09:14, Mindaugas Kašalynas wrote:
>> > > I measure from client between click and refresh. (in controlled idle
>> > > server), it takes around 2-3 seconds to open the form.
>> > > Result was without any splits.
>> >
>> > Do you have slow queries in the database log? Is the statistic of the
>> > database up to date?
>> >
>>
>> sent you database logs.
>
> For me, you are not running with my patch [1] as I can see in the log
> that after each update of stock_move I see between 5-15 more queries
> which are clearly for validation. This means that the write was not
> grouped as my patch does.
>
> By the way, it looks like you have customise the Model res.group to have
> a default order by name. This has a cost on performence because it is a
> translated field which means it has to generate a not so optimized
> query.
>
> [1] https://bugs.tryton.org/issue5033
Thanks
Raimon