Am Mittwoch, 29. Juni 2011 schrieb Albert Cervera i Areny: > IMHO BoM should be considered as a way to help the user fill in production > orders but it should not be required. There are lots of companies that > produce things but they do not have a bill of materials. Sometimes because > they simply don't know the materials that they will use in the production > when it is started. I think it's important to keep that in mind when > designing production functionalities because this probably means that the > most important aspect is the production itself and product traceability.
+1 A material may have a BOM, but this should not be a requirement. The BOM items itself may consist of physical materials ( with or without stock), text positions or dummy materials (dummies are mostly used to group additional materials, which may not be known at start. Once the BOM gets exploded in the production order (PO), the dummy material is expanded and its content is included in the PO.) Before a production order is created, there might be even an MRP to determine requirements (with or without capacity/avialability check, optional distinction between Master production (for lead products) and non MPS- materials). Do we consider planned scrap? Mostly a production order is the result of an MRP calculation. There might be a step in between - depends on if you have to take a make-or -buy decision . On existing Production Orders, the MRP should create depending requirements by exploding the BOM, and create Orders of purchase requisitions for the components as well. Scheduling of PO is a chapter for itself. Automatich scheduling based on requirements dats and with a graphical planning table would be optimal, but a big effort to realize.. After the material was produced, a goods receipt from production into stock has to be posted (good stock, maybe quality inspection). Component materials (the ones from the BOM) may be automatically backflushed, to avoid each single material to be touched/taken from stock. > This would be the model used for traceability functionalities too. So if > you wanted to know "which lots have been used to create lot X". The > traceability "system" would return the moves/lots consumed in the > appropriate "Production Moves". So if a single production order was > executed in several steps (ie has several production moves) we could know > which of those steps created the lot. This can be important for companies > in which production orders can take weeks to complete. Any information > regarding production planning should probably go to this model instead of > (or apart from) the higher level production order itself. Traceability is a very good point, but usually requies batch management , which blows up the complexity dramatically. So far my 2c Ax -- Dr.-Ing. Axel K. Braun Mobile: +49.173.7003.154 VoIP/Skype: axxite PGP Fingerprint: CB03 964D 1CFA E87B AA63 53F3 1BD6 F53A EB48 EF22 Public Key available at http://www.axxite.com/[email protected] This mail was *not scanned* before sending. It was sent from a secure Linux desktop. -- [email protected] mailing list
