Your Hyperion Planning application may or may not have multiple Plan Types depending upon the clients requirement.

If it is only one Plan Type in your application then Plan Type association concept is pretty straight forward which Hyperion Planning handles by default.

But while designing a multiple Plan Type application you should have clear understanding on the plan types association with members and their accessibility within other Plan Types and artifacts.

Keeping Multiple Plan Types in your application may be to meet the specific requirement of the client or any implementation logic used by the Application Developer or any other planning modules like Workforce or Capex.

Hyperion Planning saves spaces by using a reference to the source Plan Type in background if a member is used in multiple Plan Types.(Except the Member is not linked to the source Plan Type).

So, for a multiple Plan Type Hyperion Planning application we will clear our doubts by going through the following points.

1. Source Plan Type of a Member and
2. Valid for Plan Type of the Member 

1.Source Plan Type of a Member :- Plan Type in which You want to store the value for the Member.

2.Valid Plan Type of a Member :- Plan Type from which You want to refer the value of the member stored in source Plan Type.

Dimension Members and Plan Type Association :-

Dimension Level 

By Default generation 1 Members in standard Dimensions are enabled for all Plan Types in application and we can not disable these for any Plan type.

We can be choosy for enabling generation 1 members in Plan Types for Custom Dimensions.

Any Other Levels

For applications sharing data between Plan Types:-

We can enable a member to share its data in another Plan Type.For doing so we just enable the member in another plan Type.Although the data is stored in the source Plan Type of the Member.

Following Rules apply:-

1. Source Plan Type and valid for Plan Type should have same dimensionality.
2. The member should not be linked with "HSP_NoLink" UDA.
3. A member can't be enabled in another Plan Type if its parent in source Plan Type is not enabled for that Plan Type,so enable member's parent in that Plan Type first.

Data updation and Accessibility :-

1. Data can be updated from Source Plan Type only.
2. Data in another Plan Types is Read only and retrieved at run-time from Source Plan Type.

For Example :- Consider an Application having 2 Plan Types( DB1 and DB2) and "Headcount" and "Central Expenses" as Members in account dimension.

Members in Source Plan Type are writable.

Members in other Plan Type are read-only.

Members in "DB2" are read only this is because behind the scenes(At Essbase side) Hyperion creates Members in other Plan Types as Dynamic Calc and a formula of Xref to refer the value from source Plan Type.Have a look at the outline from EAS console.

DB1(Source Plan Type) :-

DB2(Valid for Plan Type) :-

For applications not sharing data between Plan Types:-

If Your Plan Type is having the same member enabled in another Plan Type and you want data to be stored in separate- separate Plan Types then just add "HSP_NoLink" UDA with that Member. 

Following Rules apply:-

1.You will do so for Plan Types having same dimensionality.(Because Plan Types having different dimensionality obliviously can't refer data amongst one another.)

2.After assigning "HSP_NoLink UDA" your Member will be writable in its local Plan Type and will store data also in local Plan Type itself.

DB1 (Source Plan Type) :-

DB2(Other Plan Type) :-

Have a look at attached UDA "HSP_NOLINK"

-: Thank You  :-

Author - Yashwant Sawai