Enterprise PLanning Objects Naming Convention.

As I’ve promised, here are naming conventions I tend to follow in EP projects.
Setting up naming rules doesn’t seem so crucial at project start, but generally hits on you on the head on final phase, when development turns to support. And trying to support your colleagues model will leave you thinking about naming objects the same way more than once ;) So naming conventions are one of main project documents for me now.

I really expect and encourage comments on this naming proposal. Maybe together we will create something like Sun Java Code Conventions )

Object Naming rule Example
Library Library names are not that important, though if you use Analyst with Contributor, consider creating stub libraries for importing data to\from Contributor, as I’ve described here. No data in skeleton library is a motto that will help you more than once, I guarantee.
Library codes are important if you want to keep a single store of projects (in consulting company, or competency center) and you’d better create some seeding rules for creating unique 9 numbers for projects.
A simple scheme of xxxxyylll, where xs are project code, ys — library type and ls — library order number will be sufficient in most of cases.
Sales_Planning_skl with code 777701001
Dlist The main difference with Cognos initial coding standard.
Dlists are numbered not up by their functions, but by type calculations happening in this dlist. I’ve got initial table from [Erik Thomsen's OLAP book][1] and modified it to suit EP better. So it goes like this:

1 – IF-ELSE formulas
2 – *,^, /
3 – Common Sums
4 – Timescale Sums
5 – No calculations
Second difference: these numbers are used as suffixes of dlists names, not as prefixes. This allows quick search by first letter of dlist name when you’re browsing the library and all product dlists will be kept together, regardless of type.
Third rule: only latin names with spaces substituted by _ (underscore). This guarantees that published tables will be named meaningfully and their names won’t mutate after time (a real problem with cyrillic dlist\dcube names).
Dlist item names One really useful hint: mark all calculation temporary elements (not to be seen user) with leading # symbol. This allows creating simple saved selection with filter that will easily hide all unnecessary elements from users in Contributor #temporary_allocation_element
DCubes Once again, only latin names with underscores to keep publish tables names sane. Contributor translations allow you to rename these cubes for end users with whatever names they’d like. No i\o\c, we’re out of kindergarten Product_Sales_Global
Dlinks “<" instead of ":" in separating source from target. And some hints like + when you've got an add link, - for subtract, to allow better understanding of link logic while viewing it in update list table. BalanceSheet”<"Cashflow(+)
Macros Latin verbs or sentences describing what you’re doing with macro. Latin due to necessity for batch running. Update_Products_Export_Elists
Allocation Tables Similar to links, just the allocated dimensions with some commentaries ProductGroups”<"Products
File Maps Whatever you like, I prefer filename pl_export.csv
Applications Rather strict rules are implied by Contributor itself, so i’d just advise to name aplications meaningfully, given that these names will always appear in browser connection string. No doubt that seeing “sales_plan_v8_will_it_ever_work” will ensure users. No grammar mistakes or typos, please. sales_plan_by_brands
Access Tables Access Tables should always be named. It’s best to write a short sentence, describing access table meaning Closing product list based on managers responsibility
Saved selections Plain common sense: explain what this selection selects ) Accounts_special_calc_items
Administration links Need suggestions here.
Since Administration link is a pack of links, I use macro notation — verbs describing the process, but I put target application first
sales_plan_by_brands update from regions
Macros Need suggestions here too.
Again some action descriptions, but I don’t have a common approach of separating macros by applications they’re working with or smth like that. Moreover macros aren’t grouped anyhow, so I sometimes tend to prefix macros with some block group with following description
Sales_submission sales by brands to sales by regions
System Links These are for users, so names should be descriptive actions Load new currency rates

Whoa, it’s a really huge document, maybe I’ll it finish someday…

