Import MPS entries and planning policies

Planning is the one part of manufacturing where the setup is bigger than the work. A run plans nothing for an item without a policy, so switching planning on across a real catalogue means a policy per item — sometimes a policy per item per warehouse. And a master production schedule is a grid by nature: one row per product, per warehouse, per period. Both are faster to build in a spreadsheet than in a dialog.

The same four-step wizard loads either one. Which one you get is decided by where you open it from:

• Planning policies — the Import button on Manufacturing → Planning → Policies.
• MPS entries — the Import button on Manufacturing → Planning → MPS.

Everything else about the two is identical, including the safety net: the wizard checks every row and tells you what it found before anything is written.

Before you begin

• You need permission to change planning data — the same permission that lets you edit a policy or add a schedule entry by hand.
• Products and warehouses have to exist already. An import matches against your catalogue; it never creates a product or a warehouse.
• Know which round-trip you are doing. To edit what you already have, export first and edit that file — the export comes out in exactly the shape the importer accepts. To start from nothing, download the template.

Steps

1. Open the page for what you are loading — Policies or MPS — and click Import.

2. Upload. You have three ways to get data in:

   • Click Download Template, fill it in, and bring it back. See What the template gives you below.
   • Drag a file onto the upload area, or click Choose File. CSV, TSV and Excel files are all accepted.
   • Paste rows straight into the Paste CSV/TSV data box. Set Column separator to Auto, Comma, Tab or Semicolon — Auto works for most pasted data. Pasting from a spreadsheet usually means tab-separated data, and pressing Tab inside the box inserts a tab character rather than moving to the next control.

   Once data is loaded, a Raw Data Preview shows the first few rows. Check that First row is a header matches your file before moving on.

3. Map Columns. Each column in your file is listed under Your Column with what it will be loaded into under Maps To.

   Columns are matched automatically by name, and the matching is forgiving — a column headed "SKU", "Qty" or "Week of" is recognised as well as the template's own spelling. Correct anything it guessed wrong, and set a column you do not want to load to Skip this column.

   A warning reading "Missing required mappings" names any required column that is not yet mapped. Under the table, Mapped Data Preview (first 5 rows) shows your data arranged as the import will read it — the fastest way to catch a column that is one place out.

4. Validate. Every row is checked, and counters across the top summarise the result:

   Counter	What it counts
   New	Rows that will create something
   Updates	Rows that match something that exists and will change it
   Deletes	Schedule entries marked for removal (shown only when there are any)
   Errors	Rows that cannot be imported
   Warnings	Rows that will import, but are worth a second look

   Use the All, Valid, Errors and Warnings tabs to read the detail. Errors and warnings are reported per row, in the words of the problem — "Warehouse 'Main WH' not found.", "Quantity must be a number (got 'twelve')." — so you can fix the file rather than guess.

   To abandon the whole thing at this point, click Discard Import. Nothing has been written yet.

5. Import. Click the import button, which names how many valid rows it is about to load. The import runs in the background and is tracked in the job tray, so you can close the wizard and carry on.

   The final step reports Processed, Created, Updated, Deleted and Errors. Click Close.

How bad rows are handled

A bad row does not reject the file.

Validation records errors and warnings against individual rows, and the import loads every row with no errors and skips the rest. Ninety-eight good rows out of a hundred means ninety-eight records written and two to fix — not a hundred rows to re-upload.

That makes fixing an import straightforward: filter to the Errors tab, correct those rows in your file, and import the corrected file on its own. Because rows are matched rather than duplicated, re-importing rows that already loaded changes nothing.

note

Re-importing the same file is safe. Both entity types match on identity rather than creating blindly, so a second import of the same file updates what it already wrote instead of doubling it. This is what makes the export-edit-import round-trip below dependable.

What the template gives you

Download Template produces a workbook with three sheets:

• Import Here — the header row, styled so required columns are obvious, plus a couple of sample rows showing the shape. Fill in underneath and delete the samples.
• Field Guide — one row per column, explaining what it holds, whether it is required, what values it accepts, and an example.
• Reference Data — the values your account accepts: your warehouse names, a sample of your product SKUs, and for policies, every valid planning method, procurement type, lot sizing rule and lead time source. Copy from here rather than typing and the values will match.

Planning policy columns

A policy says how one item is planned. The full meaning of each setting is in Planning policy settings; this is the file shape.

