Quick How-To Guide: Migration of Script Logic from MS to NW – Translation Vs. Interpretation
Key Concept |
The skill set required to be a language translator includes not only translation of words for words but also the understanding of the context of the statements and local language speaking styles so that you can interpret the meaning to the other listener.
For example, in Brazil they often say translated to English literally "Not Today" when responding to a question of when one might get something done. The English speaker in asking the question is seeking a commitment for TOMORROW, but the answer means literally Not Today. The good translator that can also interpret culture and speaking style would immediately alert the English questioner that the response is Not tomorrow either!
Too, the statement I can effort that also needs to be interpreted to mean I can do that work.
The same is true of script logic. We a few migrations done using a proprietary documentation and management approach that absolutely works, I am finding some new common themes among those that say they are Really Good at BPC.
They are good at Translation but lack interpretive skills. Now I can discuss soft skills but this post deals with Script Logic Interpretation as an example. Let's walk thru it!
A Script
The following script excerpt demonstrates something that is often encountered in the MS space.
*PROCESS_EACH_MEMBER = TIMEDIM
*CALC_DUMMY_ORG ACCOUNTDIM = PARENTH1
*WHEN TIMEDIM
*IS PRIOR
*WHEN TIMEDIM.PERIOD
*IS <> "P12"
*WHEN ACCOUNTDIM
*IS XXX0130
*REC(TIMEDIM=%TIME_SET%,DATASRC=BPC_PLAN)
*ENDWHEN
*ENDWHEN
*ELSE
*WHEN ACCOUNTDIM
*IS #XXXX0001
*REC(ACCOUNTDIM=XXX0130,DATASRC=BPC_PLAN)
*ENDWHEN
*ENDWHEN
*COMMIT
The above logic basically looks at the time members and processes them one at a time and it also calculates the parent values for the account dimension for later use in the program. Let’s leave it at that at the moment and move forward with the first typical effort a typical resource would provide. (Scope omitted for examples – trust me scope is valid)
The Translation
When faced with the above code, the response might look like the following:
FOR %T1% = %TIMEVARIABLE
*WHEN TIMEDIM
*IS TMVL(-1,%T1%)
*WHEN TIMEDIM.PERIOD
*IS <> "P12"
*WHEN ACCOUNTDIM
*IS XXX0130
*REC(TIMEDIM=%T1%,DATASRC=BPC_PLAN)
*ENDWHEN
*ENDWHEN
*ELSE
*WHEN ACCOUNTDIM
*IS XXXX0001
*REC(ACCOUNTDIM=XXX0130,DATASRC=BPC_PLAN)
*ENDWHEN
*ENDWHEN
*NEXT
*COMMIT
Knowing at least that they can reference parent level member values directly in the logic, the question becomes what does this now do and will it work or is it the best interpretation? With the translation done, this script logic will not work for a number of reasons. It will compile and then you will wonder why does the Net Weaver Platform NOT UNDERSTAND this translation.
The Basic Translation
For each time value check the prior time value. If that time value has the property of PERIOD not equal to 12th period then record that value to an account in the CURRENT TIME value. If the value is the 12th then do the else portion of the logic. That will presumably accumulate the top level parent for the current record set of dimensions and place that into the account required.
The accounts are from the Income statement XXXX0001 to the Balance Sheet XXX0130. The accounts are Total Net Income and Retained Earnings respectively.
The logic would calculate the XXX0130 account in the case of a 1st period and place it into the current period. The next period would then record into that account and accumulate the values of like time periods. A bit hard to follow, but that is what it does.
The Interpretation
In other words spoken in plain accounting take the Year To Date Value for the NET INCOME Parent in a period and place it into the current period balance sheet.
The reason for this is somewhat obvious in plans. As you plan potential net income in a PERIODIC application for planning Net Income and want to place the YTD value into the Balance sheet retained earnings account because the balance sheet is also period based, that is a standard accounting concept. Essentially you want to see in the balance sheet the accumulated value of retained earnings in each period.
The Way to Do It
This is a standard Account Transformation or Calculation process. The BPC System even in the MS version would have more easily allowed this. If a client has gone some other direction in the MS version because they may not have understood business rules, that is OK. But simply translating this to new NW compliant script is just not the right way to go.
Depending on whether or not a flow dimension is available, you might also be able to use the Copy Opening routine.
With the above rule, the interpretation logic is shown:
//For running accountcalculation rule (cash flow preparing)
*RUN_PROGRAM CALC_ACCOUNT
CATEGORY = %CATEGORY_SET
CURRENCY = %RPTCURRENCY_SET%
TID_RA = %TIME_SET%
CALC=A
*ENDRUN_PROGRAM
Conclusion
I know it is not a detailed or perfect document, but catch the mystery catch the drift[i]. Interpretation is more important that translation in MS to NW Script Migrations!
Richard Jabbour is a senior FICO and BPC consultant with Tata Consultancy Services. Prior to this, he worked at Buckeye Technologies, helping implement complex data warehouses and business scenarios in SAP ECC. He has worked with several BI tools including SAP NetWeaver BW, SAP BusinessObjects, and is a certified associate consultant in BPC for NW. He has extensive experience in data modeling, design, configuration, and performance tuning having held many professional certifications in Oracle technologies. You may contact Richard via email at rbjabbour@bellsouth.net. |
No comments:
Post a Comment