Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

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

Re: Purchasing services to process components, and receiving processed components

[Scott Gray <sc...@hotwaxmedia.com>]

I'm sorry I never did get time to work on it.

Regards
Scott

On 5/09/2009, at 3:27 PM, Zhiyong Cui wrote:

>
> Hi Scott
> Did you have finish it , now I need do the same work , could you  
> give me
> some advices ?
>
>
> Scott Gray wrote:
>>
>> Hi Jonathan
>>
>> I haven't looked into this very deeply but was pondering it a while  
>> back.
>>
>> I had thought about creating a new order type along the lines of
>> "GOODS_WORK_ORDER" and then using a combination of the sales order  
>> code
>> (picking, packing and shipping the raw materials) and the purchase  
>> order
>> code (purchasing the service and receipting the serviced products).
>>
>> I'm afraid I can't help get this done right now, but I could help  
>> with
>> reviewing any work you decide to submit back to OFBiz.
>>
>> Regards
>> Scott
>>
>> Jonathon -- Improov wrote:
>>> Anil,
>>>
>>>> For associating a Order with WorkEffort, there is Orders tab in
>>> WorkEffort
>>>> and we can associate a Order to WorkEffort there, It does not let  
>>>> us
>>> specify
>>>> OrderItem, But that will be a simple change.
>>>
>>> Yes, we can make the association there. But such an association
>>> doesn't seem to serve any purpose in OFBiz!
>>>
>>>> Expert Guidence is needed for use of WorkOrderItemFulfillment for  
>>>> this
>>>> purpose. Because now we have a OrderItem created for doing Task
>>> specified in
>>>> WorkEffort. where as this entity was designed to do just  
>>>> opposite. I
>>> think it
>>>> should be ok.
>>>
>>> You're right. It'll seem wrong to continue using that entity. The
>>> mapping was meant to be in the other direction.
>>>
>>> However, I also agree with you that there shouldn't be any harm in
>>> using that entity. That is just a relationship table, not an actual
>>> entity. The fact that the relationship between OrderItem and
>>> WorkEffort is put in a separate table like that means we can
>>> technically have a bidirectional relationship between OrderItem and
>>> WorkEffort.
>>>
>>> It looks like I can even tie > 1 routing tasks to a single OrderItem
>>> in a PO. I may want my bicycle frame to be polished, painted, and
>>> decal-ed, and I could make all 3 services a single Product (like
>>> product Id "DOLL_UP_BICYCLE_FRAME").
>>>
>>>> Beyond this point for tracking Outgoing shipment of parts and then
>>> receiving
>>>> them back into stock and production run, I cannot help much here.
>>>
>>> Ok.
>>>
>>> Yeah, there's still some work/planning needed for deciding how a
>>> "Service" product in a PO can be received as a "Subassembly" or
>>> "Finished Good" product. OFBiz doesn't seem to do this at the  
>>> moment.
>>>
>>>> I did this workEffort deep copy thing for Fixed Asset Maintenance
>>> project
>>>> that I am doing. I am not using Manufacturing component but may be
>>> in future
>>>> someday.
>>>
>>> Then I'll look at your deep copy function and see if I can extend or
>>> reuse it for what I need here in Manufacturing.
>>>
>>> Thanks!
>>>
>>> Jonathon
>>>
>>> Anil Patel wrote:
>>>> Jonathon,
>>>> I understand what you are saying. All database entities seems to  
>>>> be in
>>>> place. We can tie WorkEffort to OrderItem.
>>>>
>>>> For associating a Order with WorkEffort, there is Orders tab in
>>>> WorkEffort
>>>> and we can associate a Order to WorkEffort there, It does not let  
>>>> us
>>>> specify
>>>> OrderItem, But that will be a simple change.
>>>>
>>>> Expert Guidence is needed  for use of WorkOrderItemFulfillment  
>>>> for this
>>>> purpose. Because now we have a OrderItem created for doing Task
>>>> specified in
>>>> WorkEffort. where as this entity was designed to do just  
>>>> opposite. I
>>>> think
>>>> it should be ok.
>>>>
>>>> Beyond this point for tracking Outgoing shipment of parts and then
>>>> receiving
>>>> them back into stock and production run, I cannot help much here.
>>>>
>>>> I did this workEffort deep copy thing for Fixed Asset Maintenance
>>>> project
>>>> that I am doing. I am not using Manufacturing component but may  
>>>> be in
>>>> future
>>>> someday.
>>>>
>>>> Regards
>>>> Anil Patel
>>>>
>>>>
>>>>
>>>> On 1/19/07, Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>
>>>>> 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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> 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
>>>
>>>
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/Purchasing-services-to-process-components%2C-and-receiving-processed-components-tp8443719p25304779.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

