JobBOSS to EDGEBIC: The Data Mapping Reference

Mapping JobBOSS data into EDGEBIC is a column-mapping exercise, not a development project: you export parts, work centers, routings, open jobs, and optionally actuals 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 each row outcome means when the run finishes.

EDGEBIC by User Solutions integrates with JobBOSS through those import masks rather than a certified connector. If you have not read the end-to-end version yet, start with the complete JobBOSS integration guide; this post is the lookup table you keep open while you build the masks.

The five files and their order

Import in dependency order. Later files reference records the earlier ones created.

Two more entity types matter for a first load but do not come from JobBOSS: Shift (your working calendar, one row per shift with a start/end pair per weekday) and PlantHoliday (plant-wide closures by name and date). Build those from a plain spreadsheet you write yourself.

Parts to Product

The one column you cannot skip is the part number. A blank part number cell fails that row with a recorded reason and, by default, the run continues through the remaining rows.

Work centers to Workcenter

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

Number_Of_Instances is the field most JobBOSS exports do not carry, because ERPs typically model a work center as one capacity number rather than a count of machines. Fill it by hand for any center that is really a cell of three or four identical machines. Getting it right is the difference between a plan the shop can run and a plan that quietly assumes one mill does the work of four. The general principle behind that is covered in finite versus infinite capacity scheduling.

Routings to BOR

Op_Flag is the field people get wrong first. A true value says "this row is an operation running on a work center". A false value says "this row is a component consumed at this point in the routing". Mixing them up produces a routing full of work centers that are actually parts, and it shows up immediately in the graphical designer.

How sequence wiring actually happens

A routing import runs in two passes, because step 10 cannot point at step 20 before step 20 exists. Pass one reads and validates every row, auto-creates any part or work center the file names that is not in EDGEBIC yet, and buffers the rows. Pass two groups the buffered rows by end product, sorts them by sequence number, writes them, and then wires the chain: 10 to 20, 20 to 30, and the terminal step to the finished product so the routing renders as one connected flow.

That last link matters more than it sounds. Without it, the routing designer draws a chain of operations floating unconnected to the part they build. Keeping the automatic chaining option on (it is on by default) and leaving Next_Seq blank produces the connected version every time.

Open jobs to SalesOrder

When Sales_Order(Ref#) is filled, all rows sharing a reference group under one sales order and their jobs auto-number as {Ref}-{line}. Multi-line orders therefore stay together instead of scattering into unrelated jobs. Rows with a blank reference each become a standalone job.

Actuals

An actuals row can only find its home if the job is already scheduled, which is why actuals come last. The import always overwrites the days the file carries, so re-importing the same file never double-counts and a corrected timesheet file simply fixes the earlier numbers.

Conversion factors

The factor lives on the mask row, applied before the value is stored. Non-numeric cells pass through untouched.

Blank cells, zeros, and re-imports

Three behaviors govern every re-import, and they are worth memorizing:

• On an update, a blank cell preserves the existing value. A price-refresh file carrying only part number and price changes prices and nothing else.
• A zero is a value, not a blank. A column full of zeros writes zeros. Leave a column out of the file rather than filling it with zeros you do not mean.
• A routing re-import wipes and recreates that part's steps. Every run is therefore idempotent: steps never accumulate. It is also safe for running jobs, because each scheduled job carries a frozen snapshot of the routing it was planned with. This is the same protection described in the reschedule behavior posts: completed work is never moved.

Reading the outcomes

The result dialog shows the counts. The per-run log file records every row with its outcome and, for failures, the exact reason, which is where you go when a summary count looks wrong.

What does not come from JobBOSS

Some of EDGEBIC's strongest scheduling inputs have no JobBOSS equivalent and are configured directly: work center groups (machine pools that re-shop on every reschedule), the sequence-dependent setup matrix, operator skills and certifications, and bottleneck anchoring. Import gets the skeleton in; those settings are what make the plan match the floor. The EDGEBIC product overview maps the engine, and the ERP integration architecture page covers how the same mask approach works across every ERP.

Once the masks exist, the recurring cost drops to minutes. That rhythm is the subject of the daily JobBOSS and EDGEBIC scheduling workflow, and the questions shops ask before they start are collected in the JobBOSS integration FAQ.