Details

    • Type: New Feature
    • Status: Closed
    • Priority: Minor
    • Resolution: Implemented
    • Affects Version/s: Trunk
    • Fix Version/s: Upcoming Release
    • Component/s: manufacturing
    • Labels:
      None

      Description

      OFBIZ-5852 enables you to add a Party to a Routing Task (the WorkEffortPartyAssignment entity), to specify a person who is preferred to perform the task.

      If the person is on leave or unavailable, the production manager would have to manually specify a different person.

      It would be better to specify skill or skills required for the Routing Task. Then on each production run, any Party with the right skills could be scheduled to perform the task.

      There are already entities WorkEffortSkillStandard, PartySkill and SkillType which could be used to enable this.

      1. OFBIZ-9134.patch
        8 kB
        Suraj Khurana
      2. OFBIZ-9134.patch
        8 kB
        Suraj Khurana

        Issue Links

          Activity

          Hide
          deepak.dixit Deepak Dixit added a comment -

          This has been done at trunk r#1774725.

          Thanks Paul Foxworthy and Suraj Khurana for your contribution.

          Show
          deepak.dixit Deepak Dixit added a comment - This has been done at trunk r#1774725. Thanks Paul Foxworthy and Suraj Khurana for your contribution.
          Hide
          pfm.smits Pierre Smits added a comment - - edited

          Hi Paul,

          It is, for sure, part of a bigger scheduling solution. Which entail enhanced scheduling of all kinds of available resources assigned to all kinds of work efforts. This indeed involves knowing the pre-scheduling criteria, like skills and such of workers regarding production runs. As such, the patch to make the (advised/required) skills visible on schema tasks - as provided in the patch file(s) - is a first step. And should be enough given the title and description of this issue.

          The filtering/scheduling of workers does not take place on production schema and schema task. But on production run and production run tasks. And, with current manufacturing management solution in place, that is limited to pre-execution. Changes in resource allocation (due to unforeseen circumstances) can't be effected while a production run is being executed. But this is subject of another improvement issue.

          Anyway, I have reviewed the patch provided. And my conclusion is that:

          • would bring an enhancement to the component vis-a-vis features
          • does introduce a low to moderate (non-technical) risk to the project

          The risk is regarding adoption. I believe the issue and a patch is part of bigger feature enhancement. To name an example: without the proper demo data, this is just another piece where we let the (potential) adopter figure out how to use it. but that seems to be addresses.

          I suggest to wait with committing this patch until the demo data has been provided.

          Show
          pfm.smits Pierre Smits added a comment - - edited Hi Paul, It is, for sure, part of a bigger scheduling solution. Which entail enhanced scheduling of all kinds of available resources assigned to all kinds of work efforts. This indeed involves knowing the pre-scheduling criteria, like skills and such of workers regarding production runs. As such, the patch to make the (advised/required) skills visible on schema tasks - as provided in the patch file(s) - is a first step. And should be enough given the title and description of this issue. The filtering/scheduling of workers does not take place on production schema and schema task. But on production run and production run tasks. And, with current manufacturing management solution in place, that is limited to pre-execution. Changes in resource allocation (due to unforeseen circumstances) can't be effected while a production run is being executed. But this is subject of another improvement issue. Anyway, I have reviewed the patch provided. And my conclusion is that: would bring an enhancement to the component vis-a-vis features does introduce a low to moderate (non-technical) risk to the project The risk is regarding adoption. I believe the issue and a patch is part of bigger feature enhancement. To name an example: without the proper demo data, this is just another piece where we let the (potential) adopter figure out how to use it. but that seems to be addresses. I suggest to wait with committing this patch until the demo data has been provided.
          Hide
          paul_foxworthy Paul Foxworthy added a comment -

          Thanks Pierre,

          No, I'm not sure. I think this area is one many OFBiz adopters will want to customise. What I'm contemplating is a simple example implementation, and support in the data model so it would be fairly easy to write a customised service to assign parties to a routing task.

          You have implemented OFBiz in a manufacturing situation, so if you think there's no prospect for a simple implementation, I'd be happy to accept your advice.

          What really got me going on this was OFBIZ-5852. It is absolutely better than nothing, but won't scale. Associating a fixed party with a task means when that party is unavailable, there can be no automatic assignment at all. In contrast, if the assignment is skills based, when a party goes on leave or ceases to work for the organisation, the service can assign or suggest another party with appropriate skills.

          In the default implementation in OFBiz, I would be happy if the skills associated with the task are used to filter a list of parties, so only parties with the appropriate skills are offered to the production manager. If there are no skills, allow the production manager to browse all parties. Where skills have been set up, perhaps offer a list of parties filtered by skills first, with the ability to browse all parties if that's what the production manager wants to do.

          You say a production manager would only be able to assign parties that he or she can direct, members of a team over which the manager has some authority. So maybe the filter would not just be on skills. If we attach a party filter to a task to narrow down parties that might possibly perform it, we should think about criteria. Membership of a PartyGroup (a team or department) would be one, skills would be another. Are there any more we can think of?

          Cheers

          Paul

          Show
          paul_foxworthy Paul Foxworthy added a comment - Thanks Pierre, No, I'm not sure. I think this area is one many OFBiz adopters will want to customise. What I'm contemplating is a simple example implementation, and support in the data model so it would be fairly easy to write a customised service to assign parties to a routing task. You have implemented OFBiz in a manufacturing situation, so if you think there's no prospect for a simple implementation, I'd be happy to accept your advice. What really got me going on this was OFBIZ-5852 . It is absolutely better than nothing, but won't scale. Associating a fixed party with a task means when that party is unavailable, there can be no automatic assignment at all. In contrast, if the assignment is skills based, when a party goes on leave or ceases to work for the organisation, the service can assign or suggest another party with appropriate skills. In the default implementation in OFBiz, I would be happy if the skills associated with the task are used to filter a list of parties, so only parties with the appropriate skills are offered to the production manager. If there are no skills, allow the production manager to browse all parties. Where skills have been set up, perhaps offer a list of parties filtered by skills first, with the ability to browse all parties if that's what the production manager wants to do. You say a production manager would only be able to assign parties that he or she can direct, members of a team over which the manager has some authority. So maybe the filter would not just be on skills. If we attach a party filter to a task to narrow down parties that might possibly perform it, we should think about criteria. Membership of a PartyGroup (a team or department) would be one, skills would be another. Are there any more we can think of? Cheers Paul
          Hide
          pfm.smits Pierre Smits added a comment -

          Are we sure we want to put a complex solution to find suitable employees for a production task in place?

          In most companies, it is the production manager who assigns tasks to workers. And the pool is limited (only employees that are allocated under his management. This applies to both smaller and larger company. In a small company it easier than in a large company (where multiple similar departments can exist). The production manager knows his workers, and there are no others. In the larger company, the production manager will have to negotiate with the production managers of other (similar) production departments to get the resources.

          Show
          pfm.smits Pierre Smits added a comment - Are we sure we want to put a complex solution to find suitable employees for a production task in place? In most companies, it is the production manager who assigns tasks to workers. And the pool is limited (only employees that are allocated under his management. This applies to both smaller and larger company. In a small company it easier than in a large company (where multiple similar departments can exist). The production manager knows his workers, and there are no others. In the larger company, the production manager will have to negotiate with the production managers of other (similar) production departments to get the resources.
          Hide
          paul_foxworthy Paul Foxworthy added a comment -

          Thanks Pierre.

          This is the easy bit, the hard bit is using the skills data to allocate a party when scheduling a production run.

          Show
          paul_foxworthy Paul Foxworthy added a comment - Thanks Pierre. This is the easy bit, the hard bit is using the skills data to allocate a party when scheduling a production run.
          Hide
          pfm.smits Pierre Smits added a comment -

          I will review this patch later this week.

          Show
          pfm.smits Pierre Smits added a comment - I will review this patch later this week.
          Hide
          suraj.khurana Suraj Khurana added a comment -

          Oops ! Uploaded new patch. Thanks Paul.

          Show
          suraj.khurana Suraj Khurana added a comment - Oops ! Uploaded new patch. Thanks Paul.
          Hide
          paul_foxworthy Paul Foxworthy added a comment -

          Thanks Suraj.

          The request maps createRoutinTaskSkill, updateRoutinTaskSkill and deleteRoutinTaskSkill all need a "g" to make the word Routing.

          Show
          paul_foxworthy Paul Foxworthy added a comment - Thanks Suraj. The request maps createRoutinTaskSkill, updateRoutinTaskSkill and deleteRoutinTaskSkill all need a "g" to make the word Routing.
          Hide
          suraj.khurana Suraj Khurana added a comment -

          Soon, I will add patch for demo data as well.

          Show
          suraj.khurana Suraj Khurana added a comment - Soon, I will add patch for demo data as well.
          Hide
          suraj.khurana Suraj Khurana added a comment -

          Attached patch with proper fix. Please have a look.

          Show
          suraj.khurana Suraj Khurana added a comment - Attached patch with proper fix. Please have a look.
          Hide
          pfm.smits Pierre Smits added a comment -

          One of the first step in getting this new feature to completion is the availability of demo data for the referenced tables.

          Show
          pfm.smits Pierre Smits added a comment - One of the first step in getting this new feature to completion is the availability of demo data for the referenced tables.
          Hide
          paul_foxworthy Paul Foxworthy added a comment -

          Hi Pierre,

          Thanks, yes I think you're right. I've changed issue type to New Feature.

          Show
          paul_foxworthy Paul Foxworthy added a comment - Hi Pierre, Thanks, yes I think you're right. I've changed issue type to New Feature.
          Hide
          pfm.smits Pierre Smits added a comment -

          Shouldn't we consider this as a new feature?

          Show
          pfm.smits Pierre Smits added a comment - Shouldn't we consider this as a new feature?

            People

            • Assignee:
              deepak.dixit Deepak Dixit
              Reporter:
              paul_foxworthy Paul Foxworthy
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development