TXI Schedule Update PortalMaster + contractor update change log

Here's the idea. You load the master XER, then you load whatever each contractor sent you. The portal lines up every contractor activity with the master using the Activity ID, and only the Activity ID. If the IDs match, it's the same activity. If a contractor activity's ID isn't in the master, it's treated as new.

The portal works with any P6 master. It figures out which field says who owns each activity, and which activity codes to group the changes by, like work package and discipline. You can change those picks on the Load Files page. Contractors can send P6 files, MS Project files saved as XML, or Excel. The Excel can be a P6 export, an MS Project export, or their own spreadsheet. As long as it has an activity ID column and a name column, the portal finds the dates, durations, percent complete and predecessors by their headings.

Want to see it before loading your own files? Press "See an example project" on the Load Files page. It fills every screen with a made-up project so you can click around. Nothing can be downloaded from the example, and it goes away as soon as you load your own master.

For MS Project files there's no Activity ID, so the portal builds one from the task ID number plus a prefix, like MECH- in front of a mechanical contractor's task numbers. It guesses the prefix for you by trying the prefixes already used in the master, and you can change it on the Load Files page.

What the change types mean

Added means the contractor has it and the master doesn't. The portal tells you which WBS node to put it in and which activity to put it next to. It also checks the name against everything in the master, so if it might already exist you get a possible duplicate flag and it won't go in until you say so.

Updated means the activity is in both and something is different: dates, actuals, durations, percent, name, or logic.

Possible delete means the master has the activity under that contractor's code in the contractor field, but the contractor's update doesn't have it anymore. Nothing gets deleted unless you accept it.

Unchanged means it matched and nothing moved.

Loading the previous submission

Next to each contractor file there's a spot for the file that contractor sent last time, the one you already merged. It's optional, but it's the safest way to work. Here's why. If you or your team changed something in the master since their last update, like fixing logic or renaming an activity, their new file still shows their old version. Without the previous file, the portal can't tell that apart from a real change, so it would offer to put their old version back.

With the previous file loaded, the portal looks at what the contractor actually changed since last time. Anything they didn't touch is treated as your master edit, and it's kept and unticked. If both of you changed the same thing, it's flagged as a conflict so you can decide. It also stops activities you added under their code from showing up as possible deletes.

If a contractor only sends part of their scope, tick Partial on their row, and nothing of theirs will be proposed for delete.

About logic

The portal only proposes removing a predecessor when that predecessor is also in the contractor's own file. Ties to your own activities or to other contractors live in the master, so they're kept. That way a contractor update can't wipe out your cross-contractor logic.

Behind progress

This compares the contractor's update to what the master expected by the contractor's data date. If the master said it should have started and there's no actual start, that's a late start. Same for finishes. And if the contractor's finish moved out past the master finish by more than the slip setting, it shows up here too.

Needs review

These are the things a scheduler should look at before they go in: possible duplicates, possible deletes, actual dates that changed or disappeared, actuals after the data date, out of sequence progress, dates in the past with no actuals, predecessors that don't exist, an ID that belongs to a different contractor in the master, and big slips.

Building the new master

Each change can be accepted, held, or rejected. Hold means you want to talk to the contractor first. It stays out of the new master, and it shows on its own sheet in the change list. Put your name in the reviewer box at the top, and your name and the date go on every decision.

Durations are shown in days using each activity's own calendar, so a 10-hour or 24-hour calendar shows the right number of days. Every change is also tagged with the two groupings picked on the Load page, like work package and discipline, so you can filter and roll them up.

Accept what's good, reject what isn't. "Accept all clean changes" takes every added or updated item that has no review flag. When nothing is left pending, go to Build New Master. The XER keeps every table and every row of your master exactly as it was, and only touches the accepted activities. New activities get the contractor field set to the contractor's code. After you import it, press F9 to reschedule.

Before you build, the Build page warns you about logic that depends on something you didn't accept, like a tie to a new activity you rejected. After the new XER is written, the portal checks that every relationship points at a real activity and that there are no duplicate Activity IDs. If that check fails, nothing is saved.

The portal doesn't schedule. The dates you see are the dates the contractors sent. The real effect on milestones and the finish date comes after you import the new master into P6 and press F9.

Use Save review in the top bar to save your decisions and notes, then Load review later with the same files to pick up where you left off.