Wiki source for ManufacturingDiscussion


Show raw source

====Manufacturing Discussion====

The manufacturing functionality now coded as of v 3.06 is based on the specifications and discussions here

====Background====

Manufacturing businesses vary considerably from each other. The Toyota Production System epitomises best practise manufacturing with its lean principles. Fundamentally it requires that everything is done to ensure that setups are as fast as possible which in turn allows for shorter runs so that some of everything can be made every day. There are several mantras expoused perhaps the strongest is "waste elimination" where there are several defined types of waste (one of which is inventory). The "lean" principles extend into other aspects of the business aside from just manufacturing - it amounts to a culture of process re-engineering (Kaizen activities) to reduce the work involved from receiving an order from a customer to having the goods arrive at the location required by the customer. Indeed the proponents of lean see the ramifications of the principles extending through the supply chain as efficiencies are sought to remove all the waste involved in converting raw materials to products consumed with the least possible processing along the way - not least of which is freight back and to between different refineries and assemblers. As more manufacturing businesses pick up on the benefits of "lean" (and not just manufacturing), it is appropriate to consider the software requirements for the "lean" orgnisation.

Traditionally, manufacturing was split between:
* Make "to stock" - these businesses were predominantly wholesalers who had un-even demand for their products. They stocked commodity products that other suppliers also sold and a stock out would be a lost sale. The expectations of customers are such that the product is required for immediate delivery and failure to do so would result is lost business for the manufacturer
* Make "to order" - these businesses make a product which is perhaps less of a commodity and has perhaps some unique features that mean it is able to retain the order even though delivery might be a few days away. With the advent of lean the ideal is for a manufacturer to receive its orders and at a certain time collate these orders into the days manufacturing, the turnaround of manufacturing being reduced to the point where the delivery can be effected the same day. the ability of the organisation to acheive a rapid turnaround of manufacturing also determines whether they are a make to stock or make to order manufacturer.

Obviously making to order is by far the most preferable from the standpoint of "return on capital employed", inventory holdings and cashflow. The working capital of the business is not held up for long periods in inventory it is converted from raw material inventory to accounts receiveable as quickly as possible and round again to cash. Make to stock is often a replenishment exercise based on the days or weeks sales and with the advent of lean, more businesses are making based on what they sell as closely as possible. Whether that be making for sale or making for replenishment of sales.

To offer the maximum flexibility to a manufacturer the ability to build a bill of material based on a customer order or at the time of the customer order is ideal in many environments. However, in a commodity based business it would be inappropriate to define the ratios of yeast, flour, salt etc for a loaf of white toast sliced bread at the time the supermarket places the order.

====1.0 workOrder.php====

This is the main workorder maintenance screen and allows creation of new work orders and modification
of existing workorders. Once components of a workorder are "issued" the work order is
frozen and can no longer be modified (phil - well the due dates could be modified and the quantity to be made can be modified to a quantity more than has already been made - it can't be deleted though)

A work order represents an order on production to make a quant]]ity of a manufactured item.
If the item is flagged as controlled the completion of the work order will create a new lot
number to populate with the manufactured item.

====1.1 Create a new work order====

