I had accidentally replied via nabble to the Ofbiz - Commits sub-form; so I am going to move my response to Ofbiz - Dev. If anyone saw that, I am going to rework my response here because after some consideration and discussion in our office, I think we have a better proposal.
-- Part of this revision caused the TimeEntry to no longer be created for work performed on the ProductionRun task. Was the comment out intentional? Let's say this was an accident ... I think it is valuable to be creating the TimeEntry for the WorkEffort. It provides valuable information about a resource allocating time to the particular task. The trouble with the original implementation is that the data model resource book seemed to have a single "time" for this purpose -- "hours" on TimeEntry along with "hours" on the WorkEffort (in terms of the total hours spent). There are good reasons to be able to have separation on the Work Effort for various classifications of "time worked" on a specific Task. Currently, there are two classifications "setup" and "task" hours (specified in milliseconds). The trouble is that a single TimeEntry is not going to provide us with this split. My initial recommendation was to create a new entity WorkEffortTimeEntry that would allow a single WorkEffort to be bound to many TimeEntry entities. These entities could have different types so you would have the details of the materialized amount that is stored on the WorkEffort itself. However, I think it would actually be better to consider going with two (or more) WorkEfforts and each of them having its own TimeEntry. The idea here is if you have a production run and you have a Task which has some Setup and some Task work, then it really should be modeled as two dependent work efforts. Each of those work efforts would have "estimated/actual" "hours" column as per the Data Model Resource Book volume 1. We could use WorkEffort association to bind them together if you wanted to navigate a particular task that is related to others (naturally it could also be modeled as a separate ProductionRun if you were so inclined). At any rate, by doing this it would be possible to have a setup, task, teardown and any other arbitrary set of "pieces" of a particular Work Effort. Each of these would have their own estimate / actual (rather than being bound to two specific ones as it is now). Moreover, the TimeEntry would be the details that produce the materialized "hours" on the work effort. Would should also entertain changing both the "hours" on TimeEntry and the "estimatedMilliSeconds" / "actualMilliSeconds" to a generic "time" field with an associated Unit of Measure. This would allow folks to do these things at the milli second granularity if they really want, otherwise any other "time" UOM could be used (I suspect hours would be the norm). -- View this message in context: http://n4.nabble.com/Regarding-SVN-commit-r892904-tp2018084p2018084.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
