Replace Existing is the actuals import option that clears logged days your file does not mention for the operations it touches, making the imported file the complete record for those operations rather than an addition to what is already there. It is off by default, which means an import normally adds and corrects without removing anything you did not ask it to remove.
EDGEBIC by User Solutions offers it as a checkbox in the Import Options dialog for an actuals mask. This article defines the difference between the days a file covers and the days it is silent about, because that distinction is the whole option. For the daily records involved, see the sibling term daily hour breakdown.
How It Works
An actuals import is deliberately safe to re-run, and it achieves that with one rule that applies whatever the options say: the days a file carries are always overwritten with the file's values. They are not added to what is stored. Importing the same file twice leaves the same numbers, and importing a corrected file replaces the wrong ones. Nothing double-counts.
That rule covers the days the file mentions. It says nothing about days the file does not mention, and that is where Replace Existing comes in:
- Off, the default. Days not covered by the file are preserved exactly as they stand. The import is additive and corrective: it changes what it mentions and leaves everything else.
- On. Days not covered by the file are cleared for the operations the file touches. The file becomes the complete record for those operations.
The scope matters as much as the behavior. The option only reaches operations the file actually mentions. An operation absent from the file entirely is untouched either way, because there is nothing to define its record against.
A Concrete Example
Think of updating a wall calendar from a colleague's notes. Off is the colleague whose notes you copy onto the days they wrote about, leaving your own entries on the other days intact. On is the colleague whose notes you treat as the whole month, so you erase the days they did not mention because their silence means nothing happened.
At Acme Industries, JOB-2026-0107 on CNC-Mill-1 has four days logged: 20 Jul 8.0 h, 21 Jul 8.0 h, 22 Jul 6.0 h, and 23 Jul 4.0 h, the last of which an operator entered at the kiosk. A corrected file arrives covering three days only:
| Date in file | Hours | Replace Existing off | Replace Existing on |
|---|---|---|---|
| 20 Jul | 8.0 | stays 8.0 | stays 8.0 |
| 21 Jul | 7.5 | corrected to 7.5 | corrected to 7.5 |
| 22 Jul | 6.0 | stays 6.0 | stays 6.0 |
| 23 Jul | not in file | stays 4.0 | cleared |
Same file, same three corrections, and one day of kiosk-entered work either kept or removed depending on a single checkbox.
How EDGEBIC Uses It
The default is off because silence is ambiguous. A file that does not mention Thursday might mean nothing was worked on Thursday, or might mean Thursday was outside the export window, or might mean the source system does not hold that day at all. Only you know which, so EDGEBIC does not guess.
Turning it on is a statement that your source is authoritative for the operations in the file and that its silence is meaningful. That is a real and useful configuration for sites whose ERP owns actuals end to end, and it is the only way to get a stale day removed by an import rather than by hand.
It becomes dangerous exactly where two sources write to the same operations. Once stored, hours entered at the kiosk, typed in the Log Actuals screen, or loaded from a file are indistinguishable, so the option cannot protect one and clear another. Sites that run both a feed and floor logging either keep the two to separate scopes, in which case the option is safe because the kiosk-owned operations never appear in the file, or leave the option off and treat the feed as corrective.
The option is independent of the other actuals settings on the same mask. It decides which days the file governs, not whether operations are marked finished and not how a day's missing measure is derived.
For running the load, see how to import actuals from a file, and for setting the option on a saved mask see how to set import options for a mask. For where an entry came from, see what is an actuals entry source. Browse more definitions in the manufacturing glossary.
It is an option on an actuals import mask that clears the logged days your file does not mention for the operations it touches, so the imported file becomes the complete record rather than an addition to it. With it off, which is the default, days the file does not cover are preserved exactly as they were. Days the file does cover are always overwritten either way.
No. Actuals imports never double-count, because the days a file carries are always overwritten with the file's values rather than added to what is there. Importing the same file twice leaves the same numbers, and importing a corrected file fixes the earlier ones. Replace Existing addresses a different problem: hours logged on days your file is silent about.
When your source system is the authoritative record for the operations in the file and its silence is meaningful. If your system says an operation logged four hours on Tuesday and nothing else, and you want that to be literally true in EDGEBIC, Replace Existing enforces it. If your file is a partial feed and other days may have been logged at the kiosk or by hand, leave it off or you will erase them.
The option did exactly what it says, which is why it defaults to off. Your file did not mention that day for that operation, so the day was treated as not part of the record and cleared. Kiosk entries and hand entries in Log Actuals are indistinguishable from imported ones once stored, so the option cannot spare them. Recovery depends on what you still have. If the operator's punch history or a paper record survives, re-enter the day in Log Actuals, which is the fastest route for a small number of days. If you have the pre-import state from a backup you can compare and restore. Going forward, either extend the source feed so it includes every day EDGEBIC might hold for those operations, or turn the option off and accept that the file adds and corrects rather than defines. The second is safer for any site where the floor logs directly as well as through the feed.
You can, but only if the two never write hours to the same operations, and that is worth confirming before you rely on it. The clean split is by scope: if the ERP feed covers a defined set of work centers or jobs and the kiosk covers a different set, run Replace Existing on a mask whose file only ever contains the ERP-owned scope, and the kiosk-owned operations are never in the file so they are never touched. The option only clears uncovered days for operations the file actually mentions, so operations absent from the file entirely are safe. Where the split does not hold, and both sources log hours against the same operations on different days, Replace Existing will systematically erase whichever source did not appear in the last file. In that case leave it off and treat the feed as corrective rather than authoritative, then reconcile the difference in reporting instead of in the data.
Expert Q&A: Deep Dive
Q: We turned Replace Existing on and lost a day of hours an operator had entered at the kiosk. What happened and how do we recover?
A: The option did exactly what it says, which is why it defaults to off. Your file did not mention that day for that operation, so the day was treated as not part of the record and cleared. Kiosk entries and hand entries in Log Actuals are indistinguishable from imported ones once stored, so the option cannot spare them. Recovery depends on what you still have. If the operator's punch history or a paper record survives, re-enter the day in Log Actuals, which is the fastest route for a small number of days. If you have the pre-import state from a backup you can compare and restore. Going forward, either extend the source feed so it includes every day EDGEBIC might hold for those operations, or turn the option off and accept that the file adds and corrects rather than defines. The second is safer for any site where the floor logs directly as well as through the feed.
Q: Our ERP is the master for actuals but our operators also use the kiosk for pauses and reasons. Can we use Replace Existing at all?
A: You can, but only if the two never write hours to the same operations, and that is worth confirming before you rely on it. The clean split is by scope: if the ERP feed covers a defined set of work centers or jobs and the kiosk covers a different set, run Replace Existing on a mask whose file only ever contains the ERP-owned scope, and the kiosk-owned operations are never in the file so they are never touched. The option only clears uncovered days for operations the file actually mentions, so operations absent from the file entirely are safe. Where the split does not hold, and both sources log hours against the same operations on different days, Replace Existing will systematically erase whichever source did not appear in the last file. In that case leave it off and treat the feed as corrective rather than authoritative, then reconcile the difference in reporting instead of in the data.
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
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.