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

[Scott Gray]

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

some advices ?


Scott Gray wrote:

Did you have finish it , now I need do the same work , could you give me

Hi Jonathan



I had thought about creating a new order type along the lines of

code (purchasing the service and receipting the serviced products).


reviewing any work you decide to submit back to OFBiz.

Regards
Scott

Jonathon -- Improov wrote:

I haven't looked into this very deeply but was pondering it a while back. "GOODS_WORK_ORDER" and then using a combination of the sales order code (picking, packing and shipping the raw materials) and the purchase order I'm afraid I can't help get this done right now, but I could help with

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,

place. We can tie WorkEffort to OrderItem.

For associating a Order with WorkEffort, there is Orders tab in
WorkEffort

specify
OrderItem, But that will be a simple change.


purpose. Because now we have a OrderItem created for doing Task
specified in

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

future
someday.

Regards
Anil Patel



On 1/19/07, Jonathon -- Improov <j...@improov.com> wrote:

I understand what you are saying. All database entities seems to be in and we can associate a Order to WorkEffort there, It does not let us Expert Guidence is needed for use of WorkOrderItemFulfillment for this WorkEffort. where as this entity was designed to do just opposite. I that I am doing. I am not using Manufacturing component but may be in

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

whether we (as users) need
this function.

in a switch-case or a cascading if-else" issue. We're still discussing

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.


runs (not defined/template
routing tasks).


please
bear with me for this
thread.)


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

production run (via "Issue
Components"?).

WorkEffort of type PROD_ORDER_TASK are routing tasks inside production (Above description won't be enough to implement your deep copy, but I would like to connect a routing task to a PO when the routing task received should automatically put the processed parts back into the

WorkEffort has association with Order entity.

Does it? Example?

I'd prefer to have WorkEffort (production run) tie to OrderItem,
actually.
But about the only time

Product (like PC001) from

I'd definitely like to be

digress.

How about tying a WorkEffort (routing task) to an OrderItem? That
could be
more consistent with

correct) to tie a routing
task to an OrderItem inside a PO, rather than to the PO itself.


once: painting of some

single PO, one for each of

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.

Hmm. I didn't realize OFBiz applications actually do this association. such an association is made is when customer purchases a Configurable ecommerce storefront, or some rental product (not too sure about this). able to create a production run for every order item in an SO. But I existing logics. I think that it is semantically better (perhaps even Also, I might want to have a vendor do 3, not 1, services for me all at parts, decals, brushing. Then I can have 3 routing tasks linked to a the 3 OrderItems (painting, decals and brushing). When I receive the

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.



Regards
Anil Patel



On 1/19/07, Jonathon -- Improov <j...@improov.com> wrote:

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

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 <j...@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 <j...@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.

smime.p7s
Description: S/MIME cryptographic signature