Thanks Pierre,I've been examining the WorkEffort entity its sufficient for handling any of the gaps in the Manufacturing app.
Currently I'm having trouble wrapping my head around how production run task declarations are supposed to work. I created a production run to produce 2 of a product from a route containing 3 routing tasks:
1. DEFAULT_TASK - used to stock out the BOMs and represent the manufacturing work performed 2. Inspection - performed in the same dept as manufacturing 3. Cleaning/Inspection - performed by a dept other than the one where manufacturing was performed (capable of detecting flaws the previous inspection could not while cleaning to prepare for the next manufacturing stage)I issued components and completed the first task. Then I started the second task and declared 1 reject and completed. Before completing, task 2 (Inspection) indicated a producted quantity of 0. Upon completion, the quantity produced was changed to 1 (2 from DEFAULT_TASK - 1 reject). Then I started the third task and declared 1 reject and completed. Before completing the third task, the producted quantity indicated 0 (1 non-reject from task2 - 1 reject) but upon completion the produced quantity = 1. Also, the rejected quantity remains 0 after all tasks are completed.
Shouldn't the rejected quantity be 2 and quantity produced be 0 for the last task? Am I misunderstanding something or is this a bug?
On 02/01/2014 02:10 PM, Pierre Smits wrote:
But, if your business process(es) regarding the quality inspection of the products have the requirement that forms need to be filled out that are specific to that process and need to be done by other persons than those in the manufacturing process then you will need something else than just the functionalities in the manufacturing component. Maybe you are not aware of this, but underneath the manufacturing functionalities (and supporting those) are services and entities from the workeffort component. Maybe you should look at that component as well to figure out how your challenge should be solved. Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Sat, Feb 1, 2014 at 5:19 PM, Pierre Smits <pierre.sm...@gmail.com> wrote:Christian, Reading through the mails in this thread I will try to address your issues. First, a production run can include tasks for quality inspection. When done, the standard cost of the inspection is incorporated in the cost price of the product to be manufactured. However, including such a task does not define the sub process the quality inspection department has to execute. It will merely tell the production manager (when such sub process has been defined properly) what to do with the conclusions of that department regarding the production run (meaning, everything is ok, everything is wrong, only parts are wrong). The production manager can subsequently set the correct output of the production run and the defects. Secondly, if there is indeed a strong need to have this quality inspection process in manufacturing and it has multiple tasks to be performed, it can be solved with ootb functions in the manufacturing process. Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Jan 31, 2014 at 10:10 PM, Christian Carlow < christian.car...@gmail.com> wrote:Answering my own question, I think adding a separate facilityId field to the production run stock in options is unnecessary. The current method where the facilityId is automatically set to the one assigned to the production run seems correct. Inventory transfers seems to be the correct way to handle cases where production run stocks are supposed to end up in a facility other than the one assigned to the production run. It just seems awkward doing it this way because technically the transfer occurred during the production run when Edging sent the pieces to Edging Inspection for the inspection task. If this were modeled in the ticket system, its as if the inspection dept sent the pieces back to the Edging dept just so it could send it back to the Inspection dept. But I think this awkwardness is due to the incorrect data modeling used for the ticket system. On 01/31/2014 02:32 PM, Christian Carlow wrote:The inventory transferring difficulties mentioned in my last post seem invalid. When a production run is started the BOMs are deducted when the first task is completed (by default). Therefore the inventory would not exist to be transferred to the inspection dept when that production run task is supposed to occur. So it seems inventory transfers between facilities is irrelevant when dealing with production runs. In other words when the edging inspection production run task occurs, an inventory transfer of the BOMs from the Edging dept to the Edging Inspection dept does not need to occur. Once the edging inspection production run task completes, the resultant product is ready to be stocked in and the inventory needs to be stored in the Inspection facility but it is automatically produced in the Edging facility because its the one assigned to the production run. Does this mean that the inspection dept would have to create an inventory transfer from in the Edging facility to their Edging Inspection facility or change the facilityId of the inventory item produced manually? Does it make sense to add a facilityId field to the stock-in options so that you can choose to stock the resultant product in a different facility than the one from which the BOMs were used? On 01/31/2014 01:49 PM, Christian Carlow wrote:I think production runs are sufficient for managing all of the information currently handled by the companies custom-built ticket system. The difficulty is in remodeling the ticket data as correct production run data in OFBiz. Basically each ticket could be the equivalent of either a production run or a task. For example, a ticket could be created to send parts from a dept to an inspection dept which determines if the pieces are ready for the next stage of manufacturing (next production run). If I'm understanding the Data Model correctly, production runs are created anytime a new product needs to be manufactured from BOMs in inventory. Because an inspection doesn't technically do anything that changes the manufacturing state of the product it seems those tickets should be created as tasks rather than production runs (routes). Other tickets such as parts moving from the Edging dept to the Coating Dept would constitute separate production runs because the Coating production run requires the Edging WIP to be created from its corresponding production run finishing to produce the required BOM to create the Coating product linked to its route template. The ticket system depts also seem to require remodeling. Separate sub-facilities (WAREHOUSEs) were created for each room within the building (parent-facility) that may contain inventory. Some ticket represent movements to depts that actually constitute inventory transfers to different facilities while other do not. For example, a ticket that moves pieces from the Edging dept to the Edging Inspection dept would be modeled as production run with two tasks (edging and inspection). But the ticket wouldn't constitute an inventory transfer if the edging inspection is done by the same worker who edged because it doesn't leave the facility. If the edging inspection production run task is to be performed by an external inspection dept however, then it seems an inventory transfer would be necessary. If this is the correct way to model the data then difficulties lie in the cases where production run tasks are supposed be performed by different facilities other than the one for which the production run was created. Take the previous example where a ticket is moved from Edging to Edging Inspection where the Edging task is performed in Edging dept (facility) for which the production run to create the edge-manufactured part was created while the Edging Inspection task is to be performed by a separate facility. In this case, when the inspection dept completes the final task of the production run, the inventory of the resultant Edging manufactured product would go in the Edging facility but it seems they need to be stocked in the inspection facility since its the dept that actually contains the edge-manufactured part that will be converted into its next stage for manufacturing. On 01/15/2014 02:44 PM, Ted Byers wrote:On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow < christian.car...@gmail.com> wrote: One important part I'll have to work out is how to handle theinspection department mentioned in the previous post. I think inspections can be handled as separate production runs just like normal ticket movements. The main difference between the inspection and manufacturing dept tickets is that inspection dept has the ability to split a manufacturing ticket into different quantities destined for different locations. I think this can be handled with the WorkEffortAssoc entity. Inspection users currently select ticketIds from a list to be inspected. I guess the ticketIds in this case would be served by workEffortId of the previous production run. This would have to be flexible, as different manufacturers will havedifferent protocols. My father worked all his life in quality control, just down the hall from the engineer's labs responsible for designing new products. For any given product, there were sometimes multiple protocols, all of which would be used for a given assembly line. Each would be used on a random sample of the products coming off the line, and in some of their facilities, there'd be an extra protocol applied to every unit coming off the line. One protocol involved something like function or integration tests. Depending on the facility, and how paranoid about quality the facility's manger was, this would either be applied to a large random sample, or to all, of the units coming off the line. A second, including tests of each component in the unit in addition to the tests in the first protocol, would be applied to a much smaller, but independent, random sample. Please note, a sample generally had a minimum size of 100 units. In the most recent configuration of that company's QA infrastructure, the assembly lines was not started for a batch of less than 100,000 units, and they actually had a computer on the end of the assembly line which performed all the required tests. That is to say, every unit coming off those assembly lines was subjected to at least one suite of tests. And there were other protocols also, but I was too young at the time to remember much else. But I do know my father would say that the QA testing was not a separate process from the manufacturing process, but an integral part of it. On the other hand, my brother worked in a company that had it's own machine shop, and that shop would have to gear up to make a single unit (which of course would be tested thoroughly), because it was needed to permit another department in the same company repair an insanely expensive piece of equipment, the parts of which had not been made in decades. These techs had the product specs on file, and so, using modern equipment, made 'obsolete' parts to spec, so that the supported old pieces of equipment could have a few extra years of life; and they had to do it to perfection since a failure could cost lives. I would expect that there would be seemingly countless variants between these two extremes. I suppose, the question becomes how best to model QA in such a way that it supports the many varied QA protocols that may be encountered. Is the production run adequate, or can you derived from it something more flexible? I have not studied the code you're working with, or the books to which you referred, but from the perspective of an end user, in the place of either my father or brother, I would look for something that was flexible enough to support either of the cases I described above. Let me ask you, do you think what you have in mind is flexible enough to handle such edge cases, and if so, how? Cheers Ted
