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

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

> Like the StockItemMoves table I sent you in those diffs. It would not
> hold a record for the inital move (in stockmoves and breaks ref.
> integrity), and would hole the item#,orig_stkmove, and new_stkmove .

This only contains moves of controlled items right with their reference and
stockmove id - why would it not show the qty of the batch movement - where
is this recorded?  I guess the StockMoves table shows the total movement of
all serialised items per your logic. FromStkMoveNo and ToStkMoveNo - the
stock movements of a serialised item will not be in a range .... will
they???
There's a one StockMoves.StockID to many StockItemMoves.StockID (I think
some ref to controlled items would be preferable in the naming of the table)
and the StockMoves.NewQOH would contain the sum of all serialised items in
stock - not just one serial number item .... would it not??

>
> > - how would the system deal with lots and batches?
> >
> >
> non controlled, non serialised item - no conept of batches at all -
> StockMoves.Bundles defaults to 1
> controlled, non serialised item - bundle serves as an id for a stock
> move. The move maybe for, say, 25 items...maybe hundreds. That can count
> as a Lot, right?
>

OK I get it - that seems fine, just no qty control - probably ok - I prefer
my method ;-)

> > - Don't understand you templatey idea?
> >
> Do you mean the above, my plan on how to allow easy extension of
> stockitem details,

yes that bit. I see the StockModules tables - I guess it would reduce a bit
of input but would require additional sql to get the necessary info. I don't
see it as necessary? The stock category could contain any other data
relevant to the category.

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

Perhaps summing the qty ins and outs in the ControlledStockMoves - this
could be a substantial exercise with your data volumes?

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.

>
> > - how do we display on invoices the serial numbers of items sold - if we
> >wanted to ?
> >
> >
> This can be an option specified in the StockMaster table, in
> StockModules, or even at the time of printing/viewing the invoice, and a
> combination of those...I also forsee situations like I have where I want
> to invoice someone for 50,000 cards on a regular invoice (obviously
> without serialised line items) and have the option to provide/retrieve
> the invoice detail in some other format, say a csv list of serial
> numbers and possibly other data that can be sent to a customer for their
> own inventory requirements.
>

I am probably wasting your time with my inability to grasp the concepts.
Sorry I just can't get the logic of what you are proposing, I fear it seems
to be some way short of acheiving what you hope for. I think I should just
leave you to it - give it a go - if it works ... and I do hope so ... I'll
include it!

Thanks for trying to explain ... good luck!

Phil