Column	Required	Notes
product_id		Only needed when a SKU was renamed since the file was produced. When both are filled in, this one wins.
product_sku	Yes	The item the policy is for.
warehouse		Blank means the item's default policy, which applies everywhere. A warehouse name makes the row an override for that warehouse only.
planning_method	Yes	How the item is planned. None means the run skips it.
procurement_type		Whether supply is made, bought or transferred in.
lot_sizing_rule		How a shortage is turned into an order quantity.
lead_time_source		Where the item's lead time is read from.
lead_time_days		A whole number of days.
safety_stock		The level the plan refuses to drop below.
safety_lead_time_days		Extra days of buffer, so supply is planned to arrive early. There is no field for this in the app — see below.
reorder_point		The floor under Reorder Point and Min / Max planning.
reorder_up_to_level		The level Min / Max planning replenishes back up to.
order_minimum		The smallest order the plan is allowed to raise.
order_multiple		Rounds an order up to a pack, case or batch size.
order_maximum		Caps one order; a larger requirement is split across several.
fixed_order_quantity		The quantity used by the Fixed Order Quantity lot sizing rule.
period_order_days		How many days one order covers under the Period Order Quantity rule.
days_of_supply		How many days of demand one order covers under the Days of Supply rule.
eoq_ordering_cost		Required when the rule is Economic Order Quantity.
eoq_holding_cost_pct		Required when the rule is Economic Order Quantity.

Rows are matched on the product and the warehouse together. A row with a blank warehouse cell updates that item's default policy; a row naming a warehouse updates that warehouse's override. The two are separate records, so the same product can appear twice in one file.

A blank cell keeps the value that is already there. That makes a partial file safe — a two-column file of SKUs and safety stock updates safety stock and disturbs nothing else. It also means clearing a value is not something a file can express; to empty a setting, edit the policy in the app.

Columns with a fixed set of choices accept either spelling. Type the on-screen label (Min / Max) or its short form (min_max) — capitalisation, spaces and punctuation are all folded before matching.

caution

A row that names a warehouse for an item with no default policy imports successfully, and warns you: it creates an override for that one warehouse only, and the run still ignores the item at every other warehouse. When you intend an item to be planned everywhere, give it a default policy — a row with the warehouse cell blank — as well.

Safety lead time is only settable here

Safety Lead Time (days) is an extra buffer added on top of an item's resolved lead time, so supply is planned to arrive that many days early. It is a genuinely useful setting for a supplier whose delivery dates wander.

It has no field in the Add Planning Policy or Edit Planning Policy dialog. The safety_lead_time_days column is in the template, in the export, and accepted on import — and that round-trip is the only way to set it. If you want it, export your policies, fill in the column, and import the file back.

MPS entry columns

A schedule entry is a quantity of one product, at one warehouse, in one period. See Build a master production schedule for what the schedule does.

Column	Required	Notes
product_id		As above — only needed when a SKU was renamed.
product_sku	Yes	The item being scheduled.
warehouse	Yes	Required, unlike a policy. Every entry belongs to exactly one warehouse, so a blank cell is an error, never a default.
bucket_start	Yes	The first day of the period, as a date. Keep it consistent — every Monday for weekly buckets, the first of the month for monthly ones.
quantity	Yes	How much to schedule in that period. Required on a new entry; blank on an existing one keeps the quantity already there.
source		Manual, Forecast or DRP. New entries default to Manual.
delete		Put yes here to remove the entry instead of saving it. Every other column on the row is ignored.

Rows are matched on the product, the warehouse and the period together. One row per bucket: repeat the product and warehouse on each row and move bucket_start forward.

Two things the validator will tell you about:

• The same product, warehouse and period twice in one file is an error. A bucket holds one quantity, so merge the rows rather than letting the second silently win.
• A quantity of 0 imports, with a warning. It leaves an entry that contributes no demand, which is rarely what anyone means — put yes in the delete column to remove the bucket instead.

bucket_start is a plain calendar date in your account's timezone. Any date your spreadsheet writes is understood; YYYY-MM-DD avoids every ambiguity.

The export round-trip

This is the practical way to set up or overhaul a large catalogue, and it works because the export comes out in exactly the columns the importer accepts, in the same order.

1. On Policies or MPS, click Export. You can export everything, only what your current filters show, or only the rows you have selected.
2. Open the file and edit it — fill in a column across hundreds of rows, paste values in from elsewhere, sort and work through a section at a time.
3. Import the edited file back. Every row matches the record it came from and updates it.

A few things worth knowing:

• Blank cells keep existing values, so you can delete columns you are not changing and import a narrower file.
• The schedule export ships its delete column empty on purpose. An export is a picture of what exists, so importing one back never removes anything.
• Both exports stop at 50,000 rows. That clears any real catalogue, but if you are near it, export in filtered slices rather than all at once.
• Both exports come out as an Excel file by default, with CSV available when another tool needs a plain file. Either one imports back.

Next steps

• Set item planning policies — what each policy setting does, and setting one by hand
• Build a master production schedule — adding and editing entries in the app
• Planning policy settings — every setting in full, and which lot sizing rules read which
• Exports, imports and permissions — everything you can get out of planning, and who is allowed to
• Run a planning cycle — put the policies and schedule you loaded to work