P6 XML/XER Import Actions

When you import a project from a P6 XML or XER file, Oracle Primavera Cloud gives you the option create a new project, update an existing one, update the selected baselines and scenarios only, or skip importing a project. When importing a P6 XML or XER file containing multiple projects, you can set separate import actions for each project by specifying the import actions in the Import File step of the Import from P6 wizard. You can also specify the import actions and conflict actions for the imported workspace or project data objects in the Configuration step. The conflict actions are the actions the application takes when multiple matches are found for the same object.

Before you begin the import process, you must specify the target workspace into which the projects will be imported.

Note: XER refers to Oracle Primavera Proprietary Exchange Format (XER). It is a proprietary file format used by the P6 EPPM application.

Project Import Actions

Specify the import actions for each project and its baselines and scenarios in the P6 XML or XER file in the Import File step of the Import from P6 wizard.

  1. Current Schedule: Select one of the following actions for each project included in the file:
    • Create New Project: The project data is used to create a new project in Primavera Cloud. If the project already exists in the current workspace, the project will be imported into the target workspace with a numeric value appended to its project ID.
    • Update Existing Project: The project data is used to update an existing Primavera Cloud project. This option is only available if a project with a matching project ID is found in the current workspace.
    • Update Selected Baselines or Scenarios Only: The baselines or scenarios that you select for an existing project are updated in Primavera Cloud. The rest of the project data is ignored and is not imported.

      Note: When you select Do Not Import for a project, the project data is ignored and is not imported into Primavera Cloud. Global calendars assigned to the project will not be imported.

  2. Baseline: For each baseline, specify if you want to create a new baseline or update an existing one, and then select the project with which the baseline should be imported and specify the baseline name.
  3. Scenario: For each scenario, specify if you want to create a new scenario or update an existing one, and then select the project with which the scenario should be imported and specify the scenario name.

Data that can be imported from P6 includes objects stored at the Enterprise Data level and the project level. Most Enterprise Data in P6 is stored as workspace-level data in Oracle Primavera Cloud, although some project-specific data may be stored with the project. Workspace-level data is shared among the projects, child workspaces, and other objects in the workspace.

Note: Projects created in Primavera Cloud through P6 XML import have their project currency set to the parent workspace currency by default.

Workspace and Project Data Import Configuration Actions

You can set separate import actions for each workspace and project data type, providing greater control over the data that gets imported. You also have the ability to specify the action that the application takes when an object in the P6 XML or XER file already exists in Oracle Primavera Cloud or when multiple matching objects are found in sibling workspaces. Your import configuration settings can be saved and used the next time you run the import process.

Workspace Data Import Configuration Actions

Data objects in Oracle Primavera Cloud must be unique within each workspace hierarchy branch. During the import process, the application searches up and down the hierarchy of the target workspace to determine whether matching workspace objects already exist in the application. Workspace data import settings specify the action that is taken when a matching object is found in the application. Matching objects found in other workspaces in the hierarchy may need to be assigned or promoted to the target workspace to maintain existing data associations. Changes to an object's owning workspace are detailed in the list of import actions below. Separate import actions can be chosen for each workspace data type. The selected actions apply to all projects being imported from the P6 XML or XER file.

When configuring the workspace data import settings, you can choose from the following import actions:

Conflict Actions

When importing a workspace data type using Update Existing or Keep Existing, the application automatically attempts to promote any matching object found in a lower-level workspace and create an association with the workspace where the object was found. Conflicts may occur if multiple matches of the same object are found in sibling workspaces. Promoting one of the matching objects to a common parent workspace will violate the application's hierarchy uniqueness requirements and cannot be done. In these scenarios, you can select alternate actions during import configuration to resolve potential promotion conflicts. A conflict action can be set for each workspace data type:

Separate conflict actions for each data type provide greater control over your imported data. For example, you may want to insert as new any matching calendars found in a lower level, but prevent the insertion of matching resources. You can set resource objects to fail the import, enabling you to manually resolve uniqueness conflicts before running the import again.

Notes:

Project Data Import Configuration Actions

You can configure the action that is taken for each project data type imported with a project. The selected actions apply to all projects being imported from the P6 XML or XER file.

When configuring the project data import settings, you can choose from the following import actions:

For activity, relationship, and resource and role data types, select Remove from Projects to remove an object from the project if the object does not exist in the P6 XML or XER file. This ensures that a project being updated is consistent with the data in the P6 XML or XER file.

Notes:

WBS Name and ID values must be individually unique among all siblings at each hierarchical level. On import, WBS ID values are checked for uniqueness and updated according to the import action selected for WBS data. If a WBS Name conflict occurs, the matching object will be inserted into the WBS hierarchy with a numeric value appended to the WBS Name.