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

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

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=20
> 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=20
> > be done by:
> > Get all StockMoves where Type=3D25, then get all=20
> > SerialisedItems with those
> > StockMoveNo's. Limits could easily be put to select all for=20
> > just a Location,
> > that a Customer have, etc... and just require determining=20
> > which Types in
> > StockMoves reflect the Stock you want. Make sense? The last=20
> > part is where i
> > was wondering about which ones should be checked.
>=20
> But the goods received stock movement has the total qty=20
> received - not the
> qty of the batch received? Even when linked to=20
> SerialisedStockMoves this
> table has no qty in it either?
> I just don't see how this system will track how many of each=20
> 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=20
So then, to query a Bundle, you'd pick all StockMoves On-Hand =
(type=3D25.. 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=20
> Qty in the
> StockMove they refer to. We may need to talk about exactly=20
> how to account
> for StockMove Qty's, but it looks like the same as above,=20
> 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=20
> 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=20
> 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=20
> 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,=20
> > so I will...
> > Right now, I'm thinking a StockMaster field for SellAfterDays and
> > SellByDays, and then determining Stock status (as above, by=20
> > Type) should
> > just be an exercise of totalling StockMoves and examining=20
> > date differences.
> What do you think?
>=20
> 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.

=20
> I'm looking forward to seeing the code - since this is a=20
> substantial project
> I will confine my activities over the next 2 weeks to the EDI=20
> 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...