Hi Jacopo
I've been looking through the production run process a bit more and I'm
just not feeling that comfortable with doing a grouping above multiple
production runs, it seems like more of a hack than a solid improvement.
I'm thinking a better approach would be to just cater in the UI for
multiple WorkEffortGoodStandards (PRUN_PROD_DELIV) for each production
run, the data model seems like it would handle this no problem, except
that we would probably need to link what raw materials each product
consumed for actual costings. I've had a quick look through the mrp run
code and I can't see where this approach would cause problems, am I
missing something?
Thanks
Scott
Scott Gray wrote:
Hi Jacopo
I think we're pretty much on the same page now :-), I figured there
were a couple of ways to go about it but a new grouping above the
existing production run does seem like the easiest way to achieve what
I'm after. I might put together a couple of rough screen shots for
feedback. Many thanks to you and Rodrigo for your input, those tricks
will certainly come in handy later on.
Thanks
Scott
Jacopo Cappellato wrote:
Scott,
thanks for the example that is very helpful.
I still think that you should try to keep them as separate production
runs.
Why do you really need to create just one production run? In order to
simplify the production run creation? In order to provide a single
document to the workcenters' operators?
In order to make the process more user friendly you could develop
instead a new "create production run" screen (it would be nice to
include it in svn too) that, for example, makes you select the
virtual product and then the units that you want to manufacture for
each variants and then it will automatically create all the
production runs (maybe we could associate all the production runs
together using a naming convention or the WorkEffortAssoc entity or
the parentWorkEffortId).
And you could customize the manufacturing documents (pdf) to put
together the information (sorted by task) from all the production
runs of this group.
In my opinion this will allow you to keep low the development costs
and to maintain everything compatible with the existing processes
(MRP etc...)
Does it make sense?
Jacopo
Scott Gray wrote:
Hi Jacopo
Thanks for your comments, I like the idea of what you've suggested for
production planning. However what I need is garments that are actually
physically made together, I'll use your example of the T-Shirt to
illustrate
what i mean:
There are 3 basic routing tasks for making a garment -
1. Cutting - the patterns for both sizes are marked on to a
template, the
template is then layed on to say 50 layers of fabric in order to cut 50
t-shirts, cutting the sizes together saves on set up times and also raw
material usage.
2. Making - once the garments are cut they all require the same sewing
regardless of size. Side seams, neck binding, hemming etc., is
always more
efficient if you do them all in one go, you would never completely
make size
S and then get started on size L.
3. Finishing - once again all items are processed together.
Perhaps not suitable for svn? Another process that comes to mind is
getting
garments embroidered with logo's where 10 different products might
have the
same process performed in one run.
Regards
Scott
