Revenue Accounting and Reporting (RAR) | Concept and Configuration

1. Introduction

This blog starts by providing a brief understanding of IFRS (International Financial Reporting Standard) 15 – Revenue from Contracts with Customers and then lays down how SAPs RAR (Revenue Accounting and Reporting) solution helps in complying with the same. Towards the end, lists down some important configurations in SAP RAR (Revenue Accounting and Reporting).

RAR is also used to comply with ASC 606 – Revenue from Contracts with Customers.

2. Audience

Consultants/Business Users.

3. Purpose

• Understand the concept of IFRS 15 – Revenue from Contracts with Customers
• Understand SAP’s Revenue Accounting and Reporting (RAR)
• Configuration in Revenue Accounting and Reporting (RAR)

4. IFRS – 15: Revenue from Contracts with Customers

Introduction to the Concept
Let’s start with an investment decision scenario. Here we decide which is the best company to invest in purely based on financial data provided by them.

Below is an excerpt of financial data of two companies in the same line of business;By analyzing the above data, it is obvious that company B has a good ROI (Return on Investment) in fact 4.5 times that of company A and is the best place to invest in.

Now we will check some other facts and see if our decision to go with company B will change?

Other Facts;
• Both Companies had only one contract during the year.
• Company A’s contract is of 10,00,000 and to be delivered in 5 years. Fully invoiced and amount received upfront. The revenue is recognized only to the extent obligations are delivered, making it only 2,00,000 for the year.
• Company B’s contract is of 5,00,000 and to be delivered in 5 years. Fully invoiced and amount received upfront. Revenue is recognized based on the invoicing though the contract is not fully delivered.

With this new information, it reveals that company A is performing better than the company B, though the financial figures were misleading. The reason for getting mislead; company B did not follow the standard accounting principles while recognizing the revenue.

The main purpose why Accounting Standards got framed is to avoid such wrong decision making based on misleading data.

With Accounting Standards, comparison between two entities is possible when both maintain the same principle, otherwise proper comparison is not possible. As in our case both companies observed different accounting principles and the results were extremely misleading.

IFRS (International Financial Reporting Standard) 15 is one such standard which lays down the rule to recognize and report Revenue from Contracts with Customers. It specifies how and when to recognize revenue as well as requiring entities to provide users of financial statements with more informative, relevant disclosures.

Principles of IFRS 15
Though we will not get into the very details of IFRS 15 – Revenue from Contracts with Customers, we will understand the crux as SAP’s Revenue Accounting and Reporting (RAR) is a solution for IFRS 15 requirements.

The main objective of the new standard IFRS 15 is to provide a single, comprehensive revenue recognition model for all customer contracts, improving comparability within and across industries and across capital markets.

The principles in the standard will be applied using a five-step model:

• Identify the contract with a customer.
• Identify all the individual performance obligations within the contract.
• Determine the transaction price.
• Allocate the price to the performance obligations.
• Recognize revenue as the performance obligations are fulfilled.

Terminologies
It is also good to know some of the IFRS 15 specific words.

Performance Obligation; A promise to delivery good or service under a contract with a customer qualifies as a performance obligation if the good or service is ‘distinct’.

Standalone Selling Price; The price at which an entity would sell a good or service separately to a customer.

Contract Asset; Recognized Revenue is more than the Invoiced Amount.

Contract Liability; Invoiced Amount is more than Recognized Revenue.

Illustrations
Let’s try to understand this 5-step model with an illustration. We will take an example of a contract from a telecommunication industry, an industry heavily impacted by IFRS 15.

Step 1: Identify the Contract with a Customer
A contract is entered with a customer and following are the terms of the same;
• Device sold under contract at 13,000 INR, with 3 months free data subscription.
• Full amount settled at initiation of the contract.
• Device delivered immediately.
• Data service provided over the contracted period of 3 months.

Step 2: Identify all the individual performance obligations within the contract
This contract has two POBs (Performance Obligations) one delivery of device and the second one providing of data service over the period of 3 months.

