Forum Discussion

PhilB's avatar
PhilB
New Contributor III
2 years ago

Writing Annotation data in a Finance Rule (like SetDataBuffer)

Is there a way, in a member formula or Finance BR, to write annotation data back to the database in bulk?

In OneStream rule writing, it's best practice to limit the number of times you are writing data back to the database (ideally only one SetDataBuffer at the end of your code). However, it does not appear that you can include annotation information in the DataBufferCell objects that are used in a data buffer.

Is there an alternate way to be able to set a large quantity of intersections at one time (like a SetDataBuffer), but for Annotation information instead of values?

 

  • JamesKirkby's avatar
    JamesKirkby
    New Contributor III
    2 years ago

    We've used the the api.Data.SetDataAttachmentText function to set the data attachments in the past. This function uses a member script to set the value in the dataattachments table which is where the annotation type data is stored. Specifically we've used this function executed from a custom calculate script to copy annontations from one scenario to another.

     

    The attachment type is the field in this table that identifies which view member that the information is stored in; it's stored as numeric value there but the values and how they relate to the actual view members are as follows:

     

    200 = Annotation

    220 = Assumptions

    221 = AuditComment

    222 = Footnote

    223 = VarianceExplanation

    If you can generate the member script and text while in your loop - you may use this function to set the value text in the loop and the value at the end.

     

    • SirOti's avatar
      SirOti
      New Contributor
      2 years ago

      Yeah this is the way to go. Have you had to copy over data attachments that are actually files and not text? If yes, how did you approach it?

      • JamesKirkby's avatar
        JamesKirkby
        New Contributor III
        2 years ago

        You know I haven't had a need to do that yet - but would be interested to hear other's ideas.

  • Omkareshwar's avatar
    Omkareshwar
    Contributor II
    2 years ago

    Hi Phil,

    Onestream in the backend does not store any alphabetical value it only keeps number in the backend table for cube data.

    What you can do is create a DBCL in that append all the intersection info and the annotation value to a dictionary and with that dictionary create a table in the backend and store that info there and when you want to access that information you can cache in that table as a dictionary and look for that value you want to refer using the intersection as key.

    This will help you to store the information in bulk using a DBCL but to a custom table.

    • PhilB's avatar
      PhilB
      New Contributor III
      2 years ago

      Hi Omkareshwar,

      I'm not actually looking for anything custom. I'm talking about OneStream's standard annotation functionality (i.e. - V#Annotation). I want to populate the V#Annotation members in a data buffer in much the same way you would populate the numeric values in a data buffer.

      Thanks,

      • TomABC's avatar
        TomABC
        Contributor II
        2 years ago

        How about a Form Import Template?  There is a Marketplace solution (IMT - Import Template Forms) in which there are various Token driven forms such as this:

        Then go to your Cube settings where you are looking to load this data:

        Then create a data source to ensure Excel loads are enabled:

        Or create an import template with tokens as shown in below screen shot and load through a base import workflow profile type

        Search in Design and Reference guide for more on Tokens:

         

         

         

  • ckattookaran's avatar
    ckattookaran
    VIP
    2 years ago

    You could save it to the annotation tables. However, loading a lot of values to the annotation table and using it back to do calculation logic is a bad idea. It can be a performance hog in most cases. You might have to take a different approach if this is intended to drive calculations.