accrual engine by sap

Accrual Engine&

Applications

Introduction for Consultants

SAP AG 2002, Title of Presentation, Speaker Name 2

This presentation was created by the developers of the Accrual Engine and is regularily updated.

Last update: March 22nd 2006.

The authors apologize for any typing errors and probably bad English.

Preface


Content

Introduction: Accruals Overview: Accrual Engine Architecture

Customizing the Accrual Engine Customizing: Customer-Defined Accrual Methods Customizing: Account-Determination Debit and Credit Indicators Periodic Accrual Run

Applications that Use the Accrual Engine Manual Accruals

Example with Screen Shots Excursus: Status of Accrual (Sub-)Objects Reversal of Accrual Subobjects Working with Derived Accrual Types Customer-Defined Parameters Customer-Defined Additional Account Assignments Populating Additional Fields in Accounting (incl. Customer-Defined Fields) Assignment Number and Automatic Clearing Parallel Accounting Validation Customer-Defined Navigation Archiving Accrual Engine Data

Provisions for Awards Example with Screen Shots

Lease Accounting (Part of Leasing Solution - Separate Course)

Introduction:

Accruals


1000

What Are Accruals?

800 1200 700 1100 500 1400 1100 800 1100 1100 1200

12,000

Per

iod

1

Per

iod

2

Per

iod

3

Per

iod

4

Per

iod

5

Per

iod

6

Per

iod

7

Per

iod

8

Per

iod

9

Per

iod

10

Per

iod

11

Per

iod

12

Given: Value + time interval Task: Distribute value over time interval

Simple Example:


Simple Posting Example

D CP&L D CAccrual

12 000 (1)

800 (3) (3) 800

1 200 (4) (4) 1 200

1 000 (2) (2) 1 000

Accounting: Accruals = Periodic postings


Accrual Engine: Where Are Accruals Needed?

Contract business transactions: Insurance, leasing etc.

Contract-like business transactions: Bonds with fixed interests, magazine subscriptions etc.

Any periodic postings based on an amount or value:Provisions for Awards

Overview: AccrualEngine

Architecture


Accrual Engine: What it does

Accrual

Engine

Input:Contract-like information Output:

Periodic postings


Accrual

Engine

SDP

Leasing

Manual Accruals

CRM (future) IBS

Media

(future)

...

Provisions forAwards

Accrual Engine: A Generic Tool

Input

Input

Input Input

Inpu

t

Input

Output:Periodic postings


Accrual Engine: Some Features

New component in MySAP Financials

Highly flexible tool

Storage of all relevant dataInput (contract-like information incl. history!) Output (posted accruals)

Accrual Engine = ‘Accrual subledger’

Mass data processing, performance optimized


Accrual Engine: Benefits

Automated periodic calculation of accrualsNo recurring entries with fixed values!

Automated periodic posting (self correcting!)

Simulation tools (e.g. future accruals)

Supports multiple GAAPs

Comprehensive reporting tools

Integration with BW (Business Information Warehouse)


Accrual Engine: Architecture

Basis Data (Accrual Objects)

AccrualMethod

Trigger Calculation ofAccruals

Periodic:Calculate Accruals

Calculation

Create/Change

Basis Data

R

Posting

R

CreateAccounting Documents

Transfer Datato Accrual

Engine

R

Build Delta toalready posted

values

Posted Values(Accrual Engine Documents)

PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Processes


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting

Process A:Create/Change

Basis Data

Process B:Calculateand PostAccruals


Accrual Engine: Accrual Methods


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Delta Logic


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Account Determination


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Structure of Basis Data


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Structure of Basis Data

Accrual Object

Accrual Subobject

Accrual Subobject

Accrual Subobject

Accrual Item

Assignment

Parameters

Cost center, business area, profit center, ...

Customer-defined fields like ‘Product Group’, ...

Start-date and end-date of time interval for accrual

Does not carry any information; links accrual subobjects

Each combination of

- Accrual Type (costs, revenues,...) and

- Accounting Principle (IAS, US GAAP, ...)

defines an Accrual Item:

The total value to be accrued, the total quantity to be accrued and the Accrual Method (linear/periodically, linear/daily) can be entered at this level.

Header

...

Accrual Item

Accrual Item

...


Accrual Engine: Posted Values


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Reporting of Posted Values


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting

Technical Details:

Database Tables in the

Accrual Engine


Database Tables in the Accrual Engine

Accrual Objects

Basis Data Posted Values

Cutomizing Tables

Customizing Tables Customizing Tables

Accrual Engine (general)

Calculation Posting

Time-Dependent Master

Data (‘Basis Data’) Accrual Engine Documents and

Total Values


Database Tables in the Accrual Engine

ACEOBJ

ACEDSOH

ACEDSOI

ACEPSOH

ACEPSOI

ACEPSOIT

ACEDSASSGMT

Field Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XACRTYPE XACCRULE XDATE_TO XDATE_FROM AMOUNTCURRENCYQUANTITYUNITACRMETHODTIMESTMP

Field Name KeyMANDT XCOMP XBUKRS XOBJID XREF_KEYSTATUS

Field Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XDATE_TO XDATE_FROMVALITY_FROMVALITY_TOUNAMECPUDTCPUTMREF_SUBKEYSTATUS

Field Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XUNAMECPUDTCPUTMDEACTDATEREF_SUBKEYSTATUSFIRSTYEARLASTYEAR

Field Name KeyMANDT XCOMP XBUKRS XGJAHR XOBJID XSUBID XACRTYPE XACCRULE XCUMVALCAPCUMVALACCRVALCAPVALACCRVALRETIRELASTEFFDATECURRENCY

Field Name KeyMANDT XCOMP XBUKRS XGJAHR XOBJID XSUBID XACRTYPE XACCRULE XDOCNR XVALCUMVALTBPCURRENCYTRANSTYPEEFFDATEPOPERRUNIDAWTYPAWKEYAWSYSTIMESTMP

COMP XBUKRS XOBJID XSUBID XDATE_TO XDATE_FROMBUS_AREADATE_FROMPROFIT_CTRCOSTCENTERORDERIDWBS_ELEMENT

ACEDSOPField Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XDATE_TO XPARAM_NAME XCONTENTDATE_FROM

ACEDSOI_ACCOUNTSField Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XACRTYPE XACCRULE XDATE_TO XDATE_FROM INC_START_ACCNT INC_TARGET_ACCNTPER_START_ACCNTPER_TARGET_ACCNT FIN_START_ACCNTFIN_TARGET_ACCNT

Customizing theAccrual Engine


Customizing: IMG for the Accrual Engine


Customizing: Dependent on the Component

F4

Start


Customizing: Important Activities

Assign company codes to the Accrual Engine Define accounting principles and Assign accounting principles to company codes Define accrual types (costs, revenues etc.) Define accrual methods (linear etc.); separate chapter! Define posting control (summarization etc.) Define number ranges for accrual postings (4 different number

ranges!) Define account determination; separate chapter! Additionally: IMG activities specific for the application

component of the Accrual Engine, e.g.: Manual Accruals:

Define accrual object types (Insurance, Renting etc.) Define number ranges for accrual objects

Provisions for Awards: Define RFC destination for data transfer from HR system


Customizing: Important Activities


Customizing: Important Entities

The most important entities in the accrual engine are

acrual type and accrual method.

They are both defined in the customizing of the accrual engine.Their meaning is the following:

accrual typeThe accrual type defines, what is to be accrued, i.e. costs or revenues.It also determines, which kind of postings (opening, periodic and/or final posting) are done. The account determination usually depends on the accrual type.

accrual methodThe accrual method defines, how the accruals have to be calculated, i.e. linearly, degressively, … The customer can program his own accrual methods.


Customizing: Settings of the Accrual Type

Start


Customizing: Settings of the Accrual Type

Most important setting that is done in the accrual type is the setting for the accrual postings. The following settings are possible:

ALLThis means that the following three postings are done:

