Lot Management
Albert Cervera i Areny
We need to implement lot management in Tryton and I've created a blueprint for that [1]. Hope we can collect your comments there and in the mailing list.
Thanks!
[1] http://code.google.com/p/tryton/wiki/LotManagement
--
Albert Cervera i Areny
Tel: +34 93 553 18 03
Cédric Krier
> We need to implement lot management in Tryton and I've created a blueprint for
> that [1]. Hope we can collect your comments there and in the mailing list.
>
> Thanks!
>
> [1] http://code.google.com/p/tryton/wiki/LotManagement
Here is my review:
- "Add 'stock.lot' model with just the "Number" field as fields.Char()"
I think better name is product.lot in his own module because you can
want to use it without stock management.
It requires a link to product.product and move could only use lot of
the same product.
- "Adapt assign_try() and pick_product() to take 'lot' field into
account."
I'm not sure this is good. For me, lot is more like a tag on moves and
it should not prevent to validate the move.
Also I think such behavior will be very resource consuming.
- "Add a new products_by_location_and_lot() function, similar to
products_by_location() that will use (product, location, lot) as key
and will return the quantities."
product and lot are duplicate informations if there is a link between
lot and product.
But I'm not sure it will be useful. I think it will be better to have
a view that shows all the move of a lot (perhaps a Tree).
- "Add 'lot' field to all shipment views."
It will be done on stock.move once nested views are removed.
--
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/
Albert Cervera i Areny
A Dimecres, 25 de gener de 2012 13:45:25, C�dric Krier va escriure:
> On 16/12/11 09:37 +0100, Albert Cervera i Areny wrote:
> > We need to implement lot management in Tryton and I've created a
> > blueprint for that [1]. Hope we can collect your comments there and in
> > the mailing list.
> >
> > Thanks!
> >
> > [1] http://code.google.com/p/tryton/wiki/LotManagement
>
> Here is my review:
>
> - "Add 'stock.lot' model with just the "Number" field as fields.Char()"
>
> I think better name is product.lot in his own module because you can
> want to use it without stock management.
> It requires a link to product.product and move could only use lot of
> the same product.
Can't think of a use-case myself, but I see no problems with it. The less dependencies the better.
> - "Adapt assign_try() and pick_product() to take 'lot' field into
> account."
>
> I'm not sure this is good. For me, lot is more like a tag on moves and
> it should not prevent to validate the move.
> Also I think such behavior will be very resource consuming.
I think it should. Of course, we can discuss on what's the best default behaviour of stock_lot module, but I'm sure that many companies will need to be sure that the current stock levels are ok and that includes the exact lots available. If you cannot rely on that, it has no sense to manage lots (at least, in many use cases).
> - "Add a new products_by_location_and_lot() function, similar to
> products_by_location() that will use (product, location, lot) as key
> and will return the quantities."
>
> product and lot are duplicate informations if there is a link between
> lot and product.
> But I'm not sure it will be useful. I think it will be better to have
> a view that shows all the move of a lot (perhaps a Tree).
It's true that it is duplicate, it would probably be enough with location and lot.
> - "Add 'lot' field to all shipment views."
>
> It will be done on stock.move once nested views are removed.
Yes, that's a great improvement ;-)
Cédric Krier
> A Dimecres, 25 de gener de 2012 13:45:25, Cédric Krier va escriure:
> > On 16/12/11 09:37 +0100, Albert Cervera i Areny wrote:
> > - "Adapt assign_try() and pick_product() to take 'lot' field into
> > account."
> >
> > I'm not sure this is good. For me, lot is more like a tag on moves and
> > it should not prevent to validate the move.
> > Also I think such behavior will be very resource consuming.
>
> I think it should. Of course, we can discuss on what's the best default
> behaviour of stock_lot module, but I'm sure that many companies will need to
> be sure that the current stock levels are ok and that includes the exact lots
> available. If you cannot rely on that, it has no sense to manage lots (at
> least, in many use cases).
For me, I see it as a blocking stuffs that will be very annoying.
If the user pick a product with the wrong lot number, the next guys who
will need to pick the same product, the system will prevent him to do it
because it is the wrong number.
For me, it should really be like a tag and even we should be able to
modify it after the move was done. And it makes no sense to have the
system telling to the user to pick the lot number X out of thousand of
same products from a location.
Bertrand Chenal
Cédric Krier <cedric...@b2ck.com> a écrit :
> - "Adapt assign_try() and pick_product() to take 'lot' field into
> account."
>
> I'm not sure this is good. For me, lot is more like a tag on moves
> and it should not prevent to validate the move.
IMO there is at least two use case for lots:
A) I have a problem with a sold product, I want to trace back where it
comes from.
B) My products are not homogeneous (like wine, whiskey, fragrance, ...)
and I let my customer pick the exact lot he want.
For case A I agree that it's just a tag. But not for case B. Do we want
to support case B? Is there any use case for lots?
> Also I think such behavior will be very resource consuming.
I'm not sure but I think it's just a matter of changing
GROUP BY to_location, product
to
GROUP BY to_location, product, lot
in the products_by_location method, except that it must be done
through inheritance.
--
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/
Cédric Krier
> Le Wed, 25 Jan 2012 13:45:25 +0100,
> Cédric Krier <cedric...@b2ck.com> a écrit :
>
>
> > - "Adapt assign_try() and pick_product() to take 'lot' field into
> > account."
> >
> > I'm not sure this is good. For me, lot is more like a tag on moves
> > and it should not prevent to validate the move.
>
> IMO there is at least two use case for lots:
> A) I have a problem with a sold product, I want to trace back where it
> comes from.
> B) My products are not homogeneous (like wine, whiskey, fragrance, ...)
> and I let my customer pick the exact lot he want.
>
> For case A I agree that it's just a tag. But not for case B. Do we want
> to support case B? Is there any use case for lots?
Is not it a variant instead of a lot?
Because if you consider that the product sets is not homogeneous, I
think it is not a product (in the Tryton meaning).
> > Also I think such behavior will be very resource consuming.
>
> I'm not sure but I think it's just a matter of changing
>
> GROUP BY to_location, product
>
> to
>
> GROUP BY to_location, product, lot
>
> in the products_by_location method, except that it must be done
> through inheritance.
Or update stock module to take care of lot with a default lot NULL.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Albert Cervera i Areny
A Dimecres, 25 de gener de 2012 14:17:35, C�dric Krier va escriure:
> > I think it should. Of course, we can discuss on what's the best default�
> > behaviour of stock_lot module, but I'm sure that many companies will need
> > to� be sure that the current stock levels are ok and that includes the
> > exact lots available. If you cannot rely on that, it has no sense to
> > manage lots (at least, in many use cases).
>
> For me, I see it as a blocking stuffs that will be very annoying.
> If the user pick a product with the wrong lot number, the next guys who
> will need to pick the same product, the system will prevent him to do it
> because it is the wrong number.
Take into account that in many cases it is the system that creates the lot number. You're probably thinking on a use case of a
> For me, it should really be like a tag and even we should be able to
> modify it after the move was done. And it makes no sense to have the
> system telling to the user to pick the lot number X out of thousand of
> same products from a location.
I fully disagree. We've got installs in which it is the system that tells the users what lot they should use and it is a hard requirement. The lot can bring other information such as Expiry Date which may determine which lot is used.
Also note that in many places which lot was used is very important. If the user did not put the correct lot when the product arrived, then it must be corrected. The same way you make an inventory when stock is not correct.
Albert Cervera i Areny
A Dimecres, 25 de gener de 2012 15:03:47, C�dric Krier va escriure:
> On 25/01/12 14:43 +0100, Bertrand Chenal wrote:
> > Le Wed, 25 Jan 2012 13:45:25 +0100,
> >
> > C�dric Krier <cedric...@b2ck.com> a �crit :
> > > - "Adapt assign_try() and pick_product() to take 'lot' field into
> > >
> > > account."
> > >
> > > I'm not sure this is good. For me, lot is more like a tag on moves
> > >
> > > and it should not prevent to validate the move.
> >
> > IMO there is at least two use case for lots:
> > A) I have a problem with a sold product, I want to trace back where it
> >
> > comes from.
> >
> > B) My products are not homogeneous (like wine, whiskey, fragrance, ...)
> >
> > and I let my customer pick the exact lot he want.
> >
> > For case A I agree that it's just a tag. But not for case B. Do we want
> > to support case B? Is there any use case for lots?
>
> Is not it a variant instead of a lot?
> Because if you consider that the product sets is not homogeneous, I
> think it is not a product (in the Tryton meaning).
>
> > > Also I think such behavior will be very resource consuming.
> >
> > I'm not sure but I think it's just a matter of changing
> >
> > GROUP BY to_location, product
> >
> > to
> >
> > GROUP BY to_location, product, lot
> >
> > in the products_by_location method, except that it must be done
> > through inheritance.
>
> Or update stock module to take care of lot with a default lot NULL.
Now that you mention it, I think that lots are so common that it would probably make sense to put them in the default 'stock' module...
Bertrand Chenal
Albert Cervera i Areny <alb...@nan-tic.com> a écrit :
> > Or update stock module to take care of lot with a default lot NULL.
>
> Now that you mention it, I think that lots are so common that it
> would probably make sense to put them in the default 'stock' module...
Lot is common, but behaviours are diverse. So maybe we should define
lot in stock but without any important constraints or behaviours.
But to be sure that we do not forget anything we need to gather
all/most of the possible use cases and enrich the blueprint.
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Craig Barnes
Le Wed, 25 Jan 2012 19:54:14 +0100,
Albert Cervera i Areny <alb...@nan-tic.com> a écrit :
Lot is common, but behaviours are diverse. So maybe we should define
> > Or update stock module to take care of lot with a default lot NULL.
>
> Now that you mention it, I think that lots are so common that it
> would probably make sense to put them in the default 'stock' module...
lot in stock but without any important constraints or behaviours.
But to be sure that we do not forget anything we need to gather
all/most of the possible use cases and enrich the blueprint.
Goods received details such as quantity, cost, order ref, received date are all tracked against stock records for a given branch, then when the items are sold the quantity at the top of the stack is reduced, when it reaches 0 the next "lot" is then at the top and it's associated cost is recorded against sales.
I haven't looked at the Tryton stock / product / invoice way of doing things so do not know if this scenario would be handled differently in tryton.
HTH
Craig
--
() ascii ribbon campaign - against html mail
/\
Cédric Krier
> A Dimecres, 25 de gener de 2012 14:17:35, Cédric Krier va escriure:
> > > I think it should. Of course, we can discuss on what's the best default
> > > behaviour of stock_lot module, but I'm sure that many companies will need
> > > to be sure that the current stock levels are ok and that includes the
> > > exact lots available. If you cannot rely on that, it has no sense to
> > > manage lots (at least, in many use cases).
> >
> > For me, I see it as a blocking stuffs that will be very annoying.
> > If the user pick a product with the wrong lot number, the next guys who
> > will need to pick the same product, the system will prevent him to do it
> > because it is the wrong number.
>
> Take into account that in many cases it is the system that creates the lot
> number. You're probably thinking on a use case of a
If it is the system that create such number then their are useless as
any information is generated.
> > For me, it should really be like a tag and even we should be able to
> > modify it after the move was done. And it makes no sense to have the
> > system telling to the user to pick the lot number X out of thousand of
> > same products from a location.
>
> I fully disagree. We've got installs in which it is the system that tells the
> users what lot they should use and it is a hard requirement. The lot can bring
> other information such as Expiry Date which may determine which lot is used.
Of course the system can make proposal but I really think it is a bad
practice. The problematic of expiration date should be managed with a
good organization. A good system must be flexible.
> Also note that in many places which lot was used is very important. If the
> user did not put the correct lot when the product arrived, then it must be
> corrected. The same way you make an inventory when stock is not correct.
If there is no way to detect wrong encoding, this is utopian to think it
will be corrected at more it will be corrected for the future.
Cédric Krier
> On 25 January 2012 22:22, Bertrand Chenal <bertran...@b2ck.com> wrote:
>
> > Le Wed, 25 Jan 2012 19:54:14 +0100,
> > Albert Cervera i Areny <alb...@nan-tic.com> a écrit :
> >
> >
> > > > Or update stock module to take care of lot with a default lot NULL.
> > >
> > > Now that you mention it, I think that lots are so common that it
> > > would probably make sense to put them in the default 'stock' module...
> >
> > Lot is common, but behaviours are diverse. So maybe we should define
> > lot in stock but without any important constraints or behaviours.
> >
> > But to be sure that we do not forget anything we need to gather
> > all/most of the possible use cases and enrich the blueprint.
> >
> > In the ERP of my employer we operate an FIFO system to track cost prices
> for a given product, it sounds similar to Lots.
FIFO costing has nothing to do with lot management, it is purly an
accounting vision.
You can make FIFO costing without doing FIFO when you pick in your
stock. In an accounting point of view, all items of the same product are
the same.
PS: Please fix your email client, it doesn't indent correctly.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Albert Cervera i Areny
A Dijous, 26 de gener de 2012 00:54:21, C�dric Krier va escriure:
> On 25/01/12 19:52 +0100, Albert Cervera i Areny wrote:
> > A Dimecres, 25 de gener de 2012 14:17:35, C�dric Krier va escriure:
> > > > I think it should. Of course, we can discuss on what's the best
> > > > default behaviour of stock_lot module, but I'm sure that many
> > > > companies will need to be sure that the current stock levels are ok
> > > > and that includes the exact lots available. If you cannot rely on
> > > > that, it has no sense to manage lots (at least, in many use cases).
> > >
> > > For me, I see it as a blocking stuffs that will be very annoying.
> > > If the user pick a product with the wrong lot number, the next guys who
> > > will need to pick the same product, the system will prevent him to do
> > > it because it is the wrong number.
> >
> > Take into account that in many cases it is the system that creates the
> > lot number. You're probably thinking on a use case of a
>
> If it is the system that create such number then their are useless as
> any information is generated.
It is not. For example, in several of our customers, if the purchased product has a lot number, that is introduced manually by the user but the system creates a new lot number and that is attached with a label to the incomming product. From there on, the numbers used are those created by the system.
> > > For me, it should really be like a tag and even we should be able to
> > > modify it after the move was done. And it makes no sense to have the
> > > system telling to the user to pick the lot number X out of thousand of
> > > same products from a location.
> >
> > I fully disagree. We've got installs in which it is the system that tells
> > the users what lot they should use and it is a hard requirement. The lot
> > can bring other information such as Expiry Date which may determine
> > which lot is used.
>
> Of course the system can make proposal but I really think it is a bad
> practice. The problematic of expiration date should be managed with a
> good organization. A good system must be flexible.
I don't mean we necessarily should impose such restriction to the default module, but lot is very important in some cases. Of course, we can decide not to make assign_try() take care of this in the more generic modules, but it will be definitely necessary in some cases.
> > Also note that in many places which lot was used is very important. If
> > the user did not put the correct lot when the product arrived, then it
> > must be corrected. The same way you make an inventory when stock is not
> > correct.
>
> If there is no way to detect wrong encoding, this is utopian to think it
> will be corrected at more it will be corrected for the future.
If the lot is labeled in the product it can be corrected by creating inventory moves. Those moves record that you had some problems in your stock and thus can be analyzed the way many users expect: You should not sell a product lot that you have never received.
Note that I'm mixing several use cases here, but will try add the different requirements in the wiki page.
Cédric Krier
> A Dijous, 26 de gener de 2012 00:54:21, Cédric Krier va escriure:
> > On 25/01/12 19:52 +0100, Albert Cervera i Areny wrote:
> > > > > I think it should. Of course, we can discuss on what's the best
> > > > > default behaviour of stock_lot module, but I'm sure that many
> > > > > companies will need to be sure that the current stock levels are ok
> > > > > and that includes the exact lots available. If you cannot rely on
> > > > > that, it has no sense to manage lots (at least, in many use cases).
> > > >
> > > > For me, I see it as a blocking stuffs that will be very annoying.
> > > > If the user pick a product with the wrong lot number, the next guys who
> > > > will need to pick the same product, the system will prevent him to do
> > > > it because it is the wrong number.
> > >
> > > Take into account that in many cases it is the system that creates the
> > > lot number. You're probably thinking on a use case of a
> >
> > If it is the system that create such number then their are useless as
> > any information is generated.
>
> It is not. For example, in several of our customers, if the purchased product
> has a lot number, that is introduced manually by the user but the system
> creates a new lot number and that is attached with a label to the incomming
> product. From there on, the numbers used are those created by the system.
And how does the user make the difference in a location between 2
same products with different lot number generated by the system?
> > > Also note that in many places which lot was used is very important. If
> > > the user did not put the correct lot when the product arrived, then it
> > > must be corrected. The same way you make an inventory when stock is not
> > > correct.
> >
> > If there is no way to detect wrong encoding, this is utopian to think it
> > will be corrected at more it will be corrected for the future.
>
> If the lot is labeled in the product it can be corrected by creating inventory
> moves. Those moves record that you had some problems in your stock and thus
> can be analyzed the way many users expect: You should not sell a product lot
> that you have never received.
Yes as I said, you can correct only for the future not the past.
Albert Cervera i Areny
A Dijous, 26 de gener de 2012 09:41:07, C�dric Krier va escriure:
> > It is not. For example, in several of our customers, if the purchased
> > product� has a lot number, that is introduced manually by the user but
> > the system creates a new lot number and that is attached with a label to
> > the incomming product. From there on, the numbers used are those created
> > by the system.
>
> And how does the user make the difference in a location between 2
> same products with different lot number generated by the system?
- Either there's a label in the product itself and the user is in charge of checking he's picking the right one (some companies do not want to manage locations)
- or we create a system which automatically tells the user where an incoming material should go and the system ensures there's only one lot in a given location. This means that when processing the outgoing shippment (or any needed move such as prodcution) the system tells the user which is the correct location.
Cédric Krier
> A Dijous, 26 de gener de 2012 09:41:07, Cédric Krier va escriure:
> > > It is not. For example, in several of our customers, if the purchased
> > > product has a lot number, that is introduced manually by the user but
> > > the system creates a new lot number and that is attached with a label to
> > > the incomming product. From there on, the numbers used are those created
> > > by the system.
> >
> > And how does the user make the difference in a location between 2
> > same products with different lot number generated by the system?
>
> - Either there's a label in the product itself and the user is in charge of
> checking he's picking the right one (some companies do not want to manage
> locations)
> - or we create a system which automatically tells the user where an incoming
> material should go and the system ensures there's only one lot in a given
> location. This means that when processing the outgoing shippment (or any
> needed move such as prodcution) the system tells the user which is the correct
> location.
I don't say it is not doable and that nobody works like that but I think
such way of working is not efficient.
The basis of the Tryton Model is that an item of product A is equal to
an other item of the same product. If it is not the case than it should
not be the same product (perhaps variance).
That say, you could have some kind of picking rules like FIFO (useful for
perishable products), those rules could be implemented in the system for
example with location order or (and I think it is the best) with
warehouse organisation rules (ordering the placement of products or
"take the older product").
Cédric Krier
> Le Wed, 25 Jan 2012 13:45:25 +0100,
> Cédric Krier <cedric...@b2ck.com> a écrit :
>
> I'm not sure but I think it's just a matter of changing
>
> GROUP BY to_location, product
>
> to
>
> GROUP BY to_location, product, lot
>
> in the products_by_location method, except that it must be done
> through inheritance.
Indeed it will be ressource consuming because the stock period works at
product level and not at lot.
And I don't think caching per lot is a smart design choise, the number
of row in such table will increase very fast.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Albert Cervera i Areny
A Dijous, 26 de gener de 2012 11:23:14, C�dric Krier va escriure:
> On 26/01/12 10:58 +0100, Albert Cervera i Areny wrote:
> > A Dijous, 26 de gener de 2012 09:41:07, C�dric Krier va escriure:
> > > > It is not. For example, in several of our customers, if the purchased
> > > > product has a lot number, that is introduced manually by the user
> > > > but the system creates a new lot number and that is attached with a
> > > > label to the incomming product. From there on, the numbers used are
> > > > those created by the system.
> > >
> > > And how does the user make the difference in a location between 2
> > > same products with different lot number generated by the system?
> >
> > - Either there's a label in the product itself and the user is in charge
> > of checking he's picking the right one (some companies do not want to
> > manage locations)
> > - or we create a system which automatically tells the user where an
> > incoming material should go and the system ensures there's only one lot
> > in a given location. This means that when processing the outgoing
> > shippment (or any needed move such as prodcution) the system tells the
> > user which is the correct location.
>
> I don't say it is not doable and that nobody works like that but I think
> such way of working is not efficient.
>
> The basis of the Tryton Model is that an item of product A is equal to
> an other item of the same product. If it is not the case than it should
> not be the same product (perhaps variance).
A product has a code. A lot may have another code. You should be able to select only the product or a product + a lot. You must be able to know current stock of a given product and current stock of a given lot.
A variance should be a characteristic such as color or size, but a lot usually contains things such as when it arrived, an expiry date or even prices.
> That say, you could have some kind of picking rules like FIFO (useful for
> perishable products), those rules could be implemented in the system for
> example with location order or (and I think it is the best) with
> warehouse organisation rules (ordering the placement of products or
> "take the older product").
Sorry, but don't get that. AFAIU you could not manage the case of two products with different lots in a single location?
Bertrand Chenal
Cédric Krier <cedric...@b2ck.com> a écrit :
> On 25/01/12 14:43 +0100, Bertrand Chenal wrote:
> > Le Wed, 25 Jan 2012 13:45:25 +0100,
> > Cédric Krier <cedric...@b2ck.com> a écrit :
> > > Also I think such behavior will be very resource consuming.
> >
> > I'm not sure but I think it's just a matter of changing
> >
> > GROUP BY to_location, product
> >
> > to
> >
> > GROUP BY to_location, product, lot
> >
> > in the products_by_location method, except that it must be done
> > through inheritance.
>
> Indeed it will be ressource consuming because the stock period works
> at product level and not at lot.
> And I don't think caching per lot is a smart design choise, the number
> of row in such table will increase very fast.
>
I agree that caching per location and per lot is not a good idea.
So, new proposal:
a naive product_by_lot function will be slow, so we need caching. As
lots are a bit like temporary locations, caching per period makes no
sense. But we can flag 'empty' lots, I.E. lots for which all products
have been sent to customers (or consumed by a production). While the
number of lot gets bigger and bigger as the time goes, the number of
non-empty lot will stay nearly stable.
This means that an efficient product_by_lot is doable: we only
have to consider the moves that are linked to an non-empty lot.
And for the same price we can do a "product_and_location_by_lot".
Now, the question of how to integrate this with shipments and
assignment will depends of the use case.
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
> Le Thu, 26 Jan 2012 11:28:21 +0100,
> Cédric Krier <cedric...@b2ck.com> a écrit :
>
> > On 25/01/12 14:43 +0100, Bertrand Chenal wrote:
> > > Le Wed, 25 Jan 2012 13:45:25 +0100,
> > > Cédric Krier <cedric...@b2ck.com> a écrit :
> > > > Also I think such behavior will be very resource consuming.
> > >
> > > I'm not sure but I think it's just a matter of changing
> > >
> > > GROUP BY to_location, product
> > >
> > > to
> > >
> > > GROUP BY to_location, product, lot
> > >
> > > in the products_by_location method, except that it must be done
> > > through inheritance.
> >
> > Indeed it will be ressource consuming because the stock period works
> > at product level and not at lot.
> > And I don't think caching per lot is a smart design choise, the number
> > of row in such table will increase very fast.
> >
>
> I agree that caching per location and per lot is not a good idea.
> So, new proposal:
>
> a naive product_by_lot function will be slow, so we need caching. As
> lots are a bit like temporary locations,
If so, why not use location instead of lot?
> caching per period makes no
> sense. But we can flag 'empty' lots, I.E. lots for which all products
> have been sent to customers (or consumed by a production). While the
> number of lot gets bigger and bigger as the time goes, the number of
> non-empty lot will stay nearly stable.
>
> This means that an efficient product_by_lot is doable: we only
> have to consider the moves that are linked to an non-empty lot.
> And for the same price we can do a "product_and_location_by_lot".
>
> Now, the question of how to integrate this with shipments and
> assignment will depends of the use case.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Albert Cervera i Areny
A Dijous, 26 de gener de 2012 13:24:44, C�dric Krier va escriure:
> > I agree that caching per location and per lot is not a good idea.
> >
> > So, new proposal:
> >�
> >
> > a naive product_by_lot function will be slow, so we need caching. As
> > lots are a bit like temporary locations,
>
> If so, why not use location instead of lot?
Because you can have several products with different lots in the same location :)
Cédric Krier
> A Dijous, 26 de gener de 2012 13:24:44, Cédric Krier va escriure:
> > > I agree that caching per location and per lot is not a good idea.
> > >
> > > So, new proposal:
> > >
> > >
> > > a naive product_by_lot function will be slow, so we need caching. As
> > > lots are a bit like temporary locations,
> >
> > If so, why not use location instead of lot?
>
> Because you can have several products with different lots in the same location
> :)
This is not an answer. If you consider that a lot is like a temporary
location than you can not put different lots in the same location.
Albert Cervera i Areny
A Dijous, 26 de gener de 2012 13:33:55, C�dric Krier va escriure:
> On 26/01/12 13:26 +0100, Albert Cervera i Areny wrote:
> > A Dijous, 26 de gener de 2012 13:24:44, C�dric Krier va escriure:
> > > > I agree that caching per location and per lot is not a good idea.
> > > >
> > > > So, new proposal:
> > > >
> > > >
> > > > a naive product_by_lot function will be slow, so we need caching. As
> > > > lots are a bit like temporary locations,
> > >
> > > If so, why not use location instead of lot?
> >
> > Because you can have several products with different lots in the same
> > location
> >
> > :)
>
> This is not an answer. If you consider that a lot is like a temporary
> location than you can not put different lots in the same location.
Well, I do not consider that a lot is like a temporary location. In fact, it has nothing to do with it.
Bertrand Chenal
Cédric Krier <cedric...@b2ck.com> a écrit :
> On 26/01/12 13:26 +0100, Albert Cervera i Areny wrote:
> > A Dijous, 26 de gener de 2012 13:24:44, Cédric Krier va escriure:
> > > > I agree that caching per location and per lot is not a good
> > > > idea.
> > > >
> > > > So, new proposal:
> > > >
> > > >
> > > > a naive product_by_lot function will be slow, so we need
> > > > caching. As lots are a bit like temporary locations,
> > >
> > > If so, why not use location instead of lot?
> >
> > Because you can have several products with different lots in the
> > same location :)
>
> This is not an answer. If you consider that a lot is like a temporary
> location than you can not put different lots in the same location.
1) I was talking about caching, noting else.
2) Your answer looks like you think that the concept of lot is
completely non-needed, what's your point of view?
Once again, my feeling is that we have different use cases in mind. As
long as this point is not clear, nothing constructive can be done.
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
> Le Thu, 26 Jan 2012 13:33:55 +0100,
> Cédric Krier <cedric...@b2ck.com> a écrit :
>
> > On 26/01/12 13:26 +0100, Albert Cervera i Areny wrote:
> > > A Dijous, 26 de gener de 2012 13:24:44, Cédric Krier va escriure:
> > > > > I agree that caching per location and per lot is not a good
> > > > > idea.
> > > > >
> > > > > So, new proposal:
> > > > >
> > > > >
> > > > > a naive product_by_lot function will be slow, so we need
> > > > > caching. As lots are a bit like temporary locations,
> > > >
> > > > If so, why not use location instead of lot?
> > >
> > > Because you can have several products with different lots in the
> > > same location :)
> >
> > This is not an answer. If you consider that a lot is like a temporary
> > location than you can not put different lots in the same location.
>
> 1) I was talking about caching, noting else.
> 2) Your answer looks like you think that the concept of lot is
> completely non-needed, what's your point of view?
I think lot management is just about information and nothing more.
All cases, where people think they can be solved by using restrictive lot
management, can be solved differently.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Albert Cervera i Areny
A Dijous, 26 de gener de 2012 13:53:34, C�dric Krier va escriure:
> On 26/01/12 13:50 +0100, Bertrand Chenal wrote:
> > Le Thu, 26 Jan 2012 13:33:55 +0100,
> >
> > C�dric Krier <cedric...@b2ck.com> a �crit :
> > > On 26/01/12 13:26 +0100, Albert Cervera i Areny wrote:
> > > > A Dijous, 26 de gener de 2012 13:24:44, C�dric Krier va escriure:
> > > > > > I agree that caching per location and per lot is not a good
> > > > > > idea.
> > > > > >
> > > > > > So, new proposal:
> > > > > >
> > > > > >
> > > > > > a naive product_by_lot function will be slow, so we need
> > > > > > caching. As lots are a bit like temporary locations,
> > > > >
> > > > > If so, why not use location instead of lot?
> > > >
> > > > Because you can have several products with different lots in the
> > > > same location :)
> > >
> > > This is not an answer. If you consider that a lot is like a temporary
> > > location than you can not put different lots in the same location.
> >
> > 1) I was talking about caching, noting else.
> > 2) Your answer looks like you think that the concept of lot is
> > completely non-needed, what's your point of view?
>
> I think lot management is just about information and nothing more.
> All cases, where people think they can be solved by using restrictive lot
> management, can be solved differently.
In fact, it's about traceability. I need to be able to know that the 3 units of product A that I sold with lot 1112 was composed (once we've got prodution ;-) of 5 units of product B with lot 782 and 5 units of product C with lot 818 (2 units) and 551 (3 units).
Product B with lot 782 has supplier reference YYUI889 and was recevied from supplier S1 on 30/12/2011. They were stored until 05/01/2012 on location L1 and later moved to L2 until 20/01/2012 when they were finally used for production. Etc, etc.
I also need to know how many units of each product (A, B and C) I have available and how many units I have of each of their lots and were they are located. As mentioned, I also need to know were they have been located at each given time.
I think the only way to manage this is by adding a new field in stock.move called produt_lot which points to (Many2One) a new model called product_lot or so. Given that we've discussed several things, I'm not sure we agree on that or not.
Sharoon Thomas
I think lot management is just about information and nothing more.
All cases, where people think they can be solved by using restrictive lot
management, can be solved differently.
Director & CEO, Openlabs Technologies & Consulting Pvt Limited
Mobile: +1 786 247 1317
http://openlabs.co.in
Cédric Krier
> A Dijous, 26 de gener de 2012 13:53:34, Cédric Krier va escriure:
> > On 26/01/12 13:50 +0100, Bertrand Chenal wrote:
> > > Le Thu, 26 Jan 2012 13:33:55 +0100,
> > >
I fully agree.
Cédric Krier
> On Jan 26, 2012, at 7:53 AM, Cédric Krier wrote:
>
> >
> > I think lot management is just about information and nothing more.
> > All cases, where people think they can be solved by using restrictive lot
> > management, can be solved differently.
> >
>
> I agree with cedk here and the basic module should just provide that.
> Probably the only constraint it should offer is ensure there are lot/batch
> numbers for products which are required to have them.
>
> I would prefer to have the serial numbers/lots on a separate table and not
> stock.move with the following structure.
>
> stock_move (m2o)
> quantity
> lot (m2o) [Agree with cedk's concept of product.lot against product]
I think such design will give a bad UX.
I prefer to split stock moves when needed and a simple concept of modulo
on stock move quantity could make the job.
Albert Cervera i Areny
A Dijous, 26 de gener de 2012 15:16:06, C�dric Krier va escriure:
> On 26/01/12 08:35 -0500, Sharoon Thomas wrote:
> > On Jan 26, 2012, at 7:53 AM, C�dric Krier wrote:
> > > I think lot management is just about information and nothing more.
> > > All cases, where people think they can be solved by using restrictive
> > > lot management, can be solved differently.
> >
> > I agree with cedk here and the basic module should just provide that.
> > Probably the only constraint it should offer is ensure there are
> > lot/batch numbers for products which are required to have them.
> >
> > I would prefer to have the serial numbers/lots on a separate table and
> > not stock.move with the following structure.
> >
> > stock_move (m2o)
> > quantity
> > lot (m2o) [Agree with cedk's concept of product.lot against product]
>
> I think such design will give a bad UX.
> I prefer to split stock moves when needed and a simple concept of modulo
> on stock move quantity could make the job.
I agree it gives a bad UX. At the same time, I must admit that when working with serial numbers, splitting the lines can also be cumbersome. We've got a customer that can create a production of more than a thousand units and that creates shippments with a large number of lines.
So if we found a good way of managing it, maybe Sharoon's idea would not be so bad.
One idea would be to have two One2Many widgets in the shippment and once the user selects a stock.move line the second One2Many field is filled in with all related lots?
Cédric Krier
> A Dijous, 26 de gener de 2012 15:16:06, Cédric Krier va escriure:
> > On 26/01/12 08:35 -0500, Sharoon Thomas wrote:
> > > > I think lot management is just about information and nothing more.
> > > > All cases, where people think they can be solved by using restrictive
> > > > lot management, can be solved differently.
> > >
> > > I agree with cedk here and the basic module should just provide that.
> > > Probably the only constraint it should offer is ensure there are
> > > lot/batch numbers for products which are required to have them.
> > >
> > > I would prefer to have the serial numbers/lots on a separate table and
> > > not stock.move with the following structure.
> > >
> > > stock_move (m2o)
> > > quantity
> > > lot (m2o) [Agree with cedk's concept of product.lot against product]
> >
> > I think such design will give a bad UX.
> > I prefer to split stock moves when needed and a simple concept of modulo
> > on stock move quantity could make the job.
>
> I agree it gives a bad UX. At the same time, I must admit that when working
> with serial numbers, splitting the lines can also be cumbersome. We've got a
> customer that can create a production of more than a thousand units and that
> creates shippments with a large number of lines.
You will still have thousand of lot lines. So still the same issue.
> So if we found a good way of managing it, maybe Sharoon's idea would not be so
> bad.
I don't think there is a good way. More over it is also about DB design
an this is also bad because you have duplication of information
quantity = sum(lot quantity)
> One idea would be to have two One2Many widgets in the shippment and once the
> user selects a stock.move line the second One2Many field is filled in with all
> related lots?
Looks like the board communication but having it at the form level will
break the behavior concept of Model for the on_change(_with) and states.
Albert Cervera i Areny
A Divendres, 27 de gener de 2012 10:12:17, C�dric Krier va escriure:
> > I agree it gives a bad UX. At the same time, I must admit that when
> > working� with serial numbers, splitting the lines can also be
> > cumbersome. We've got a customer that can create a production of more
> > than a thousand units and that creates shippments with a large number of
> > lines.
>
> You will still have thousand of lot lines. So still the same issue.
Sure, but it's not exactly the same. Let's say you have to ship, 500 hundred units of each products A, B and C. All of them use serial numbers. With a lot per stock move you have a shipping with 1.500 lines and so there is no way you know you're actually shipping 500 units of A, 500 of B, and 500 of C. At most you're informed that there are 1.500 lines in the shippment.
With sharoon's approach you've got three lines which clearly describe what you're sending.
> > So if we found a good way of managing it, maybe Sharoon's idea would not
> > be so� bad.
>
> I don't think there is a good way. More over it is also about DB design
> an this is also bad because you have duplication of information
> quantity = sum(lot quantity)
Yes. At the same time, I don't know if this could somehow help in the cache issue you were discussing with Bertrand. Maybe doing another cache at stock.move.lot level independent from stock.move?
> > One idea would be to have two One2Many widgets in the shippment and once
> > the� user selects a stock.move line the second One2Many field is filled
> > in with all related lots?
>
> Looks like the board communication but having it at the form level will
> break the behavior concept of Model for the on_change(_with) and states.
I think having something like that in the form view could be very useful in other cases. It would allow, for example, to design current import and export dialogs with simple forms. For example, you can have a One2Many field with the list of all fields in the database. When you double-click on one of them, the selected item triggers an on-change and the field is added to a second One2Many where all selected items are added.
We've also found several other circumstances in the past in which we would have used that feature.
Cédric Krier
> A Divendres, 27 de gener de 2012 10:12:17, Cédric Krier va escriure:
> > > I agree it gives a bad UX. At the same time, I must admit that when
> > > working with serial numbers, splitting the lines can also be
> > > cumbersome. We've got a customer that can create a production of more
> > > than a thousand units and that creates shippments with a large number of
> > > lines.
> >
> > You will still have thousand of lot lines. So still the same issue.
>
> Sure, but it's not exactly the same. Let's say you have to ship, 500 hundred
> units of each products A, B and C. All of them use serial numbers. With a lot
> per stock move you have a shipping with 1.500 lines and so there is no way you
> know you're actually shipping 500 units of A, 500 of B, and 500 of C. At most
> you're informed that there are 1.500 lines in the shippment.
>
> With sharoon's approach you've got three lines which clearly describe what
> you're sending.
You can make a view that group moves by product.
> > > So if we found a good way of managing it, maybe Sharoon's idea would not
> > > be so bad.
> >
> > I don't think there is a good way. More over it is also about DB design
> > an this is also bad because you have duplication of information
> > quantity = sum(lot quantity)
>
> Yes. At the same time, I don't know if this could somehow help in the cache
> issue you were discussing with Bertrand. Maybe doing another cache at
> stock.move.lot level independent from stock.move?
Yes having the quantity of lot on a separate table could become a
performance issue.
> > > One idea would be to have two One2Many widgets in the shippment and once
> > > the user selects a stock.move line the second One2Many field is filled
> > > in with all related lots?
> >
> > Looks like the board communication but having it at the form level will
> > break the behavior concept of Model for the on_change(_with) and states.
>
> I think having something like that in the form view could be very useful in
> other cases. It would allow, for example, to design current import and export
> dialogs with simple forms. For example, you can have a One2Many field with the
> list of all fields in the database. When you double-click on one of them, the
> selected item triggers an on-change and the field is added to a second One2Many
> where all selected items are added.
That is something else.
Albert Cervera i Areny
A Divendres 27 Gener 2012 11:12:50, Cédric Krier va escriure:
> On 27/01/12 10:49 +0100, Albert Cervera i Areny wrote:
> > A Divendres, 27 de gener de 2012 10:12:17, Cédric Krier va escriure:
> > > > I agree it gives a bad UX. At the same time, I must admit that when
> > > > working with serial numbers, splitting the lines can also be
> > > > cumbersome. We've got a customer that can create a production of more
> > > > than a thousand units and that creates shippments with a large number
> > > > of lines.
> > >
> > >
> > >
> > > You will still have thousand of lot lines. So still the same issue.
> >
> >
> >
> > Sure, but it's not exactly the same. Let's say you have to ship, 500
> > hundred units of each products A, B and C. All of them use serial
> > numbers. With a lot per stock move you have a shipping with 1.500 lines
> > and so there is no way you know you're actually shipping 500 units of A,
> > 500 of B, and 500 of C. At most you're informed that there are 1.500
> > lines in the shippment.
> >
> >
> >
> > With sharoon's approach you've got three lines which clearly describe
> > what you're sending.
>
> You can make a view that group moves by product.
We need to address this issue for a couple of customers who regularly work with a lot of serial numbers. Did you have something in mind? The main problem I see with trying to make a view that groups moves is that would be needed in stock moves, production, and all shipment types. Not to say that any inheritance in stock.move views is lost or must be re-adapted to the new view.
I'm thinking that maybe serial numbers should be managed with another kind of relationship instead of reusing stock.lot.
By the way, it seems the problem has been there in other systems too [1] :)
[1] http://www.navisioninfo.com/whitepapers/Navision%20Item%20Tracking%20Technical%20White%20Paper.htm
--
Albert Cervera i Areny
Cédric Krier
> A Divendres 27 Gener 2012 11:12:50, Cédric Krier va escriure:
> > On 27/01/12 10:49 +0100, Albert Cervera i Areny wrote:
> > > A Divendres, 27 de gener de 2012 10:12:17, Cédric Krier va escriure:
> > > > > I agree it gives a bad UX. At the same time, I must admit that when
> > > > > working with serial numbers, splitting the lines can also be
> > > > > cumbersome. We've got a customer that can create a production of more
> > > > > than a thousand units and that creates shippments with a large number
> > > > > of lines.
> > > >
> > > >
> > > >
> > > > You will still have thousand of lot lines. So still the same issue.
> > >
> > >
> > >
> > > Sure, but it's not exactly the same. Let's say you have to ship, 500
> > > hundred units of each products A, B and C. All of them use serial
> > > numbers. With a lot per stock move you have a shipping with 1.500 lines
> > > and so there is no way you know you're actually shipping 500 units of A,
> > > 500 of B, and 500 of C. At most you're informed that there are 1.500
> > > lines in the shippment.
> > >
> > >
> > >
> > > With sharoon's approach you've got three lines which clearly describe
> > > what you're sending.
> >
> > You can make a view that group moves by product.
>
> We need to address this issue for a couple of customers who regularly work
> with a lot of serial numbers. Did you have something in mind?
> The main problem
> I see with trying to make a view that groups moves is that would be needed in
> stock moves, production, and all shipment types. Not to say that any
> inheritance in stock.move views is lost or must be re-adapted to the new view.
> I'm thinking that maybe serial numbers should be managed with another kind of
> relationship instead of reusing stock.lot.
> By the way, it seems the problem has been there in other systems too [1] :)
>
> [1]
> http://www.navisioninfo.com/whitepapers/Navision%20Item%20Tracking%20Technical%20White%20Paper.htm
Albert Cervera i Areny
A Diumenge 21 Juliol 2013 14:38:15, Cédric Krier va escriure:
Displaying only is easier but then the user has to switch between the place where she changes stuff, and the place where that information is summarized. Possibly in two different tabs of the shipment. It is the UX that I don't like.
> > I'm thinking that maybe serial numbers should be managed with another
> > kind of relationship instead of reusing stock.lot.
>
> I think it is a wrong decision.
>
> > By the way, it seems the problem has been there in other systems too [1]
> > :)
> >
> > [1]
> > http://www.navisioninfo.com/whitepapers/Navision%20Item%20Tracking%20Tech
> > nical%20White%20Paper.htm
>
> Yes and their "Sales Shipment Line" is just the grouped moves I talked.
Yes, but users can "operate" with those lines. It seems that they use "Item Ledger Entry" (stock.move) for registration only, but it is not the object with which the user works on the shipment. If the user has to change information in the "grouped" view he can do it and it has a one2many relationship with the Ledger Entry.