RE: [Web-erp-developers] Serialised stock - how to code this up

[Jesse P. <jes...@st...>]

Ok. Sounds like what I have here will work, but that certain views will =
be required to provide links to some easy way to track items back...

jesse

> -----Original Message-----
> From: Phil Daintree [mailto:ph...@du...]
> Sent: Thursday, March 25, 2004 17:32
> To: web...@li...
> Subject: Re: [Web-erp-developers] Serialised stock - how to=20
> code this up
>=20
>=20
> Typically a bundle of steel has a tracking bundle number as=20
> given to it by
> the vendor. Quality information would be available and=20
> certification by
> bundle reference. A manufacturer would want to know which=20
> steel went into
> its product so if there were some particularly rusty products=20
> produced or
> the carbon deposits causing structural flaws in the steel=20
> then these could
> be tracked to the bundle that they came from.
>=20
> Similarly, with cloth - a manufacturer receiving returned=20
> garments would
> want to know which roll of cloth this came from - so that the cloth
> manufacturer could be held accountable. Or when cutting the=20
> cloth to make
> garments a flaw is revealed - the cloth mill will need to=20
> know the roll
> reference they gave the roll when it was made to have a look=20
> at its quality
> processes.
>=20
> Food is the same - A batch of cheese with razor blades in it=20
> would need to
> be withdrawn and the manufacturer would need to issue a recall off the
> shelves immediately for batch xyz to all retail outlets - and=20
> need to be
> able to trace where this batch was sold to.
>=20
> Phil
>=20
> ----- Original Message -----
> From: "Jesse Peterson" <jes...@st...>
> To: <web...@li...>
> Sent: Friday, March 26, 2004 10:00 AM
> Subject: RE: [Web-erp-developers] Serialised stock - how to=20
> code this up
>=20
>=20
> > comments down below....
> >
> > > > > > > - how do we display all the serial numbers of items on
> > > > > hand at any one
> > > > > time?
> > > > > > >
> > > > > > >
> > > > > > I realized this a while ago as well. All Items will have
> > > > > their current
> > > > > > StockMove associated with them in their table - upkeep
> > > > > necessary during
> > > > > > adds/moves/etc. I figure to select on-hand items the base
> > > > > criteria will
> > > > > > be based on selecting a set of StockMoves with
> > > appropriate SysTypes,
> > > > > > then selecting Items still tagged with those StockMoves. Do
> > > > > you know the
> > > > > > SysTypes necessary without me digging around to find them?
> > > > > I don't understand this. The SysTypes table refers to=20
> the various
> > > > > transaction types - not all of which create stock movements.
> > > > It looks to me that finding all SerialisedStock-on-Hand can
> > > > be done by:
> > > > Get all StockMoves where Type=3D25, then get all
> > > > SerialisedItems with those
> > > > StockMoveNo's. Limits could easily be put to select all for
> > > > just a Location,
> > > > that a Customer have, etc... and just require determining
> > > > which Types in
> > > > StockMoves reflect the Stock you want. Make sense? The last
> > > > part is where i
> > > > was wondering about which ones should be checked.
> > >
> > > But the goods received stock movement has the total qty
> > > received - not the
> > > qty of the batch received? Even when linked to
> > > SerialisedStockMoves this
> > > table has no qty in it either?
> > > I just don't see how this system will track how many of each
> > > batch you have
> > > left.
> >
> > I'm assuming a Batch will be a set of like StockMaster=20
> types and using
> StockMoves.Bundle is an adequate tracking no. for each batch:
> > Let's see... GoodsReceived would create a StockMove /w the=20
> Qty received -
> if it is controlled, the Receiver would be required to enter=20
> a BundleId
> (that would go in StockMoves.Bundle). As more goods were=20
> received, we could
> allow it to be batched together with the previous one or=20
> given/require a new
> Bundle
> > So then, to query a Bundle, you'd pick all StockMoves=20
> On-Hand (type=3D25..
> more?), Sum their Qty for a total number of items, then sum=20
> the number of
> SerialisedItem moves where those StockMove(s) are set as the=20
> OrigStockMoveNo
> . That could be a little slow, but I think it will end up=20
> working out ok.
> For consistency (in that quantities always come from=20
> StockMoves), it may be
> better to retrieve the distinct NewStockMoves for the=20
> OldStockMoves and pull
> their Qty out of StockMoves... that would give us a Total and=20
> the number
> Removed from it, which obiously is enough to show us the=20
> number available.
> >
> > Tangent on BundleIds: do you think these should be=20
> auto-generated? I was
> thinking treat Bundle as it if were a hex number and just=20
> keep adding 1...
> so they'd go 00000001,...,00000009,0000000A,..0000000F,00000010 - or a
> 'base26'(A-Z) or 'base36'(0-9,A-Z) scheme to accomodate even=20
> more unique
> Bundle #s (I have some functions that count/convert things like that
> already)...
> >
> > You may want/need to explain to me how batches *need* to=20
> work so I can
> take a fresh look at that...
> >
> > > >
> > > > > Individual
> > > > > stockmoves contain the total balance of all stock in the
> > > > > location in the
> > > > > newqoh field if I understand your logic so the quantity in
> > > > > the batch is
> > > > > unknown. or do you mean to re-calcuate the quantity remaining
> > > > > on hand in the
> > > > > ControlledStockMoves record and just pick up the last
> > > > The Qty for a batch of SerialisedItems would simply be the
> > > Qty in the
> > > StockMove they refer to. We may need to talk about exactly
> > > how to account
> > > for StockMove Qty's, but it looks like the same as above,
> > > where certain
> > > Types can be referenced to get the total(s) we are looking for.
> > > >
> > > > > Perhaps summing the qty ins and outs in the
> > > > > ControlledStockMoves - this
> > > > > could be a substantial exercise with your data volumes?
> > > > Yes, it could. I did not intend on needing to do this.
> > > >
> > > > > Not using the LocStock table seems nice but what about items
> > > > > that need to
> > > > > mature before they are sold - so they need to be held or
> > > products -
> > > > > serialised items that must be sold before a given date as per
> > > > > Danie's note.
> > > > > I think if we are doing it, it would be a shame to limit
> > > the scope to
> > > > > exclude this.
> > > > > Are we looking at another table to hold serialised quantites
> > > > > on hand and
> > > > > these variables. The table being maintained like LocStock but
> > > > > at the serial
> > > > > number level - the total of serialised items always agreeing
> > > > > to the LocStock
> > > > > table QOH. There seems a disturbing amount of double up
> > > with LocStock
> > > > > though.
> > > > Agreed, I wouldn't want to double up like that... I read Danie's
> > > > requests - I've never really thought about having to do that,
> > > > so I will...
> > > > Right now, I'm thinking a StockMaster field for=20
> SellAfterDays and
> > > > SellByDays, and then determining Stock status (as above, by
> > > > Type) should
> > > > just be an exercise of totalling StockMoves and examining
> > > > date differences.
> > > What do you think?
> > >
> > > Clunky and processing intensive .... you asked what I thought :-)
> >
> > Ok :)... possibly so. If I do it now, I'll probably do it=20
> that way unless
> I can work in another way.
> >
> >
> > > I'm looking forward to seeing the code - since this is a
> > > substantial project
> > > I will confine my activities over the next 2 weeks to the EDI
> > > scripts and
> > > suggest Danie and Dick do similarly - to give you a free=20
> run without
> > > worrying about other changes in the scripts.
> >
> > That would be very nice. I'll keep my eye out in case=20
> changes are needed,
> though, so that you guys aren't completely strapped by me=20
> working on this.
> My hope is to have most of this done (assuming I don't hit=20
> any big snags)
> within a week or so - that's probably a little=20
> over-ambitious, though. The
> first thing I may end up sending back is reworkings of some=20
> sections of code
> to allow us to class out the StockItems, at least as a data=20
> structure...
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>=20