[1]: http://www.amazon.com/OLAP-Solutions-Building-Multidimensional-Information/dp/0471400300

  • Carsten

    Hi Yuri,

    Brilliant post as usual!
    I will be on holiday for 3 weeks and will be on a plane in 10 hours, but I thought I had to add my contribution to such a long awaited post. I will add my relevant comments in order of you table.

    Libraries: I like the idea with the project number, however I usually use the creation date (makes it almost unique, too). Maybe with extensions for various libraries. I.e. 200805161, 200805162, etc.
    Further I got used to a specific folder structure, which I have zipped and use as initial setup for new projects. I will just post the structure here and maybe send you a more detailed description document via email.

    I then usually save the contributor xml in the library folder. You then have with a zipped version of the ep_applications folder everything you need for support or to set it up again.

    Dlist: I see where you are coming from, but I hesitate to agree to the first 2 differences. I don’t have to tell you the disadvantages to differ from common and still taught standards and so far it worked quite well for me. Further, how often do you have conditionals and other calculations together in one list?

    DList item names: Not always, but quite often I try to stick with these (where suitable):
    –HEADERS– (text formatted and a “0” in the calculation)

    DLinks: DCubeName<IDL for internal links (although I know they should be avoided ;))

    Macros: I am used to the following abbreviations. Not quite sure if they are taught by Cognos training:
    DLO Open a D-List.
    DLU Update a D-List.
    DCE Export Cube data
    DCO Open a D-Cube.
    DCU Update a D-Cube.
    ATO Open an A-Table.
    And so forth. They are then used as prefixes. I.e.:
    DCE – Sales Actuals
    DCE – Accounts_CostCentres_AT (for access table export)

    Administration Links:
    In the early days I sticked to the concept of Analyst, but since you see source and target application and cube in the details, I now use a proper description. I.e.: “Version Copy of Fcst CY to Budget NY as starting point” and then the relevant cube names for the link elements. The description may have a reference to a Macro that uses the Link if applicable.

    Macros: I create brief suffix’ for the application. Keeps them nicely grouped. And ALL for Macros that run steps for all apps. I.e. if you have a Sales Plan app and an OpEx app:
    SP – GTP
    SP – Synch and GTP
    SP – Load Actuals
    Opex – GTP
    Opex – Synch and GTP
    ALL – GTP
    And so forth.

    Formats (maybe obvious)
    1 Decimal place will have the format 0.0
    2 Decimal places will have the format 0.00
    2 Decimal places with a % will have the format 0.00%

    And last but not least. Not sure if it belongs to naming conventions, but ALWAYS use the {Lib} function for files, especially with the above named folder structure. You can use ..\ if you need to browse folders up. I.e. “{LIB}\..\data_load\export_files\elist_cost_centre.txt” if you want to save a file from a Macro in the common library.

    Looking forward to create some proven best practice standards ;).

  • Carsten

    Sorry the nesting was lost for the folder structure hierarchy in the post. I hope this will work:
    >> analyst_applications
    >>>> access_tables
    >>>> common
    >>>> data_load
    >> contributor_applications
    >>>> xyz_contr_app_name1
    >>>> xyz_contr_app_name2
    >> documentation
    >>>> deployment
    >>>> design
    >>>> status_reports
    >> automation
    >>>> batch_files
    >>>> contributor_macros
    >>>> admin_links

  • ykud

    Thank you Carsten.

    Since you’re on vacation by now ), I’ll take my time to think over your suggestions and will comment on them in more detail.

  • ykud

    An answer to your list, Carsten. Sorry for delay (

    I’ll go on point by point, as you did:

    Libraries: I like the idea with the project number, however I usually use the creation date (makes it almost unique, too). Maybe with extensions for various libraries. I.e. 200805161, 200805162, etc.

    We’ve got the very same situation at my previous workplace. Started project at very same date and couldn’t mix them up later. Caused some trouble.

    Folder structure

    We’ve got a very same kind of zip package for roll-out. Thanks for sharing your one, got some new things there. Need to think over with new 8.3 deployment functionality and adapt this folder structure to it.


    Yep, that’s the hardest part, and I always fail here. So we usually go on with cognos naming, only putting numbers at the end of lists (that really makes life & publish easier). But maybe someday…
    Cognos logic was initially the same, just they made it informal, like “Products should be 2″, not “All summs should be 2 and precede Timescales”

    Analyst Macros

    That’s new abbrevations, never seen them anywhere else ) Nice ones, I must admit, I’ll record them down, if it’s okay with you. Though I rarely use any Analyst macros these days, except for dlist updates.

    Contrib Macros

    Yep, we do app name prefixing as well. But we’ve had to add project prefixes as well, since in a big shared installation you have more than one sales planning application at a time.


    Yes, that’s the way to name ‘em )

    Looking forward to create some proven best practice standards ;).

    I’ll update this post with your insights and will be a step further in that direction.