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
