Should You Import Your ERP's Manufacturing Calendar?

Your ERP's manufacturing calendar is a working-day flag per date, built so MRP can offset lead times, and a flag cannot tell a scheduler which hours exist. So import the part that is genuinely useful, the closure list, and author your shift patterns as a short spreadsheet that goes in through its own mask. The calendar is EDGEBIC-owned for a good reason: no ERP models a plant calendar at the grain finite capacity scheduling needs, and pretending otherwise produces dates that look precise and are not.

EDGEBIC by User Solutions has been building shop calendars alongside ERP data since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, this is consistently the highest-value hour in the whole setup. Every scheduled date is computed against it.

What the ERP calendar actually contains

Open your ERP's shop calendar and you will usually find one row per date with a flag: working or non-working, sometimes with a shop calendar identifier so different plants can differ.

That is the right model for what it does. MRP needs to count working days backward from a due date, and a flag per date answers that question exactly.

It does not answer the questions a finite capacity engine asks:

One row on that table is worth importing.

Harvest the closures, author the shifts

Harvest: the non-working dates. These are the one piece of calendar data the business genuinely maintains and agrees on, including the shutdown weeks nobody remembers to enter twice. Export the non-working dates, drop weekends if your shift patterns already handle them, and import the remainder as plant holidays. The step-by-step is in how to import plant holidays from a file.

Author: the shift patterns. One row per shift with a start time, an end time, and a break per weekday. A two-shift plant needs two rows. Import them the same way any other file goes in, covered in how to import shifts from a file.

Keeping both as spreadsheets rather than screen entry has a quiet benefit: the calendar becomes a file you can review, diff, and hand to somebody else, instead of settings nobody can audit.

What a shift row has to say

The fields are short and each one moves dates:

• Start and end time per weekday. A shift that does not run on Saturday has zero hours on Saturday rather than a missing row.
• Break duration. Real available hours are the span minus the break, so an unmodeled hour of breaks per shift is five hours a week per machine.
• Whether the shift crosses midnight, which is a genuinely different case and is covered in how a schedule handles a shift that crosses midnight.

The concept of a shift as the scheduler sees it is in what is a work center shift, and the full configuration path is in how to set up shifts, holidays, and downtime.

Assignment matters as much as the pattern

Most shops need very few patterns and one clear assignment. Three shifts on two machines and one shift everywhere else is two patterns, not thirty calendars.

Assign each work center to the pattern that reflects its real hours. Then remember that shift hours and the instance count work together: a center running one shift with four identical machines has four times the hours of the same shift with one machine, and most ERPs export the machine count as one. The instance count is the highest-value field on the whole load, as set out in which ERP fields EDGEBIC needs to schedule.

One-off exceptions stay exceptions. A Saturday added to break a bottleneck belongs as an exception rather than a rebuilt pattern, so the standard hours stay standard and the extra day reads as the deliberate decision it was. That case is walked through in adding a second shift to break a bottleneck.

Holiday scope: whose closure is it

A closure is not always plant wide. A maintenance day that shuts one cell is different from a national holiday that shuts the site, and treating them the same either over-reduces or under-reduces capacity. The distinction is covered in what is holiday scope in scheduling calendars, and the symptom when it goes wrong is in a holiday did not reduce capacity.

Harvest plant-wide closures from the ERP. Enter work-center-specific closures locally, because the ERP does not model them.

Keep runway ahead of your horizon

This is the calendar failure that surprises people, because it is silent until it is not.

A holiday list that runs to the end of this year is fine in June and wrong in November, the moment a job with a four-month lead reaches into January. Nothing errors. The plan simply schedules straight through a plant closure and every date after it is wrong.

Keep at least six months of calendar ahead of the longest job on your board, and check it during a monthly ERP to EDGEBIC data audit. Refresh the closure list once a year when the business publishes it.

Leave the calendar out of your other masks

Because the calendar is EDGEBIC-owned, no capacity column from the ERP should be mapped onto it, and no work center mask should carry a column that resets shift assignment or instance counts.

An import writes only the fields you mapped, so an unmapped field is never touched however often the import runs. That is what makes ownership durable rather than a rule someone has to remember. The full ownership map is in choosing the system of record for each scheduling field.

Ten minutes with the widest effect

Once shifts and holidays are right, every hour the engine hands out is an hour that really exists. From there the rest of the model applies: finite capacity across shifts and machine instances, work center groups, sequence-dependent setups, lot streaming with transfer batches, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps the engine, and the ERP integration architecture shows where the calendar sits relative to the ERP-fed masks.

The order to do it in, alongside the rest of a first load, is in the first week ERP integration checklist.

Bring your calendar and your shift times

Export your ERP's non-working dates and write down your real shift start and end times, then bring both to a demo. Building the calendar live takes about fifteen minutes, and it is usually the point where a planner sees their own capacity numbers for the first time.