Advanced Production Planning and Scheduling

Run the MRP wizard in SAP Business One and you get recommendations: make this, buy that, by this date. What you do not get is a schedule. There is no operation sequence, no work centre load, no changeover logic and no answer to the only question the shop floor actually asks — what do I run next, on which machine, and can we still promise Friday.

So the plan leaves SAP and lives in a spreadsheet. One person owns it, it is out of date by mid-morning, and the true capacity of the bottleneck is a number in somebody's head. Promise dates are guessed from lead-time padding. Two jobs get released for the same machine on the same shift and the second one waits. Sales quotes a date the plant cannot hit, then the expediting starts. The ERP is not wrong — it was never asked to schedule.

ECOSIRE builds a production planning and scheduling add-on on top of your SAP Business One installation that turns the recommendation list into a sequenced, capacity-aware schedule. It is build-to-order: we model your work centres, routings, shift patterns and scheduling rules, quote a fixed price, then build and install. There is nothing to download today.

What SAP Business One already gives us, and what it does not

We build on the standard data model rather than around it. SAP Business One 10.0 already has Resource master data with capacity, Bills of Material that can carry resource lines, Production Orders, Forecasts and the MRP wizard. What it does not have is a routing with ordered operations and dependencies, finite-capacity sequencing that refuses to overload a work centre, a schedule board, or a promise date derived from real capacity. That gap is exactly what gets built, and your existing resource and BoM setup is reused instead of duplicated.

Routings and work centres

Routing is implemented as a User-Defined Object: an ordered set of operations per parent item or per BoM version, each with a work centre or resource, setup time, run time per unit or per batch, teardown, queue and move time, and predecessor rules that allow strict sequence, overlap or parallel paths. Alternate work centres carry an efficiency factor so a slower fallback machine schedules honestly.

Work centres are modelled on Resource master data with capacity, efficiency and a calendar: shift patterns, breaks, planned maintenance windows, holidays and non-working days. Where a resource is a person, a tool or a mould rather than a machine, it is modelled the same way — because a schedule that ignores tooling constraints produces jobs nobody can start.

Scheduling

The scheduling engine runs forward from a release date, backward from a due date, or bottleneck-first, and respects finite capacity: an operation is placed only where the work centre calendar actually has time. Sequencing rules are configured to your plant — earliest due date, shortest processing time, minimum changeover by attribute such as colour, grade or tooling, or a campaign rule that groups like with like to cut setups. A firm or frozen horizon locks the near term so replanning cannot yank tomorrow's work out from under the shop floor.

The planner works on a schedule board: resource rows, operation blocks, drag to reschedule with the calendar respected, a load histogram against available capacity, and a clear view of which jobs are late and why. Every reschedule writes back to the underlying Production Order (object type 202) dates, so SAP remains the record.

Demand in, schedule out

A master production schedule is assembled from Sales Orders (object type 17), Forecasts, safety-stock policy and manual demand lines. MRP recommendation output is consumed rather than replaced: recommendations become Production Orders and Purchase Orders (object type 22) on confirmation, with component requirements pegged to the demand that caused them so a planner can trace why a job exists. Pegging is what makes the difference when a customer moves an order and you need to know what to unwind.

Promise dates and the shop floor

Because capacity is modelled, a capable-to-promise date can be calculated and exposed on the Sales Order line in a User-Defined Field, giving sales a date that came from the plant rather than a padded lead time. Downstream, operators report against operations: quantity good, scrap with a reason code, and actual setup and run time, feeding schedule adherence and real versus standard cost comparison.

Component consumption is handled either by backflush on operation completion or by explicit Issue for Production, and finished goods post as Receipt from Production, so inventory and WIP stay correct without a parallel system. Crystal Reports deliver the paperwork the floor needs: shop packet with operation cards, dispatch list per work centre, load versus capacity, and schedule adherence by resource.

Architecture and compatibility

Built as an SAP Business One add-on plus a scheduling service: Service Layer (REST) for production order, sales order and master data operations, DI API where an object is not fully exposed, and UDOs, UDTs and UDFs for routings, calendars, schedule versions and promise dates. Compatible with SAP Business One 10.0 on Microsoft SQL Server and on SAP HANA, on-premise or hosted. Multi-plant setups are supported through warehouse and resource grouping so each site schedules independently while reporting into one company database.

Who it is for

Discrete and batch manufacturers who have outgrown the MRP recommendation list; plants with a genuine bottleneck whose utilisation nobody can currently prove; make-to-order businesses that must quote a date and hit it; and operations where setup and changeover time is large enough that sequencing decides whether the week is profitable.

How delivery works

A scoping call and a plant data review — we ask for your item and BoM structure, your work centres and shift patterns, a sample of real routings however they are recorded today, and the sequencing rules your best planner uses in their head. From that we produce a modelling proposal and a fixed written quotation with lead time stated; typically one working week from acceptance, since scheduling scope is wider than a document integration and the modelling has to be right. We build, then install into your test company database and schedule a real historical week so you can compare the engine's output to what actually happened. We tune the rules against that evidence. Only then do we install into production, with a cutover that runs the new schedule alongside your current method until your planners trust it. You receive source code, the modelling and configuration workbook, planner and operator documentation, and a post-go-live support window stated in the quotation.

What this is not

It is not a MES, and it does not collect machine signals unless that is separately scoped. It will not fix data that is wrong: if your BoMs and standard times do not reflect what the plant actually does, the schedule will be precise and useless, and part of scoping is telling you honestly what data work has to happen first.