Skip to main content

Exports, imports and permissions

Most of the planning work happens on screen. Two things do not: handing a buyer the week's purchases in a spreadsheet, and setting up hundreds of items at once when you first switch planning on. This page covers what comes out, what goes back in, and who is allowed to do either.

Exports​

Five screens export. Each Export button takes the view you are looking at with you — the filters you applied, the sort you chose, and on the list screens, the columns you have showing.

Every export offers XLSX (Excel) or CSV. XLSX is the friendlier file; CSV is the one that never runs out of room, which matters on a large catalogue.

Planned orders​

From the Workbench, the suggestions the run produced. This is the export to hand a buyer or a production lead.

Columns: ID, Product, SKU, Warehouse, Supply Type, State, Released Order, Accepted, Qty, Net Requirement, Due Date, Release Date, Lead Time, Lot Sizing, Source, LLC.

Two of those are not on the grid. SKU is split out from the product cell so a spreadsheet can sort and filter on it. Net Requirement is the raw shortage behind a lot-sized quantity — the answer to "why 500 when I only need 410?" — which the grid can filter on but has no column for.

Time-phased plan​

From the drilldown drawer you open on an item in the Workbench, that one item's period-by-period plan: one row per period, carrying the six requirement lines as columns.

Columns: Product, SKU, Warehouse, Bucket Start, Bucket End, Gross Requirements, Scheduled Receipts, Projected Available, Net Requirements, Planned Order Receipts, Planned Order Releases.

This one exports the item and warehouse the drawer is showing, not the whole run. See Read the time-phased plan for what each line means.

Exception messages​

From the Exceptions page, the inbox as a spreadsheet — useful for a weekly review, or for handing a category's problems to whoever owns them.

Columns: Type, Severity, Status, Product, SKU, Warehouse, Current Qty, Current Due Date, Recommended Qty, Recommended Due Date, Days Late.

The page opens filtered to open exceptions, so unless you change the filters that is what you get. See Work the exceptions inbox.

Planning policies​

From the Policies page. Its Export menu is slightly different from the others: Export filtered, Export selected, Export all planning policies, and Export filtered as CSV. Excel is the default format.

Columns: product_id, product_sku, warehouse, planning_method, procurement_type, lot_sizing_rule, lead_time_source, lead_time_days, safety_stock, safety_lead_time_days, reorder_point, reorder_up_to_level, order_minimum, order_multiple, order_maximum, fixed_order_quantity, period_order_days, days_of_supply, eoq_ordering_cost, eoq_holding_cost_pct.

note

This export is deliberately a valid import file. The headings are the import's own columns, in the import's own order, so export → edit in a spreadsheet → import back is a supported round trip rather than a coincidence. It is the only way to set Safety Lead Time (days), which has no field in the policy dialog — see Planning policy settings.

MPS entries​

From the MPS page, your master production schedule.

Columns: product_id, product_sku, warehouse, bucket_start, quantity, source, delete.

The same round trip applies: what comes out is a file the MPS import takes back in, including the delete column you can use to remove entries in bulk.

Practical limits​

The three run-scoped exports — planned orders, the time-phased plan, exception messages — refuse an oversized Excel file rather than building a broken one, with a message telling you to export as CSV instead or narrow the filters. CSV has no such ceiling.

The policies and MPS exports stop at 50,000 rows. That clears any real catalogue, but if you are exporting an unfiltered list on a very large tenant, filter it first rather than assume the file is complete.

Imports​

Two things can be loaded from a spreadsheet: planning policies and MPS entries. Both use the same four-step wizard — upload, map columns, validate, import — reached from the Import button on the Policies and MPS pages.

Templates​

Step one of the wizard offers Download Template. Take it: guessing the columns is the main way an import goes wrong.

Each template is a workbook of three sheets:

  • Import Here — the header row you fill in, with the required columns highlighted and a sample row showing the shape
  • Field Guide — a row per column explaining what it accepts
  • Reference Data — the values your tenant actually has, so warehouse names and the accepted setting values can be copied rather than typed

An export of what you already have works as well as a starting file, and is usually the better choice when you are changing existing records rather than adding new ones.

Planning policies​

Required columns: product_sku, and planning_method on any row creating a new policy. Everything else is optional.

Rows are matched on the item and the warehouse together. A blank warehouse cell means the item-level default policy; a named warehouse is an override for that warehouse. An unknown combination creates a policy, a known one updates it in place, so re-importing the same file is safe.

