Importing Customer Due Dates vs Internal Need Dates

An ERP work order usually carries several dates, and only one of them belongs in the EDGEBIC due date field: the date you actually committed to, expressed as the point manufacturing must be finished. Dates the ERP derived by subtracting a lead time allowance are a different kind of value, and importing one as a due date subtracts a buffer twice: once in the ERP's arithmetic and again when finite capacity scheduling computes the real work content against real machines.

EDGEBIC by User Solutions has mapped ERP order dates this way since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the date column is where a first import most often looks fine and reads wrong.

The dates a work order export usually carries

Names vary by ERP, so identify these by what they mean rather than by their heading:

The first four often sit within a few days of each other, which is exactly why mapping the wrong one is easy and hard to notice.

What EDGEBIC does with each date it receives

Two fields matter on the order import.

The job date is the demand's own timing anchor. Without a due date, a job schedules forward from here.

The due date is the deadline the plan works toward. It drives ranking against other jobs and it is the anchor for backward scheduling from a due date. The general trade-off between the two directions is in forward versus backward scheduling, and no import mask carries the direction itself, which is why the direction decision your ERP export cannot make is a policy to settle before the first order file.

Both are accuracy fields rather than blockers. A work order with a product, a quantity, and a job date will schedule, as the field tiering in which ERP fields EDGEBIC needs sets out. Adding a due date changes how the job is ranked and lets you plan back from it.

The double-buffer trap, in numbers

This is the specific failure worth naming.

Say a customer commitment is the 30th. Your ERP subtracts a standing 10 working day lead time and produces a need date of the 16th. That 10 days was never a measurement: it is an allowance covering queueing, changeovers, and a machine being busy, assumed rather than computed.

Now import the 16th as the due date. Finite capacity scheduling takes that deadline and works backward through the real work content, which includes queue time, setups, and the fact that the mill is booked. It might land a start on the 4th.

The second row looks safe and is expensive. Jobs start earlier than they need to, work in process rises, machines fill with work that did not have to be there yet, and the jobs that genuinely are urgent compete with jobs that are not. Worse, the schedule reports jobs as late against a deadline nobody promised, so the late list stops meaning anything.

The general version of this argument is in the cost of an unrealistic due date.

The mapping that works for most shops

Due date: the production due date. The commitment, adjusted by a consistent, documented offset for packing and transit. Apply the offset in the export, not in somebody's head, so every order gets the same treatment.

Job date: a real earliest start, or the order date. Map a derived need date here only when it stands in for a genuine constraint, such as material arriving, a customer authorization, or a drawing release. Where it is only arithmetic, leaving it out lets the engine find an earlier start when a machine is free.

Priority: separately, if you have one worth trusting. Ranking is not the due date's only job, and squeezing urgency into a fake early date is the habit that erodes date discipline everywhere. Use the field made for it, as covered in mapping ERP order priority into your schedule.

Why the due date is a target rather than a wall

A finite capacity engine that refuses to schedule a job it cannot fit before its due date is giving you a shrug. EDGEBIC works toward a due date and shows you the miss when the capacity is genuinely not there, which is the answer you can act on: add a shift, split the order, move it to another machine, or renegotiate with the customer.

That is also why the optimizer treats deadlines as strong targets carrying heavy penalties rather than as hard constraints, explained in why the optimizer treats due dates as soft targets. A plan that shows a two-day miss is more useful than no plan at all.

Getting the date format right on import

Two mask behaviors handle nearly all date friction, so you do not pre-edit files:

• Format parsing. Dates are parsed against the invariant format first and your machine's regional format second, so a locale-specific export lands correctly without a conversion step.
• Row-level failure. A row with a genuinely unreadable date is marked Failed with the reason recorded, and the run continues through the remaining rows. One bad date never blocks 500 good ones.

Time of day is worth a decision rather than a default. A due date that arrives with no time component lands at the start of the day, which is stricter than most shops mean when they say "due the 30th". If your commitment really means end of day on the 30th, carry that in the export consistently.

Check the mapping on your own dates

Three quick tests after the first import:

1. Pick a job with a comfortable deadline. Its due date in EDGEBIC should equal the date on the customer acknowledgment, plus or minus your documented offset. If it is a week or two earlier, you mapped a derived date.
2. Look at the late list. If nearly everything is late on a shop that ships on time, the deadlines are derived rather than promised.
3. Look at the start dates. If jobs are starting far earlier than the floor would ever release them, a derived need date is sitting in the job date field and holding, or a double buffer is pulling everything forward.

Fold those into the wider pass in the import reconciliation checklist.

Sending the honest date back

The return trip closes the loop. The job schedule exports to Excel from the Job View grid with the dates finite capacity actually produced, and those go back into the ERP through whatever date maintenance path your order process already uses. There is no automated write-back, which keeps the ERP's data under your team's control. The mechanics are in exporting the EDGEBIC schedule back to your ERP.

That exported date is the one worth arguing about with a customer, because it came from real machines, real shifts, and real changeovers rather than from a standing allowance. The engine behind it is mapped on the EDGEBIC product overview, and the import layer every ERP shares sits under the ERP integration architecture.

Bring one week of orders

Export a week of open work orders with every date column your ERP carries and bring them to a demo. Naming what each column actually means takes fifteen minutes, and it usually settles a disagreement between sales and production that predates the software.