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

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

> > Dont have head completely around the stock movement issues. In a
previous
> > system I wrote the stockmoves table held the information about the
item's
> > serial number a stock move being created for all serial number items eg
a
> > stock movement of 3 invoiced out for a controlled item would require
> > specification of each individual item so this would not be possible -
this
> > would need to be a rule enforced by reference to the stock master. Stock
> > Master also needs additional fields for the number of units of measure
per
> > bundle - this would determine whether there is only allowed one
> > item (in the
> > units of measure) per serial number or potentially 1000 of the unit of
> > measure in a lot or 99999 metres per bundle of cloth. Also, the number
of
> > decimal places to display for the stock item in inquiries. eg
> > stock held per
> > tonne but .01 of a tonne is of interest at stock checks etc.
> Ok. 1st, if I hadn't mentioned it, I don't come from a 'physical
inventory'
> world, I come from a 'service/usage world' (which, if you don't know,
you're
> not going to like :) ), so I'm probably not as familiar with that as you
are
> and you may get dumb questions on things...that said...
> I don't really see a need for that. I would consider all of those
> situtations just quantities ordered - the stockmaster item has units,
which
> I had always interpreted as usually being 'each' (as defaulted) or a
> standard unit of weight or measurement, both of which can be easily
> accounted for as a Quantity. Some user friendliness may be in order for
user
> interfaces (order entry, reports...), though,  as most people would not
want
> to have to figure out that they wanted to order 0.001 tonne of something
> when they want a kilogram, though...maybe that leads to a sort of product
> catalog, kinda like the BOMs, with 'preconfigured' StockMoves of what you
> actually sell (as opposed to what you order & stock).
>

Of course the most appropriate unit of measure is used - the point is some
things can and should be allowed to be issued and sold in fractions of a
unit and if so the system should allow the user to determine how many
decimal places to display. Currently we have no way to specify this.


> > In the eg above the stockmoves table would actually record 3 seperate
> > records each with the Bundle field set to the serial number. The invoice
> > would show the serial number of each item sold (or the bundle/lot etc)
the
> > stock quantity by location would reflect the changes effected by the 3
> > separate stockmoves. However we would need to expand the LocStock table
to
> > have bundle (or serialNo or such) in it too, the stock status
> > inquiry would
> > then sum the stock of all serial number items by location.
> Going on the above, and assuming that we can keep up accounting (tedious,
> but doable) such that the Qty in the StockMove is correctly reflected in
the
> StockItems (ie, the reconciliation program would never complain), that
extra
> work shouldn't be necessary.

I guess I am saying I don't see the necessity for a StockItems table as
distinct from the StockMaster and the StockMoves - all information about
each movement is recorded against the StockMoves and all info about the item
itself is in the StockMaster, so what is the purpose of the extra table ??

>In my thoughts, a 'StockMove' becomes an
> extension of the Invoice item - there are options in invoicing (possibly
> attached to StockMaster instead, as a 'Controlled'-only variable) that
allow
> the detail for each item/serialnum sold to be shown, or not, on an
invoice.

Yes that's it in fact on the printing of invoices and credit notes the
StockMoves are what makes up the detail of the invoice.

> The Bundle field, which could be added to the invoice, could make a great
> tracking or lot number to represent Qty sold instead of printing a
StockMove
> num, but may need to be lengthened (though we may also need further ids
for
> shipping purposes (5 of the 25 '30 yard rolls of cloth' per box??).

We already have a quantity field in the StockMoves table - the bundle field
is meant to refer to the actual serial number of the item moving. This is
defaulted to 1 where there is no bundle/bath/lot/serial number control
required.

>I can
> also see a need in various stockmodules to produce a manifest of the items
> the actually went with an invoice.

These should be spelled out on the invoice - this would simply be a listing
of the stock movements displaying the 'bundle' as well on the invoice.

> Keep in mind that I am planning for quite large tables of items - like
> creating 100,000 items and selling them 50,000 at a time, but still
wanting
> to know exactly where every single one of them is.


A fair bit of input - bar coding may well be appropriate too.

Phil