Re: Purchasing services to process components, and receiving processed components

[Zhiyong Cui <zh...@gmail.com>]

Hi Scott
Did you have finish it , now I need do the same work , could you give me
some advices ?


Scott Gray wrote:
> 
> Hi Jonathan
> 
> I haven't looked into this very deeply but was pondering it a while back. 
> 
> I had thought about creating a new order type along the lines of 
> "GOODS_WORK_ORDER" and then using a combination of the sales order code 
> (picking, packing and shipping the raw materials) and the purchase order 
> code (purchasing the service and receipting the serviced products). 
> 
> I'm afraid I can't help get this done right now, but I could help with 
> reviewing any work you decide to submit back to OFBiz.
> 
> Regards
> Scott
> 
> Jonathon -- Improov wrote:
>> Anil,
>>
>> > For associating a Order with WorkEffort, there is Orders tab in 
>> WorkEffort
>> > and we can associate a Order to WorkEffort there, It does not let us 
>> specify
>> > OrderItem, But that will be a simple change.
>>
>> Yes, we can make the association there. But such an association 
>> doesn't seem to serve any purpose in OFBiz!
>>
>> > Expert Guidence is needed for use of WorkOrderItemFulfillment for this
>> > purpose. Because now we have a OrderItem created for doing Task 
>> specified in
>> > WorkEffort. where as this entity was designed to do just opposite. I 
>> think it
>> > should be ok.
>>
>> You're right. It'll seem wrong to continue using that entity. The 
>> mapping was meant to be in the other direction.
>>
>> However, I also agree with you that there shouldn't be any harm in 
>> using that entity. That is just a relationship table, not an actual 
>> entity. The fact that the relationship between OrderItem and 
>> WorkEffort is put in a separate table like that means we can 
>> technically have a bidirectional relationship between OrderItem and 
>> WorkEffort.
>>
>> It looks like I can even tie > 1 routing tasks to a single OrderItem 
>> in a PO. I may want my bicycle frame to be polished, painted, and 
>> decal-ed, and I could make all 3 services a single Product (like 
>> product Id "DOLL_UP_BICYCLE_FRAME").
>>
>> > Beyond this point for tracking Outgoing shipment of parts and then 
>> receiving
>> > them back into stock and production run, I cannot help much here.
>>
>> Ok.
>>
>> Yeah, there's still some work/planning needed for deciding how a 
>> "Service" product in a PO can be received as a "Subassembly" or 
>> "Finished Good" product. OFBiz doesn't seem to do this at the moment.
>>
>> > I did this workEffort deep copy thing for Fixed Asset Maintenance 
>> project
>> > that I am doing. I am not using Manufacturing component but may be 
>> in future
>> > someday.
>>
>> Then I'll look at your deep copy function and see if I can extend or 
>> reuse it for what I need here in Manufacturing.
>>
>> Thanks!
>>
>> Jonathon
>>
>> Anil Patel wrote:
>>> Jonathon,
>>> I understand what you are saying. All database entities seems to be in
>>> place. We can tie WorkEffort to OrderItem.
>>>
>>> For associating a Order with WorkEffort, there is Orders tab in 
>>> WorkEffort
>>> and we can associate a Order to WorkEffort there, It does not let us 
>>> specify
>>> OrderItem, But that will be a simple change.
>>>
>>> Expert Guidence is needed  for use of WorkOrderItemFulfillment for this
>>> purpose. Because now we have a OrderItem created for doing Task 
>>> specified in
>>> WorkEffort. where as this entity was designed to do just opposite. I 
>>> think
>>> it should be ok.
>>>
>>> Beyond this point for tracking Outgoing shipment of parts and then 
>>> receiving
>>> them back into stock and production run, I cannot help much here.
>>>
>>> I did this workEffort deep copy thing for Fixed Asset Maintenance 
>>> project
>>> that I am doing. I am not using Manufacturing component but may be in 
>>> future
>>> someday.
>>>
>>> Regards
>>> Anil Patel
>>>
>>>
>>>
>>> On 1/19/07, Jonathon -- Improov <jo...@improov.com> wrote:
>>>>
>>>> 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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> 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
>>
>>
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Purchasing-services-to-process-components%2C-and-receiving-processed-components-tp8443719p25304779.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Purchasing services to process components, and receiving processed components

