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

Period 1

Period 2

Period 3

Period 4

Period 5

Period 6

Period 7

Period 8

Period 9

Period 1

0

Period 1

1

Period 1

2

Given: Value + time interval

Task: Distribute value over time interval

Simple Example:


Simple Posting Example

D C P&L D C Accrual

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:


Overview:

Accrual

Engine

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 for

Awards

Accrual Engine: A Generic Tool

Input Output:

Periodic postings


Accrual Engine: Some Features

New component in MySAP Financials

Highly flexible tool

Storage of all relevant data

Input (contract-like information incl. history!)

Output (posted accruals)

Accrual Engine = ‘Accrual subledger’

Mass data processing, performance optimized


Accrual Engine: Benefits

Automated periodic calculation of accruals

No 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)

Accrual

MethodTrigger Calculation of

Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create

Accounting Documents

Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values

(Accrual Engine Documents)

Post

Document

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Processes


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R

Calling Application

R

Accrual Engine

Reporting Reporting

Process A:

Create/

Change

Basis Data

Process B:

Calculate

and Post

Accruals


Accrual Engine: Accrual Methods


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Delta Logic


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Account Determination


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Structure of Basis Data


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

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


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R

Calling Application

R

Accrual Engine

Reporting Reporting


Accrual Engine: Reporting of Posted Values


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

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


Database Tables in the Accrual Engine

ACEOBJ

ACEDSOH

ACEDSOI

ACEPSOH

ACEPSOI

ACEPSOIT

ACEDSASSGMT

Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

DATE_TO X

DATE_FROM

AMOUNT

CURRENCY

QUANTITY

UNIT

ACRMETHOD

TIMESTMP

Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

REF_KEY

STATUSField Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

DATE_TO X

DATE_FROM

VALITY_FROM

VALITY_TO

UNAME

CPUDT

CPUTM

REF_SUBKEY

STATUS

Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

UNAME

CPUDT

CPUTM

DEACTDATE

REF_SUBKEY

STATUS

FIRSTYEAR

LASTYEAR

Field Name Key

MANDT X

COMP X

BUKRS X

GJAHR X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

CUMVALCAP

CUMVALACCR

VALCAP

VALACCR

VALRETIRE

LASTEFFDATE

CURRENCY

Field Name Key

MANDT X

COMP X

BUKRS X

GJAHR X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

DOCNR X

VALCUM

VALTBP

CURRENCY

TRANSTYPE

EFFDATE

POPER

RUNID

AWTYP

AWKEY

AWSYS

TIMESTMP

COMP X

BUKRS X

OBJID X

SUBID X

DATE_TO X

DATE_FROM

BUS_AREA

DATE_FROM

PROFIT_CTR

COSTCENTER

ORDERID

WBS_ELEMENT

ACEDSOP Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

DATE_TO X

PARAM_NAME X

CONTENT

DATE_FROM

ACEDSOI_ACCOUNTS Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

DATE_TO X

DATE_FROM

INC_START_ACCNT

INC_TARGET_ACCNT

PER_START_ACCNT

PER_TARGET_ACCNT

FIN_START_ACCNT

FIN_TARGET_ACCNT

Customizing the

Accrual Engine


Customizing: IMG for the Accrual Engine


Customizing: Dependent on the Component


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 type

The 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 method

The 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:

ALL This 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 Periodic No opening posting is done. Only during the periodic accrual run, periodic postings with process = ‚P„ are done.

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

None No 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 accrual types which are determined by a complicate algorithm.


Customizing: Example for ‘All Postings’

D C Accrued Revenues

18 000 (I)

D C Clearing Account

(I) 18 000

D C Revenues

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 C Provisions

300 (P.1)

300 (P.2) …

300 (P.x)

D C Expected Expenditure

(P.1) 300

(P.2) 300

…

(P.x) 300


Customizing: Link from Messages to IMG

Customizing:

Customer-Defined

Accrual Methods



