Hello Forum,

This documnet will give you the detailed explanation of New asset accounting functionalities, configuration and end user screen details, I am hoping that this documnet will give some inputs about new asset accounting in simple finance.

Prerequisites for new asset accounting:

Enterprise activation EA-FIN is required for FI-AA (new), check the OSS note 1121965 for further functionalities and information.

For every additional currency type defined on the company code a corresponding depreciation area need to be set up.

Download Pre-check report (RASFIN_MIGR_PRECHECK) via note 1939592 and 2129306

New asset accounting features

• Fixed asset accounting based on universal journal
• After new asset accounting migration, previous year reporting is possible due to compatibility views.
• We have an option of assigning the depreciation is to accounting principle.
• Here we can segregate the accumulated depreciation and depreciation asset wise, but it is not happening now in classic asset accounting.
• Simplified chart of depreciation, only one depreciation area per valuation is necessary, no delta depreciation areas required for parallel valuation, but which is happening now in classic asset accounting.
• Flexible account determination and no more FI-AA reconciliation is required.

Benefits of new asset accounting:

• No more hard coupling of depreciation area 01
• Posting to different periods possible, but beginning /end of the FY need to be equal.
• New transactions for accounting principle, depreciation area specific documents.
• The beauty of new asset accounting is always systems will posts the separate documents per each accounting principle, like ledger specific document in new GL.
• As I said above details depreciation postings will happen each asset wise.
• The traditional asset tables like ANEK, ANEP, ANEA, ANLP & ANLC now replaced with ACDOCA and ANEK table data will be replaced with BKPF; we will call ACDOCA as a universal journal table.
• Due to compatibility views  we will get the old year reports in new asset accounting.
• In new asset accounting technical clearing account acts as a zero balance clearing account in new GL and it is a offsetting account.
• In new asset accounting after posting the document, the display document in FB03 contains the special tab of Asset accounting display, once you click on this document it will give you the accounting principle wise posted accounting document, here the technical clearing account will acts as a offsetting account in both the accounting principles.

The below picture will give you the clear understanding of local GAAP and IFRS will update, assume that if you are procuring 10000 EUR asset and in local gap you have to capitalize the 500 EUR freight charges. Here we have IFRS and LGAAP as two different accounting principles.

• In AW01N transaction you have hierarchical views for both accounting principles and we can differentiate the same.
• The AFAB depreciation screen modified completely and you can give the company code range in AFAB screen, accounting principle specific we can run the depreciation.
• Now the reason for posting run options are obsolete in AFAB.

• In the classic asset account, system won’t allow you to post any depreciation if you have errors in depreciation run, but now in new asset accounting, you can exclude the errors and can execute the depreciation for other assets, like cost estimate for materials in CK40N.

• Former IMG activity reset posted depreciation is obsolete due to redesign of depreciation run.

Balance Carry forward:

Configuration changes:

Define Depreciation area :–

      Financial Accounting (New) -> Asset Accounting (New) -> Integration with General Ledger Accounting -> Define How Depreciation Areas Post to General Ledger (TCODE - OADB)

      Here we define depreciation area for minimum of all accounting principle with different currencies.

Define Technical Clearing account:

      Financial Accounting (New) -> Asset Accounting (New) -> Integration with General Ledger Accounting -> Define Technical Clearing Account for Integrated Asset Acquisition

   We define technical clearing account at chart of account level and/or also with different account determination basis.

Define depreciation area for quantity update (if necessary):

      Financial Accounting (New) -> Asset Accounting (New) -> General Valuation -> Depreciation Areas -> Define Depreciation Area for Quantity Update

      Quantity updates in real time is possible for depreciation areas other than 01. This function is especially relevant in case of collective low-

      Value assets. Currently the system uses depreciation area 01 for updating quantities unless we have configured different depreciation area for the same.

Define alternative Doc. Type for Original Trans.Type (if necessary):

      Financial Accounting (New) -> Asset Accounting (New) -> Integrated Transactions: Alternative Doc. Type for Acctg-Princpl-Spec. Docs -> Specify Alternative Document Type for Acctg-Principle-Specific Documents

            This configuration can be necessary, if we are using functionality of document splitting and we want the document splitting rules to be

      Different for the business transaction variant of the valuating document (asset acquisition) and the operative document (Accounts Payable).

      This configuration could also be necessary, if our organization requires that the valuating documents are posted with a different document 

      type than the operational documents.

      This configuration can be made company code dependent as well as company code independent.

