To correct a wrong actual date in EDGEBIC by User Solutions, open the operation's Edit Actual Dates dialog, type the right value, and save. The correction replaces the old value and lands in the operation's history with who changed it and when. Then reschedule, because actual dates are what the engine treats as reality and downstream work will keep queueing behind the wrong one until a run happens.
If you are still working out whether the dates are actually wrong, start with actual dates look wrong, which is the diagnosis. This post is the fix.
Before You Start
| Prerequisite | Why |
|---|---|
| You know the real dates | A guess corrected to another guess helps nobody; check the paper record or the punch history first |
| The job is not marked complete at order level | A completed job locks actuals entry until it is reopened |
| You are prepared to give a reason | Editing values that were already reported requires one, and an empty reason cancels the save |
Step 1: Open the Edit Actual Dates Dialog
Three routes reach the same dialog.
| Route | Where |
|---|---|
| Double-click the Actual Start or Actual End cell | The Job View grid row |
| Right-click the operation's bar and take the Edit Actual Dates option | The Schedule View Gantt |
| Click Log Actual Dates from inside the dialog | The Log Actuals dialog, when you are already in it |
The dialog carries Actual Start and Actual End fields plus the one-click helpers: Start = Now, Use Sched Start, End = Now, Use Sched End, and Clear.
Step 2: Type the Corrected Value
Enter the real date and time. Two rules govern what will be accepted.
- The end must be strictly after the start. An inverted pair is refused at every entry point, in both directions. Moving a start past an existing end fails, and so does moving an end back before an existing start.
- Correcting a system-filled day makes it yours. A day that was auto-filled from plan loses its badge the moment you type over it, and the value becomes a normal hand-entered one.
Step 3: Handle an Inverted Pair
If the correction is refused because both ends are wrong, do it in two moves rather than fighting the validator.
- Clear the value that is blocking you (usually the actual end).
- Set the corrected start.
- Set the corrected end.
The same sequence fixes the classic same-day inversion, where an end sits at midnight on a step that started at 08:00. If you clear the end and complete the operation without giving an explicit time, it snaps to 23:59 of the last day with logged hours and the inversion cannot recur.
Step 4: Give a Real Reason
When you change values that were already reported, a reason is required and it is stored in the operation's logging history alongside the old value, the new value, and your name. Write the sentence a colleague could use six months from now. "Operator tapped complete an hour early, corrected from the time study sheet" beats "fix" by a distance that will matter during an audit.
Step 5: Reschedule
Correcting the date changes the record. It does not move the plan. Run the targeted Re-Schedule for that job so downstream steps re-queue behind the corrected resume point.
What Changes When You Save
| Surface | Effect |
|---|---|
| The operation's actual dates | Replaced with your values |
| Logged daily hours and pieces | Untouched: dates and hours are edited independently |
| Provenance | A system-filled row flips to user-entered |
| Logging history | The old value, the new value, your name, and the reason are appended |
| The Gantt bar | Moves to the corrected actual position |
| The next reschedule | Downstream steps re-plan from the corrected date |
How to Check It Worked
Read the operation's row in the Job View grid and confirm both actual columns show what the floor reported. Open View History in the Log Actuals dialog: your correction is there with the old and new values and your reason. After the reschedule, open Job Audit and confirm the newest event shows the job's old and new start and end together. Finally run the anomaly report and confirm the inverted-dates check comes back empty. What the anomaly checks actually look for explains each one.
Common Mistakes
- Correcting only one end of the pair. A start moved without its end produces a step whose duration is now fiction, even though both values pass validation individually.
- Correcting the parallel sibling row. A routing step on parallel work centers shows a primary and a sibling. Edit the primary. The sibling mirrors it at save time, and a direct sibling edit is overwritten on the next save anywhere on that job.
- Leaving the reason blank. The save cancels, and people then assume the correction landed.
- Forgetting the reschedule. The dates are right, the promise date is still wrong, and the customer hears the old one.
- Fixing dates when the real problem is a wrong completion. If the step is not finished at all, reopen it rather than moving the end date around. See how to reopen a completed operation.
Next Steps
If the whole day's hours are wrong rather than the dates, how to enter actual hours for yesterday covers back-dated entry. If the correction came out of an audit question, how to see who changed a schedule shows the trail. For the pattern-level view of what goes wrong, read actuals logging mistakes.
Every task in this library is indexed on the EDGEBIC how-to hub. Bring a job with dates you do not trust to a demo of EDGEBIC and we will correct them on screen.
Expert Q&A: Deep Dive
Q: Hours and dates were both logged against the wrong job. What is the correct unwind order?
A: Empty the wrong job completely before you touch the right one, otherwise you end up debugging two half-corrected jobs instead of one. On the wrong job: zero every actual hours and pieces cell in the Log Actuals grid and save without marking complete, then clear the actual end if one exists, then clear the actual start. Now the wrong job carries no actuals at all and reads as not started. Move to the real job: set the actual start, enter the hours on the correct days, and complete it if the work is genuinely finished. Reschedule at the end, once, rather than after each step.
Q: Someone patched dates straight into the database. Why does the planner screen still disagree?
A: Screens hold the state they loaded. Click Refresh on the Job View for the affected job and the corrected values appear. What you have lost is the validation: direct edits bypass the check that refuses an end before a start, so an inverted pair can exist that the application would never have accepted. So verify before you trust it. Confirm the dates read correctly in the Job View, then run the anomaly report and look at the check for inverted actual dates specifically. Only then run the single-job reschedule so the engine reclassifies against the new values. See [how to run and read the anomaly report](/blog/how-to-run-and-read-the-anomaly-report-in-edgebic).
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
How to Create a Watched-File Integration in EDGEBIC
Create a watched-file integration in EDGEBIC: point it at the file your ERP drops, pick the target entity and import mask, set the debounce, and let a new file trigger the run.
How to Rehearse an Integration With the EDGEBIC Simulator
Use the built-in Simulator to provision demo data, watch real integration runs happen, and prove the mechanism before you point anything at a live ERP. Includes the tear-down rule.
How to Run an Integration Now and Pause All Schedules in EDGEBIC
Force one integration to run with Run Now, cancel a run in progress, disable a single definition, or tick Pause all schedules to stop every automatic sync for the session.