Step 3: Determine the Transaction Price
In this the contract TP (Transaction Price) is 13,000 INR.

Step 4: Allocate the price to Performance Obligations
We have identified 2 POBs in this contract. The transaction price should be allocated between these 2 POBs in the ratio of their standalone selling price (SSP). As defined in IFRS 15, the SSP is the price at which an entity would sell a good or service separately to a customer. The SSP for device is 10,000 INR and for the 3 months subscription is 6,000 INR. Hence, the allocation amount for the Device will be 8,125 INR and for 3 months subscription will be 4,875 INR.

Step 5: Recognize revenue as the performance obligations are fulfilled
The revenue for the Device POB will be recognized as and when the device is delivered, which in our case is in the 1st month. Revenue relating to Subscription POB will be recognized over the period of 3 months equally as and when it gets fulfilled.
At the end of 1st month there will be a Contract Liability of 3,250 INR, as the contract amount is fully invoiced, and subscription for 2 months is yet to be provided.

Following is the pictorial representation of the illustration narrated above;
We also consider an illustration where in contact asset is ascertained.

 

5. Revenue Accounting and Reporting (RAR)

Overview
SAP Revenue Accounting and Reporting Component is based on the 5-step model of IFRS 15. In RAR system, data obtained from different source applications are processed to identify the POB and their recognizable revenue. During the period end, revenue as per IFRS 15 is recognized along with contract liability / contract asset if any and posted to accounting.

Architecture
Data flow to RAR system from different applications to calculate revenue, contract asset and contract liability as per IFRS 15. Data can flow to RAR with native integration from SD and Hybris, and from third party applications using BAdIs.

Following diagram depicts data flow architecture to and within RAR system.

Source Applications
SAP RAR is a standalone application and multiple applications (managing contracts) can be integrated directly into RAR through the ARL (Adapter Reuse Layer). RAR is compatible with SAP and Non-SAP applications.

Standard Integration Applications
1. SAP Hybris
2. Sales and Distribution

Third Party Applications
1. Data Hub Approach

In this approach data is gathered from various source systems, staged and processed in a SAP RAR compatible language before sending it to RAR.

The information flow from source applications to RAR provides details of Order, Fulfillment and Invoice of a contract. An order creates a contract in RAR, whereas fulfillment and invoice update an existing contract.

Adapter Reuse Layer
Data received from source applications generate RAIs (Revenue Accounting Items) to pass the contract information to RAR. SAP applications like SD can be configured to generate RAIs in ARL (Adapter Reuse Layer) automatically.

RAIs (Revenue Accounting Items) in simple terms can be referred to as common language understandable by RAR system. Data received from all the source applications generate RAIs (Revenue Accounting Items).

Once Revenue Accounting Items are created, they need to be processed to create/update RA Contract and POBs (Performance Obligations).

RAIs (Revenue Accounting Items) can be viewed and processed using RAI Monitor (Transaction FARR_RAI_MON).There are typically 3 stages/status in RAI processing; Raw, Processable and Processed. However, few stages can be skipped with integrated approach.

Each stages/status mean;

Raw: No validation done
Processable: Validation like master data, company code and so on done
Processed: RAI is processed, and corresponding Revenue Accounting Contract is created or updated successfully.

A RAI is created for each line item (Main Item) and corresponding conditions (Condition Item) for order, fulfillment and invoice.

Successfully processed RAIs will create/update RA Contracts and POBs based on rules set in BRF+ (Business Rules Framework).Once Order RAIs (Revenue Accounting Items) are processed, Contract No. and POB No. gets updated against each of the RAIs.

Business Rules Framework+
BRF+ is a standalone application and a prominent component in ARL (Adapter Reuse Layer). BRF+ is used to derive attributes of Revenue Accounting Contract and Account Determination with predefined business rules. BRF+ acts as an API as well as a User Interface to define and process business rules.

