This content has been marked as final. Show 6 replies
Martin wrote:I think (I am trying to do something similar), you have to have these descriptive values off as a separate hierarchy. For example, for us, organization approver is an attribute of entities (flex value). In order to populate this value, I had a separate hierarchy for approvers (*only* approvers currently available otherwise this would become a massive hierarchy for HR which is not the true purpose of this hierarchy). Then, in my opinion, you have to export out the metadata you need and load it into EBS without using the DRM GL template values into staging tables, and then work out an incremental loading routine into EBS.
We would like to maintain the eBusiness Descriptive Flexfield (attribute) values that are associated with a Chart of Accounts key accounting flexfield.
Does anyone know how can we achieve this?
The GL DRM integration only maintains the key accounting flexfields and not any associated descriptive flexfields.
Thank you for your help.
An addendum, for this purpose, I don't think the out of the box DRM GL template is sufficient. You will need other properties and comparison exports to help you with this.
Martin, we are looking at this area too.
There are no columns in the interface table gl_drm_segvalues_interface to carry this information so it appears as other posters have said this is not possible through standard functionality.
It looks like a major piece of development and I would be concerned that it would become far more complex to build these DFF values in DRM as you are likely to already have a source of this data in your eBS.
We also have an issue that the load appears to clear DFF values that are already set within the application. Does anyone know if this behaviour can be modified?
Just for future reference there is a patch to stop the API form overwriting DFF information at upload time.
Patch number 13249707
We have applied and tested and it appears to prevent the overwriting of the DFF values.
We have been trying to get the integration working as well. The EBS custom FFs that are required obviously make the delivered adapter useless. But the EBS guys essentially cloned the adapter and added the fields we needed. I'm not sure why Oracle is find this so difficult.
The other issue, we will have 20-40 ValueSets. We can't afford to put each one of those in a different DRM Version. That's too much maintenance. We are putting them all in 1 version, and the custom program will just pull from the 'current' Version.
If anyone has great ideas on how to work around the DRM limitations, please let us know!
I agree... I am not too sure why Oracle have not implemented this. I have raised it as an enhancement request - we shall see what happens!
Would you mind sharing where you found the adapter file to clone it? What amendments did you make to the adapter file?
We also hit the problem of having multiple versions which is a bit of a negative and like you say increases maintenance - luckily we only have max 10 value sets.
Thanks in advance.
Hopefully we can solve this / improve this integration together!