[Scott Gray <le...@gmail.com>]

Hi Jonathan

I haven't looked into this very deeply but was pondering it a while back. 

I had thought about creating a new order type along the lines of 
"GOODS_WORK_ORDER" and then using a combination of the sales order code 
(picking, packing and shipping the raw materials) and the purchase order 
code (purchasing the service and receipting the serviced products). 

I'm afraid I can't help get this done right now, but I could help with 
reviewing any work you decide to submit back to OFBiz.

Regards
Scott

Jonathon -- Improov wrote:
> Anil,
>
> > For associating a Order with WorkEffort, there is Orders tab in 
> WorkEffort
> > and we can associate a Order to WorkEffort there, It does not let us 
> specify
> > OrderItem, But that will be a simple change.
>
> Yes, we can make the association there. But such an association 
> doesn't seem to serve any purpose in OFBiz!
>
> > Expert Guidence is needed for use of WorkOrderItemFulfillment for this
> > purpose. Because now we have a OrderItem created for doing Task 
> specified in
> > WorkEffort. where as this entity was designed to do just opposite. I 
> think it
> > should be ok.
>
> You're right. It'll seem wrong to continue using that entity. The 
> mapping was meant to be in the other direction.
>
> However, I also agree with you that there shouldn't be any harm in 
> using that entity. That is just a relationship table, not an actual 
> entity. The fact that the relationship between OrderItem and 
> WorkEffort is put in a separate table like that means we can 
> technically have a bidirectional relationship between OrderItem and 
> WorkEffort.
>
> It looks like I can even tie > 1 routing tasks to a single OrderItem 
> in a PO. I may want my bicycle frame to be polished, painted, and 
> decal-ed, and I could make all 3 services a single Product (like 
> product Id "DOLL_UP_BICYCLE_FRAME").
>
> > Beyond this point for tracking Outgoing shipment of parts and then 
> receiving
> > them back into stock and production run, I cannot help much here.
>
> Ok.
>
> Yeah, there's still some work/planning needed for deciding how a 
> "Service" product in a PO can be received as a "Subassembly" or 
> "Finished Good" product. OFBiz doesn't seem to do this at the moment.
>
> > I did this workEffort deep copy thing for Fixed Asset Maintenance 
> project
> > that I am doing. I am not using Manufacturing component but may be 
> in future
> > someday.
>
> Then I'll look at your deep copy function and see if I can extend or 
> reuse it for what I need here in Manufacturing.
>
> Thanks!
>
> Jonathon
>
> Anil Patel wrote:
>> Jonathon,
>> I understand what you are saying. All database entities seems to be in
>> place. We can tie WorkEffort to OrderItem.
>>
>> For associating a Order with WorkEffort, there is Orders tab in 
>> WorkEffort
>> and we can associate a Order to WorkEffort there, It does not let us 
>> specify
>> OrderItem, But that will be a simple change.
>>
>> Expert Guidence is needed  for use of WorkOrderItemFulfillment for this
>> purpose. Because now we have a OrderItem created for doing Task 
>> specified in
>> WorkEffort. where as this entity was designed to do just opposite. I 
>> think
>> it should be ok.
>>
>> Beyond this point for tracking Outgoing shipment of parts and then 
>> receiving
>> them back into stock and production run, I cannot help much here.
>>
>> I did this workEffort deep copy thing for Fixed Asset Maintenance 
>> project
>> that I am doing. I am not using Manufacturing component but may be in 
>> future
>> someday.
>>
>> Regards
>> Anil Patel
>>
>>
>>
>> On 1/19/07, Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>> 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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> 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
>
>