Define Revenue Distribution for Fixed Asset Retirement:

      Financial Accounting (New) -> Asset Accounting (New) -> Transactions -> Retirements -> Gain/Loss Posting -> Define Revenue Distribution for Fixed Asset Retirement

      At company code level we specify how the system is to distribute revenues arising from asset retirements: either based on the net book

      Value or acquisition / production costs (APC). In the standard system, the distribution is based on the net book value

Smoothing is no more relevant (and available) any more

Welcome your valuable inputs and happy learning.

Regards,

Ravi

Outbound & Inbound IDOC Relationship for Message Type FIDCC1

Assume the below scenario,

1. The requirement is to transfer the FICO transaction data between two systems (say from Source System X10 to Target System X20).
2. A Financial Accounting document is posted in source system (X10) and an Outbound IDOC is generated for message type FIDCC1 (for both Accounting and Controlling Document) in X10 system.
3. Program that transfers the FICO transaction data between systems – how it is accomplished.
4. FICO transaction data gets transferred to the Target System X20 and an Inbound IDOC is generated for the message type FIDCC1 in X20 system.

There could be instances thousands of accounting and controlling documents gets posted in SAP systems on a particular day and difficult to track the inbound IDOC’s created in the Target system for the respective outbound IDOC generated in the source system. Here I have tried to explain on how to relate or match the Outbound & Inbound IDOC’s from business user’s perspective.

Step 1: Posting FICO Accounting Document in Source System (X10)

Assume a vendor invoice 0500000010 is posted and an outbound IDOC is generated for the message type FIDCC1. The Relationship browser can be used to identify the Outbound IDOC generated for this vendor invoice.

The outbound IDOC reference created for the accounting document being posted can be easily obtained from FB03àRelationship option (refer above screen shots)

The relationship window in the above menu displays the Outbound IDOC 42138 for the message type FIDCC1.

The IDOC can be displayed using the transaction WE02.

Step 2: Finding the relation of the Outbound and Inbound IDOC posted between the systems:

Solution 1: WE09

Enter the below details in the selection screen of the transaction WE09 to narrow down the output to the exact record. Enter the date and the Logical Message as “FIDCC1” as shown below. (Note: Execute WE09 in the target system)

The Segment, Field and the value details can be obtained from the source system IDOC. Here E1FIKPF is the Header Segment in the IDOC structure and BELNR is the Accounting document reference in the IDOC.

Execute the program now.

Here the relationship between the outbound IDOC 42138 and the Inbound IDOC 1824424 can be displayed and this Inbound IDOC number can be used to display the accounting document posted in the Target system X20.

Display the Inbound IDOC 1824424 in the target system using the transaction WE02 /WE05.

Document 0500000008 was the accounting document posted in the Target system for the corresponding accounting document in Source system 0500000010.

The same relationship can also be obtained from the target system accounting document.

FB03-->Environment-->Relationship Browser.

Solution 2: Usage of BD87

Execute the transaction BD87 in the Source System to find the Inbound IDOC created in the Target system.

Solution 3: BDM2

BDM1 – IDOC Tracing

Execute the transaction in the Source system (X10) to find the relationship between the Outbound IDOC created in the Source system and the Inbound IDOC created in the Target system.

• Enter the message type as FIDCC1 for FICO transactions.
• Enter the Partner Type of the Receiver: LS (Logical System), because the transfer is between the systems. The detail can also be found in the Outbound IDOC created in the Source system. Use transaction WE02/WE05 as explained previously.
• Enter Partner Number of the Receiver: The Partner number can be found in the Outbound IDOC created in the Source system.
• Use transaction WE02/WE05 as explained previously.

Use the above information for IDOC tracing.

*************************************End of the Document********************************************************************

