Types of plan Vs Condition of authorization

Similar Questions

• No. counterpart. types of Plan in HP

  Hi Expert,
  
  I would like to know if there are any rules or guidelines to decide in what circumstances, we must structure separate plan types in an application of HP?
  
  I understand a typical rule would be if separate dimensions are needed for the different set of data, then may need separate plan types, but want to deepen the following situations:
  
  Situation 1:
  
  Say for 1 set of data (say, A data set), we need dimension 1, 2
  For another set of date (i.e. the data set B), we need 3 dimensional
  
  For the two set of data, there are 5 other common dimensions that are required both by
  
  We face with only 1 plan installation type option is and the members of the configuration of dimension 1 and 3 in the same dimension, webform control for A data set, select dimension tree 1 and the data set B, select a rating of 3.
  
  Or we in place 2 types of plan.
  
  You want to check what are the factors we have to consider the possibility to separate the type of plan or not?
  
  Situation 2:
  
  We have 2 groups of data, both groups require the same set of dimension. But we expect that the volumn of the two groups would be big enough and although their dimensionality is the same, but the 2 groups of data are independent of each other.
  
  We wonder if we should divide it into 2 types of plan, to avoid any performance issues, when more data are entered?
  
  Say that we have about 11/12 dimensions, in which the account dimension (which is dense), have about 500-700 for each group, then 4-5 dimensions will be approximately 500-1000 members each and you want to store about 5-7 years of data, in combination with about 20 scenarios/versions. Is - this large enough to justify / better to have separate plan types?
  
  Want to know, what would be the limit / no. threshold. dimensions / members to decide to have 1 or more types of plan? or what other considerations?
  
  Thanks in advance!

  Hello

  I took the content slot of OTN. Please understand your condition properly, based on which defines the types of Plan.

  ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  A few points of clarification:

  I saw a good number of customers use several types of plan, when it probably wasn't necessary. For example, I had a client create three types of plan which were identical, except for the entity dimension. They are trying to reach some type of workflow/approvals from the data of a plan type to another... all this because they did not know about the features in Hyperion Planning approvals. Cosolidated their application to a type of unique plan and they saved us much maintenance and worsening.

  As a general rule, you break an application in several types of plan due to one of two reasons:
  (1) you have the granularity of the data significantly different between the two databases.
  (2) you have a domain differs between the two databases.

  Workforce planning is a good example of the point #1. PAM includes data at the granular level employee, is not your typical P & L cube case. If you already have a cube of P & L type, and you want employee-level details, it makes sense to create a separate plan type.

  Another example of the point #1 can be real data vs data Plan. I had clients who wanted to analyze their actual data at very granular GLG, but they have planned at a much higher level in the account structure. When executing the planning business rules, you want your blocks Essbase dragging around all these GL accounts granular you will never use as part of a Plan? N ° it therefore makes sense to break out in a different plan type.

  Example # 2 can be P & L data vs data of balance sheet. While many people can and do not put these accounts all in the kind of dieting, it can sometimes be more effective to get out them. (Thus reducing the size of the global block of each database.)

  One last point... you CAN add strength and CapEx to your plan types existing once they have been created/made. However adding additional map types (except enrolment or Capex) would require recreate you the app.
  -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  Hope the above examples helps you to understand the concept and define your types of plan...

  Thank you

• Not available in the Type 3 Plan attribute

  Hi all

  I use EMP 11.1.2.4. When I run the application studio financial statement, I can see my attribute fades in the Plan Type 1 but not in the Plan Type 3. That is, if I have a link and develop a report against the foreground Type 1 can drag and drop my attributes in the lines, columns, etc. However, when I link the report against the Plan Type 3, I'm more able to see the attribute fades as a selection available for drag and rop in lines, columns, etc.

  Thanks in advance for any help.

  Can you confirm that the DB Fr for Plan type 3 connection is not a planning connection? If there is a link to planning, you will not be able to see the size of the attribute that those are exposed through an DB EN Essbsase connection.

  Of course, the assumption is that the dimension that has the size of the attribute is valid for the type of Plan 3