Re: Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

Anil,

 > For associating a Order with WorkEffort, there is Orders tab in WorkEffort
 > and we can associate a Order to WorkEffort there, It does not let us specify
 > OrderItem, But that will be a simple change.

Yes, we can make the association there. But such an association doesn't seem to serve any purpose 
in OFBiz!

 > Expert Guidence is needed for use of WorkOrderItemFulfillment for this
 > purpose. Because now we have a OrderItem created for doing Task specified in
 > WorkEffort. where as this entity was designed to do just opposite. I think it
 > should be ok.

You're right. It'll seem wrong to continue using that entity. The mapping was meant to be in the 
other direction.

However, I also agree with you that there shouldn't be any harm in using that entity. That is just 
a relationship table, not an actual entity. The fact that the relationship between OrderItem and 
WorkEffort is put in a separate table like that means we can technically have a bidirectional 
relationship between OrderItem and WorkEffort.

It looks like I can even tie > 1 routing tasks to a single OrderItem in a PO. I may want my 
bicycle frame to be polished, painted, and decal-ed, and I could make all 3 services a single 
Product (like product Id "DOLL_UP_BICYCLE_FRAME").

 > Beyond this point for tracking Outgoing shipment of parts and then receiving
 > them back into stock and production run, I cannot help much here.

Ok.

Yeah, there's still some work/planning needed for deciding how a "Service" product in a PO can be 
received as a "Subassembly" or "Finished Good" product. OFBiz doesn't seem to do this at the moment.

 > I did this workEffort deep copy thing for Fixed Asset Maintenance project
 > that I am doing. I am not using Manufacturing component but may be in future
 > someday.

Then I'll look at your deep copy function and see if I can extend or reuse it for what I need here 
in Manufacturing.

Thanks!

Jonathon

Anil Patel wrote:
> Jonathon,
> I understand what you are saying. All database entities seems to be in
> place. We can tie WorkEffort to OrderItem.
> 
> For associating a Order with WorkEffort, there is Orders tab in WorkEffort
> and we can associate a Order to WorkEffort there, It does not let us 
> specify
> OrderItem, But that will be a simple change.
> 
> Expert Guidence is needed  for use of WorkOrderItemFulfillment for this
> purpose. Because now we have a OrderItem created for doing Task 
> specified in
> WorkEffort. where as this entity was designed to do just opposite. I think
> it should be ok.
> 
> Beyond this point for tracking Outgoing shipment of parts and then 
> receiving
> them back into stock and production run, I cannot help much here.
> 
> I did this workEffort deep copy thing for Fixed Asset Maintenance project
> that I am doing. I am not using Manufacturing component but may be in 
> future
> someday.
> 
> Regards
> Anil Patel
> 
> 
> 
> On 1/19/07, Jonathon -- Improov <jo...@improov.com> wrote:
>>
>> 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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> 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

Re: Purchasing services to process components, and receiving processed components

[Anil Patel <to...@gmail.com>]

