Imports

Very little about a construction site starts life in SimOps. The programme is in P6, the floor plans are in the drawing office's CAD, the survey is a shapefile, and the defect register lives in whatever system the contract names. The Imports panel (Z) is the single place those things come in — a stack of source cards, each opening its own workflow in place.

What comes in

• Floor plans (DXF). A CAD drawing becomes a per-building, per-level Floor plan — rendered as native vector by default, with raster as the fallback.
• Programmes. A P6 .xer export, a native Asta Powerproject .pp file, or a .pdf print of the master schedule, staged as work breakdown, activities and logic.
• Reference layers. A shapefile or GeoJSON landing as a static reference layer — buildings, zones, roads: the Reference features the rest of the app reasons about.
• Site data. A SimOps GeoJSON or CSV export restored back into a site: workers, plant, areas, deliveries, points of interest, text labels and reference features.
• Defects. A per-contractor export of the contractual quality register (see Defects).

Most cards answer to the manage-any band (entity_manage_any) — importing is a site-shaping act. Reference layers additionally sit on layer_manage, the programme's write verbs on work_plan_manage, and the defects card is capability-derived from defect_view / defect_import so a contractor who may read their own register sees the card without being handed the upload.

Bulk import: look before you commit

A bulk file is never applied on sight. Upload runs a dry run first, which parses the whole file and reports every row into one of four buckets — valid, warning, error, or skipped (kinds SimOps deliberately declines to rebuild from an export, like casework and stock). You read the preview, exclude what you don't want, and only then commit. Nothing is written until you do, and the prepared import is consumed on commit, so a double-submit is refused rather than duplicated.

The programme: staged, then promoted

A P6 import is the one that repays understanding, because it deliberately does not turn 450 activities into 450 things on your plan.

A Programme is a durable, site-scoped series — never a file. Each handed-over file lands as an immutable Programme revision under it, and the whole revision is held in Staging: browsable, inert, touching nothing. What it was staged from is carried on its face, because fidelity differs — a P6 XER export and a native Powerproject file both carry full logic, while a PDF print is degraded: lines and dates only, day-precision, and blind to logic. The badge says which, so nobody reads a PDF's silence as evidence of absence.

Promotion is the curated act that follows: a coordinator picks activities and mints one Work line per activity, pre-filled from the remembered band mapping. Logic between promoted lines materialises as dependencies behind a mandatory preview that says how many edges will appear and how many are already violated. The inverse verb is detach.

When a newer revision arrives, nothing moves until a human says so. The Sync review reads the new revision against the standing basis and groups what changed into facets — dates, names, status disagreements, orphans, new codes, logic edges — which are accepted per facet, not per row. The commit is a single Apply: planned windows and names track the revision, while placement, contractor, tokens and evidence are preserved. Apply never mints lines; a new code is a signpost back into promotion.

Read the other way, the same data becomes a variance lens: a per-line signed slip (Slip chip) comparing the planned window against site reality, derived at read time and never stored, toggleable on the work-line board so switching it off leaves the board untouched.

Upload lives here; browsing and promoting the programme lives in the Work home's Plan tab (W), where the lines it mints already are.

Two planners, one door: P6 and Powerproject

Not every programme is a P6 programme. A main contractor planning in Asta Powerproject hands over a .pp file, and that file goes through the same door as an XER — you upload it against the series exactly as you would an export, and it lands as a revision badged Powerproject.

A .pp is a second full-fidelity format, not a degraded one. It carries the same things an XER does: every activity and milestone, the work-breakdown bands, the target and scheduled dates, actual starts and finishes, durations, calendars, the activity-code libraries, and the whole logic network with its lag — so a .pp revision promotes, materialises edges and syncs like any other, and its apply moves both the revision and the logic basis. Mixing formats across revisions is an ordinary delta: an XER after a .pp, or a .pp after an XER, reads as changes, not as a fresh start.

Three things a Powerproject file does not carry, and no amount of reading will find them:

• late dates — the backward pass a P6 export brings with it,
• total float, and
• the critical path flag, unless the planner happened to have longest-path display switched on when they saved.

They are absent because the file does not hold them, not because the import lost them: SimOps shows a — rather than inventing a number. The badge's tooltip says exactly this on every .pp revision.

When a file is refused

Unreadable bytes are refused at the door, before anything is created — upload a spreadsheet or a Word document and you get "not a programme SimOps can read" and no revision row to clean up. A file that is a Powerproject database but cannot be turned into a programme lands as a failed revision that names why, in the refused-row list under the revision list:

What happened	What to do
The file is password-protected	Re-save it from Powerproject without a password.
It was written by a Powerproject version SimOps cannot read	Re-save it from a supported version, or send a P6 XER export instead.
It holds more than one project	Split it so each uploaded revision carries a single project.
It stages no activities	Check the programme chart was actually saved into the file.

An XER has the same shape of refusal: a file that says it is an XER but carries no project, WBS or activity tables fails with "no programme tables", and wants re-exporting from P6.

The fallback

A Powerproject seat can also export a P6 XER, and that export lands through this door today with nothing new to configure. It is the fallback rather than the road, because the export flattens things on the way out — codes, lags and baselines are pre-folded, and it adds a per-revision dialog somebody has to remember to drive. Send the .pp where you can.

What deliberately isn't here

Permit XLSX import is not an Imports card. It moved to the permits board, where the permits it creates live — see Configuring permits.

In a demo world the DXF import is read-only. The card is visible — you can walk up to the door and see what it does — but its action is locked with a "read-only in the demo sandbox" marker, and the import route itself refuses outright, because the raster pipeline is disabled there for memory safety. A deliberate carve-out, not a bug: on a demo site the door can be shown, never opened.

See it / try it

Where to go next

• Configuring permits — the permit XLSX intake, which is not on this panel.
• Defects — the contractual register — the defect import in detail.
• Spatial & temporal model — what reference layers become once they are in.