What Is a Grid Export Snapshot?

A grid export snapshot is an Excel file that reproduces exactly what a grid is showing at the moment you export it, in its current sort and filter order, built for sharing and analysis rather than for loading back in. It is the fastest way to get a schedule in front of people who do not sit in the planning system, and it is deliberately not an interchange format. Understanding that one boundary saves a great deal of wasted effort: in EDGEBIC by User Solutions data comes in through import masks and goes out through snapshots, and the two are different shapes on purpose.

How it works

An export walks the grid as rendered, not the tables underneath. That means three things travel with it: the columns you currently have visible and in the order you have them, the sort and filter state you currently have applied, and whatever presentation the grid adds, such as color coding.

The fidelity to the screen is the point. Filter a schedule grid to one work center and one week, and the export is that week for that machine. Collapse a grouping band, and the export follows. If a colleague asks "can you send me what you are looking at," the answer is one button, and the file genuinely is what you were looking at.

That same fidelity is why the file does not come back in. An import reads a file whose columns you have mapped onto named target fields, one mapping per field, saved as a reusable recipe. A snapshot's columns follow the screen, which any user can reorder, hide or filter, and it may carry legend sheets and colors that no importer has any use for. Nothing about a snapshot is stable enough to be a contract. The import side and its stable field names are described in what is an import entity type and EDGEBIC import masks explained.

There is one more consequence worth stating plainly. If the goal is to move a whole installation to another machine or another environment, the route is a database backup and restore, not a stack of exported grids reassembled by hand. Snapshots capture views; a backup captures the system.

A concrete example

Monday morning a planner needs three different things from the same week of plan, and each one is a different export.

The production meeting wants the schedule. The planner filters the job schedule grid to the current week, exports to Excel, and the file arrives with the same color coding the grid uses plus a legend sheet that explains what each shade means. Nobody in the meeting has the planning application open, and nobody needs it.

An engineer questioning a routing wants the steps. The planner opens the routing data grid, sorts by sequence number, exports, and hands over a file that reads in exactly that order.

Finance wants the work center utilization report for the month. The planner opens the report dialog, sets up the columns once, exports to Excel, and because report layouts are remembered per user, next month's export arrives in the identical shape without any setup.

Later that week someone tries to close the loop: they edit the schedule export in Excel and ask whether it can be imported back to apply the changes. It cannot, and the reason is structural rather than a missing feature. The changes belong in the planning screens or, for bulk data, in a mask built against the right entity type, whose row outcomes are described in what is an import row status.

How EDGEBIC uses it

Exports exist on the surfaces where sharing actually happens: the job schedule, the routing grid, the work center schedule, and every report dialog. Reports additionally offer PDF, which is the better choice when the file is going to be read rather than analyzed.

Two practical habits keep snapshots useful:

• Set the view before you export, not after. Because the file follows the screen, a minute spent on columns, sort and filters is a minute you do not spend cleaning up in Excel.
• Do not build a process on a snapshot's column order. Anyone who rearranges the grid changes the file, and a downstream spreadsheet formula that depends on column F breaks without warning.

The complementary direction is worth keeping in mind while you work. Imports change data and never touch the plan: an imported batch of orders appears as jobs ready to be planned, and nothing lands on a timeline until the scheduler runs. Exports are the mirror image: they read the plan and change nothing at all. Neither direction is a live link, which is exactly why both are safe to use freely.

The takeaway

A grid export snapshot is a faithful picture of a view, aimed at people rather than at parsers. Use it liberally for meetings, reviews and analysis, and reach for an import mask when data needs to travel the other way. Keeping those two paths distinct is what stops a spreadsheet from quietly becoming a system of record. To see the exportable grids and reports in a working plan, explore EDGEBIC, and if you are moving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For the inbound side, read what is a delimiter in data import and what is an upsert in data import.