Re: [Web-erp-developers] Re: some serialised work

[Phil D. <ph...@du...>]

> serialmoves...hum...Did you check out my response on that and the sql
statements in it? you had linked the tables a bit off in your 1st email
about them.
> If you still see problems, let's chat about the restructuring a bit...

Yeah I saw your reply which basically confirmed that we are into outer joins
or several copies of the table to get all the movements of serialised items.

> > 3) I'll continue work on expanding the rest of the scripts
> for Serialised
> support now that part of the base changes are fairly settled
> and we are just
> back to defining functional requirements for Serialised support.
> >

I rekon defining the functional requirements comes first in many ways, it is
only when there is a clear idea of what is required to be output that we can
define appropriately the inputs. There may be outputs that you require that
are best served with the structure you have. I do like your treatment of the
serialised stuff by entirely separate tables thus leaving the level about
completely untouched - damn clever!

I think knowing:
- to whom and the date a serial item is sold
- when a serial number arrived (or was made)
- when it was returned if it was credited

This is basically the stock movement inquiry I was talking about. I think
this could be a sub-inquiry from the stockmovements inquiry ie to click on a
stockmovement record to get the lower level serial moves.

We also need to know:

- what serial numbers we have in stock

Not sure how we get this from StockSerialItems ? I am not happy with a
requirement to retrieve all stock movements to re-calculate the stock on
hand - a 2 minute query - choking other activity - when there may be none!
This also ignores the possibility of purging old data. To  my mind this
would have to be an update to the SerialStockItems at the time of a
movement.

Phil