Header Ads

Latest posts
recent

Workplan Version Naming in Project Management - Copy Copy?


If you have enabled workplan versioning within your project templates or project you get the functionality of having multiple versions of your workplan. These versions can be rescheduled and progress updates can be done. When using Microsoft Projects (MSP) integration you'll import specific workplan versions to make changes.

If you enabled the option to automatically publish the workplan upon project creation from a project template you'll get a Working version and a Baselined Published version of your workplan. When this auto publish option is disabled you'll get initially only one Working version which you must publish and baseline in order to maintain progress and collect actual efforts from for example Oracle Time and Labour. I'll dedicate a seperate post later on the exact functionality of workplan versioning in project management.

Whenever a working version is created Oracle will add the text Copy before the workplan name. So you'll get the below situation.


A published version is created which holds the name as defined in the project template. When you make changes to the working version like adding tasks, changes dates on tasks and adding planned efforts you publish it. After publishing a new published version is created from the working version with the same name as the working version. Also a new working version is created but again the text Copy will be added to the existing workplan name. Hence you'll get a Copy Copy x 20 workplan name eventually when you have a workplan which changes regularly. Note that the workplan version name has a max of 240 characters.


Oracle is adding the word Copy to the workplan names due to the fact that workplan names must be unique within the same workplan structure - so per project. Within the details of the working or published workplan you have the option of manually changing the workplan name but still everytime Copy will be added to your new working version after publishing which in the end will be very timeconsuming.

Microsoft Projects Integration
Due to the default workplan naming behaviour you'll get problems when using the Microsoft Projects (MSP) integration functionality. When you try to import a project into MSP which has workplan versioning enabled you'll get the option to import a specific workplan version. Based on the status of the workplan version (working or published) and the type of workplan sharing you have implemented (partially shared, fully shared etc) you can do different things in MSP.

The working version should be used for adding planned effort and rescheduling. The published version should be used for progress updates.

Due to the Copy Copy behaviour and more important not visible attributes as published and working you have to guess what you're actually importing in MSP.


By default there is no option to change this behaviour so a customization is in place here. The customization will have the following functionality:
  • The default workplan version name will be the name of the related project
  • The working version will have a timestamp
  • [W] will be added before the working version
  • The version number will be added to a published version
  • [O] will be added to the initial published version (original)
  • [P] will be added to a published version
  • [B] will be added to a baselined and published version
With this workplan versions can be easily identified which will benefit importing workplan versions into MSP when using MSP integration.  Picking the published and baselined version and the latest working version can be done by just looking at the letters at the beginning of the workplan version.

Workplan versions are recorded in table PA_PROJ_ELEM_VER_STRUCTURE of the PA schema. Within this table columns exists which will tell eBS if the version is published, working or baselined. By adding a BEFORE INSERT OR UPDATE trigger to this table we are able to change workplan version names before records are inserted or updated. Within the table also other structures are maintained by Projects so we will make sure we're only changing the workplan structure :-).

The system will do inserts when creating working and published versions and will do updates when baselining an existing published version and publishing the current working version.

As described in a previous article about rolling back previous workplan versions (see Rollback a previous workplan version in Project Management) the user will get the option to define a name for the new working version. When following the customization there is no need any more to provide this option to the user as this is handled by our trigger. With a small personalization the field can be hidden from the screen.

Trigger PA_PROJ_ELEM_VER_STRUCTURE
The trigger we need is a BEFORE INSERT OR UPDATE trigger. Within the trigger the workplan version name is generated and seperate codeparts will execute when doing an insert or an update. Find below the trigger needed to have the new way of workplan version naming.

CREATE OR REPLACE TRIGGER APPS.XXX_PA_PROJ_ELEM_VER_STRUC_IU
BEFORE INSERT OR UPDATE
ON PA.PA_PROJ_ELEM_VER_STRUCTURE
FOR EACH ROW
DECLARE
projName VARCHAR2(30);
versionName VARCHAR2(240);

BEGIN
  
   SELECT NAME INTO projName FROM PA_PROJECTS_ALL WHERE PROJECT_ID = :NEW.PROJECT_ID;
   versionName := '[';
  
   -- determine status of workplan versions
   IF :NEW.ORIGINAL_FLAG = 'Y' THEN --initial version of workplan (original)
    versionName := versionName || 'O';
   END IF;
  
   IF :NEW.CURRENT_FLAG = 'Y' THEN --baselined version of workplan
    versionName := versionName || 'B';
   END IF;
  
   IF :NEW.CURRENT_WORKING_FLAG = 'Y' AND :NEW.STATUS_CODE = 'STRUCTURE_WORKING' THEN --current working version
    versionName := versionName || 'W';
   END IF;
  
   IF :NEW.STATUS_CODE = 'STRUCTURE_PUBLISHED' THEN --workplan is published
    versionName := versionName || 'P';
   END IF;
     
   IF :NEW.CURRENT_WORKING_FLAG IS NOT NULL THEN -- to prevent updating other structures (like Deliverables)
  
    IF INSERTING THEN -- create working and/or published versions
        versionName := versionName || '] - ' || :NEW.VERSION_NUMBER || ' - ' || projName;
   
        -- add systimestamp to working version
        IF :NEW.CURRENT_WORKING_FLAG ='Y' THEN
            versionName := versionName || ' - ' || to_char(systimestamp, 'HH24:MI:SS.FF6');
        END IF;
        :NEW.NAME := versionName;
    END IF;
  
    IF UPDATING THEN -- for publishing and baselining
        IF :NEW.CURRENT_WORKING_FLAG ='Y' THEN -- publish working version
            versionName := versionName || '] - ' || :NEW.VERSION_NUMBER || ' - ' || projName || ' - ' || to_char(systimestamp, 'HH24:MI:SS.FF6');
            :NEW.NAME := versionName;
        END IF;
  
        IF (NOT :NEW.CURRENT_FLAG = :OLD.CURRENT_FLAG) THEN --baselining published versions
            versionName := versionName || '] - ' || :NEW.VERSION_NUMBER || ' - ' || projName;
            :NEW.NAME := versionName;
        END IF;
    END IF;
  
   END IF;
   
   EXCEPTION
    WHEN OTHERS THEN
        RAISE;
END;

See below for the workplan version naming functionality after applying my trigger.

Powered by Blogger.