The previous post introduced Oracle Profitability and Cost Management Cloud Service (PCMCS) as the core technology application in our Oracle Cloud EPM solution, defined the high expectations of our PCMCS OTP solution, explored some of the most common overhead transfer pricing (OTP) methodologies that are deployed in PCMCS, and set the stage for building our PCMCS solution.
This post inspects the PCMCS dimensional outline required to support our calculation and reporting expectations and introduces how to structure Rule Sets and Rules within PCMCS to ensure the successful execution of our OTP methodologies.
Setting up Dimensions in PCMCS
In any PCMCS application development cycle, our first task is to define and build our dimension outline within the PCMCS tool. Dimensions are crucial in any Oracle EPM application as they are utilized to organize and segregate data elements within the applications and, as such, they form the basis for both our calculation and reporting development.
Before we start going into detail on what dimensions we expect within our PCMCS OTP solution, let’s spend a few moments to understand the different types of dimensions that we see in PCMCS. The below list details the Alithya defined dimension types in our PCMCS OTP solution:
System (S) dimensions:
- These are the PCMCS System defined dimensions to control allocation\calculation logic.
- These dimensions should never be changed or updated manually by the users.
- By default, these are the “Rule” and “Balance” dimensions.
Point of View (POV) dimensions:
- These dimensions are used to manage a slice of Model Logic, Statistic\Driver Metrics, and Input Data & Results within PCMCS applications.
- PCMCS applications can have up to 4 POV dimensions.
- Examples of POV dimensions are “Year,” “Period,” “Scenario,” and “Version.”
Business Financial (BF) dimensions:
- These are key allocation\calculation and reporting dimensions for PCMCS.
- These dimensions should be familiar to any Financial User.
- Examples of Business Financial dimensions are “Account”, ”Entity”, and ”Department,” which are common to a range of ERP and EPM applications in any organization.
Business Analytical (BA) dimensions:
- These are key business dimensions for facilitating allocation\calculation logic and reporting.
- These dimensions are often specific to a PCMCS application are not often common throughout the ERP and EPM applications.
- Examples of Business Analytical dimension are “AllocationPool” and ”DataType.”
Attribute (A) dimensions:
- These dimensions are descriptive dimensions that are associated with a base dimension to facilitate enhanced calculation and\or reporting functionality.
- The members in these dimensions do not store data and behave in much the same way that alternative hierarchies do.
As a critical note on System, POV, and Business dimensions, they cannot be added or removed without an application rebuild in any PCMCS application. Attribute dimensions can be added at any time, but cannot be easily removed. Although members within the dimensions can be added, removed, and updated at any time, the inability to add and/or remove dimensions underscores the importance of defining the correct dimension outline before the start of development.
Fortunately, through the implementation of our OTP solution at various clients, Alithya has developed digital content that allows us to streamline our OTP development. The below image illustrates the common dimensions deployed within our PCMCS OTP solution:
The above dimension approach ensure that both the calculation and reporting expectations can be met and also ensures scalability and flexibility for future model enhancements. A key element to meeting the different needs of clients in the concept of the EPMFlex dimensions with our solution. The EPMFlex dimension concept was introduced by Alithya to help accommodate differences in the data model, calculation, and reporting requirements at different clients. Although we have standard recommendations for the EPMFlex dimensions such as Department, Activity, and Recipient Entity, these dimensions can be changed to accommodate the requirements of specific clients. Similarly, although we see similar attributes such as LegalEntity, CatalogOwner, and DriverType being utilized at most OTP clients, Attribute dimensions can be added to the OTP solution based on the client’s requirements.
As it would make for a very long blog, I’m not going to go through the details of every single dimension shown in the above diagram, but I am going to give some highlights:
Entity (Sender Entity) and EPMFlex3 (Recipient Entity):
- This dimension, in combination with the EPMFlex3 (Recipient Entity), is the most critical dimension in our OTP solution. This dimension contains all the Sender Entity members who receive payments for the various charges that are billed to the Recipient Entities.
- An attribute dimension, LegalEntity, is often associated with this dimension if the Entity members have a one to one association to a Legal Entity.
Account:
- This dimension contains all our Expense Accounts which are utilized in OTP solution for the billing of services, but also contains additional hierarchies that contain Statistic members, driver members, Assumptions, Metrics, and, of course, summarized Line Item or Journal Accounts.
- The different Account members can be populated in different Rule Sets within our OTP model.
AllocationPool:
- The AllocationPool dimension is similar to a traditional CostPool or Bucket dimension that we see at many clients and facilitates the introduction of an intermediary step in the OTP process where charges can be pooled prior to being allocated or charged out.
- However, this dimension is special in its ability to create traceability through our solution by its association to various attribute dimensions such as AllocationType, MethodType, and DriverType which can be utilized both to simplify the calculation process and enhance reporting.
Catalog/Service:
- The members within this dimension are utilized to create the bill of services when charging a Recipient Entity/Consumer and can be utilized in determining how the charges were derived for any given Recipient in combination with the AllocationPool.
DataSource:
- Those with EPBCS applications will be familiar with the concept of the DataSource dimension that is utilized for the tracking of sources of data in the application. However, in our OTP solution, we take that concept a step further and utilize this dimension to not only track our sources of data, but our output of calculations.
- For example, this dimension is utilized for traceability on which source system, such as Oracle EBS, load the pre-charge expenses, but is also utilized in differentiating the base charge, mark-up charge, and total charge amounts at a Recipient Entity level.
Thinking about Rule Sets and Rules
So now that we have an overview of how to structure our solution, we are ready to start looking into the core of our calculations, the Rule Sets, and Rules. At a minimum, our OTP solution needs to have various Rule, grouped by Rule Set to accommodate the OTP methodologies that we outlined in the previous blog, but there is also some other functionality that we need to accommodate about such as currency conversion, driver preparation, expense exclusion, financial allocations, various attributions and journal preparation that are also important.
For comments, questions, or suggestions for future topics, please reach out to us at infosolutions@alithya.com. Visit our blog regularly for new posts about Cloud updates and other Oracle Cloud Services such as Planning and Budgeting, Financial Consolidation, Account Reconciliation, and Enterprise Data Management. Follow Alithya on social media for the latest information about EPM, ERP, and Analytics solutions to meet your business needs.