Blog Series: Can an Asset also be a Liability? Let’s Talk About SAP Asset Retirement Obligation Management (AROM) (Part 1) Details on how AROs work in SAP Asset Retirement Obligation Management (AROM) (Part 2) Details on how AROM Integrates with the Lease Accounting Engine (LAE) (Part 3) How does AROM Integrate with the Accrual Engine (Part 4)
After covering an overview of AROM and then showing how ARO’s are valued it’s now time to dive into the details of the solution. Specifically, I want to talk about the integration points of AROM because that is the part that I find the most interesting.
Why Integration
As most people know, integration is probably the most difficult part of any SAP module to work with. It’s also one of the core and fundamental reasons why ERP is as successful as it is so it’s an important area to discuss whenever you are covering a new solution.
In the case of AROM the main integration points are to the General Ledger (FI), the Accrual Engine (ACE), the Lease Accounting Engine (LAE) and Asset Accounting (FI-AA). The GL and asset subledger are obvious integration points and well known. ACE is a bit new-ish but is mostly a dedicated area within FI that handles accrual postings. I’ll try and cover them in a subsequent blog but want to focus on LAE since it’s probably the biggest unknown.
LAE
What is LAE? Having worked a lot with capital management issues I was aware of leasing and the solution in FI-AA. SAP had also developed a newer solution from the lessor side that worked in CRM and ERP. It was this newer and far more advanced leasing solution that introduced the Lease Accounting module (FI-LA). Within FI-LA, lies the Lease Accounting Engine. LAE was originally used to handle a lot of the integration of the FI-LA solution with external modules such as the GL. It handled a lot of the account assignment and value calculation for leasing. It tracked dates and processes of each lease, bill plan, condition types, and the proper capital classification. Since the leasing solution required both CRM and ERP, it was LAE and Contract Accounting (FI-CA) that was used as the inbound target of ERP for each CRM event. For instance, a contract created in CRM had to be replicated to ERP and this was done within LAE and FI-CA. The main point of this is that LAE is flexible enough to handle external data and make it available to the financial modules of ERP.
LAE is just a component and not what I would consider to be an ERP module (or sub-module). There isn’t a set of LAE master data. There are no LAE transactions similar to a PO or sales order. It makes calculations but mostly hands that data off to FI to do the actual posting. On it’s own, I’m not sure what value it would provide anyone. It’s only when it’s combined with another module such as AROM, the GL and FI-AA that it proves more valuable.
Purpose of LAE for AROM
LAE provides the following main purpose to support AROM
- Value Transfer – LAE is used to transfer the necessary values and attributes to FI-AA and the GL.
- Classification – LAE classifies each ARO as being capital related or not, thus engaging FI-AA for the appropriate accounting entries.
- Integration – In addition to the above functions, all other general integration issues are triggered by LAE. When a change is made to an ARO that should involve other modules (i.e., an adjusting entry based on a partial ARO termination), LAE is engaged once that CEP is released. There is no direct integration between ARO and the GL or FI-AA… LAE is always involved as the intermediary. In this way, it acts as a sort of middle-ware to the total AROM solution.
Without LAE, there would be no integration from AROM over to FI-AA. Thus, ARO creation, terminations, changes in ARO cost estimates would not generate the appropriate asset master data or postings. Those would have to be done manually without LAE. LAE has a very important role to play when implementing AROM. It’s not possible to implement AROM without LAE.
Development via Configuration
The most interesting thing about LAE is how it surfaces certain features or functionalities that previously would be considered pure ABAP development. These integration points are now accessible in a more functional/configuration way. What do I mean by that? As a comparison, consider a typical PS scenario. A new investment measure is ready to settle for the first time. At settlement, an AuC is automatically created in the asset class specified in the IM profile that is assigned to that WBS. This process has been around forever and works fine. AuCs are throw-away temporary records so they don’t require a rich set of attributes to support reporting. They typically don’t have many fields that are required to be maintained. But what if you wanted to automatically populate a few of them with attributes from the WBS? What if you wanted to change how the cost center is transferred from the WBS to the asset? What if you wanted to pull in the project type or some of the CNEX0007 customer fields into the asset? And what about the final asset… what if you wanted to transfer some of those same attributes to the final asset when the WBS is TECO’d? You can’t. All of that integration between PS and FI-AA is, from a configuration perspective, fixed and untouchable.
LAE makes this integration process from AROM to FI-AA and the GL much different. In a way, you can now do what would previously be considered a Development activity as normal configuration. It makes the solution soooooo much more flexible and a heck of a lot more interesting than your typical ERP solution.
Here’s a simple example. In standard ARO, when the ARO is released an asset is created. The asset’s description is a concatenation of the ARO number and the Cost Estimate Plan (CEP) within the ARO. ex: 1000012-1. While accurate, this isn’t very helpful for identification purposes when you are looking at it from an asset perspective. If you run an asset balance report and see numerous equipment assets, machines, etc., and then 1000012-1, you won’t know by looking at it what that record is. At least in the PS example above the WBS’s description gets copied into the asset, not it’s external ID.
To improve upon this, I’d like to preface the ARO number with “ARO” so that the asset is more easily recognized in an asset report. Again, this very simple scenario is something that is not normally configurable in other areas of ERP.
First… and this topic is too big for this particular blog about LAE… but LAE makes heavy use of an item called a ValueID. ValueIDs are temporary containers of information… information that it gets from an inbound module (AROM in this case) and then passes it off to another module such as FI-AA. In this case, there is a ValueID that captures the ARO and CEP numbers (the inbound data) and maps it to the asset’s description when it creates the asset.
So, the first thing I have to track down is the delivered function module that controls this. The $OBJECT_ID shown below represents the ARO number and it is mapped to a function module LAGF_EXT_OBJECT_ID_GET.
After copying this FM to a z-version, I can insert some simple code to concatenate “ARO-” with the ARO-CEP numbers. This is obviously a development activity but it’s lower than junior level stuff and still something that can’t be done in other solutions without implicit enhancements or modifications. This is neither.
Then I create a new ValueID for the asset description and map it to this new z-function module.
Lastly, I have to map the ValueID ASSETDESC that I created earlier to the ANLA-TXT50 field on the asset master.
Now, after releasing a new ARO I can pull up the asset that was created and see that it’s description is now prefaced with “ARO”, thus making the object more easily identifiable. A small win, but a cool way to do it.