Working capital is a significant component in any enterprise’s financials and it is important that the organization accords enough importance to the working capital in order to ensure the right balance between liquidity and profitability. Receivables constitute a substantial proportion of the working capital. Therefore management of working capital would imply management of receivables also. An organization is therefore required to determine the optimum level of credit and also its management.

The management of receivables within SAP is governed by SAP Credit, Collection and Dispute Management module.

This document deals with the Collection management module of SAP Financial Supply Chain Management.

Traditional ways of managing receivables include ageing reports and dunning. These reports are no longer supported in today’s world and a more dynamic approach to credit management is needed. With Collection Management, SAP has brought about a paradigm change in the way receivables are managed.

In Collection Management, we follow up on the receivables based on the priority accorded to the customer. This is a more scientific and proactive way of keeping track of the customers as customers who are likely to default are given higher priority and are effectively followed up.

This document is divided into 2 parts- Part 1 would deal with the basic configuration settings in Collection Management module and the Part 2 would deal with the process flow in SAP.

Note:Customers need to be created as business partners with role collection management.

The important steps in configuration of Collection Management are as follows:

Basic Data configuration:

Define Company codes for SAP Collection Management

The company codes for which Collection Management is required to be activated are defined in this step. The SPRO path for this is as follows:

Financial Supply Chain Management-Collection Management-Basic Settings for Collection Management-Basic Data-Define Company Codes for SAP Collections Management.

Defining Collection Strategies:

Collection Strategy is a set of rules based on which customers are accorded valuated and accorded priority in the worklist. The collection strategy will also help to determine the currency in which the worklist will be generated.

Creation of collection strategy is a three step procedure:

1. Defining Basic Rules
2. Defining Collection Rule
3. Processing of Strategies

Each of these steps are defined below:

Defining Basic Rules

The basic rules contain conditions which are used to determine the priority that has to be accorded to business partners in Collection Management i.e.-high/low.

SAP has already defined some Basic Rules and additionally own rules can be defined. For example, a basic rule can be the Risk category of the customer-higher the risk category of the customer the greater is the priority that has to be accorded to that customer.

The spro path for this is as follows:

Financial Supply Chain Management-Collection Management-Basic Settings for Collection Management-Collection Strategies-Basic Rules-Define Basic Rules

Define Collection Rules

A Collection Rule is a group of Basic Rules in Collection Management. The spro path for defining collection rule is given below:

Financial Supply Chain Management-Collection Management-Basic Settings for Collection Management-Collection Strategies-Collection Rules-Define Collection Rules

Processing of Strategies

A collection strategy groups together various collection rules. It helps to valuate the business partner based on points assigned to each of the collection rules contained therein, thereby determining the whether the business partner is more likely to default and whether more emphasis and has to be laid in following up with that particular customer:

The spro path for the same is defined below:

Financial Supply Chain Management-Collection Management-Basic Settings for Collection Management-Collection Strategies-Process Strategies

An example of a sample strategy for sample valuation of two customers is given defined below:

The sample consists of rules with valuation points assigned to it. The characteristics of two customers are defined and their valuation is derived thereof. As shown in the example above, a collection rule can also contain prerequisites. Collection rule 5 will be applicable to a customer only if the pre-requisite is fulfilled.

Defining priorities and its derivation:

In the above example we have derived the priority of customers A as very high and for Customer B as low. The derivation of priorities is based on the following configuration in SAP.

This is two-step process in SAP:

First is to define the priorities in the below spro path

Financial Supply Chain Management-Collection Management-Basic Settings for Collection Management-Collection Strategies-Priorities-Define Priorities

The next is derive the priority based on percentage point valuation. This is defined in the following spro path:

Financial Supply Chain Management-Collection Management-Basic Settings for Collection Management-Collection Strategies-Priorities-Define Derivation of Priorities.

Organizational Structure for Collection Management:

The organizational structure for collection management comprises of

• Collection segment
• Collection profile
• Collection group
• Collection specialist

Each of these elements are defined in the following spro path:

Financial Supply Chain Management-Collection Management-Basic Settings for Collection Management-Organizational Structure.

Collection Segment

A collection segment groups together company codes/credit segment in SAP. If receivables from two or more company codes are to be processed together they would be grouped into a collection segment.