BRF+ as a standalone application, is not only integrated with RAR but can be integrated with other SAP applications like CRM, SRM and other custom applications also.

Following BRF+ application templates are delivered by SAP by default;
FARR_AP_SD_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration with Sales and Distribution (SD).

FARR_AP_CA_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration of SAP Hybris Billing (sender component CA).

FARR_AP_CRM_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration of SAP Customer Relationship Management (CRM).

FARR_AP_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration of any other sender component.

FARR_ACC_DETERMINE_TEMPLATE
Template for Account Determination.

Own BRFplus application can be created by copying the appropriate template application delivered by SAP and maintain installation-specific logic by maintaining the appropriate decision table entries.

BRF+ applications are assigned in the configuration for POB processing and Account Determination.

There are Decision Tables in each of these applications for specific purposes which contains condition columns and result columns. The result column data is identified and sent back to RAR based on condition columns data received from RAR system.

Following picture depicts input column (in blue) and output columns (in green);

Following are some of the decision tables provided in a BRFplus applications;
1. Updating POB Attributes
2. Getting SSP (Standalone Selling Price) for each POBs
3. Right of Return
4. Account determination for Contract Asset
5. Account determination for Contract Liability
6. Account determination for Recognized Revenue
7. Account determination for Rev. Adj. Allocation
8. Account determination for Deferred Cost

Revenue Accounting Contract and POBs
Revenue Accounting Contracts can be accessed by clicking contract number in RAI Monitor. Revenue Accounting Contract contains list of Performance Obligations under it along with detail status of each of the POBs.

Once Fulfillment or Invoicing is done, respective POBs gets updated.

Column ‘Invoiced Amount’ shows POB invoiced till date and column ‘Fulfilled Progress’ shows the status of fulfillment of the POB.

Column ‘Performance Obligation Status’, shows as ‘Completed’ once fully fulfilled and invoiced, otherwise ‘In Process’.Calculation of revenue is based on multiple attributes of a POB, which gets partially filled up by BRF+. Following picture depicts attributes of a POB;Revenue Accounting Contracts also show Revenue Schedule for each POBs, especially for Time Based.Revenue Schedule provides the projection of revenue to be recognized over the period of contact. It also shows the status of revenue recognized in each period.

Period End Processing
In Revenue Accounting and Reporting (RAR), 3 step period end closing happens.

Step 1 – Transfer Revenue
Purpose: Identifies the revenue to be recognized at the end of the specified period. However, doesn’t post any accounting entries.

SAP Path: Revenue Accountant > Revenue Posting > Transfer RevenueBy clicking on Transfer, a background job gets created.
The status of the job can be checked using Revenue Posting Jobs Monitor.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Jobs Monitor

Step 2 – Calculate Contract Liabilities and Assets
Purpose: Calculates Contract Asset or Liability at the end of the specified period. However, doesn’t post any accounting entries.

SAP Path: Revenue Accountant > Revenue Posting > Calculate Contract Liabilities and Assets

By clicking on Transfer, a background job gets created.
The status of the job can be checked using Revenue Posting Jobs Monitor.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Jobs Monitor

Step 3 – Revenue Posting Run
Purpose: Posts accounting documents based on the calculation done in earlier steps.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Run

By clicking on Post, a background job gets created which will post accounting documents. Before posting, simulation can be done to verify the entries.

The status of the job can be checked using Revenue Posting Jobs Monitor.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Jobs Monitor

Accounting Entries
Accounting entries gets posted from RAR during the period end processing in step 3. We shall consider the following scenario as the basis to understand the accounting entries;

Step 1: Invoice Posting
Following will be the accounting entry posted during billing/invoicing. There is no role of RAR in this entry;

Step 2: Invoice Correction (RAR) (Reversal of Invoice)
This is an entry from RAR which reverses the revenue recognized in Step 1. By this it nullifies the revenue posted earlier and with subsequent entries RAR will post actual revenue as per IFRS 15;

