Flexible upload of profitcenter nodes from CSV is restructured after succes

Question

Hi;
I'm having a problem with using flexible upload loading data center nodes into an existing structure. The result is that Inside that profit center hierarchy a node 1000 is created in which the nodes specified in the CSV file are created. It is found that the hierarchy structure is not maintained as the newly created nodes are created under earchother.
Based on the idea that a hierarchy has been created as a profit center group with exactly the same structure it is not understoud why it is not possible to do this for the profit center. Additionally it demonstrates that the flexible upload function is understoud and is configured correctly. As well the file is properly setup.
This website was used http://help.sap.com/saphelp_sem60/helpdata/en/62/f7e73ac6e7ec28e10000000a114084/frameset.htm
I'm looking to understand why it is that the nodes are created differently for a profit center group then a profit center, It is suggested that the problem lies in the fact that the profit center was created and is under a specific configuration that does not allow me to add nodes to it.
THis is the structure:
H
--N1
   --N2
      -- The node that is added here and one level below is placed under "N3 1000"
--N3 1000
   --The node is added here
   --The child is added as a sibling
It was noticed that N3 is labeled as 1000 which is the controlled area. When refering to the log it has been found that the CO area was automatically populated with 1000 dispite this not having been done in the CSV file. Therefore it is assumed that there is a relationship between the nodes being added to the 1000 node and the controlled area.
Any suggestions are welcome. Would it be required to provide more detail with regards to the problem then please state this.

Answer 1

Hi,
IMHO, the culprit is a CO area set as an external attrbute int the hierarchy of PC and PCG.
AFAIR, CO area might/must be a linked attribute to PC (see the last tabstrip in PC infoobject screen) and that's why it should be fixed in the ConsArea settings (and populated aotomatically durung the data load).
If I were you I would try the following:
- ask the basis guys make a backup copy of the system
- delete CO Area from the external char of PC & PCG hierarchies
- set CO Area as a linked attribute to PC & PCG (if it is really needed - very often it's not needed if CO area has just the only value (which is fixed in the ConsArea settings)). => NB => These changes are very significant for BW and it's not always possible to done without data deletion.
- regenerate the BCS data basis (and probably the ConsArea).
The 1st step is needed because SEM-BCS very often does not regenerate properly the data basis (it simply doesn't see the changes). In the forum topics I several times explained how to force the system to see these changes (just drag and drop any role in the definiton of the BCS data basis and the save it).
This is (significant change in underlying properties of BW infoobjects) the main painpoint in changes BW for SEM-BCS. In my practice, unfortunately,  it required not less than several attempts (even with dumps). And unfortunately it may require the full data deletion in the cubes which play role in the data basis. It might be the main charge for the bad desifn of the BW structures for SEM-BCS.
Hopefully, you'll avoid it.
Good luck!
Linked attribute = compound attribute.
Edited by: Eugene Khusainov on Jan 31, 2011 4:25 AM