Jonathon,
I understand what you are saying. All database entities seems to be in
place. We can tie WorkEffort to OrderItem.

For associating a Order with WorkEffort, there is Orders tab in WorkEffort
and we can associate a Order to WorkEffort there, It does not let us specify
OrderItem, But that will be a simple change.

Expert Guidence is needed  for use of WorkOrderItemFulfillment for this
purpose. Because now we have a OrderItem created for doing Task specified in
WorkEffort. where as this entity was designed to do just opposite. I think
it should be ok.

Beyond this point for tracking Outgoing shipment of parts and then receiving
them back into stock and production run, I cannot help much here.

I did this workEffort deep copy thing for Fixed Asset Maintenance project
that I am doing. I am not using Manufacturing component but may be in future
someday.

Regards
Anil Patel



On 1/19/07, Jonathon -- Improov <jo...@improov.com> wrote:
>
> 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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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
>
>

Re: Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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

Re: Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

Andrew,

You're not missing the point. Anil created that service/function for another functionality altogether.

Yes, I do agree Anil's service won't do us any good, since we're only concerned with tying a PO 
(vendor services) to a PR (production run).

You're sharp! Good catch :)

Now, if you would throw me some complaints about OFBiz's current PR functionality (having no PO 
link), I'll get to work serving both my boss and you!

Jonathon

Andrew Ballantine wrote:
> Anil,
> 
> This sounds like way too much human intervention. The order if the finished
> product should kick-off all the subsidiary processes and POs automatically
> otherwise the implementation of OFBiz is going to create jobs rather than
> reduce the need for extra staff.
> 
> Sorry if I am missing the point.
> 
> Kind regards,
> 
> Andrew Ballantine.
> 
> -----Original Message-----
> From: Anil Patel [mailto:toanilpatel@gmail.com]
> Sent: 19 January 2007 17:32
> To: user@ofbiz.apache.org
> Subject: Re: Purchasing services to process components, and receiving
> processed components
> 
> 
> 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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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.6/646 - Release Date: 23/01/2007
> 03:36
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
> 03:36
> 
> 
> 
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************
> 
> 

RE: Purchasing services to process components, and receiving processed components

[Andrew Ballantine <ac...@willowbrook.co.uk>]

Anil,

This sounds like way too much human intervention. The order if the finished
product should kick-off all the subsidiary processes and POs automatically
otherwise the implementation of OFBiz is going to create jobs rather than
reduce the need for extra staff.

Sorry if I am missing the point.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Anil Patel [mailto:toanilpatel@gmail.com]
Sent: 19 January 2007 17:32
To: user@ofbiz.apache.org
Subject: Re: Purchasing services to process components, and receiving
processed components


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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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.6/646 - Release Date: 23/01/2007
03:36

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
03:36



*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************

Re: Purchasing services to process components, and receiving processed components

[Anil Patel <to...@gmail.com>]

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 <jo...@improov.com> 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 <jo...@improov.com> 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 <jo...@improov.com> 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
>
>

Re: Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

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 <jo...@improov.com> 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 <jo...@improov.com> 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

Re: Purchasing services to process components, and receiving processed components

[Anil Patel <to...@gmail.com>]

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 <jo...@improov.com> 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 <jo...@improov.com> 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
> >>>
> >>
> >>
> >
> >
>
>

Re: Purchasing services to process components, and receiving processed components

[Jacopo Cappellato <ti...@sastau.it>]

It would be really nice to finally implement some of the processes
needed in sub-contracts and external manufacturing activities, I would
be interested too.
Also having a specialized set of production run management screens to
track and log the external processes would be worth of some work.

Jacopo

Andrew Ballantine wrote:
> Jonathon,
> 
> My client is going to need this type of off-site production.
> 
> I thought OFBiz already catered for this.
> 
> Kind regards,
> 
> Andrew Ballantine.
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: 19 January 2007 08:00
> To: user@ofbiz.apache.org
> Cc: Tom Anderson
> Subject: Re: Purchasing services to process components, and receiving
> processed components
> 
> 
> 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 <jo...@improov.com> 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.6/646 - Release Date: 23/01/2007
> 03:36
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
> 03:36
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
> 03:36
> 
> 
> 
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************

