Unless someone suggests otherwise, I'm going with the WIP method. Every
inventory move ticket in the company's existing ERP will be handled by a
production run. I'm probably going to design a custom UI that looks the
same to the users but behaves differently in the background by
automatically creating manufacturing data necessary to account for the
move. The custom UI will probably include a DeptTo field that will be
used to automatically create new WIP considered to be in the
manufacturing stage of the dept chosen. Then the newly created WIP
product will be used to automatically create parent BOM a relationship
to the previous WIP. I suppose Routings and Routing Tasks would also
need to be automatically created using the auto-created WIPs.
One important part I'll have to work out is how to handle the inspection
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.
On 01/15/2014 12:31 PM, Christian Carlow wrote:
Thanks Anil,
I looked over the book again and think I grasp the concept of how the
manufacturing app is supposed to work. In the existing ERP, employees
are somewhat creating production runs and facility/location inventory
transfers/stock moves at the same time when they are creating
tickets. When an employee creates a ticket to move a part to a
different dept, technically they could be considered to be creating a
new WIP from the previous WIP which could be considered a production
run in OFBiz. However, the company ticket system resembles the
facility inventory transfer and location stock moves applications much
more than the production run app. In other cases, such as when the
assembly dept creates a ticket, a product is created from components
which is clearly a production run.
Another part of the ticket system is the inspection functionality.
All tickets are inspected before moving on to their next location and
are actually sent to inspection depts before moving on to their next
manufacturing dept. Three inspection depts are considered to be in
the same dept as the one that manufactured the part and in these cases
the same employee is the manufacturer and inspector of the ticket.
One inspection dept is external from the manufacturing dept and so the
inspectors are different from the manufacturing employees. The
inspection depts are never considered to be creating new tickets but
inspecting existing ones to approve them to move to their next
intended manufacturing dept.
Ultimately the company just needs to be able to generate a report that
indicates how much of each product row is in each dept column. If I
were to use the WIP method then having something like a dept
identifier field in the product entity might be necessary in order for
the company WIP dept inventory/manufacuring stage report to be
generated correctly.
The only alternative to using the WIP method I can think of is storing
facilities as depts or locations and using the inventory transfer or
stock moves app to track how many pieces of products are stored in
depts. Because of the assembly dept (and other stages requiring
production runs), the company is going to require production runs
regardless of whether the use the WIP method or not. Because of this,
it seems that depts would need to be stored as facilities because a
facilityId must be specified when production runs are created, which I
assume is from where the raw materials to produce the finished good
are supposed to be used, and a production run might mistakenly take
the materials from the wrong dept if they are stored as locations.
Storing depts as facilities seems to have its own set of problems
dealing with inventory. If depts were stored as facilities then I
guess they would be stored as children of the parent facility
containing them? Does OFBiz know how to calculate inventory of parent
facilities based on child facilities?
The WIP progress method seems like the easiest and best way to replace
the existing functionality.
Anyone agree with WIP method or have other ideas?
On 01/15/2014 10:39 AM, Anil Patel wrote:
Sounds like your requirements can be best served by Ofbiz
Manufacturing application. You may reference “Getting Started with
Apache OFBiz Manufacturing and MRP” by Sharan Foga. It will get you
started.
Thanks and Regards
Anil Patel
Hotwax Media Inc
http://www.hotwaxmedia.com/
ApacheCon US 2013 Gold Sponsor
http://na.apachecon.com/sponsors/
On Jan 15, 2014, at 9:21 AM, Christian Carlow
<[email protected]> wrote:
The company manufactures raw pieces of glass into high precision
lenses according to specification drawing and currently uses what it
calls a "Ticket System" to track the manufacturing stage of the
glass its manufacturing. Each ticket has a productId, deptFrom,
deptTo, operatorId, and ticketDate. There is also the ability for a
ticket to be inspected either by the initial operator or one within
the inspection department. There is also a reason code for the move
as well as a comments field. The company generates a
Work-In-Process report that lists the number of pieces for each
product row for each dept column.
Workers are able to determine the manufacturing progress of parts
based on the dept they are located.
The company also generated "Percentage Good" reports based on the
tickets for each employee (operator of the ticket). When a part is
to be scrapped the operator moves it to a scrap location with a
reason code that indicates its scrap which is used to determine how
many bad pieces were caused by an operator.
Anyone have any ideas about getting OFBiz to support this system?
