The Daily JobBOSS + EDGEBIC Scheduling Workflow

The daily JobBOSS and EDGEBIC routine is four moves and roughly twenty minutes: export open jobs and actuals from JobBOSS, run the saved import masks, run the scheduler once, and export dispatch lists and dates back. Nothing about it is a project. Once the masks exist, the recurring cost is a planner's coffee-length morning ritual, and the part that takes the longest is reading the result rather than producing it.

EDGEBIC by User Solutions sits beside JobBOSS rather than replacing any part of it. JobBOSS keeps order entry, purchasing, costing, and financials. EDGEBIC owns the sequencing question, which is the one that needs finite capacity. If you have not set up the masks yet, the complete JobBOSS integration guide covers the build and the JobBOSS mapping reference lists the fields.

The shape of the morning

A workable clock for a shop that starts at seven:

Those times are a shape, not a promise. A shop with 40 open jobs finishes faster; a shop with 400 spends more time in the review step, which is the right place to spend it.

Move one: the export

Only two things genuinely change every day: open jobs and shop-floor actuals. Everything else changes on its own slower cadence.

Set the JobBOSS side up once as saved reports that write to a known folder with stable file names. The masks remember the last file path, so a stable name turns the import into two clicks instead of a file-picker hunt. This is the only step where IT is worth involving, and it is a one-time job.

Running master-data masks daily is harmless (existing records come back Reused and untouched) but it is work nobody needs to do.

Move two: the imports

Select the mask, click run, read the result dialog. A mature shop's daily orders import looks something like Created 9 · Updated 0 · Reused 214 · Failed 0. That is the healthy shape: nine genuinely new jobs, 214 already known and deliberately untouched, nothing broken.

Three readings matter:

• Reused is success, not inaction. The default for a matching record is to leave it alone. That is what makes a daily re-import of the same file safe.
• A non-zero Failed count is a five-second question, not an emergency. Open the per-run log, which records every row with the exact reason. Nearly always it is a blank required cell or a date the file wrote in a format the row could not parse.
• Counts that surprise you are the real signal. Forty Created rows on a Tuesday usually means the export ran with the wrong date filter, not that forty orders arrived overnight.

Then the one rule that governs the whole workflow: imports change data, never the plan. Newly imported jobs sit as unscheduled demand. Nothing lands on the Gantt until you run the scheduler. That separation is deliberate, and it is why an import can never quietly rearrange the floor while your back is turned.

Move three: actuals in

Two paths, and most shops use both. Operators record hours and piece counts at a shop-floor kiosk as the work happens, which keeps the plan honest hour by hour. Anything the kiosk does not cover (a JobBOSS labor export, a data-collection extract, a supervisor's spreadsheet) comes in through the actuals import: one row per job, work center, and day.

The actuals import is built to be re-run, because corrected timesheets are a permanent fact of shop life. The days a file carries are always overwritten with the file's values, so importing the same file twice never double-counts and importing a corrected file simply fixes the earlier numbers. Days the file does not mention stay as they are.

The payoff arrives in the next move: remaining work replans from where the shop actually stands, and completed work stays exactly where reality put it.

Move four: the scheduler run

Tick the jobs you want planned, or tick none and accept the offer to include everything. A confirmation dialog then states the run in plain numbers before anything happens: how many jobs are being scheduled for the first time and how many existing jobs are being rescheduled. Read it. It is the cheapest blast-radius check in the product.

The run shows a progress overlay while it works, and cancelling is always safe: nothing partial is kept and your previous plan stands. Jobs you did not select keep their plans, and the capacity they already reserved is respected by everything planned around them.

Two guarantees are worth stating plainly because they are what makes a daily cadence tolerable:

1. Completed work never moves. No run, no setting, no mode will shift or recompute an operation that already has an actual start and end.
2. Scheduled jobs run on the routing they were planned with. Each carries a frozen snapshot, so a routing re-import changes future jobs and leaves work in progress alone. That mechanism is explained in why a job jumps after a reschedule.

Move five: read the result before you publish it

The schedule grid answers the morning's real questions in five columns: status, start date, first operation start, job end, due date, and days late. Days late is a projection, not a complaint: it means the current plan's end date lands past the due date. A positive number on a job due next week is the system telling you something now rather than in six days.

The review that takes ten minutes and saves the week:

• Scan days late. Anything positive is a decision (re-sequence, overtime, a moved promise), and the decision is cheaper today than Thursday.
• Check the bottleneck's load. If it is over 100 percent on a day, everything downstream is fiction. Bottleneck identification covers what to do about it.
• Look at what moved since yesterday. Jobs that jump usually jump for a documented reason: an actual that ran long, a capacity change, a higher-priority job inserted ahead.

Move six: dates and dispatch lists out

The return trip is Excel. The Job View grid exports the job schedule as a workbook with colored cells and a legend sheet. The work center schedule exports the same way. Every report dialog exports to Excel or PDF with the column layout you saved, so a dispatch list is a saved report you run, not a document you build.

From there, updated promise dates go back into JobBOSS through the same date-maintenance path your order-entry process already uses, and the dispatch lists go to the floor. JobBOSS workflows do not change; they just receive dates the shop can hit.

Who does what

That table is the honest measure of the integration approach. A workflow that needs IT every morning does not survive its second month.

The weekly and monthly extras

Daily is the loop. Two slower cadences keep it accurate. Weekly: reconcile EDGEBIC's dates against the promises in JobBOSS, and tune anything that disagrees (shift calendars, instance counts, setup times). Monthly: refresh parts and work centers, review which work centers are actually the constraint, and check whether the setup matrix still matches how the shop sequences work.

The rest of the engine (work center groups, sequence-dependent setups, lot streaming, optimization with a proven optimality gap) sits underneath all of this without adding a daily step. The EDGEBIC product overview maps it, and the ERP integration architecture shows how the same rhythm runs against any ERP. For a shop's first week rather than its hundredth day, read a JobBOSS shop's first week with EDGEBIC.