Scheduling a Nightly ERP Export and Import Routine for EDGEBIC

A nightly or weekly ERP export and import routine keeps the EDGEBIC schedule current by having the ERP produce fresh files on a timer, then importing them through saved masks in a fixed order and running the scheduler once, with the per-run counts read before anything reaches the floor. The routine is repeatable by design: master data that already matches comes back untouched, routings re-import idempotently, and work in progress is never disturbed.

EDGEBIC by User Solutions integrates with every ERP through the same file-based masks, so the routine below is identical whether the files come from SAP, QuickBooks, or a job-shop system. This post is the operational how-to for making that refresh a reliable habit rather than an occasional scramble. The architecture behind it is in why EDGEBIC connects to every ERP the same way.

The two halves of the routine

Separate the routine into a part the ERP can automate and a part a person should own.

• Export (automatable). Most ERPs can save a report or list to a file on a schedule. Point those saved exports at a known folder and let them run overnight so current items, routings, and open orders are waiting each morning.
• Import and schedule (person-owned). Importing changes data and scheduling changes the plan. You want a human to read the counts and decide before the floor receives a new sequence. This half is a few minutes of clicks, not an all-day task.

Keeping the second half manual is a deliberate control, not a limitation. An unattended process that both imports and reschedules could silently rearrange the shop overnight; the split prevents that.

The import order

Run the masks in dependency order so the logs stay clean and a bad file is obvious:

1. Items first, so downstream data has products to attach to.
2. Work centers next, so routings have resources to reference.
3. Routings next. The two-pass routing import auto-creates any item or work center it names that is missing, so strict ordering is not mandatory, but running items and work centers first keeps the routing log free of incidental creations.
4. Open orders last among the core files, because they are the demand the scheduler consumes.
5. Actuals optionally, if you feed logged hours back so the reschedule starts from where jobs really stand.

Then, and only then, run the scheduler. Imports never schedule anything; imported orders sit as unscheduled demand until you run the engine, which states how many jobs are new and how many are being rescheduled before it plans.

Why re-running is safe

The routine is built to be run repeatedly:

• Reused means untouched. Master data that already matches an existing record comes back Reused, not rewritten, so re-importing an unchanged item list is a no-op that clears in seconds.
• Routings re-import idempotently. A routing import wipes and recreates only that product's steps once per run, so importing the same routing file twice leaves the same result, not doubled steps. Keep all of one product's steps in one file so the wipe-and-recreate stays whole.
• Work in progress is frozen. Every scheduled job carries a snapshot of the routing it was planned with, so a routing change applies to future jobs and leaves running work untouched.
• Blank cells preserve values. On an update run, a blank cell keeps the existing value, so a partial refresh file is safe. A zero, though, is a value, so leave a column out rather than filling it with zeros you do not mean.

Reading the counts

Every run ends with a result dialog and a per-run log. Read the counts before you trust the schedule:

• A high Reused count is normal and good. It means most master data already matched.
• An unexpected Failed count is your signal. Open the log; each Failed row records the exact reason. A common cause is a date format or a quoted-text setting that needs adjusting in the mask, not in the file.
• A surprisingly low Created count on a file you expected to add rows often means an export came out short. Re-export that one file rather than proceeding. When a scheduled export does not land at all, what to do when the ERP export is late or missing covers why yesterday's plan is still safe to work to and how to catch up cleanly.

Because failures isolate at the row level, one bad date never blocks the rest of a file, and one bad file never blocks the other masks.

A weekly rhythm that scales to nightly

Most shops start weekly and tighten from there. A weekly run looks like this:

Moving to nightly changes only the cadence, not the steps. The saved masks and the import order are unchanged; you simply run them more often. For the full weekly walkthrough see keeping ERP and EDGEBIC in sync, and for the exact fields each file should carry see which ERP fields EDGEBIC needs to schedule.

Sending the plan back

The routine closes by exporting the finished schedule. The Job View grid and every report export to Excel or PDF using your saved column layout, and revised dates go back into the ERP through your normal order maintenance path. The mechanics of that return trip are covered in exporting the EDGEBIC schedule back to your ERP. The EDGEBIC product overview maps the engine that produces the plan, and the ERP integration architecture shows where this routine fits.

Make it a habit, not a project

The whole point of a saved routine is that it stops being a decision. Once the masks exist and the import order is fixed, the refresh is muscle memory: files land, masks run, counts read, scheduler runs, plan exported. Bring a week of your own exports to a demo and build the routine live, so you leave with the masks already saved.