Importing ERP Labor Transactions as Scheduling Actuals

If your ERP already collects labor transactions, export them and import them into EDGEBIC through the actuals mask: the schedule then knows what really happened, a reschedule preserves completed work instead of replanning it, and a partially finished job resumes from where its hours left off. Shops with reliable time collection do not need a second capture point on the floor. The transactions they already record are exactly what the scheduler needs.

EDGEBIC by User Solutions has taken shop floor hours from ERPs this way since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the difference between a schedule that stays believable and one that drifts is almost always whether actuals get back into it.

Why the schedule needs actuals at all

A plan without feedback is a forecast that never gets corrected. Actual hours do three specific jobs:

• They protect finished work. Completed work is never moved by a reschedule, so anything already done stays where it is on the plan.
• They set the resume point. A job that is 60 percent through an operation restarts the plan from that point rather than from the beginning, so only the remaining work is replanned.
• They feed variance. Planned against actual, per work center, is what tells you which routing times are wrong and which machines run faster or slower than the standard says.

The general behavior is covered in how actuals flow into the schedule and what is actuals preservation on reschedule.

What the import needs

The actuals import matches hours to a specific piece of work, so it needs three anchors plus the reported values:

The job number is why identifier discipline matters so much. Matching is on the identifier, case-insensitively, so hours only find their job if the ERP number carried through unchanged on the order import. The conventions are in keeping job numbers aligned.

The step-by-step application view of the same import, including the replace and auto-calculate options, is in how to import actuals from a file.

Getting the work center onto the row

This is the one column ERPs commonly omit. Many time tickets record hours against a work order and an operation number without naming a work center.

Resolve it in the export, not at import time. Most ERPs can join the time ticket to the routing operation on the same report, which puts the work center on every row for free. If the report cannot join, add a lookup column using your routing file, since the operation-to-center relationship is stable and the mapping is a one-time build.

Do not infer the center from the job's planned routing. A job that ran on an alternate machine would have its hours credited to the wrong center, which distorts both the resume point and your utilization reporting, and neither error announces itself.

Additive against replacing, and why you must choose

The actuals import can either add the reported values or replace what is already recorded for a given job, work center, and date. Both are correct for different export shapes:

• Replacing suits an export that always covers a full period, because a repeated or overlapping run reproduces the same result rather than stacking. This is the safer default for most shops.
• Adding suits a strictly incremental export that never overlaps a previous run.

The failure mode is mixing them. An overlapping export imported additively inflates hours silently. The affected centers look busier than they are, and the next schedule pushes work out for capacity that was never consumed. Pick one, write it into the mask, and keep the export shape consistent with it.

Unit conversion applies here too

Labor transactions are frequently recorded in minutes, or in decimal hours with a different convention from your routing times. Set a conversion factor on the hours column in the mask and the multiplication happens before the value is stored: 0.016667 for minutes to hours, 0.000278 for seconds.

Getting this wrong is the same clean-multiple error that shows up everywhere else in ERP integration, and the same fix applies. The wider treatment is in mapping your ERP's units of measure.

Sequence: actuals before the reschedule

Order of operations in the daily or weekly routine matters more than frequency:

1. Import master data changes if any: items, work centers, routings.
2. Import new and revised work orders.
3. Import actuals.
4. Run the scheduler.
5. Export the plan back.

Actuals must land before the reschedule, because a reschedule with stale actuals replans work that is already finished. That is the single most common sequencing mistake, and it produces a schedule the floor immediately recognizes as wrong, which costs trust that takes weeks to rebuild.

The full rhythm is in the weekly ERP sync routine; the higher-frequency version is in scheduling a nightly export and import routine.

Reconcile the counts, briefly

Every row produces exactly one outcome: Created, Updated, Reused, or Failed, with a result dialog showing the counts and a per-run log recording each row. For actuals, two checks are worth thirty seconds:

• Failed rows. Almost always a job number that does not exist yet, which means the order import ran after the actuals import or the order was closed in the ERP. A related case is a labor history that begins partway down the routing, covered in when your ERP labor file starts mid-routing.
• Total hours. Compare the sum of imported hours against the sum in your export. A clean multiple means a conversion factor; a partial figure means rows failed.

The six-check version for all imports is in the import reconciliation checklist.

When the ERP is not the right source

Importing labor transactions works well when the ERP's time collection is timely and accurate. It works badly when transactions are entered a week later from paper, because the schedule is then always reacting to stale information.

If that describes your shop, the alternative is capturing at the point of work rather than routing it through the ERP first. The kiosk approach covers it. The two are not exclusive: some shops capture on the floor for scheduling and keep the ERP transactions for payroll and costing, since the two systems need the data for different reasons and at different speeds.

What the schedule does with them

Once actuals are in, the engine plans around them: 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, all applied only to the work that remains. The EDGEBIC product overview maps the engine, and the ERP integration architecture shows where the actuals mask sits alongside the other four imports.

Bring a week of transactions

Export one week of labor transactions and one week of work orders and bring them to a demo. Watching a partially complete job reschedule from its actual resume point makes the behavior concrete faster than any description of it.