Odoo 10: MRP Draft Spec

Introduction (done)
Workflow (done)
Master Data (done)
Picking Types (done)
Product Category
Bill of Materials (done)
Form view (done)
Why we remove valid from/valid until? (done)
Search View (done)
Remove properties (done)
Routings (done)
Operations in parallel in a routing (done)
Work Centers (done)
Introduction: Time Clocking (done)
Specifications: form view (done)
Specifications: Scheduling (done)
Specifications: KPIs (done)
Manufacturing Operations (done)
Manufacturing Orders (done)
Introduction: MO vs Work Orders (done)
MO: Bill of Material without routing (done)
MO: Bill of Material With Routing (done)
Scheduling (done)
State and Material availability (done)
Costing (done)
Unbuild (done)
Work Orders (done)
Work order: form view (done)
Work Order: Planning (done)
Work Order Kanban (done)
Work Order Gantt (done)
Work order: misc (done)
Work Orders Planning
Rework (done)
Procurements
Introduction

1/58
 Time-Phasing / Time Buckets (done)
The new scheduling algorithm will consider future demand, and create future
supply, based on small time periods. These small time periods are called
buckets. By default, the time buckets have size of one day. Using time-phasing,
we delay orders for components until the day they are needed.
Low-Level-Coding
Menus & Filter (done)
Form view (done)
Manual Routing
Product form (done)
Product Configurator & Variants
Product configurator
Buying Matrixes
Generic Grid View (done)
SO Related Matrix
Dashboards (Foreman)
Dashboard: floor plant
Work center control panel (done)
Sequence of Operations (done)
Work sheets / work instruction (done)
Scheduling (done)
Traceability (done)
Touchscreen (done)
Product Lifecycle Management (PLM) (done)
Extra fields for PLM (done)
Engineering Change Orders (done)
Communication (done)
Maintenance of Machines (done)
Introduction (done)
Equipment (done)
Maintenance (done)
Preventive maintenance (done)
Maintenance Request (done)
Menu (done)
Master Production Schedule (done)
Quality (done)
Introduction (done)
Scrap (done)
Quality Control (done)
Quality Control Objects (done)
Quality Alerts (done)
Objects (done)
Random notes to specify (done)
2/58
 Statistics Reports: SPC (done)
RMA (Return Merchandise Authorization)
Menus (done)
Configuration
Contract (purchase agreements) (done)
Blanket orders (done)
Technical Specification (done)
Split of Modules
Workflow
Business cases
PLM: Two different departments: engineering and production department
Indented BoMs and history
Being able to change the product in all BoMs because we don't want to use the
component anymore.
Corrective vs. preventive maintenance
MPS: MTO orders, but MTS raw materials

3/58
Introduction (done)
Most MRP software on the market are old, very complex and not efficient for the users.
Moreover, companies usually have to use different software to handle their MRP needs: MRP,
plm, maintenance, quality, ... Those are usually not part of the same software. With the Odoo
technology, we think we have a serious opportunity to disrupt the market.

The MRP module has two different modes / ways of working:

1. by manufacturing orders (bom without routing): for companies that just need a todo list
of manufacturing orders to process, ordered by expected date. There is no work centers
planning or resource assignation, but it's also easier as you only need to manage bill of
materials, not routing. (small companies that mostly do assembly and do not need to
assign tasks amongst different work centers)
2. by work orders (bom with routing): for companies that need to track and plan
operations over different work centers. In such a mode, workers work on a work center
(can be a machine or a person) and perform operations defined on the routing, linked to
the manufacturing order.

Some of the software we analysed:

