- Home
- Blog
- ERP Integration (EDGEBIC)
- Fishbowl to EDGEBIC: The Data Mapping Reference
Fishbowl to EDGEBIC: The Data Mapping Reference
Mapping Fishbowl data into EDGEBIC is a column-mapping exercise rather than a development project: you export parts and open manufacture orders to Excel or CSV, drag each source column heading onto the matching EDGEBIC field once, and save it as a reusable import mask. The operation-level routing Fishbowl does not carry is built once inside EDGEBIC, with a bill of materials export as an optional scaffold. This reference lists what maps to what, which columns are mandatory, how unit conversion and blank cells behave, and what every row outcome means.
EDGEBIC by User Solutions integrates with Fishbowl through those masks rather than a certified connector, so nothing is installed inside Fishbowl. If you have not read the end-to-end version, start with the complete Fishbowl integration guide. This post is the lookup table you keep open while building masks.
The load order
Import in dependency order. Later files reference records that earlier files created.
| # | Fishbowl source | EDGEBIC entity type | Depends on |
|---|---|---|---|
| 1 | Built in EDGEBIC | Workcenter | Nothing |
| 2 | Bill of materials scaffold plus operations | BOR (bill of routing) | Parts and work centers |
| 3 | Parts | Product | Nothing |
| 4 | Open manufacture / work orders | SalesOrder | Parts |
| 5 | Confirmations (optional) | Actuals | Scheduled jobs |
Two entity types have no Fishbowl origin and are built from a spreadsheet you write: Shift (one row per shift with a start and end pair per weekday, a blank pair meaning the day is off) and PlantHoliday (closures by name and date). These define the calendar every date is computed against, so they deserve ten careful minutes.
Auto-create is on by default, so a routing file naming a work center that does not exist yet creates it on the fly. That is a useful safety net and a poor strategy: an auto-created work center has a name and nothing else. Build the work centers properly first.
Parts to Product
| EDGEBIC target field | Mandatory | Source column |
|---|---|---|
Product_Id | Yes | The Fishbowl part number. Natural key, matched case-insensitively |
Product_Name, Description | Descriptive text | |
UOM | Unit of measure | |
Unit_Price, Lead_Time, Category | Optional planning and quoting attributes | |
Size, Weight, Country_Of_Origin | Optional descriptive columns |
Only the identifier is required. Everything else can arrive later through a second, narrower refresh file, because blank cells preserve existing values on an update run. Watch identifier formatting across exports: matching ignores case but not a location prefix, so make every export render the identifier the same way.
Work centers to Workcenter
This is the file where scheduling accuracy is won or lost, because it carries capacity. Fishbowl has no true work-center model, so you build it.
| EDGEBIC target field | Mandatory | What it drives |
|---|---|---|
Workcenter Id | Yes | Natural key. Routing steps match on it |
Workcenter Name | Label on the Gantt and in reports | |
Number_Of_Instances | How many identical machines the center holds. Blank defaults to 1 | |
Capacity, Efficiency | Rated capacity and the efficiency applied to it | |
Setup_Time_Hours | Default setup, overridden per routing step where present | |
Hourly_Rate | Cost rollups | |
Is_Bottleneck | Marks the constraint so the engine can anchor around it | |
One_Per_Day_Flag | One job per machine per day, for long-changeover centers | |
Use_Global_Shifts, Shift_Names | Calendar assignment | |
Pieces_Per_Hour | Rate-based capacity where the center is measured in output | |
Min_Batch_Size, Max_Batch_Size | Batching limits | |
Is_Active, Color, Type | Housekeeping and Gantt color |
Number_Of_Instances is the highest-value column on the page. A cell of four identical machines imported with one instance produces a plan roughly four times too long, and it fails quietly: nothing errors, the dates are simply wrong. Fill it deliberately for every multi-machine center. The arithmetic is in how EDGEBIC calculates work center capacity.
Machine pools
Planners think in pools of interchangeable machines, and EDGEBIC models that as a work center group. A routing step bound to a group re-evaluates every member on each reschedule, picks by strategy (earliest completion, primary first, or earliest start), and applies a per-member efficiency factor so a slower machine is chosen only when it still finishes first. Operations already started keep the machine they started on, because recorded work is never moved. Build the members as ordinary work centers, then create the group inside EDGEBIC and add them: see how to create work center groups.
Routings to BOR
| EDGEBIC target field | Mandatory | What to put in it |
|---|---|---|
End_Prod | Yes | Part identifier this routing builds |
Sub_Prod | Yes | Work center id (operation row) or component part (material row) |
Op_Flag | Yes | True for an operation, false for a material or component |
No_Req | Yes | Hours required per unit |
Seq_No | Operation sequence, in gaps of 10 | |
Next_Seq | Leave blank; chaining happens automatically | |
Setup_Time | Setup hours at this step | |
Queue_Time | Buffer hours before the step may start | |
Flow_Step, Transit_Days | Overlap between steps, and transport time | |
Parallel_Op | Parent step's work center name for parallel or alternate steps | |
Alt_Type | Parallel-Independent, Parallel-Dependent, or Alternative | |
Res_Mult | Applicable machine instances for this step | |
Fam_Dept | Department for auto-created work centers |
Op_Flag is the field people get wrong first. True means "this row is an operation running on a work center". False means "this row is a component consumed at this point in the routing". A Fishbowl bill of materials export lands as component rows, all with an operation flag of false, and you add operation rows around them.
Why the import takes two passes
A routing cannot be written row by row, because step 10 must point at step 20 and step 20 does not exist yet. So the import runs in two passes. Pass one validates each row, resolves or creates the parts and work centers it names, and buffers the row. Pass two groups the buffer by end product, sorts by sequence number, writes the steps, and wires the chain: 10 to 20, 20 to 30, and the terminal step to the finished part. Check that visually after the first import: a routing missing its final link draws as a chain floating free of the part it builds.
All of one part's steps must travel in one file, because a run wipes and recreates that part's steps on first reference. And re-importing is safe for running orders, because every scheduled job carries a frozen snapshot of the routing it was planned with.
Orders to SalesOrder
| EDGEBIC target field | Mandatory | Source |
|---|---|---|
Product_Id(BOR) | Yes | Part being built |
Qty | Yes | Order quantity |
Job_Date | Yes | Release or start date |
Sales_Order(Ref#) | Order reference: shared references group into one sales order, jobs auto-number {Ref}-{line} | |
Job_Number | Your Fishbowl order number carried across | |
Due_Date, Order_Date, Priority | Promise, entry, and ranking | |
Customer_Name | Auto-created when missing | |
Unit_Price, User_Notes | Optional |
Two mask options control the date logic when the export carries only one date: one treats the job date as the due date, the other derives the job date backward from the due date. Choose the one matching how your export is built, once, on the mask.
Confirmations to Actuals
Job number, work center id, and actual date are mandatory. Hours and pieces are both optional, and either can be derived from the other using the operation's rate. A Complete column marks the operation finished, and an explicit start column overrides the default of using the earliest imported date. The import always overwrites the days a file carries, so re-running a corrected extract fixes the numbers rather than doubling them. Actuals import last, because each row has to find an operation on a job that is already scheduled.
Conversions, blanks, and zeros
| Situation | Behavior |
|---|---|
| Minutes in the export | Conversion factor 0.016667 on that mask column |
| Seconds in the export | Conversion factor 0.000278 |
| Hours quoted per 100 pieces | Conversion factor 0.01 |
| Blank cell on an update | Existing value preserved |
| Zero in a cell on an update | Zero is written: it is a value, not a blank |
| Unmapped column | Ignored entirely |
| Mandatory field unmapped | Run aborts before reading any row |
| One bad row | Fails alone and the run continues, unless you choose strict mode |
Reading the outcomes
Every row resolves to Created, Updated, Reused, or Failed. Reused is the default for a record that already exists, so a weekly part file of 5,000 rows reporting Created 11, Reused 4,989 is the desired result rather than a failure. When counts look wrong, the per-run log file carries one line per row with the exact reason for every failure.
What import cannot bring, and why it matters
The settings that most differentiate a schedule have no column in a Fishbowl export: the sequence-dependent setup matrix, operator skills and certifications, work center group strategies, bottleneck anchoring, and lot streaming transfer batches. Those are configured once in EDGEBIC and then apply to every imported order afterwards. The EDGEBIC product overview maps the engine, and the ERP integration architecture explains why one mask design serves every system.
For the questions that come up before a project starts, see the Fishbowl integration FAQ. The QuickBooks and Odoo references show how the method scales up and down the ERP spectrum, and the ERP scheduling add-on page frames the category.
Each entity type has a short mandatory list and everything else is optional. Products need a product id. Work centers need a work center id. Routings need end product, step name, an operation flag, and hours required. Orders need product, quantity, and a job date. Actuals need job number, work center id, and the actual date. If a mandatory field is unmapped in the mask, the run aborts before reading a single row.
Partly. A bill of materials lists the components a part consumes, which map as material rows on the routing, but scheduling also needs the operations: which work center runs each step, hours per unit, and setup time. Fishbowl does not carry those, so you add them once, either in the graphical designer or by extending the bill of materials export into a routing spreadsheet. After that, every manufacture order for the part reuses the routing.
Dependency order: work centers first, then routings, then parts, then open manufacture orders, then optional confirmations. Routings reference both parts and work centers, and orders reference parts, so loading upstream data first stops the auto-create behavior from inventing thin placeholder records. Auto-create is on by default and will fill gaps, but a record created that way carries only the name it was given.
By scheduling scope rather than by Fishbowl structure. If locations share machines or transfer work between sites, import them into one database and use departments to group each site's work centers, because the engine can only balance load across resources it can see. If each location plans independently, a database per location keeps files small and each planner's view focused.
Expert Q&A: Deep Dive
Q: Our part numbers in Fishbowl sometimes include a location prefix. Will that create duplicate products in EDGEBIC?
A: It can, and it is the one mismatch case-insensitive matching does not rescue. Natural-key lookups ignore case, so PUMP-A and pump-a resolve to the same record, but WH1-PUMP-A and PUMP-A are genuinely different strings and become two products. Decide on one canonical part identifier and make every Fishbowl export render it the same way, stripping or keeping the prefix consistently. Run a distinct-values check across your part file and your routing file before the first import, because a mismatch caught then costs minutes, while the same mismatch caught after routings load means a routing chain pointing at a product with no demand.
Q: We make the same part at two Fishbowl locations by different methods. How do we model that?
A: Give each version its own product identifier, something like PUMP-A-S1 and PUMP-A-S2, rather than trying to hold two routings under one name. A routing import wipes and recreates a single product's steps on every run, so two genuinely different methods under one identifier would overwrite each other. With separate identifiers, each carries its own routing whose steps name that site's own work centers, and you group those work centers into departments per site. If the two sites build the part identically and only differ in which machines are free, model it once as a work center group instead, so the engine picks the site that finishes first on each reschedule.
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
Connecting EDGEBIC to Your ERP Database With a SQL Source
How to point a scheduled EDGEBIC integration at a read-only ERP query instead of a file: testing the connection, previewing columns, checking the mask fits, and the stored-password rule that catches most teams out.
EDGEBIC ERP Integration: The Complete Guide
How EDGEBIC integrates with any ERP: eight import masks, three source options, a documented data mapping, and the weekly rhythm that keeps a finite capacity schedule current.
Closing ERP Work Orders That EDGEBIC Still Thinks Are Open
Your ERP closing a work order is invisible to EDGEBIC. There is no status column on the order mask, and a job whose every step is done is not closed automatically. Here is the closing pass that keeps your numbers honest.
