How to Export the Product List to Excel in EDGEBIC

To export the product list in EDGEBIC by User Solutions, open the Products grid, right-click any column header, choose Export, pick Excel or CSV, and select a target file path. The file contains the columns that are visible in the grid at the moment you export, one row per product.

It is a three-click operation, and the only thing worth slowing down for is which columns are in the grid before you start. The export is a picture of what you are looking at, not a dump of everything the product record holds.

Before You Start

• Decide what the file is for. A review file, a supplier list, and a bulk-edit source need different columns, and getting them right before you export saves doing it twice.
• Check the grid for filters. If you have filtered the product list, work from the assumption that the filter shapes what you see and confirm the row count in the exported file matches what you expected.
• Know that this is a one-way trip. Getting edited data back in is a separate job through the Import module.

Exporting the List

1. Open the Products grid.
2. Right-click any column header.
3. Choose Export, then Excel or CSV.
4. Choose the target file path.
5. Click Export.

Excel is the right choice when a person will read the file. CSV is the right choice when a system will, or when you plan to feed the file back through an import mask later.

What Ends Up in the File

The export carries the visible columns. In a default grid that includes:

Two of those rows deserve attention. Unique number is the column that lets a spreadsheet row find its way back to the right product on a later import, so never edit it and never let a spreadsheet reformat it. Quantity on hand is a convenience snapshot: for anything that has to be correct to the piece, use the inventory ledger instead.

Fields that are hidden in the grid are not exported. Tags and notes are the usual casualties. If you need them, make those columns visible in the grid before you export.

Choosing Excel or CSV

The two formats carry the same rows, so the choice is about what happens next.

Pick Excel when a person is the destination: a supplier review, a management summary, a file somebody will read and comment on. Formatting survives, and the file opens cleanly without anyone having to think about separators or encodings.

Pick CSV when a system is the destination, or when the file is going to come back in through an import later. CSV is the plainer format and it avoids the layer of spreadsheet interpretation that can quietly reformat an identifier. Whichever you pick, if the file will be re-imported, treat the unique number column as read-only from the moment it leaves the product.

One practical note for either format: the export writes the grid you are looking at, so if you have narrowed the product list before exporting, the file is narrowed too. That is usually what you want, and it is occasionally the reason a file has 40 rows when you expected 400.

How to Check It Worked

Open the file and check three things in about ten seconds. The row count should match the number of products you expected, which tells you whether a filter was active. The column set should include every field you actually need, which is the mistake that is expensive to find later. And the unique number column should have survived intact rather than being reformatted into scientific notation or having leading zeros stripped, which is a spreadsheet behavior rather than an export behavior but bites just as hard.

If a column you wanted is missing, close the file, make the column visible in the grid, and export again. It is faster than trying to patch the file.

A Quick Worked Example

A manufacturer is repricing a product family before a quarter close. The planner filters the Products grid to the category in question, scans the list to confirm the right items are showing, then right-clicks a header and exports to Excel.

The file lands with 118 rows and the default column set. She saves an untouched copy named before-repricing, because that copy is her undo. In the working copy she updates unit price on 94 rows, leaving unique number and every other column alone.

To bring it back she builds an import mask that maps unique number to the product key and the price column to unit price, then runs it against a five-row test file first. The five products update correctly, so she runs the full 118. If the mask had mapped the wrong field, she would have found out on five rows instead of on the whole family.

Common Mistakes

Exporting before setting up the columns. Hidden columns are not in the file. Decide what you need, make it visible, then export.

Treating quantity on hand as a count. It is a cached snapshot. For a real stock position, use how to run the stock-on-hand report or how to audit the inventory ledger for a part.

Editing the unique number. That column is how a re-import finds the right product. Change it and the import either creates duplicates or fails.

Assuming the file can be loaded straight back. It cannot. Import is a separate, mapped operation: see how to build an import mask.

Running a bulk import without a test file. An import mask applies the same mapping to every row. Prove it on five rows first.

Next Steps

For the return trip, see how to import products from Excel and how to re-run a saved import mask. For the fields you are exporting in the first place, see how to set up products and EDGEBIC products and planning attributes explained.

For exporting analysis rather than master data, see how to export a report to Excel. For the full task library, see the EDGEBIC how-to hub, and for the platform overview, EDGEBIC.