a) An opening posting (process = ‚I‘), when the accrual (sub)object is created.b) Periodic postings (proess = ‚P‘) are done by the periodic accrual run.c) If the accrual (sub)object is terminated before it has reached the end of ist life time,

then the remaining value which has not yet been accrued, is posted with a final posting (process = ‚F‘).

Only PeriodicNo opening posting is done. Only during the periodic accrual run, periodic postings with process = ‚P‘ are done.

Opening posting onlyOnly an opening posting is done (process = ‚I‘), when the accrual (sub)object is created. No periodic postings are done during the periodic accrual run.

NoneNo accrual postings are done at all.This setting can be reasonable if the accrual values are needed for display only, e.g. as explanation for other accrualtypes which are determined by a complicate algorithm.


Customizing: Example for ‘All Postings’

D CAccrued Revenues

18 000 (I)

D CClearing Account

(I) 18 000

D CRevenues

300 (P.1)

(P.1) 300

300 (P.2)

(P.2) 300

…

…

(P.18) 300

(F) 12 600

300 (P.18)

12 600 (F)


Customizing: Example for ‘Periodic postings only’

D CProvisions

300 (P.1) 300 (P.2) …

300 (P.x)

D CExpected Expenditure

(P.1) 300(P.2) 300…

(P.x) 300


Customizing: Link from Messages to IMG

Long t

ext

Customizing:Customer-Defined Accrual

Methods


Customizing: Customer-Defined Accrual Methods

SAP delivers a number of accrual methods:Linear, periodically Linear, daily with 365 daysLinear, daily with 360 days...

Accrual methods are ordinary function modules Customer can define (develop) his own accrual

methods by programming corresponding function modules with the ABAP workbench.


Customizing: Developing Accrual Methods (1)



Most important is the internal table CT_PERIOD_VALUE. The entries in this table have to be modified (filled) by the accrual method:

The accrual method has to populate the following three fields in the internal table CT_PERIOD_VALUE:

VALACTThis field has to be filled with the value that has to be accrued between the dates DATE_FROM and DATE_TO

VALCUM This field has to be filled with the value that has to be accrued during the time before DATE_FROM

VALREMAIN This field has to be filled with the value that remains to be accrued after DATE_TO.

Important: No records may be deleted or inserted into this table CT_PERIOD_VALUE; only the above mentioned three fields have to be filled.Other fields may not be modified!



In the interface of the function module contains also additional parameters which contain information for which accrual object the accrual method is currently called.

These parameters may not be changed by the accrual method. Their meaning are the following:

1. Import structure IS_ACE_KEYThis structure contains the unique key of the accrual item in the database tables of the accrual engine.Note: Usually you will not need to use this parameter to read data from the accrual engine database tables, since all relevant information is passed from the accrual engine to the accrual method by the other parameters like IT_GENERAL_PARAMS etc.



2. Import table IT_GENERAL_PARAMSThis table is importing only: The records contained in this table may not be changed. The table contains the time dependent header and item data of the accrual subobject, i.e. the following fields:

AMOUNT (and CURRENCY)The total value which is to be accrued.

QUANTITY (and UNIT)The total quantity which is to be accrued.

VALITY_FROM and VALITY_TOLife time of the accrual subobject, i.e. the interval in time, in which the accrualshave to be done.

FY_VARIANTFiscal year variant. Needed only,if the periods need to be determinedfrom the dates.



3. Import table IT_PARAMSThis table is importing only: The records contained in this table may not be changed. The table contains entries with the customer-defined parameters of the accrual subobject. See separate chapter ‘Customer-Defined Parameters’.The parameters can be used to determine the accrual values.

PARAM_NAMEName of the parameter.

CONTENTThe value of this parameter



4. Import table IT_COMP_SIMUPARAM_RANGESThis table is importing only: The records contained in this table may not be changed. Usually this table is empty and not used.It is intended to be used for simulation of periodic accruals:If the simulation is done with certain assumptions (technically: Additional input fields on the entry screen of the periodic accrual report), this table would contain a table with the entered data for these additional fields:

FIELDNAMEName of the additional input field.

FIELDRANGETable with the entered select-options.

Note: The additional fields have to be added to the selection screen usingselect-option-statements.This possibility is not available in standard.Contact the SAP development for further information, if needed.



4. Export table ET_RETURNIf messages appear in the accrual method, they can be put into this table.Only the following fields have to be filled, if a message appeares:

TYPEType of the message (‘E’ for Error, ‘W’ for warning etc.)

IDMessage class of the message.

NUMBERNumber of the message in the message class.

MESSAGE_V1, …, MESSAGE_V4Parameters for the message, if required by the message.



When developing accrual methods it is very important to note that the accrual method can called from several programs.

The CT_PERIOD_VALUE table can contain different entries.More detailed:

The accrual method is called during the periodic accrual posting run.In this case, the accrual method is called for the key date that was entered on the entry screen: The CT_PERIOD_VALUE table contains exactly one single entry. In this entry DATE_FROM = DATE_TO = key date of the accrual run!

The accrual method is called from the display transaction for accrual objects (e.g. the ACACTREE02 transaction). In this case, the CT_PERIOD_VALUE table contains several entries: One entry for each period, i.e. DATE_FROM <= DATE_TO in each entry.

The accrual method is called during the data extraction to BW (data warehouse).In this case, CT_PERIOD_VALUE usually contains one entry in which DATE_FOM <= DATE_TO.

The accrual method has to populate correctly the CT_PERIOD_VALUE table in all of these cases! All three cases should be tested thoroughly!



Display of the accrual object (e.g. ACACRTEE02 transaction):The accrual method is called and CT_PERIOD_VALUE contains several entries for the complete life time of the accrual subobject.



DATE_FROM DATE_TO VALACT VALCUM VALREMAIN

01.01.2000 31.01.2000 150 0 885001.02.2000 29.02.2000 150 150 870001.03.2000 31.03.2000 150 300 855001.04.2000 30.04.2000 150 450 840001.05.2000 31.05.2000 150 600 8250…

DATE_FROM DATE_TO VALACT VALCUMVALREMAIN

01.01.2000 31.01.2000 0 0 001.02.2000 29.02.2000 0 0 001.03.2000 31.03.2000 0 0 001.04.2000 30.04.2000 0 0 001.05.2000 31.05.2000 0 0 0…

Accrual Method

1. Example (correct): Accrual Method filles the value fields VALACT, VALCUM and VALREMAIN in the CT_PERIOD_VALUE table.




01.01.2000 31.01.2000 150 0 885001.02.2000 29.02.2000 150 100 875001.03.2000 31.03.2000 150 300 855001.04.2000 30.04.2000 150 450 840001.05.2000 31.05.2000 150 600 8250…

DATE_FROM DATE_TO VALACT VALCUMVALREMAIN

01.01.2000 31.01.2000 0 0 001.02.2000 29.02.2000 0 0 001.03.2000 31.03.2000 0 0 001.04.2000 30.04.2000 0 0 001.05.2000 31.05.2000 0 0 0…

Accrual Method

2. Example (incorrect): Accrual Method filles the value fields VALACT, VALCUM and VALREMAIN in the CT_PERIOD_VALUE table, but makes a mistake by popuplating the field VALCUM incorrectly:

In period 2/2000, the cumulated value (VALCUM) is 100, but should be 150.




01.01.2000 31.01.2000 150 0 885001.02.2000 29.02.2000 150 100 875001.03.2000 31.03.2000 150 300 855001.04.2000 30.04.2000 150 450 840001.05.2000 31.05.2000 150 600 8250…

Automatic correction after Accrual Method

2. Example (incorrect, continued): After the accrual method was called, the system automatically corrects the wrong cumulated value in period 2/2000 by adjusting VALACT and VALCUM):

In period 2/2000, VALACT and VALCUM are corrected.The correction value is stored in the field VALCORR.

DATE_FROM DATE_TO VALACT VALCUM VALREMAIN VALCORR

