Customers, Departments and Units of Measure in EDGEBIC

Customers, departments, units of measure, and product categories are the reference records that give a schedule its context rather than its constraints. In EDGEBIC by User Solutions none of them changes how the engine allocates capacity, with a single exception noted below. They decide what you can filter, group, roll up, and report on, and they are the difference between a schedule that answers "when does Acme's order ship" and one that only answers "when does job 0101 ship."

This is the overview. For the hands-on setup see how to organize departments and plants, for the capacity math see department capacity analysis, and for the failure modes see customer and department setup mistakes.

Customers: traceability, not scheduling

A customer is the business partner who orders your products, the demand side of every job and quote. One record per partner, linked to manufacturing orders, quotes, and sales orders.

The scheduler ignores the customer completely. A job runs the same with or without one, because priorities and dates live on the manufacturing order. What the customer record buys you is the ability to answer questions the schedule alone cannot:

• What are we building for this account right now?
• What have we already promised them?
• Which quotes are still open?
• How is our delivery performance per customer?

Two identity fields do different jobs. Customer Id is the short unique code (ACME) that grids and dropdowns display everywhere. Name is the longer descriptive label (Acme Industries) that travels alongside it. Only the Customer Id is required, and it must be at least two characters.

The rest of the record is address, contact, and financial reference data. Contact person and email are worth filling in for anyone you quote, because the quote dialog pre-fills from them and saves retyping on a customer-facing document.

Credit limit is a warning, not a gate

Credit limit and current balance are informational. When the balance exceeds the limit, saving raises a validation warning, and the warning does not block anything. It does not block the save, and it certainly does not block orders. Set the limit to zero if you do not track it, or the check produces noise on every save.

Deleting a customer unlinks, it does not cascade

This one surprises people, and the behavior is deliberate. Deleting a customer leaves their manufacturing orders, quotes, and sales orders intact. The records survive, keep scheduling normally, and simply show a blank customer field. Quotes keep the customer's name as text so the historical document stays true.

That is the right trade. History is more valuable than referential tidiness, and a schedule that silently lost three jobs because someone cleaned up a customer list would be a much worse outcome. The practical rule is the standard master-data rule: deactivate rather than delete. Unticking the active flag hides the customer from new-order and quote dropdowns while every link stays intact.

Where customer data actually surfaces

Knowing where a record shows up tells you how much care it deserves:

Everything on that list is traceability or a customer-facing document. Nothing on it changes a date.

The order history dialog

One button on the customer row opens a two-tab history: manufacturing orders with job number, product, quantity, due date, status and estimated cost; and quotes with quote number, product, quantity, dates, status and total. When a customer calls asking about progress, that is the whole answer in one dialog rather than three screens.

Departments: a monitoring layer over work centers

A department groups work centers that belong together: a physical area, a functional unit, or an entire plant site. Each carries a name, a unique code, a type, a manager, a location, an operating status, and a planning-period capacity in hours.

The single most important thing to understand about departments is what they do not do. Departments are not a scheduling constraint. The engine books time on work centers and never consults the department. You can restructure departments freely and not one job moves.

That has a corollary that catches people out. Setting a department to Maintenance or Inactive is informational: the card turns amber, the summary tiles change, and the scheduler keeps booking work centers inside it exactly as before. To actually block production time you put downtime or holidays on each affected work center. Real shutdowns need both steps: the status for human visibility, the calendar entries for the engine.

What a department card shows

Each department renders as a card that mixes two kinds of number, and knowing which is which matters:

The bottom three rows of that table are always current. The utilization bar is only as good as the planning numbers someone maintains for the period. That is a deliberate design: department capacity is a planning figure for a planning period, not a live aggregation, and the platform does not pretend otherwise.

The bottleneck chips are the quiet value here. A department card showing a bottleneck chip points straight at the constraint that governs everything downstream of it, which is the starting point for any bottleneck identification exercise.

Departments as a multi-plant pattern

The one scheduling-adjacent use of departments is multi-site modeling, and it works through a combination rather than a dedicated module:

1. One department per site, with the site address in the location field.
2. Each site's work centers assigned to its department. Work centers keep their own shifts and holidays, so each plant runs its own calendar.
3. Transit days on any routing step where work crosses sites. The engine adds that travel time before the next plant's operation can start.

Worked example. A part is milled in Houston, heat-treated in Monterrey, and inspected back in Houston. The step routed to the Monterrey furnace carries four transit days. The engine finishes the Houston milling, waits the transit, books the furnace, then adds the return transit before inspection. The department page shows Houston and Monterrey as separate cards with their own utilization. No separate installation, no per-site license juggling, one schedule.

Units of measure: the one reference record with teeth

A unit of measure carries a name, a symbol, a category, and a scheduling behavior. That last field is the exception to "reference data has no scheduling effect." Units of measure explained covers the whole record, including why the unit is master data with its own row rather than free text typed onto a product.

The scheduling behavior has three values:

Worked example. A paint shop sells by the square metre. The unit is defined with a pieces behavior, and Paint-Booth-1 is configured at 20 square metres per hour across two booths. A 400 square metre order resolves like this:

Hours required = 400 ÷ 20 = 20 hours
Two booths, load balanced: 10 hours each
Wall-clock span: 10 hours

Configure the same order with an hours behavior and the engine treats 400 as hours directly. Getting the pairing wrong produces a schedule that is twenty times too long or twenty times too short, which is why this field is worth a moment's thought.

One precedence rule to remember: the work center's own capacity type is what the engine follows. The unit's scheduling behavior is a configuration signal and a sensible default. If the two disagree, the work center wins, so set them consistently and avoid the confusion entirely. The work center material covers how capacity type interacts with instances and shifts.

Product categories: deliberately simple

Categories are a flat lookup: name, code, description, active flag. No hierarchy and no parent-child nesting. If you need sub-categories today, a naming convention such as Metal/Ferrous is the working answer.

Their job is filtering and grouping. The product list groups by category by default, the toolbar filters on it, and reports group on it. Because there is no item-type switch on the product form, categories plus the procured flag are how a catalog stays visibly organized into raw materials, sub-assemblies, and finished goods. That is covered further in product master data and planning attributes.

How the four fit together

Set them up in this order and nothing needs redoing:

1. Units of measure and categories first, because products reference both.
2. Departments next, so work centers have somewhere to be assigned as you create them.
3. Customers whenever you like, since nothing depends on them structurally.
4. Work center assignment into departments once the work centers exist.

The greenfield setup walkthrough runs that sequence end to end on a real plant, the complete EDGEBIC guide places it in the wider platform, and the product hub carries the full feature map. Bulk lists belong in an Excel or CSV import through the configurable import masks rather than in dialogs.