Step 3: Recognize Revenue (RAR) (Upon Fulfillment)
With this set of entries, RAR recognizes revenue as per IFRS 15. However, it first posts the Transaction Price and then adjusts it with the allocation effect. The result is nothing but the allocation of the POB for the period;

Step 4: Contract Assets and Liabilities (RAR) (Balance in Receivable Adjustment)
With this entry Contract Asset/Liability is posted;

 

6. Configuration

IMG path for RAR configuration can be accessed by Transaction FARR_IMG.

In this section some of the important configurations are highlighted. Please note the configurations here mentioned are not exactly the way it is arranged in FARR_IMG but have been put in line with the concept/flow discussed in the earlier section.

Source Applications
Step 1: Sender Component
As discussed earlier, RAR can support multiple source applications. The source applications are defined as sender component.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Sender Components

Sender Component is assigned to logical system and source document item types.

Step 2: Logical System
Define logical systems from which revenue accounting retrieves source items.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Logical Systems

Step 3: Source Document Item Types
The information flow from source applications is in the form of Order, Fulfillment and Invoice of a contract. These are defined as Source Item Types.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Source Document Item Types

Adapter Reuse Layer
Step 1: Interface Components
This configuration activity provides access to the interface components that can be used when defining revenue accounting item classes.

SAP provides preconfigured interface components that can be used immediately. These include basic components, which are mandatory for each record type, as well as other optional components which can be added to a Revenue Accounting Item Class.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Define Interface Components

Assign Structures, Prerequisite Components and Program Enhancements. Also define Key Fields and assign Components to Class Type and Record Type.

Step 2: Maintain Revenue Accounting Item Classes
Define revenue accounting item classes and their technical attributes. For each Revenue Accounting Item Class, it is required to define:
• The interface that you use to transfer revenue accounting item information to the system.
• The data store to be used for the revenue accounting items
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Maintain Revenue Accounting Item ClassesCustomer fields can be added to the RAI structures / Revenue Accounting Item Classes

Step 3: Generate Interfaces for Revenue Accounting Item Classes
Generate the runtime objects resulting from the Revenue Accounting Item configuration.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Generate Interfaces for Revenue Accounting Item Classes

Step 4: Assign Upload Rules to Revenue Accounting Item Classes
Define behavior of revenue accounting item class during upload. It can be;
1. Create RAI as Processable Item. Consistent items are created as processable items and Erroneous items are created as raw revenue accounting items.
2. Create RAI as Raw Item. Consistent items and erroneous items are created as raw revenue accounting items.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Assign Upload Rules to Revenue Accounting Item Classes

Step 5: Define Exemption Reasons for Revenue Accounting Items
We can exempt revenue accounting items from processing. In this configuration define the reasons for so and can specify whether the item can be restored or not.

This comes handy if there are issues with the Customizing or the item may be corrupt. The system then moves these items to a separate table which excludes them from ordinary processing.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Exemption Reasons for Revenue Accounting Items

Step 6: Define Restoration Reasons for Revenue Accounting Items
Define restoration reasons to restore Revenue Accounting Items that are exempted with an exemption reason. Once restored, they can be further processed in RAI monitor.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Restoration Reasons for Revenue Accounting Items

The option to Exempt or Restore RAI is available in Revenue Accounting Items monitor.

Business Rules Framework+
Step 1: Revenue Accounting Item Classes
BRF+ applications assigned to RAI classes to add business rules while creating/updating RA Contract and POBs (Performance Obligations).
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Assign BRFplus Applications to Revenue Accounting Item Classes

Step 2: Account Determination
Assign BRF+ application for account determination and FI postings.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Assign BRF+ Applications to Revenue Accounting Processes

Revenue Accounting Contract and POBs
Step 1: Accounting Principle-Specific Settings
Maintain different accounting treatment and presentation specific to Accounting Principle.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Configure Accounting Principle-specific Settings

Assign Company Codes to Accounting Principles.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Assign Company Codes to Accounting Principles