01.01.2000 31.01.2000 150 0 8850 001.02.2000 29.02.2000 100 150 8750 -5001.03.2000 31.03.2000 200 250 8550 5001.04.2000 30.04.2000 150 450 8400 001.05.2000 31.05.2000 150 600 8250 0…



Periodic accrual run (e.g. ACACACT transaction):The accrual method is called and CT_PERIOD_VALUE contains exactly one entry in which DATE_FROM = DATE_TO = key date from the entry screen of the periodic accrual run.



The slides before showed, how accruals are calculated by the accrual method.This slide now shows, how the system calculates the value which is to be posted in an periodic accrual run:

In the periodic accrual run, the system would sum up the two values

CT_PERIOD_VALUE-VALACT (Value of the current period) and

CT_PERIOD_VALUE-VALCUM (Value from former periods):

This sum is assumed to be the value which should be the cummulative accrual value at the key date of the periodic accrual run.

The other field CT_PERIOD_VALUE-VALREMAIN is not important, since it is not used for postings. But it might be interesting for reporting purposes.

In case that accruals have already been posted by the periodic accrual runs at former key dates, the system would post the delta, so that after the current accrual run, the above sum is the cummulative accrual value (balance).

Customizing:Account

Determination


Customizing: Account Determination

When posting Accruals, Accrual Engine documents are created in the Accrual Engine. These documents consist of only one line item without GL accounts and without CO assignments like cost center etc.

When the Accrual Engine documents are transferred to Accounting (which is usually done automatically when they are posted), an Accounting document with two line items is created from the Accrual Engine document.

At this point in time, the Accrual Engine account determination is executed to get the following information:

Start account Target account Document type



The customizing of the account determination is done in two steps: Define the customizing tables for the account determination

The customer can define himself, which dimensions determine the accounts and document type!E.g. the ‘Process in the Accrual Engine’ and ‘Accrual Type’ determine the start and target account

Create customizing entries in these self-defined customizing tables!


Customizing: Example for Account Determination

The accounts which are used in an accrual posting depend mainly on the following criteria:

Process in the accrual engine

I: Opening posting (This posting is optional, depending on the setting of the accrual type).This posting is done, when the accrual (sub)object is created.The opening posting usually posts the total value which is to be accrued to an accrual account.

P: Periodic accrual posting The periodic posting is done by the periodic accrual run.It usually posts from the accrual account to a P&L account.

F: Final posting (This posting is optional, depending on the setting of the accrual type).It is only executed if

a) an opening posting was done andb) the accrual (sub)object is terminated before it has reached

the end of ist life time. Accrual type

Since the accrual type determines the kind of accruals (e.g. costs or revenues), it is clear that the accounts usually depend on the accrual type.

As a consequence, the account determination will usually depend on these two criterias (see next slide).


Customizing: Extended Account Determination

In addition to the ordinary account determination, there exists also a so-called ‘extended account determination’.

Both of these account determinations use the same derivation tool! Only difference: The extended account determination offers more

features than the simple account determination. Basis idea of the extended account determination is explained in the

following example: Accruals have to be done in a lot of company codes. In all companies, the same logic is to be used to derive the accrual accounts. Problem: The accounts depend on the chart of accounts, but the chart of

account is different in each company code. Solution:

Do not derive the accounts directly, but derive only account symbols. In a second step of the account derivation, derive the account from account symbol

and chart of accounts! This two-step logic can be done in the extended account determination.

Debit and Credit Indicators


Debit and Credit Indicators in Accrual Postings

Postings which are done by the Accrual Engine create two kind of documents:

Accrual Engine documents Accrual Engine documents are stored in the Accrual Engine and each document consists of one line item only: This line item contains the information which value was accrued for which accrual object in which period.

Accounting DocumentsThe Accrual Engine document is automatically transferred to Accounting. During this transfer from each Accrual Engine document two line items are created in the Accounting document.The account determination yields the necessary two accounts: Start and target account:

Accrual Engine document: 100 EUR - 100 EUR to start account

100 EUR to target account

Accounting document


Debit and Credit Indicators in Accrual Postings

The debit and credit indicators are determined from the sign of the Accounting line item:

If the value is > 0, then the debit indicator is set, If the value is < 0, then the credit indicator is set.

Accrual Engine document: 100 EUR - 100 EUR to start account

100 EUR to target account

Accounting document

Credit: 100 EUR to start account

Debit: 100 EUR to target account

Accounting document

Periodic Accrual Run


Periodic Accrual Run

The periodic accrual postings are done by starting a periodic job, the periodic accrual run.

The periodic accrual run isstarted for a key date.Note: Not all key dates are allowed. Only those key dates can be entered, which are defined by the settings of the accrual type, see next slide.


Periodic Accrual Run: Customizing

The allowed dates which can be used as key date in the periodic accrual run are determined by the ‘frequency’ which is entered in the posting control of the accrual type.Example: If the frequency is ‘Per posting period’, then only the last day of a period is allowed as key date. Possible dates are then e.g. 01/31/2000, 02/29/2000, … But not dates like 01/01/2000 or 02/15/2000.


Periodic Accrual Run: Execution Type

Usually, the periodic accrual run has to be executed for all dates which are defined by the ‘frequency’ in a rising order.

Example:If the frequency is ‘Per posting period’, days 01/31/2000, 02/29/2000 etc. are possible. After the periodic accrual run was executed for 01/31/2000, the next run is assumed to be at 02/29/2000.

If the run 01/31/2000 has to be repeated, e.g. because additional accrual objects were created after the first run was already

executed or the first run was executed not for all relevant accrual objects due to entered

select options,

than the execution type has to be set to ‘Repeat’ instead of ‘Normal’.

If one or several runs have to be skipped, e.g. after the run on 01/31/2000, the next run will be not on02/29/2000, but on 03/31/2000, then thethan the execution type has to be set to ‘Unplanned’.


Periodic Accrual Run: Log

The already executed periodic accrual runs are logged on company code level.

You can display the log in the entry screen of the periodic accrual run by ‘Environment -> Log of Periodic Accrual Runs’:


Periodic Accrual Run: Key Dates in the Past

It might be necessary that an accrual run is executed with key date 01/31/2000 despite there was already an run on 02/29/2000.

By default, this is forbidden by the system:An Error message (ACEPS 054) is sent, if key date 01/31/2000 is entered on the entry screen of the periodic accrual run.

Solution: Enter the key date 01/31/2000 and(!) set the execution type to ‘Repeat’. The system will send error message ACEPS 055, but this message can be switched off with the OBA5 transaction.Support Package SAPKGPAA12 is required as prerequisite in release extensions 1.0 / 1.1!

Background for this restricted possibility to enter ‘past’ key dates:If there were already periodic accrual runs in future fiscal years, the values which were posted in these future years are then wrong. Consequence: Accrual runs in future years have to be repeated.


Periodic Accrual Run: Message Log

Messages which occur in a periodic accrual run are looged in the so-called application log.

You can display this log in the entry screen of the periodic accrual run by ‘Environment -> Display Application Log’:

Applications that Use the Accrual Engine


Applications that Use the Accrual Engine

Manual Accruals

Provisions for Awards

Lease Accounting

Manual Accruals


Manual Accruals: Overview

Purpose: Post accruals for contract-like data

Create ‘contract data’ (accrual objects) manually in the Accrual Engine

Start periodic accrual posting runs



AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting

Manual Accruals

CreateAccrual Objects

Manually


Manual Accruals: Interface for Creating Accrual Objects

In the application component ‘Manual Accruals’, accrual objects are created manually, but SAP also delivers an interface for creating accrual objects.

The interface is the function module ACAC_OBJECT_MODIFY_EXT

There are two ways to use this interface: Customer can develop a report to create accrual objects using this interface.

The report would work in the following way:

Select contract-like data which is to be accrued.The data can be selected from any source!

Transform the selected data into the format that is needed by the interface. Save the transformed data as accrual objects in the Accrual Engine.

