Global Shop to EDGEBIC: The Data Mapping Reference

Mapping Global Shop Solutions data into EDGEBIC is a column-mapping exercise rather than a development project: you export items, work centers, routings, open jobs, and optionally reported hours to Excel or CSV, 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 unit conversion and blank cells behave, and what every row outcome means when a run finishes.

EDGEBIC by User Solutions integrates with Global Shop through those masks rather than a certified connector, so nothing is installed inside the ERP and nothing enters its upgrade path. If you have not read the end-to-end version, start with the complete Global Shop integration guide. This post is the lookup table you keep open while building masks.

The load order

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

Two entity types have no ERP origin and are built from a spreadsheet you write yourself: 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). These two define the calendar every date is computed against, so they deserve ten careful minutes rather than five. Job shops running a partial Saturday should put it in the shift record rather than treating it as overtime nobody models, because a Saturday the engine cannot see is capacity you will keep discovering by accident.

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

Items to Product

Only the identifier is required. Everything else can arrive later through a second, narrower refresh file, because blank cells preserve existing values on an update run. Watch identifier formatting across exports: matching ignores case but not leading zeros or punctuation, so make every export render the identifier the same way.

Work centers to Workcenter

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

Number_Of_Instances is the highest-value column on the page and the one most ERP exports do not carry, because ERP data models generally describe a work center as a capacity figure rather than a count of machines. A cell of four identical machines imported with one instance produces a plan roughly four 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.

If your export expresses capacity as an available-hours figure that already embeds a machine count, do not carry that number into Capacity unchanged while also setting instances, or you will count the same capacity twice. Pick one representation: instances plus the shift calendar is the one the engine reasons about best.

One_Per_Day_Flag earns its keep in job shops more than anywhere else. A center with a long, messy changeover (a paint booth, an oven, a large fixture setup) is often run as one job per machine per day in practice, and telling the engine that produces a plan the floor recognizes rather than one that assumes three changeovers in a shift.

Machine pools have no export column

Planners think in pools of interchangeable machines, and EDGEBIC models that as a work center group. The membership is not a static assignment: a routing step bound to a group re-evaluates every member on each reschedule, 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 the machine they started on, because recorded work is never moved.

That efficiency factor matters in job shops where the pool is genuinely mixed: an older mill and a newer mill do the same work at different rates, and the factor is how the engine knows. None of it fits in an export column, so import the members as ordinary work centers and create the group inside EDGEBIC afterwards. The concept is defined in what a work center group is and the procedure is in how to create work center groups.

Routings to BOR

Op_Flag is the field people get wrong first. True means "this row is an operation running on a work center". False means "this row is a component consumed at this point in the routing". Mixing them produces a routing full of work centers that are actually parts, and it is visible immediately in the graphical designer.

Transit_Days is the outside-processing field. Model plating, heat treat, and anodize as an operation on a work center named for the vendor, and put the turnaround in transit days so the vendor week appears on the Gantt as its own block rather than as padding inside the step before it.

Why the import takes two passes

A routing cannot be written row by row, because step 10 must point at step 20 and step 20 does not exist yet. So the import runs in two passes. Pass one validates each row, resolves or creates the items 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 item so the routing renders connected. Check that visually after the first import: a routing missing its final link draws as a chain floating free of the item it builds.

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

Jobs to SalesOrder

Carry Job_Number if you possibly can. In a job shop the ERP job number is the word everybody uses on the floor, on the traveler, and on the phone, so a schedule that shows the same number needs no translation step. Customer_Name is worth carrying too: in make-to-order work the customer is often the fastest way a planner recognizes a job on the Gantt.

Reported hours to Actuals

Job number, work center id, and actual date are mandatory. Hours and pieces are both 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 explicitly ask for them to be cleared. Actuals import last, because each row has to find an operation on a job that is already scheduled.

Conversions, blanks, and zeros

Different columns in the same file can carry different factors, so a routing export mixing per-lot run times with per-changeover setup minutes lands correctly in a single run.

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 item file of 8,000 rows reporting Created 14, Reused 7,986 is the desired result rather than a failure. When counts look wrong, the per-run log file carries one line per row with the exact reason for every 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 certifications, work center group strategies, bottleneck anchoring, and lot streaming transfer batches. Those are configured once in EDGEBIC and then apply to every imported job afterwards. The EDGEBIC product overview maps the engine, and the ERP integration architecture explains why one mask design serves every ERP.

For the questions that come up before a project starts, see the Global Shop integration FAQ, and for the case that usually precedes the decision, Global Shop scheduling gaps and how EDGEBIC fills them. The Infor and Microsoft Dynamics references show how little the method changes from one platform to the next, and the ERP scheduling add-on page frames the category.