Changing e.list Structure Strategies

[Charles.Lorenz]

Can anyone out there comment on best practice when dealing with changing e.list structures?  

Is there a way to generalize the e.list for changes so that restructuring when lower level changes occur, no restructuring needs to occur?  

Thought I'd throw this out there.  I have some ideas, but wanted to get input from the Planning gurus of the world.

Thanks

[whitestone]

I have a Contrib app that will be coming on line soon where we may need to make daily e-list changes during seasonal periods (around certain sales cycles). Would there be any advantage to pre-loading my e-list with 'hidden' dummy entries, and then renaming and unhiding these entries when I need to 'add' new e-list items. When I say pre-load our e-list I also mean pre-load any assumption data tied to these e-list entries and pre-load access table entries as well (to nodata these elist slices).

Additional background: My high level e-list items are sales regions. These will remain static. My low level e-list entries are stores handling our product line. When we add a new store (e-list item), we also update assumption cubes and access tables (to cut-down a store's cubes).

Question: Am I over-complicating an already complicated process???  :-\

[ykud]

I have a Contrib app that will be coming on line soon where we may need to make daily e-list changes during seasonal periods (around certain sales cycles). Would there be any advantage to pre-loading my e-list with 'hidden' dummy entries, and then renaming and unhiding these entries when I need to 'add' new e-list items. When I say pre-load our e-list I also mean pre-load any assumption data tied to these e-list entries and pre-load access table entries as well (to nodata these elist slices).

Additional background: My high level e-list items are sales regions. These will remain static. My low level e-list entries are stores handling our product line. When we add a new store (e-list item), we also update assumption cubes and access tables (to cut-down a store's cubes).

Question: Am I over-complicating an already complicated process???  :-\

You'll gain speed in adding new stores (need just to rename elist items), but will complicate your life by adding new procedures dealing with those elists.
Those dummy elements will participate in reconcile (which will make it slower) only in case of data change for them (that is synchronize). And they will be subject for cut-down (slowing that too).
I wouldn't choose that unless adding new stores is really business critical (1 minute difference matters).

[ykud]

Can anyone out there comment on best practice when dealing with changing e.list structures? 

Is there a way to generalize the e.list for changes so that restructuring when lower level changes occur, no restructuring needs to occur? 

Throw in an example or define "restructuring" and we'll see what can be done.

[whitestone]

Ykud,

I think I was trying to get too complicated. Thanks for setting me straight :)

Will