Manufacturing - simply the combination of items to make other items can be implemented effective from KwaMoja version 3.06.
It has been possible to build bills of material for manufactured items for some time but the functionality that allows the materials to be issued from stock and manufactured items received into stock was introduced with 3.06. This is the purpose of the work order.
Functionality to add labour items to work orders and post recovery amounts to a profit and loss account for issues of labour to a work order was added after 3.09 (Sept 2008).Functionality to set up a master production schedule and explode bills of materials into the components required to manufacture this demand and calculate the required orders to be placed/rescheduled (MRP) was added by Mark Yeager in March 2009.
Bills of material now allow components to be defined as "auto-issue". Components set up to auto-issue, automatically create the issue transactions against the work order based on the bill of material quantities on the entry of receipts of a finished item against the work order. This decreases the administration of work orders for those components with relatively low value and limited possibility for any usage variance. It is not recommended that this feature be used on components where the final requirement for it could vary with for example yield differences between work orders. Work orders take the value of components and materials issued and divide this total cost between the output items to arrive at a cost per unit for all output items. The process for performing this calculation is called "closing" the work order.
Functionality to automatically create works orders for manufactured items at a default factory when a sales order is entered for which there is insufficient stock after all sales orders are delivered and outstanding works orders and purchase orders received. This functionality needs to be turned on as an option under configuration settings. The email address of the production manager who will receive an advice of the work order being created can also be defined in the configuration settings.
In dealing with serial or batch controlled items there are two ways that the system can operate. Either the serial numbers or batches must be created at the time the work order is created or they are entered at the time they are completed. If they are created at the time the work order is set up there is an option enter remarks about each lot or serial number about the manufacture or quality check data. To have serial numbers (or batches) defined at the work order entry stage this needs to be set in the configuration settings.
The sequence of events in manufacturing an item is as follows:
When the "Create GL entries for stock transactions (at standard cost)" option in the company preferences form is set to "Yes", then GL journals are created as a result of work order transactions. When a work order is created there is no GL impact. The ways the GL is impacted as a result of manufacturing processes are as follows:
| Event | Debit | Credit |
|---|---|---|
| Components issued to the work order | WIP a/ct from stock category of manufactured item | Stock account from the category of the component item |
| Labour issued to the work order (identical to any other component except that labour type categories have profit and loss accounts for their stock account) | WIP a/ct from stock category of manufactured item | Labour recovery account from category of the labour type item |
| A completed manufactured item is received against the work order | stock account from the category of the manufactured item | WIP from the category of the manufactured item |
Work order closed and the difference between the WIP debits and credits from the above transactions is compared and the balance is either
|
WIP /
Usage variance |
WIP /
Usage variance OR stock |
The Work Order is the medium for issuing components/raw materials to. A running total of the costs issued to the work order is maintained. Work orders can be created that have any number of output items. Output items are restricted to only "manufactured" items as defined in the item entry form. The work order tracks the quantity of the output items received against the work order and checks that no more than the work order quantity originally set up, with an allowance including the over-receive proportion as defined for purchase orders, is received.
Setting up a work order is performed from the Manufacuting tab -> transaction entry -> Work Order Entry. The work order number is automatically maintained and defaulted for new work orders as is the start date defaulted to the date the work order was created. Other data required includes:
With the above information completed then the items to be manufactured on the work order need to be selected. Normally this should just be a single item but it is possible to have multiple outputs against a single work order which is useful for by-products or processes with several output products. There are search facilities in the work order entry screen - only items flagged as manufactured in the item definition screen (Stocks.php) will show for selection. For each item selected the quantity required defaults to the EOQ - (Economic Order Quantity) defined in the item definition (Stocks.php) screen. If no EOQ is defined for the item then the quantity defaults to 0 and must be entered manually. The quantity required can be over-ridden and changed at any stage. Things are a bit different if the configuration option to defined serial numbers and lots at the time of work order creation is set. The quantity on the work order is calculated based on the number of serial numbers created or the sum of the quantity required for each batches entered. It is not possible to create a duplicate of an existing batch or serial number for the same item. (It is possible to have the same serial number or batch for different items.)
The quantity received of the item is maintained automatically against the work order items. The balance of the work order yet to be manufactured and received shows as "on order" in the stock status inquiry. Similarly the quantity required of components as extended by the bill of material for work order items is shown as quantity demanded against component items stock status inquiries.
The selection of work orders allows the costing to be viewed. The work order costing shows all the issues of materials and components against the work order as compared against the bill of material requirments - as they were when the first reciept of manufactured stock was received against the work order. The variances on the work order in terms of the usage of components and the expected cost of materials/components issued to the work order are displayed. Closing the work order takes these variances and if general ledger integration to inventory is enabled then journals are created to write back the work in progress balance. Of course if there are several manufactured output items on the work order then the variances are apportioned between the items based on the quantity of the item received multipled by the expected cost as a proportion of the total expected cost of all items received on the work order. The detail of how the postings created depends on whether weighted average costing is used or standard costing.
Closing the work order also deletes any existing serial number/lots that were defined at the time the work order was entered (where this conifguration option is enabled) but the serial number has not been entered as received/finished.
It is one thing to plan for purchasing where the item being sold is the item to be purchased. Things get more complicated when the item being sold is manufactured - each of the components in the bill of material need to be available before the item being sold can be manufactured. Where the components in turn are also manufactured then the complexity compounds - this is the material requirements planning calculations are for.
The author of the MRP - Mark Yeager has also contributed a manual page for his scripts which is linked from the manual contents page. For the curious, here (in the developers own words) are the basic steps of the MRP calculations: First, create a levels table by examining the bom table and finding a level number for each part; for instance, a part with nothing under it in a bom structure is a level 0 part, a part with 7 levels of parts below it is level 7. Next, I create an mrpsupplies table and an mrprequirements table. Supplies are from the current quantity on hand, open purchase orders, and work orders. Requirements are from open sales orders, worequirements records for open work orders, parts below their reorder levels, and demands the users can enter in an mrpdemands table for sales forecasting. Then I read through the levels table, starting at the highest level, and net the supplies and requirements for every part. If there is not enough supply, an mrpplannedorder record is created, and, if that part has parts below it in the bom structure, a requirement record is created for those lower level parts based on the net requirement for the top level part times the quantity per assembly for the component, with a schedule date based on the lead time for the part.
The MRP system uses certain order modifiers to inflate the requirement quantity. The EOQ from stockmaster is used, together with the item shrinkage factor and pan size.
There are a few programs to use before running an MRP.
Each item that requires a shrinkage factor or pan size to be set up must be defined in the stock item maintenance form all items need to have an EOQ (Economic Order Quantity - the most efficient or required order quantity) set up.
Pansize : This modifier is sometimes called the order multiple. It allows you to create planned orders in even multiples. This is especially useful if you are required by your suppliers to place orders in specific lot sizes. It is also a useful modifier is you have established your own production run sizes. This modifier causes MRP to inflate the required order quantity to an even increment of the pansize value. As with all modifiers you do need to be careful with this modifier as its use could lead to excess inventories
From the Setup Menu - MRPCalendar.php creates a calendar of valid dates for manufacturing. That way if the system schedules a planned work order for a part for a Friday and a component has a lead time of 5 days, the system will schedule the component for the preceding Friday rather than the preceding Sunday. To create the calendar, you enter a starting and ending date range and can opt to exclude Saturdays, Sundays, or any other day of the week. After the original creation, individual days can be set to be valid or invalid manufacturing days.
It is important to remember that this is "infinite capacity" MRP - i.e. orders will be created based on the demand requirements without any constraints on the ability/capacity to manufacture the order... currently the system is only implemented to calculate and report orders required and further analysis is required to figure out how to manufacture the required orders.
From the Setup Menu the demand types need to be defined - by default KwaMoja sets up a single Forecast demand type - which should be adequete for many businesses without further additional demand types. However, the system has ability to add additional demand types (the script MRPDemandTypes.php maintains a table of user-defined types of demands; for instance, F for Forecast or S for sales or whatever the user wants to use.
There are two programs for users to enter the demands.
MRPDemands.php can be used to enter single demands at a time. There is also a List Selection button that will list all demands for a part, if a part is entered, or all demands for a demand type, if no part is entered; when the parts are displayed, there are buttons to Edit or Delete. The Delete Demand Type button deletes all of the particular demand that is selected.
MRPCreateDemands.php can be used to generate a Master Production Schedule. The user selects a demand type, stock category, inventory location, and then enters a date range for sales orders to include. The program will generate demands beginning from the Start Date For Distribution for the number of periods – either weeks or months – that the user selects. Parts can be excluded based on their total sales quantity or total sales dollar. A multiplier can be used to increase the quantity; an example from my company is that we wanted to forecast for a year and a half, so rather than look at the last year and a half sales, we looked at the most recent 6 months and multiplied that times 3. An example of the distribution is if in a certain sales period a part had a quantity of 15 and the Distribution Period was months and the Numbre of Periods was 6, the first three months of records would have a quantity of 3 each and the last 3 would have a quantity of two. Dates are calculated based on the manufacturing calendar.
MRP.php runs the MRP itself. It is a regenerative process that purges all of the old files and creates new ones. There is a selection to chose the location for inventory. Days Leeway can be entered, so purchase order and work order dates scheduled within the leeway of the calculated need date are considered valid; the system does not actually change the dates in the work orders or purchase orders, but there is a report of those orders that the MRP estimates should be changed. And there are check boxes to select if MRP Demands, eoq, pan size, and shrinkage factor should be used. The MRP runs pretty quickly. The system I am running it against is not as large as most long running systems, but, with about 3,000 parts, a few hundred open sales orders and purchase orders, a half a dozen demands for assemblies that go 7 levels deep and have close to a thousand parts, plus individual demands for a few hundred other parts, I run this on a 3 and a half year old iMac with 1 gig of memory and it takes less than a minute. I also tried it on my web host, which is in Chicago, while I’m in New Jersey about 30 miles west of New York, and it took less than 20 seconds.
The MRP doesn't change or create webERP purchase orders or work orders. I think it might be dangerous to do that automatically, without some sort of human oversight. In the 2.0 version, I might have some sort of screen that will bring up what I call MRP Planned Orders and allow users to generate purchase orders or work orders from them. Right now, there are several reports to show the results of the MRP. MRPReschedules.php shows those work orders and purchase orders that the system calculates should have their dates changed; if there is no requirement for the orders, a CANCEL message is displayed. MRPPlannedWorkOrders.php and MRPPlannedPurchaseOrders.php show orders that the MRP calculates should be created. The reports can be created showing every individual order needed and the source of its requirement, or the orders can be consolidated into weekly or monthly orders. MRPReport.php shows the supply and demand for individual parts. On the demand side, it shows the type of order that created the demand, the top level part for that demand, and the order number ��� in the case of user entered MRP demands, the order number is system generated. The supply side shows orders that make up the supply and in the case of Planned orders created by the MRP, it shows the type of demand the supply was planned to cover and the order number for that demand. Finally, there is MRPShortages.php that shows those parts that have a demand that is greater than the supply. The dollar total might be a little misleading because if there is a sales order for an assembly without enough supply to cover it, that will show up on the report, but so will all of the components that are needed to build the assembly. I haven���t quite decided if I should exclude the components or not.
A table of work centres is maintained. It contains the following fields: