Migration of Script Logic from MS to NW – Translation Vs. Interpretation - A discussion and example
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.
One of the above requires translation and one requires interpretation. I want the interpreter.
The same is true of script logic. With 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 throught it just to get a feel for the challenges of a migration.
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 effort a typical resource might provide. (Scope omitted for examples – trust me scope is valid)
Translating
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, but it will compile. After compiling it and thinking you are done, the trip down the rabbit hole begins. Some will sit and wonder why does the Net Weaver Platform NOT UNDERSTAND this translation and keep banging away around this theme and produce variations that may or may not work or may be very sub-optimized.
Beginning to Interpret
For each time value check the prior time value. If that time value has the property of PERIOD not equal to the 12th period then record that value to an account in the CURRENT TIME value. If the value is the 12th period 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. (again this is an example to show you what you will face as a manager of resources)
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 same period balance sheet account for retained earnings.
The reason for this is somewhat obvious in plans and is a common 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. (be aware regardless of what the documentation says, copy opening does not like to not have a flow dimension)
With the above rule, the interpretation executed in 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 the idea is important. If you are managing migrations and need to make sure you serve the client, you need to serve as the master interpreter because most people will only translate.
Interpretation is more important than translation in MS to NW Script Migrations!
- SAP Managed Tags:
1 Comment