Easier way: SAP delivers a sample report which can be used for transferring vendor invoices into the Accrual Engine and it can be reused for transferring data from any source to the Accrual Engine (see next slides)


The sample report SAP delivers is ACAC_DATA_TRANSFER_EXAMPLE

This report selects vendor invoices and creates the line items of the corresponding FI document in the Accrual Engine as accrual objects

There is also a detailed program documentation (red circle) which describes the meaning of the parameters

Manual Accruals: Automatic Datafeed (1)



The selection screen of the sample data transfer report consists of the following subscreens:

General selectionsThese parameters are specific for the vendor invoices: They are used for selecting the vendor invoices.

Accrual ParametersThese Parameters are used for creating the accrual objects. Example: If you enter the accrual method ‘LINEAR’, the accruals are calcuated linearly periodically).

Posting parametersNeeded only, if an opening posting is done by the Accrual Engine, when the accrual object is created, according to the customizing of the accrual types.

Control parametersMost important is the selection method which is described in the next slides.


Basic idea of the sample report is that all kinds of data transfers into the Accrual Engine work in a similar way:

First the data have to be selected The data have to be transformed into the format of the Accrual Engine The data have to be saved in the Accrual Engine A results list has to be created

In addition, each data transfer report must contain a lot of ‘administration overhead’:

Checking and setting locks Checking the user input Connecting the Schedule Manager Checking errors bevor saving(!) and error handling Creating an output list Testrun feature and possibility of deleting data from the Accrual Engine

The sample report has all of these features and can even do more: The sample report can be reused for selecting data from any source

(see next slides)!



Selection Methods in the sample report enable the customer to use the sample report to select data from any sourceand transform the selected datainto the format that is required by the Accrual Engine

The selection methods can be defined in the customizing.This customizing can be found in the sample report in the menue: ‘Environment -> Settings -> Selection Methods for Data Transfer’




Definition of selection methods:



Selection methods consist of two parts: A function module for selecting the data which shall be transferred into

the Accrual Engine. This function module must also transform the data into the format that is required by the Accrual Engine.

A DDIC-Structure which contains the fields which are to be displayed by the sample report as results list.

SAP deliveres sample selection methods for the transfer of vendor invoices into the Accrual Engine.

Please study also the F1 help for the field ‘selection method’ on the entry screen of the sample report ACAC_DATA_TRANSFER_EXAMPLE and study also the program documentation of this report.

In the source code, there’s a documentation of the function modules that are used in the sample selection methods (Function modules ACAC_DATA_TRANSFER_EXAMPLE_1 and ACAC_DATA_TRANSFER_EXAMPLE_2).


A problem for the selection methods are the select-options:The sample report must ‘tell’ the function module (e.g. ACAC_DATA_TRANSFER_EXAMPLE_1) which data to select.

Of course, the required select-options and parameters of the data transfer report depend on the source from which the data are selected. From this it is clear, that the selection-screen of the sample report is not suitable for all selection methods:The selection screen of the sample report ACAC_DATA_TRANSFER_EXAMPLE was made for selecting vendor invoices.

But since all the program logic of the data transfer program is identical for all data sources, SAP separated the selection screen from the program logic in the following way:

The sample report consists only of a few includes: One include for each subscreen on the selection screen

E.g. include ACAC_DATA_TRNSF_SELOPT_EXAMPLE. Some includes for the program logic (e.g. includes

ACAC_GENERIC_DATA_TRANSF_M10 and ACAC_GENERIC_DATA_TRANSF_F10).



The includes marked with red lines can be replaced by customer-defined includes which contain the select-options that are required.

First, the report ACAC_DATA_TRANSFER_EXAMPLE has to be copied into the customer name space to avoid modifications. Only the main program has to be copied, not the includes!

Aferwards, the includes can be replaced by customer-defined includes.



How the select-options are transferred from the selection screen to the function module that is used by the selection method:

Since the interface of the function modules (used by selection methods) are generic, the select options are contained in an internal table (parameter IT_GENERIC_SELOPT).

This works in the following way: The sample report scans the selection screen and puts all select-options into this table which have the addition ‘MODIF ID SEL’.This table is then passed to the function module of the selection method.

A similar logic is used for the accrual parameters:All select-options which have the addition ‘MODIF ID ACP’ are put into the table IT_ACCRUAL_PARAMS and passed to the function module of the selection method.




The addition ‘MODIF ID SEL’is important in the include with the select-options for the data selection.



Example: Results list from transferring vendor invoices to the Accrual Engine Double click on a line in the list of results displays the accrual engine

object with the accrual data



Deleting of data in the Accrual Engine

Expert Mode On


Manual Accruals: Basis Data Structure

Accrual Object

Accrual Subobject

Accrual Item

Assignment

Parameters

Cost center, business area, profit center, ...

Customer-defined fields like ‘product group’, ...

Start-date and end-date of time interval for accrual

Defined by the Accrual Object Type / Accrual Object Number combination

Each combination of

- Accrual Type (Costs, Revenues,...) and


defines an accrual item.

The total value to be accrued, the total quantity to be accrued and the Accrual Method (linear/periodically, linear/daily) can be entered at this level.

Header

Accrual Item

Accrual Item

...

1:1


Manual Accruals: Application Menu


Manual Accruals: Customizing

Manual Accruals:Examples


Manual Accruals: Sample ‘Insurance Contract’

Contract data: Valid from 01 Jan. 2000 until 31 Dec. 2004 (5 years)Annual premium (to be paid by customer): 3,600 EUR

Revenues: Customer pays 5 x 3,600 EUR = 18,000 EUR

Costs: Salesman gets 6,000 EUR bonus

Costs and revenues must be accrued over 5 years Monthly revenues: 300 EUR = 18,000 EUR / (5 x 12) Monthly costs: 100 EUR = 6,000 EUR / (5 x 12)


Manual Accruals: Create Accrual Object


Manual Accruals: Accrual Object and Subobject


Technical Background: Accrual Object and Subobject


Manual Accruals: Architecture


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Manual Accruals: Create Accrual Object


Manual Accruals: Opening Postings


Manual Accruals: Navigation

Place cursor in ‘COSTS’ line

and double-click or

press ‘Transfer Accrual Item’

button


Manual Accruals: Documents in FI



D CAccrued Revenues

18,000 (I.1)

D CAccrued Costs

(I.2) 6,000

D CReceivables

(I.1) 18,000

D CPayables

6,000 (I.2)


Manual Accruals: Start Periodic Accrual Run


Manual Accruals: Result of Periodic Accrual Run


Manual Accruals: Display Accrual Object after Periodic Accrual Run


Manual Accruals: Documents in FI

D CAccrued Revenues

18,000 (I.1)

(P.1) 300

D CReceivables

(I.1) 18,000

D CRevenues

300 (P.1)


Manual Accruals: Posting Deltas

In each period, the following accruals are calculated: Revenues (Accrual Type RVNUES): 300 EUR Costs (Accrual Type COSTS): 100 EUR

In the first period (1/2000) these values were posted correctly. Now let us assume that the customer forgets to carry out the accrual run in

2/2000. The next accrual run is carried out in 3/2000. The Accrual Engine then calculates that in 3/2000 the accrued values should

be: Calculated Revenues: 3 x 300 EUR = 900 EUR Calculated Costs: 3 x 100 EUR = 300 EUR

In 3/2000, the Accrual Engine then posts the difference between the calculated values and the values already posted:

Posted Revenues: 3 x 300 EUR - 300 EUR = 600 EUR Posted Costs: 3 x 200 EUR - 100 EUR = 200 EUR

This is displayed in the next slide


Manual Accruals: Posting Deltas


Manual Accruals: Changing the Accrual Object

Let us make the example more complex: Change to total costs which are to be accrued:

On 31 March 2000, the following costs had already been accrued: 3 x 100 EUR = 300 EUR

On 15 Feb. 2000, the premium for the salesman is raised from 6,000 EUR to 9,000 EUR