• Option to uncheck a type of plan when you create a new planning application

  I create a new planning application where I can have only 2 types of plan. I want to disable the third type of plan that is established not to when I press the button create, but the boxes are grayed out. Has anyone run into this situation before and I did fix you?

  Please see attached screenshot.

  Comes to learn that it is a known problem with applications of budget and planning in the Public sector. As noted in the planning 11.1.2.4 new version of document:

  Public sector planning and budgeting

  l 20114042 - during the creation of new sector Public planning and budgeting applications with this version, all non - HCP available plan types must be selected, for example, plan1, plan2 and plane3. If each of these types of plans are not selected, creating application errors will be produced.

  the lines in the forms that you save and open, l 19896540 - budget request, are reduced. This collapse of the line hierarchy occurs only when you open packages of decision data collection forms.

• Condition of authorization ISE

  Hello

  I have a requirement to configure ISE so that it makes a distinction between switches in a switch stack. Anyone know if there is an expression that I could use in a condition of authorization that allows to get the following:

  If a device using MAB connects for 1 in the battery it will assign to VLAN 10.

  If the same device connects for 2 in the same stack that will be assigned to VLAN 20.

  Thank you

  Terry

  You can use the interface numbering as a condition, the switch sends information on the numbering of the battery. I don't remember the specific av pair, but you should be able to find it in the details of the live journal.

• What is the purpose of the type of plan in hyperion planning?

  why we use the type of plan what is the purpose?

  Plan types allow you to break a budget or forecast of components - serving slightly different purposes each.

  You might have a Plan Type where you budget data of salary & compensation for employees. Where analytical budgets can be moved into another Type of Plan which users budget expenditures not compensation & revenue to build a larger budget. A third Type of plan could be used to review the budget in a reporting application.

  Each Plan Type uses a separate Essbase database. The type of database can be either ASO or OSB Office.

• Is it possible to migrate an application and drop one of the three types of plans?

  Migrating applications is 11.1.1.3 to 11.1.2.2.300.  Try to migrate an application and a company wants to only 2 of the 3 types of regime to be brought back.  Is there a way to do this?  Or to remove or hide the type of 11.1.2.2.300 if all 3 are migrated on?

  Here is what has been tried, but he cuased a problem in the DB:

  • Migrate an existing application that originally had 3 types of plan. Plan dropped type 1 and kept plan types 2 and 3
  • Created 2 types of plan when creating the application in 11.1.2.2
  • Initially built the contour using 11.1.1.3 LCM export dimensions and had to modify the XML to import. Edited plan 2 and made this plan type 1. Edited plan 3 and made this plan type 2. Had problems with the LCM/xml and finally finished by using the extractor contour and loading by using the outlineload utility. Dimensions are now based.
  • Initially, wrong Bishop Calc. To change the value of the hsp_systemcfg for the type of plan table = 2 instead of 3 as it was in the table.
  • Calc Mgr shows that type of plan 2 and no plan to type 1.

  Any ideas?

  Probably the best way to rebuild the application and then reload the hierarchies or hack files XML of LCM, if 11.1.2.3 then you would be able to create/delete plan types.

  See you soon

  John

  http://John-Goodwin.blogspot.com/

• Maximum number of user defined dimensions for Hyperion application with several types of plan

  Dear,

  I know that the maximum number of dimensions is 20 for an application and for better performance, we shouldn't have more than 12 years, but if we plan different types? I found the below in the psb user guide:

  "Applications are supported up to 20 dimensions. However, optimal performance, not more than 12 dimensions must be attributed to each Type of Plan. »

  I have therefore 20 dimensions by plan type, or application? and that optimal performance it should be 12 dimensions by plan type, not by the application?

  Any advice, please?

  Thank you

  Hello

  The limit is for a planning application for a type of plan... You can add dimension to choose to exist for a type of plan in particular.

  All members of custom dimension that there will be for only this type of regime...

  Kind regards

  Sourabh

