Specifying the ERP Export You Need From IT

A good ERP export request specifies five things: the grain, the columns with their units, the filter, the format, and the saved name. Requests that fail almost always omit the grain or the units, which produces a file that looks correct in a spreadsheet and imports wrong into the schedule.

EDGEBIC by User Solutions reads whatever your ERP can export through saved import masks, which puts the whole burden of the interface on the export specification. That is a good trade, because a specification is a one-time document and a report is a one-time build. This post is how to write both so the request comes back right the first time.

Ask for five exports, not one

Each data type has its own grain and its own refresh cadence, and each feeds its own mask. Combining them makes a file that cannot be imported in one pass.

Five small reports are easier to build than one wide one, easier to filter, and independently re-runnable, which matters because the cadences differ. Why they differ is worked out in deciding import frequency by data type.

State the grain in one sentence

The grain is what one row represents, and it is the assumption most likely to be different in your head and the report writer's.

"One row per operation, per end product" produces a routing file. "One row per operation, per work order" produces something else entirely, because the same operation now appears once per job and the file is twenty times larger. Both are valid reports. Only one is a routing.

Write it as a sentence at the top of the request: "One row per routing operation, for every active end product." Ambiguity here costs a full request cycle.

Name the units on every numeric column

This is the single highest-value line in the specification, because a units mistake produces no error at any point.

A standard time column carrying minutes where the schedule expects hours makes every operation sixty times longer, and the file looks entirely reasonable. The fix on the import side is a conversion factor on that column, which is easy once you know: minutes to hours is 0.016667, seconds to hours 0.000278, and a standard quoted per lot of 100 becomes per piece with 0.01. The mechanism is in what a conversion factor is.

So ask the question explicitly rather than assuming: is setup in hours or minutes, is run time per piece or per lot, and if per lot, what lot size? A report writer can answer all three in one email. Nobody can answer them from the file afterward without arithmetic.

Specify the filter, and say why

Which rows appear is a planning policy, not a technical detail, so it belongs in the request rather than being left to the report writer's judgment.

For work orders, that means naming the statuses that count as demand: released and firm planned orders in, MRP suggestions and canceled orders out. The reasoning is in deciding which ERP work orders to import. For products and routings it usually means active records only. For multi-plant shops it means either a site parameter or an all-sites file, depending on the model, per handling multi-plant ERP exports.

Include the reason in one clause. Six months later somebody will ask why suggested orders are excluded, and the answer needs to be recoverable from the report definition rather than from memory.

The column table

Write the columns as a table, not a paragraph. Four fields per row is enough.

Two conventions save trouble later. Ask for stable headings, because the import mask maps by heading rather than by position, so reordering columns is harmless and renaming one is not. And ask that the first row of the file be the heading row, since that is what makes the mapping resilient. The consequences are covered in handling an ERP export that changed column order.

Sequence numbers are worth one extra sentence: ask for them in gaps of 10 if the ERP allows it, so a later insert becomes 25 and nothing renumbers.

Ask for a twenty row sample first

This is the step that converts a possible second three week cycle into a same-day correction.

Review the sample against the specification and check three things: the grain matches, the units are what you asked for, and one job you know by heart produces the right arithmetic. Three operations at 0.25, 0.40, and 0.10 hours per piece with 1.5 hours of setup, on an order of 200 pieces, totals (0.25 + 0.40 + 0.10) x 200 = 150 run hours plus 1.5 setup, so 151.5. If the sample produces something else, you have found the problem before the report was finished.

Format, delimiter, and name

The remaining three lines are short.

Format. An Excel workbook or a delimited text file both work, and the mask handles comma, semicolon, tab, and space delimited text. If values may contain commas, say that the file should quote text values so the reader handles them correctly. Whether to prefer a file or a read-only database view is a separate decision, covered in CSV versus database view export tradeoffs.

Delivery. A shared folder the report writes to on a schedule is the version that removes the most friction from the weekly routine.

Name. Ask for the saved report to be named so it is obviously a scheduling asset, and ask that edits to it be treated as changes to a shared asset. Most format churn comes from a well meaning edit by someone answering an unrelated question.

What not to ask for

Do not ask IT to add custom fields for machine counts, shift coverage, or changeover cost by sequence. Those are not transaction data, they change faster than anyone will maintain an ERP master record, and they belong with the planner who owns them. What the export cannot carry, and what to do instead, is in what your ERP export cannot tell you about the floor.

Bring a draft specification and a sample export to a working session. Mapping a sample live usually surfaces the two columns that need a different definition, and it takes minutes rather than a request cycle. The import layer that consumes the file is on the EDGEBIC ERP integration page, and the engine behind it is on the EDGEBIC product overview.