replace resources

Dear All

I have inherited a P7 schedule plan with 2 different resources (one Material and one labor) in common with another project. As for enterprise’s policies I need to separate the resources from other project. (both resources have actuals)

I made some new “user defined fields” and copied Budgeted, Actual and remaining units of the resources in them and tried to delete the old resources and reassign the new ones using these user defined field, but I wasn’t successful. I could not do it neither with global change nor with import-export excel files

Does anybody know how can I manage that?

the only good point is: I just have Labor resource and one Matrial

A
Ali Pandidan 👤 Member for 13 years 6 months

Gracias Rafael

I agree with you... it is very delecate decision to use enterprise or seperated resources for projects, but with the help of a colleauge I could finally manage the problem with a very easy solution:

First I changed the name of the resource to something strange that can later be distinguished easily.

Then I exported one of the projects (project A) as an XER file.

then I re-renamed the resource as it was in my PRIMAVERA data base and inported the project A again, but in import optional fields I changed the MODIFY for resources I choosed "Insert New" action.

the new project entered in data base with its new resources and the problem solved.

 

A
Ali Pandidan 👤 Member for 13 years 6 months

Gracias Rafael

I agree with you... it is very delecate decision to use enterprise or seperated resources for projects, but with the help of a colleauge I could finally manage the problem with a very easy solution:

First I changed the name of the resource to something strange that can later be distinguished easily.

Then I exported one of the projects (project A) as an XER file.

then I re-renamed the resource as it was in my PRIMAVERA data base and inported the project A again, but in import optional fields I changed the MODIFY for resources I choosed "Insert New" action.

the new project entered in data base with its new resources and the problem solved.

 

R
Rafael Davila 👤 Member for 22 years 3 months

I do not use P6 but suggest adding a prefix to your project resource codes and calendar codes. 

Say you have for Masons on job 01 the code MA and for job 02 you are using the same code, then use 01MA and 02MA respectively. In this way the software will not be confused as to the details for each job. It might be that the resource limit for Masons on job 01 is 20 while on job 02 is 70.

The same goes to calendars. Say you have for Calendar 1 on job 01 the code 1 and for job 02 you are using the same code, then use 01CAL1 and 02CAL2 respectively. In this way the software will not be confused as to the calendar details for each job. It might be that the work hours and non-work days for the calendar on job 01 are different to those on job 02.

Depending on your software it might be that the rule shall also be applied to other codes such as codes for user defined fields and activity codes (different from Activity ID). 

This is an issue inherent of shared codes in P6 database structure, once a job is imported into P6 database it is no longer a stand alone job and will share some codes. The way P6 database is structured you cannot have pure stand alone jobs on a single database otherwise it would not matter how you define your codes on each job.  If locally you have a single job you might not notice the issue.

In Spider Project we can have as many separate databases we want on a single computer, every single job is a separate database file while a portfolio of jobs is another separate database file. If we import several jobs to a portfolio we will have similar issues. If we keep our jobs as stand-alone, meaning not belonging to a portfolio, then we will not have such issues. As a matter of fact I rarely use Portfolios and keep my jobs under separate files. In no way I am saying Portfolios are of little value, it all depends on your needs. For some people it makes sense to keep all jobs under separate database files, for some it makes sense to keep all jobs on a single portfolio while for others it makes sense to have a combination. I use a combination where most jobs are under separate database file, even jobs from the same clients I keep on separate database files. 

Good Luck

Forum Sponsor

Top Posters

Josephus Enot
1 posts
Julian Pegg
1 posts
Peter Nagy
2 posts
Raymund de Laza
17 posts
Syed_Asad
0 posts
Tony Greyvenstein
0 posts
Ahmed Al-Jubouri
13 posts
Umar Alvi
3 posts
Sibusiso Mahlalela
0 posts
Michael Samanyayi
3 posts