• Hyperion Planning 11.1.2.1 Custom Types Dimensions/Plan

  I was hoping to get some expertise on an issue I have with Hyperion Planning. We are currently working on the 11.1.2.1 environment and we have 2 types of active plan implemented;

  Plan Type A - dimension of active channel (Custom)

  Plan B - channel (Custom) inactive dimension Type

  For the channel size, is it possible to transform the Plan Type B as a valid plan type in 11.1.2.1? I didn't know if it could only be configured on the creation of the application or not.

  If we activate the dimension for the type of plan, I understand this will cause a number of issues, for example to set the POV for all Web/reports/Scripts for Plan Type b Forms. We are just assessment of the impact, have previously, anyone had any experience of this?

  Thank you very much for your help!

  For the application of EPMA you doing the same thing of EPMA, change the properties of dimension and deploy the application, here is the link:

  Changing property values

  See you soon... !!

  Rahul S.

• Security filters for the Types of Plan of ASO in 11.1.2.3

  
  All,

  My understanding of security filters for the Types of Plan of ASO in 11.1.2.3, is that they are not as robust as Types of Plan of traditional BSO are. Is this true? If so, can I restrict access to users who are assigned to the ASO Plan Type to display only and read/write on the private accounts and entities (for example)?

  Thanks in advance.

  The limitation that you refer is a bit confusing.  In summary, the planning will not create Essbase security filters on a data base of the ASO.  However, this does NOT mean that you will not have security on the Type of Plan of ASO.  Instead, it depends on which tool you are using to access the Type of Plan of ASO.

  If you want to connect to the ASO Plan type planning or tool (e.g., EN) with a connection to planning, you'll be fine.  The planning gets its security filters Essbase security information.  It gets its information from the relational repository security.  So the planning and the EN (with a connection to planning) are supported.  Security works as you would expect, even for the Type of Plan of ASO.

  If you want to connect on the type of Plan of ASO with something that requires a * Essbase * (not planning) connection, it only is not supported out-of-the-box, because planning will not create filters on the ASO cube (at least not yet in this version).  However, there is nothing that prevents you from creating filters on your own.  I usually manage all of my safety in an Excel/VBA model that allows me to export/import the Essbase security planning and.  This allows me to apply specific to Essbase filters after a refresh (by importing the custom filters via MaxL).

  So the question is... what tool you will use to access the Type of Plan of ASO?  If you use a connection of planning, you're good.  If you use a connection of Essbase, should be a personalized approach.

  Hope this helps,

  -Jake

