Integrate Primavera and ERP around a shared status date

Choose one project and a small set of work packages. For example, the pilot might compare approved budget, recorded actual cost and the planner's selected progress measure by package at a reporting cut-off. State which sources are authoritative for each measure and what the report is intended to support.

Do not begin by synchronising every available field. A narrow reporting question reveals the mappings and timing rules that matter. Finance owns the financial basis; the planner owns the scheduling basis; the integration owner maintains the transfer and its audit history.

Oracle's P6 baseline guidance describes snapshots used for comparison. A baseline is not the same thing as the current update, and changing a baseline is not merely a data-cleaning action. The pilot should identify both the approved comparison basis and the current source snapshot without altering either.

In this fictional scenario, the ERP extract includes transactions through Friday month end. The P6 update represents Wednesday. The report should display both dates and mark the comparison as using different cut-offs. It must not imply that Wednesday's progress already reflects all activity associated with Friday's recorded cost.

The reporting owners can choose to obtain an aligned schedule update, use an agreed earlier financial cut-off, or present the mismatch explicitly with a limitation. The integration should implement that approved choice. It should not interpolate two days of progress or move the schedule data date to make the screen look consistent.

Also distinguish transaction date, posting date, extraction time and source update time. A late posting may affect a prior period under finance's rules. Preserve the original run and the corrected run so the change in the report can be explained.

Create a cross-reference between ERP project and cost dimensions and P6 project, WBS and relevant activity identifiers. Define whether the relationship is one-to-one, many-to-one or an approved allocation. Keep the effective date, owner and rationale for each mapping.

A cost line split across packages needs an explicit allocation basis. The allocated amounts must reconcile to the original value, and the report should avoid counting the source again at a parent level. A WBS hierarchy is not permission to sum every parent and child total together.

For unmapped records, retain their count and value in an exception section and in source control totals. Excluding them from a package comparison may be appropriate while the mapping is unresolved, but excluding them from reconciliation would hide missing data. Make the coverage of the report visible.

Schedule duration progress, physical completion and financial consumption answer different questions. Select the measure appropriate to the report and document its source definition. Do not average percentages across activities unless the weighting and meaning have been approved by the planning owner.

Units matter as well. Installed metres, tested circuits and invoiced value cannot be added as though they were the same measure. If the business uses earned-value or another weighted method, the responsible specialists must define and validate it. The integration's job is to carry that method accurately, not invent it from available fields.

Before building a trend, check whether the definition or package boundary changed between periods. Preserve historical mappings or provide an explicit restatement. Otherwise a new coding structure can look like a sudden improvement or deterioration in project performance.

For the pilot, source accounts are read-only. The integration writes to a controlled reporting store with a run identifier, source timestamps, mapping version and validation results. It cannot reschedule activities, approve budgets or post accounting entries.

Version the interface contract and validate required fields, identifiers and units. A source upgrade or renamed field should fail visibly rather than silently populating blanks. Limit access to commercial and personal information that the report actually needs.

Handle repeated requests and delayed responses deliberately. The AWS guidance on idempotent APIs explains the importance of stable request identity for safe retry behaviour. In this bridge, a rerun should create a traceable replacement or identical result according to the agreed rule, without duplicating financial rows.

Establish the baseline effort required to assemble the existing report, including mapping corrections and late clarifications. During the pilot, measure reconciled coverage, unexplained differences, reviewer effort and time to produce an accepted view. Do not call a faster refresh a success if planning and finance cannot explain it.

Test an unmapped cost code, a changed WBS relationship, an out-of-order update, a repeated extract and a source schema change. Compare source totals with imported, excluded and rejected records. Every difference needs a reason and owner.

Stop publication of the affected report if totals fail, a mapping changes without approval or the source basis is uncertain. Preserve the last accepted snapshot and its date, clearly marked as historical. Use the established manual reporting process while the team corrects and replays the failed run. Reconcile before declaring the new snapshot current.

The pilot's deliverable is a report whose basis can be reproduced by the planner and finance reviewer. Once that works for the selected packages, expand coverage gradually. Write-back remains a separate project with different authority and recovery requirements.

1. Agree one reporting question, source owners and the cut-off rule.
2. Build an approved mapping and retain all source records in reconciliation totals.
3. Run the Wednesday–Friday mismatch and failure cases through the read-only bridge.
4. Review accepted reporting effort and exception handling before adding more packages.