When changing the total costs to be accrued from 6,000 EUR to 9,000 EUR, the opening posting of 6,000 EUR is reversed and a new opening posting of 9,000 EUR is posted. Periodic costs are now calculated to be 9,000 EUR / (5 x 12) = 150 EUR

In the next periodic accrual run on 30 April 2000, Accrual Engine calculates the following costs: 4 x 150 EUR = 600 EUR

On 30 April 2000, the Accrual Engine posts the delta of 600 - 300 = 300 EUR automatically.



D CAccrued Costs

(I.1) 6 000

D CCosts

6 000 (I.1)

(I.3) 9 000 9 000 (I.3)

(I.2) - 6 000 - 6 000 (I.2)


Manual Accruals: Display History of Accrual Object



D CAccrued Costs

D CPayables

(I.1-3) 9,000

9,000 (I.1-3)

D CCosts

300 (P.3) (P.3) 300

200 (P.2) (P.2) 200

100 (P.1) (P.1) 100


Manual Accruals: Totals

The Accrual Engine stores Accrual Engine documents and totals. One total record exists for each year. Accrual Engine Customizing: Only 2 years can be open for periodic

accrual postings.Usually, only the currentyear is open, while theprevious year might also stillbe open for closing entries

Creating an accrual object:A total record is createdfor each year that is open.


Manual Accruals: Totals

Automatic carryforward to year 2001

Opening posting in year

2000


Manual Accruals: Carryforward

At the end of the year, a fiscal year change program (carryforward) must be started in the Accrual Engine.

This program creates total records for the new fiscal year for all accrual objects for which a corresponding record does not yet exist.

This carryforward does not lead topostings in Accounting

The carryforward also increasesthe ‘current year’ in Accrual EngineCustomizing.

In the example: The carryforward program does not have to be started atthe end of fiscal year 2000, since a total record already exists for 2001.However, it does have to be started at the end of 2001. Of course, it is advisableto execute the carry forward at the endof each fiscal year.


Manual Accruals: Deactivating an Accrual Subobject

Let us assume that a customer quits an insurance contract before it ends. The contract was supposed to run from 1/2000 until 12/2004, but customer quits in 6/2001.To stop accrual postings in 6/2001, the accrual subobject is deactivated on 06/30/2001.

The total costs to be accrued were 9,000 EUR.At the end of 6/2001, 150 EUR x (12 + 6) = 2,700 EUR had been accrued.The rest: 9,000 EUR - 2,700 EUR = 6,300 EUR may not be accrued any more. Accordingly, the remaining revenues of 18,000 EUR - 300 EUR x (12 + 6) = 12,600 EUR may not be accrued any more.

In Customizing for the accrual types (COSTS and RVNUES), customers can determine what happens with the remaining values. They have two options:

Do nothing with the remaining values after deactivation. Simply stop posting periodic accruals.

When deactivating the accrual subobject, perform a closing posting and post the remaining costs and revenues to a different account.



Final posting at deactivation

Excursus:Status of Accrual Objects


The processing status can be set on two levels in the Accrual Engine: on level of accrual object and on level of accrual subobject.

Status of Accrual Objects and Subobjects

Disp. Tech Data


Status of Accrual Objects

The status of an accrual object can have the following values: ‘In Process’ ‘To Be Archived’.

The status of the accrual object usually is ‘In Process’.

The status ‘To Be Archived’ can be set by the transaction ‘Prepare Archiving Session’:The archiving session will archive only those accrual objects which have the status ‘To Be Archived’ (see chapter ‘Archiving Accrual Engine Data’).

Please refer to the documentation in the customizing and to the F1 help for further information.


Status of Accrual Subobjects

The status of an accrual object can have the following values: ‘In Process’ ‘Completed’ ‘Stopped’

The status of the accrual object usually is ‘In Process’. The status ‘Completed’ is set when the user executes the function

‘Deactivate Accrual Subobject’ (see chapter before). The status ‘Stopped‘ means that no accrual postings are done as long

as this status is active. Setting this status is -up to now- supported only by the Leasing application.

The history of changes of the status of the accrual object is recorded in the basis data of the accrual engine.Exception: Setting the status ‘Stopped’ is not recorded in the basis data.

Please refer to the F1 help of the status for further information.

Reversal of Accrual Subobjects



Let us assume that a customer wants to delete an accrual subobject.

As documents are normally created in Accounting for an accrual subobject, the original documents (Accrual Engine documents) cannot be deleted, since they are needed for the Audit trail, i.e. for explaining the Accounting Documents. It is therefore not possible to delete accrual subobjects.

Instead, customers have the option of ‘reversing’ accrual subobjects. This reversal does the following:

All Accrual Engine documents that were posted for this accrual subobject are reversed.

The total value and quantity to be accrued are set to zero for all accrual items. The zero values are valid from the reversal date.Consequence: No more accrual postings will be made for dates subsequent to the reversal date.

Features of the reversal: It is not possible to reverse accrual subobjects that have been deactivated.


Reversal Postings in the Accrual Engine

It is possible to reverse certain Accrual Engine documents Reversal of periodic accrual runs Reversal of complete accrual subobjects including all corresponding Accrual

Engine documents.

There is no ‘true’ reversal of Accrual Engine documents:Reversals are new postings with reversed +/- signs.

Consequences: The corresponding FI documents are not reversed. Instead, new FI

documents are created with reversed values. The reversal documents are always created based on the basis data for the

accrual subobject that is valid at the key date of the posting.Changes to the basis data should therefor be made for dates in the past.


Example of Reversal Posting

Carry out accrual posting (run) on 31 Jan. 2000.The cost center in the basis data of the accrual object on this date is CC01. In Accounting, the posting is made to cost center CC01.

The cost center is changed to CC02 on 15 March 2000 in the Basis Data.The next accrual posting run is carried out on 31 March 2000.The corresponding posting in Accounting is made to this new cost center CC02 as this cost center is valid on key date 31 March 2000.

Now reverse the two accrual postings:The reversal posting for the first posting on 31 Jan. 2000 is posted to cost center CC01, since cost center CC01 is still valid on key date31 Jan. 2000. The reversal posting for the second posting on 31 March 2000 is posted to cost center CC02.

If the cost center had been changed on a different date, say 15 Jan. 2000,, the reversal posting on 31 Jan. 2000 would be posted to new cost center CC02 instead of CC01.Reason: In this case, the new cost center CC02 would be valid on 31 Jan. 2000.

Working with Derived Accrual Types

New Example


Manual Accruals: Derived Accrual Types

Derived accrual types can be used for calculating accruals from other accruals types.

(New) Example:

Customer gets a discount of 10 % Discount: 18,000 EUR x 10% = 1,800 EUR The discount must be treated differently according to IAS and HGB (German

GAAP):HGB: Discount is posted once when the contract is createdUS GAAP: Discount has to be accrued during the life of the contract.

The monthly accrual value is 1,800 EUR / (5 x 12) = 30 EUR


Manual Accruals: Example of Derived Accrual Types

According to US GAAP, additional accrual postings have to be made for the discount.

These additional postings can be made with the help of derived accrual types using the following rule:

“In US GAAP, the discount is calculated by taking 10 % of the revenues in HGB”.

The following activities have to be performed in Accrual Engine Customizing: Create the new accrual type “DISCNT” The above rule is entered in activity “Define Calculation rules for Derived Accrual

Types”.


Manual Accruals: Customizing Derived Accrual Types

Customer-Defined Parameters


Customer-Defined Parameters

Customer-defined parameters are additional fields that can be entered by users when creating or changing accrual objects

Customer-defined parameters are entered at the accrual subobject level

The values entered here can be used in Accrual Methods

The parameters can contain additional information that can be used in customer-defined accrual methods

Account DeterminationThe parameters can also be used in Accrual Engine account determination

BAdIs Parameters can be used in BAdIs for modifying documents before they are transferred to Accounting.


Where Do Customer-Defined Parameters Appear in the User Interface?


How to Define Parameters