SAP delivers a number of accrual methods:

Linear, periodically

Linear, daily with 365 days

Linear, 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:

VALACT

This 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_KEY

This 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_PARAMS

This 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_TO

Life time of the accrual subobject, i.e.

the interval in time, in which the accruals

have to be done.

FY_VARIANT

Fiscal year variant. Needed only,

if the periods need to be determined

from the dates.



3. Import table IT_PARAMS This 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_NAME

Name of the parameter.

CONTENT

The value of this parameter



4. Import table IT_COMP_SIMUPARAM_RANGES This 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:

FIELDNAME

Name of the additional input field.

FIELDRANGE

Table with the entered select-options.

Note: The additional fields have to be

added to the selection screen using

select-option-statements.

This possibility is not available in

standard.

Contact the SAP development for

further information, if needed.



4. Export table ET_RETURN

If 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:

TYPE

Type of the message („E‟ for Error, „W‟ for warning etc.)

ID

Message class of the message.

NUMBER

Number of the message in the message

class.

MESSAGE_V1, …, MESSAGE_V4

Parameters 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 8850 01.02.2000 29.02.2000 150 150 8700 01.03.2000 31.03.2000 150 300 8550 01.04.2000 30.04.2000 150 450 8400 01.05.2000 31.05.2000 150 600 8250 …


01.01.2000 31.01.2000 0 0 0 01.02.2000 29.02.2000 0 0 0 01.03.2000 31.03.2000 0 0 0 01.04.2000 30.04.2000 0 0 0 01.05.2000 31.05.2000 0 0 0 …

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 8850 01.02.2000 29.02.2000 150 100 8750 01.03.2000 31.03.2000 150 300 8550 01.04.2000 30.04.2000 150 450 8400 01.05.2000 31.05.2000 150 600 8250 …


01.01.2000 31.01.2000 0 0 0 01.02.2000 29.02.2000 0 0 0 01.03.2000 31.03.2000 0 0 0 01.04.2000 30.04.2000 0 0 0 01.05.2000 31.05.2000 0 0 0 …

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 8850 01.02.2000 29.02.2000 150 100 8750 01.03.2000 31.03.2000 150 300 8550 01.04.2000 30.04.2000 150 450 8400 01.05.2000 31.05.2000 150 600 8250 …

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 0 01.02.2000 29.02.2000 100 150 8750 -50 01.03.2000 31.03.2000 200 250 8550 50 01.04.2000 30.04.2000 150 450 8400 0 01.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 and b) 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.


The 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



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

periodic accrual run.

The periodic accrual run is

started 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 on

02/29/2000, but on 03/31/2000, then the

than 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


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



Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R

Calling Application

R

Accrual Engine

Reporting Reporting

Manual Accruals

Create

Accrual 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 selections

These parameters are specific for the vendor invoices: They are used for

selecting the vendor invoices.

Accrual Parameters

These Parameters are used for creating the accrual objects.

Example: If you enter the accrual method ‘LINEAR’, the accruals are

calcuated linearly periodically).

Posting parameters

Needed 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 parameters

Most 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 source

and transform the selected data

into 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_EX

AMPLE 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


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


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

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




18,000 (I.1)

D C Accrued Costs

(I.2) 6,000

D C Receivables

(I.1) 18,000

D C Payables

6,000 (I.2)


Manual Accruals: Start Periodic Accrual Run


Manual Accruals: Result of Periodic Accrual Run


Manual Accruals: Display Accrual Object after



Manual Accruals: Documents in FI


18,000 (I.1)

(P.1) 300

D C Receivables

(I.1) 18,000

D C Revenues

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 C Accrued Costs

(I.1) 6 000

D C Costs

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 C Accrued Costs

D C Payables

(I.1-3) 9,000

9,000 (I.1-3)

D C Costs

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 current

year is open, while the

previous year might also still

be open for closing entries

Creating an accrual object:

A total record is created

for 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 to

