On Apr 20, 2010, at 11:25 PM, Bob Morley wrote: > > 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 ...
If I am not wrong at that time I disabled it because it was only partially implemented feature; it had to be enhanced and completed before it is usable. However I agree that time entries are an important concept and would be a very nice feature to have, especially when we will have decent ui to enter them and possibly a specialpurpose manufacturing application where: 1) a user logs in 2) all the tasks assigned to the users, or to the fixed asset (workcenter) where the user works, appears 3) the user can enter the time spent on the task (time entries), the materials used and produced; any scrap etc... Jacopo > > 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.