Defining Collection Segment:

Assigning Company Codes/Credit Segment to Collection Segment

Collection profile

A group of collection segment comprises the collection profile. The collection profile is assigned to a business partner in the collection management segment.

Defining collection profile:

Assigning collection segment to collection profile

Assigning Collection Profile to the Business Partner in the Collection Management Role:

Collection Group

A collection group comprises of collection specialists who follow up with the customer for securing payments. A collection group is assigned a collection strategy. The implication of this is that all collection specialists who belong to a particular group will use the same strategy for the business partners assigned to them.

The collection specialist is provided with a worklist i.e. list of customers who have to be contacted, sorted in the order of priority. With this worklist so generated in SAP a collection specialist is equipped with all necessary information to contact the customer, recording of the conversation/promise made by the customer and the requirement to contact the customer on a particular day.

Defining Collection Group

Further a collection group will also be assigned to a collection segment:

A sample org structure in collection management is defined below:

In the above example, receivables of Customer 1 in Company code 1000 and 2000 are to be processed together-hence they are grouped to collection segment 1. Similarly its receivables in Company code 3000 and 4000 are to be processed together-hence they are grouped to collection segment 2.. Each of these collection segments(for instance, Coll Seg1) are assigned a collection group(for instance, Coll Group 1) which comprises of specialists(Mr A, B, C) who are assigned a strategy(Coll Stategy 1, in this case).

Once the org structure for collection management is ready the same, the next steps would be to transfer the customer open items from AR module in SAP to the Collection Management module in SAP. Thereafter worklist would be generated and monitored by the collection specialist. In the process promise to pay, re submission and dispute cases can be created. This would be dealt in the second part of the document.

Summary

The document provides technical details for building centralized SAP Finance Document validations that can be called remotely. The SAP validations are set up on the ECC system to validate a SAP documents before posting. there are various scenarios in which the ECC is the central instance for document postings/Payments however itself isn't a UI system for document entry, it just takes feed of document from various interconnected systems.

This document provides a solution to build a centralized Finance validation which can then be used to call from any SAP or Non-SAP integrated systems. The situation is very specific to business need and mostly applicable for highly integrated environment consisting of more then one Document posting systems with a centralized ECC.

The Need

Mergers, Mobile Apps, Integrated systems, cloud services are the Buzz word in IT, there are lot of integration's point behind all of these vast processes, Processes as they are much more than a mere technology and cater to a larger segment within a business processes.

In larger companies, where we have one of our ECC as a central instance and numerous technological setups connecting to it to produce an outcome, it becomes utter important to build a fully integrated system, whereby each system is talking in a real-time manner to others. This not only makes the integrated environment much more stable at a time but also helps to keep the customer trust (sic). The later is much more important for our ecosystem of providing flawless IT services. Having a centralized document validation not only decreases data footprint but also makes the maintenance cheaper, document entry faster and drastically decreases the time and resource utilization (man and machine) in re-validating documents at various stages of system interconnections.

The solution don't apply to scenarios were the connected system are posting directly to ECC using BAPI, obviously that don't require it as well, but for the cases whereby we consolidate our postings in a lot and post them on a single go or cases whereby the postings are happenings in a non-real time basis likewise using IDOCS, which decouples the fronted postings to IDOC travel and thereby imposes a fractions of delay or may be more.

The scenario

There are two business scenarios, one from a system merging and another from the point of generating a document

During my one of the merger implementation I come across a scenario of two ECC systems. Both were independent systems performing Procure to pay, end-to-end till the merger happened. Post merger one of the system has to give way to the other as a central payment system, but keeping the reporting’s and other downstream processing as it is. This means some of the relevant data (read postings) has to flow to the downsized (in terms of process) ECC for reporting’s and downstream.The replication of the documents was done using standard FIDCC IDOCs and is the reason the validation from the destination system were deferred to the time IDOCS were posted. This raised the need to call it earlier in time of posting at source system to avoid any IDOCS failures in receiving system..

As the reporting was separate so the validations for posting the same document in two different systems.