Step 2: Open and Close Revenue Accounting Periods
Configure whether an accounting period is open for revenue accounting related transactions. The settings in this activity provide a revenue accounting perspective of period closing. This is more of a periodic activity.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Open and Close Revenue Accounting Periods

Step 3: Number Ranges
Number Ranges – Contracts
Maintain number ranges for Revenue Accounting Contracts.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Number Ranges – Define Number Ranges for Contracts

Number Ranges – Performance Obligations
Maintain number ranges for Performance Obligations (POBs).
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Number Ranges – Define Number Ranges for Performance Obligations

Number Ranges – Run IDs
Maintain number ranges for Performance Obligations (POBs). Run IDs are reference numbers that the system uses to track background jobs created for revenue postings.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Number Ranges – Define Number Ranges for Run IDs

Step 4: Define Contract Categories
Define contract categories and assign number ranges to them.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Define Contract Categories

Step 5: Define Performance Obligation Types
Define performance obligation types and their associated attributes. POBs can also derive their attributes using BRF+ application.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Define Performance Obligation Types

Step 6: Condition Types
Maintain settings relating to condition types.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Condition Types

Define Reserved Condition Types

Define Condition Types Not Requiring Allocation

Define Roles for Condition Types

Step 7: Define Fulfillment Event Types
Different event types can be defined to recognize fulfillment. As per IFRS 15, revenue is recognized upon fulfillment.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Define Fulfillment Event Types

Step 8: Change Message Control
Configure how the system handles certain messages for Revenue Accounting.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Change Message Control

 

Period End Processing
Step 1: Define Posting Specifications for General Ledger Transfer
Maintain RAR posting related configuration like Posting Key, Document Type, Transfer Account for Document Splitting, Profit Center and so on. FI documents posted during period end processing will be based on this configuration.
SPRO Path : Revenue Accounting – Revenue Accounting Postings – Define Posting Specifications for General Ledger Transfer

Step 2: Configure Account Determination for Specific Transactions
This configuration allows to define rules that system uses to determine the accounts to make certain revenue-related postings. It can also be maintained in BRF+ application directly.
SPRO Path : Revenue Accounting – Revenue Accounting Postings – Configure Account Determination for Specific Transactions

 

Hope you find this blog helpful.

Introduction

This blog starts by providing a brief Introduction to IFRS (International Financial Reporting Standard) 15 – Revenue from Contracts with Customers and then explains the posting Process in SAP RAR. Also, it provides high level overview of direct posting functionality

Audience

Consultants/ Business users/ IT auditors

Purpose

Understand the posting process in SAP RAR

Get an overview on Direct posting functionality in SAP RAR

Configuration for Direct posting

Introduction to IFRS 15

The main objective of the new standard IFRS 15 is to provide a single, comprehensive revenue recognition model for all customer contracts, improving comparability within and across industries and across capital markets.

The principles in the standard will be applied using a five-step model:

• Identify the contract
• Identify the performance obligations in the contract
• Determine the Transaction price
• Allocate the transaction price to performance obligations
• Recognize the revenue

 

Recognizing the Revenue is the last step in the five step model and it is very crucial step. How to recognize the revenue is determined by the Performance obligation fulfillment type. There are 3 different fulfillment types as below.

• Event Based
• Time Based
• Percentage of completion

Revenue will be recognized when a performance obligation (POB) is fulfilled.

If the POB is Event based, revenue will be recognized on the occurrence of certain event (example, Goods delivery, Acceptance date, proof of delivery etc.)

If the POB is time based, revenue will be recognized on certain time or by passage of time.

If the POB is Percentage of completion, revenue will be recognized over a time based on the percentage of completion of activity.

 

Revenue Posting in SAP RAR  

Revenue recognition in RAR is mainly handled with 3 programs which are as below

• Transfer Revenue (Also called as Program A)
• Calculate Contract liabilities and Assets (Also called as Program B)
• Revenue Posting run (Also called as Program C)

 

