Anil,

> I realize that this is user mailing list, What I am suggesting will
> take little bit of development work.

It's alright. I believe the dev list is for actual development discussions, like a "do we code it in a switch-case or a cascading if-else" issue. We're still discussing whether we (as users) need this function.

> The tasks in Production run are nothing but WorkEffort.

Yes. And to confirm and align our understanding...

WorkEffort of type PROD_ORDER_HEADER are production runs.

WorkEffort of type PROD_ORDER_TASK are routing tasks inside production runs (not defined/template routing tasks).

(Above description won't be enough to implement your deep copy, but please bear with me for this thread.)

I would like to connect a routing task to a PO when the routing task calls for a sub-contracted service, like painting. Naturally, I'll usually need to ship some parts to my painting vendor for processing, so an outgoing shipment will be tied to this PO. Further, an incoming shipment when received should automatically put the processed parts back into the production run (via "Issue Components"?).

> WorkEffort has association with Order entity.

Hmm. I didn't realize OFBiz applications actually do this association. Does it? 
Example?

I'd prefer to have WorkEffort (production run) tie to OrderItem, actually. But about the only time such an association is made is when customer purchases a Configurable Product (like PC001) from ecommerce storefront, or some rental product (not too sure about this). I'd definitely like to be able to create a production run for every order item in an SO. But I digress.

How about tying a WorkEffort (routing task) to an OrderItem? That could be more consistent with existing logics. I think that it is semantically better (perhaps even correct) to tie a routing task to an OrderItem inside a PO, rather than to the PO itself.

Also, I might want to have a vendor do 3, not 1, services for me all at once: painting of some parts, decals, brushing. Then I can have 3 routing tasks linked to a single PO, one for each of the 3 OrderItems (painting, decals and brushing). When I receive the PO, I'd like OFBiz to automatically complete all 3 routing tasks for me, and pump the processed components back into production run for the following routing tasks.

> So what we can do is, Create a Template WorkEffort (Parent ) for the
> process that is repeated. This template workEffort can have more
> then one workeffort Associated with it. Each associated workEffort
> represents a task (or Step) in process. For the Tasks that will be
> out sourced, create a Template PO and associate it with WorkEffort.

Hmm. Yes, I like this idea very much. You doing this yet? Or still asking for inputs before you embark on it?

We can work on this together. What you're doing is definitely relevant to me 
(and mine to yours?).

Jonathon

Anil Patel wrote:
Jonathon,

Please forgive my ignorance of Manufacturing terms. Also Now I realize that
this is user mailing list, What I am suggesting will take little bit of
development work.

The tasks in Production run are nothing but WorkEffort. WorkEffort has
association with Order entity. So what we can do is, Create a Template
WorkEffort (Parent ) for the process that is repeated. This template
workEffort can have more then one workeffort Associated with it. Each
associated workEffort represents a task (or Step) in process. For the Tasks
that will be out sourced, create a Template PO and associate it with
WorkEffort.

Now for every production run, we do a Deep copy of Parent WorkEffort.

Regards
Anil Patel



On 1/19/07, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:

Anil,

How does that relate to my question on tying PO/SO to shipment and to
WorkEffort (production runs)?

Are you saying that there can be a tree of production runs, the upper
nodes being dependent on the
lower leaves?

So, I would have the following production runs:

1. Production run to manufacture a bicycle frame

2. To paint bicycle frame

3. To assemble bicycle

Production run 3 will be top level, and will depend on production run 2,
which will in turn
require 1 to be performed first?

Seems like an odd way to break up a production run. More convenient to
have all 3 production runs
above be made routing tasks instead, routing tasks that all reside within
a single production run.

I'd say the more user-friendly way, but more complex at coding level, is
to have the
sub-contracted routing task (painting) automatically tie to a PO buying
painting services.

Let me know if I understand you correctly?

Jonathon

Anil Patel wrote:
> Yesterday I applied a patch to Jira Issue for Deep copy of WorkEffort.
Its
> based on Idea of Create a Template WorkEffort (can have Assocs) , Then
use
> deep copy service to create instance of  it. This deep copy service can
be
> extended to even copy POs associated with WorkEffort.
>
> Any Ideas!
>
> Regards
> Anil Patel
>
>
>
> On 1/19/07, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
>>
>> Chris,
>>
>> I've confirmed that OFBiz doesn't do anything near as complicated as
what
>> I described below (in
>> 1st post in thread). (Even the routing task type of Sub-contracting
>> doesn't do anything?).
>>
>> I'd like to ask the community for advice of "best practices" before I
>> submit an enhancement. How
>> would you usually go about:
>>
>> 1. Starting production run.
>>
>> 2. Task1: Produce some parts.
>>
>> 3. Task2: Ship parts to vendor for painting.
>>
>> 4. Task3: Assemble painted parts.
>>
>> For Task2 (step 3 above), I'm proposing we have a PO for the painting
>> service, complete with a
>> link from PO to routing task, an outgoing shipment of pre-painted
parts,
>> and an incoming shipment
>> of painted parts.
>>
>> Has anyone done this yet (not merged into OFBiz)? Is it something that
a
>> sizable majority of the
>> community would need? How would such a majority propose I do the above?
>>
>> TIA for inputs!
>>
>> Jonathon
>>
>> Jonathon -- Improov wrote:
>> > Chris,
>> >
>> > Yeah, I read that. Nothing on what I'm talking about here.
>> >
>> > Let me try to get the requirements streamlined or simplified, and
>> see if
>> > OFBiz can handle then.
>> >
>> > Jonathon
>> >
>> > Chris Howe wrote:
>> >> I don't do any manufacturing in my day to day stuff so
>> >> this may not fit your bill exactly, but have you read
>> >> over this:
>> >>
>> >> http://ofbizwiki.go-integral.com/Wiki.jsp?page=Manufacturing
>> >> ?
>> >>
>> >> --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> Say I want to send some parts over to a vendor for
>> >>> painting services.
>> >>>
>> >>> Is there a way to:
>> >>>
>> >>> 1. Create a product of type "service" named
>> >>> PAINTING,
>> >>>
>> >>> 2. Create a PO to purchase this service,
>> >>>
>> >>> 3. Attach to this PO an outgoing shipment ferrying
>> >>> my parts to my vendor,
>> >>>
>> >>> 4. Receive the PO and have my painted parts in my
>> >>> inventory rather than the
>> >>>     product PAINTING.
>> >>>
>> >>> I've tried product associations like "Product
>> >>> Manufactured As", "New Version, Replacement" and "Equivalent or
>> >>> Substitute". Tried associations in
>> >>> both directions. No go.
>> >>>
>> >>> I can't "manufacture" PAINTING to produce the
>> >>> painted parts. Nor can I purchase PAINTING to receive the painted
>> parts.
>> >>>
>> >>> Any ideas?
>> >>>
>> >>> Jonathon
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date:
1/18/2007 6:47 PM




------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: 1/18/2007 6:47 
PM

Reply via email to