Another case is whereby we have a custom mobile applications for generating an invoices which are later posted onto ECC at a defined time in a day using file upload, Replicating the validations on to the mobile applications isn't a lean method of achieving the design, so our best bet was to call the ECC validations into the mobile engine, this make the usability more transparent for the user and at the same time a document posted on mobile guarantees a unstoppable posting on ECC. This was a hit from validation maintenance perspective as well

The Solution

Before we start with the solution the expectation is that it’s a complete custom solution, so must be used based on the need basis, it can be tweaked on requirement basis and must be thoroughly tested.

We will be using the three major standard function modules which are mostly called by standard SAP while running the Documents validation check.

Overall document validation check: FI_VALIDATION_DOCUMENT

CALL FUNCTION 'FI_VALIDATION_DOCUMENT'
TABLES
t_bkpf        = <Internal table to header BKPF Line>
t_bseg        = <Internal table to Document item BSEG Line>
EXCEPTIONS
error_message = 3
OTHERS        = 4.

Header validation check: FI_VALIDATION_HEADER

CALL FUNCTION 'FI_VALIDATION_HEADER'
EXPORTING
i_bkpf        = <Header BKPF Line>
EXCEPTIONS
error_message = 3
OTHERS        = 4.

Item validation check: FI_VALIDATION_ITEM

CALL FUNCTION 'FI_VALIDATION_ITEM'
EXPORTING
i_bkpf        = <Header BKPF Line>
i_bseg        = <Document item BSEG Line>
EXCEPTIONS
error_message = 3
OTHERS        = 4.

In our case, we built a wrapper remote function to call all these three validation in a go; this will serve as a final validation call at the remote application before it can be posted into the SAP system. The wrapper FM acts as a centralized validation engine which can be called at various applications be it connected R/3 or non--SAP System.

Conclusion

The document provides a basic guide to achieve centralized validation for integrated Finance document postings. The information can easily be leveraged to build some more complex and integrated Finance scenarios with other SAP or Non-SAP systems.

Feel free to add you views/Ideas in comments.

Document Description

This is a document with tips for PMW file format configuration (DME).

If you are looking for PMW Configuration, please take a look at

DMEE Configuration:Step By Step Part 1

sapnote 1788223  - Attachments - EN_Create_the_new_DMEE_format.pdf

Scenario 1

Create a flat file with the following structure:

Header

      Payment Document

            Invoice

            Invoice

            ........

      Payment Document

      .........

Trailer

The file has the following definition:

- Header: 01 ; Payment Document: 02: Invoice: 03 ; Trailer: 09

- File is has a fixed structure, no separator character

- The DME separates payment documents according to House Bank

- Payment Method has different values defined by the Bank

- Trailer Section has a control on payments done by Total Records & Amount paid

The file format generated with DME is attached in the following document for analysis purpose

Solution

1) Get Payment information

2) Set levels of record type

3) Set Constants

4) Assign field values

5) Define output value according to a schema

6) Count records on file

7) Total Paid Amount

8) Create technical node

9) Create Composite node

10) Export / Import DME file

11) DME debug

1) Get payment information

Run Payment Program and execute FM

          fi_regu2fpay              Completes tables FPAYH, FPAYP

          fi_paym_fill_fpayhx    Completes table  FPAYHX

With the information obtained from Payment Run (tables REGUH, REGUP), fill parameters in the function modules described above and identify the data your need.

The file is generated with trx FBPM

2) Set levels of record types

trx DMEE

3) Set constant

4) Assign field Value

5) Define output value according to a schema

Payment Method D -> 02

Payment Method I  -> 03

6) Count records on file

7) Total Paid Amount

8) Create Technical node

A technical Node does not send element into the file

It used for temporary calculations or data

9) Create Composite node

It's logical division in the DME structure used to group different fields

10) Export / Import DME File

Export / Import DME structure to another system. You can also edit the DME file to change language.

DME structures cna only be maintained in original language

11) DME Debug

trx DMEE_DEBUG

Setup a break in DME Element to debug PMW

Revenue Recognition in SAP

Revenue Recognition is the process of recognizing the income, when a sale contract is fulfilled and ownership of goods/service are transferred from the seller to the buyer or customer. Traditionally revenue recognition happens in SD through the billing invoice functionality in SAP. The traditional Revenue recognition functionality in SD works as below:

SAP SD offers an integrated Revenue recognition based on SD Documents. With SD Revenue Recognition, invoices are posted to Deferred Revenue (depending on Previous Recognized Revenue Items) with recognized revenue also posting to COPA.

What Changes with New Updates on IFRS 15?

IFRS 15 is an accounting standard promulgated by IASB providing guidance on accounting for revenue from Contracts with customers. It was adopted in 2014 and will become effective as mandatory for US and most of Europe from January 01, 2018. The IFRS 15 has new disclosure changes, both quantitative and qualitative information about the amount, timing and uncertainty of revenue from Contracts with customers. The New IFRS 15 and ASC 606 revenue accounting standard basically follows a five step model for recognition of revenue:

Drawbacks in Existing SD Revenue Recognition Process:

1) No multiple Element Arrangements:  The traditional Revenue Recognition in SD does not offer allocation of transaction price, one of the fundamental step for New updates on IFRS 15. Revenue is always recognized separately for every SD Order Item according to its pricing conditions.

2) Parallel Accounting: The traditional Revenue Recognition cannot manage different accounting principles. With New GL, it makes an accounting postings to all the ledgers at the same time (Ledger group is blank on the accounting document header), negating automation and increasing the reconciliation efforts for accounting teams.

3) Cost Recognition: COGS is not reconciled with revenue recognized. However, SD can recognized the cost only at the time of PGI or billing depending on the set up of pricing schema in SD

4) Disclosures and Reporting capability: The traditional SD Revenue Recognition is not capable of meeting the new disclosure requirements for IFRS 15

Impact of the changes Accounting Standard IFRS 15 on Customers

The new accounting standards is a mandatory rule for US and Europe. Early adopters of IFRS can start earlier. The customers most impacted by the New Standard are as below:

Example of Revenue Recognition in case of Multiple Arrangements

Mr A buys a Phone for $ 1 from a telecom company with a guaranteed Service Contract of $ 20 per month for 24 Months. The total Transaction price for phone and service contract for Mr A will be = (1+(20x24)=$ 481)

Mr A can also buy the Mobile Phone on a standalone basis for $180. Mr A can also enter into a standalone service contract with the telecom company for $16 per month for 24 Months (Total Transaction Price = 16x24=$ 384)

In this case, if Mr A purchases the service contract and phone from the telecom company, the charge for the mobile and service contract has to be allocated over a period of 24 Months to recognize revenue as per IFRS 15.

Allocated Price of Mobile Phone = Standalone Selling Price of Mobile Phone/(Sum of all Stand Alone Selling Price)* Complete Transaction Price

The SAP Revenue Accounting and Recognition Component is based on the 5-step model of IFRS 15 and also meets the requirement of FAS 2014-09/ ASC 606:

Step 1: Revenue Accounting combines items from different operational systems like SD, CRM or non SAP Systems in one single revenue accounting contract. The contract is the operational object for the determination and allocation of Transaction Price

Step 2: The Performance Obligation (POB) is the level, where the Standard Selling Price (SSP) is determined or defined, price is allocated and fulfillment (POC) is determined. Most of the times it would correspond to a line item of an operational contract, but it may also be a combination of several items Eg, from a Sales BOM, implicit obligation ( Eg, Upgrade for a licensed Software)

Step 3: The transaction price is determined from Pricing Conditions of operational document such as a sales order.

Step 4: The Transaction Price is allocated to POB of a contract on a relative SSP basis

Step 5: Revenue is recognized on the completion of POB. The completion can be defined as an event or over time. The over time fulfillment can be calculated based on time based or based on Percentage of Completion.

With the above design principles, the SAP Revenue accounting and recognition (RAR) Component has been introduced. It is an optional download component on SAP ERP (ECC). The Component is the only possible component for Revenue Recognition in SAP S/4HANA Finance

The component can be downloaded by any customer with SAP S/4HANA

The Current version of RAR available is 1.1 and version 1.2 has been released to a select customers.

In the next part of this series I will talk about the set up of SAP RAR 1.1 and the accounting flow for revenue recognition through the same.