Values accept either the on-screen label or the underlying value — Min / Max and min_max both work — and matching ignores case and punctuation. Whole numbers must be whole and zero or more; decimals must be numbers and zero or more, with thousands commas stripped.

caution

A blank cell keeps the existing value — it does not clear it. Clearing a setting is deliberately not expressible in the file, so that an export re-imported with one column edited cannot wipe every parameter you left alone. To remove a value, edit the policy in the dialog.

A warehouse override for an item that has no default policy behind it raises a warning rather than an error: that item will be planned in the one warehouse and skipped everywhere else, which is rarely what a bulk import means.

MPS entries​

Required columns: product_sku, warehouse, bucket_start and quantity. source and delete are optional.

Rows are matched on the item, the warehouse and the period start together. Unlike a policy, the warehouse is required — a blank cell is an error here, never a default, because an MPS entry has to belong somewhere.

bucket_start takes any date the spreadsheet can express and is treated as a date, not a moment. source accepts Manual, Forecast or DRP, and defaults to Manual on a new entry. delete accepts 1, true, yes or y, and removes that period's entry.

note

A quantity of 0 leaves an entry in place that contributes no demand, which is almost never what you want. The wizard warns about it and tells you the fix: put "yes" in the delete column to remove the period instead.

What validation does​

The wizard validates before it imports anything, and reports per row rather than per file.

The validate step summarises what it found — New, Updates, Errors, Warnings, and Deletes when the file removes anything — and splits the rows into Valid, Errors and Warnings tabs so you can read the failures without scrolling past everything that worked.

Then the important part: a bad row is skipped, not a reason to reject the file. Importing a thousand rows of which three have a typo imports 997 and reports the three. That is deliberate — an onboarding file assembled by hand always has a few bad rows, and holding the other 997 hostage to them helps nobody.

Errors are things the import cannot resolve: an unknown item, an unknown or ambiguous warehouse, a value that is not one of the accepted ones, a number that is not a number, a required column left blank on a new record, the same record appearing twice in one file, or a combination of settings the plan does not accept. Warnings are things worth knowing that do not stop the row.

The import runs in the background and reports into the job tray, so a large file does not tie up the page you started it from.

Permissions​

Access to the Planning area comes in three levels. In Roles & Permissions they appear together under the group MRP Planning.

They are additive, so a planner who runs the plan also needs to see it.

See the plan​

Opens every page in the Planning area and reads everything on it: runs and their planned orders, the time-phased plan, why an order exists, exception messages, item policies, the master production schedule, capacity, availability and promise checks, transfer lanes, and run comparisons.

It also covers all five exports. Reading the plan into a spreadsheet is reading the plan — someone who can see it on screen can take it away, and someone who cannot see it cannot use an export as a back door.

Give this to anyone who needs the answer: buyers, production leads, customer service checking a promise date, finance looking at what is coming.

Run and change the plan​

Everything that alters the plan or the data it reads, and nothing that creates a real document. That means starting, cancelling and deleting runs; firming, unfirming, accepting, dismissing and editing planned orders; accepting and dismissing exception messages; creating, editing and bulk-applying item policies; maintaining the master production schedule, the transfer lanes, planning calendars and capacity setup; and both spreadsheet imports, including their templates.

Accepting a planned order belongs here rather than with carrying out: it is a sign-off flag on a suggestion, not an order.

This is the planner's level. Note how much of it is destructive in bulk — a planning-policy import can rewrite every policy in the business — so it is a real grant, not a convenience.

Carry out planned orders​

Turning planned orders into real purchase orders, manufacturing orders and warehouse transfers. One action, on its own permission.

caution

Carrying out is separate on purpose. It is the only step in the Planning area that creates documents with money and commitments attached — a purchase order goes to a supplier, a manufacturing order consumes stock, a transfer moves it between sites. Everything else can be undone by running the plan again; this cannot.

Separating it lets you give the whole plan to a team and the act of committing it to the few people who should be committing it — a planner who works the plan all day, and a manager who signs it off.

Without it, the Planning pages all work normally and the CARRY OUT (RELEASE) buttons are disabled, with a tooltip saying to ask an administrator for the Carry Out permission.

What to grant​

The personWhat they need
A buyer, production lead or anyone reading the planSee the plan
A planner who owns the plan day to daySee the plan, and run and change it
Whoever commits the plan into real ordersAll three

All three sit inside general Manufacturing access, so a role needs that as well — granting a planning permission to a role that cannot reach Manufacturing at all does not open the area.

Last verified: