Forum Discussion

SKForbes's avatar
SKForbes
New Contributor
11 months ago

Best practice for mapping from NetSuite to OneStream

I am hoping someone can point us in the right direction.

We are being asked to map from the NetSuite Internal ID to the OneStream Member. What we had proposed was to map from the NetSuite External ID to the OneStream Member.

I don't want to pre-empt responses by expanding on why we had suggested using the NetSuite External ID, but would really appreciate any insight from anyone who has done this or has the understanding to explain what good looks like / best practice.

Many thanks in advance 

Data Integration
  • Wcho's avatar
    Wcho
    New Contributor II
    11 months ago

    SKForbes 

    I have previously used NetSuite's Internal ID to create account mapping transformation rules. It was basically a set of transformation rules where source was the internal ID and target was account members in OneStream. 

    It worked well for us because the internal ID for each account in NetSuite was unique and there were no duplicates. I would assume as long as your external ID are unique and there are no duplicates, you would be able to create transformation rules in OneStream. 

    Things to make sure:

    1) Make sure the external ID is unique for each OS member equivalent

    2) Make sure all records do have an external ID assigned.

    Hope this helps.

    • SKForbes's avatar
      SKForbes
      New Contributor
      11 months ago

      @WchoWcho 

      Huge thank you for your response, I appreciate it.

      The business would like to make changes to the external ID and the description of many accounts, further they would like to, in some cases, shrink the number of NetSuite accounts from many to one. They feel that if they have mapped using the internal IDs this will reduce their maintenance, because the internal IDs will always be the same ....

      My feeling is that the internal ID will mean nothing to the end user when they drill down and see the detail from the data upload?

      I also feel that the changes made to the accounts when in the sandbox environment, unless made in exactly the same order and not allowing for any errors, during the development/maintenance process, will end up meaning the internal IDs can be different in the two environment, only on the affected accounts, but if we test mapping from the sandbox and then migrate to production ...

      Please let me know what you feel, what was your motivation for using the internal ID for mapping?

  • Krishna's avatar
    Krishna
    Valued Contributor
    11 months ago

    SKForbes  - If the ID's are just for supporting detail and it is not part of your consolidation or FP&A process. I would recommend bringing this into the Attribute or Value Dimension. So the data will be stored in Stage and not in the cube. It will be visible when you brill down to stage area in OS. You can also create dashboard and in future if you are going to BI Blend you can utilize these ID's to create dashboards.

     

    • SKForbes's avatar
      SKForbes
      New Contributor
      11 months ago

      Krishna Huge thank you for your response, I appreciate it.

      The internal UDs are not required for supporting detail, the business would like to make changes to the external ID and the description of many accounts, further they would like to, in some cases, shrink the number of NetSuite accounts from many to one. They feel that if they have mapped using the internal IDs this will reduce their maintenance, because the internal IDs will always be the same ....

      My feeling is that the internal ID will mean nothing to the end user when they drill down and see the detail from the data upload?

      I also feel that the changes made to the accounts when in the sandbox environment, unless made in exactly the same order and not allowing for any errors, during the process, will end up meaning the internal IDs can be different in the two environment, only on the affected accounts, but if we test mapping from the sandbox and then migrate to production ...

  • RobbSalzmann's avatar
    RobbSalzmann
    Valued Contributor II
    11 months ago

    Adding some thoughts to Wcho ‘s response, data in Netsuite are usually at a detail level not required for planning or consolidations.  In this situation I might encourage design to summarize into OS the data coming out of NS using many to one mappings in the xformation rules.  

    The thinking is it’s not necessary to maintain the same level of detail in two systems capable of producing reports, nor is it always necessary to have ERP level of detail in a system used for planning or consolidation.  

    • SKForbes's avatar
      SKForbes
      New Contributor
      11 months ago

      RobbSalzmann 

      Huge thank you for your response, I appreciate it.

      I agree with all your points.

      The business would like to make changes to the external ID and the description of many accounts, further they would like to, in some cases, shrink the number of NetSuite accounts from many to one. They feel that if they have mapped using the internal IDs this will reduce their maintenance, because the internal IDs will always be the same ....

      My feeling is that the internal ID will mean nothing to the end user when they drill down and see the detail from the data upload?

      I also feel that the changes made to the accounts when in the sandbox environment, unless made in exactly the same order and not allowing for any errors, during the development/maintenance process, will end up meaning the internal IDs can be different in the two environment, only on the affected accounts, but if we test mapping from the sandbox and then migrate to production ...

      I would prefer to use many to one mappings in the xformation rules, but would prefer to use the external ID because it is not just randomly assigned and using the external IDs allows for mapping of ranges etc, whereas internal IDs required explicit mappings for every single GL account?