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

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

> Again, I agree on the functionality, just not the implementation. If there
> is something wrong with what I've proposed before, please just give me a
run
> down of what will not work and a sample so I can consider it and see what
> you would think about how I would make that scenario work.

I can't say I understand your schema completely as yet, but I like the sound
of what you are proposing. This stuff is hard to describe and understand -
at least for the simple like me. Especially when I had in mind a method for
how I did it before. Your points about minimising the data in stockMoves
makes sense - some kind of drill down separate table of SerialisedMoves
would add to the complexity but possibly improve performance I agree.

> One note was your mention of disallowing BOMs to contain Serialised items.
I
> disagree... I also think what I've laid out alleviates your concerns with
> this. That, and I already have BOMs setup in situations where I definitely
> want one to contain both non-controlled,non-serialised items and
> controlled,serialised items.

Only "assembly" item BOMs - manufacturing items would of course need BOMs
that contain serialised items. Assembly items are just ghosted codes that
refer to a final assembly put together by the pickers rather than
manufacturing - there is no opportunity to enter serial numbers for the
components in this situation.

> And, in my mind, the data you would add to StockMoves for each serialised
> item in large moves would just duplicate most of the data for the other
> items involved... things not duplicated are simply numbers (qty, newqoh).
So
> why not just keep 1 copy of that data, and move the 1 thing (serial num)
> that really needs to change, but rarely needs to be directly referenced
> elsewhere and get it out of the way?

Yes good point.

>
> Did it actually handle the numbers being thrown around here? As I said,
> desigining it this way makes me nervous...
>
>
No it never had that kind of load.

> > Variable batch
> > control is a substantial undertaking and will trash the
> > system throughout
> > until we get it stable. It does add a fair bit of complexity
> > to scripts and
> > is not a project for the feint of heart!
> > Are you going to take it on ?
>
> Yes, it was my intention to start coding this... soon in fact. Keep in
mind,
> my original draw to this project was that you have an enormous amount of
> work put forth in areas that I had determined as necessary - before I
found
> it, I would have ended up writing the whole thing (ouch). I was mostly
> waiting to see what would come out of these discussions since they
obviously
> have a good deal to do with the coding...
>
> So, I think the question here is if you actually think my proposed system
> simply won't cut it, or if we are just coming to an impasse on design
ideas.

I'm coming round .... but still need a little more flesh on the idea ...
sorry:
 - what would this subsidiary serialstockmoves table look like?
 - how would the system deal with lots and batches?
 - would there be any control on quantities in batches/lots/bundles or could
these be any amount?
 - Don't understand you templatey idea?
 - how do we display all the serial numbers of items on hand at any one time
?
 - how do we display on invoices the serial numbers of items sold - if we
wanted to ?

I'm a pedantic b/std! Please bear with me I'll get there!

> If it's the later, I will try to get around to mocking up some tables,
> adding lots & lots of records to them, and running exisiting
queries/reports
> against them to see how they will perform.
>
> Thank you for having these discussions. I really am not trying to irritate
> you and am only being this persistant b/c I like the package you've put
> together and would like to help make it better - to that end, obviously I
> think the method I proposed will scale better than the way you'd
planned...
> again, though, please show me if you see holes in it so I can rethink my
> position.
>

Thank you for lending your knowledge to the greater good!
Certainly not irritated - enjoying the dialogue :-) .... its the only reason
I do it!
I think the discussion at this stage is great to ensure we get it right.

Phil