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

[Phil D. <ph...@du...>]

Typically a bundle of steel has a tracking bundle number as given to it by
the vendor. Quality information would be available and certification by
bundle reference. A manufacturer would want to know which steel went into
its product so if there were some particularly rusty products produced or
the carbon deposits causing structural flaws in the steel then these could
be tracked to the bundle that they came from.

Similarly, with cloth - a manufacturer receiving returned 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 cloth to make
garments a flaw is revealed - the cloth mill will need to know the roll
reference they gave the roll when it was made to have a look at its quality
processes.

Food is the same - A batch of cheese with razor blades in it 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 need to be
able to trace where this batch was sold to.

Phil

----- 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 code this up


> 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 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=25, 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 types and using
StockMoves.Bundle is an adequate tracking no. for each batch:
> Let's see... GoodsReceived would create a StockMove /w the Qty received -
if it is controlled, the Receiver would be required to enter a BundleId
(that would go in StockMoves.Bundle). As more goods were received, we could
allow it to be batched together with the previous one or given/require a new
Bundle
> So then, to query a Bundle, you'd pick all StockMoves On-Hand (type=25..
more?), Sum their Qty for a total number of items, then sum the number of
SerialisedItem moves where those StockMove(s) are set as the OrigStockMoveNo
. That could be a little slow, but I think it will end up working out ok.
For consistency (in that quantities always come from StockMoves), it may be
better to retrieve the distinct NewStockMoves for the OldStockMoves and pull
their Qty out of StockMoves... that would give us a Total and the number
Removed from it, which obiously is enough to show us the number available.
>
> Tangent on BundleIds: do you think these should be auto-generated? I was
thinking treat Bundle as it if were a hex number and just 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 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 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 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 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 run without
> > worrying about other changes in the scripts.
>
> That would be very nice. I'll keep my eye out in case changes are needed,
though, so that you guys aren't completely strapped by me working on this.
My hope is to have most of this done (assuming I don't hit any big snags)
within a week or so - that's probably a little over-ambitious, though. The
first thing I may end up sending back is reworkings of some sections of code
to allow us to class out the StockItems, at least as a data structure...
>
>
>
> -------------------------------------------------------
> 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_id70&alloc_id638&opÌk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>