Primavera P6 XER Import: Best Practices

Most schedule intelligence failures in integration projects are not algorithm bugs—they are import gaps: wrong encoding, missing baselines, unclassified LOE, or silent drops of relationships. This guide focuses on getting Primavera P6 data into Bellator’s normalized schema cleanly so every downstream endpoint sees the same network.

What the XER import API does

POST /api/v1/import/xer accepts a P6 .xer file and returns a normalized schedule plus a conversion report. That JSON is the same shape used by health scoring, CPM, DCMA, and other forensics APIs.

Step	Owner
Export XER from P6	Scheduler
Upload to /import/xer	Integrator
Review warnings / mapping stats	Both
Call analysis APIs with normalized_schedule	Integrator

Full detail: Import guide.

P6 export checklist (before you leave the tool)

1. Include the projects you mean — multi-project XERs surprise importers; export the EPS node you intend to analyze.
2. Baselines — if you need BEI, baseline compare, or delay methods, ensure baseline dates are present in the export set your organization uses.
3. Calendars — global vs. project calendars should be consistent; odd calendar assignments create false criticality later.
4. Activity IDs stable — forensic time series needs stable IDs across updates.
5. Minimize junk open ends in P6 first — import will faithfully preserve dangling logic.

Encoding: the silent breaker

P6 XER files are often Latin-1 (ISO-8859-1) even when your stack assumes UTF-8. Bellator uses encoding detection (including Latin-1/UTF-8) so resource and activity names do not mojibake mid-pipeline.

Practice:

• Do not “fix” XER by opening in a text editor and re-saving as UTF-8 unless you control the full byte pipeline.
• If names look wrong after import, check the conversion report before blaming the parser.

Classification: LOE, summaries, and milestones

Network topology statistics (open ends, relationship mixes, float distributions) should exclude LOE, summary, and hammock tasks. Bellator treats this as a platform rule when task_type is set.

Prefer native flags + auto classify

curl -X POST "https://api.bellatorsi.com/api/v1/import/xer" \
  -H "x-api-key: YOUR_API_KEY" \
  -F "[email protected]" \
  -F "auto_classify_task_types=true" \
  -F "use_prefix_classification=true"

Prefix conventions (when P6 UDFs are messy)

If your enterprise standard uses name prefixes, enable prefix classification. Common patterns documented in the import guide include markers such as LOE-, SM-, and PP- for planning packages.

Example activity names:

Activity name	Intended type
LOE-CM Support	Level of effort
SM-Area 3 Summary	Summary
INST-Cable Pull A	Normal / task dependent

Worked flow: XER → health → DCMA

import requests

API = "https://api.bellatorsi.com/api/v1"
HEADERS = {"x-api-key": "YOUR_API_KEY"}

with open("programme.xer", "rb") as fh:
    imp = requests.post(
        f"{API}/import/xer",
        headers=HEADERS,
        files={"file": fh},
        data={
            "auto_classify_task_types": True,
            "use_prefix_classification": True,
        },
        timeout=120,
    )
imp.raise_for_status()
payload = imp.json()["data"]
normalized = payload["normalized_schedule"]
print("import warnings:", payload.get("warnings") or payload.get("conversion_report"))

health = requests.post(f"{API}/health/score", headers=HEADERS, json=normalized, timeout=60)
health.raise_for_status()
print("health", health.json().get("score"), health.json().get("grade"))

# Add status_date / targets as required by your DCMA package, then:
# dcma = requests.post(f"{API}/health/dcma-14-point", headers=HEADERS, json=dcma_body)

Keep the same normalized object in memory; do not re-key activity IDs between calls.

Conversion report: what to fail the build on

Treat these as integration errors, not warnings you ignore:

• Zero activities parsed
• Relationship count collapsed unexpectedly vs. P6
• All tasks unclassified when you expected milestones/LOE
• Missing project start when your analysis requires it

Soft warnings (unmapped UDF, unknown calendar name) can be logged and triaged.

Common failure modes

Symptom	Likely cause	Fix
Every task critical	LOE/summary included in topology	Classification + task_type
BEI blank / fail	No baseline dates	Export baseline data; map fields
Garbled names	Encoding mishandled upstream	Rely on API detection; avoid manual re-encode
Duplicate IDs	Multi-project clash	Export single project or namespace IDs in P6
DCMA open ends explode	True P6 open ends	Repair logic in P6, re-export

Security and ops notes

• Prefer server-side import with API keys; do not embed keys in browsers.
• XER can contain commercial volumes—respect tier payload and task limits.
• Import is a normalize billing class in Bellator’s model: analysis calls are separate successful completions.

Next steps

• How we use the API: from health score to DCMA
• Import guide and task schema
• MS Project users: save as XML and use /import/mpp (binary .mpp is not uploaded raw)

Sources

• Oracle Primavera P6 — XER exchange format (vendor documentation)
• DCMA PAM 200.1 — why classification and open ends matter to reviewers
• Bellator Import API documentation