Arena: quite good PLM. It has the feature we need and could be a reference for a PLM
implementation. We can get inspiration from Arena for the list of fields/features, but we
have to rethink the usability. As opposed to Arena, our PLM should be fully integrated
with the WMS/MRP modules. (example, after an ECO you decide what you do with old
products that you replaced in the BoM)
Frepple: Open Source Production Planning
Plex: Plexs usability is bad but their business features are good. Its one of the most
mrp oriented software we have seen.
QAD: a reference for APICS based manufacturing software
(http://www.qad.com/solutions/manufacturing)
Netsuite: quite bad, but one of the rare MRP solution in the cloud. So, it's worth having a
look at it.
Rootstock: I dont know it, but it looks good.
Aras (www.aras.com).
All community modules already developed on Odoo 8. Once the first draft of this
document is written, we plan to read all community modules to check if we did not miss
something important.
IBM Maximo: for the maintenance section only
To test: http://pinpointinfo.com/
OdooPLM already integrated in odoo, with cad capability, revision and workflow on
document and product (I will be at the workshop, with a live demo if needed) .
4/58
 Infor XA ERP which is installed worldwide to more than 2000 customers. This ERP is
designed mainly for manufacturing companies and is same generation as SAP (Year
80s) Others knowledges are based on European cost accounting (Costing) rules used
by many from our manufacturing customers.

Workflow (done)
A typical workflow:

Procurements (sales order in MTO, minimum stock rules, pull flows) create new
manufacturing orders that are directly confirmed by Odoo, but not planned (they are
ordered by scheduled date by the scheduler)
The manufacturing planner can plan those orders to assign tasks to the work centers. At
that time, work orders are created and their start/end date is computed based on work
center capacities and availabilities.
The worker can start working on a work center and process all work orders related to this
work center. He only sees work orders that are ready. When working on a work order, he
can mark products that are consumed or produced, do quality checks, see the work
sheet, etc.
Once the worker start a work order, this may mark the manufacturing order as In
progress. Once the worker finishes the latest work order of a MO, this will mark the
manufacturing order as done.

Departments and their main roles:

Engineering: bom, products

Manufacturing Engineering: routing, worksheet
Manufacturing: mo, work order, work center
Logistic: procurement

Roles:
Logistic/Manufacturing Managers: may validate procurement (and, thus, launch
manufacturing order or decide to buy/subcontract). Depending on the push/pull rule, it
can be automatic (default) or require a manual confirmation on the procurement.
Production Planner: he plays with manufacturing orders and work orders: planning and
material assignment. He can prioritize manufacturing orders to impact the work orders
planning, or the quantities to produce.
Workers: they only work on a specific work center, processing work orders as they
arrive.

Inventory:
5/58
 At every work order, we may consume products (or not), or produce products (finished
goods or by-products)
The latest work order produce every product that are not linked to an operation: finished
goods, by-products, and raw materials. (because these ones have already been
recorded)

6/58
Master Data (done)
Picking Types (done)
Currently, the picking types can be of 3 kinds: internal, incoming, outgoing. We will extend this
list to add a fourth one: Manufacturing Operation. It will be displayed in the kanban view of
picking types (stock dashboard) as well, and we will design a specific card for manufacturing
operations that will show MRP related information, shortcuts

That way, you can create different Manufacturing zones (by warehouse, company, etc) and you
can define specific routes attached to each picking types. (e.g. trigger a picking to prepare
products to manufacture)

Product Category

Note: not sure we need to implement this feature. (phase 2 or 3)

7/58
Add in the product category an integer field Time frame (days) which will be used for the
grouping of procurements into the same PO/MO. More info in section on procurements.

Bill of Materials (done)

Form view (done)

On the bill of material components, we can select a work operation, the one where raw
materials will be consumed. (a many2one). If nothing is set in this field, products are consumed
at the latest work operation. If some products are consumed in multiple work centers, we have
to deduplicate the line in the bill of material. Same features for finished products.

The idea is to relate components from the bill of materials to operations in the routing. Mainly
because raw materials and finished products are consumed/produced during work orders
operations (coming from the routing). The name of the field should be Consumed in Operation
Sequence # (not consumed in Work Center as shown in the above screenshot)

Add a selection field Ready to produce:

When all products are available
When the products of the first operation are available

8/58
Remove the fields:
Internal Reference: as a Reference field already exists
Sequence (keep this field in the tree view (drag_handle), but remove from the form view)
Remove the fields: valid from & valid until on the Bill of Material
Remove the fields: valid from & valid until on the BoM lines (*)

Replace the active checkbox by a Archive/Unarchive top button, on the top bar like in other
documents. (Add a filter on Archives)

Add a related button on the top that opens the tree view of the bill of material (including all
sub-levels of nested BoMs).

The following fields should not be in Technical Features: valid from, valid to, rounding,
efficiency, active (but its converted into a button in the topbar). They should always be visible in
the Miscellaneous tab.

By-Products should also be linked to routing operations, like bill of material components.

Log any change on the BoM (or BoM lines) in open chatter.

Add a field picking type (domain=[(type, =, manufacturing)]): when a procurement has a

produce route with a picking type set, it will try to create a Mo for that product using a BOM with
the same picking type (if there is no exception). That allows to define pull rules for products
with different routing (different BOMs)

Why we remove valid from/valid until? (done)

When you need to change a BoM, you rarely replace a component in a BoM at a specific date.
Usually, when you do an engineering change request, you have 3 options: exhausted (replace
the BoM when the deprecated products are consumed) or ASAP (when logistic/manufacturing
engineer are ready), or manually.

For each of these 3 options, we use a date (an estimate time of application). This date is just an
estimation to sync all the departments: manufacturing engineering should change the process
and worksheets, logistic should order new components, manufacturing should train the
worker This date is on the ECO (Engineering Change Order) and you can apply the new BoM
in one click from the ECO.

It never happens on a specific date at midnight as you can not take the risk to apply a BoM
change automatically if one of the department is not ready (what if manufacturing-engineer did
not had time to apply changes on the worksheet for the deadline? Or vendors did not ship the

9/58
raw materials on time). Sometimes a change apply on several BoMs/routing that can be done
on different dates --> the process takes 3 days.

Its also risky to manage changes using Valid from, valid until If some dates overlap, you
have two time the component in the BoM. Its also not clear for the readability of the BoM.

For these reasons, the ECO gives all information to update a BoM / routing / worksheets, But
the application of the ECO is always done manually (you just need to press a button) and never
automatically by the system (at a specific date).

In short, we have different BoMs that does the history. (when we want to make a change on a
BoM, we can duplicate the existing one and have another that is not in production yet). We have
an estimated date, but the application should be triggered manually to avoid blocking a line in
case of issues.

More over, keeping the history of a bom change within a bom is a bad practice (for readability),
its better to keep old BoMs as separate, deprecated, BoMs.

10/58
Search View (done)

Since the Bill of Material is created by the Engineering department and the routing is created by
the Manufacturing Engineering department. We will create a filter on Bill of Materials No
Routing. That way, the Manufacturing Engineering can easily check the bill of material to
complete.

Add a Archive filter to show archive BoMs

Add a search on the work center. (bill of material containing an operation using this workcenter)

Add a search on a component where used.

Remove properties (done)

Remove everything related to properties: properties, properties group, Indeed, the feature of
selecting the BoM directly from the SO can now be achieved by routes and picking type on
BoM, so the properties are redundant. (or variants)

Routings (done)

We plan to have two modes:

Easy: no routing & work order, only BoM and Manufacturing Orders
Advanced: a many2one on the BoM: routing_id allowing to share routing from one
product to another.

Routing operations have a sequence that define the order they can be launched. Sequence are
not in form view, but we use a widget=handle in tree view. Operations are always in series,
one after each other.

Operation Sequence Reference

Drill 1 OP/0006

Saw 2 OP/0007

Lathe 3 OP/0008

Assembly 4 OP/0009

11/58
In the above example:
You must start by the drill operation
Once the drill is started (even if its not finished!), you can start saw
Once saw is started (even if its not finished!), you can start Lathe
You can do the Assembly once Lathe is started

Its possible to have all work orders open in parallel. Use case: you have a bill of material of 100
PCEs and you work in a pull flow where you produce the pieces one by one. After having
produced the first finished product (going through the 4 steps), all the four work orders are in
progress.

Move the production location field on the bill of material, instead of the routing, since routing
are now integrated in BoM. This production location should be editable in the MO.

Operation should have a reference field with a unique sequence (can be used through the
barcode interface or to refer to a specific operation when talking to people).

Operations in parallel in a routing (done)

The design we choose is to have all operations in series in the routing, we do not support
operations in parallel. Another alternative would have been to create a graph of dependencies
between operations, but the usability would have been much more complex.

Lets suppose you have the following line, that has lots of operations in parallel: (pretty common
in the automotive industry)

In the above example, sub1-sub2 and sub3 are manufactured in parallel. To manage this in
Odoo, you will create 4 bill of materials (and, thus, 4 routing): one for the main assembly line,
and one for each sub-product. So, when you want to run operations in parallel, you just split into
sub-products.

Same for the example below, you will have 3 manufacturing orders, and 2 sub-products.

12/58
Another example could be a line that support operations that can be launched in any order:

In this example, with 5 operations, the routing can follow the red or the green path. The way to
organize this in Odoo is to define a default path (ex: red line). And force readiness on the work
order 3 if you want to follow the green line.

A routing line should have a clean name_get/name_search as we will have a many2one on

bom.line to routing_line object.
name_get: WORKCENTER/Operation Name
name_search: workcenter OR operation name OR reference

Work Centers (done)

Introduction: Time Clocking (done)

In most manufacturing industries, the manufacturing engineering team measures the time they
need to perform the operations (time study). These theoretical times on routing operations are
used to compare the actual performance with the expected one. We usually follow best
practices of the industry in our specifications, but this practice is very time consuming and not
very efficient. (there are always good reasons to be off-timing: process change, ). Its even a
bad practice as workers tend to produce slowly if the theoretical times are too high. (
Parkinsons law )

We think its easier and more efficient to report all actual times with a simple control panel on
the work center and report the performance based on average times and variances (standard
deviations). The statistical variances across all production is a better KPI than the distance
between theoretical times and real ones.

13/58
If you want to detect where you can improve the performance (speed loss, quality loss, or
machine break), the best KPI you have is the standard deviation. In other word: if you are able
to produce some pieces faster than others (or some slower than others), check why. The actual
comparison with theoretical times is less efficient and more time consuming.

Its also a huge effort during the implementation of the ERP since you have to report all
theoretical times on work centers (and most SMEs dont have this) If you base all your reporting
on actual time, you dont need this anymore. You get in real time the work centers where you
can improve (standard deviation is high) and the optimum target (the faster of all these
productions, which is more correct than one-time measured time).

This method also better adapts itself to process change.

As a summary, we still allow to set theoretical time on workcenters and routing operations. But
these are mostly used for the planning when we do not have enough sample to base scheduling
based on average times.

All times (setup & cycle) are measured. To analyse the efficiency, we report on the average and
the standard deviation (variance). As the user does not have to fill in times anymore, the
usability is much better. Moreover, the statistics on the performance is more accurate and better
adapt to process changes.

There is no setup time and time after production, just a fixed time (setup + post-production) and
variable time (per cycle). On the work center control panel, they can register their time, with
three (setup time, production time, clean-up time).

Of course, this approach only works if you are able to measure actual time on work orders. But
we think that, if you are not able to do it, reporting on average times during a day for a whole
manufacturing line does not give good enough insights to detect inefficiencies in your process.

Technically, it means that time fields on workcenters and routing operations are computed,
instead of being set manually. This makes the creation/definition of new work center super easy
as there are not a lot of fields to fill in.

But this actual time can be setup initially to some values, for example when you start a new
routing. (its not exactly a computed field) So, we still support time study, but just to kick off a
new routing or a change in an existing routing.

14/58
15/58
Specifications: form view (done)

If the computation is based on real time, we use the average time for one piece of the last X (10
in the above example) operations. If no work order have been done yet, Odoo will allow you to
set a default time for the first planning.

Rate

To reach a deep operation calculation detail we need to introduce cost line. To each WC we
need to fulfill annually estimated costs by cost line and we need to estimate the annual time
we plan to consume on WC. On cost line we need to share: direct cost who are the cost spend
into the WC himself (eg salary for employ) and indirect costs who are shared to many WC (eg
production manager salary). To calculate the rate: divide each cost line / annual time means we
have a cost rate x cost line.

For calculation of item operations we can have 1 amt x cost line. This help to know if company
cover the fixed expenses by dept who is the break point, who are the manufacturing cost into
each item and help manager to take decisions

Eg of WC / cost line
WC1000 = CNC engine, company plan to work 1000 x year
. direct cost
- cost line A (fix) = WC employee salary EUR 80000 x year
- cost line B (fix) = WC employee social cost EUR 30000 x year
16/58
 - cost line C (fix) = amortization cost EUR 30000 x year
- cost line D (var) = electricity, oil EUR 5000 x year
. indirect cost
- cost line M (fix) = management salary EUR 10000

WC1000 will have following rate for employees

- A = EUR 80.- (80000 / 1000 hours)
- B = EUR 30.- (30000 / 1000 hours)
- C = EUR 30.- (30000 / 1000 hours)
- D = EUR 5.- (5000 / 1000 hours)
- M = 10.- (10000 / 1000 hours)
- Total rate is EUR 155.-
For pre-calculation (master data) and post-calculation (MOs) we could have deep cost analysis.

WC1000 will have following rate for foreman / trimer

- single rate is enough, dont need to have so deep requirement
- this rate is used only to calculate setup

It is not good to eliminate time field after prod and cumulate it with setup because people who
are working on those times dont have same rate.

To reach the effective rate we need to have

- real costs for WC / cost lines who came from accounting (in manufacturing the costs
must be charged on WC/cost lines and on MOs routing)
- real consumed time (cumulated based on time job on/of)
- real rate x cost line (used by MOs costs follow-up)

Specifications: Scheduling (done)

Even if the time of the operations are computed, one should be able to set a time manually on a
work operation by changing the start or the end date. (for the use case when you dont have a
correct time yet, you want the planning to be correct).

The form view should have a button Reset Averages Time that sets the Average Reset Date to
today. This is used when the process changed, you should press this button to reset the
averages so that they directly adapt to the new process.

We should also add a function here that write this average times into theoretical ones,
particularly usable when we use Standard Costs reevaluated per month/quarter and so on. This
method should be callable from a list of work operations, or a routing.

17/58
Regarding scheduling there is another requirement to have good result: queue time. (time
before production and time after production, set on the work center) Before we can start an
operation, we have a queue from the previous MO. We need to have a fixed queue time that
help to schedule correctly operations. We need to have average queue time, corresponding to
the average of time between the previous operation start date and the real operation start date.
This average queue time help to analyze what we setup into standard queue time. Without
queue time on WC the operation scheduling will not consider the time to wait before start an
operation.

Set all time and duration in minutes, not in hours.

Specifications: KPIs (done)

Add the following computed fields:

OEE (Overall equipment efficiency) --> computed field (speed loss, downtime loss,
quality loss)
Speed loss: based on real time registered on WO
Quality Loss & Availability losses: based on blocking mechanism

Manufacturing Operations (done)

Manufacturing Orders (done)
Introduction: MO vs Work Orders (done)

So, depending if the bill of material has a routing or not, you must:
plan work orders, produce on work orders (if routing)
produce directly (if not routing)

MO: Bill of Material without routing (done)

If the bill of material has no routing, you can produce from the manufacturing order, a button
Produce is visible, once you click on it:
it does all the operations, according to the quantity set on the manufacturing order:
consume all goods, produce finished products and by-products, close the manufacturing
order.
18/58
 If the finished products is managed by lots:
A wizard opens asking for a lot number (finished products), then lots numbers of
raw material related to this finished product,
Then, next finished product, etc.

The quantity on the manufacturing order can be changed before launching the Produce button.
So, you can produce a different value than what is requested by the system. But the raw
materials are always a direct relation of the quantity produced (according to the BoM).

Manufacture required more and more to produce partially (eg: MO original qty = 1000 ; each
time we produce 80 to 120 pieces then we have to update finished qty and consume
components. We should have the possibility to produce many time partial quantities.

So, we only keep two one2many fields on the manufacturing orders:

Products to Consume (label changes into Consumed products once done)
Products to Produce (label changes into Produced Products once done)

Remove the following fields:

Produced Products (add a related button)
Consumed Products (add a related button)
Scheduled Products

Remove the Produce wizard. We always produce the quantity set in the manufacturing order.
(but this quantity can be changed in the form before launching the production).

MO: Bill of Material With Routing (done)

If the related bill of material has a routing, the main operation is to first plan Work Orders, then
process all the work orders, instead of using the Produce button.

Cfr section on work orders for more information.

Scheduling (done)

Manufacturing Order states are: confirmed planned in progress done

confirmed: a MO to be done (generated by Odoo or created manually, different than in
v9) -> create WO in draft
planned: WO have been planned
in progress: first WO is started
done: MO is marked as done (usualy, when all WO are completed, but not necessarily)

19/58
The logic is the following:
All MO are created in draft, their expected date is computed by the scheduler and it
defines their priority. (the v9 algorithm is good for that, nothing to change)
A user (the planner) can plan MOs, one by one (draft planned). The button will create
related work orders update state to planned. The start date of work orders are
computed in a ASAP algorithm starting of today based on work center
availabilities (without using the date on the MO) Thus, the order in which the planner
plan MOs is important for the scheduling. If he validates a whole list of MOs at once
(from list view), Odoo will plan them based on their priorities (thus, expected date)

Manufacturing orders have an expected date (that is usually not updated, its computed by the
scheduler, based on customer expectations. The current algorithm is good for that).

The scheduled start/end date on MO are computed automatically based on the min start/max
end of work orders. These are computed field with an invert method. If you change the start
date on a MO, all work orders are recomputed accordingly.

Manufacturing orders have the following fields (the version 9 state field is splitted in two
concepts):
State: Draft, Planned, In Progress, Done, Cancelled. (no more confirmed,
confirmed=draft)
Inventory Availability: Fully Available, Not Available, Partially Available (enough to start)
computed field depending on the availability on the WO.

Remove the workflow. The workflow can be removed, to the benefit of more flexible transitions.

The transition In Progress Done is set manually, or proposed by the system when the latest
WO is finished for the full quantity. (its a proposition requiring a manual action, never
automated)

The priority between manufacturing orders is defined by the tuple priority, expected date. By
default, all manufacturing orders have the same priority, but you can start reorganizing them in
kanban to change priorities.

We should have three dates on manufacturing order: expected date, start date, end date. The
expected end date is computed by the scheduler and never changed. (it could come from the
promised date to the customer so it serves as a reference) The planner changes the start date if
he wants to reprioritize: its a computed field (coming from WO) with an invert method. (gantt or
calendar) The expected date should usually not be changed (you can change it if you changed
the promised date to customer).

The end date is only set when the MO is closed or is computed based on the latest work order.
(its an actual date, not a scheduled)
20/58
The start date is initially scheduler. Once the MO actually started, we set the actual start date in
the MO and this date should be readonly. Same for end date, its set when the manufacturing
order is closed.

A procurement can either:

create a draft manufacturing order
add quantities to an existing manufacturing order, only if:
procurement.group matches
manufacturing order is in draft
same uom, same product.

So, manual scheduling can be done:

- on MO priority (or expected date, but thats not recommended), before planning the
manufacturing orders (and they will be planned according to priorities) or after planning if
you launch the reschedule wizard. Thus, MO are mostly managed in tree view (or in
kanban grouped by priority)
- on WO operations (only open operations ; if operation is late the reference date is the
scheduling date) Thus, the main view is a Gantt view on WO

A reschedule menu will recompute all WO based on work center availabilities, starting of today,
keeping the priority of the MO.

State and Material availability (done)

The planner can force availability on the work order to Fully Available (like a Force Reservation
on a delivery order). Sometimes you want to start a manufacturing order even if all the raw
materials are not available (they will arrive during the MO process).

The manufacturing order state draft, to do,in progress, done should be orthogonal to the
material availability state:
not available
partially available (first work order)
fully available (all operations)

Material availability check should be made also for work orders. Check availability button should
be present in MOs. It should also be present even if MO has been started or not.

21/58
Costing (done)

Take into account:

Cost of products (raw materials): avg (product form), standard (product form), or real
(cost of quants used)
Cost of time spent (setup, production, clean-up), with cost of the work orders (this
includes the cost of the machine, tools and human resources)
Cost of scrapped products

Real / Theoretical:
Average or real price: use the real costs from manufacturing order with operations to
compute the batch cost
Standard price: can use theoretical values from bill of material and routing to periodically
(once we click on a button) recompute the standard cost.

Unbuild (done)

We need a tool to unbuild a finished product (disassembly). In Odoo 8, we were using negative
manufacturing to do that, but its a bad usability and its not correct: its not normal to follow the
same routing, lots should be reused, ...

We will create a real unbuild document for this operation.

Since the unbuild process is only used in assembly operations (not cutting operations as an
example) or discrete manufacturing (not in continuous manufacturing), the unbuild document
only works for one piece.

The fields:
Product_id, required
bom_id, required (domain: product_id = product_id)
mo_id
Lot number: may be the lot number of the finished product OR one of his components
(so, no domain on lot_id depending on product_id), not required
state: to do done
Destination Location ID: many2one(stock.location)

22/58
Work Orders (done)
Work order: form view (done)

Add the following fields

User: many2one user, required, default to uid
Employee: many2one, not required
Production Qty: 3 PCEs (not need for the UoM, it has to be the UoM of the MO)
Lot_IDS: one2many (for both consumed and produced products)
product_id
lot_id
consume_move_ids: one2many: stock.move
produce_move_ids: one2many: stock.move
Logs: one2many:
Start Date
End Date
Selection:
Setup Time
Production Time
Failure: many2one(failure types)
Duration: computed field, store=True, sum of logs(setup + production time)
Efficiency: 90% (if a 9 minutes time operation has been done in 10 minutes). This field is
set when the work center operation is finished
state:
Draft
To Schedule
Scheduled
In Progress
Done
Inventory: Fully Available, Not Available, Partially Available (computed field)
kanban_state: computed field based on current log
in progress
not active
failure

Work Order: Planning (done)

Work Order Kanban (done)

23/58
When coming from a work center:
Group by Date (day) reschedule with D&D
Filter on WorkCenter
Color: of the BoM

When coming from a Manufacturing Order:

Group by Date (day) reschedule with D&D
Filter on MO
Color: of the Work Center

Kanban Cards:
Height of Kanban Cards: estimated hours

Work Order Gantt (done)

When coming from the global menu: (but this view should also be defined on the action when
coming from a workcenter or MO)
Group Level 1: Work center, then work order
Red if capacity > capacity of the workcenter
Color: BoM

24/58
Work order: misc (done)

Remove workflow.

Work Orders Planning

We need a recompute button in the work order planning that recompute all start/end date to
satisfy the capacity and precedence constraints, of work orders that are in the To Schedule
state. When scheduled by the scheduler, the work order stays in to schedule. Only the worker
can change it to Scheduled so that his timing is not impact anymore.

Recompute must be done based on MO start date, except if MO is late. For late MO the
recompute must be based on the date of the day.

25/58
Rework (done)
Based on repair.

Procurements
Introduction

Procurements should become the main material planning tool having much more visibility and
usability than they have got now.

On push and pull rules,we need a checkbox that says if the procurement is triggered
automatically or requires a manual validation before generating the orders (MO, PO, ) That
way, the planner can decide to subcontract instead of producing, or to group manufacturing
orders, or to schedule priorities.

When procurement generate manufacturing orders, they can add to existing manufacturing
orders that are for the same location, procurement group, and same product and that are
confirmed but not yet started. This is similar to the way purchase orders work in version 8.
(multiple procurements can trigger one purchase order, if the procurement group is the same).

For that, we will add a field on the product to depict the time frame for which we allow the
grouping of procurements (same field will be used for PO and MO). It will work in the following
way: given that my product X has a time frame of 5 days for grouping procurements, when I
confirm a procurement with a buy route for the 15th of October, it will look for a draft PO for the
same product between the 10th and the 20th of October to add the procurement quantity. For
the produce rule it will look for confirmed MO in the same period.

Once a MO is planned, procurements will be created for the raw materials in the routing location
and its up to the procurement system to gather the raw material (buy, pull rules).

On a pull rule, remove the kind of operation (move, buy, produce): it can be deducted by the
picking type given (which becomes mandatory): incoming shipment buy, manufacturing
operation produce, other move.

Menus & Filter (done)

We need a menu: Procurements to Validate that lists all procurements that requires a manual
validation before being scheduled.
26/58
Form view (done)

tbd

Manual Routing

In some companies the logistic department want to validate/trigger manufacturing orders

manually. (instead of confirming all MO automatically) For this need, we will add a feature that
allows the procurement to wait for a manual decision. That way, you can decide on the
procurement level, before launching it, if you want to subcontract, buy or manufacture. (or use
another route) The user must have a list of procurements waiting for a validation and push/pull
rules may have a checkbox that says if the procurement should be decided upon.

Product form (done)

On the product form, add a related button X Procurements to schedule. This tells the user if
some procurements are pending a validation of the user. It only take into account, the
procurements that requires a manual confirmation.

Product Configurator & Variants

Product configurator

The way variants (mandatory & optional) are managed in the eCommerce is very good. It allows
to have an advanced product configurator in a very simple way. In the eCommerce, you first
select the first level of variants: (here 2 dimensions):

27/58
Then you have the options, every option may have its own set of variants too:

28/58
We need the same feature, but at the Sale Order and purchase order level:
1. Choose a template
2. A dialog opens and ask you to:
a. select dimensions to get a variant
b. Add options, with their variants too

Buying Matrixes

Generic Grid View (done)

We plan to implement a generic grid view. This view should replace the hr_timesheet_sheet
widget and should be useful to manage grids of variants at different levels: SO, Inventory, MO,
etc.

SO Related Matrix

In some companies, (e.g. garment industry), you often buy a lot of variants of the same
products. So, we need to open a matrixes of variants so that the user can set quantities for
every possible combination:

1. Select a product template

2. Fill the matrix to get several lines added to your SO:

Color / Size S M L (+5)

Red 5 4 6

Blue 0 2

Black 1 0 3

NOTE: the cell having a red background color is a combination that do not exist.

Dashboards (Foreman)
FLOOR PLANT FULL MOCKUP https://openerp.mybalsamiq.com/mockups/3675831.png

29/58
Dashboard: floor plant

The dashboard is a floor plant of the work centers, similar to the point of sale restaurant
module. Work centers have a color (selected manually), a shape (rectangle, circle) and a visual
status as a grey/green/red point like on tasks (unused=grey, blocked=red, used=green,
warning=quality or logistic problem) as well as a user working on it. (an avatar) Work center may
have a name that appears in the floor plant, but it is optional. (use the reference field that is
optional)

We can have different floor plants, like in the restaurant modules, with a selector on the top to
switch to another floor plant. Every work center belong to a floor plant (many2one on workcenter
to mrp.floor.plan). The tab of the floor plant can become orange or red is one of the related
workcenter is orange/red. (that way, you directly see if one work center is red/orange whatever if
floor plant)

The shape should be one of: rectangle, circle, rectangle with rounded corner, diamond. Every
work center should have a color (use the current color selector)

When clicking on a workcenter, you get a page displaying all the information of this work center
(see below, the work center control panel).

When a work center is red, show the time in the red bullet: 2h.
30/58
On the top of the dashboard, add some KPIs, like in the sales dashboard.

It will be a separate application called Floor Plant

Configuration (res.config):
Select your default dashboard:
Kanban of work orders (with no group by, more like the sales teams in the sales
dashboard)
Floor plant of work centers

Work center control panel (done)

The work center control panel is the main user interface for workers. It is designed to run on
touch screen tablets, with or without barcode user interface.

The work center control panel must include the following information:
If at least one work order is in progress
to be defined...
If no work order is in progress:
Blank screen with two buttons:

31/58
 Select Operator
Select Work Order
Show all available work orders, a list:
Or Scan a work order / MO

Operator:
Button to select the right operator (an employee that can operate this work center), or a
code assigned to the employee.

Note that several work orders may be running on the same work center in parallel. In that case,
you have tabs to select the right work order. (like tickets in the POS application)

Note: if the BoM or routing has been changed since the latest operation from the same operator
on the same product, the system should make a warning and show the change to the operator.
(A text message set on the ECO should appear on the work order control center, on red
background)

Sequence of Operations (done)

Lets take the following Bill of Materials, to produce a table:

Product Qty Consumed At

Table Top 1 Pce Drill Tabel Top

Legs 4 Pce Cut Legs

With the following routing:

Sequence Operation Work Center Cycles Production Phase

1 Drill Table Top Drill Machine 4

2 Cut Legs Cutting Machine 3

3 Assembly Worker 1 X

In this example, we have the following operations Drill Table Top Cut Legs Assembly.

Lets suppose you have a Manufacturing Order of 5 Tables that is started. Here are the
following operations:
A worker starts the Drill Table Top operation. He should record how many tables he
produced. He records 5 tables. (which actually consume 5 table top, but do not produce
5 tables)
32/58
 Another worker starts the Cut Legs work order. He records 3 tables because he does
not have enough Legs to produce 5. Recording 3 tables actually consume 12 Legs.
Once the two operations above have been performed, the Assembly work order
becomes ready. The system proposes to produce 3 tables (the min of all preceding work
orders). Lets say the worker records 2 tables at the Assembly: this does not consume
anything (as no components is linked to this work center) but it produce 2 tables as its
the latest work order of the process. (or the one marked as the production phase)
The next day, the worker cut more legs. On the work order Cut Legs, the worker record
2 tables (which actually consume 8 legs)
Then, the Assembly worker can produce the three remaining tables. Once this latest
work order is closed, the manufacturing order is marked as done.

The schema bellow shows all steps of the work orders.

33/58
And the related form layout:

Work sheets / work instruction (done)

Worksheet should be easily accessible from the work center control panel, related to the current
work order.

Integrate bottom-up feedback so that the worker can easily send feedback to the manufacturing
engineering team. --> something similar to awesome screenshot. The idea is that the workers
are the ones that best know how to improve an operation as they do it every day. That way,
workers can easily send feedback to the engineering team. (feedback loop)

34/58
35/58
 bottom-up feedback is a great feature that may interest a lot of manufacturing companies
https://openerp.mybalsamiq.com/mockups/3675831.png

On a routing operation, we need two documents:

worksheet: everything should fit in one page, it's not a complete training document, it
does not need to be complete, but it needs to be useful.
training document: full explanations, for those that want to learn the operation.

Most companies try to put everything in a single worksheet, but we think its a bad practice for
companies having cycle time of more than 45 minutes. (it may work in automotive industry
where they have lots of small cycles, but if a work order is more complex, its better to split the
two documents).

NOTE when working with Lots/Serial numbers: When registering productions and consumed
products in the work center control panel, we need a link between the finished product and the
raw material (even if you produce 10 products, for each of these products, you should be able to
define the lot of the related raw materials) its optional because it may change the way you
scan the serial numbers (you must first scan the finished product before scanning the related
components)

Scheduling (done)

The scheduler algorithm should work in three steps:

1. Schedule manufacturing order: expected dates, using the current scheduler (Odoo v9
already does this correctly)
2. Compute work orders start and stop dates based on manufacturing orders: by default
work orders end date are set at the date of the manufacturing order. The start date is
computed based on the duration.
3. Move work orders date based on work centers capacity and manufacturing orders
priorities. (move in the past)

The expected date on manufacturing order is never changed, even if you reschedule. But the
date on work orders my be updated at each run of the scheduler. (unless the manufacturing
order has started)

To compute the time operations, use the calendar attached to the resource (work center).

The screens to control the planning are the following:

Calendar of MO: based on expected date (one color by product?)
Gantt of MO: based on min(Start of all work orders) and max(end of all work orders),
group by product
36/58
 Calendar of Work Orders: based on start/end date of WO, one color per manufacturing
orders
Gantt of Work Orders: based on start/end date of WO
Kanban of work orders: group by work center

Traceability (done)

Note about the traceability: when we need to identify a finished product (a semi-finished one),
we usually do not scan the product but one of its component. (you identify a car by its chassis
number.)

We should change current lots tracking to reflect that: when we need to scan a finished product,
if we scan a raw material, it could be ok too, it will take the lot of the finished product directly
related to this raw material.

This is not related to MRP only, it should impact normal stock operations if MRP is installed.

On traceability of a lot, we can open the related stock.move: upstream and downstream
traceability. (that report must be super clean) From this upstream/downstream traceability, we
should be able to open the related documents: manufacturing order, delivery order, repair order,
scrap, A bit like in accounting, from the report, we dont open the journal item but the invoice
or the payment.

Bug in Odoo 9 to fix: when doing an inventory, the reference of the inventory should appear as
the source document on the stock.move (useful for traceability on stock.move). Same for repair
orders.

Touchscreen (done)

On the work center control panel screen:

Scan an employee code to select the operator on the work center.
Scan a manufacturing order reference to select the work order related to this
manufacturing order on this work center.
Special codes:
Start
Pause: (the resume is the Start barcode again)
Every failure can have a barcode
Finished
37/58
 Setup / Run / Cleanup (if we have time into routing for clean-up management)

Product Lifecycle Management (PLM)

(done)

The mrp_plm module mostly add features on the existing MRP to ease the maintenance of the
Bill of Materials and the routing. This include: additional fields (reference to plan, owner, ),
change requests (to change BoM), traceability features (revisions on BoM, Routings), efficient
management of attachments (plans), manage product and his revision history

Extra fields for PLM (done)

Add fields on bill of material:

Change Request in Progress: Yes, No
Lifecycle phase (Stage ID): (it is a status)
mrp.bom.stage object (just a sequence and a name, and a Boolean telling if it
can be used in production if it's in this stage)
Data to Create: In Production (production_ready=true), Obsolete
(production_ready=false)
Product Manager: many2one(res.users)
Ready for Production: Boolean, related(stage_id.production_ready), stored
Revision: fields.integer

The default mrp.bom.stage can be:

Engineering (eBoM)
Manufacturing Engineer
Manufacturing (mBOM)
Obsolete

Fields to add on a routing:

Routing version: fields.integer
Stage_id
user_id: (responsible, from manufacturing engineering dept)

Fields to add on product:

38/58
 Version

In the list view of BoMs, the bom is grey if active=false or production_ready=false. Blue if there
is an ECO in progress.

In the form view of bom, we need related buttons to see all revisions (boms for the same
product, active and inactive), as well as all ECO (related to this BOM or preceding one)

Note: In the data installed by default, we don't create stages like "In Development" that are
"production_ready=false" to avoid usability trap: I create a bom and I can't use it because it's not
production ready by default. (but people can create this stage if they need this feature.)

Product form:
Revision: fields.integer
Manufacturer
Manufacturer Item Number
Manufacturer Type: Make to Specification, Off-the-shelf
Status: computed field:
Engineering Change Order (eco) in progress
Nothing in Progress
On product forms, add a related button: 3<br>Where Used. It opens the bill of materials
that include this product as a raw material of the BoM

Engineering Change Orders (done)

Main workflow:
Validations are handled by stage (all the validation of preceding stage should be ok,
before moving an ECO to the next stage)
Once you start working on an ECO (a button to press manually), Odoo creates a
duplicate of the BoM and the routing and increase its version number, in non active
mode.
The user work on the newly created, unactivated, Routing / BoM
Once the ECO is finished, the current bom is desactivated and the new one, linked on
the ECO, is activated

Engineering Change Orders:

Rfrence: sequence field ECO/00001
Name: fields.char(Subject)
Description
product_template_id
bom_id: many2one
39/58
 Approval Deadline
Effectivity: After first exhaust, Asap, At date
Effectivity_date: date
Effectivity_status (computed field): Not ready, ready
Modifications Items: one2many
Product
Operation : Add, Remove or Update revision
New Revision
Qty
UoM
Approval_template_id: mrp.eco.approval.template
tag_ids: many2many(mrp.evo.tag) (name, color on tag)
Approved: fields.selection(Not Yet,Refused,Approved) Show a tag in the kanban
only if its Refused or Approved, not if in Not Yet
Approvals: (approval_ids, one2many: mrp.eco.approval
Approval Role: Team: char
Approval Requirement: optional, required, comments only
User: user_ids
Status: Not yet approved / approved / rejected / commented
Stage (=stage_id: mrp.eco.stage)
kanban_state: grey, green, red
Add a button that applies the ECO to the BOM: it deactivates the BOM and creates a new one,
that is a duplicate with the change applied.

ECO Stages: (mrp.eco.stage)

Sequence: integer
Name
approval_ids
Folded: boolean, default False
Data to create for stages:
New
In Progress
Validated
Effective
Refused (folded)

Approvals (object: mrp.eco.stage.approval):

Approval Template Name
Approval Template Lines (one2many: mrp.eco.approval.template.line)
Sequence
Name (Role)
user_ids: many2many
Approval Requirement: optional, mandatory
40/58
Two data to create for approval templates:
Engineering Change (3 validation: engineering, manufacturing engineering, logistic,
quality)
Manufacturing Change (1 validation only: manufacturing engineering) example:
change of a work sheet
NPI

When doing on on change on the approval template, it should fill the Approval_ids
automatically.

Note for Inventory Disposition: this is a field for information purpose only. It has no effect when
the ECO is accepted/done. The idea is the the Engineering Change Request is processed by
the engineering team, then other team can use information about the Inventory disposition to
actually: cancel/change PO, change products in the stock, Same for products change, once
the ECO is validated, it will not impact the BoM, but you can information about why you changed
some products and their revision numbers.

Stages to Create:
New Someone made a request
In Progress Engineering is working on it
Waiting Approval Approval in progress
Approved All mandatory approval accepted
Effective Put in production (engineering updated the BoM, manufacturing
engineer changed the worksheet, manufacturing trained the worked, ) They all do their
work when the task arrive in the Effective column, we put in green when everyone did his
job.

When setting an ECO to effective, it should:

Duplicate the current BoM, apply the changes
Set the oldest BoM in archive (or course, current MO are still on the old bom/archived
ones), only new MO will use the new BOM

Communication (done)
Communication is key between the four departments: manufacturing, engineering,
manufacturing engineering and logistic. To ease collaboration, at the installation of the different
modules, create dedicated channels: quality, maintenance, engineering. The admin user should
automatically join these channels.

41/58
Maintenance of Machines (done)

Introduction (done)

We plan to integrate the Equipments module with work centers. A work center may be
composed by several Equipments, can be machine or tools. It could be a workcenter with a
capacity of 3 (3 identical machines) or a machine and several tools, or a complex machine
having several components that should be maintained independently.

Equipment (done)

Replace category on a maintenance request by a Related field. (readonly)

The generic module for equipment independent of mrp, and can be used for all equipments in a
generic way (cars, IT assets, buildings). Then the module mrp_equipement will inherit to
make the relation with the workcenter.

On a work center, add a many2many field to Equipments one work center may have
different equipments, and an equipment can be shared across several work centers (e.g. tool).
This is not an important field, it is only used to get statistics on the work center level. (e.g.
MTBF) If not set, everything works perfectly, its not required.

Maintenance (done)

The concept of maintenance requests is already existing in the equipment module, so only the
things related to mrp_equipement should be in mrp_maintenance module (as Maintenance is
not mrp specific and could be fully working on non-mrp equipments as well).

The maintenance request object will be used for preventive (maintenance request in a future
date) as well as for corrective maintenance.

Preventive maintenance (done)

The periodicity of preventive maintenance will be done simply with 2 fields on equipements:
an integer for the number of days between each preventive maintenance
the date of next preventive maintenance
42/58
That means that if I have an equipment -say a saw machine- that should be checked every 2
weeks for the blade and every 1 month for the oil level, then I should split my saw machine in 2
equipments in Odoo (saw machine: blade, saw machine: engine).

There will be also a view on equipments having their date of next preventive maintenance >
today or empty, so that its easy to keep track on them, and the date of next preventive will be
automatically updated when a maintenance request is done for an equipment. Some cron job
(scheduler) could be defined to automatically create the maintenance request, or even
reminders few days before.

Everything related to preventive maintenance should be done in the generic equiment module.

Maintenance Request (done)

To modify in the generic equipment module:
remove things related to HR (department, employee) and dependance
equipment_ids: many2many instead of m2o (widget=many2many_tags)
team_id: (equipment.maintenance.team object with just a name field), default data:
Operator
Maintenance Team
Metrology Team
Subcontractor
type: corrective / preventive
responsible_user_id: (visible if responsible type in (vendor, operator))
next_action_date
priority
description: explain what to do
archive: instead of active

In mrp_maintenance module:
Alert in work center control panel: boolean
If alert true:
workcenter_id

Note: maintenance request of type operator should appear on the work center control panel.

On the Equipment object, add:

Expected MTBF
Mean time between failures (MTBF), stored, based on latest failure, if any. Otherwise,
use the Expected MTBF.
Mean time to repair (MTTR), stored
Estimated Next Failure, computed field, integers not stored: Latest Failure Date + MTBF

43/58
 - Current Date. (in days)

Menu (done)

Create a module mrp_equipment that adds menu in the MRP application:

Maintenance
Equipments
Maintenance Requests
All Maintenance Requests
Subcontracting
Maintenance Team
Operators
Preventive Rules

Master Production Schedule (done)

An MPS can be important as certain raw materials have a long lead time and need to be
purchased even if the sale orders are not confirmed yet. It is also interesting to plan other
resources in advance.

It start from the demand forecasts to check how much is necessary at which dates (regular
periods of e.g. a week). For the forecasts, you might want to base yourself on historical data
(other module) , seasons, trends So it will be only manual at first but could be improved in
further versions.

The report will be based only on forecasted stock and demand (forecast + indirect) to propose
the quantity to supply. There wont be comparison with confirmed demand (SO) or confirmed
supplies (PO, MO). This could be added in another module but we want to keep the report as
simple as possible and adding too much information would be counterproductive in that aspect.

The MPS of Odoo will be one dynamic report (like the accounting reports) that will compute all
the products at once. Changing one product can change the values of a lot of products in the
report, with everything calculated as much as possible on the fly. The report will show a table by
product-warehouse and products are sorted by product category in order to process similar
products together.

For one product and warehouse, the table will be as follow:

(procurement method: buy) (safety stock defined on the product 5)
P1 P2 P3 P4 P5 P6

44/58
 Demand 30 40 30 40 40 20
forecast /!\ 32
confirmed

Indirect 0 10 0 0 0 0
Demand

To supply 0 15 30 (button) 40 (button) 40(button) 20(button)

Forecasted
Qty 70 40 5 5 5 5

1. Forecast Stock(N+1) = Forecast Stock(N) + To Supply(N) - Direct(N) - Indirect(N)

2. To Supply = X < Safety and (-X + Safety) or 0
3. X = Forecast Stock - Direct - Indirect

Demand Forecasts can be changed e.g. if you have an unexpected sale, you could add to
the forecast and they are saved for next time
Indirect Forecasts are due to other forecasts of products in the report where e.g. this product
is a component. This one is a little bit complex to compute as it has to follow the stock
moves, procurement pull rules, bom explosion based on the the demand of other
products.
To supply is the procurement orders that need to be created in order to keep the safety
stock for the next period. There is a button that allows to create a procurement order
directly from the report and once it is clicked, the cell changes of color to depict that an
action has already been taken.
Forecasted quantity: starts with the current stock of product in that warehouse (in bold in the
example), and is computed from that.

Buttons:
Launch: create and run the procurements for real (can change the quantity in pop up
window, show also the route that will be used for the procurement resolution and people
can change it manually if they want)
Save/change sale forecasts
button to recompute all data in top left

We may need to add an editable tree view with one line per product to encode the Demand
Forecast. But this is the same report than the above one, you can just told/unfold by clicking on
an expand button:

Demand Forecast in Warehouse XYZ

45/58
 P1 P2 P3 P4 P5 P6

Ipad

RJ45 wire

Other remarks:
- The period taken is not necessarily by week -> definition is made on the company level,
and thus is the same for all products of the company
- In the report, we will show only the line to supply, but we will be able to expand it to see
the details.
- When you set a quantity in a cell, if will set this quantity in all cells on the right having the
same original value. Example with empty values:
- Set 50 on P1, Odoo will fill 50 on all cells
- Set 40 on P4, it will also fill p5, P6
- Set 20 on P3, only P3 is changed

Quality (done)
Introduction (done)

In quality, people are usually obsessed by the document management (version control,
archiving, approvals, ) but we think the key of a great quality department is in the process /
flow and the communication Cfr the feedback loop mechanism described on the worksheet,
should be part of the quality application.

Quality is not related to MRP only. The module that integrate the quality should be stock_quality
& mrp_quality

The main flow work that way:

Quality Control Point Quality Check Quality Alert
Problem Somewhere Alert Launch future quality checks (e.g. control the next 3
pieces)

Scrap (done)

In the stock module, add a feature to scrap products, and a menu.

46/58
Add a new document to scrap some products:
product_id
lot_id
quant_it
work_center_id (so that we have the cost of scrap in the production)
manufaturing_order_id
quantity
product_uom_id
scrap_reason_id: many2one stock.location having scrap_location to true
state
draft, scraped

Remove all scrap icons on the stock.move views. (people will directly use the menu)

Quality Control (done)

The quality team defines control point (when and where should you do a quality control). These
control point will launch quality check requests at different level: picking (reception, delivery, ),
or some work orders. A quality check is technically an eSign document with some fields to fill in.

Here is how the worker will use it:

1. On the work order screen, he sees a quality check to do
2. When clicking on the button, he as a quality screen (eSign)
3. At the end of the eSign, he should click Pass / Fail

47/58
48/58
The above example triggers the quality control from the work order. We need a similar button on
the stock.picking (on the lot view, or the picking line directly based if lot or not)

Quality Control Objects (done)

Quality Alert Type (quality.alert.team): _inherits = {'mail.alias': 'alias_id'}

Name
Sequence
Color
# current alerts: function fields
alias_id': fields.many2one('mail.alias', 'Alias')

Default data for alert types:

Non Conformity Request
Work Center Failures
Security Alerts

Quality Control Point (quality.control): inherit (mail.thread)

Active: boolean
product_template_id: fields.any2one, requiredl
product_id: fields.many2one (not required: apply to a template)
type_id: fields.many2one(required)
measure_at: section, Measure At (--> not required anymore defined by picking type)
Stock Operation (shipping, packing, internal move, reception, )
In Process Control (@Work Order)
measure_picking_type_id: many2one (stock.picking.type)
if measure_type==Stock Operation
measure_frequency: selection
All operations
Randomly (%)
Periodically
measure_frequency_value: (could be a % or a int)
Appears only if randomly (X%) or periodically (every X products)
template_id: many2one(document.esign.template)
(NOTE: should we call that a control point, isnt there a better wording for this?)

Quality Check: (quality.check)

control_id: many2one(quality.control)
user_id: fields.many2one(res.users)

49/58
 document_id: many2one(document.esign.document)
lot_id: many2one
type_id: fields.many2one(required)
quant_id: many2one (technically, we need a quant, not a lot. But for the UI, its easier to
search for a lot, and an on_change will set the quant) Or if we do a clean
name_get/name_search on the quant, we can even avoid the lot_id field.
alert_id: (if failed, we can launch an alert directly)
state: (this is a selection field, not a many2one)
To do
In progress (he opened the document)
Success
Fail
Skipped (FP NOTE: can we allow to skip?)

The quality check can be created in advance and the work order / delivery order will use it if its
already defined. (that way, you can create quality check requests that will be fulfilled at the next
work order related to the same product/work center/lot)

Quality Alerts (done)

Quality alerts are triggered when something failed: could be a problem in the process (work
center failure), in suppliers (not received products on time) or a quality problem on a product
(following a quality control)

The most important feature of quality fails is the communication. Be sure to attach the right
persons to the open chatter related to the quality alert:
For inbound quality checks; communication with supplier,
For customer quality alerts: communication with the customer
For work center failures: communication with maintenance team

Quality alerts can be created:

manually
following a quality control (cfr above section) a Non Conformity Request
setting a work center in red/orange

They are managed through a kanban view.

Objects (done)

quality.reason

50/58
 name: char(Name,required)

quality.tag
name: char(Name,required)
color

Quality Alerts (inherit mail.thread)

type_id: fields.many2one(required)
user_id
reason_id
create_date
date_assign
date_close
subject
product_id
workcenter_id
lot_id
tags: many2many
action corrective: text
preventive action: text
root cause: text
stage_id: many2one(quality.alert.stage)

quality.alert.stage:
name
sequence
folded
type_id: fields.many2one(required)

Work centers have a status (kanban_state):

red: blocked
orange: slowed down seriously
grey: not used
green: used

When setting a work center into red/warning, we should ask for a reason. The main reasons, to
create as data are: products missing, machine broken, quality problem.

Possible feature: When a problem is detected, measure the next 3 lots automatically.

The dashboard is a kanban view on quality.alert.team

51/58
Random notes to specify (done)

SPC = control process

Sampling (done)

When an item is setup as quality control quality assurance dept can take some pieces to make
all required tests (this process is called sampling). After all tests the items must be moved to a
location on which we can retrieve them in case of problem, customer complain

The sampling process is done when item are moved into quarantine location. Not sure we
should handle that.

Statistics Reports: SPC (done)

This section should be completed.

Graph of workcenters:
X: Workcenter
Y: Cumulated Time
group by: status: green, red, orange

Graph of reasons:
X: Date
Y: Cumulated Time
group by: reasons

RMA (Return Merchandise Authorization)

To be specified (a RMA can just be a picking in draft?)

Menus (done)
Quality: (app)
Dashboard (quality.alert.team kanban view)
Alerts (ungrouped kanban view with all alerts)
52/58
 Quality Control
Quality Control Points
Quality Checks
Reporting
Quality Checks
Quality Alerts
Configuration
Quality Alert Stages (group no one)
Quality Tags

Maintenance (app)
Dashboard (kanban of teams)
Maintenance
Maintenance Requests
Maintenance Calendar
Assets
Work Centers
Machine & Tools IT Assets (domain on category)
Reporting
Overall Equipment Effectiveness (OEE)
Losses Analysis
Configuration
Settings
Maintenance Teams
Tags

PLM (App)
Changes
Engineering Change Orders
BoM in Development (kanban of all bom, group by stage_id)
Master Data
Products
Bill of Materials (list view filtered on production ready)
Routing
Search
Plans and documents
Reporting
Change Requests

MRP (app)
Dashboard: Floor Plant the main menu: click on a work center to get his todo list
Manufacturing
To dos:
53/58
 Manufacturing Orders list view allowing drag & drop to prioritize
Work Orders kanban by work centers allowing d&d to prioritize
Planning
Work Orders Planning gantt of start/end expected group by work
center
Manufacturing Orders same gantt on work orders but grouped by
manufacturing order
Operations
Unbuild
Scrap
Rework (=repair)
Alerts
Procurements to Process those that should be launched manually
Late Manufacturing Orders
Procurements in Exception
Master Data
Products
Bill of Materials (list view filtered on production ready)
Routing
Reports to be improved / specified
Manufacturing Orders
Work Orders
Configuration
Settings
Quality
Dispositions
PLM
Validation plans
Planning
Working Time
Resource Leaves

Configuration
In Odoo 9, merge the two options Work Order Planning and Routings into a single one.

Three apps to develop:

Product Lifecycle Management
Quality
Maintenance
54/58
Contract (purchase agreements) (done)
Manufacturing companies work most of the time with contracts (purchase and sales)
- to order item with big quantities and small prices purchase manager need to make a deal
on price and quantity for defined period.
- Same for sales
- Contrat need to have a number, partner, items, qty, fixed price, valid from & to date
- When PO line or SO line is fulfilled, valid contract code must automatically be retrieve
and price is search into contract
- When PO quote or SO quote is confirm then qty is updating the contract real qty ordered

The purchase_Requisition module has been improved to purchase agreement to manage

contracts

Blanket orders (done)

Manufacturing companies order many time an PO item line or SO item line with many delivery
date. The line is like a firm commitment but with scheduling on deliveries (blanket).
- eg: firm commitment from 10000 pieces but blanket delivery as follow
4000 -> 01.09.2015
3000 -> 22.09.2015
3000 -> 12.10.2015
We could not entry 3 lines on PO or SO because the goal to place a firm commitment is
to reach the better price as possible, if we share with 3 lines the price/qty dont consider
the full qty

Technical Specification (done)

Split of Modules

Features in Odoo Community:

bill of materials, kits, manufacturing order, routing, work orders
scheduling of MO (expected dates)

Features in Odoo Enterprise:

mrp_floor_plant: floor plant dashboard
55/58
 scheduling of work orders
work centers planning
statistics & dashboard
touchscreen and barcode UI
Maintenance
Quality - documentation

Workflow

When all work orders are done, the manufacturing is set as done.
When one work order start, the manufacturing order is started.
When a manufacturing order is done, finished products that have not been produced by
a work order are produced.
When a work order is done, components related to this work order are consumed, and
finished products related to this work order are produced. Of course, the quantities
should be provided by the worker. If nothing is recorded, the default value should be the
expected ones, with a dialog for confirmation (like delivery orders in v9)
When a manufacturing order is done, all other components are consumed

Business cases
We put some typical business cases in here in order to contextualize. What is written here is
not necessarily covered by the specs above. (but we should at least check)

PLM: Two different departments: engineering and

production department

First, the engineering department is going to start creating the BoM when designing the product.
In a lot of companies, this will happen a lot in the CAD program itself, where the several parts
might be created too.

When the engineering department approved the BoM, the manufacturing department will check
how it can be planned and executed on the different work centers. This can also change the raw
materials used a little bit and they will add the routing and the work centers. For that, it will copy
the engineering BoM into a manufacturing BoM.
56/58
When changing a BoM, there are two possibilities. The change is an engineering change and
needs to be checked and approved by the engineering department for design and functionality.
Then you need to change the engineering BoM and it is important to change product revision of
the product. (When the BoM is child of other BoMs, it is important to change that revision also)

It is also possible that the change is a small one or has more to do with the way it is
manufactured than the engineering itself. For example, a screw that is made a little longer.
Then it can just be changed in the Manufacturing BoM.

Indented BoMs and history

The reports of indented boms can be interesting to see the entire picture of what is in the BoM,
but it would be interesting also to see the combined routing of the different BoMs e.g. to see the
total capacities needed. For traceability reasons, you also want to answer the question: at that
date, was that component in the BoM or not?

Being able to change the product in all BoMs because

we don't want to use the component anymore.

When a product is depreciated or we want to deactivate it, we should have an easy way to
change it in all BoMs.

Corrective vs. preventive maintenance

There is an important difference between corrective and preventive maintenance. Corrective

maintenance is when something breaks and preventive maintenance is done to prevent
breakage. Both should be followed up.

MPS: MTO orders, but MTS raw materials

Sale orders can be made MTO as it can be produced in a relatively short time (e.g. a week) and
you can easily create a manufacturing order immediately for each order, but the raw materials
itself have a long purchase lead time, which means you will need to buy those MTS. (in other
57/58
words, in the MPS of the raw material, you will already create the raw materials)

So, based on the forecasts of the MTO finished product, you will buy its MTS components
already. Once the real orders are there, they create the manufacturing order (but not the
purchase orders as it is MTS). As the forecast created the necessary raw materials, they will be
there.

58/58