Planning Area Change

[Former Member]

Hi all,

I am currently undertaking a planning area change (key figure settings). We have a client level daily backup policy in place.

But in order to mitigate any risk of loss of data. I need to evaluate 2 options.

1. Create a duplicate planning area (copy of the existing PA) and copy the entire planning version to the duplicate PA (Both PA based on the same MPOS).

2. Take planning area backup in an Infocube.

Could you please guide me to appropriate source so that I can find arguments in favour of either options.

Thanks

Ankur Shrivastava

[Former Member · Accepted solution]

Hi Ankur,

Both the options are equally good. If you have Server capacity constraints then back to BI is better, since when you take back up into a Info cube you are ensuring that the data is permanently there for all users including the management to view. where as if it is into a simulation version then you are using that much space in the server and when you take the next back up the earlier details just wipe out. Also not everybody may be comfortable in navigating in APO.

It is suggested that having both methods as back up is an ideal situation as it reduces risk to a minimum.

Thanks,

Harsh

[aparna_ranganathan]

Hi Ankur ,

Since you already have a daily backup policy , there is no need to create a duplicate planning area . In most companies whenever they do a planning area change , they dump the planning area to a back up cube before migration. So there is absolutely no need for a duplicate P.A

Thanks

Saradha

[Former Member]

Hi Ankur,

I would suggest create a MASTER Infocube which contains all the original data. From this master, create WORKING infocube and use it for your day today works.

Copy data from WORKING infocube to your required planning area. So, as daily practice, take backup of your planning area data to WORKING INFOCUBE(s) and finally update to MASTER Infocube.

In this scenario, say for eg, if yesterday data has gone means you can always get and regenerate from MASTER Infocube.

Regards

R. Senthil Mareeswaran.