you should know first from where you are pulling the data like Database so here the DBA team will change that entity name before going to add/update any metadata changes in to Hyperion.
Data loading in the sense you should use any ETL/ELT tool like FDM for HFM so while pulling the data from database through FDM script you can check whether the changed entity is there or not? you can check using the Export to Excel option once confirmed that you can add that entity in to the Hyperion there isnothing effect about data because the data wont load if any member is not there like Entity R4604.
let me know if anything need.
This is not possible except in the case of EPMA. Even then, you still have to go back and review all your application objects: forms, grids, rules, smart view, Financial Reports, FDM, etc. In EPMA you can rename the member without losing the data, but given all of the other dependencies that can't be completely addressed, I suggest you take this approach:
Extract all data and journals associated with this account. You must then unpost and delete all the journals, for all time periods, years, scenarios. Add the newly named member as it exists, so for a short time you will have both in the application. The reason for this is occasionally grids and reports cannot be opened if they refer to a member that no longer exists. At this point you can re-load all the data and journals, re-post them, and reconsolidate. If everything works as expected, then load a metadata file which removes the original name. With this done, finally run "delete invalid records" to get rid of the excess, now orphaned records in the database.
If your member is a parent entity, and no data or journals have ever been loaded to it (including ICP data or journals) then your job will be much easier. Bearing in mind what I said about application ojects, you have to ensure the entity is unlocked (and rejected if you use process management) for all time periods, then load the new hierarchy, with the new name, and reconsolidate. Parent entities will simply regenerate the needed data. The risk is much greater in renaming input level members than parent members.
Just to add to this, I would be very cautious if this is a base entity that another unit has potentially reported IC activity with, you'd then have to look through all possible intersections where it has been used as an ICP partner and update that data otherwise that would be come an invalid record and the data could basically disappear.
I would definitely have a look at EPMA and live cycle management to address this issue.
With EPMA you can rename metadata without losing the data (ICP included).
EPMA had a bad reputation in the past, but with the newer versions, most of the problems are solved and with the actual copy application utility you are able to downgrade back to classic by creating a 'classic' copy of an EPMA application.
I don't think, that wdef, grids and reports are a big issue, because most of the time, the Entity dimension has to be dynamic anyway (different to the account dimension), if not metadata security would have a negative impact on these artifacts.
If you have hard coded Entity selection in some of the objects (e.g. member lists, rules, but also grids, forms and FR reports, you can use LCM to create an extract of these objects and use an advance Text editor or some find and replace tool to fix it. All LCM artifacts are stored as XML documents (in other words, as text). Be careful with subset names, if you are doing a find and replace, changing the entity "York" will also change "New York".
Depending on your application design, renaming an object can be complicated and expensive if you have a lot of hard coded object names in your artifacts. Please ask your business user if it is worth the effort.
Actually this is possible. I've done it a few times already. It's just not supported by Oracle and they tend not to advertise it much because there is some risk if you don't know what you're doing. You need to make the change directly in the Database. I use the Oracle SQL Developer for it personally.
First a little back end. HFM doesn't associate data, journals, or ICP with your entity name at all. Everything is always stored in reference to a unique ID Number. So while you may think of it as Entity R4605, HFM views it as entity 734 (Or whatever other number is given to it). When you delete an entity from HFM through a Metadata load, you create invalid records because the data is still associated with entity 734, but HFM can no longer identify what 734 is.
That information is stored in a table called "XXXXXXX_ENTITY_ITEM" where XXXXXXX is your application name. So the Comma application would have COMMA_ENTITY_ITEM. That table holds all the information relating to your entities. They have similiar table for all the other dimensions as well.
If you go in and update the Label for a row, the Item number will stay the same. That means your data remains intact, but the name gets changed. This updates for all IC transactions as well Journals. The only thing it will not update is any rules/memberlists that contain the entity name as it was.
Standard advice of doing this in a test environment first applies, but I've done it several times over the past year with no issues.