* entry of a required by date, an item code, and quantity required (xlyz not sure what you wanted
when you said "please allow date and shift")
* The location where it is to be made - foreign key to stock locations
* Location of where finsihed stock is to be received
* The Storage Bin at the above location where the finished items will be stored (i.e. tank1, tank 2, warehouse location 3). (phil - well this would be good if we have warehouse management but we don't)
* Works order number to be a sysType transaction number auto generated

Once the work order is entered it is automatically released to production and the date stamped as the ReleasedDate - notice that this structure is already there in the DB.

An automatic backflush flag is also on the work order

Creating a work order and releasing it recalulates the cost of the manufactured item based on the sum of the BOM components at the time the work order is created/released and the StockMaster Standard cost fields are updated for the item being made. GL entries created for stock revaluation - as per stock cost update script.

(Phil - we could do with a script that performs a cost roll up - as described above - to update standard costs of parents based on the accumulated latest standard costs of the children parts from the BOM - the code in the create/release work order could be included from this script. The cost roll up should allow entry of a single stock code and runable from the SelectProduct.php if the item is manufactured, and it should also allow selection of a stock category and go through all manufactured items in the category to perform the cost roll up on them)

<Kitch>
The current spec assumes that one or more items will be used to produce a single stock item. I need a system that can also do the inverse. That is, a single item, when run through a process, produces a set of stock items. As the quantities output may not be known at the start of the production run, the system needs to allow for manual input of produced quantities. This is a critical requirement for sorting/grading processes. The creation of lot/batch numbers is needed as is (optional) serialisation of the output items.
-- SteveKitchen (2005-03-06 20:54:53)

<Phil> OK. Lets consider the potatoe sorting example - where a load of unsorted potatoes turn up on a truck and are sorted into grade 1, grade 2, grade 3 etc depending on size and quality. One way we could handle this in a nice generic way might be to allow other outputs than the primary output. Whilst we make the work order up expecting just one output - we could allow other outputs too. ie we just make up a work order for grade1 potatoes and allow grade 2 and grade 3 to be received against the same work order as by products. Perhaps we could pre-define those items that could be output by the wo. This would require a workorderoutputs table

CREATE TABLE (workorderoutputs){
workorderno (references workorders wono)
stockid (references stockmaster stockid)
quantity
PRIMARY KEY (workorderno,stockid)
}

The work order could be considered as a cost bucket - we issue or tip in to the bucket materials and labour and then tip out of the bucket processed product. What is left in the bucket is either WIP or cost variances.

In this example we issue unsorted truck load of tatties .... we issue to labour to it and some machine time - we receive out of it 300kg of grade1 tatties - perhaps a controlled item - which requires a Lot number/reference, 200kg of grade2 tatties another LOT controlled item and 150kg of grade 3 tatties - not lot controlled. Say there is 700kg in a truck load - and raw tatties cost $1 per kg. The standard cost of grade1 tatties is 1.20 and the standard cost of grade 2 tatties is $1.1 and grade 3 $1.

The cost of the inputs is 700 x $1 = $700 for the tatties + 30 mins labour @ $1 minuite = $730
The cost of the outputs is:

300kg x grade1 @ $1.2 = 360
200kg x grade 2 @ $1.1 = 220
150kg og grade 3 @ $1.0 = 150

Total output weight = 650kgs less total raw tatties 700kg , waste =50kg
Total cost is $730 for the inputs - the cost of good product @ standard cost = $730 so there is no variance reported. If the waste had been more than the allowed % then a variance would be reported.

The bill of material for grade1 potatoes being 1.18 unsorted potatoes and 0.02 minutes = $1.18 + (0.02 * 1) =$1.20

Would this work Kitch?
</Phil>

====1.5 We need a pdf work order report====

Needs an option to list the components at this level for the item being made. Perhaps some format that allows for quality checks. We may consider recording standard instructions by item that are printed on this work order. Quantites produced should be entered on this work order report perhaps as the input document for 4.0 work order receipts.

====2.0 The stock status script needs modification to show demand====

including the sum the quantity of BOM components demand extended by the quantity of WO yet to be received - the work order records for work orders not closed, (WorkOrder.UnitsRequired - WorkOrder.UnitsRecd) * BOM.Quantity BOM.Parent=WorkOrder.StockID WHERE BOM.Component = $StockID over and above sales order details demand.

There is a start on the work order script in the CVS.

====3.0 WorkOrderIssues.php====

This script will allow quantities of stock items and lot/serial number to be entered against work orders. It should be possible to issue alternative items to the work order than are actually on the BOM (perhaps a flag in the work order to allow items not in the BOM to be issued or not). WO Issues need to be a transaction type defined in sysTypes and auto numbered as other transactions using GetTransNo($TransType) from SQLCommonFunctions.php. An issue of componentry to work orders will require a work order - that is currently open - to be selected, the component code to be issued, the stock location where it is issued from and the work centre where the component was issued to and how many were issued to the work order. The standard cost of the item issued will be recorded against the stockMoves table. If the component being issued to the WO is a controlled item we need to get into batch/serial no entry. If warehouse management is active at the location where the item issued from we need to get into recording the Bay where the component came from. (No warehouse management) (Phil - I dont think we need a WorkOrderIssues table - the info we need is in the stock movement record.)

Create the stockMove or serialStockMove record referenced to the WO # and the standard cost.

GL Entries need to Debit WIP - from the stock category record of the item being made (ie the WO item) and Credit Stock from the same stock category record.

Accumulate the value of components issued to the work order (at standard cost at the date of the issue) in the WO record under the AccumValueIssued field.

====3.0 WorkOrderReceipts.php====

This script will allow quantities of the finished item to be entered as received against a work order - into a specified location (and Bay/Bin - no warehouse management). There needs to be a WO Receipt transaction in sysTypes - autonumbered in usual fashion (GetTransNo()). If the item is controlled - allow entry of serial numbers/ lot references, the lot reference should be the same as the WO# - if there is warehouse management at the location being received into then we are into selection of the Bay(s) entry of quantities.

Create StockMoves records referencing the WO# for the total quantity and StockSerialMoves if necessary. These will show up in the stock movement inquiries on the date received.

GL Entries Debit stock at the current standard cost of the WO item being made, and credit the WIP of the stock category record of the WO item being made at the standard cost recorded in the WO table. Also, check for any difference between current cost and cost as stored in WO master and take difference x quantity received to the price variance account in the stock category record of the item being made - as stock cost update script.

Accumulate the value of the item received at the cost in the WO record against the WO AccumValueTrfd
record the quantity received against the WO record.

If the WO has the auto issue components flag checked then components required to make the quantity being received will be issued using the same logic as Script 2 - sounds like some include file is requried for the processing after passing a component stock item, quantity and WO number. This processing cant really take place if there is warehouse management or controlled components being issued - thats why the auto-issue flag cannot be set if there are controlled components.

====4.0 - WOInquiry_Close.php====

Takes a wo number and shows:

* the WO header - how many, released date, required date, item description, standard cost.
* the WO issues to the work order - all components issued - date issued, quantity, std cost and cost extended by quantity.
* the WO Receipts, dates received, quantites, total value received extended by WO standard cost
* the cost left in the work order being the total value of issues less the value of WO receipts as above - ideally this should be 0 if the BOM was correct and materials issued as per the BOM for the quantity made. This balance is of course is the material usage variance of the work order away from the standard cost.

With appropriate secuirty of the user this form should allow the work order to be closed - this flags the WO as closed -does GL entry to take this cost difference above out of WIP to the stock category material usage variance account. The quantity required is changed to the quantity received.

====5.0 - SelectWorkOrder.php====

Allows selection based on item code, open, closed, number, release date, required by - links back to WOInquiry_Close.php to Inquire/Close and to WorkOrder.php to allow modification of quantity required or date required by - WorkOrder.php will not allow release again if already released.


I currently have a WORequirements table and a WOIssues table I cant think why I needed them in the previous system - the information is available from the BOM in the case of requirments and the stockmoves table in the case of issues. I guess the BOM could change in which case the requirments at the time of the WO being issued would not reflect the same standard cost as it would after a BOM change. Do we need this ... nah!
Valid XHTML :: Valid CSS: :: Powered by WikkaWikiGet webERP Accounting & Business Management at SourceForge.net. Fast, secure and Free Open Source software downloads