RE: [Web-erp-developers] Reverse GRNs of Serialised stock

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

-- I just realised this did not get sent (over 24 hrs ago). Explains why I
never saw a response ;)


> > => item must have been received against the PO we are reversing
> pieces of
>
> Why do you need to have the PO specified - this is held against the GRN?

It is already specified, unless there's another way to get at doing a
Reverse GRN. When you process the reversal, PurchOrderDetails are being
updated to remove X Qty as being received and ensuring it is marked such
that has additional receiving necessary. Also, if I did not require that, I
would potentially have to find and update, say 10 different POs when
receiving items. Maybe necessary, though, as it may be difficult for some to
find where items they are reversing came from.

> > => any conditions a specialised stock module checks
> > + Delete records from Item-specific tables (only affects you if you have
> specialised stock modules)
>
> You got me here - cant keep up - is this some new functionality module??

Yes. I have them working... it is a pretty customizable setup (some assembly
required :) ) , but also easily (and I'd say by default) hidden...it
encompasses the standard serialised item (ie, you just have a single piece
of info - the serialno - that you want to store/maintain for the item), but
you wouldn't notice (from the UI, at least). You'll see soon - I don't think
it will interfere with anything. And I should have a couple examples.

> >
> > then, either:
> >
> > 1) Change/Invalidate SerialNo in StockItems Records.
> > a) Change Serial in All affected StockItem records to something
> bogus like
> 'XXXXXXXX' or just ''
> > b) Update StockItems w/ new StockMove No. for each.
> > c) Create StockItemMove for tracking (StockItemNo,
> OldStockMoveNo, New/Eff
> StockMoveNo)
> >
>
> > 2) Delete Item history
> > a) Delete records from StockItems
> > c) Delete StockItemMoves
> >
> >
>
> What about
> 3) Hybrid record reversal and delete stock item
> a)  Delete records from StockItems
> b) Create StockItemMove of a GRN reversal type for tracking (StockItemNo,
> OldStockMoveNo, New/Eff StockMoveNo)
>
> For security purposes we need some record of what happened but there is no
> point having the stockitem existing if its gone. Just 2c

Yes... the only problem (and it may just be in table struct) with 3b is that
StockItemNo and SerialNo are not the same. I keyed StockItems on an Int
Identity (StockItemNo) and allowed SerialNo to be just any var char with no
restrictions - I've just realized that I think I can leave the StockItem
entries in for that fact exactly. I figure when I have to select StockItems,
I'll always be coming through StockMoves, and you just wouldn't allow
someone to fullfill an order with an item you reversed, huh? So you're
hybrid works with out A which is the best scenario.