• ODI - Size Build for several types of plan

  Hello

  Application of classical planning on 11.1.2.2

  I have a version of dimension for an application with two types of plans.   The entity dimension is one of the six required and is shared by the two types of plans.  So when I reverse engineer my target planning app in my model target in ODI, there are four new fields.  Two fields of aggregation for each plan type and two plan of fields of type for each type of plan.   I can then map my SQL Server source that has all four.

  However, I have exactly the same to a custom dimension called 'Project' and when I reverse in the dimension of 'Project' target only two fields for the aggregation appear for each type of plan.   The Type of Plan of those who are not there so I can't have my model source card.

  This is normal and it is assumed that this dimension is shared and the two contours will be updated?  Or something is wrong and I should / need to have these "Type Plan" for each type of plan on the target model?   The fact is required dimension feature have nothing to do with it?  I rechecked and the two Types of Plan are verified in the screen "Administration-> Dimension.

  Just confused with ODI runs.  No sense sometimes

  The two types of plan are updated every hour.

  As I said, when loading dimensions in Hyperion Planning with ODI, ODI adapters that connect to the planning will limit the options on the dimension build based on the rules that apply in Hyperion planning.

  So what I mean is that if you can not do in planning directly then used ODI will give the option to do either.

  Remember you when loading dimensions in planning directly (in the user interface or through ODI) you are loading in planning first and then it is a refresh of Essbase growing dimensions and members to essbase and plan types in Essbase. Loading dimensions in Planning with ODI you're ALWAYS updated of all types of plan. The options you see in ODI on the Plan Types and aggregations are options/parameters for the Member. Its not what type of plan is being updated. The Plan Type of option in the entity dimension is a setting that says: is this valid member for this type of plan. It is to say is that members actually exist in this type of plan. This is not an option to say update the members for that plan type.

  But back to what I said about the custom dimensions. Custom dimensions are valid for the Types of Plan, that are set at the level of the dimension. That is to say members of level you can't say member 1 is valid for type 1 and type plan 2 plan and member 2 is valid for the Type 1 Plan. If the dimension is valid for both, then all members of this dimension are valid for both. You can not change at the level of the Member and so if the option is not relevant and ODI has so no need to get this option

  I think you're confused as to what Type Plan of ODI fields are actually for. As I say, is not here to say what plan update types. His option to tell whether or not this member exists in this type of plan.

  So in your case because the project is valid for the two types of plan, then you don't need to specify the type of plan at the Member level because by default both will be updated, because you do not have the option for both during the loading of the dimension with the help of ODI is not to be updated.

• Remove the type of plan?

  Dear Experts,
  
  Once we create an application in the planning, can we delete a type of plan?
  If so, what is the process and the precautions to take to do. Do we need to delete the first table backend then essbase?
  
  Thank you
  ~ RN.

  That post is 6 years and version 4 planning, as I said it's possible, but it's not worth the hassle and if it won't, then you would be in trouble, cleaner to recreate

  See you soon

  John
  http://John-Goodwin.blogspot.com/

• Remove the level 0 type of plan only

  Hello
  
  I use 10.1.3.6 and wanting to know if it is possible to remove metadata Hyperion Planning for only one type of plan only? I tried entering a '1' against the type of plan, then using 'delete level 0' but the result was that it removed the code completely, even the type of plan that I wanted him to stay in.
  
  Your help is appreciated.
  
  See you soon

  If you use the option delete will remove the Member completely.
  What you would do, is make a load of standard metadata and to update the plan type, properties, then put 1 or to 0 against the plan of the member types should be associated, remember you are still are under planning constraints so what you try to do must be valid in the planning.

  See you soon

  John
  http://John-Goodwin.blogspot.com/

• Planning an application of type two plan considered

  Hello
  We try to create an application of two type of separate plan ASO (Hyperion planning). We need to get the dimension member two of the plan
  Let's Plan A has five dimensions and plan b is six dimensional. I need eleven dimension in my application. My question is - who I create software, ASO can merge times the dimension of plan member in a single application of ASO.
  
  Thank you

  Hello
  Not always 2 + 2 gives you 4. Similarly, fusion 6 dimensions of type of a single plan and 5 on the other doesn't really mean you should have 11 dimensions in your application to aso. Do not create separate dimensions for common dimensions. That is, both types of plan should include an entity dimension so Aso, you should have 1 entity only.
  2 types of different plan to a single ASO cube data is quite difficult, but can take you re - write a little MDX formulas. However, take this as a starting point. Instead of merge requests, rather flatten by including all members in dimensions, regardless of their type of source.
  For example, in the account dimension you have 4 accounts, 2 of them are in Plan 1 and 2 are in Plan 2. Ultimately in your ASO you should have 4 accounts of course in the same database.

  See you soon,.
  Alp

• Remove the types of Plan

  Hi all
  
  We have 2 plan types & workforce planning. We remove the 2nd type of plan. What is the best way to remove it.
  Is it better to build a new application from scratch? How can do us

  It is much safer to start from scratch, there is no built-in method to remove a type of plan.

  See you soon

  John
  http://John-Goodwin.blogspot.com/