UD34, UD56 and UD78 columns in DataRecords
Hello everyone,
While checking a DataRecord table in OneStream Application database, the following three columns exists: UD34, UD56 and UD78.
Does anybody know what is the utility of these colum...
Forum Discussion
Hi, am I right in assuming that this data is just a historical "data dump"? This is not part of the reconciled data for statutory consolidation I assume?
The code that has been shared here allows you to copy data to parent entities, but if data is loaded to all entities, the data from the base entities will still translate and consolidate to the parent entities. So at least, consolidation % should be set to 0 to prevent this.
If this is indeed for statutory consolidated historical data, that is also used to provide closing balances for the starting point in OneStream so that the correct opening balances are pulled from there, I recommend not following this approach. The typical approach is to load the data to base entities and then let the system translate, calculate share and eliminate the data. Additional adjustments should be posted via journals. I know this is taking more time, but it gives control to the accountants and it ensures data integrity in the statutory actual scenario as all data is based on the same consolidation logic. This also helps validate the solution in a sense that once historical data has been reconciled in OneStream, the system works as per your requirements.
Historical journals can be loaded directly into OneStream as well in case you have a lot of those and posting each one individually seems too time-consuming.
Hello Henning,
Thank you again for your help.
I confirm that this is just a historical static data dump. I am not aiming to use these data to provide closing balances for the starting point in Onestream.
I just need to add these consolidated amounts in OneStream for read only purposes.
Is it possible to load data directly to TOP consolidation member?
Thank you in advance.
Regards,
No, C#Top does not store data. Data is stored (amongst others) on C#Local.
You could also consider using technical / historical entities for 'dumping' this data. That way you could just load all of your data to a technical base entity in OneStream which represents a parent in your legacy system. That way you could leverage built-in load functionality via the workflow. But that all of course depends on your solution and requirements.