Parameters are fields in DDIC structure ACAC_PARAMETERS.This structure contains only one parameter, named ‘EXAMPLE’.

Additional (customer-defined) parameters can be created by adding the corresponding fields to this DDIC-structure.For this purpose, SAP has added the customer include CI_ACAC_PARAMETERS to this DDIC-structure.

To create additional parameters, start transaction SE11 for data type CI_ACAC_PARAMETERS and choose the ‘Create’. A popup now appears, where you have to choose ‘Structure’ radio button.

Enter the parameters as fields. Note that the field names must start with ‘Z’ or ‘Y’.

Save and activate your entries.



F4


Entering Parameters

Choose ‘Enter Parameters’


Entering Parameters


Evaluating Parameter Values in Periodic Accrual Runs


Parameters in Account Determination


Parameters in Account Determination

F4


Parameters for Other Components

The preceding slides described the procedure for creating additional parameters for Manual Accruals.

For other applications of the Accrual Engine, such as Provisions for Awards or Lease Accounting, the procedure for creating additional parameters is almost identical to the procedure described for Manual Accruals.

However, you should note the following differences:The name of the DDIC structure is different to ACAC_PARAMETERSAssignment of parameters to accrual object types is only necessary

in Manual Accruals


Parameters for Other Components: DDIC Structure

Customer-Defined Additional

Account Assignments


Additional Account Assignments

In the Accrual Engine some account assignments can be entered, like

Cost center Internal order WBS element Business area Profit Center.

Not all possible account assignments are supported by the accrual engine. E.g. it is not possible to post to a network or network activity.

Because of this it might be necessary to enable more account assignments (like network).


Additional Account Assignments (Rel. 1.0)


Additional Account Assignments (Rel. 1.0 + 2.0)

The assignments are stored in the database table ACEDSASSGMT. This table contains two substructures:

ACE_PL_ASSIGNMENTS‘PL’ stands for ‘profit and loss’; the fields of this structure like ‘cost center’, are moved into line items where the GL account is a profit and loss account. They are not moved into line items where the GL account is a balance sheet account.

ACE_BS_ASSIGNMENTS‘BS’ stands for ‘balance sheet’; the fields of this structure like ‘business area’, are moved into line items where the GL account is a balance sheet account. But they are also moved into line items where the FL account is a balance sheet account, I.e. these fields are moved into both types of line items.

Both of these two structures contain customer includes, CI_ACE_BS_ASSIGNMENTS and CI_ACE_PL_ASSIGNMENTS

where customer-defined fields can be added. In rel. Extensions 2.0 these fields are then automatically displayed on

the screen.


Additional Account Assignments (Rel. 1.0 + 2.0)

Posting of Accounting Docs

with the Accrual Engine


The accrual engine does accrual postings: If the corresponding accrual type is customized accordingly then the accrual engine executes one, several or all of the following type of postings:

Opening postings The full amount which is to be accrued is posted, usually to an accrual account. This posting is executed, when the accrual object is created.

Periodic accrual postings These postings post a certain value which is calculated by the accrual method. This value is usually a part of full value (which is to be accrued). It is usually posted from the accrual account to a P&L account. These postings are executed by the periodic accrual run which is usually started at the end of each period.

Final postingsIf the posting of accrual has to be terminated before the full value has been (periodically) accrued, then the remaining value is posted to a certain account.

Other types of postings which are less important These postings have been explained in examples in detail before. Each posting creates an accrual engine document and this document

is transferred automatically to accounting.

Accounting Docs: Basics Of The Accrual Engine


The accrual engine document consists of one line item only: This line item contains the value which is to be posted, the key date which is used as translation date and as default posting date in accounting. It also contains the reference, to which accrual object it belongs.

The transfer of accrual engine documents to accounting consists of the following steps:

Accounting Docs: How They Are Posted

The system transforms the accrual engine document into a (temporary/preliminary) two-line document. These temporary documents are not saved. After this step, this temporary document can be modified with the BAdI ‘ACEPS_BAPIPREDOC_MOD’ (see IMG of the accrual engine).

The system summarizes the two-lined documents and transforms them into another format, which is required by the BAPI, see next step. These documents are not saved, too.After this step, the summarized documents can be modified with the BAdI ‘ACEPS_BAPIDOC_MODIFY (see IMG of the accrual engine).

Finally, this document is transferred to accounting by calling the BAPI BAPI_ACC_DOCUMENT_POST. This BAPI creates all the documents in accounting, like the FI document and –if required- the CO document.These accounting documents are saved in the corresponding database tables.


Accounting Docs: Overview

Accrual Engine Document

Preliminary two-lined document

FI document CO document

AccountingCall BAPI

BAdI ACEPS_BAPIPREDOC_MOD

BAdI ACEPS_BAPIDOC_MODIFY

Summarized document

Accrual Engine

How to Fill Special Fields in the

Accounting Documents


The accrual engine only populates some of the fields which exist in the accounting document: The fields that are filled by the accrual engine are contained in the complex DDIC structure ACEPS_BAPI_PREDOC. Included in this structure is the DDIC structure ACEPS_BAPI_PRELINEITEM which contains all the fields which are filled in the line item of the accounting document.

The complete set of fields which are available in the accounting document can be viewed in the DDIC structures

BAPIACHE09 (document header) BAPIACGL09 (line items) BAPIACCR09 (currency information)These structures are the interface of the BAPI which is used for posting the

accounting documents.

It might be necessary from the customers point of view that some fields have to be populated which are

available in the BAPI interface (e.g. in the BAPIACGL09 structure) but not available in the preliminary document (e.g. structure

ACEPS_BAPI_PRELINEITEM), i.e. they are not filled automatically by the accrual engine.

To fill these fields there are two BAdIs available (see next slides).

Special Fields in the Accounting Documents


BAdI ACEPS_BAPIPREDOC_MOD:

is used to fill special fields in the accounting document which depend

on the accrual object.

In this BAdI interface the accrual engine document is available

which contains the link to the accrual object.

BAdI ACEPS_BAPIDOC_MODIFY:

is used to fill fields in the summarized document, I.e. immediately

before the document is transferred to accounting with the BAPI.

In this BAdI interface the accrual engine document which contains the

link to the accrual object is not available anymore.

available BAdIs in Accrual Engine

Customer-defined fields in Special Ledgers


A more complex problem are customer-defined fields in a Special Ledger: It might be necessary that these fields are populated when documents are posted by the accrual engine.

The problem is that the customer-defined fields do not exist in the BAPI interface (DDIC structure BAPIACGL09) and also not in the preliminary documents in the accrual engine (DDIC structure ACEPS_BAPI_PRELINEITEM). Because of this, the fields cannot be populated by postings which are done by the accrual engine in standard, i.e. inhancements like BAdIs are necessary to solve this problem.

The task is to transport the values of the customer-defined fields from the accrual engine, through the BAPI which creates the accounting documents, through the accounting interface into the special ledger.

The following slides visualize the problem and its solution.

Customer-Def. Fields in Special Ledgers


Excursus: Architecture of Accounting in R/3

FI PrCtrCO SL CONS

Accounting Interface

CO-PA

DDIC structures:ACCHDACCITACCCR

FI interface CO interface CO-PA intf. PrCtr interf. SL interface CONS interf.

BAPI


SL


SL interface

BAPI

Excursus: Architecture with Accrual Engine



Summarized document

Accounting

Accrual Engine


Customer-Def. Fields in Special Ledgers: Steps 1+2

FI PrCtrCO SL CONS


CO-PA

DDIC structures:ACCHDACCITACCCR

FI interface CO interface CO-PA intf. PrCtr interf. SL interface CONS interf.

BAPI

Step 1 (precondition): A special ledger was configured, which contains a customer-defined field, e.g. the field ZZREGION.

Step 2 (precondition): The customer-defined field must also be added to the accounting document line item (ACCIT structure), so that it can be ‚transported‘ from the BAPI through the accounting interface to the special ledger.


