8 Customer and Department Setup Mistakes in EDGEBIC

Reference data mistakes do not throw errors. They just make the screens lie. In EDGEBIC by User Solutions, customers, departments, units of measure, and categories sit outside the scheduling math almost entirely, which means a misconfiguration here shows up as a number that looks plausible and is not. Here are eight that recur, with the symptom that gives each one away.

For what these records do, read customers, departments and units of measure explained. For the setup sequence, see how to organize departments and plants.

1. Deleting a customer instead of deactivating them

Symptom. Three jobs on the schedule with a blank customer column. A quote still shows the account name in its text fields.

Cause. Someone deleted the customer during a cleanup. Deleting unlinks rather than cascades, which is the safe behavior from the schedule's point of view: the orders, quotes, and sales orders all survive and keep scheduling. What is lost is the association.

Fix. Re-create the customer, then edit each affected order and re-select them in the customer dropdown. Prevent it by unticking the active flag instead, which hides the customer from new-order and quote dropdowns while every existing link stays intact. Keeping master data forever and using active flags is standard ERP practice, and this platform supports exactly that.

Before deleting anything, open the customer's order history dialog. It lists every manufacturing order and quote for that account in two tabs, so you can see precisely what you are about to unlink. The delete confirmation itself does not itemize them.

2. One customer, several records

Symptom. Delivery-performance reports split an account across three rows. Nobody can answer "what have we shipped Acme this year" in one number.

Cause. Someone created a separate customer record per site, per division, or per contact.

Fix. One record per legal entity. Model sites with the address fields or notes, not with duplicate records. If the split already exists, there is no automatic merge: re-point each order and quote to the record you are keeping, then deactivate the duplicates. Doing it once is tedious. Doing it after two years of history is a project.

3. Stale credit limits producing permanent noise

Symptom. A validation warning about the balance exceeding the credit limit on every single save of a customer record. Everyone clicks through it without reading.

Cause. Credit limit and current balance are informational fields that nobody is maintaining. The check compares two numbers that were imported once and never updated.

Fix. Either maintain the balance from your accounting system, or set the credit limit to zero, which disables the check entirely. What you should not do is leave a warning firing on every save, because a warning that always fires trains people to ignore warnings that matter. The limit never blocks an order in any case; it exists to inform the person entering it.

4. Expecting department status to stop production

Symptom. A department was set to Maintenance for a shutdown and jobs kept being scheduled on its machines all week.

Cause. Department status is informational. The card turns amber and the summary tiles update, and the engine keeps booking work centers exactly as before, because it allocates capacity on work centers and never reads the department.

Fix. Two steps for any real shutdown:

1. Set the department status so people see it on the card.
2. Add holidays or downtime on each affected work center so the engine sees it.

Skip the second and the schedule promises work on a torn-down line. If a job still lands somewhere it should not, the job scheduled on a holiday troubleshooting post walks the calendar precedence.

5. Letting department capacity numbers go stale

Symptom. A utilization bar reading zero percent on a department that is flat out, or a comfortable green bar on an area everyone knows is overloaded.

Cause. Department capacity hours and planned hours are planner-maintained planning figures. Neither is recalculated when a job is scheduled or completed, so a denominator set once at implementation stops meaning anything within a period or two.

Fix. Recompute capacity at the start of each planning period, derived as instances times shift hours per day times working days, adjusted for holidays and known downtime. Set planned hours from the committed queue. If your organization will not commit to that rhythm, then read the live parts of the card instead: the work center count, the per-work-center utilization rows, and the bottleneck chips are all current at all times. The full breakdown is in department capacity analysis.

6. Reading the average instead of the constraint

Symptom. Plant-wide average utilization reads 62 percent, there are hundreds of available hours on paper, and dates keep slipping.

Cause. An average across departments hides the only number that governs throughput. One saturated machine sets the plant's output regardless of how idle everything else is.

Fix. Read the department cards bottom-up: bottleneck chips first (live), per-work-center rows second (live), the department bar last (maintained). Then open the constrained work center itself. The department layer is a period-level lens and it aggregates away exactly the detail a constraint problem needs. Bottleneck identification and the anchor scheduling example cover what to do once you have found it.

One more detail on the arithmetic: average utilization is a mean of department percentages, not a weighted plant figure. Three departments at 65, 55, and 66 percent average to 62.0 whatever their relative sizes. When departments differ materially in size, read the totals row instead.

7. Department codes with spaces, and duplicate codes

Symptom. A save is rejected with a message that the department code can only contain letters, numbers, dashes, and underscores. Or a save is rejected because the code already exists.

Cause. The code validator accepts letters, digits, dashes, and underscores only, and enforces uniqueness.

Fix. Use short structured codes: MCH-01, FAB-01, PAINT-EU. Not MCH HOU. Establish the convention before you create the first department, because renaming codes later means updating whatever you have exported them into.

8. Mismatching unit of measure and work center capacity type

Symptom. A schedule that is dramatically too long or too short for a piece-based operation. A 400 square metre paint job showing 400 hours of booth time.

Cause. A unit of measure carries a scheduling behavior of hours, pieces, or both. A work center carries its own capacity type. When they disagree, the work center's capacity type is what the engine follows, and the unit's behavior is only a configuration signal.

Fix. Set them consistently. A booth producing 20 square metres per hour needs a piece-based capacity type, so a 400 square metre order resolves correctly:

Hours required = 400 ÷ 20 = 20 hours

Treat 400 as hours instead and the schedule is twenty times too long. Reverse the error and it is twenty times too short. This is the one place in reference data where a mistake changes the schedule rather than just the reporting.

Two smaller ones worth naming

A work center vanishing from a department card is not a loss. A work center belongs to one department at a time, so ticking it elsewhere moves it. Nothing about the work center changes and no job moves, because the engine does not read departments. Re-tick it where it belongs, and check whether the other department's capacity figure assumed it was a member.

Product categories have no hierarchy and no uniqueness constraint. Two categories can share a name or a code. If you need sub-categories, use a naming convention such as Metal/Ferrous and keep the list short. The product list groups by category by default, so a sprawling category set makes the catalog harder to read rather than easier.

Finding these before they matter

Three habits catch most of the list:

None of these takes long, and each one prevents a class of number that looks right and is not. For the platform overview, read the complete EDGEBIC guide, and for a plant standing up from scratch the greenfield walkthrough shows the reference data in its proper sequence. The product hub has the full feature map.