RE: Purchasing services to process components, and receiving processed components

[Andrew Ballantine <ac...@willowbrook.co.uk>]

Jonathon,

When I said that my client WILL need this functionality, that means my
client hasn't yet committed to using OFBiz. So my time, at the moment is
wasted keeping his MS Access project alive.

I can certainly help a bit with testing, but haste is not required at the
moment, but I think it's great that you have so much energy and enthusiasm.
Once I can get the go-ahead from my client, I shall be quite active.

So let us know what you propose and we can all contribute ideas as to how it
should be done for the benefit of the OFBiz community at large.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: 23 January 2007 13:37
To: user@ofbiz.apache.org
Cc: Tom Anderson; Ian McNulty
Subject: Re: Purchasing services to process components, and receiving
processed components


Andrew,

Wait a sec! Ie, hear me out. :)

OFBiz does cater for this in the database end of things.

My boss needs it; you need it. If you're willing to work with me on this
(even something simple as
help with user-testing and complaining), I'm sure I can get this up within a
couple of days, or
less. Meaning, "right away".

How about that?

Jonathon

Andrew Ballantine wrote:
> Jonathon,
>
> My client is going to need this type of off-site production.
>
> I thought OFBiz already catered for this.
>
> Kind regards,
>
> Andrew Ballantine.
>
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: 19 January 2007 08:00
> To: user@ofbiz.apache.org
> Cc: Tom Anderson
> Subject: Re: Purchasing services to process components, and receiving
> processed components
>
>
> 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 <jo...@improov.com> 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.6/646 - Release Date: 23/01/2007
> 03:36
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
> 03:36
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
> 03:36
>
>
>
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************
>
>



--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
03:36


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
03:36

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
03:36

Re: Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

Andrew,

Wait a sec! Ie, hear me out. :)

OFBiz does cater for this in the database end of things.

My boss needs it; you need it. If you're willing to work with me on this (even something simple as 
help with user-testing and complaining), I'm sure I can get this up within a couple of days, or 
less. Meaning, "right away".

How about that?

Jonathon

Andrew Ballantine wrote:
> Jonathon,
> 
> My client is going to need this type of off-site production.
> 
> I thought OFBiz already catered for this.
> 
> Kind regards,
> 
> Andrew Ballantine.
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: 19 January 2007 08:00
> To: user@ofbiz.apache.org
> Cc: Tom Anderson
> Subject: Re: Purchasing services to process components, and receiving
> processed components
> 
> 
> 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 <jo...@improov.com> 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.6/646 - Release Date: 23/01/2007
> 03:36
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
> 03:36
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
> 03:36
> 
> 
> 
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************
> 
> 

RE: Purchasing services to process components, and receiving processed components

[Andrew Ballantine <ac...@willowbrook.co.uk>]

Jonathon,

My client is going to need this type of off-site production.

I thought OFBiz already catered for this.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: 19 January 2007 08:00
To: user@ofbiz.apache.org
Cc: Tom Anderson
Subject: Re: Purchasing services to process components, and receiving
processed components


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 <jo...@improov.com> 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.6/646 - Release Date: 23/01/2007
03:36


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
03:36

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.6/646 - Release Date: 23/01/2007
03:36



*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************

Re: Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

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 <jo...@improov.com> 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
>>>
>>
>>
> 
> 

Re: Purchasing services to process components, and receiving processed components

[Jonathon -- Improov <jo...@improov.com>]

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 <jo...@improov.com> 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
>>
> 
> 

Re: Purchasing services to process components, and receiving processed components

[Chris Howe <cj...@yahoo.com>]

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 <jo...@improov.com> 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
>