postings in Accounting

The carryforward also increases

the ‘current year’ in Accrual Engine

Customizing.

In the example: The carryforward

program does not have to be started at

the 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 advisable

to execute the carry forward at the end

of 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


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 date

31 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 created

US 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 Determination

The 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.


Entering Parameters

Choose

‘Enter Parameters’


Entering Parameters


Evaluating Parameter Values in Periodic Accrual Runs


Parameters in Account Determination


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_PARAMETERS

Assignment 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 postings If 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

Accounting Call 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 PrCtr CO SL CONS

Accounting Interface

CO-PA

DDIC structures:

ACCHD

ACCIT

ACCCR

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 PrCtr CO SL CONS


CO-PA

DDIC structures:

ACCHD

ACCIT

ACCCR

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 periodic

postings (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 same

assignment number.

Problem: The Accrual Engine does not add the assignment number to

the Accounting documents.

D C Accrual 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 assignment

number 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 the

customer 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 accounts

The account determination can be customized in a way that different

accounts are used depending on the accounting principle.

Parallel ledgers

The 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

Archiving

Accrual 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 Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

DATE_TO X

DATE_FROM

AMOUNT

CURRENCY

QUANTITY

UNIT

ACRMETHOD

TIMESTMP

Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

REF_KEY

STATUS

Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

DATE_TO X

DATE_FROM

VALITY_FROM

VALITY_TO

UNAME

CPUDT

CPUTM

REF_SUBKEY

STATUS

Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

UNAME

CPUDT

CPUTM

DEACTDATE

REF_SUBKEY

STATUS

FIRSTYEAR

LASTYEAR

Field Name Key

MANDT X

COMP X

BUKRS X

GJAHR X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

CUMVALCAP

CUMVALACCR

VALCAP

VALACCR

VALRETIRE

LASTEFFDATE

CURRENCY

Field Name Key

MANDT X

COMP X

BUKRS X

GJAHR X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

DOCNR X

VALCUM

VALTBP

CURRENCY

TRANSTYPE

EFFDATE

POPER

RUNID

AWTYP

AWKEY

AWSYS

TIMESTMP

Feldname Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

DATE_TO X

DATE_FROM

BUS_AREA

DATE_FROM

PROFIT_CTR

COSTCENTER

ACEDSOP Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

DATE_TO X

PARAM_NAME X

CONTENT

DATE_FROM

ACEDSOI_ACCOUNTS Field Name Key

MANDT X

COMP X

BUKRS X

OBJID X

SUBID X

ACRTYPE X

ACCRULE X

DATE_TO X

DATE_FROM

INC_START_ACCNT

INC_TARGET_ACCNT

PER_START_ACCNT

PER_TARGET_ACCNT

FIN_START_ACCNT

FIN_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:

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


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Transfer Data

to Accrual

Engine

R

Build Delta to

already posted

values

Posted Values


Post

Document

R RR

Accrual Engine

Reporting Reporting

HR-System

Outstanding Awards

Read HR DataR



Provisions for Awards: Processes


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Process A:

Transfer Data

from HR-

System

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R


R

Accrual Engine

Reporting Reporting

HR-System

Outstanding Awards

Read HR DataR

Process A:

Create/

Change

Basis Data

Process B:

Calculate

and Post

Accruals


Provisions for Awards: Processes


Accrual


Accruals

Periodic:

Calculate Accruals

Calculation

Create/

Change

Basis Data

R

Posting

R

Create


Process A:

Transfer Data

from HR-

System

R

Build Delta to

already posted

values

Posted Values


Post

Document

R R


R

Accrual Engine

Reporting Reporting

HR-System

Treasury

Stock Rates

Outstanding Awards

Read Stock

Rates

Read HR DataR

R

Process A:

Create/

Change

Basis Data

Process B:

Calculate

and Post

Accruals


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

Accrual Engine by Sap

Documents

Transcript of Accrual Engine by Sap