To recognize the revenue, business users have to execute the above three programs in sequence and post the accounting entries. Lets us try to understand the three programs in a high level.

Transfer Revenue:

You can transfer revenue and cost to the revenue accounting subledger, and also calculate the exchange rate difference from the foreign currency revaluation which generates invoice records from the simplify invoice process.

Calculate Contract liabilities and assets

Revenue Accounting can calculate contract liability and contract asset, or unbillable receivable and deferred revenue, at performance obligation level. The calculation result can be posted either at performance obligation level or contract level. If contract liability and contract asset have been aggregated at contract level, you can also distribute them at performance obligation level by implementing a BAdI.

 

 

Revenue Posting Run

In this step, we execute the posting run program in order to generate the revenue posting document

Users have an option to run the posting either in simulation mode or in update mode. Simulation mode gives flexibility to users to validate the amount even before posting and once everything is fine, users can proceed to post in update mode.

Concept of Direct Posting

 

Revenue Accounting and Reporting works similar to the concept of subledger. Every Accounting entry generated in RAR for revenue recognition is first recorded in RAR (FARR_D_POSTING table )and will be pushed to ACDOCA table for recording in GL level.

With the latest RAR 2021, we have the flexibility to post directly in to FI GL – ACDOCA table with out making a posting in RAR (FARR_D_POSTING) table.

Direct Posting

You can enable direct posting if you want to have close integration with the universal journal by posting directly to the universal journal without Revenue Accounting (RAR) subledger persistence. Such a mechanism is called direct posting for the posting mode.

Configuration

To enable direct posting, you need to activate direct posting in Customizing for Revenue Accounting under Revenue Accounting Contracts  Define Posting Mode for Company Code.

 

 

Create Number ranges

 

Where do we use

We can use the direct posting on company code level, to achieve following

• Direct Posting to Universal Journal with out posting to RAR sub ledger
• Smaller posting granularity because posting takes place for each revenue accounting contract
• Event-triggered postings are enabled for revenue and cost recognition postings.

When we activate the Direct posting, we need to keep in mind the following points

• No data will be generated in RAR – FARR_D_Posting table
• No need to run the Program C – Start Revenue Posting run program
• We will continue to run Program A and Program B for Time based POBs and Contract Asset/ Contract liability calculations
• Posting documents are generated at contract level.

Process Execution Using Direct Posting Approach

Let us create one Contract and post using the direct approach.

Sales contract Created

 

RAI processed

 

After the sales order is proceed in FARR RAI MON, Revenue contract is created as below

FARR_D_CONTRACT Table

The contact has only had the time based POBs, so revenue will be recognized on passage of time. Since we are following the approach of direct posting, as soon as we run the Program A, system will post the accounting entry as below.

To recognize the contact liability / asset for the contract, we have to run the Program B.

 As you might have observed, we are able to post and recognize the revenue directly in ACDOCA with out running program C, this is possible only with direct posting functionality.

Error Handling

When a direct posting is in place, it is possible that error can occur due to many reasons. let us try to understand how to handle each error.

• If the Errors occurred during processing of RAIs, then we can push the RAIs to the status postponed and analyze the error them later.
• If the errors occur while running program A, then we can post the revenue postings to next period.

Conclusion

Direct posting functionality is introduced with RAR 2021 version. It can be activated by present customers who are using RAR and also customers newly implementing it. For existing customers, when we activate his functionality, it will be activated prospective only.

It is not recommended for the customers with High volume of transactions and postings.  Also, to have the direct posting functionality, customers must use the Optimized contract management aka Contract management functionality. It is not supported with classic contract management.

Hope this blog gives you reasonable understanding on the approaches of Revenue Posting in RAR

 

https://blogs.sap.com/2020/09/11/revenue-accounting-and-reporting-rar-concept-and-configuration/

 

Thanks & Regard

Prasad

 

 

FollowLikeRSS Feed

 

FollowLikeRSS Feed