SL


SL interface

BAPI

Customer-Def. Fields in Special Ledgers: Step 3+4



Summarized document

Accounting

Accrual Engine

Step 3: The customer-defined field must also be added to the line item of the preliminary two-lined document (ACEPS_BAPI_PRELINEITEM structure; with the SE11 transaction).

Step 4: A BAdI implementation has to be defined for the

BAdI ACEPS_BAPIPREDOC_MOD. In this BAdI the field ZZREGION has to be filled.


Customer-Def. Fields in Special Ledgers: Step 3


Customer-Def. Fields in Special Ledgers: Step 4


SL


SL interface

BAPI

Customer-Def. Fields in Special Ledgers: Steps 5+6



Summarized document

Accounting

Accrual Engine

Step 6: The value for the customer-defined field has to be moved from the line item of the summarized document into the Extension table. This is done in a BAdI implementation for the BAdI ACEPS_BAPIDOC_MODIFY.

.

Step 5: To make the new field ZZREGION available in the BAdI ACEPS_BAPIDOC_MODIFY, this field has to be added to the DDIC structure BAPIACGL09.


Customer-Def. Fields in Special Ledgers: Steps 5



SL


SL interface

BAPI



Summarized document

Accounting

Accrual Engine

Step 7: The value for the customer-defined field has to be moved from the Extension table into the line item of the accounting document (ACCIT table). This is done in an implementation for the BAdI ACC_DOCUMENT.

Assignment Number and Automatic Clearing


Assignment Number: General

The assignment number in FI documents is usually needed to carry out clearing automatically.

The assignment number can be useful for clearing postings to accrual accounts if open item management is active for the accrual account.

Open posting (I.1) and periodicpostings (P.2 - P.4) should be cleared after the last periodic posting (P.4).

For this reason, the automatic clearing (report SAPF124) is run after posting (P.4). Condition: All documents (I.1), (P.2), ... (P.4) must contain the sameassignment number.Problem: The Accrual Engine does not add the assignment number to the Accounting documents.

D CAccrual Account

3,000 (I.1)

(P.3) 1,000

(P.4) 1,000

(P.2) 1,000


Assignment Number: How it can be entered

The Assignment Number is not entered in postings made by the Accrual Engine, as this number should in principle be unique for each accrual item, but then no summarization would be possible during transfer of Accrual Engine Documents to Accounting.

As a result, the Accrual Engine does not enter the assignment number.

However, it is possible to fill the assignmentnumber using the BAdI (Business Add In) ACEPS_BAPIPREDOC_MOD:

The customer has to define an implemation for this BAdI in Customizing.

Parameter CS_BAPI_PREDOC-LINEITEMS contains field ALLOC_NMBR (‘Assignment Number’). This field can be filled by thecustomer when implementing the BAdI.


Example: How to fill the assgmt number in postings

The assignment number can be filled in the BAdI ACEPS_BAPIPREDOC_MOD by the customer.

The following slides are intended to help the customer to define an implementation for the BAdI with a source code that filles the assignment number reasonably in case of the application ‚Manual Accruals‘:

It would be natural to use the accrual object number as assignment number. The only problem is that the assignment number has 18 digits, but the accrual object number has 22 digits. Because of this one has to be careful when using the accrual object number as assginment number.

If the accrual object number is defined as an internal number range (i.e. not as an external number range) in the customizing (ACAC_NUMOBJ transaction), then it is ok to use the accrual object number as assignment number, since the number range for accrual object numbers (ACAC_NUMOBJ transaction) has only 10 digits: The other 12 digits are filled with zeros.

If the accrual object number is defined as an external number range, then the accrual object number can in general not be used as assignment number. An example would be the accrual object numbers that are used by the automatic data feed of invoices (ACACDATATRANS transaction). In this case, only the document number of the invoice (which is part of the accrual object number) should be used as assignment number.


Example: Assgmt. Number and Accrual Obj. Number


Example: Define the BAdI Implementation


Example: Sample Source Code in BAdI

Parallel Accounting


Parallel Accounting

The Accrual Engine supports parallel accounting in two ways

Parallel accountsThe account determination can be customized in a way that different accounts are used depending on the accounting principle.

Parallel ledgersThe account determination need not yield different accounts for different accounting principles, but in the customizing of accounting, a special ledger is assigned to one of the accounting principles. The corresponding posting in accounting will then be done only in this special ledger.


Parallel Accounting: Create Accrual Object


Parallel Accounting: Parallel Accounts


Parallel Accounting: Parallel Ledgers

Validation


Validation of Creating/Changing Accrual Objects

The validation is a tool to execute customer-defined checks.

A validation can be created and activated to execute checks, when an accrual object is created or changed.


Creating Validations


Validating Customer-Defined Parameters

Checking customer-defined parameters (see corresponding chapter) in the validation is possible:

Before customer defined parameters can be used in the validation, the corresponding fields have to be added to the DDIC structure ACEVSR_VAL_PAR

To do this, an append structure has to be created using the SE11 transaction. In the append structure the corresponding fields have to be added. After activating the append structure, the added fields are available in the validation.

If the validation does not yield the desired result, i.e. the checks fail somehow, it might be usful to swith on the trace in the validation maintainance transaction (GGB0 transaction): In the menue choose the function ‘Extras -> Activate trace’.

Afterwards, start again the transaction for creating or changing accrual objects again. The system will then stop in the validation. The F3 key makes the system continue.


Activating Validations

Customer-Defined Navigation


Navigation (Rel. 2.0)

From rel. Extensions 2.0 on, a navigation from the display transaction of accrual objects, it is possible to execute a customer-defined navigation from the accrual object to the original object (e.g. a vendor invoice or insurance contract) for which the accrual object was created.

This navigation is done with the BAdI ACE_UI_NAVIGATION.

For the application Manual Accruals, SAP deliveres the implementation ACAC_UI_NAVIGATION as example. The customer can define additional implemenations since multiple usage is allowed for this BAdI.

The example implemenation ACAC_UI_NAVIGATION for Manual Accruals executes a navigation to the vendor invoice, if the accrual object type is ‘0VENDORINV’, since in this case it is assumed that a vendor invoice is accrued and the document number of the vendor invoice is contained in the accrual object number. This way, the system can find the vendor invoice and display it.


Navigation (Rel. 2.0): Example Manual Accruals

Double

click

ArchivingAccrual Engine Data


Archiving

Archiving Accrual Engine data is done in two steps:

Archive Accrual Engine documents (archiving object FI_ACE_ITM) This archiving object contains the database table ACEPSOIT. Remark: Accrual Engine documents are needed for the reversal of periodic accrual runs; hence please archive only Accrual Engine documents which are not needed any more for reversals.

Archive Accrual Engine objects (archiving object FI_ACE_OBJ) This archiving object contains the database tables ACEOBJ, ACEDSOH, ACEDSOI, ACEDSASSGMT, ACEPSOH, ACEPSOI. Prerequisites for archiving accrual objects:

All Accrual Engine documents have been archived (archiving object FI_ACE_ITM) for this accrual object

The accrual object has the status ‘To Be Archived’.


Archiving: Archiving Objects

ACEOBJ

ACEDSOH

ACEDSOI

ACEPSOH

ACEPSOI

ACEPSOIT

ACEDSASSGMT

Field Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XACRTYPE XACCRULE XDATE_TO XDATE_FROM AMOUNTCURRENCYQUANTITYUNITACRMETHODTIMESTMP

Field Name KeyMANDT XCOMP XBUKRS XOBJID XREF_KEYSTATUS

Field Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XDATE_TO XDATE_FROMVALITY_FROMVALITY_TOUNAMECPUDTCPUTMREF_SUBKEYSTATUS

Field Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XUNAMECPUDTCPUTMDEACTDATEREF_SUBKEYSTATUSFIRSTYEARLASTYEAR

