A customer id is the short unique code that identifies one trading partner, such as ACME, and it is the value the application shows on grids, dropdowns, and filters throughout. A longer descriptive name travels with it for correspondence and reporting, but the id is the handle everyone reads and quotes.
This entry defines the customer id and shows how it reads inside EDGEBIC by User Solutions. For the wider index of terms, see the manufacturing glossary; for the record it identifies, see EDGEBIC customers and departments explained; and for its counterpart on the product side, see what is a product id.
How It Works
Master data records almost always carry two identifiers, and confusing them is a reliable source of frustration. One is a short code meant for people to read and type. The other is a longer descriptive string meant for documents.
The customer id is the first of these. It must be present, it must be at least two characters, and it must be unique across customers. Because it is short, it fits in a grid cell, a dropdown row, a report group header, and a filter box, which is why it becomes the value people say to each other. The descriptive name is optional and free text, and it appears where there is room for it.
Uniqueness is what makes the id an identifier rather than a label. Two customers cannot both be ACME, so a reference to ACME on an order, a quote, or a report resolves to exactly one partner with no further qualification. The name carries no such guarantee, which is why nothing keys off it.
One thing the customer id does not do is affect scheduling. The engine does not care who a job is for. A job schedules identically with a customer attached or without one, because capacity, routings, and calendars are what determine dates. What the customer link buys is traceability: filtering the schedule by account, pre-filling the right contact on a new quote, and grouping delivery performance per customer on reports.
The id is also the scope for other uniqueness rules. Sales order reference numbers, for instance, are required to be unique per customer rather than globally, so the customer id is what makes two identically numbered orders from different partners legitimate.
A Concrete Example
A shop sets up a new account. The customer id is ACME, five characters, obvious to anyone in the building. The name is Acme Industries, which is what will print on a quote document. A contact person and email are added, which pre-fill on new quotes for that account.
Some months later a planner is looking at a busy schedule and wants to see only Acme's work. They filter on ACME. The grid narrows in one action, because the id is the value in the column.
Sales raises a quote and picks ACME from the customer dropdown. The contact defaults in, and when the quote is accepted and converted to a manufacturing order, the customer link carries across so nobody rekeys anything. Later the on-time delivery report groups by customer, and Acme's record appears as its own line.
The same shop also has a second account whose descriptive name is Acme Fasteners, an unrelated company. Because it needs its own distinct id, it is set up as ACMEF. The two are never confused in a filter, a report group, or a dropdown, which is exactly the value the id provides and the name cannot.
How EDGEBIC Uses It
In EDGEBIC, the customer id is the required field on the customer record and the value shown across order grids, quote grids, and customer dropdowns. The name sits alongside it as a longer descriptive field. Both an id already in use and an email address already in use are hard errors that block the save, so duplicates are caught at entry rather than discovered later.
Customer records link to manufacturing orders, quotes, and sales orders, which is what makes account-level questions answerable. A history view on the customer row opens their manufacturing orders and their quotes side by side, so you can answer what you are building for a partner and what you have promised them without leaving the screen. Reports use the same link to group delivery performance and order progress by account.
Retiring an account is a matter of unticking the active flag rather than deleting. That removes the customer from new order and quote pick lists while keeping the record and its history intact, and the list's active-only filter plus its status column make deactivated partners easy to find again.
Two financial fields sit on the record as well. Both are informational and neither blocks anything, which is covered in what is a credit limit.
For the orders the id anchors, see EDGEBIC sales orders explained and what is a sales order reference number. For the account-level scorecard the link makes possible, see on-time delivery rate.
A customer id is the short unique code that identifies one trading partner, such as ACME. It is the value shown on order grids, quote grids, and dropdowns, so it is what planners and sales staff actually read all day. A separate descriptive name, such as Acme Industries, travels alongside it for documents and reports. The id is the key; the name is the label.
The id is short, required, and unique, and it is what the application displays in compact places like grid cells and pick lists. The name is optional, longer, and descriptive, meant for correspondence and reporting where there is room for it. Two customers cannot share an id, but the name is free text. If you only ever fill one of the two, fill the id, because that is the one everyone will see and quote.
Not at all. Customers have no influence on the scheduling math: a job schedules exactly the same whether or not a customer is attached to it. Their value is traceability, which means filtering the schedule by account, defaulting the right contact onto a quote, and reporting delivery performance per customer. Linking a job to a customer buys you those views without changing a single date on the plan.
Clean them up during migration, before anyone builds habits around them, because that is the only moment it is cheap. The id has to be at least two characters and unique, but beyond that it is yours to choose, and short readable codes pay for themselves every day in grid filters and pick lists. Once orders, quotes, and reports have been running against a code for a year, changing it becomes a data exercise nobody wants to schedule. If a legacy code carries meaning your team relies on, keep it in the descriptive name or the notes rather than in the id, so the id can be the clean human-readable handle it is meant to be.
Deactivate rather than delete, in almost every case. Unticking the active flag removes the customer from new order and quote pick lists while leaving the record and its entire history intact, so old jobs, old quotes, and old reports still resolve to a real account rather than a gap. The customer list has an active-only filter and a status column, so a deactivated partner is easy to find again if they come back, and reactivating is a single edit. Deletion is the option that costs you something you cannot get back, since the whole point of holding a customer record is the trail it anchors.
Expert Q&A: Deep Dive
Q: We are inheriting customer codes from an old system and some are 12 characters of gibberish. Should we clean them up?
A: Clean them up during migration, before anyone builds habits around them, because that is the only moment it is cheap. The id has to be at least two characters and unique, but beyond that it is yours to choose, and short readable codes pay for themselves every day in grid filters and pick lists. Once orders, quotes, and reports have been running against a code for a year, changing it becomes a data exercise nobody wants to schedule. If a legacy code carries meaning your team relies on, keep it in the descriptive name or the notes rather than in the id, so the id can be the clean human-readable handle it is meant to be.
Q: A customer stopped ordering. Should I delete them or is there a better option?
A: Deactivate rather than delete, in almost every case. Unticking the active flag removes the customer from new order and quote pick lists while leaving the record and its entire history intact, so old jobs, old quotes, and old reports still resolve to a real account rather than a gap. The customer list has an active-only filter and a status column, so a deactivated partner is easy to find again if they come back, and reactivating is a single edit. Deletion is the option that costs you something you cannot get back, since the whole point of holding a customer record is the trail it anchors.
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.