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

[Daintree <p.d...@pa...>]

> > > > - 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.

>
> > 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 :-)

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.

Phil