Field Name KeyMANDT XCOMP XBUKRS XGJAHR XOBJID XSUBID XACRTYPE XACCRULE XCUMVALCAPCUMVALACCRVALCAPVALACCRVALRETIRELASTEFFDATECURRENCY

Field Name KeyMANDT XCOMP XBUKRS XGJAHR XOBJID XSUBID XACRTYPE XACCRULE XDOCNR XVALCUMVALTBPCURRENCYTRANSTYPEEFFDATEPOPERRUNIDAWTYPAWKEYAWSYSTIMESTMP

Feldname KeyMANDT XCOMP XBUKRS XOBJID XSUBID XDATE_TO XDATE_FROMBUS_AREADATE_FROMPROFIT_CTRCOSTCENTER

ACEDSOPField Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XDATE_TO XPARAM_NAME XCONTENTDATE_FROM

ACEDSOI_ACCOUNTSField Name KeyMANDT XCOMP XBUKRS XOBJID XSUBID XACRTYPE XACCRULE XDATE_TO XDATE_FROM INC_START_ACCNT INC_TARGET_ACCNTPER_START_ACCNTPER_TARGET_ACCNT FIN_START_ACCNTFIN_TARGET_ACCNT

FI_ACE_OBJ FI_ACE_ITM


Archiving: Changing the Status of Accrual Objects


Archiving: Status of Accrual Objects

The status of the accrual object is displayed in the technical data:

Disp. Tech Data

Provisions for

Awards


Provisions for Awards: Overview

A company grants a number of stock options to selected employees

Purpose: Post provisions (= accruals) for the outstanding options.

To do this: Transfer information about outstanding optoins from HR system to Accounting system (Accrual Engine)

Afterwards: Calculate and post provisions using the Accrual Engine

Different calculation (=accrual) methods are possible for calculating the provisions: SAP delivers two examples as accrual methods:

APB 25 Provisions based on stock prices FAS 123 Provisions based on Black & Scholes Model


Provisions for Awards: Architecture


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R



Engine

R


values


PostDocument

R RR

Accrual Engine

Reporting Reporting

HR-System

Outstanding Awards

Read HR DataR



Provisions for Awards: Processes


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R


Process A:Transfer Data

from HR-System

R


values


PostDocument

R R


R

Accrual Engine

Reporting Reporting

HR-System

Outstanding Awards

Read HR DataR


Basis Data



Provisions for Awards: Processes


AccrualMethod



Calculation

Create/Change

Basis Data

R

Posting

R


Process A:Transfer Data

from HR-System

R


values


PostDocument

R R


R

Accrual Engine

Reporting Reporting

HR-System

Treasury

Stock Rates

Outstanding Awards

Read StockRates

Read HR DataR

R


Basis Data



Provisions for Awards: Structure of Basis Data

Grant (=Accrual Object)

Vesting (=Accrual Subobject)



Accrual Item

Assignment

Parameters

Default: Cost Center

Basis Security ID, Exchange, Basis Value, ...

Vesting Date

Award, Grant Date and Cost Center (optional)

Each combination of

- Accrual Type (APB25, FAS123,... ) and


defines an Accrual Item.

The number of outstanding awards is stored together with the accrual method at this level.

Header

Accrual Item

Accrual Item

...


Provisions for Awards: Application Menu


Provisions for Awards: Customizing in Accounting


Provisions for Awards: Customizing in HR

Provisions for

Awards:Example


Provisions for Awards: Example

Prereqisites:

On 1 Jan. 2000, company code 0001 will issue 6,000 options (award OPTN) for company stock to the employees of cost center "Executive Board". The security identification number of the company stock is "0000000000001".The base price of the options is 100 EUR, meaning that these options will have an inner value if the stock price rises above 100 EUR.

The employees cannot exercise their stock options until expiry of the waiting period.The company decides to make the 6,000 stock options that it awards available in three waiting periods.These waiting periods are as follows:

1 Jan. 2000 to 1 Jan. 2001: 3,000 options, vesting date: 1 Jan. 2001.



This means that 3,000 stock options can be exercised from 1 Jan. 2001, a further 2,000 can be exercised from 1 Jan. 2002, and the remaining 1,000 can be exercised from 1 Jan. 2003.The waiting periods are also referred to as vesting periods.The division of the 6,000 stock options into vesting periods of 3,000, 2,000 and 1,000 is referred to as a vesting rule. If the stock price has a value of more than 100 EUR when the stock options are exercised, the company will have to meet the corresponding costs. For this reason, provisions must be posted in good time in Accounting.


Provisions for Awards: Example

Data Transfer HR -> Accounting (Accrual Engine)

Provisions can be calculated and/or posted according to different rules.

For each desired rule, a separate accrual item has to be created.Customizing has to be adjusted accordingly for the data transfer program.

SAP delivers two accrual methods: ACC_APB25 and ACC_FAS123 for calculating provisions according to APB 25 and FASB 123 respectively.


Provisions for Awards: Customizing Data Transfer


Provisions for Awards: Customizing the Data Transfer


Provisions for Awards: Data Transfer


Provisions for Awards: APB 25 and FAS 123

To post the provisions, the company can choose between the two methods APB 25 and FASB 123 .

Method APB 25 uses the current stock price to calculate the inner value of the outstanding options.

With APB25, the provision amount fluctuates in the same way as the stock price. If the company chooses the APB 25 method, it must add an additional calculation of the provisions according to FASB 123 in the appendix of the balance sheet.

Method FASB 123 calculates the provisions based on an average stock price assumed by the historical volatility of the underlying stock.

This means that the provisions do not fluctuate as they would using method APB 25.


Provisions for Awards: APB 25

Accrual Method ACC_APB25 works as follows: The value of the provisions is to be determined for 31 Jan. 2000. On this date, the stock price is 110 EUR. As the base price taken over from HR is 100 EUR, the option has an inner value of 10 EUR.For the first waiting period from 1 Jan. 2000 to 1 Jan. 2001 (vesting date), 1/12 - or 8.3 % has expired by 31 Jan. 2000. Accordingly, only this fraction has to be depicted as a provision.The vested share for the second and third waiting periods is worked out in the same way: 1/24 (= 4.17 %) and 1/36 (= 2.78 %).The system calculates the weighted vested share thus: (1/12 x 3,000 + 1/24 x 2,000 + 1/36 x 1,000) / (3,000 + 2,000 + 1,000) = (250 + 83.33 + 27.78) / 6,000 = 0.0602 = 6.02 %This provides the following provision amounts for the three waiting periods:

First waiting period: 3,000 options x 10 EUR x 6.02 % = 1806 EUR

Second waiting period: 2,000 options x 10 EUR x 6.02 % = 1204 EUR

Third waiting period: 1,000 options x 10 EUR x 6.02 % = 602 EUR

Total: 1,806 EUR + 1,204 EUR + 602 EUR = 3,612 EUR


Provisions for Awards: APB 25 (II) Enter Stock Prices


Provisions for Awards: FASB 123

Accrual method ACC_FAS123 works as follows: In contrast to method APB 25, the value of an option is not calculated using the price of the underlying stock. Instead, the value of an option is defined manually in IMG activity "Define Data for the Black & Scholes Model".Here, values can be defined by waiting period.Example:

First waiting period: 9 EUR

Second waiting period: 10 EUR

Third waiting period: 11 EUR The vested share is not used as a weighting of the three individual waiting periods. Instead, the last vesting date determines the vested share. In the example: 1/36 = 2.78 %. This results in the following provision amounts:

First waiting period: 3000 x 9 EUR x 2.78 % = 750.60 EUR

Second waiting period: 2000 x 10 EUR x 2.78 % = 556.00 EUR

Third waiting period: 1000 x 11 EUR x 2.78 % = 305.08 EUR Total: 1612.40 EUR


Provisions for Awards: FASB 123 (II) Enter Black & Scholes Values


Provisions for Awards: Display Transferred Data (I)


Provisions for Awards: Display Transferred Data (II)


Provisions for Awards: Display Transferred Data (III)


Provisions for Awards: Periodic Posting Run