MIE Trak Pro to EDGEBIC: The Data Mapping Reference

Mapping MIE Trak Pro data into EDGEBIC is a column-mapping exercise rather than a development project: you export parts, work centers, routers, open work orders, and optionally labor hours to Excel, CSV, or a database view, then drag each source column heading onto the matching EDGEBIC field once and save it as a reusable import mask. This reference lists what maps to what, which columns are mandatory, how conversions and upserts behave, and what every row outcome means when a run finishes.

EDGEBIC by User Solutions integrates with MIE Trak Pro through those masks rather than a connector, so nothing is installed in the ERP and no integration credential exists to maintain. If you have not read the end-to-end version yet, start with the complete MIE Trak Pro integration guide. This post is the lookup table you keep open while building masks.

A note on column names: MIE Trak Pro grid and report output varies by version and configuration, so the source headings on your export may not match another shop's. That does not matter. You map headings to EDGEBIC fields once per mask, and the EDGEBIC target fields below are the stable side of the mapping. Where a source column is genuinely unclear, map only what you are sure of; unmapped columns are ignored.

The load order

Import in dependency order. Later files reference records that earlier files created.

Two entity types have no MIE Trak Pro origin and come from a spreadsheet you write: Shift (one row per shift with a start and end pair per weekday, a blank pair meaning the day is off) and PlantHoliday (closures by name and date). Together they define the calendar every scheduled date is computed against, which makes them the ten minutes with the widest effect in the whole load.

Auto-create is on by default, so a router file naming a work center that has not been imported yet creates it on the fly. Good safety net, poor strategy: an auto-created work center carries a name and nothing else, meaning one machine, no shift assignment, and no efficiency.

Reading the file itself

MIE Trak Pro exports have their own habits, and all of them are handled on the mask rather than by editing files.

If a worksheet is renamed later, the reader falls back to the first sheet rather than failing, which is forgiving but worth knowing: re-pick the file on the mask when a workbook's structure changes so the choice stays explicit.

Parts to Product

Only the part number is required. Everything else can arrive later through a narrower refresh file, because blank cells preserve existing values on an update run. Keep the part number rendered identically across every export: matching ignores case, so BRK-200 finds brk-200, but it does not reconcile a genuine spelling difference or a stray revision suffix.

Work centers to Workcenter

This is where scheduling accuracy is won or lost, because this file carries capacity.

Number_Of_Instances is the single highest-value column here and the one ERP exports rarely carry, because a work center is usually modeled as one resource with a capacity figure. A cell of three identical brake presses imported as one instance produces a plan roughly three times too long, and it fails quietly: nothing errors, the dates are simply wrong. Fill it deliberately for every multi-machine center; the arithmetic is in how EDGEBIC calculates work center capacity.

Machine pools have no export column

Where machines are genuinely interchangeable, EDGEBIC models a work center group: a named pool whose membership is re-evaluated on every reschedule. A router step bound to the group picks by strategy (earliest completion, primary first, or earliest start) and applies a per-member efficiency factor, so a slower machine is chosen only when it still finishes first. Operations already started keep their machine, because recorded work is never moved.

None of that exists as an export column. Import the members as ordinary work centers, then build the group inside EDGEBIC: a one-time configuration per pool that changes the schedule more than most imported columns do. The setup path is how to create work center groups.

Routers to BOR

Op_Flag is the field most often set wrong on a first load. True means the row is an operation running on a work center. False means the row is a component consumed at that point in the router, which is exactly how a subassembly is attached to its parent. Getting the flag backwards turns components into work centers, and the graphical designer shows it immediately.

Why the import takes two passes

A router cannot be written row by row, because step 10 must point at step 20 and step 20 does not exist yet. The import therefore runs in two passes. Pass one validates each row, resolves or creates the parts and work centers it names, and buffers the row. Pass two groups the buffer by end product, sorts by sequence number, writes the steps, and wires the chain: 10 to 20, 20 to 30, and the terminal step to the finished part so the router renders connected rather than floating free.

Two rules follow. All of one part's steps must travel in one file, because a run wipes and recreates that part's steps on first reference, so splitting one part across two runs means the second wipe deletes the first run's work. And re-importing is safe for work orders in progress, because every scheduled job carries a frozen snapshot of the router it was planned with.

Work orders to SalesOrder

Two mask options handle the case where an export carries only one date: one treats the job date as the due date, the other derives the job date backward from the due date. Set whichever matches your export once, on the mask. Carrying the MIE Trak Pro work order number into Job_Number keeps the reference your floor already recognizes on a dispatch list, which matters most on the AOG and hot jobs everyone is asking about.

Labor to Actuals

Job number, work center id, and actual date are mandatory. Hours and pieces are each optional, and either can be derived from the other using the operation's rate. A Complete column marks the operation finished, and an explicit start column overrides the default of using the earliest imported date.

The import always overwrites the days a file carries, so re-running a corrected extract fixes the numbers rather than doubling them. Days a file does not mention are preserved unless you ask for them to be cleared. Actuals go last because every row has to find an operation on a job that is already scheduled.

Conversions, blanks, and zeros

Reading the outcomes

Every row resolves to Created, Updated, Reused, or Failed. Reused is the default for a record that already exists, so a weekly parts file of 3,000 rows reporting Created 9, Reused 2,991 is the desired result rather than a problem. When counts look wrong, the per-run log file has one line per row with the exact reason for each failure.

What import cannot bring, and why it matters

The settings that most differentiate a schedule have no column in any ERP export: the sequence-dependent setup matrix, operator skills and rosters, work center group strategies, bottleneck anchoring, and lot streaming transfer batches. They are configured once in EDGEBIC and then apply to every imported work order afterwards. The EDGEBIC product overview maps the engine, and the ERP integration architecture explains why one mask design serves every platform.

For the questions that come up before a project starts, see the MIE Trak Pro integration FAQ. The SYSPRO and Made2Manage references show how little changes from one platform to the next, and the ERP integration hub frames the category.