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

[jesse <je...@st...>]

I definitely see how just using StockMaster will work. I'm trying to make it
work better in environments with large stock needs. Really, I could load
over several million items into this... think about all those stock moves.
I think both our thoughts will work together together fine, though. What if
we made StockMaster types both serialised and controlled? - controlled would
indicate that a bundle reference (stockmoves.bundle) is to be associated
with it, serialised would indicate that both a bundle ref. and
individualised serial numbers existed. best of both worlds? Maybe you could
bounce a couple scenarios off me to make sure I'm not forgetting something?
also, what about the methods of importing all those items that I mentioned?
or printing an invoice w/ even a few thousand items?


jesse

> > > 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
>
>
>
> -------------------------------------------------------
> 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_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>