RE: [Web-erp-developers] Credit Items & Controlled Items

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

Hum... let me remind you how I've put this together since it wasn't quite
like you had originally thought of doing it, and some of your answers seem
to be refering to your way rather than how I've coded it....from the top,

A StockMaster record can be Controlled. If it is Controlled, it can also be
Serialised, but does not have to be. If it is Serialised, a StockModule is
required (that has no bearing on this discussion except that it's part of my
changes). Lastly, the *only* inventory table considered to be 1-to-1 is
StockItems - a StockMoves record could have a Qty of 1, thus being 1-to-1,
but just as easily could have Qty 0.1 (g when StockMaster.Units in kg) or
100 (Cell Phones w/ SerialNos). Further, Serialised item Qtys are always
Integers - no decimal places. This has just made me remember I need to make
sure I enforce that everywhere!

Controlled means that anytime a StockMove is being done, the User is
required to enter a Bundle(Id) for it - some sort of Id that can be used to
generally refer to the full Qty involved in that StockMove. That, so far,
entails POs, SOs, Stock Transfers, Stock Adjustments, Credits, ReverseGRNs,
and anything else I run upon that I missed.

Serialised means that you have a single item with a single tracking number
(through a little code you could fairly easily code and decode single
SerialNos from multiple ones if necessary - I'll explain later). B/c of some
of the things we are talking about, these items can be moved between
StockMoves outside their original Qty (someone returning 1 item out of 10
sold to them, selling 5 of 1000 purchased). StockItemMoves tracks those with
the ItemId, and the old and new StockMoveNo. From that, you basically can
look at all the previous StockMoves a item was part of if you need to.

based on that, some answers below... and maybe check out the other email
again...
> > if Controlled, allow:
> > 1) Enter/Select 1 to X Bundles based on the StockId and the Quantities
> from each bundle being Returned. Qty's being returned must be <=the Qty of
> the Original Bundle.
>
> Do you mean Sum(Qty) of the individiual bundles must be == Qty of
> the total
> stock move, or is perhaps accumulated into == that quantity for the stock
> move record?

I mean that you can Credit X, Y, and Z qty of items of out 3 different
Bundles so long as X,Y,& Z are all <= the Qty of each Bundle they refer to.
Or do it w/ (2)

One thing - to Credit, I am adding an option that allows/forces you to pick
whether or not you are going to strictly Credit (verify each item) or
loosely credit (the geezums) - that is option (2) here....

> > 2) Additionally, you may Credit any Quantity without referencing an
> existing Bundle
> > if Serialised: Items are treated like they are being brought in on a PO
> where Item details must be verified and the total number of Items
> must match
> the Qty being Credited.
>
> Could the quantity be accumulated from the bundles rather than
> entering the
> quantity and then trying to tie it up.

Certainley... though probably by defaulting the value of the Qty field the
the full Qty :)

> > There's nothing to keep the user from using a previous BundleId, but I
> won't be prepopulating that. The alternative would be to treat each
> 'sub-line' (ie, all 5 Bundles of a StockId) as a full line, complete with
> it's own BundleId and StockMove.
>
> That kinda what I was thinking originally - but your method of keeping
> bundle movements table separately I thought was better.

I may actually make it possible to control (or not) BundleIds so that you
(ok, the code) could grab a new one and force it to be used when doing a
move. I guess that would be an option...