Copying WorkEffortCostCalc as part of a ProductionRun

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Copying WorkEffortCostCalc as part of a ProductionRun

Bob Morley
When you create a new production run for a particular product, a clone of the routing template work effort tree is created for the new production run.  In doing this any WorkEffortPartyAssignment entities are also copied along with the BillOfMaterials information (into WorkEffortGoodStandard).

My question is why do we not also clone the WorkEffortCostCalc.  If we were to do this, tasks that were created via the routing template OR manually created could be handled consistently.  We would also have the ability to update the WorkEffortCostCalc for that specific ProductionRun.  I assume this latter point is the reason why we are copying WorkEffortPartyAssignment so that different people can be assigned the task without affecting the routing template itself.

What I would like to do is start cloning these records for the new ProductionRun and then change createProductionRunTaskCosts so that it will simply use the WorkEffortCostCalc entities associated with the specific task (rather than potentially using the associated routing task).

Very interested in hearing from anyone with practical experience with ProductionRuns to see if I am missing something (or any developers that worked in this area).
Reply | Threaded
Open this post in threaded view
|

Re: Copying WorkEffortCostCalc as part of a ProductionRun

Jacopo Cappellato-4
Yes, I think it is a good idea. Thanks for working at this.

Jacopo


On Apr 19, 2010, at 6:37 PM, Bob Morley wrote:

>
> When you create a new production run for a particular product, a clone of the
> routing template work effort tree is created for the new production run.  In
> doing this any WorkEffortPartyAssignment entities are also copied along with
> the BillOfMaterials information (into WorkEffortGoodStandard).
>
> My question is why do we not also clone the WorkEffortCostCalc.  If we were
> to do this, tasks that were created via the routing template OR manually
> created could be handled consistently.  We would also have the ability to
> update the WorkEffortCostCalc for that specific ProductionRun.  I assume
> this latter point is the reason why we are copying WorkEffortPartyAssignment
> so that different people can be assigned the task without affecting the
> routing template itself.
>
> What I would like to do is start cloning these records for the new
> ProductionRun and then change createProductionRunTaskCosts so that it will
> simply use the WorkEffortCostCalc entities associated with the specific task
> (rather than potentially using the associated routing task).
>
> Very interested in hearing from anyone with practical experience with
> ProductionRuns to see if I am missing something (or any developers that
> worked in this area).
> --
> View this message in context: http://n4.nabble.com/Copying-WorkEffortCostCalc-as-part-of-a-ProductionRun-tp2016212p2016212.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Copying WorkEffortCostCalc as part of a ProductionRun

Bob Morley
I have created a ticket and applied a patch https://issues.apache.org/jira/browse/OFBIZ-3724.

There are some comments there about two things that we probably should discuss a little bit before committing this change.  Will leave the conversation to flow under that ticket.
Reply | Threaded
Open this post in threaded view
|

Re: Copying WorkEffortCostCalc as part of a ProductionRun

BJ Freeman
In reply to this post by Bob Morley
some thoughts
if you provide a way to change a process you must make sure it can not
be changed once it is used for Resource planning without feeding back
the change to the Resource planning component.

cloning from a template or cloning to create a template is acceptable.
Cloning of data that is in two places creates a sync situation.
This trickles down to the BI component.

I have more but it will take me awhile to verify and pull together.
been a while since I worked product run code.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Bob Morley sent the following on 4/19/2010 9:37 AM:

> When you create a new production run for a particular product, a clone of the
> routing template work effort tree is created for the new production run.  In
> doing this any WorkEffortPartyAssignment entities are also copied along with
> the BillOfMaterials information (into WorkEffortGoodStandard).
>
> My question is why do we not also clone the WorkEffortCostCalc.  If we were
> to do this, tasks that were created via the routing template OR manually
> created could be handled consistently.  We would also have the ability to
> update the WorkEffortCostCalc for that specific ProductionRun.  I assume
> this latter point is the reason why we are copying WorkEffortPartyAssignment
> so that different people can be assigned the task without affecting the
> routing template itself.
>
> What I would like to do is start cloning these records for the new
> ProductionRun and then change createProductionRunTaskCosts so that it will
> simply use the WorkEffortCostCalc entities associated with the specific task
> (rather than potentially using the associated routing task).
>
> Very interested in hearing from anyone with practical experience with
> ProductionRuns to see if I am missing something (or any developers that
> worked in this area).


Reply | Threaded
Open this post in threaded view
|

Re: Copying WorkEffortCostCalc as part of a ProductionRun

Bob Morley
BJ Freeman wrote
some thoughts
if you provide a way to change a process you must make sure it can not
be changed once it is used for Resource planning without feeding back
the change to the Resource planning component.

cloning from a template or cloning to create a template is acceptable.
Cloning of data that is in two places creates a sync situation.
This trickles down to the BI component.
Yep this is a real good point; we need to avoid data redundancy at all times in the operational database.  I must confess that I am not very familiar with the resource planning in Ofbiz at all.

What I have now in our project is a routing template that you can only assign specific resources to it the form of WorkEffortPartyAssignment.  These relations (between WorkEffort and Party) were always cloned from the routing template (I made no change there).  The implication is that the WorkEffort's resource could change during some parts of the ProductionRun lifecycle.  In my mind this was during the "non-finished" states -- Created, Documents Printed, Running -- but not during Completed, Closed, Cancelled.

How does the Ofbiz resource planning component fit in here?  What I have now puts the onus on either the template task creator to assign the specific resources up front or on the user that is creating the Production Run (or printing docs / starting) to assign specific resources to the tasks before things get rolling.
Reply | Threaded
Open this post in threaded view
|

Re: Copying WorkEffortCostCalc as part of a ProductionRun

BJ Freeman
In reply to this post by BJ Freeman
Resource planning is usually against requirements. These can be
realistic like sales orders, or what if's projection.

ofbiz(trunk svn) at this point is limited to sales orders requirements
if you look at the applications\manufacturing\data\ManufacturingData.xml
it will give you and Idea of the MrpEventType.
with project manager, it would provided some "what-if scenarios" as well
as well as give an overview of actual requirements and  the progress of
a requirement. I am looking at what it will take for this integration now.
Based on that if the WorkEffortCostCalc or any manufacturing processes
are modifies after the project manager has shown a result, a task
message should be generated be generate to view the project manager
results again, noting what was changed.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Bob Morley sent the following on 4/19/2010 9:39 PM:

>
> BJ Freeman wrote:
>> some thoughts
>> if you provide a way to change a process you must make sure it can not
>> be changed once it is used for Resource planning without feeding back
>> the change to the Resource planning component.
>>
>> cloning from a template or cloning to create a template is acceptable.
>> Cloning of data that is in two places creates a sync situation.
>> This trickles down to the BI component.
>>
>
> Yep this is a real good point; we need to avoid data redundancy at all times
> in the operational database.  I must confess that I am not very familiar
> with the resource planning in Ofbiz at all.
>
> What I have now in our project is a routing template that you can only
> assign specific resources to it the form of WorkEffortPartyAssignment.
> These relations (between WorkEffort and Party) were always cloned from the
> routing template (I made no change there).  The implication is that the
> WorkEffort's resource could change during some parts of the ProductionRun
> lifecycle.  In my mind this was during the "non-finished" states -- Created,
> Documents Printed, Running -- but not during Completed, Closed, Cancelled.
>
> How does the Ofbiz resource planning component fit in here?  What I have now
> puts the onus on either the template task creator to assign the specific
> resources up front or on the user that is creating the Production Run (or
> printing docs / starting) to assign specific resources to the tasks before
> things get rolling.