This content has been marked as final. Show 8 replies
Step one will be to move the application to 9.5 or later (recommendation would be to go to 184.108.40.206).
You can then migrate your planning application to EPMA instead of classic planning (2 minute migration that doesn't require IT). Once there you should be able to change the structure from 13 months to 12 without much difficulty. You could do this playing around in the table but unless you really know what you are doing could be a recipe for trouble.
Once you have the app to 12 months instead of 13. If you are using dynamic member list (@idescendants, @children, etc.) most of your forms and stuff should be automatically updated. Same for some of your calcs. But if you hardcoded stuff (especially in calcs) then you will have to do some manual work but not impossible.
Hope that gives you some ideas.
Others can suggest how to work around the relational backend table structures, it's just that (in my opinion) migrating to EPMA will be easier and have other benefits as well and you will also need a DBA.
Thanks for your information.. We are not aplnning to go to a higher version until next year & for the upcoming year budgeting we need to change the application so that we can use the sytem by end of August 2010.
Does anybody know more information on how to work around the relational backend table structures in 9.3.1. Does anybody have done this kind of thing before on their current system ?
EW wrote:Just out of interest are you saying for definite that the period member will be deleted from planning, I know it will be removed from EPMA.
Once there you should be able to change the structure from 13 months to 12 without much difficulty.
It was a while back but when I gave it a test it removed the member from EPMA, refreshed to planning with no issues but did not delete base time period.
You were stating a fact, hence the reason you didn't put a ? at the end, and hence why I didn't think it waranted a response.
So yes you can add a period and it will work, but you can't delete a period, which is clearly a bug. So my comment above was clearly wrong.
Was this ever logged as a bug to Oracle?
Sorry it was just you told the OP to upgrade to 220.127.116.11 and then upgrade from classic to EPMA so I thought you must of tried it, I apologise for missing a question mark.
I don't know if you can call it a bug or a feature of planning, it has always been that way.
I call it a bug. Cause you delete the member in Dimension Library and doesn't give you a warning or error. You validate and it doesn't give you a warning or error. You deoploy both as refresh and/or create and still no warning or error. Seems like everything worked fine and yet it didn't.
After you asked the question I tested all these scenarios with the same result. I also tested adding a member and that did work as intended, so they had designed it to allow you to make changes to this dimension. When I have more time I'll go in and test further use cases. For example I didn't test what would happen if I delete the member directly in EAS after refreshing but I'm sure that isn't going to go over very well.
Had it given me a warning at least one time then it would be working as intended IMO. But since nothing was ever flagged I can't see how someone could say working as intended.
Always interesting to play around with these scenarios to see what happens :)