Why an Operation's Actual Start Is Written Once

An operation's actual start in EDGEBIC by User Solutions is written once: whichever source records it first owns it, and the other source will not overwrite it. That single rule is the quietest piece of actual start date scheduling behavior in the product, and it is the reason two independent people reporting the same job cannot corrupt when it began.

It is also the one rule in this area that behaves differently from everything around it. Daily hours can be typed over. An actual end can be cleared and re-stamped. The start alone is protected, and it is worth understanding why before you meet the behavior in the middle of a correction.

What the Actual Start Is Actually For

The start is not decoration on a Gantt bar. It does three specific jobs.

It sets the operation's state. An operation with no actual start is not in progress; it is planned work the engine is still free to move. The moment a start exists, the bar moves to its actual position and the operation enters the in-progress zone, where the next reschedule keeps what has been logged and re-plans only what remains. See planned, in-progress, and completed work explained.

It anchors the resume point. Rescheduling plans the remaining work forward from where work really reached, and the start is the earliest fixed point in that calculation. See how a reschedule uses last night's actuals.

And it feeds the job's roll-up. The job's reported actual start is the start of the first operation to begin, so an error on the first operation misreports the beginning of the whole job. See rolling a job's actuals up to the end product.

A value doing three jobs of that weight is a poor candidate for silent overwriting.

Two Sources, No Arbitration

There are exactly two ways an actual start comes into existence, and neither is aware of the other's intent.

A planner sets it in the Edit Actual Dates dialog, which opens automatically the first time Log Actuals is used on an operation with no start yet. Start = Now stamps the current moment; Use Sched Start copies the planned start when work truly began on time; a typed value covers everything else. See logging actuals from the planner.

An operator sets it by tapping Start Run at the terminal, at which point the run punch opens and the start is stamped, provided nobody has recorded one already. See how the kiosk captures a production punch.

Now imagine the rule were last-write-wins, the way daily hours are. A planner records Monday 08:00 because that is when the job genuinely began. On Wednesday an operator who has been running the job all along finally taps Start Run for the first time, and the operation's start becomes Wednesday. Two days of real work now sit before the operation officially began, the in-progress state was recomputed from a false anchor, and nobody typed anything wrong.

First writer wins avoids all of that at the cost of one thing: a genuinely wrong start has to be corrected on purpose. That is an acceptable trade, because a correction is visible and an overwrite is not.

How the Three Fields Compare

Read down the last row and the design becomes coherent. Hours are expected to be corrected, so correction is frictionless. Completion is a decision, so it can be reversed. The start is a historical fact that other calculations lean on, so it resists being changed by accident.

Where the Kiosk Stamp Lands, and Why It Matters

The stamp goes on at the first Start Run, not at Start Setup, and the distinction has practical consequences worth knowing.

The setup ribbon runs first, stepping through its phases with each one timed separately. Only when the last phase's advance button reads Start Run does setup close, the run punch open, and the actual start get written. So a changeover that takes fifty minutes sits entirely before the operation's actual start.

That setup time is not lost. It lives in its own punches, stays out of production hours, and feeds setup variance reporting against the routing's standard. See how setup phases become setup variance and how punches roll up into daily actual hours.

What it means for a supervisor reading a bar is this: an actual start later than the scheduled start does not necessarily mean the operator was late. It may mean the changeover ran long, which is a different problem with a different owner. The setup punches are where you tell those two apart, and reading the start alone will mislead you.

What Setting the Start Triggers

The start is also a gate, in the sense that other things only become possible once it exists, and knowing what they are makes the sequence feel less arbitrary.

Daily hours cannot be logged before it. The Log Actuals dialog opens with one row per calendar day of the operation's window, and the window has to begin somewhere, so on an operation with no start the Edit Actual Dates dialog opens first and asks for one. That is why the start feels like a hurdle on the first entry and never again.

Setting it is also where the prior work centers handshake fires. If earlier operations in the same job have no actuals yet, a prompt lists them and explains that continuing will auto-log their planned values as actuals, tagged as system filled. Canceling stops so the earlier steps can be reported properly, which is the honest path; accepting lets a guess stand in a visible, badged form. See the prior step actuals gate at the kiosk and the auto-filled actuals badge explained.

And it is the moment the bar changes on the Gantt. The operation moves to its actual position and reads as started, which is the visual cue a planner scanning a board relies on rather than opening each job.

Correcting a Start, Properly

Because nothing will overwrite it, a wrong start is corrected by hand, and the path is short.

Open Edit Actual Dates on the operation. Clear sits beside the one-click Start = Now and Use Sched Start options, so you clear the wrong value and set the real one. Save. Two checks afterward are worth the seconds.

Check the daily grid. If the correction moved the start earlier, the operation's window may now cover days that were previously outside it. That is usually right, and it may mean there are real hours to log on the earlier days.

Check the job header. If the operation you corrected was the first to begin, the job's reported actual start was wrong too, and it now recomputes.

The wrong instinct is to leave a bad start alone on the grounds that hours are what matters. Hours are what the progress bar reads, but the start is what the reschedule anchors on, so a start two days late understates the operation's elapsed span and can push the plan's forward view around.

Practical Guidance

Three habits keep this rule from ever becoming visible as a problem.

Set the start from the truth, not the convenience. Start = Now is a one-tap convenience for work that is genuinely starting now. On a catch-up entry for a job that began yesterday, Use Sched Start or a typed value is the right answer, and it costs ten seconds.

Decide the primary reporting door per work center. Most start conflicts trace back to a machine where both the floor and the planner report whenever they get round to it. Naming one primary and one fallback removes the ambiguity entirely: see who should log actuals, the operator or the planner.

Treat a late first punch as a reporting gap, not a start. If an operator punches on for the first time on the third day of a job, the punch is welcome and the run hours are real, but somebody needs to set the start correctly for the earlier days. The kiosk will not do it, and it should not.

None of this is guesswork about intent. The one-time rule exists so that a value three other calculations depend on cannot be moved by a well-meaning tap, and so that changing it is always somebody's decision. See why actuals are immutable in EDGEBIC for the wider principle the rule belongs to.

The takeaway

An actual start is a historical anchor, not a status field, which is why the first source to write it owns it. Understand that the kiosk stamps it at Start Run rather than Start Setup, that hours and ends follow different rules on purpose, and that a wrong start is fixed deliberately in Edit Actual Dates rather than by another punch. Get the start right and every forward calculation that leans on it stays honest. Explore the platform at EDGEBIC, see the upgrade path in RMDB to EDGEBIC, and read on in the end-of-day actual end snap explained and logging actuals from the planner.