Two orders both need that machine on Tuesday, and the system has no opinion about which one gets it
The requirement is not the hard part. Something needs building, the structure says what it is made of, the lead times say when it has to start, that arithmetic is honest work and a computer does it better than a person. The hard part arrives one step later, when the two orders that were each scheduled sensibly turn out to want the same work centre at the same hour. Somebody now has to decide which one moves, and that decision has consequences the person making it usually cannot see: which customer date slips, which component reservation unwinds, which downstream operation goes idle. So it gets made on the floor, by whoever is standing there, and the system finds out afterwards.
What you get with MRP
Manufacturing wired into supply rather than bolted beside it. A supply rule can take the action manufacture, which turns a need at a location into a production order, the same mechanism that raises a purchase for a bought part raises a build for a made one. The warehouse decides how many physical steps that involves: manufacture in one step, pick components then manufacture, or pick, manufacture and then store. And the order remembers why it exists: the reordering rule, the procurement group and the sale line that caused it are all fields on the production order, so "who asked for this" is a link rather than an investigation.
The order carries real dates, not just a status. A start, a finish, a deadline, a flag for whether it has been planned, and a priority that decides which order gets first call on the components when two of them want the same stock. The date the schedule works back from is built from the same lead-time arithmetic that raises the purchase orders, the production delay held on the bill of materials is read by the procurement layer and added into the cumulative delay along the path.
Below the order, the sequence is a graph rather than a list. Operations on the bill of materials become work orders when the order is confirmed, and where the BoM enables it, those work orders carry explicit blocked-by and needed-by links to each other. There is a planning routine that schedules them, a work-centre load view, and a check that identifies work orders which overlap. Work centres themselves are modelled properly: a working calendar, a default capacity with per-product overrides, setup and cleanup time, an efficiency percentage, and a list of alternative work centres that can absorb the same job, with expected duration recomputed against the alternative's own capacity and efficiency when you move a job there.
And the line this page will not cross. All of that models capacity and shows you the collision. None of it resolves the collision. What we install has no finite-capacity scheduler and no optimiser: nothing in it takes your order book and returns the sequence that best fits your machines. It will tell you that two work orders overlap, what each work centre is loaded with, and which alternative centre could take one of them, and then a person decides. Systems that do solve the sequence exist, they are a distinct category with a distinct price, and we would rather you hear that here than discover it in month three.
Where MRP comes from
The whole of the above is Odoo Community, the manufacturing core, checked feature by feature against a running instance rather than read off a feature list. Work orders, work centres, the dependency graph, the load and planning views and the printable order documents are all included. No tier to reach and no extra per-user fee, and it runs on infrastructure you own.
One thing under this heading genuinely is not available, and it is worth knowing before you sign anything: there is no shop-floor tablet interface for operators. Odoo's own is an Enterprise app, and unlike most gaps in this stack there is no free replacement to install, we went looking, and the community barcode project never ported the scanning application forward. On Community, operators work through the standard back-office screens. That is a real limitation, it is on the short list of ones we have actually verified, and no add-on closes it.
What is MRP, and what does it actually calculate?
MRP stands for material requirements planning, and what it calculates is narrower than the name suggests: given something that has to be finished by a date, and a structure describing what it is made of, MRP works out which components are required, in what quantity, and by when each of them has to be available or started. It does this by exploding the bill of materials level by level and offsetting each level by its lead time, so a requirement for a finished unit in six weeks becomes a build starting in four and a purchase raised this afternoon. Two things are outside it, and confusing either with MRP is the usual source of disappointment. MRP does not forecast demand, it takes the requirement as an input. And classical MRP assumes capacity is infinite: it will tell you that four jobs need to start on Tuesday without noticing that you have one machine.
What is the difference between MRP and finite-capacity scheduling?
MRP answers what to make and when to start it, assuming the resources are available. Finite-capacity scheduling, the core of what is usually sold as advanced planning and scheduling, or APS, answers what to run in what order on which machine, given that the resources are not available, and it does so by solving a constrained sequencing problem across the whole order book. The difference is not a matter of degree. A system can model capacity in detail, hold a calendar per work centre, a rate per product, setup and cleanup time, an efficiency factor, a list of alternative machines, and still leave the sequencing decision entirely to a person, and most ERP manufacturing modules do exactly that. Vendors are not always precise here: NetSuite's own supply chain page describes systems that "accurately schedule machinery and labor resources" and use "AI powered predictive analytics" to "optimize production strategies". The question worth asking of any such claim is concrete, when two work orders collide, does the software tell me, or does it move one of them? Both answers are legitimate. Only one is a scheduler.
How does a production order know when it has to start?
By working backwards from when the output is needed, through the delays that sit on the path between the two. The bill of materials carries a production lead time, how long the build itself takes, and the supply rules between the stock location and the source each carry their own delay, with the supplier's quoted delay held separately on the supplier line. The required date, less the sum of those delays, is the date the order has to start; the same arithmetic is what decides whether a component has to be ordered today. This is worth understanding rather than trusting, for one reason: every one of those delays is a stored value that somebody entered, so a start date that looks wrong is almost never an arithmetic problem. It is a lead time that has not been revisited since the supplier changed.
Is manufacturing in Odoo Community, or does it need Enterprise?
The manufacturing core is in Community. Bills of materials, production orders with their full lifecycle, work orders, work centres with capacity and efficiency, the work-order dependency graph, work-centre load and planning views, OEE reporting and the printable production documents are all included, and so is manufacturing accounting, with no extra per-user fee. Three named things are not: the shop-floor tablet interface for operators, engineering change orders and product lifecycle management, and quality control are Enterprise capabilities. The distinction is worth checking rather than assuming in either direction, because "manufacturing is included" and "everything you saw in the manufacturing demo is included" are different sentences, and the second one is the one that matters at renewal.