I have had some thoughts on the MRS module overnight. My realisation is that with its current feature set it is really only applicable for fairly large scale manufacturing with a consistent range of products. I do not think it would be workable for small run manufacturing or custom builds - in this environment the standard Odoo auto stock management features via procurement orders should still be used. Odoo are thinking of enhancing it somewhat during V10's lifetime but not dramatically.

A couple of features I think should be added:

• Ability to select a finished product and the system will automatically load all associated componentry down to n levels. Then allow the user to enter the required quantity of the finished item and the system calculate shortfalls and raise PO's or SO's.

• Ability to save "sets" of products to be used in forecasting - the current method of manually adding and removing products would be unuseable if 100's of components were involved.

• Ability to do live forecasts based on current PO's, SO's and MO's.

• Ability to import forecasted quantities.

So on to day 2....

Machine/Equipment maintenance was the first topic covered. This module is an enhancement of the community module "IT assets" in V9. It now has specific features required for an MRP environment including:

- Machines can be categorised for viewing and grouping

- Maintenance teams assigned to a machine

- Maintenance requests of two types - Preventative and Corrective. Preventative requests are cyclical and can be triggered via a cron job (emails to responsible person/group would be easy to add). Corrective maintenance requests can be raised directly from the work order - this is the value that integration brings.

Maintenance requests can go through several user defined stages and the system keeps track of such KPI's as:

• "Mean time between failures" - (time between first and last maintenance request/(total requests -1))

• "Mean time to repair" - mean time between close date (stage done) and creation date

Unfortunately, there is only one maintenance request that can be assigned to a machine and even that does not have a description. In reality I think there may be several types of preventative maintenances at different intervals required on a particular machine - looks like we will have to do a custom mod for V10, which will then be replaced by Odoo version in V11!

There is no link to assets from a machine and no way to record maintenance costs. There is the possibility to use the repair module but this does not have a link to assets either. So this module adequately fills the operational needs of a maintenance department but falls short of a complete solution as there is no integration to the asset module and depreciation etc. Conceivably analytic accounts could be created to keep track of machine costs, however all this information should be directly available against a machine - I can feel a custom module coming on!

Lots and serial numbers are handled well but can inevitably complicate the workflow, e.g. if a single MO produces multiple finished products requiring a serial number and consumes components requiring lots then only one of the finished items can be created at a time at an individual work centre. The last sentence may need to be read twice and this in itself indicates that this workflow can potentially require multiple user interventions! A smart implementation of barcoding would make such a complex workflow feasible. Initially the system seems unintuitive as it requests finished product serial/lot numbers at each work centre, however this is a logical consequence of implementing complete traceability of products.

Also I learnt something interesting regarding lots & serial numbers: In V9 & V10 it is possible to set a picking type to enable or disable the entry of lots/serial numbers, even if the product being received is defined as requiring a lot/serial number. This makes it possible to receive products without a serial number but ship them with a serial number. In V8 this was possible via another mechanism however the shipped items with a serial number would create a negative quant which worked but was ugly and confusing. However in V9 & 10 a new quant is created at sending time and the original receiving lot (with associated blank serial numbers) is decremented - much better.

When it comes to product traceability, I have always been a little confused by the terminology "upstream" and "downstream". To remember the "upstream" direction the presenter (Jos) uses an image of a fish swimming upstream to its source - i.e. from the customer to the supplier, and visa-versa for "downstream" - I like this image and will use it in future.

Quick note: component attachments are now directly available on the BoM definition thus giving quick access to possible build instructions etc.

Units of measure are now available at the finish item level and on the components - so you can define a BoM for an item by say the Kilo rather than the gram - this is especially important for BoM's that have components that are infinitesimal if defined at the unit level (e.g. paint).

OK now for some bad news - BoM parameters are GONE in V10. You may not have used this feature at all but it allowed you to do fairly rudimentary product configuration whilst entering a Sales Order by entering parameters against a BoM component. The parameters are then prompted for when entering a Sales Order and only components with matching parameters are selected when generating the manufacturing BoM. This feature was used heavily in the OCA (Odoo Community Association) product configurator.

On the plus side a new feature has been added to variants where the generation of variants can be suppressed by setting a boolean flag on the attribute. However, the only implication is that the attributes are available for selection in the web shop and the resulting sales order has the user selections as part of the description. This feature could, with a bit of creative thinking, be used to replace the parameters that were used previously to create a configurator.

As in V9, variant attribute values can be placed against BoM components to select the correct variant to be used in a MO based on the product variant selected to be manufactured. However, this does not really give the same flexibility for configuring BoM's based on parameters.

I hope all the above makes sense. Possibly if you have not used parameters for product configuration before it may seem a little esoteric, but it will mean some rethinking of custom configurator models built using this feature.

There is now a complete log of all costs used in a manufacturing order and a nicely formatted report is created. The final cost of the manufactured item is then used to update the cost of stock as the product is completed using the costing method chosen on the product (standard, average or real). When I tested this it appeared to have a bug which Jos ensured me would be fixed quickly.

Another nice feature is the ability to create "Unbuild" orders that are like manufacturing orders in reverse and which therefore naturally include lot traceability etc.

I did not have time to test all the financial and accounting implications of moving components into WIP and finished goods out of WIP, but was assured this would all be OK. As with all things Odoo, it will require careful setup and testing using the input and output accounts specified on the virtual production location.

So what are my final thoughts on the new MRP modules? Broadly speaking they have done a good job on the operational aspects of MRP from planning and tracking orders and through the manufacturing workflow. The integration with quality control, PLM and machine maintenance is truly impressive. The Master Production Schedule is definitely a work in progress and I believe will require changes before being used in live production environments.

Full MRP II implementations are extremely time consuming. Getting software functionality to match physical stock movements and workflows requires careful analysis and testing. Any customer intending to do such a full implementation with Odoo will, I believe, need customisations to realise this goal. However, MRP implementations should not be done in a single project phase, but rather in several smaller and "easier" phases where the many advantages of Odoo MRP can be realised quickly. It is better to plan and extend an existing working and reliable implementation in small steps rather than do it all in one go.

--Jon Wilson 2016.10.05