TFIN50I PART 1

UNIT 1: BASIC SETTINGS

Lesson 1: Organizational Units
⇒ Client: Highest level: independent unit: separate MRs and set of tables/data.
⇒ Important Organization Units in FI: 1. Company Code (CC): Independent
balancing/legal @ing entity (Minimum structure of FI). 2. Business Area (BA):
Separate areas of operation (can create own set of Financial Statements (FS) and
can be used across CCs.
⇒ Creating a CC: Copying an existing CC copies: 1. Definition, 2. Global
Parameters, 3. Customizing Tables, 4. GL @s, and 5. @ Determination.
⇒ Editing CC data (defining a CC): 1. Four-character CC key (identifies CC), 2.
Name, 3. City, 4. Country, 5. Currency, 6. Local Currency, 7. Address.
⇒ Define BA: 1. Four-digit alphanumeric key, 2. Description. To create FSs for BAs,
the field for BA in line item must be ready for input. In activity “Enable BA FSs”, set indicator for the
BA field for each CC. Once done, the BA field is always ready for input when you post docs regardless of
field controls for the PK and @s.
Country Templates (CC 001): A template for a general CC with CA INT and no
country specifications. What does country template contain? 1. Cross-Application: Calendar
settings, factory calendar, public holidays, etc. 2. FI: Tax on sales and purchases calculation procedures,
withholding tax, @ determination, charts of @s, FS versions, Customizing settings for the PYMT
program, PYMT methods and sample house banks, formats for the electronic @ statement, valuation
approaches, etc. 3. CO: Cost elements, standard hierarchies for cost centers, profit centers, etc. 4. Other
country-specific templates for other areas.
Lesson 2: Variant (V) Principle.
Three step method used to assign particular properties to one or more objects.
Steps: 1. Define V, 2. Determine Values for V, 3. Assign V to objects. V is used for:
a. Fields Status, b. PP, c. FY. The advantage of the V principle is the low level of maintenance
required in the sys.
Lesson 3: Fiscal Year (FY).
FY defined as a period of 12 months for which a company regularly creates an inventory and FSs. 1.
Year-Independent: number and start dates for the period are the same for every
year: a. calendar year, b. Non calendar year. 2. Year-Specific: Periods can vary
from year to year. Conditions: 1. Start and end dates of the posting periods for
same FY are different to the dates to other FYs. 2. If all the FYs of FY variant have
the same number of posting periods, only the dates have to be defined. 3. If one
FY variant has less posting periods than others, is a shortened FY (closing in
advance). Special Periods: Used for postings not assigned to time periods but to
the business process of year-end closing. Max. 16 periods. How do I post in a special
period? 4 conditions: 1. Posting date must be in last PP (irrespective of whether this last PP is open). 2.
Special periods must be open for posting. 3. Special period must be entered manually when posting. 5.
Authorization to post in special periods must be given (optional).
Lesson 4: Currencies.
⇒ Currencies and exchange rate (T∆) types: Currency key: assigned to every
currency used. T∆ type: diff. T∆ for every combination of two currencies.
Translation ratios: to maintain the relationship between two currencies per T∆
and currency.
⇒ Maintaining T∆: Tools: 1. Inversion 2. Base currency: choose one currency
and maintain the rest currencies only to that one 3. T∆ spreads: between the bank
buying/selling rate and average rate usually remains constant.
⇒ Direct Quotation of T∆: 1 unit of foreign currency is quoted for the local
currency. Indirect quotation: one unit of local currency is quoted for the foreign
currency.
⇒ Work lists for maintaining T∆: 1. Only the relevant T∆ can be maintain and
assign authorizations. 2. Only the relevant quotation can be maintain. 3. The

1
worklist is smaller and therefore clearer. 4. Parallel processing of diff worklists is
possible.
⇒ Design of T∆ in diff. quotations: 3 scenarios: 1. Mostly work with direct
quotations (“blank” for direct and “/” for indirect). 2. Increasingly use of
indirect quotation (“*” for direct and “/” for indirect). 3. Mostly use of indirect
quotation (“*” for direct and “blank” for indirect).
UNIT 2: MASTER DATA
Lesson 1: GL Accounts
⇒ Chart of Accounts (CA): Variant with structure and basic info about GL @s.
Steps: 1. Define the CA (assign a 4-character ID). 2. Define properties (language,
length of the @ number, CA group, status). 3. Assign the CA to CC.
⇒ Define CA: 1. CA key, 2. Description. General info: Language and length (1-
10 digits). Controlling integration: Manual or automatic creation of cost
elements. Consolidation: Group of CA (used for cross-company reporting if
companies use diff CA. Status: “blocked” indicator if CA is not yet completed.
⇒ Assigning the CA to every CC: Using V principle, one CA can assign to several
CCs. Controlling uses the same CA than FI. If CCs intend to use cross-company code
controlling they must have the same CA.
⇒ CA segment: contains basic info about @s: 1.@ Number. 2. Name. 3.
Control fields. 4. Consolidation fields.
⇒ Fields in the CA segment: applies to all CCs. Groups of fields (tab pages):
A. Type/Description: 1. Control in CA. 2. Description. 3. Consolidation data in CA.
B. Keyword/Translation: 1. keyword in CA 2. Translation. C. Information: 1. Info
in CA. 2. GL texts in CA. Tab pages can be defined on: # of tab pages, title, field
groups and their position on the tab pages and select layout for central processing.
⇒ CC segment: Must be created for the @ to use this @ from the CCs CA. CC
segment + CA segment form the @.
⇒ Fields in the CC segment: 1. Currency. 2. Taxes. 3. Reconciliation @. 4. Line
item display. 5. Sort Key. 6. FST group. 7. House Bank/ interest calculation info.
Groups of fields: A. Control/Data: 1. @ control. 2. @ Management. 3. Joint
venture. B. Bank/interests: 1. Doc creation. 2. Bank/fin. Details. 3. Int. calculation.
C. Information: 1. info. 2. GL @ texts.
⇒ One CA, Several CCs: A CA segment can be assigned to several CC segments. Ex: 2 CCs use
the same CA. Therefore, both CCs use same CA segment of a G/L @, but each have a different CC
segment. The entries in the CC segment are CC-specific and can be diff. for diff. CCs (for example,
different currencies).
⇒ Balance sheet (BS) and P&L statement @s: CA segments ask if @ is BS
(balance is carried forward to same @) or P&L statement @ (balance is carried
forward to a retained earnings @ and the P&L @ is set to 0.
⇒ Retained Earnings @: is part of the FSs. Use field “P&L Statement @ Type” to define retained
earnings @ to which balance is carried forward. Define the key in Customizing. If user has only defined
one retained earnings @ in Customizing, the “P&L Statement @ Type” field is hidden in the G/L @ MR.
User can use different retained earnings @ to reflect different FS standards within the sys.
⇒ @ groups for GL @s: Assign range # to an @ group to ensure similar @s are
grouped together. In CA segment, enter @ group to control appearance of CC
segment of a GL @.
⇒ FST: Enables to control the display and maintenance of an @’s master data.
What is the purpose of the FST?: 1. Superfluous field groups or fields are hidden. 2. Input errors are
avoided. Priority: 1. HIDE (not used fields). 2. DISPLAY (values that must not be
changed). 3. REQUIRED (required value enter). 4. OPTIONAL (can contain entry
but are not required). Fields “@ currency” and “FST group” are always required. Two
options for controlling the FST: @ group-specific and Transaction-specific.

2
⇒ FST for master data: Not only @ group controls the field, also the transaction
used to edit master data. “Change master data” transaction is used when after
creating a MR, its data is not intended to be changed. By choosing OPTIONAL, @
group specific control is used when not wanting to use transaction-specific control.
⇒ Reconciliation Accounts: GL @s assigned to the business partner MRs to
record all transactions in the Sub-ledger (SL). All postings to SL @s are
automatically posted to the assigned reconciliation @s. You cannot post directly to
those @s. The reconciliation @ connects a SL to the GL realtime. The following SLs are connected to
the GL via reconciliation @s: 1. @s Receivable. 2. @s Payable. 3. Assets. 4. Contract @s Receivable
and Payable. A report carries out reconciliation between GL and SLs through consistency checks as part
of the monthly GL closing: 1. Debit and credit transaction figures of the C/V, and G/L @s with the debit
and credit totals of the posted docs. 2. Debit and credit transaction figures of C/V, and G/L @s with the
debit and credit totals of the application indexes (secondary index).
⇒ Line Item display: Transaction figures are total of line item postings on the
debit or credit side. Balance=D-C. Line Item display field is control field in the CC
segment of an @. @s without “line item display”: Transaction figures updated
when docs are posted (user can only view balance). @s with “line item display”:
Data stored in special index table and user can see balance and line items. NOT
USE “LID” FOR: 1. Recon. @s (line items are managed in SLs). 2. Revenue @s
(managed by sales application). 3. Material stocks @s (managed by purchasing
application). 4. Tax @s. Line items are items posted to a specific @. In contrast to a doc item, a line
item only contains information relevant from the @ view. User can display the following line items in a
G/L @: 1. Open items. 2. Cleared items. 3. Noted items. 4. Parked items. User defines whether an @ is
managed with line items in the MR of the G/L @. User can activate line item display for an @ later (@
has already been posted to). Prerequisites: 1.Line item display is active in the G/L @. 2. @ is blocked for
posting during the changeover.
⇒ Open Item Management: “line item display” should be activated for the @.
Open Item Management is necessary to see if there’s any offset posting for a BT.
USE OIM FOR: 1. Bank clearing @s. 2. Clearing @s for goods receipt/invoice
receipt. 3. Salary clearing @s. Cleared Items: already closed with an offsetting
doc. OIM can only be activated or deactivated if @ has 0 balance. If indicator
“OIMt” is set in MR for a G/L @, items belonging to this @ are either open items or cleared items. The
balance of an @ with OIM is always the balance of the open items. G/L @s are always managed with
OIM if user wants to see if an offsetting posting exists for a BT
⇒ Accounts in local currency: If @ currency is local, that @ can be posted in
any currency.
⇒ Only Balances in local currency: (Checkbox), if activated in MR, transaction
figures are only managed for amount converted to local currency. USE IT FOR:
clearing accounts that use same local currency amount without necessitating T∆
difference postings.
⇒ @s in foreign currency: only posted in chosen currency and not in local
currency.
⇒ Creating a GL @: A. Manually: 1. Centrally 2. Two steps: CA segment and
CC segment. B. Copying: 1. An individual GL @. 2. Entire CA segment. 3. Entire CC
segment. C. Data transfer: transfer a new CA from an external system.
⇒ Collective Processing: change simultaneously: 1. CA data. 2. CC data 3.
Description.
⇒ Group CA: Possible to have internal reporting (FS) that contains items from
several CCs that share the same CA. When that’s not possible because of legal
constrains, use Group CA assigned to each operational CA. Disadvantage: not cross
CC controlling because of diff. CAs.
⇒ Country CA: alternative to Group CA to fulfill the country-specific requirements for
external reporting and simultaneously carry out uniform internal reporting. All CCs use the same
operational CA but if a CC requires a special CA, use the country CA. Enter it in

3
every CC segment. Cross CC controlling because of the same CAs is possible. The link
between an @ in country CA and in operational CA is always a 1:1 relationship.
Lesson 2: Customer/Vendor (C/V) Accounts
⇒ Accounting View of the C/V @: C/V @s have 2 segments: 1. At client
level with general data and 2. At CC level with CC specific data. Any CC that
is to do business with a C/V has to create a CC segment for the C/V (creating a
C/V@).
⇒ Sales Area and Purchasing Organization Segments can be crated for
each C/V.
⇒ The complete Customer @: 3 segments: 1. Gral Data at client
level. 2. CC segment. 3. Sales area segment. @ Number is assigned to
the customer at client level so it applies for all CCs and sales areas.
⇒ The complete Vendor @: 3 segments: 1. Gral Data at client level.
2. CC segment. 3. Purchasing organization segment. @ Number is
assigned to the customer at client level so it applies for all CCs and sales
areas.
⇒ Centralized Maintenance: to FI, MM and SD. Decentralized Maint.:
from FI, MM and SD separately. Compare Master Data is possible to avoid
duplicated or incomplete MRs. Two ways: 1. Use match code before creating a
new @. 2. activate automatic duplication check.
⇒ Pages of the C/V @: Groups of fields in every @ segment. 1. Gral
data: address, control data, payment tranasactions + texts. 2. Company
data: accounting info, payment transactions, correspondence, insurance,
withholding tax + texts. IMPORTANT FIELDS: 1. SEARCH TERMS
(abbreviation of C/V name to find quickly) 2. CORPORATE GROUP (C/Vs
grouped together by group key if belong to a corp. group. 3. ACCOUNTING
CLERK (ID of responsible). You can create a new C/V with reference to
an existing another.
⇒ Avoiding Master Data Duplication: Two ways when creating a new customer: 1.
Before creating a new MR, use matchcode to check whether C/V already exists. 2. The message
control should create a message when creating a C/V again.
⇒ @ Groups for C/Vs: useful to control: 1. Number ranges for @s so that all
@s in an @ group are in one @ number interval. 2. FST in the MRs so that all @s in an @
group have same screen layout. 3. If @ is a one-time C/V. In contrast to GL @s, where user
enters @ group in CA segment of MR, for C/V @s enter @ group before maintaining individual
MR segments. Reason: For C/V @s, the @ group controls the internal or external # assignment.
For G/L @s, the # assignment is always external. In addition to CC segment, sales segment, and
purchasing segment, the @ group also controls screen layout at client level.
⇒ # ranges for C/V: separate for C/V and divided into smaller # ranges
(int. and ext).
⇒ FST of the MRs: @ Group is used to control the fields in the MR.
Factors that affect the C/V data screen: 1. @ group-specific control: One
group controls the FST of all its @s. 2. Transaction-specific control: FST
can be dependant on the master data transaction (create, change, display). 3.
CC-specific control: in CC segment of the C/V MRs via the CC-specific screen
layout. Applies FST priority.
⇒ Dual Control Principle: one user makes changes to a C/V and another
confirms them. “Dual control” is defined in the MR and can apply for a
single CV or a list restricted by – C/V – CC - @s not yet confirmed - @ rejected -
@accounts to be confirmed by me.
⇒ C/V clearing: if a person is both vendor and customer, payment and
dunning programs clear open items against each other. Steps: 1. Enter V @
number in the Customer @ and vice versa. 2. Select field “clearing with V/C” in
the C/V @ correspondent.

4
 ⇒ Alternative payer/payee: Can be entered at client and CC levels.
“individual entries indicator” makes this possible. Payer/payee may be a C/V
already created in the sys (entering C/V @ number as permitted payer/payee
in the MRs) or been entered when creating the invoice. Definition options for
alternative payer/alternative payee:

Priority Type Basic Setting at...

1 At doc level: 1.Individually (no MR exists), 2. Selection list (MRs exist) Client level
2 At CC level CC level
3 At client level Client level

⇒ Head Office/Branch: Items posted to a branch @ are automatically

posted to the head office @.
Lesson 3: Bank Accounts
⇒ Bank Master Data: for house banks or C/V banks. Every bank is ID by
the bank country and bank key. Bank MRs contain data as SWIFT code, bank
group and postal giro data. House Bank: Bank Master Data, electronic
payment info, Bank @s, GL @s per Bank @s. 4 ways of creating Bank
Master Data: 1. Entering bank info in C/V MRs or in customizing for House
Banks. 2. “Create Bank” transaction in the @R and @P MD menu. 3.
Imported. 4. Lockbox function. Bank Type: To distinguish between diff.
banks. Partner Bank field: when processing invoices and the C/V has
more than one Bank.
⇒ Bank Accounts: each bank @is reflected in sys as combination of
House bank ID + @ ID that is entered in a GL @ that represents the Bank
@ in the GL. Bank @s can be ID by and @ ID unique per House Bank. Bank
@ data contains: 1. @ number at the bank. 2. @ currency. 3. GL @. One
Bank @= one GL @= ID @= same currency.
UNIT 3: DOCUMENT CONTROL
Lesson 1: Document Structure
⇒ Doc principle: a doc is saved for every BT posting and remains as complete
unit in sys until archived. Every doc is uniquely ID by: 1. Doc number. 2. CC. 3.
FY. Parts of Doc: 1. Header (info applies to entire doc). 2. Doc items (info applies to
line item). 3. Detailed Data for 1 and 2. Control Keys: 1. Doc type for doc header.
2. PK for line item. Doc # can be assigned int. or ext. A BT can create 1 or more
docs linked to each other to have overview of every BT.
⇒ Doc types: ctrls doc header and is used to differentiate BTs to be posted.
Doc types are defined at client level so valid for all CCs. Doc types define:
1. ranges for doc #s. 2. @ type permitted for posting. 3. FST of doc header fields
“doc header text” and “ref. #”. 4. Whether invoices are posted with the net
procedure. If doc has ext. #: 1. Use ext. # in field “reference #” in header. 2. Note
the # of the sys # in the original doc. Options for int. doc # assignment: 1. Up to a
future FY. 2. For each FY. One # range can be assigned to several doc types.
Intervals of doc # ranges can be copied from one FY/CC to another.
⇒ Functions of the PKs: within the line items: 1. Types of @ line item can be
posted to (D, K, S, A, M). 2. If item is posted as Debit or Credit. 3. FST of additional
details (layout of entry screens). PKs are defined at client level. PKs also
specifies: 1. if line item is connected to a payment transaction. 2. If the PK is sales
relevant and if the sales figure if the @ is to be updated by transaction. PKs are
posted D or C. PKs default values: 1. GL @ posting: D=40 C=50. 2. Customer
Invoices: D=01 C=50. 3. Vendor invoices: D=40 C=31.
⇒ Doc FST: defines whether fields are to be hidden, required or optional fields. However, this does
not apply for fields: 1. .Amount. 2. PK. 3. @ which are required entry fields, you cannot influence their
FST. FST for posting an accounting doc is determined by three factors: 1. @ type (for example, G/L @,
SL @). 2. FST of the PK. 3. FST of the @. Sys determines the FST dependent on the @ type. It cannot
be influenced by Customizing. The PK-specific and @-specific FST both control the field layout of the
additional @ assignments in the line item.

5
⇒ FST Groups: for each group of GL @s define the status of every doc entry
fields. Info is divided into FST groups for each group of GL @s and summarized in
one FST variant assigned to the CC. This is so that the FST groups can be used in the @s of
these CCs. Different CCs can use one FST V.
⇒ Standard PKs: Since SL @s don’t have FST group, differentiation via PKs. In
GL postings, differentiation is via FST groups (only 2 PKs are needed for GL
postings: 40 and 50).
Lesson 2: Posting Periods (PP)
⇒ PPs: defined in the FY variant. PP can be closed to prevent docs from being
posted to the incorrect period. OPEN a PP by entering a range in the PP variant.
Special periods can be opened furing period closing for closing postings. During
closing, two period intervals must be open at the same time. PP Variant: can be
used by several CCs.
⇒ Period checks by @ type: PP variant must contain at least @ type “+”. PPs
can be handled differently for diff. @ types (K, D, S, M). At line item level, sys
checks if PP assigned is open to permit postings. Determination of PP during
posting: When entering a doc posting date, sys determines PP and FY based on that
date. PP is entered in doc overview and transaction figures for this posting are
updated.
Lesson 3: Posting Authorizations
⇒ Maximum amounts: defined per CC in “tolerance groups”. This is also where
the processing of PDs is controlled. Upper limits for posting transactions in: 1. Total
amount x doc. 2. Amount x C/V item. 3. Cash discount granted.
Lesson 4: Simple Documents in Financial Accounting
⇒ Simple Posting in FI: FI uses one posting transaction for several different
postings: GL @s, Customer invoice posting, Customer credit memo posting, Vendor
invoice posting, Vendor credit memo posting.
⇒ ENJOY Posting Screen: in the GL, C/V area are single screen transactions. Header and
first line item: Enter Gral data for posting doc: invoice, posting date, text, etc.
Define a doc type for each transaction. Additional Line items: Once made and
confirm entries, @ name appears. Once balance is 0, select PARK, POST or HOLD to
complete doc entry transaction.
UNIT 4: POSTING CONTROL
Lesson 1: Default Values
⇒ Default values for user settings: Configure screens for areas: 1. Doc entry. 2.
Doc display (using “list view”). 3. Open Items (layout display and posting options).
⇒ Sys. and Accounting defaults: Sys provides defaults for doc entry. Doc
Principle: Balance of doc must be 0 before posted. Doc types, PKs, FYs all can
be proposed by sys.

Lesson 2: Change Control

⇒ Changing Docs: that have been posted is possible only in certain fields.
(based on rules). 1. Doc Header: a. Ref #. b. Text fields. 2. Line Item: Not
changes in a. amount. b. PK. c. @ d. any field that would affect the reconciliation
of a posting.
Doc change rules: based on: 1. @ type: AR, AP or GL @ (M,K,D,S,A). 2. Transaction
Class: for SGLTs (bills of exchange and down payment). 3. CC: if field is blank, rules
apply to every CC. Change conditions for changing a field (line item) if: 1. PP
is still open (also applies for doc header). 2. Line item is not yet cleared. 3. Line item
is either a debit in a customer @ or a credit in vendor @. 4. Doc is not credit memo
for an invoice. 5. doc is not credit memo from a down payment.

Lesson 3: Document Reversal

6
 ⇒ Reverse Docs: 2 ways of reversing: 1. Normal (standard) reversal
posting: causes sys to post the incorrect debit as credit and the incorrect credit
as debit. The normal reversal posting causes an additional increase in the
transaction figures. 2. Negative posting: also posts the incorrect debit as credit
and the incorrect credit as debit. This time the posted amount is not added to the
transaction figures of the other side of the @, setting transaction figures back to
as they were before the incorrect posting took place. Prerequisites to enable
negative postings: 1. CC permits negative postings. 2. Reversal reason must be
defined (explains the reversal and allows to use or not the same posting date).
Negative postings are also to perform transfer postings of incorrect line
items. During the reversal, a reversal doc is created. The reversal doc and the reversed doc are then
cleared items. In the doc header of the reversed doc you can see the number of the reversal doc and
the reversal reason. The doc header of the reversal doc contains the number of the reversed doc but
not the reversal reason. Mass reversal: With recurring entries or with the PYMT program, a large
number of docs are created automatically. Using the mass reversal function, these can be reversed
simultaneously.

Lesson 4: Payment Terms and Cash Discounts

⇒ Terms of Payment (TofP): conditions agreed between business partners for
the payment of invoices. TofP are used to define: 1. Baseline date for due date
calculation. 2. Cash discount periods/terms. 3. Cash discount % rate. TofP are
assigned to C/V MRs, defaulted in sys or entered by user, and used in
transaction line item to determine payment conditions.
⇒ TofP in Invoices: TofP can be entered in the C/V MR: 1.CC segment (defaulted
if invoice created in FI). 2. Sales area segment (defaulted if invoice created in SD).
3. Purchasing organization segment (defaulted if invoice created in PM). When
entering an invoice it’s possible to enter a fixed cash amount or a
discount % rate. (entry in cash discount field).
⇒ TofP in credit memos: Linked from original invoice by entering invoice # in
“invoice ref.” field in doc entry. TofP are copied from invoice, so invoice and credit
memo have same due date. In Non-Invoice related credit memos TofP are invalid.
⇒ TofP basic data: 1. Day limit: Calendar day to which the TofP are valid.
Store a single or multi-part TofP in a TofP Key. 2. Description (1. Sales order
management text for printing on invoices, 2. An explanation if necessary, 3. An explanation generated
by the sys) 3. @ Type: Subledger in which TofP can be used.
⇒ TofP controls: 1. Block Keys (line item, @, or payment terms) to block
payment or collection (enter block key and the PYMT method: 1. During posting. 2. In the C/V MR
(CC segment). 3. In the TofP). 2. Payment Method: (for country): line item, @, or
payment terms. The PYMT method is generally entered in the C/V MR and not in the doc.
⇒ Baseline date: Starting date sys uses to calculate invoice due date. Rules of
calculation: 1. default values: No default, doc date, posting date, entry date. 2.
Specifications for calculating the baseline date: Fixed date (use to overwrite the
calendar day of the baseline date). 3. # of months to be added to the calendar
month of the same baseline month. Fixed day = fixed calendar day to which the first or second
cash discount terms apply or when net due date is reached. Additional months = Number of months to
be added to the baseline date to determine the end of the 1. or 2. cash discount terms or the net due date.
⇒ Cash discount: calculate: enter % rate in TofP and the 3 of days the % is
valid for the same line (possible to add fixed days and months). Days and Months
in TofP+ Baseline date+ %= cash discount amount.
⇒ Day Limit: enables day-specific TofP in one TofP key. Several versions of TofP
having each version a diff day limit. Day limit is the baseline date to which
the term version applies. Two-part TofP under the same TofP key is possible
when the TofP are dependant on whether the baseline is before or after an
specific day of the month. TofP that require day limit: 1. Doc with invoice date up

7
 to 15th of the month are payable on the last day of the following month. 2. Docs
with later invoice date are payable 15th of the month after.
⇒ Installment Payments: Invoice paid over several months. One due date per
partial amount. If installment payment is defined, sys splits automatically (do not
define cash discount periods or %). Elements: 1. installment #. 2. % rate. 3.
TofP for each installment (line item per each installment).
⇒ Cash discount base amount: 1. Gross (tax): when open items are cleared,
cash discount goes to an @ for “cash discount expense/received”
(expense/revenue @s are not reduced). 2. Net (no tax): Expense/revenue @s are
reduced. There’s a cash discount clearing @ and also a lost cash discount if
payment done after cash discount deadline.

Lesson 5: Taxes
⇒ Taxes are levied in invoice amount as: 1. Tax on sales/purchases. 2. US sales
tax. 3. Additional Taxes (country-specific). 4. Withholding tax. Taxation types: 1.
Fed/country level. 2. State/jurisdiction level.
⇒ Tax support: 1. Calculate tax amount. 2. Posting amount to define tax @s. 3.
Performing tax adjustments for discounts and deductions. 4. Tax reporting. Base
amount: expense or revenue amount (with or without discount). Gross tax base =
Includes cash discount, Net tax base = Does not include cash discount. Tax code: required to
perform tax functions. 1+2=tax amount (which can be gross or net depending on
the CC or jurisdiction code).
⇒ Tax on sales and purchases: Balance of output tax (to net value of goods and
billed to customer. Liability of company to tax authorities) and input tax (to net
invoice amount and billed to vendor. Receivable company claims to tax authorities).
⇒ US tax on sales and purchases: Collected by vendor on a sale and remitted
to jurisdiction of the customer. Use tax: on customer if previous condition didn’t
occur.
⇒ Tax calculation procedure: Assigned to every country: 1. Steps. 2. Tax
types (condition types) that apply for the country (rules for calculating tax). 3. @
key/transaction key: This is used for posting to the correct tax @s (automatic @ determination). The
@ keys also create the tax items during posting. The calculation procedures are defined in sys and user
does not have to maintain them. Tax rates are assigned to the tax types that are used in the tax calculation
procedure.
⇒ Jurisd. code: State, County, City, District. 2 steps: 1. define length of
individual elements of the code for the format “jurisdiction code”. 2. define it for
every level.
⇒ Tax code: enterede when posting the doc and main connection to tax
calculation. Tax code is linked with: 1. Country key. 2. Combination of country key
and tax jurisdiction code. Tax code is used for: 1. Verify amount of tax. 2. Calculate
amount of tax. 3. Calculate additional tax portion. 4. Verify tax type. 5. Determine
GL @. 6. Show tax correctly on tax forms.
⇒ Tax rates: Contained in tax codes. Assigned to the tax types used in tax
calculation procedure. 1. Tax code may have several tax rates for diff. tax types.
Tax rate 0 applies. Tax type definition determines if the base amount is “percentage
included” or “percentage separate”.
⇒ Tax postings: 2 cases: 1. As separate line item (standard) to a special tax @.
2. tax with certain transaction/@ keys are distributed to relevant expense/revenue
item (non deductible input taxes).
⇒ Tax @ determination: can be automatic by assigning data to the
account/transaction keys: 1. Posting key (40-50) 2. Rules determining fields
the @ determination is based on (e.g. tax code or account key). 3. Tax @s.

8
⇒ Tax @s: to which tax items are posted. Defined in the “tax category” by
entering: 1. < for input tax. 2. > for output tax. (tax code can define it).
⇒ Other GL @s: “blank” for non tax-relevant postings. “-“ postings that require
an input tax code. “+”postings that require an output tax code. “*” any tax code.
“xx” with a xx predefined tax code. If “posting without tax allowed” field is
selected, GL @s can be posted without any tax code.

Lesson 6: Cross-Company Code Transactions (CCCT)

⇒ 1 or more CCs in one BT (1 pays, buys or sells for/to another). Process flow:
1. A CCCT posts to @s in several CCs (1 doc for each CC). 2. Sys creates
several offsetting docs to balance C and D in the doc. Sys generates automatic line
items which are posted to Clearing @s for payables and receivables. 3. All docs are
linked by a common CCCT number. Taxes are not distributed among CCs.
⇒ Clearing @s: defined in every CC before a CCCT. @ may be GL or C/V @.
Assign clearing @ to every possible combination of CCs. Use one CC as the
clearing CC so every CC assign clearing @ to that one. PKs must be assigned to
the Clearing @s to identify account types. CCCT doc #: CC doc that links all docs
together: combination of doc # of the first CC, the first CC # and the FY. Can be
reversed.

UNIT 5: CLEARING
Lesson 1: Clearing Open Items.
⇒ Open Items are incomplete transactions such as invoices not paid. For a
transaction to be completed, it must me cleared (clearing postings have been
carried out for item or group of items so balance = 0). Docs with open items can’t
be archived. A clearing transaction always creates a clearing doc. There are two
ways to clear open items: 1. @ clearing (subsequent). 2. Posting with clearing (during posting).
⇒ Posting with Clearing (PWC): invoice is posted to a customer @, customer
pays and payment is assigned to an open item, the invoice is cleared with the
payment and balance=0. Procedure: 1. enter the clearing doc amount. 2. select
open items to be cleared. 3. clearing amount is assigned automatically. 4. If total

9
amount of selected items = total amount of clearing doc, sys clears open items by
creating clearing items. If total amount of selected items ≠ total amount of
clearing doc, sys allows to post the difference. PWC can be done for several @s, @
types and any currency simultaneously. It can be manual or automatic.
Account Clearing: e.g.: clearing an open invoice with a related credit memo and
payment on @. Procedure: choose open items from an @ that balance=0. Sys
marks them as cleared and creates a clearing doc which number and date are
entered in the clearing item. Date can be current or determined by user. Account
clearing works for any @ managed with open items in GL or SL. To Clear items
within an @ not always is necessary to carry out postings. It can be manual or
automatic. Manual clearing takes place, for example, in the following cases: 1.For bank sub@s
and clearing @s, 2. For debit memo procedures. 3. If a vendor makes a rePYMT.
⇒ Automatic Payment Program (to clear open items for GL and SL @s): It
groups items for an @ together when they have the same entries in: 1.
Reconciliation @ #. 2. Currency. 3. SGL indicator. 4. Five free defined criteria from
doc header or line item. If balance in local currency=0 sys clears automatically and
creates clearing docs. Prerequisites: Customizing defines: 1. @ to be cleared. 2.
define user criteria. Steps: 1. Groups items. 2. If balance=0, clears. Program does
not clear: 1. noted items. 2. statistical postings, bills of exchange postings. 3.
items with withholding tax entries.
⇒ Assignment field as sort field: “Sort+ field” entry in MR when posting
(combination of up to 4 fields max 18 characters). Can be used to trace docs
between FI and other components.

Lesson 2: Incoming and Outgoing payments

⇒ Manual Payment Process: transaction that clears an open item (typically and
invoice), by manually assigning a clearing doc. INCOMING PAYMENT (AR): clears
an open debit @. OUTGOING PAYMENT (AP): clears an open credit @. Three
steps:
⇒ 1. Data is entered in doc header: a. Payment header: 1. doc date. 2. Doc
type. 3. CC. 4. Posting date and PP. 5. Currency code, T∆, date of currency
translation 6. Ref. doc #, doc header text, clearing text. b. Bank Data: 1. @ (GL
for incoming or outgoing payments). 2. Payment amount. 3. Bank charges. 4. Value
date (date on which the actual cash movement takes place -to evaluate position in
cash management). 5. Text (description). 6. Assignment #. c. Select Open Items:
1. @ and @ type. 2. Normal open items and/or SGLTs. 3. Payment advice note #. 4.
Other @s (to process their open items at the same time).
⇒ 2. Process Open Items: a. Activate line items to assign a payment:
amount entered is assigned to the line item and their cash discount. Options: 1.
Selection of editing options for open items. 2. Double click on the amount. 3.
Selection form action menus and function keys. If amount entered=amount
assigned posting the doc is possible. b. Activate cash discount: determined by
TofP of line item. Discount is used to calculate assigned amount and is can be
changed (tolerances).
⇒ 3. Post: a. Display overview. b. Simulate to reveal automatic
generated items. C. Correct mistakes. d. Post (if D and C agree).
⇒ Automatic Postings for clearing open items: Can be carried out for: 1. Cash
discount expense or revenue. 2. Cash discount clearing (net procedure) 3. Tax
adjustments. 4. T∆ differences. 5. Bank charges. 6. Clearing fro CCC payments. 7.
Over or under payments with tolerances.
⇒ Resetting Clearing: for individual docs when line items cleared in error.

Lesson 3: Payment Differences (PD)

⇒ If PYMT differences occur they may be handled either automatically or manually. 1. Automatic
clearing: If the PYMT difference is small, it can be dealt with automatically: 1.By adjusting the cash

10
discount. 2. By writing off the difference to a special @. The limits up to which a difference is considered
to be immaterial are defined in tolerance groups. 2. Manual clearing: If the PYMT difference is too high
to be immaterial, it must be processed manually: 1. By manually adjusting the cash discount. 2. By
posting the PYMT as a partial PYMT. 3. By posting the PYMT difference as a residual item. 3. By
posting the PYMT difference as a difference posting.
⇒ Tolerance Groups (TG): 3 types: 1. Employee (assign to
user Mater data): type of employee hierarchy (a. upper limits. b.
permitted PDs). 2. GL @s (assign to MRs): clearing @s for external
procurement or for in-house production (permitted PDs). 3. C/V @s
(assign to MRs): good, not so good, cash only (a. Default values for
clearing transactions. b. Permitted PDs. c. Specification for posting
residual items from PDs. d. Tolerance for payment advice notices).
Two steps to use TGs: 1. Group definition: a. TG is defined by a
group key, CC and currency code. b. Group key 4-character
alphanumeric key. C. “blank” is standard TG: minimum. 2. Group
Assignment: a. Employees. b. GL MRs. c. C/V MRs. d. default “blank”
value.
⇒ Permitted PD: can be found in both types of TGs. Control de
automatic posting of cash discount adjustments and
unauthorized customer deductions.
⇒ PD: Normally during clearing of an open item. Diff. is compare
to TGs and handled accordingly: Within tolerances: automatically
posted as either cash discount or unauthorized deduction. Outside
tolerances: processed manually.
⇒ Processing PDs: If diff. is immaterial (limit defined in TG),
processed automatically by allowing sys to adjust cash discount up to
certain amounts or to write it off to a special @. If diff is too high to be
immaterial, processed manually. Payment can be posted as follows: 1.
Partial payment (all docs remain open). 2. PD may be posted as a
residual item (only residual items remain in the @ and open). 3. PD
can be posted to an account assigned to a reason code or written off
by manually entering a new posting item. 4. Payment on account
(write off the diff.).
⇒ Partial and residual payment: C/V TGs contain entries to
control residual items that specify: 1. TofP for residual items are the
same as the cleared items or are fixed. 2. Cash discount is granted
partially or not for the whole amount. 3. By using a dunning key, if
residual item has a max. dunning level or is printed separately.
⇒ Reason codes: to describe reason for the PD. “distribute diff.”
can be used to assign more than one reason code to a PD. Reason
codes can be assigned to: 1. Difference postings. 2. Partial payments.
3. Residual items. Optional functions: 1. Ctrl type of payment notice
sent to customer. 2. Ctrl @ where a residual item is posted. 3.
Automatic posting of a residual item to a specified GL @. 4. Exclusion
of residual items from credit limits checks because they are disputed.

Lesson 4: Exchange Rate (T∆) Differences (T∆Ds)

⇒ Realized T∆Ds: due to fluctuations, when claring open items in
foreign currency. Sys posts T∆Ds automatically and realizes gains
or losses to revenue/expenses @s. the realized T∆Ds is stored in
the cleared line item. T∆Ds are also posted when open items are
valuated for FS to another T∆Ds @ and to a FS adjustment @.
⇒ @ Determination: All Recon. and GL @s with open item
transactions in foreign currency must be assigned
revenue/expense @s for realized losses or gains. One gain/loss
can be assigned to: 1. All currencies and currency types. 2.

11
 Per currency and currency type. 3. Per currency. 4. Per
currency type.

UNIT 6: CASH JOURNAL

Lesson 1: Cash Journal (CJ) Configuration
⇒ What is the cash journal and what can you do with it? 1. Tool for managing cash. 2. Supports
posting cash receipts and expenses. 3. Create a separate cash journal for each currency. 4. Make postings
to G/L, customer, and vendor @s. 5. A CC can have several cash journals. 6. A cash journal has a 4 digit
alphanumeric key
⇒ CJ Assignment: CJ is tool for managing cash, which supports cash receipts
and payments. Functions: 1. Create a separate CJ for each currency. 2. Post to C/V
and GL @s. 3. Run several CJs in each CC. 4. Choose a number for CJ ID (4.-digit
alphanumeric key).
⇒ Setting up the CJ: enter values in: 1. CC. 2. 4-digit CJ ID code. 3. GL @s to
which you want to post the CJ BTs. 4. Currency. 5. Doc types for: a. GL @s
postings. b. Outgoing payments to Vs. c. Outgoing payments to Cs. d. Incoming
payments from Vs. Incoming payments from Cs.
⇒ BT types: 1. Expense (E): Expense/cash desk. 2. Revenue (R): Cash desk
revenue. 3. Cash Transfer from CJ to Bank (B): Bank/cash desk. 4. Cash
Transfer from Bank to CJ (C): Cash/Desk Bank. 5. AR (D): Customer payment
receipt cash office/customer and Customer outgoing payment customer/cash office.
6. AP (K): Vendor payment issue Vendor/cash office and Vendor incoming payment
CJ/Vendor.
⇒ Creating BTs: can define them in two places: 1. CJ itself 2. IMG. Settings to
create a BT: 1. CC in which BT should be created. 2. Type of BT. 3. Tax codes for
the BT E and R. 4. For BTs E, R, B and C: set indicator to enable the GL @ for the BT
to be changed when the doc in entered. GL @ is only a default value in this case. 5.
For BTs E and R: indicator to enable tax code to be changed when doc is entered. 6.
Once saved, BT is assigned a code automatically. 7. Set and block indicator for
further postings.

Lesson 2: Cash Journal (CJ) Transactions

⇒ Posting BTs in the CJ: CJ is one of the ENJOY BTs that can be processed in a
single screen (enter, display and change CJ entries). CJ entries can be saved locally
in the CJ SL and can be copied or deleted. Saved CJ entries are posted to the GL at
the end of working day for example.
⇒ CJ doc with doc split: A CJ can contain several items with diff. tax codes
and/or @ assignments relevant to cost @s. When the CJ doc is forwarded to FI, only
one accounting doc is therefore created.
⇒ CJ docs with One-Time account: In CJ you can create a BT linked to a one-
time @. If you use a one time @ in the CJ, the dialog box for entering the one time
data is called automatically and the entries saved in the CJ.

12
 UNIT 7: SPECIAL G/L ACCOUNTS
Lesson 1: Application Area for SGL Transactions
⇒ What are Reconciliation @s (R@)?: Transactions in the SLs (e.g. AR-AP) are
also posted in R@s in GL to have the values available in form of totals as well as in
the GL to quickly create a financial/income statement. To determine
payables/receivables, the balance of the R@ can be directly displayed instead of
searching for the values in the SL. R@ to be posted is entered in the C/V MR. R@
field: CC segment of C/V MR.
⇒ Posting in the SL: @ # of the R@ posted can be seen on the FI doc.
Transaction figures are updated on the R@ in concern.
⇒ SGLTs-Alternative R@: are @s in the AR and AP that are displayed separately
in the GL and the SLs. Transactions in the SL are linked to the GL by RA defined in
the SL MR. If SL @ assignments are made using a SGLindicator, postings are
performed on alternative RA (SGL@s) to display these transactions separately.
⇒ 3 SGLclasses: 1. Down Payment (DP): requested, received and used. DP
process is integrated to the dunning and payment programs. Bills of Exchange
(BofE): In order to deal with country-specific particularities. 3. Other transactions:
“other” option in doc entry menu in AR and AP.
⇒ 3 SGLtypes: or ways of transferring SGL entries to sys. Configured in the SGL
indicators.
⇒ 1. Automatic offsetting entries (statistical): transactions always posted on
the same offsetting @. Usually included in the notes of FS. The @# is defined in
customizing and entries are made automatically to the @. Clear the open items in
the respective @ makes the sys clear the open items in the offsetting @. These
transactions are called statistical postings since are not displayed in FS but in
notes.
⇒ 2. Noted items: individual @ assignments only used to remind the respective
department of due payments of payments to be made and are not intended to be
displayed in GL. Only one line item is updated if a noted item is created and no
offsetting entry is made. No zero balance check is made. Payment and dunning
programs can access noted items for further processing. Noted items are
administrated as open items in the AP/AR and the SGL@. Line item display must be
activated. No transaction figures are updated when entering noted items.
Items can be found on the line item list but do not affect the displayed
balance of the customer. SGL@s posted to also always display balance
zero.
⇒ 3. Free offsetting entries: Postings are part of the FS with freely definable
offsetting entries.
⇒ DP in the Customer area: Procedure: 1. DP request: are noted items. Do not
change any account balance. It’s possible to automatically issue dunning notices
and make payments. 2. DP received: displayed as payable in accounts. They may
not change the balance of the “receivables” RA. Received DPs are administrated in
the “DP received” alternative R@ in the payables area on the FS. 3. Customer
invoice: Customer receives an invoice whenever good or services are supplied. 4.
Posting a DP clearing with invoice: at this point, DO is not longer a DP. Amount must
be displayed as payment on the normal RA. 5. Clearing: of items during payment of
customer’s balance. 6. Individual Value Adjustment (IVA): another SGLT. Disputed or
doubtful receivables are entered as IVA when preparing the balance statements for
year-end closing. The transaction is entered in the customer @ and in the SGL@.

13
⇒ IVA for receivables: Procedure: 1. Receivable is entered in the customer @.
2. IVA without tax is entered. Expenses are now in the right place in the “expenses
for IVA” @ for the income statement reporting. 3. IVA is cleared after the key date
for the balance sheet, meaning it is reversed. 4. Final value adjustment is made
after asserting that the receivable in uncollectible. In this case, the expenses for
uncollectible receivables @ is posted to. No SGLaccount is used since
adjustment postings must be made on regular C RA.
⇒ Guarantees of Payment-customer (guarantees of payment made): Company
takes over a guarantee of payment for certain amount. Transaction is displayed in
on the @of the customer and on a SGL@. Guarantees made are displayed in the FS
notes. Guarantees of payment are stored in SAP as transactions with automatic
offsetting entries.
⇒ Guarantees of Payment-vendor (received guarantees of payment): vendor
makes the guarantee for company.
⇒ Bills of exchange (optional): a type of short-term financing treated as a SGLT.
Transactions are automatically recorded in the SL separately from other
transactions and posted to a SGL@. BofE can be seen at any time. Receivable and
payable BofEs can be posted as well as incoming and outgoing checks. Procedure:
1. Receivable is enetered in the customer @. 2. Customer initiates payment with a
BofE. @ balance is now registered as a receivable BofE and not as a normal balance
of AR. 3. Bank collects money from @ of the customer on a fixed date. 4. Collected
amount is transferred to the company’s @. 5. Amount is posted to the @ of the
customer and the respective accounts cleared.

Lesson 2: Configuration of SGLTs

⇒ Basic settings for SGLT: 1. PKs: SGLT are posted from the application side
by means of special PKs (09,19,29,39) and using SGL indicators that indicate PK is
being used to enter SGLTs. 2. Outsorting of the alternative R@. SGLT are
posted to an @stored in customizing and not to the R@ stored in the MR. These @s
must be created in FI and outsorted according to requirements. SGL @s are defined
as R@s for the D and K @ types (always line item display activated).
⇒ Configuration of SGLT: Properties and @ determination: in SGLT possible
to make changes in: 1. Diff. @ # for R@ or SGL @s. 2. Other PKs or GL indicators for
individual transactions. 3. Other settings for automatic postings (accounts to be
posted to, PKs, rules of @ assignment). SGL indicator: determines the type of
transaction and the @ type. In “properties” determine the characteristics of SGL @s
in connection with the @ type: a. Noted Items: can determine that the SGLT does
not update any @ balance. b. Relevance to credit limit check: can include SGLTin
the credit limit check for customers. c. Warning against commitments: can
determine that the user get a warning about SGLT existence when posting to C/V
@s. d. Target SGL indicator: for noted items. For line items, set which SGL indicators
are allowed to be added as target SGL indicators when entering (applying) a
payment request. The target SGL indicator is used in the standard sys for DP
requests. e. SGLT class: determines types of transaction. F. PK. The alternative SGL
@ is stored separately in the account determination according to the CA. sys
proceeds form the R@ found in the C/V MR and assigns it when posting the SGL @
assigned to this R@ in the account determination.
⇒ Automatic Statistical offsetting entries: statistical postings are always made
on the same offsetting @. The @ is stored in the basis of a combination of the @
type (C/V) and the SGL indicator used.
⇒ Setting up the SGLT: 1. Noted Items: No transaction figures updated. No
offsetting @. Only a reminder on the C/V @. 2. statistical items with automatic
offsetting entries: a. stores an alternative SGL @ (alternative RA) and a clearing
@. 3. Transactions with manual offsetting entry: Alternative GL @ should be
stored for the selected SGL indicator. The offsetting @ is entered manually during
transaction.

14
 UNIT 8: PARKING DOCUMENTS
Lesson 1: Basics of Document Parking vs Hold Document
⇒ Holding/parking docs: docs cannot be saved or posted if they aren’t
complete.
⇒ Scenarios for entering docs: 2 ways of saving docs without posting:
⇒ 1. Holding: entered data can be saved temporarily to continue the entries at
later time. Held docs don’t have to be complete. 1. No @ balances are updated
(no update of transaction figures). 2. Doc data is not available for
evaluation. 3. No doc # is assigned. Doc is named to be found later. 4. Free
assignment of the designation/ID. 5. No used in evaluations/reports. Held
docs can be completed and posted or deleted later.
⇒ 2. Parking: 1. Enter complete doc # via doc type as normal. User must
pass on # if assigned externally. 2. Park docs can be supplemented, checked
and post by diff. operator (principle of dual control) 3. Displaying
authorizations/approval. 4. No data updated when parking docs (trans.
figures). 5. Data is available for evaluations/reports. 6. Responsibility. 7.
Acceleration of work procedures. Park doc function is available for conventional
posting and ENJOY posting mask. Park docs can be completed, changed,
posted or deleted. No Substitutions only until the park doc is turned into an
accounting doc.

Lesson 2: Parking Documents and Processing Park Documents

⇒ Enter and store incomplete docs without having to check entries.
⇒ Alternatively it’s possible to check park docs for their completeness.
⇒ @ assignment templates can be used but not reference docs.
⇒ CCCT can also be parked.
⇒ Transaction figures, asset values, are not updated.
⇒ No automatic postings are created.
⇒ Balance is not checked.
⇒ Areas of application of doc parking: 1. Temporary storage of input values. 2.
Displaying multi-level models. 3. Work assignment by means of work lists.
⇒ Ways of using doc parking: 1. Customer @ (invoices and credit memos). 2.
Vendor @ (invoices and credit memos). 3. GL @s (GL @ postings).
⇒ Processing: further processing of park docs by: 1. editing park doc and
posting them (deleted in exceptions). 2. Displaying parked docs in the sys.
(individually or list).

15
⇒ Editing parked docs: Header and line items can be edited, including
amounts. Doc change rules for normal docs do not apply for parking docs. NOT
CHANGE: currency, CC and doc type/number. MAY CHANGE: Dates, amounts, @s
and @ assignment objects. Changes can be displayed before or after posting.
⇒ Posting Parked Docs: as standard transaction individually or by list: direct
posting or batch input. When a park doc is turn into a “proper” doc: 1. Usual
inspections are performed when posting a doc. 2. A normal complete FI doc is
created. 3. History is documented. 4. Doc number remains the same. 5. Transaction
figures are updated. 6. Park doc is deleted after creating a FI doc.
⇒ Doc parking reporting and overview: Doc parking is linked to @ display and
reporting FI functions. Can be included in doc journal and be viewed in line item
display.

Lesson 3: Doc Parking and Workflow

⇒ Workflow: providing employees with right tasks and respective info at
right time.
⇒ SAP Business Workflow: four process dimensions: 1. Organizational
structure (who). 2. Process structure (when, in what order, under what
circumstances?). 3. Function (what). 4. Information (with which data).
Using a graphic definition tool, process to be display as a workflow can be
stored in the sys. SAP BW: 1. tool for the automation of business processes
in SAP sys and between sys. 2. Not tied to a particular application and can
be adapted to customer requirements. 3. Works the same way in all
applications. 4. Coordinates all integrated tasks. 5. Supports user actively.
⇒ Workflow management architecture: 3 layers (flexibility): 1. the right
work. 2. at the right point of time. 3. to the right processor. Workflow are
usually initiated by a triggering event.
⇒ Tasks related to the workflow: 1. Posting invoices. 2. Changing
material masters. 3. Realizing purchase requisitions. 4. Approving leave. 5.
Creating customer @s. 6. Deleting purchase order. 7. Creating requirement
request via internet.
Workflow and FI: workflow variants: can be crated for doc parking in customizing
and assigned to CCs and no doc is released until this task is performed. The workflow
V and the corresponding CCs must have the same currency.
⇒ Assigning workflow variants to CC: it’s possible to apply diff. release
procedures to diff. AR and AP. The Release Group field in these @s
controls it. Release group is required to determine Release Approval
Path at the time of processing. The path is determined by the workflow
variant in connection with doc type and release group.
⇒ Calculation of Release Approval Path: Release procedure is
represented by Subwork flows. For doc parking, workflow variant +
release approval paths are assigned amounts, which determine the release
procedure to be initiated and performed. Subwork flows control the
individual release procedures.

16
TFIN50I PART 2
UNIT 1: FUNDAMENTALS
Lesson 1: Customer/Vendor (C/V) Accounts
⇒ Master data: C/V data that remains unchanged and that is often referred to
another data.
⇒ FI view of the C/V @: C/V @s have two segments in the FI view: 1. At client
level: General data. Can be accessed throughout the whole organization. Data: a.
address. b. Ctrl data. c. PYMT transactions. + texts. 2. At CC level: CC specific
data. Any CC, to do business with a certain C/V, has to create a CC segment for the
C/V (a C/V @ is created). Data: a. @ management. b. PYMT transactions. c.
Correspondence. d. Insurance. e. Withholding tax. + texts.
⇒ Pages of the C/V @. Important fields: 1. search term: abbreviation of C/V
name. 2. Corporate group. 3. Clerk/accounting: name and ID. 4. Explanatory texts: A
new C/V can be created with ref. to an existing MR.
⇒ AP/AR @ groups: when creating a C/V MR, enter @ group in initial screen. @
group ctrls: 1. # of ranges of the @. 2. If @ is one-time C/V. 3. FST of in MRs.
⇒ Controlling the FST: Factors affect the C/V layout: 1. @ group-specific control:
FST is only control by @ group. 2. Transaction-specific ctrl: FST can be dependant
on the master data transaction (create, change, display). 3. CC-specific ctrl: FST for
fields in the CC segment for C/V MR can also be controlled by the CC dependent
screen layout.
⇒ Clearing C/V: if a customer is also a vendor, PYMT and dunning programs can
clear open items against each other. Steps: 1. V @ must be entered in the C @
and vice versa. 2. Each CC can decide separately if wants to do clearing.
⇒ Alternative Payer/payee: at CC level (1) and a client level (2). 1>2. Individual
specifications indicator: if alternative Pyr/Pye has not been created in SAP. If it
already exists, enter C/V @ as permiteed Pyr/Pye in MRs.
⇒ Head/office branch: C place orders locally but pays centrally. Items posted to
branch are automatically transferred to head office @. Dunning can be an exception
using function “descentral processing”.

17
Lesson 2: Simple Docs in FI
⇒ FI docs in SAP: According to Doc principle: a doc is saved for every posting
and each doc is uniquely ID by: 1. Number (int or ext). 2. CC. 3. FY.
⇒ Doc consists of: 1. Header: info applies to entire doc. 2. Line Item: Specific
info
⇒ Doc ctrl keys: 1. Doc type: for the doc header. 2. PK: for line items.
⇒ Simple posting in FI: can be: 1. GL @ posting. 2. C/invoice posting 3. C/credit
memo posting. 4. V/invoice posting. 5. V/credit memo posting.
⇒ Header and first line item: Grl data for the posting doc (invoice, PK, posting
date, text).
⇒ Additional line items: table in the lower part of screen (@ name) select park,
post, hold. If balance=0.

UNIT 2: AUTOMATIC PAYMENTS

Lesson 1: Payment Run- Overview
⇒ The PYMT process: Nat and Intl PYMT transactions with C/Vs and for
outgoing and incoming PYMTs. PYMT program allows: 1. select open invoices to
be paid or collected. 2. post PYMT docs. 3. print PYMT media.
⇒ 4 steps: 1. Setting parameters: a. what is to be paid. b. PYMT method. c.
when. d. CC considered. e. How are they going to be paid? 2. Generating a
proposal: list of open invoices and business partners that are due for PYMT.
Invoices can be blocked for PYMT. 3. Scheduling the PYMT run: PYMT doc is
created and GL and SL @s are updated. 4. Printing PYMT media.
⇒ Settings for the PYMT prog. are defined in 3 places: 1. In the MR for the business partner,
i.e.: bank details and PYMT methods. 2. In the items, i.e.: PYMT methods in the doc and terms of
PYMT. 3. In Customizing for the PYMT program.
Lesson 2: PYMT Program Configuration
⇒ Structure: Most settings can be accessed directly from USER. Categories
(configuration areas): A. For all CCs define: 1. Inter-company PYMT relationship.
2. CC that process PYMTs (paying CC that records Bank postings) on behalf of
sending CC (records SL postings). 3. Tolerance days for PYMT (grace days). 4. C/V
SGLT to be made. 5. PYMT method supplements (to print sort PYMTs). 6. Cash
discounts. B. For Paying CC define: 1. Minimum amounts for incoming and
outgoing PYMTs. 2. Forms of PYMT advice and EDI. 3. BofE specifications. C. For
PYMT method/ country define: 1. Methods of PYMT and for each method: 2.
create a check, bank transfer, BofE, etc. 3. MRs requirements. 4. Doc types for
posting and clearing. 5. Print program. 6. Permitted currencies. D. PYMT method
for CC define: 1. Min. and Max. amounts. 2. Allowing or not foreign currecies,
foreign C/V, PYMTs via C/V’s bank abroad. 3. Bank optimization (PYMT program pays
from a bank within the same clearing house sys. 4. Postal Code optimization (PYMT
from a bank based on the C/V city of residence). 5. Forms of PYMT media in the form
data area. E. Bank selection define: 1. Ranking order: a. PYMT method. b. House
bank to be considered for PYMT. c. Currencies. d. BofE @ e. House bank identifier. 2.

18
Accounts and Amounts: a. Bank and Bank @. b. Days until de value date and
clearing @ (for BofE). c. Currencies. d. Amount available in house bank for outgoing
PYMTs. e. offset @ to the SL posting for each house bank and PYMT method. 3.
Value date: for each combination of house bank and PYMT method: a. Used with
cash management and forecast to track outflow of funds. b. # of days until value
date plus posting date (value date= PYMT run posting date+ days until value date).
4. Bank Charges: a. Assess additional bank charges for incoming and outgoing
PYMTs. b. Used with BofE. c. Additional automatic posting configuration: sys
subtracts bank charges from clearing amounts for incoming PYMTs. For outgoing
PYMTs, sys adds charges to clearing amount. Sys also posts bank charges to an
expense @ (requiring PK and @ assignment).
Lesson 3: Running the PYMT Program- Individual Steps
⇒ Parameters: Define: 1. What’s to be paid. 2. PYMT method. 3. Date of PYMT.
4. CCs considered. 5. How are they going to be paid. PYMT program is ID by two
fields: 1. Run date: recommended as actual date when program is executed. IDs the
program run. 2. ID field: to differentiate between programs with same date.
⇒ Open Item Selection: 1. docs to be included in the PYMT run. 2. CCs listed. 3.
PYMT method (order important due to priorities).
⇒ Proposal run: Selects docs and @s with items pending for PYMT. Once
complete, two reports: 1. PYMT proposal list: business partners and amounts to
be paid or received with parameters, TofP and discounts. 2. Exception List: Items
that can’t be paid (invoice blocked, invalid data in MR, invalid PYMT record or house
bank, amount is<than min., not enough $ in house bank, debit balance).
⇒ PYMT blocks: temporarily block of items by manually assigning it. 3 ways: 1.
during invoice verification. 2. MR if there’s a reason why vendor should not be paid.
3. When an AP invoice in entered and invoice may be blocked for PYMT. 1 and 2: not
remove from proposal. 3: optional to remove from proposal.
⇒ Editing PYMT proposal: user can edit the list to view details of a particular
PYMT, change PYMT term or add a PYMT block.
⇒ Editing PYMTs: display list of open items due to be paid and change PYMT
block and discount or create new PYMT choosing PYMT method and a house bank.
⇒ PYMT Run: 1. After proposal is edited and save and no postings are yet
made, docs are locked against other postings (manual or other PYMT run). PYMT
docs are created, open items cleared and the GL and SL @s posted to. 2. PYMT run
used data from proposal to: a. Post PYMT docs to GL and clear open items. b. post
related postings for taxes, discounts, and T∆ diff. c. select PYMTs that can be paid
with EDI. d. supply print programs with data.
⇒ Bank subaccounts: advisable for posting incoming and outgoing PYMTs (e.g.
@s for incoming and outgoing checks and transfers). Advantages: 1. Reconciliation
of bank @ at any time with the corresponding GL @. 2. sub@s contain all incoming
and outgoing PYMTs until $ is actually debited or credited in the bank @. Item is
then transferred from sub@ to bank @. Bank sub@ has to be assigned to PYMT
methods when bank settings are configured.
⇒ The PYMT doc: elements: 1. Doc type for PYMT docs: define in country
specific for the PYMT method. 2. Doc header text: date and ID #. 3. Value
Date=days to value date +posting date.
⇒ Printing PYMT media: Print run starts PYMT program doing the following: 1.
Transfers PYMT media, advice notes and summary to print adm. 2. Transfers the
DME PYMT data to DME adm. 3. Creates intermediate docs for selected PYMTs.
⇒ Variants for print programs: Print program is assigned to each PYMT method
for each country when configured. Variants contain a series of selection criteria
used to separate data in the print data set. If several variants are assigned to a
print program, sys runs the program once for each variant.

19
⇒ Forms of PYMT media: in configuration setting of the PYMT prog. assign
PYMT medium forms either to each CC or to each PYMT method in a CC.
⇒ EDI (Electronic Data Interchange) and PYMT advice noted: EDI: sys chooses
all PYMTs selected for EDI, creates a SAP doc for them and forward the to EDI
subsys converting docs into data to be sent to Bank. PYMT advice noted can be sent
by email or EDI.
⇒ DME (Data Media Exchange): File with relevant PYMT info is created
according to bank rules. DME file is stored in data medium adm. DME can be used
in all PYMT methods in which medium is handled to bank for further process.
Lesson 4: PYMT Medium Workbench
⇒ PMW is used to create PYMT media. Avantages: 1. Uniformity. 2. Formats
can be changed without modifications. 3. New formats can be created. 4. All
advice notes output in one print file. 5. Better sort of options for advice
notes. Each PYMT method can be converted individually to PYMT
media formats.
Lesson 5: Debit Balance Check
⇒ PYMT run could result in PYMTs made even if the @ has a debit
balance.
Lesson 6: Automating the PYMT Process

UNIT 3: AUTOMATIC DUNNING

Lesson 1: Dunning (D)-Run Overview
⇒ D Overview: Parameters to specify how D program runs can use a
previous one and update dates for a new one. During D run, sys chooses @
and checks them for overdue items, whether D notes have to be sent and
which D should be assigned. All data is stored in a D proposal that can be
edited, deleted or recreated. D notices are printed and D data updated in the
MR associated docs.

Lesson 2: D Program Configuration

⇒ D procedure: Every @ to be included in the automatic D has to have a
D procedure (also one-time @s). Any # of D procedures can be defined for
standard or SGL @s.
⇒ Structure of the D program configuration:
⇒ A. Procedures: 1. Key for D procedure. 2. Description. 3. D intervals in
days. 4. Minimum days in arreas (@) after which a D notice will be sent. 5.
Grace periods per line item. 6. Interest calculation.
⇒ B. Levels: 1. Minumum # of days, referring to due date of net
payment, to reach a certain D level. 2. If Int is to be calculated. 3. Print
parameters. 4. If D notice is printed although no further @ movements have
occurred.

20
 ⇒ C. Expenses/charges: defined for each currency and dependant on the
level. Fixed amount or %. Set a minimum amount for D charges.
⇒ D. D texts: Name of form used in every level (payment advice notes,
D notices, payment forms).
⇒ E. Environment: 1. CC data. 2. Sort fields. 3. Sender details. 4. D areas
(organizational entity). 5. D keys that determine if line item can be dunned
with restrictions or display separately. 6. D block. 7. Interest. 8. D grouping
to use separate D notice with a different text for each D level in an @.

Lesson 3: Parameters for the D Run.

⇒ Maintain Parameters: D program is ID by two fields: 1. Run date. 2.
Identification (to ID between programs with same date). Parameters provide the D
program with info on the D run. Copying parameters is possible.
⇒ Open Item selection: For overdue items: 1. which CCs. 2. Which @s (range of
C/V @ or free selection). 3. Which Docs (docs posted to date or free selection)

Lesson 4: The D Run

⇒ Creates a D proposal that can be edited, deleted or recreated.
⇒ Steps: 1. @ selection. Criteria: D procedure entered in Master Data; Date of
last D run entered must be earlier than D interval of the D procedure. 2. D line
items (levels). 3. D @s (checks whether payments have to be dunned for an @ and
D level). D procedure entered as master data.
⇒ Due Dates for Receivables and Credit Memos: Receivables are due at the
due date for net payment. Usually Payment terms of a credit memo do not apply.
Rules instead: if a CM refers to an invoice it has the same due date as the invoice.
All other credit memos are due at the baseline date.
⇒ Clearing with Credit Memos and Vendor items: Due net credit items on the @
are cleared with the due net credit items. Applies also for vendor @ if clearing
between C and V is chosen.
⇒ D dates: Due date: Day after which the liabilities must be paid. D date:
Day when the overdue items are dunned. Every dunned item must be overdue
but not all overdue items are due.
⇒ D blocks in item @: If item is overdue but @ has a D block in item, sys adds
item to blocked items list. Also a list of blocked @s.
⇒ Payment method in line item or @: If payment method for incoming
payments has been identified for an item, item is usually not dunned because
payment program is responsible for collecting. Only dunned if has payment block.
⇒ D levels for line item (up to 9 levels): define content of D notice (formulation
in D text). Level is assigned to item according to the D arrears and no D levels can
be skipped. D procedures with 1 D level are Payment reminders.
⇒ D keys: by assigning them to certain items, prevent those items from
exceeding certain D level.
⇒ Minimum amounts per D level: Total amount of all items in an @ with certain
D level must be > than a defined Minimum amount. The relationship between the
total amount and the total open items must be >than a minimum %. If not, items
are set to a lower D level.
⇒ D level in @: @ is assigned the highest D level of all items to be dunned and
also dunning text is worded according to highest level.
⇒ D requirements: @ is only dunned if conditions fulfilled: 1. Data has
changed since last D run. 2. “Always Dun” checkbox has been selected for the D
level. (last level and payment reminders). Different rule for @s in a “legal dunning
procedure”: if the start date of the legal procedure is entered in the @ master data,

21
the @ is always dunned if conditions are fulfilled: 1. Postings have been made
since last run. 2. The “always dun in legal procedure” indicator is selected. In
this case no dun notices are sent.

Lesson 5: Editing the D Proposal

⇒ Editing the D proposal: list that can be printed: 1. D statistics. 2. D list. 3.
Blocked @s. 4. blocked line items. 5. D history.
⇒ Edit D data: possible to: 1. Block @ and remove block. 2. Block line item and
remove. 3. Lower D level. 4. Change D correspondence date of an @ in MR. 5.
Change Doc. 1, 2 and 3 apply for the current D proposal. 4 and 5 don’t apply for the
current D proposal. ONLY CHANGES IN D PORPOSAL APPLY FOR THE
CURRENT D RUN.

Lesson 6: Printing D Notices

⇒ Scheduling Printing: Print Program does: 1. group items to be dunned with d
notice according to rules. 2. Generates a D notice for each group. 3. Enters the D
date and level in the dunned items and @s.
⇒ Group Items in D notices: possible if items have same CC, D area and @.
(Also possible one-time items if they have same address.
⇒ Special Grouping: 1. D by D level: separate D notice for each D level. 2.
Grouping key: in C/V @ to group items in D notices with same values in the fields
assigned. 3. Decentralized processing: head/office branch: items are posted to
central @, Head office receives one D notice with all due items from its branch
offices. Or select “decentralized process”. CCC D is also possible to combine
overdue items from diff. companies in one D run.
⇒ D text ctrl: D recipient, D clerk or accounting clerk, D interest, payment
deadline, standard texts available, all items, D charges, attach payment form.

UNIT 4: CORRESPONDENCE
Lesson 1: Overview
⇒ Opportunities to create correspondence: 1. Ad Hoc: 1. Doc creation. 2.
Display/change line items. 3. Balance display. 4. Line Item processing. 5. Payment.
2. Automatically: 1. Periodic Bank @ statements. 2. BC. Correspondence can be
done periodically specifying interval in the C/V MR. Processing payments manually
and from line item display creates correspondence online. It’s Possible to
configure correspondence creation for certain postings.
⇒ Steps of creation: 1. Request required correspondence. 2. Requesteed
correspondence types are printed.

Lesson 2: Correspondence Types

⇒ User can generate correspondence directly from many screens in the sys (manual individual
request): 1. Doc creation. 2. Display/change line items. 3. Balance display. 4. Line item processing. 5.
PYMT. User can generate this correspondence automatically (collective request with selection program):
1. Periodic bank @ statements. 2. Balance confirmations.

22
⇒ How can user define correspondence in the sys? 1. Define periodic correspondence (for example,
bank @ statements) in the MR. 2. Request individual correspondence directly in the application (such as
for processing PYMTs manually or displaying line items). 3. In Customizing, for example, attach
correspondence to PYMT differences using reason codes.
⇒ Types represent a type of letter in the sys (one for each correspondence
type). Types can be selected by user when processing a BT or automatically.
⇒ Standard Correspondence types: 1. Payment notice. 2. @ statement. 3.
Individual correspondence. 4. Open item list. 5. User-defined.
⇒ Correspondence type components: Following data is necessary for each
type: 1. Payment notice=Doc #. 2. Bank statement= @ # and date. 3. BofE
statement= doc #. 4. Internal docs=doc #. 5. Individual letters= @ #. 6. Doc
extracts= Doc #. Components: required data (doc #, @ #), Additional text, Inter-
company relationship and the # of date fields required. Data from several CCs can
be combined in a letter.
⇒ Printing Correspondence: print program and selection variant can be used for
each correspondence type.
⇒ Linking correspondence type to transactions: Specify which correspondence
type can be used in conjunction with various online functions. This selection
influences the choice of forms available. Specifications per CC.
⇒ Linking Correspondence types and reason codes: For different tolerance
groups, for business partners, specify the default correspondence type in cases of
payment differences. Use different types depending on the reason code. A payment
notice is only created according to reason code if all the reason codes carry the
same correspondence type, otherwise the type of payment notice define in
tolerance group is sent.

UNIT 5: INTEREST CALCULATION

Lesson 1: Fundamentals of Interest (I) Calculation.
⇒ Types of I calculation: 2 kinds:
⇒ 1. Account Balance I calculation: applied to the entire balance of GL or
customer @ using a specific I% over a specific period of time.
⇒ 2. Interest on Arrears: applied to individual items in AR or AP. A certain I%
is applied to those items that are still open or unpaid at specified date.

Lesson 2: Configuring I Calculation.

⇒ Configuring I calculation: involves settings in 5 areas:
⇒ 1. I calculation indicator: Basic parameters to use when calculating I.
Each indicator must be assigned to and I type which specifies whether it is
used for an @ balance I calculation or item calculation.

23
⇒ 2. General terms: Set financial parameters for each I calculation
indicator. E.g.: Frequency, settlement day, calendar type, other settings, max/min
limits on I posting, block on outgoing payments, payment terms, forms.
⇒ 3. Time-based (dependant) I terms: they have validity dates which is
different from General Terms (e.g. a reference I% used in calculation-LIBOR).
⇒ 4. Reference I rates: e.g. LIBOR. For each reference I, a value and
validity are entered periodically.
⇒ 5. @ determination: predefined BTs which are accessed when user runs
the I calculation program. When BT is combined with optional modifiers such as CC
and I calculation indicator, sys determines PK and @ symbols. @ symbols, combined
with modifiers such as currency and CA, refer to GL -C/V @s where the I
transactions are posted.
⇒ Running the I calculation: ways to calculate I:
1. Account Balance: Limit the # of @s included in the I calculation by entering
intervals or individual values for the CA, @#, CC, I indicator, and business area.
Generally, only @s with I calculation indicator and line item display in the MR are
included.
2. Item I calculation (on arreas): I on cleared items only and post the I; I on
open and cleared items and post the I; I on open and/or cleared items without
posting the I.

UNIT 6: COUNTRY SPECIFICS

Lesson 1: Check Management
⇒ Checks are only printable if sys contains a payable, such as an invoice. PYMT
process creates a PYMT doc that clears the open invoice. Check and payment docs
are created in 2 separate steps. When check is created, check #, bank info and
recipient are printed in both PYMT doc and open invoice. 3 docs involved in PYMT
process: 1. Vendor invoice (entered in AP or PO cycle). 2. PYMT doc (records the
PYMT of the invoice and clears the open invoice). 3. Checks (pre-printed or #
generated by sys).
⇒ PYMT docs: 3 ways to pay an invoice: 1. Automatic PYMT program: creates
PYMT docs and checks automatically. 2. Post and Print forms: create individual PYMT
docs and checks. 3. Post: Creates individual PYMT docs using pre-printed checks.

24
⇒ Check info: Info entered in a PYMT doc and the invoice when a check is
created: 1. Bank details: a. House bank and bank key. b. @ ID and #. c. bank name
and city. 2. Check Recipient: a. name. b. city. c. country. d. region. 3. Check Info: a.
check #. b. PYMT date. c. Currency and amount paid. d. cash discount amount. e.
encashment date.
⇒ Voiding checks and reversing PYMTs: checks can be voided before printing
if they are: 1. accidentally damaged. 2. stolen. 3. destroyed. After printing: 1. not
required because cash PYMT is made instead. 2. Torn during printing. 3. used for a
test print. If PYMT doc needs to be reversed, sys allows to: 1. reverse the check. 2.
reverse check then reverse PYMT doc separately. 3. simultaneously.
⇒ Reasons for voiding checks: standard or own. A reason can be defined for
each type of void. Sys-generated codes are used by the printing program. Voiding
a check updates the PYMT doc, original invoice, and check register.
Reversing a doc creates a new reversal doc.
⇒ Check register: ABAP program with reports. 1. All checks. 2. outstanding
checks. 3. checks paid. 4. voided checks.
⇒ Checks cashed online: “cashed checks program” used to manually record
checks that have been cashed by the bank. Process can be automatic with data
supplied by bank. Sys transfers check amount from check clearing @ to the cash @.

Lesson 2: LockBox
⇒ Service by banks to facilitate collection and processing on incoming PYMTs.
PYMT don’t’ go to office but to bank. Information contained in lockbox: 1. Customer
name and # in SAP. 2. Customer MICR # (routing # and @ #). 3. check amount. 4.
Invoice #. 5. Payment date. 6. payment amount/deductions per notice. 7. reasons
fro deductions. Advantages of lockbox: 1. less processing time in accounting dept.
2. increases cash flow. 3. cutting processing costs.
⇒ Capital Flow: Lockbox import programs post a GL entry to update the CC’s
cash position and create a PYMT advice file from the bank input. PYMT advice note
is compared with Customer’s open items in AR. Matching items are cleared. Not
processed checks will be manually processed.
⇒ Lockbox file formats: BA1, BA2, MICR number.
⇒ Lockbox posting entries: posts a cash receipt to an incoming PYMT @ and an
@ for unassigned cash receipts. When PYMT advice info is offset against open
customer items, open item and posting to the @ for unassigned cash receipts are
cleared.
⇒ Processing of PYMT advice notes: PYMT advice notes contain info on the
incoming PYMT. The more complete the better chances of efficient automatic
clearing. Info contained: 1. customer’s MICR, 2. check amount, 3. invoice #. 4. PYMT
date. 5. PYMT amount/deductions per invoice. 6. reasons for deductions. LOCKBOX
searches data and clears open items. When check is assigned, PYMT advice note is
deleted, If not, PYMT advice note is kept for further processing.
⇒ Post processing: check status: checks the status of checks that were
assigned in the lockbox function. Every check that do not balance open items or
that was not assigned to a customer’s @ has to be manually cleared.
⇒ 4 status of checks: 1. Applied (assigned): a. customer identified. b. doc
cleared. 2. Partially applied (assigned): a. customer identified. b. doc cleared. c.
further processing. 3. On account: a. customer identified. c. further processing. 4.
Unprocessed: c. further processing.
⇒ Posting data: in the “posting data for autocash with lockbox” screen, specify
the owner of the lockbox and the types of postings generated. 1. Lockbox format
(BA1, BA2). 2. Types of posting generated (GL, SL). 3. Amounts posted per check or
grand total. 4. Create a batch input session to insert new/missing bank details into

25
the Customer MR. 5. Additional posting parameters (PK, doc types used to create
posting docs).
⇒ Lockbox import program: in the main lockbox program screen you specify
where the lockbox data is stored and how it is to be processed. Also: file name,
format of the input records, and how PYMT amounts are to be cleared against open
items.

UNIT 7: STANDARD REPORTS IN GL ACCOUNTING AND AR/AP

ACCOUNTING
Lesson 1: Information Systems
⇒ Where are the reports? 1. Info sys for each area. 2. Gral report selection
screen. 3. role-based user menu. 3. generally>sys>services>reporting.
⇒ Report Names: most reports in GL, AR, AP start with “RF”. RFK_=vendors.
RFD_=customers. RFS_=GL @s. RFB_=doc reports.
⇒ AP info sys is split into reports for: 1. vendor balances. 2. vendor items. 3.
master data. 4. PYMT transactions. In Dynamic selections options can be chosen
for industry, @ group, country, city, etc.
⇒ AR info sys: GL @ balance list displays selected total figures by reporting
period. It’s possible to see: 1. Carryforward balance at the start of the FY. 2. Total of
the carryforward balance period. 3. D&C total for the reporting period. 4. D&C
balances at the end of each reporting period. At the end of the list: total for each
CC, al CCs and each local currency.

Lesson 2: Report Variants and Variables

⇒ Report Variants: selection criteria: variant enable to execute a report
repeatedly with a diff. selection criteria in diff. variants. Define multiple report
variants for one report. The report variants contain diff. selection criteria. A
report can have diff. report variants that provide info based on the selection criteria
defined.
⇒ Report Variants Attributes: One variant can have: 1. Name. 2. description.
⇒ Report Variant selection variables: instead of entering values for selection
criteria each time a report is started, enter values only once and save them in a
variant Use selection variables if call up the report and use a variant but still want
to display certain values up to the current date. Types of selection variables:
1.Table Variables from TVARV: use them when storing statistical info that can
be used in diff. reports. When saving attributes for the variant, can maintain
parameters in the table with the selection options, single values, intervals, etc. 2.
Dynamic date calculation: e.g. current date, from month start to today, current
date +/- days (working days), first day of the month (current, previous, next), 1st,
2nd, 3rd, 4th, quarter, previous/current month etc.

UNIT 8: LIST VIEWER

Lesson 1: SAP List Viewer Design

26
⇒ LV: Line item list: Creates standard ergonomic list fro predefined data. LV
standardizes and simplifies use of lists in SAP by providing uniform interface list
preparation function.
⇒ LV: Display/change viewers: Functions for displaying and changing docs: 1.
Select detail: eyeglasses to display, pencil to change. 2. Select item: select an item
on the left side of the list. Mass change is possible. Change errors logs.
⇒ LV: Generic functions: 1. Select columns (sorting, filters). 2. Summation (total
and subtotal for specific values).
⇒ LV: Display variants and fields: Possible create new display variants in
addition to the provided. Select fields in column set, hide and sort fields and add
specific fields.
⇒ Classic List and grid ctrl in line item list: When display the list choose: 1. ALV
classic list. Displayed list when no specific settings are made. Useful for multiple
@s. (essentially the print screen and offers a better overview of the sorted list). ALV
grid control: has proportionate text. Useful for individual @s.
⇒ User parameters for list: enter user-default values where value is constant.

Lesson 2: Selections
⇒ Line Item list: use specific selection criteria to choose line item to evaluate.
Criteria: 1. GL @ -C/V@: simple and multiple selection to include or exclude @s
and @ intervals. 2. Selection using search help: A. input for the GL @ line item
list: i) GL @# in CA. ii) GL@ name. iii) GL@ with deletion and block indicators. iv)
Keywords. v) Alternative @ #s. B. Input for V line item list: i) Gral V data. ii) V
country/CC. iii) V by personnel #. iv) V by purchase, material or plant ref. C. input
help for C line item list: i) Gral C data. ii) C country/CC/@group. iii) C with rental
agreement. iv) C for each sales group or with plant ref. v) head office C. 3. Item
selection: A. Item status: i) Open items (operational key date). ii) Cleared items
(Clearing date, open at key date). iii) All items (posting date). B. Item Type
(category): i) standard items. ii) SGLT (C/V). iii) Noted items. iv) Parked items. v) C/V
items.
⇒ Selection by net due date: net due date is calculated from the TofP baseline
date and the highest # of days within the TofP.
⇒ Key for icons: In the header of the AVL classic list: 1. item status: a. open. b.
cleared. c. parked. 2. Net due date: a. overdue. b. due. c. nor due.
⇒ Assignment field as sort field: in addition to selection columns, when creating
or changing the layout, it’s possible to define sort criteria for sorting and create
subtotals.

Lesson 3: Changing the Screen Layout

⇒ Layout: choose between diff. layouts when displaying a list: standard layout
starts with “/” and can be chosen as default layout. If indicator for display variant is
set as initial variant, this variant is always used unless otherwise specified. Also
possible is to use a user-specific layout. 1. Standard layout: default and
initial layout: it’s possible to save the last layout used as default layout. If no
choice is made, the list layout from the default selection screen is selected from
user parameters. Default the input field for each @ type. By default, sys uses ALV
initial layout. Then choose display variant management, if not, sys uses 1SAP
layout. 2. User-specific layout: which only user can use. Select in “editing
options” of the user parameters.

27
 UNIT 9: DRILLDOWN REPORTING IN FI
Lesson 1: Architecture of Drilldown Reporting (DR)
⇒ DR is a dialog-oriented info sys for evaluating data from FI, GL, AR and AP
databases. Contains helpful functions for navigating in the database and for
processing a report interactively. Using the Report Painter: Graphic interface for
activities such as: 1. report writer reports. 2. DR forms. 3. Planning layouts.
⇒ Form types: DR in FI: can be used for GL@s evaluation: 1. Reports for FS
analysis: based on FS versions defined in FI. 2. Key figure reports: takes only the FS
items in the FS version needed for calculation of specific key figures. 3. Balance
display: for C/V DR it’s possible to use a. Balance display report. b. Line item
analysis.
⇒ Architecture of DR: a report is a number of interactive, controllable report
lists and graphics that are displayed on the screen and contains characteristics, key
figures and forms. 1. Provides functions for navigating within dataset. 2. Contains
additional functions to process a report interactively. 3. It’s possible to send, display
on the internet, or transfer reports. 4. Contains functions for printing reports. A
form describes basic content and formal structure of report list. Can be seen as
semi-finished product for a report.
Lesson 2: Characteristics and Key Figures
⇒ A. Characteristics: specify classification options for the data set. E.g. CC,
business area, Plan/actual indicator, time reference (FY, period). B. Characteristic
values: Concrete forms of a characteristic. A combination of a+b=object in DR.
Key figures: are not just values (balance sheet value, debit total, sales/purchases)
or quantities (# of employees, sales quantity) but also calculations (formulas).
⇒ Drilldown list/detailed list: Two types of list for displaying info: 1. Drilldown
list: several objects are formatted using a selection of key figures. 2. Detail list: an
individual object is formatted for all key figures according to the form.
Lesson 3: Form Types
⇒ Single-axis (one) form without key figure: make selection only in
characteristic columns which define the column content. Select key figures and
Drilldown characteristics when defining the report. Single-axis (one) from with key
figure: key figures are integrated with characteristics in rows of form. Two-axis
(matrix) dual anis form with key figure: define rows and columns with key figures
and characteristics.
Lesson 4: Navigation in Reports
⇒ From drilldown list to detail list: Choose detail list symbol.
⇒ From detail list to drilldown list: Choose drilldown symbol.
Lesson 5: Form and Report Definition
⇒ Form definition: Balance sheet analysis example: can define characteristics
for all columns individually (gral selections). Also possible to define characteristic
values (fixed values or variable). Formula can be used to compare two year balance
sheet.
⇒ Report definition: Balance sheet analysis example: characteristics: select all
to be used fro the evaluation in report. These are drilldown characteristics used
to navigate. Sorting and organizing is possible. once one characteristic is selected,
all values of this characteristic are included in the report. Options to restrict the
characteristic values for each drilldown characteristic: 1. do not make an entry: sys
selects all characteristic values. 2. define characteristic value for a characteristic.
Lesson 6: Report-Report interface and report assignment.
⇒ Report-Report interface: links several individual reports, each with a limited
# of characteristics to perform flexible data evaluations.

28
⇒ Report Assignment: Assigns the recipient reports and defines the report
type.
UNIT 10: OVERVIEW OF THE CLOSING ACTIVITIES
Lesson 1: Month-end Year-end Closing Processes
⇒ Month-end closing process: Pre-closing activities (old month): 1. Technical:
Open New @ period (FI). 2. FI: Enter ACRs/deferrals, process entries and bad debt
expense in AR, post depreciation and I expenses in Asset Accounting (AA). 3. MM:
Maintain GR/IR clearing @, post material revaluation. 4. HR: Post payroll expenses.
5. SD: Post goods issues for deliveries to customers. 6. Technical: close old
month in MM, close SLs in FI, preliminary close of G/L (FI).
⇒ Managerial closing activities: CO allocations and repostings, locking the old
accounting period in CO, and re-opening the G/L for adjustment.
⇒ Closing Activities for external purposes: 1. CO: reconciliation posting to FI
(for cross organizational unit CO postings). 2. FI: Foreign currency valuations and
FS adjustment. 3. Technical: Final closing of old period. 4. FI/CO: Creating
external and internal reports.
⇒ Year-end closing process: Activities performed in addition to the regular
month-end closing for the final period of the FY. Pre-closing activities (old month):
1. technical: Open the first accounting period of the new FY (FI). 2. MM: Perform
physical inventory count. 3. PP/CO: update product-cost estimates. 4. MM:
Lowest value determination and LIFO/FIFO valuation. 5. AA: Asset valuations and
investment support. 6. FI: BC for C/V. 7. Technical: FY change (AA) and balance
carryforward (FI).
⇒ Closing activities for external purposes: 1. FI: GR/IR clearing @ analysis,
receivables and payables reclassification, reconciliation of prior year to new year,
and other adjustment postings. 2. Technical: Final closing of the old period (AR/AP
and GL). 3. FI/CO: Creating external and internal reports.

29
 UNIT 11: THE FINANCIAL STATEMENTS
Lesson 1: Financial Statement Versions
⇒ Overview: SAP provides a standard report (RFBILA00) for creating FS. FS
versions are also used in structured balance list, drilldown reporting, planning, and
transferring data to consolidation. To configure the report format determine: 1.
Items to be included as their sequence and hierarchy. 2. Texts describing items.
3. CA and individual @s relevant. 4. Totals to be displayed. Selection parameters
help to make additional specifications: report at business area, CC, level etc.
⇒ FS versions: 1 steps to define version: 1. Enter in the directory of FS
versions. 2. Define hierarchy levels and assign @s. each version must have special
items: a. assets. b. liabilities. c. profit. d. loss. e. profit and loss results. f. @s not
assigned. g. notes to FS. A fixed item similar to assets and liabilities is now created
for notes of FS, ensuring that these @s are no longer included in the profit and loss
result which is derived from the balance of all other @s.
⇒ Balance sheet version of a FS version: A FS version consists of maximum 20
hierarchy levels. Assign items, texts and @s and sys calculates totals.
⇒ @ group assignment according to balance: You use @ group assignment to
determine in which cases the balance of a specific @ group is to appear in a specific
FS item.
⇒ Profit and loss section of a FS version: Hierarchy in the same way as assets
and liabilities in the balance sheet. Use the graduated total function to display the
result of BTs (total of operating result and financial result) as a total.

Lesson 2: Drilldown Reporting

⇒ DR is a tool to analyze GL @ transactions figures and FS and also with diff.
types of comparisons. This reporting provides functions for processing lists (sorting,
conditions, ranking). The basis of DR are formed by: the characteristics (how
data can be classified or provide a time reference-company, CC, business area, CA,
FS item, currency, FY, period, etc-) and key figures (include store values or
quantities, and calculations based on them- total credit balance, total debit
balance, balance sheet value, accumulated balance, balance carryforward, etc-).
⇒ Each report contains lists (# depending on characteristics and values): 1.
Drilldown list: displays a selection of key figures (balance sheet value) in
combination with at least on characteristic (FY) for a number of drilldown
characteristics (assets/business area). 2. Detail list: Shows all the key figures
and characteristic combinations for a single combination of drilldown
characteristics.

30
 UNIT 12: RECEIVABLES AND PAYABLES
Lesson 1: Balance Confirmation (BC)
⇒ Overview: Customer @ closing activities: at the beginning of the FY, the
balance carryforward program is run 1) carrying forward the balances of the
customer @ to the next FY. 2) posting periods of the old FY are blocked and 3)
special periods for closing posting s are opened, then a 4) technical reconciliation
for doc/transaction figures and affiliated companies is performed so posting docs
are technical problem-free. 5) balance are then confirmed, 6) foreign currency docs
valuated, 7) values adjusted, 8) receivables regrouped, 9) special periods closed,
10 BCs generated, foreign currency valuated and receivables regrouped.
⇒ BCs: BC program automatically created BCs for C/V as well as reconciliation
list and result table. BCs are sent to C/V and list forwarded to control center (audit).
⇒ Customizing BCs: reports create correspondence to and for C/Vs to enable to
check the balance of receivables and payables. Procedures: 1. BC. 2. Balance
notification. 3. Balance request. Report outputs a checklist and an error list to
check the receipt of BCs. Prints reports with reminders of overdue BCs and
inquiries. Procedure: 1. define from names for printing correspondence. 2. Define
sender details for correspondence. 3. define reply addresses for BC. 4. specify
selection criteria for BC. 5. Prepare BC for C/Vs.

Lesson 2: Foreign Currency Valuation

⇒ Foreign Currency Valuation (FCV): Do FCV before creating FS. Valuation
includes the following @s and items: 1. @s: Foreign currency balance sheet @s (GL
@s managed in foreign currency). 2. Line Items: Open items (C, V, GL @s) posted in
foreign currency. Previous settings in customizing: 1. Check currency
customizing 2. Define valuation methods. 3. Define expense and revenue for T∆
diffs. from the valuation. Also Balance sheet adjustment @s for receivables and
payables @s. FCV is necessary if vendor @s contain open items in foreign currency.
Amounts for open items were translated into the local currency at the time they
were entered using the current T∆. At the time of closing, T∆ is different and
program valuates the open items again with the new T∆. Enter valuation difference
in the valuated line items and creates a valuation posting. Since valuation cannot
be posted directly to the payables @, it’s posted to adjustment @ in the same line
of the balance sheet as the R@.
⇒ Valuation of Open items without update: Without updating the valuation diff.
in the doc line item (reversing). Valuation with update: storing valuation diff. in
the doc line item. Diff. not posted to the R@ (only updated in doc).
⇒ Customizing: Valuation Methods: for each valuation method define: 1.
parameters for the evaluation procedure. 2. parameters for the T∆ determination.
⇒ @ determination: T∆ diff. (open items): in @s on an open item basis, define
entries for valuated T∆ gain and losses for each R@ in SL @s. Sys posts the @
entries for realized T∆ diff. in foreign currency during the open item clearing.

31
⇒ Valuation of a foreign currency balance sheet @s: depending on the
evaluation method, and the balance of the foreign currency balance sheet @, the
result can be devaluing or revaluing @s.

Lesson 3: Value Adjustments

⇒ Options for creating value adjustment for receivables: 1. enter individual
value adjustment (IVA) as a SGLT. 2. use the program “additional valuations” to
carry out a flat-rate IVA. 3. Once determined the amount of value adjustment,
adjust the flat-rate value by making a manual GL @ posting.
⇒ A. IVA for doubtful receivables: doubtful receivables are written off as an IVA
during year-end closing. SGL methods is suitable since transaction is entered in the
customer @ and is posted to an SGL @, IVA for receivables. After knowing that the
debt will be unpaid or after receiving the payment, IVA is reversed.
⇒ B. Flat rate IVA for Overdue receivables: it’s possible to perform automatic
flat-rate IVA for overdue receivables. In AR configuration define debit rate % (bad
debt expense %) for a valuation adjustment key and an overdue time period in
days. Also set up the adjustment and bad expense @s for doubtful receivables in
the @ determination table. Valuation adjustment key is assigned to C @ MRs. After
valuating, sys produces a proposal that, if correct, valuation can be transferred to
the GL to generate postings.

Lesson 4: Regrouping
⇒ Regrouping payables: To provide outsiders with a better overview of
company’s liquidity situation, receivables and payables can be grouped in the
balance sheet according to remaining life. P and R have to be listed separately in
the balance sheet. Some vendors can have a debit balance so these balances need
to be changed to customer-like vendor @s before creating FS. Another group is
payables in the balance sheet according to their remaining life. Adjustment @ is
used as the offsetting @ since adjustments cannot be posted directly to a R@.
⇒ Regrouping receivables and payables: According to remaining life. The report
to regroup them has the following functions: 1. Sorts receivables and payables
according to remaining life and makes the transfer postings required. 2. Makes the
required adjustment postings. 3. Determines whether transfer postings are
required.
⇒ Regrouping customers with credit balances and/or vendor with debit
balances: The balance of an @ determines whether the sys displays it as a
receivable or payable. For the sys to make transfer postings, adjustments are
required.
⇒ Balancing for affiliated companies: If CC has R and P from a Business partner
that is an affiliated company. In C/V master data define the same company ID in the
“trading partner” field. Define an alternative R@ in master data. In customizing,
assign adjustment @s based on these special R@s.
⇒ Changed R@: Can be changed it in the C/V MR during a FY.

32
 UNIT 13: PROFIT AND LOSS
Lesson 1: Cost of Sales Accounting (CSA)
⇒ Period Accounting (PA): P&L statement can be created using two types of
accounting: 1. PA. 2. CSA. Operating result is the same. In PA, total result for a
period and total cost of this period are summarized. Total result for a period=
sales revenue- decrease of inventory level + increase of inventory level. Total
cost of a period= Grouped by expense type.
⇒ CSA: sales revenue for a period and the sales costs of the period are
summarized: Sales revenue for period= determined the same way as in PA
(balance sheet changes are not considered). Sales costs of period= expenses
related to sales (not grouped as expense type but by function: production, sales,
adm, etc).
⇒ CSA and functional areas: standard program fro P&L statement used PA. CSA
requires the use of organizational units called functional areas to divide costs of
posted to the same expense @ to separate report items. By grouping by function,
CSA also defines the BT that each individual expense in the company results from.
Functional areas can be assigned directly to master data records, such as cost
centers, internal orders, or GL @s.
⇒ Deriving the functional area: in CSA, coding block (list of @ assignment
objects) is extended to include a field for functional area. This field is filled by: 1.
Manual entries 2. Automatically entered functional area with substitution rules. 3.
Automatically copying a functional area entered from MR of P&L @. 4.
Automatically copying a functional area entered from MR of CO object.
⇒ Cost of sales ledger: to create balance sheet in CSA, sys requires transaction
figures for each functional area. Since in standard GL transactions figures are
maintained only for CCs and Business Area, cost of sales ledger must be used so
P&L statement is created in CSA. If additional transactions figures are to be
maintained using existing or new @ assignment fields, use special ledger
component to: 1. Extend coding block. 2. Maintain additional transaction figures in
separate ledger.

Lesson 2: Controlling
⇒ Reconciliation Ledger: Stores all cost flows with CO in a summarized form. In
sys Reconciliation Ledger represents cost element accounting. Compares CO view
with FI view and automatically reconciles CO controlling with FI.

33
Lesson 3: Accrual/Deferral Postings
⇒ Accrual/Deferral of expenses and revenues: Exp and rev posted in one period
can originate in other periods, so they have to be distributed to periods from which
they resulted (accrued/deferred). ACRs: Trigger: economically, exp/rev were posted
to current period and are only posted to a subsequent period once an invoice has
been received or issued. Deferrals: trigger: exp/rev were posted to current period
on a receipt/issue of an invoice but economically belong, at least partially in a
future period.
⇒ ACRs: create them when an exp/rev is to be received in the future but is
incurred or earned partly or completely in the current period. (it is posted in “other
payables” if amount is certain or in “ provisions” if amount is uncertain.

Lesson 4: The ACR Engine (AE)

⇒ Application components of AE: AE is a generic tool for calculating and
creating ACR postings. It receives basic data as input and uses it to calculate ACRs
and create related periodic postings. It’s used among other things to: 1. Manual ACR
in FI. 2. Provisions for awards. 3. Lease accounting. 4. Intellectual property
management.
⇒ Interaction with the AE: AE stores two types of data: 1. Basic data:
description of the subject to be accrued (ACR object). 2. AE docs and total
records: All ACRs docs create postings in the AE and update FY-specific total
records. The AE docs automatically create FI docs. 2 main processes are trigger
from the application component: 1. Create/change basic data. 2. Periodic start
of the ACR run: or reversal of an ACR run.
⇒ Advantages of the AE: 1. Automatic calculation of ACRs. 2. Automatic
periodic postings. 3. Simulations (future ACRs).4. Support parallel reporting. 5.
Extensive info sys. 6. Application components delivered by SAP.
⇒ Activate the Application Component: Customizing: 1. Assign application
components to CC. 2. Define accounting principles. 3. Assign application
components to the required combinations of accounting principles/CCs. 4. Open the
FY for the required application component (usually previous and current FY).
⇒ Closing Activities of AE: 1. Reconciliation AE/GL: AE and GL docs are
reconciled to check transfer to GL. 2. Balance Carry-forward: At end of FY,
carryforward balances of ACR objects into n FY. Not related to GL balance
carryforward.

Lesson 5: Manual Accruals

⇒ Manual ACRs with AE: Creation of basic data, manually via user-interface.
⇒ Posting Deferrals: 1. Expense to vendor. 2. Prepayments and accrued income
to expense. 3. Expense to prepayment and accrued income.
⇒ Posting ACRs: Posting record is “expense to other payables”(certain) or
“provisions (uncertain). When invoice is received, it is posted as “other payables (or
provisions)” to vendor.
⇒ Definition of the Subject Matter to be Accrued: ACR object: make this
definition manually in application component “manual ACRs”. ACR objects are
identified uniquely for each CC using an ACR object # from a range. ACR object is
grouped in categories. Use these categories: 1. as a navigation level to find ACR
objects more easily. 2. to assign special customer-defined parameters to describe
object in detail. Each ACR object can have several ACR Items that describe how a
related ACR type (usually costs or revenues) is accrued using a specific accounting
principle.
⇒ ACR Calculation: for each ACR item, for each combination of ACR type and
principle specified. ACR item contains: 1. Amount. 2. Quantity. 3. Method. Derived
ACR type can also be defined.

34
Lesson 6: Posting Control and Account Determination
⇒ Posting Ctrl: defined for each: 1. CC. 2. Accounting principle. 3. ACR type.
Define Frequency per: 1 PP. 2. Quarter. 3. Semester. And summarization: 1. No
summarization. 2. at ACR object level. 3. Max. summarization.
⇒ @ Determination Task: Purpose: 1. determine doc type. 2. determine debit @
(target @). 3. determine credit @ (start @). Postings per ACR type: 1. none. 2.
only the opening posting. 3. only periodic postings. 4. all. AE supports
parallel @s and parallel ledgers for parallel accounting.
⇒ Derivation Rules: consist: 1. conditions. 2a. source field (derivation rule
input). 2b. target field (derivation rule output). 3. rule entries.
⇒ @ Determination Rules: derivation rules are summarized in a set of rules
which are processed either in parallel (determine independent results) or
sequentially (results and consultative).

UNIT 14: TECH, ORGANIZATIONAL, DOCUMENTARY STEPS

Lesson 1: Technical Steps
⇒ GL closing operations: at beginning of FY: 1. balance carryforward prog.
carries forward balances of GL @s to next FY. 2. PPs of old FY are blocked and
special periods for closing postings are opened. 3. technical reconciliation between
transaction figures and docs guarantees that posting docs are technically problem-
free. 4. Foreign currency docs are valuated. 5. ACRs are carried out. 6. GR/IR
clearing @s are analyzed, including regrouping balance. 7. business area
adjustment if necessary. 8. special periods can be closed. 9. Balance audit trail
carried out. 10. FS are created. 11. messages are created for statutory reporting.
⇒ Balance carryforward: 1. Sys calculates balance carryforward to new FY for
each balance sheet @. 2. balance of P&L @ if posted to P&L carryforward @.
⇒ Defining PPs: Sys used posting date specified in the doc entry to determine
to which PP (defined by FY variant for CC) the doc is posted. The FY variant can be
used to do the following settings: 1. Beginning and end of FY. 2. # of normal PPs. 3.
# of special periods. 4. PP length. PP control: PP variant: code assigned to CCV to
allow opening and closing of PPs for several companies at the same time. @ type:
“+” All, “A” assets, “D” customers, “K” vendors, “S” GL. Allows to control PP by @
type.
⇒ Technical reconciliation: Consistency check performed: 1. D and C
transaction figures for C/V and GL @s with D and C totals of posted docs. 2. D and C
transaction figures for C/V, GL @s with D and C totals in appl. index (used for @s
with open item management or line item display).
Lesson 2: Organizational Steps
⇒Adjustments to FS: Breaks receivables, payables and taxes down into
additional @ assignments “ business area” and “profit center”, which are
sorted in GL@s items (reversal possible) if the adjustment item posted is
cleared at key date of the new run. P&L statement adjustment breaks down
cash discount and T∆ diff. which are accrue when C/V invoices are paid

35
 according to following additional @ assignments from the cleared doc’s GL@
assignment: 1. Business area. 2. Partner business area (consolidation). 3. profit
center. 4. partner profit center. 5. some of CO objects. 6. All fields defined in
coding block.
Lesson 3: Documentary Steps
⇒Balance audit trail (BAT): Displays balance at beginning of period and
changes to @ to period end. Reasons: 1. To display posting info for a FY and
doc status in FI. 2. To provide a statement for external audit. An extract for
accumulated balance audit trail can be periodically generated and extract the
balance list from there. Types of BAT: according to way posting data is
displayed: 1. Historical: transactions arranged according to PP and posting
date. 2. Open Item: Open item turnover is output for each R@. Items are
divided into open/cleared items for SGL indicator.
⇒Accumulated BAT: a data set is extracted or updated from the operational FI
tables to create @ details. Data is written to database tables. 1. Create
balance: docs and transaction figures are read and written to the database
tables (overwriting) 2. Delete balance: data records are removed from balance.
3. Output: an entry of aprox. 250 bytes in length per doc line.
⇒Output for Accum. BAT: Historical accum.: transactions on C/V, GL @s in
classical sense. List also contains transaction data (individual items) from
selected period. Balance carryforward is derived from this. Monthly turnover for
C/V @s is always derived from docs. Monthly turnover for GL @s can be derived
from docs or transaction figures. Open item: transaction for C/V and GL @s with
open items. It processes balance of open item @ accumulated BAT that was
generated before.

UNIT 15: ADDITIONAL MATERIAL

Lesson 1: General Tax Processing
⇒ Taxes: FI is able to handle the tax requirements and procedures of many
countries.
⇒ Tax charged to the invoice amount: 1. Taxes on sales/purchases: a. input
(deductible or no deductible). b. output. 2. Acquisition tax. 3. Withholding tax. 4.
additional taxes (investment tax, sales equalization tax).
⇒ Pre-conditions for tax processing: 1. Calculation procedure inthe country
table. 2. Tax code. 3. GL @ tax category. 4.GL @ as tax @. 5. Doc Tax info. 6.
Closing postings.

Lesson 2: Tax Report in the USA

Lesson 3: Tax Report in Germany
Lesson 4: Tax Report in the European Union
Lesson 5: Reporting in Accordance with German Foreign Trade Regulations

Lesson 6: Consolidation
⇒ Individual FS data as a basis for consolidation: The basis of the consolidation
are the individual FS of all associated companies. All FS from a company are
reported in the consolidation CA which contains itemized values that are result of an
exchange of services within the group. (these values must not be included in the
balance sheet).
⇒ Elimination of Inter company payables and receivables: consolidated balance
sheet cannot include payables and receivables from companies in the same group.

36
Including: 1. Down payments made and received. 2. R/P. 3. BofE R/P. 4. Payments
ands accrued income/accrued expense and deferred income.
⇒ Elimination of Inter company P&L in current assets: Assets involving
deliveries or services provided by the companies in the consolidated FS have to be
reported with the amount whoch they would be reported for a single independent
company.
⇒ Consolidation of investments: Aggregated FS include: 1. Assets. 2. Liabilities.
3. Adjusting Entries. 4. Entire equity capital of parent and subsidiary companies. For
this reason, the balance sheet includes company’s interest in the subsidiaries as
well as the assets of subsidiaries.
⇒ Consolidated Balance Sheet: Includes assets and liabilities of all affiliated
internal trading partners. Services and activities between companies in the group
are eliminated.

TFIN52 PART A
UNIT 1: ORGANIZATIONAL STRUCTURES
Lesson 1: Assignment – CC- CA-Chart of Depreciation (CD)
⇒ Client/CC: Client is highest level in SAP. Apply to all CCs. Each CC is
independent accounting unit. Balance sheet and P&L are created at this level.
⇒ CA/CD: All GL @s are defined in the CA. Asset Accounting (FI-AA) works with
the CA. CD is always country-specific. Each dep. area (DA) represents a specific
type of valuation (e.g. book dep. Or tax dep.). Each CC=CA=CD. CA and CD can
apply to several CCs.
⇒ Depreciation Areas (DA): 2 digit # key and represents dep. terms user enters
in the asset management record or in the asset classes. Values and dep. are posted
to the GL. DA #1 is the leading DA where all values and dep. are posted to the GL.
Other DA: 1. country-specific valuation. 2. Values or dep. that differ from area #1. 3.
consolidation in CC or group currency. 4. Book dep. in group currency. 5. Diff
between group and country- specific tax-based dep. Valuation can be diff. for diff.
purposes. DA are created to manage these diff. valuations. There are separate
transaction figures for: 1. Each asset and DA. 2. individual value components
such as asset values, dep. and net book values.

37
⇒ Asset Accounting (AA): CC must be set up in FI first. The assign CD to CC. CC
is now available for use by AA.

Lesson 2: Cost Accounting Assignment

⇒ In MR assign to an asset: 1. Cost center. 2. (internal) order (real or
statistical). 3. activity type. Thos are assigned to a controlling area with one or more
CCs. Posting dep. from each DA in cost accounting is possible. It’s impossible to
assign an asset to two cost centers.
Lesson 3: Introduction to Asset Classes (AC).
⇒ Client- AC: Fixed assets are classified into ACs (vehicles, furniture,
machines)- AC: consists of 1) Master data section. 2) DA section. ACs are created
at client level and then assigned to at least one CD. For each DA, propose the
dep. attributes for the assets. Dep. attributes cannot be changed unless proposed
by user. Several CDs can be assigned to one asset class ensuring uniformity despite
using several DAs.
⇒ AC and Asset MR: Main criterion for classifying assets. Each asset is assigned
to only one AC.
Lesson 4: Depreciation Areas (DA)/Posting of Values
⇒ CD: It’s possible to manage diff. values of fixed assets in DAs. The attributes
of each DA can be specified in the CD. Assign CD to CCs.
⇒ Define Posting to GL: To determine how and whether values from dep are
posted in GL, it’s possible to: 1. Do not post any values. 2. Post asset values
online, dep. periodically. 3. Post asset values and dep periodically. 4. only
post dep. periodically. Sys dictates that DA #01 posts values to the GL online in
real time (book dep.). Dep. is always posted on a periodic basis. Other DA can
receive values from 01 but calculate and post diff. dep. values to the GL. Some DA
can be fro reporting meaning no posting to GL.
⇒ DAs and the Balance Sheet: Possible to post both asset balance sheet values
and dep. from individual DAs to separate balance sheet @s or income statement @s
in the GL.

UNIT 2: MASTER DATA

Lesson 1: Functions of the Asset Class (AC)
⇒ AC: are the most important means of structuring fixed assets according to
CC. AC consists of 2 main sections: 1) Master data section. 2) Value section. When
creating an asset MR, data in taken by AC.
⇒ AC: @ allocation (determination): Link between MR and @s to which the
related values and dep. key can be identical to the @# of the asset balance sheet
@ in the GL. Several AC can use same @ determination key if they use same
CA.
⇒ Assigning GL @s: 1. Ordinary Dep: a. accumulated dep. @. b. expense @. c.
revenue from write-up. 2. Unplanned dep: a. accumulated dep. @. b. expense @. c.
revenue from write-up. 3. Revaluation of dep, interests (if needed).

38
⇒ Number Range intervals: Ctrls the assignment of the # of the asset MR (#
can be int or ext). Each CC can have its own range or share with other CCs.
⇒ Screen layout of Asset Master Data: Input fields displayed in the asset MR
and if they are required entry or optional. 1. Maintenance level: Master data level at
which each field can be maintained (e.g. AC- main asset #- sub#). 2. Ref. Indicator:
Ctrls which field contents of an asset area can be copied when that asset is used as
ref. to create a new asset MR.
⇒ Activate @ assignment objects: 1. In order for “dep. @ assignment objects”
to appear in the asset MR, activate them in customizing. 2. Otherwise, not
possible to specify how the @ assignment object should appear in the MR. Cost-
accounting dep. can be posted to: 1. Cost-center. 2. CO internal order. 3. WBS
element. 4. real state object. 5. Objects from public sector management.
⇒ Tab pages: Used to represent asset master data in sys. Specify layout of
each AC: 1. # of tab pages. 2. name. 3. field groups.
⇒ Screen layout, asset depreciation area: in each AC enter a screen layout rule
for each DA. Rules also contain a maintenance level that guarantees dep. is
controlled uniformly. Three options: 1. AC: maintenance level ensures uniform ctrl
of valuation at AC level. Entries made in AC are passed to asset MR (not possible to
change). 2. Main asset #: Ctrl of valuation is uniform at asset MR level. Entries
made in AC are adopted in MR and can be changed there. Sub# adopt values that
cannot be changed. 3. Asset sub# valuation can be controlled more flexibly. Asset
sub# have their own individual dep. terms.
⇒ Additional Functions for AC: 1. copy assets from ref. 2. define allowed entries
for user’s fields (evaluation groups, environmental protection indicator, reason for
investment). 3. Enter/change default values in AC. 4. Link AC to material group.
⇒ Special AC: Assets under Construction (AuC): Require a separate AC and GL
@. Dep. key 000 because dep. is not calculated.
⇒ Special AC: Low Value Assets (LVA): manage them individually (single asset
per MR) or collectively ( any # of assets per MR). Needs an AC for each type of
management.

Lesson 2: Asset Master Records

⇒ Create MRs: 2 options: 1. enter CC and AC to which the new MR is to belong
(AC provides ctrl parameters fro the MR). 2. Use an existing asset MR as ref. When
save entries displays asset # if the AC is assigned to a number range. The asset #
is also the @# for the individual asset @.
⇒ Create Multiple Similar Asset Records: useful when purchasing several items
and it’s possible to still make separate entries for each individual asset: 1.
description. 2. inventory #. 3. business area. 4. cost center. 5. evaluation groups.
⇒ Time- dependant Data: that can be changed in a monthly (or other period)
basis. Dep. posting takes place on a monthly basis.
⇒ Changing Assets: A change doc is created every time an asset MR is
changed. Doc contains list of fields changed, number of changes to a field, user
name and the old and new contents are stored. Carrying out a mass change is
possible.
⇒ Asset and Equipment MRs: Two methods to assign equipment and functional
location to an asset: 1. Asset MR (gral info, time dependant data, posting info, asset
valuation info). 2. Equipment MR (gral info, organization, location info, structure) sys
creates the MR and transfers certain MD fields when creating an asset. (updates
automatically).
⇒ DA “XX” in the Asset/AC: data in DA: 1. Dep. key (kind of dep.). 2. Useful life
(how long). 3. Ordinary dep. start (useful life begin date). 4. changeover year (when
to change from declining balance to straight-line dep.). 5. Idex (optional) annually

39
increasing replacement values. 6. Variable dep. amount (how much dep. should be
weighted by the shift factor when using shifts). 7. scrap value (optional): end dep,
when scrap value is reached. 5,6,7=additional parameters mostly used in
cost-accounting dep.
⇒ Asset Sub#: Ext or int # assignment for the asset subnumber that can be
made in AC. If fixed asset is made up of many components. Sub# useful because: 1)
values of individual parts of assets managed separately. 2) values of subsequent
acquisitions managed separately. 3) split asset according to diff. technical aspects.
Sub# can be selected from a list or group them for each asset.
⇒ History List/Personal Value List: List of values that are required recently.
History list os controlled by MR management.

Lesson 3: Mass Changes

⇒ Mass Changes using Worklists: It’s required to process a worklist using FI-
AA standard functions. Workflow not necessary. Steps: 1. create substitution
rule. 2. list of assets to be changed. 3. chose the “create worklist” function. 4. enter
description and purpose. 5. choose appropriate substitution rule for mass change. 6.
Make sure worklist not assigned to any user. 7. check success.
⇒ Substitution Rule for Mass Changes: 2 parts: 1. conditions that identify the
records to be selected. 2. substitution rules that identify the replacement values.

UNIT 3: ASSET TRANSACTIONS

Lesson 1: Asset Acquisition
⇒ AA as Subsidiary Ledger: every transaction in C/V in AP/AR and in asset @s
has direct effect on corresponding GL @s. Thus, Subsidiary ledgers are always in
balance with their GL R@s. GL R@s must be setup in advance with fixed asset’s
dep.
⇒ Asset Acquisition: Integration: 1. From a Business partner (external): a)
in FI-AA integrated with AP (incoming invoice) but not reference to a purchase
order. c) in FI-AA with automatic offsetting entry (which has to be cleared. No link
to purchase order and no integration with AP (invoice has not been received or

40
invoice posted by AP department before hand). c) In FI-AA with automatic clearing
of the offsetting entry: First, posting made in FI-AP. Clearing @ is cleared at the
same time as asset posting is made. d) In MM. 2. From in-house production:
capitalization of goods and services partially or completely produced in the
enterprise. The costs have to be capitalized to assets. 3. Using a CO order.
⇒ Asset Acquisition: Integration with FI-AP: possible to post to both assets and
the vendor in one doc (debit asset, credit vendor). Posting is often made in AP
satisfying the requirements of both FI and AA. Transaction type: when posting to
assets enter a transaction type which identifies diff. transactions in asset history
sheet.
⇒ GL @s for integrated Asset Acquisition: When posting to a vendor or asset @,
relevant GL @s (payables and fixed assets) are automatically updated at same
time.
⇒ Asset Explorer: all functions of asset value display and options of simulating
alternative dep. terms or transactions.
⇒ Asset Acquisition: Master Data changes: at time of 1st acquisition posting,
info updated: 1. Date of asset capitalization (derived from asset value date). 2.
Date of initial acquisition in relevant MR (derived from asset value date). 3.
Acquisition year and period (derived from posting date). Asset Acquisition: Value
Fields: asset value date (capitalization date) determines dep. start date of the
asset. This date is determined for each DA by the period control method of the dep.
key. Posting date and asset value date must be in same FY.
⇒ FI Doc #: define separate # range for each CC.
⇒ Doc Type: Gross or Net: use propose doc or own. Doc type is a 2-character
alphanumeric entry that determines how docs are stored. Doc type determines how
posting is processed. Doc type AA posts gross (no deduction of a discount). Doc
type AN (KN, RN) posts net (the amount capitalized to the asset is reduced by the
discount)
⇒ Transaction Type: used with every posting. Identifies acquisitions,
retirements and transfers. Transaction type specifies which of the following are
updated: 1. Asset balance sheet @s. 2. DAs. 3. Value fields. Transaction types can
be limited to specific DAs or define own transaction types. Transaction Type
Groups: Gather transactions types and define characteristics of transaction types.
Specific groups can be limited to certain ACs.
⇒ Acquisition: Posting to a Clearing @: if asset acquisition postings are not
integrated, a clearing @ would be normally used (GL @ with open item
management to guarantee @ can be cleared). Reasons for not using
integrated postings: 1. Invoice arrived before asset. 2. asset delivered but
invoice not. One posting is made to clearing @ from AP. Other posting is made
from AA. Postings to vendor @ can also be made from AA. Clearing @ is
cleared in the GL (manual or automatic).
⇒ Asset Acquisition with MM integration: Steps: 1. creation of a purchase
requisition. 2. creation of asset MR. 3. creation of the purchase order. When
entering the purchase order, sys determines whether asset is posted directly to AA
and therby capitalized when the good receipt is posted (valuated good receipt), or
whether capitalization will take place until invoice receipt is posted (not valuated
good receipt). If good’s receipt was not valuated, the asset is capitalized, line items
cleared, and the value fields are updated when the invoice receipt is posted.
Lesson 2: Asset Retirement
⇒ Integrated Asset Acquisition: Select “asset retirement” field in revenue @.
Enter data: 1. # of asset. 2. retirement transaction type. 3. asset value date
(retirement date). 4, Portion of historical APC being retired or indicator fro
“complete retirement”.

41
⇒ @s for Asset retirement: Ways of posting retirements: 1. With or without
revenue (scrapping). 2. with or without customer (non-integrated). 3. as full or
partial retirement. 4. a mass retirement. 5. as retirement of several assets (within
the manually posted retirement transaction). Asset Retirement: Calculating
Gain/Loss: sys determines ref. period for retirement based on asset value date
(asset retirement date) and the period ctrl method (period ctrl key) of dep. key. Sys
automatically determines dep., up to the period, that applies to the part of the asset
being retired and cancels this dep. At same time, sys posts asset retirement. Gain
or loss results as the balance of: amount of asset retirement; amount of value
adjustments; and revenue (that is sale price) received for asset.
⇒ Mass Retirement: with or without revenue: is a standard task in sys. Steps:
1. create a list of retiring assets (report). 2. create a worklist. 3. select a purpose fro
the worklist (retirement without or with revenue (sale)). 4. enter revenue
distribution. 5. process the worklist, or edit the worklist before realizing it.
Lesson 3: Intracompany/Intercompany Asset Transfer
⇒ Intracompany Asset transfer: types of transfer: 1. intra. 2. inter. Reasons for
intra: 1. MR created and posted to in wrong AC. 2. Asset location changed. 3. asset
needs to be split. 4. stock material needs to be transferred to an asset. Variant 4.
⇒ Automatic Intercompany Asset Transfer: reasons: 1) due to sale, physical
location of asset has changed. 2) assign asset to a new CC. Differentiate between:
a) Transfer within a legal independent unit (within a company): Both CCs belong to
same company. b) Transfer between legally independent organizational untis.
⇒ Transfer Methods: “automatic intercompany” is used to enter acquisition and
retirement parts of the transfer in one step. Transfer method ctrls how values
are transferred from the source CC to the taget CC. Most cases “gross
transfer method” is used for intracompany transfer which transfers the historical
values of the asset to the target CC.
⇒ Methods: 1. Gross method: No revenue from sale, clearing via clearing @ or
loss due to scrapping. Posted to a R@ in the target CC. 2. Net method: sales
revenue equal to net book value, clearing using R@ fro retirement. Posted to a R@
in the target CC. 3. Net value method: sales revenue, clearing via retirement
clearing @ and revenue clearing @. Posted to a RA in target CC. In net value, net
book value is capitalized on the target asset, and in new value, sys
capitalizes the amount of the sales revenue on the target asset.
⇒ Standard Setting for the Transfer Variants: Variant setting=combination of
transaction types + transfer methods. 1. Transfer within a legally independent unit:
always mapped as intracompany transfer (intracompany transaction type and gross
method). 2. diff. structure: company-specific transfer variants with diff.
transaction types.
⇒ Transfer Variant: Cross-company DA: If CCs are assigned to diff CDs, CDs cab
contain diff. DAs (diff keys) with same actual functions and therefore Cross
company DA. Cross company DA can have assigned diff DAs from diff. CDs. Cross
company DAs don’t’ have their own parameters only a uniform key throughout
client.
Lesson 4: Assets Under Construction (AuC)
⇒ AuC are assets produced by the same company: Two phases: 1) under
construction phase. 2) Useful life phase. Transfer from 1 to 2 is called:
“capitalization of the AuC”. Phase 1 can be managed as a) normal asset MR. b)
asset MR with line item management. Transfer can be done in a lump sum or with
line item settlement. Sys also separates transactions from previous years. AuC: Line
Item Settlement: Procedure: 1) select all items to settle in same proportion to same
receiver. 2) define distribution rules for each. 3) post settlement of line items to
receivers using distribution rule. No need to distribute a 100% of each line item.
Lesson 5: Unplanned Depreciation

42
⇒ In addition to automatic dep. using dep. keys. Manual dep. is possible fro
individual assets according to type. When entering transaction type, sys recognizes
the choice of manual dep. select DAs for which you want to enter dep. sys does not
create an FI doc immediately, only until dep. posting program is run.

UNIT 4: PERIODIC PROCESSING

Lesson 1: Depreciation
⇒ Periodic Processing: Overview: Periodic processing comprises the tasks in AA
to be performed periodically. Planned Dep. and interests can be determined to plan
primary costs on a cost center basis and pass it to CO. Investment Support: Subsidy
a company gets for certain asset investment. Inflation management: Countries with
high inflation rates or deflation.
⇒ Valuation: 1. DAs= 2 character numeric key. 2. Per each DA define how to
post the asset balance sheet values and Dep. to the GL @s. 3. DAs can be defined
for reporting reasons only (no postings to GL @s). 4. Calculation of diff. values in DA
for specific purposes. 5. Per DA, define which values have to be managed and 5.
How posting values and dep. terms should be transfer to other areas. Each area
requires info for dep. postings (frequency, procedure, CO @ assignment).
⇒ Depreciation: define which types of dep. should be used for each DA. Types:
1. Ordinary: Planned reduction in an asset value due to normal wear and tear. 2.
Special: tax-based type of dep. for wear and tear. Usually allows for depreciating a
% of the asset value and the % may be staggered within a tax concession period
without taking the actual wear or tear on the asset into consideration. 3.
Unplanned dep.: Unusual circumstances. 4. Unit-of-production dep.: Take
fluctuation in activity into account for dep. calculations (seasonal usage of an
asset).
⇒ Depreciation Calculation Methods: Specifications and parameters that the
sys requires to calculate dep. calculation methods replace the internal calculation
key of dep. key. 1. Based method. 2. Declining- balance method. 3. Max. amount
method. 4. Multilevel method. 5. Periodic control method. Methods can be
assigned to a dep. key. Advantages: a) country-specific requirements. b) avoid
increasing # of internal calculation keys. c) Dep. keys can be default values for CC
or DA.
⇒ Calculating Depreciation Values: asset MR contains the dep. terms. Sys
calculates annual dep. using dep. key and useful life. Sys determines dep. start date
using asset value and period control method. Values and Dep. are display for every
transaction and area.
⇒ Depreciation Calculation on the basis of periodic intervals: New logic that
examines how long the ref. value can be assumed to be valid within a FY.
⇒ Time-Dependency of Depreciation Terms: Maintaining essential dep. terms
depending of time when maintaining asset MRs. Parameters that can be changed on
a time dependant basis: 1. Dep. key. 2. Useful life. 3. Variable dep. amount. 4.
Absolute scrap value. 5. % scrap value. In FI-AA new features: 1. Dep.
calculation on the basis of periodic intervals. 2. Time-dependant dep-
terms. 3. Automatic changeover method to period/months.
⇒ Cost-accounting Area: Specify in DA whether interests should be calculated
for cost accounting DA and whether dep. should continue below 0. Automatic
calculation: 1. dep. after planned life. 2. dep. below book value (DA: negative book
value). 3. Effective life after planned end. (actual not planned life determines rate of
dep.).
⇒ Imputed Interests: For CO it might be necessary to calculate imputed
interests on the capital tied up in assets. Settings: 1. Allow calculation of imputed
interests in DA. 2. Interests should be posted for the CC and the DA. 3. Dep. key is
used for each calculation method for the dep. type “i” or an own key. 4. If

43
calculation of interests is based on replacement value, sys calculates indexed
interests.
⇒ Replacement Values: Index: if revaluation (indexing) is used in a DA. It’s
possible to specify and index series assigned to index class (parameters). Indexed
revaluation can also be calculated for accumulated dep. and interests (specified in
DA).
⇒ Depreciation Posting Program: Posts the following: 1. ordinary dep. 2. tax
dep. 3. unplanned dep. 4. imputed dep. 5. revaluation of APC or accumulated dep.
Program posts to GL @s and additional @ assignment objects.
⇒ Settings to Post Depreciation: 1. Configure DA. 2. Specify GL @s. 3. Assign
doc type to CC. 4. define posting rules and intervals for DA. 5. Activate account
assignment objects. 6. specify @ assignment type for the @ assignment objects.

Lesson 2: Fiscal Year Change and Year-end Closing

⇒ FY Change Program: opens new annual value fields for each asset. Starts in
the last PP of current year. Applies to whole CC.
⇒ Year-end Closing: Preparation Process: 1. Dep. is posted. 2. Report periodic
posting. 3. Carry out dep. simulation or changes if results are not satisfactory. 4.
Run dep. posting again if changes are made. 5. Balance sheet and P&L statement
can be created. Program checks that dep and asset values are posted in full, and if
assets contain errors or are incomplete. Then, program updates the last closed FY
for each DA and locks posting for AA for the closed FY.

UNIT 5: INFORMATION SYSTEM

Lesson 1: Report Selection
⇒ Report Tree and Area Menu: Report trees were replaced by area menus. The
area menu for reporting is called: FIAA Info Sys Asset Accounting embedded in
the AA area menu. The area menu contains AA Standard Reports.
⇒ SAP List Viewer (ALV): To standardize and simplify using reports in SAP.
Functions ALV: 1. friendly characteristics support the dynamic creation of layouts. 2.
New graphical design. LV functions: 1. Deleting and inserting columns (display and
hiding). 2. Ascending or descending order for values. 3. Totals and subtotals. 4.
layouts to save individual report structure to use it again. 5. setting filters.
⇒ Sort Criteria: 5 sort levels determined via ABAP. Totals and Statistics. Any
sort version can be used with any report.
⇒ Assets History Sheet: Most important and comprehensive year-end report or
intermediate report. It’s possible to: 1. create it using sort version and with totals
at any group level. 2. create compact totals lists. 3. Display history sheet for the
individual assets that form the total and drilldown the asset value display. 4. call up
diff. reports from other SAP components. 5. country-specific versions of the history
sheet. 6. define own history sheet versions.

Lesson 2: Value Simulation

⇒ Simulation with “Asset Explorer”: This offers possibilities for evaluating
individual asset MR. “*” in sub# field. Requests combined reporting for # and sub#.
With “display dep. calculation” is possible to see calculation of dep. in sys. “posted
values” displays planned data for a FY and amounts posted to date. Asset explorer
creates a preview of how values for individual assets will develop by means of
“simulated transactions” and/or “simulated depreciation terms”. Reports
can be started from asset explorer. Other functions: 1. Go to FI docs. 2. Display dep
calculation. 3. Go to related objects. 4. Call reports. 5. Go to asset MRs. 6. Refresh
data after changes. 7. Call values with all sub#s.

44
⇒ Depreciation Simulation: “Simulation”: experimental change to depreciation
parameters affecting the valuation of assets. Applies to: a) single asset. b) entire
asset portfolio. c) part of the portfolio. possible to: 1. change all the important dep.
fields. 2. simulate dep. for future FYs. 3. sort versions and options for a totals report.
4. include dep. for planned k investments.
⇒ Simulation Versions: Allow to simulate a change in dep. method for asset
value/dep. reports. For each DA, AC and Dep. key specify which dep. key useful life
should be chosen for simulation. Possible to define a substitution rule to include
other dep. parameters in the simulation.

UNIT 6: VALIDATIONS/SUBSTITUTIONS
Lesson 1: Basic of Validations/Substitutions (V/S)
⇒ Both used to validate and substitute data immediately upon entry.
Validation: Checks entered values and value intervals. Rule Manager validates
data according to validation rules. Possible to define result of non-compliance with
validation rule. E.g. Pops a message but allows to continue or forces to correct error
before continuing. Substitution: values entered are validated according to a pre-
requisite. If pre-prerequisite is met, sys replaces.
⇒ Procedure: Measures required to Execute V/S: 1. For which area of
application V/S should apply (Where). 2. Select correct call-up point for V/S (When).
3. Define V/S (What). 4. Assign V/S to an organizational unit. 5. Activate V/S. 1.
Application area: where V/S or rule is used (FI, CO, AA, GL special purpose ledger,
Consolidation (V only), PS project sys, Real State, PC profit, center accounting (S
only), etc. 2. Call-up point: specific places in the application that specify the exact
location where V/S occur. Key for the call up point: point from where the V/S starts.
Combination of 1 and 2 determines the Boolean Class for a validation, which
establishes the dimensions that can be used in the definition of V/S and roles. Also
establishes the message class. FI three call-up points: 1. Doc header. 2. Doc line
item. 3. Complete Doc.
⇒ Formula Editor: (Builder): interface for entering arithmetic and logical
statements. Enter operands and operators for logical statements in the formula
through push bottoms. 3 diff. settings: 1. default settings (short descriptions,
displays all operands). 2. Technical names of operands rather than descriptions. 3.
Expert mode: technical names of operands are displayed and statements. Elements
to enter rules: 1. Operands. 2. Logical operators (Boolean terms). 3. Comparison
operators.
⇒ Assignment and Activation: 1. Assign V/S to an organizational unit. It can be
valid for several CCs at the same time. 2. Activate the V/S for the correct call up
point. Degrees of activation: 0=inactive, 1=active for dialog and batch, 2=active
except for batch input. Only V/S can be activated for one CC for a call up
point.
Lesson 2: Definition and Execution of Validations in FI
⇒ In SAP sys almost all input values are validated by a program or checked
against tables or master files. Since some types of validation cannot be
standardized, validation program is used to create validation for specific
requirements.
⇒ Validation Procedure: Consists of several steps with 3 parts each: 1.
Prerequisite. 2. Check. 3. Message. If 1 is satisfied (true), 2 is performed. If
the result of 2 is false, sys posts a message (3). Messages: I= Information,

45
W=Warning, E=Error, A=Cancel. Using Boolean logic, it’s possible to define diff.
types of logical statements (simple or complex). Logical statement can: 1. Compare
fields with one another. 2. Validate fields content for certain values. 3. Check or
compare only a part of the field. 4. Compare text patterns in the statement.
Lesson 3: Definition and Execution of Substitutions in FI
⇒ During doc entry, sys sometimes automatically determines values for fields
from values that were entered for other fields. Sometimes it’s necessary to execute
additional substitutions when entering docs.
⇒ Substitution Procedure: substitution permits the customer-specific
enhancement (substitution) of certain field contents. Several steps with two parts
each: 1. Prerequisite. 2. Replacement. If 1 is satisfied, 2 is performed.
Substitution Methods: 1. Constant value (always the same number value). 2. Exit: to
be carry out at run time. 2. Field –field assignment.
Lesson 4: Additional Techniques in Connection with Val/Subs
⇒ Independent rules and sets available to provide more complex logic. Rule:
Logical statement that can be used in a prerequisite statement, a check or another
rule. Permit s complex logic to be summarized. Can be reused. Rules can also be
used within a statement that uses mathematical processing.
⇒ Set Usage: Set is a flexible data structure for processing for portraying
arranged amounts and hierarchies (sets are maintained and administrated
centrally). Multi-dimension sets are also available (a combination of sets for various
fields-dimensions-) to execute cross-validation with values of diff. characteristics.
TFIN52 PART B
UNIT 1: INTRODUCTION
Possibilities with New General Ledger (NGL) Accounting
⇒ Real-Time Integration CO=>FI
⇒ Segment Reporting
⇒ Transparency and Consistency
⇒ Accelerated Period-End Closing
⇒ Simple Representation of Parallel Accounting
⇒ Financial Reporting Using Any Characteristics (Doc splitting)
⇒ Standard Enhancement and Extensibility (With custom fields)
⇒ Legal and Management Reporting

Benefits of NGL Accounting-Overview

⇒ NGL Accounting: contains functions that combine classic GL Accounting with
Special Purpose Ledger component.
⇒ Extended data structure in standard delivery: Customer fields can be added
to GL.
⇒ With Real-Time Doc splitting, balance sheets can be created for entities such
as “segment”.
⇒ Run Real-Time document reconciliation of Management Accounting (CO) and
FI. There is the real-time integration with Controlling.
⇒ Makes it possible to manage multiple ledgers within the GL Accounting. This
is one of the possible ways of portraying parallel accounting.

UNIT 2: LEDGER DEFINITION

Do companies have to use NGL Accounting?
⇒ Optional for existing customers: During a release upgrade, classic GL
accounting (using totals table GLT0) remains active at first.

46
⇒ For new installations: NGL Accounting is active by default.
The NGL Accounting
⇒ Activation: Customizing transaction (FAGL_ACTIVATION). One of the last
activities performed during the migration project up to the implementation of the
NGL Accounting. The activation indicator is set for each client (mandante).
Activating NGL Accountings results in system-wide changes to application and
customizing paths: Effects: 1. New functions (segments, derivations, derivation
rules). 2. New SPRO Menu. 3. NGL tables activated.
⇒ New Menu Paths: Paths for the NGLA are added to the existing Customizing
paths. Initially, classis paths will remain and then they can be hidden. After
activation. A few classic functions/transactions can no longer be executed.
⇒ Ledger definition: SAP provides the Leading Ledger (L0) and totals table
(FAGLFLEXT) with the standard system. L0 gets many of its control parameters from
the CC: currencies, FY variant, PP variant. Additional currencies can be defined.
⇒ Special features of the L0: 1. There’s exactly one Leading ledger. 2. Only the
values from the leading ledger are posted to CO in the standard sys. In addition to
the L0, it’s possible to have other non-leading ledgers that can be assigned
currencies and/or FY variants that differ from the L0.
⇒ Totals Table FAGLFLEXT: updates more entities than in classic totals table.
New standard fields: Cost Center, Profit Center, Segment. New table can be
extended with additional customer fields that first have to be added to the @
assignment block.
Scenarios
⇒ What is a scenario definition? A scenario defines which fields are updated in
the ledgers (in the GL view) during a posting (from other application components).
⇒ Scenarios provided: 1. Cost center update. 2. Preparation for consolidation.
3. Business Area. 4. Profit center update. 5. Segmentation. 6. Cost-of-sales
Accounting.
⇒ Fields updated by scenarios can be used to model certain business
circumstances- such as segment reporting. Define own scenarios is not possible.
Delivered scenarios are assigned to the ledgers in customizing. A ledger (including
L0) can be assigned one, more or all scenarios. Non-leading ledger are not required
to be defined so scenarios don’t have to be assigned to non-leading ledgers either.
Not need of a ledger for each scenario. Multiple/non-leading ledgers are useful
for portraying accounting in accordance with different accounting principles.
⇒ Entry View and GL View: when NGLA is active, a FI doc always has two
views. Besides the L0, the doc can be seen in other non-leading ledgers in the GL
view.
⇒ Entry View: How a doc also appears in the SLs views/ SL (AR-AP-AA-Taxes)
⇒ Modeled situations: 1. Entry view of FI doc without assignment of
scenarios to a ledger: Nothing changes compared to classic entry view except for
the “segment” that can be derived from profit center. 2. GL view of FI doc
without assignment of scenarios to the leading ledger: If the corresponding
scenarios are not assigned, no entities are inherited to GL accounting (impossible to
allocate transaction to a business area, functional area, profit center, or other
entity). If scenarios are not assigned to a ledger, segment balance sheet is not be
possible. 3. GL view of FI doc with previous assignment of scenarios to the
leading ledger: entities are updated to GL accounting in the corresponding GL
view. The segment field is also updated if scenario has been previously assigned to
ledger. Scenario assignment is not capable of effecting a “zero balance setting” for
any entity.
⇒ Use of the Entity Segment: Segment field is one of the standard account
assignment objects available SAP for running analyses for “objects” below the CC

47
level. The objective is to give a detailed look at the various business activities
(markets or products- Activity areas) at a (bread-based) enterprise. Segments can
be used to meet the requirements of international accounting principles regarding
“segment reporting”. Business Area or Profit Center can be used as alternatives.
⇒ Deriving a segment: ERP enables to assign a segment in the master data of a
Profit Center. Postings are automatically made to segment when profit center is
posted to. If profit center does not have a segment there’s no segment account
assignment.
⇒ Steps to post, analyze and display doc segments in NGLA: 1. Definition of
the scenario: Scenario Segmentation has to be defined for leading ledger (and for
any other non-leading ledgers). If not, segment is only visible in the entry view. 2.
Define segments. 3. Derive segments: derivation from profit centers. 4.
Maintain FST variant and/or FST groups for corresponding FI @s: segment
field must be “optional entry”. 5. Maintain the FST of the corresponding PK.
Also “optional entry”. 6. Display the segment field: using the layout icon in the
doc display. If FST are not defined, posting are still made to the Segment table field,
but this table cannot be displayed or edited in the coding block.

UNIT 3: DOCUMENT SPLITTING

⇒ Available functions in the sys to create segment financial statements: 1.
segment field is a standard field in the totals table for NGLA. 2. FI drilldown
reporting functions let create a segment financial statements.
⇒ Assumptions: The operative process must not be disturbed by the online
split. User only wants to enter the vendor once and when a vendor line item list is
called, there should sill only be one open item for the invoice. Therefore, doc
splitting is only relevant for the GL, it doesn’t need to be visible from within the SLs.
⇒ Steps: 1. Passive split: during clearing (i.e. payment), the @ assignment of
the items to clear are inherited to the clearing line item(s). This step cannot be
customized. 2. Active (rule-based split): The sys splits docs on the basis of
(delivered or custom) doc splitting rules which can be configured. 3. Clearing
lines/zero balance formation by balancing char (and document): Sys creates
clearing lines automatically to achieve a split. Process can be controlled with the
“zero balance indicator”. Clearing lines are always formed when values have to be
reposted between @ assignment objects (i.e. transfer posting from profit center A to
profit center B). Between steps 2 and 3, doc splitting is supported by two
things: inheritance and default @ assignment.
⇒ Characteristics: First define for which FI characteristics doc splitting
is performed (customizing). Characteristics are proposed by sys based on
assigned scenarios. Any other additional characteristic chosen by user must be used
in at least one ledger. When using characteristics to create financial statements,

48
always use “zero balance indicator” so the balance of the involved entities is then
always zero for every posting ensuring “entity balancing”.
⇒ Mandatory Field: 2 meanings: 1. it is an extension of the FST for @s in which
the characteristics cannot be entered during doc entry, and/or @s that cannot be
controlled using the FST. 2. it is a check as to whether a business process-
equivalent business transaction variant was selected (which determines whether a
splitting rule can be found).
⇒ Activating: Doc splitting is first activated client-wide in customizing and
further it can be activated/deactivated for each CC.
⇒ Inheritance: means that, when creating a customer invoice from a revenue
line, for example, the entities (such as business area or segment) are projected
(inherited) to the customer and tax lines in the GL view. There’s no reason to not
activate inheritance when doc splitting is active. Other wise user should have to
define rules for the business processes to ensure that the @ assignment are
projected (i.e. achieve a zero balance in order to post the doc). Activation of
inheritance is first step after activating doc splitting and inheritance is performed
online and at the line item level.
⇒ Standard A/C assignment: can be used to replace all @ assignments that
could not be derived from the posting, with a constant value.
⇒ Simulating the GL view: before the posting.
⇒ Split logic, Active split: 1. Splitting Method: is the total of all splitting rules
of all business transactions and defines how and under which circumstances doc
splitting is performed. Each splitting method defines how each item category is
handled in the individual business transactions- for example whether the @
assignment of a customer item is copied from the revenue items to a customer
invoice. 2. Business Transaction: general breakdown of actual business
processes that SAP provides and that is assigned a wide variety of item categories.
3. Business Transaction Variant: is a specific version of the predefined business
transaction provided by SAP and the (technical) modeling of a real business process
fro doc splitting. 4. Item Category: is a (technical) map for the posted line items.
It describes the items that appear within a doc (business transaction). They are
derived from, among other things, the @ types and GL @s. In other words, the item
category is the semantic description of doc split. 5. Individual Splitting Rule:
defines which item category can/will be split (item categories to be split) and at
the same time defines which base can be used (base item category).
⇒ Expert mode: provides info on all essential doc splitting parameters and
describes how the split amounts are achieved.
⇒ Follow-Up Process: example: vendor invoice is now paid with a cash discount.
Watch for: the selected doc splitting characteristics now have to be inherited to the
posting lines of the payment doc as well. Payment doc is split on the basis of doc
splitting rules of the original posting/vendor invoice. If there’s a residual item due to
a partial payment, this remaining item (creates a new vendor line item) would in
turn be split among the original expenses in the GL view for invoice entry.
⇒ Inheritance indicator ensures deriving and a zero balance setting for entities
selected for doc splitting, without requiring defining any other sys settings. Zero
balance creation is only useful and necessary when creating a complete balance
sheet for a specific characteristic.

UNIT 4: INTEGRATION
⇒ Relevant with the following components: A. Integration with FI
Subledgers: 1. FI-AP. 2. FI-AR. 3. FI-AA. B. Integration with Controlling: CO->FI
real-time Integration.
⇒ Integration with FI-AR: Customer docs are subject to the same rule as in AP:
1. The @ assignment objects in the revenue line item are inherited to the

49
customer and tax items in the invoice (can be seen in the GL view of doc display).
2. The customer and tax line item of a customer invoice withy different @
assignment objects in the revenue line item are split online in proportion to the
amounts in the revenue line items (can be seen in the GL view of doc display). 3.
The customer line item list still only outputs one item per document. 4. When
payments are received, the bank and any cash discount are split analogous to
the revenue lines in the original customer invoice.
⇒ Integration with FI-AA: Assumed sys configuration: 1. AA is managed as a SL
with two DAs (Book 01 and Costing 20). 2. The costing-based dep. is passed on to
CO in the costing area. 3. Parallel Accounting is not relevant.
⇒ Process: 1. Both @ assignment elements are generally derived form the
assigned CO objects in the asset MR (cost center or order). To assign a segment (or
a profit center) for asset transactions, activate @ assignment type APC values
posting for area 01 for the corresponding CO object. The new entities within the
NGLA, such as segment or profit center, cannot be defined directly in the Asset MR.
Sys derives these two objects from the cost center or order, which can be
maintained in the “time-dependent data” for the asset. 2. The segment or profit
center now has to be inherited from the asset item to the vendor and tax items. Doc
splitting also works in the case of the integration of an asset acquisition that is
posted for multiple assets (with different segment assignments). The reconciliation
@s (asset balance sheet @s and value adjustment @s) are already classified
internally as item categories. The item categories for the asset retirement @s may
still need to be defined. New Drilldown reports let create segment or PC financial
statements immediately. As a result, no loger necessary to transfer assets to profit
center accounting. The cost center for the asset is not display in entry or GL views
by default meaning that the asset balance sheet value is not forwarded to a CO @
assignment object by default.
⇒ Post-capitalization of cash discount for an asset: Only possible when doc
splitting is active. However, it’s not necessary to define doc splitting characteristics.
Only works is function is active before entering invoice not just before entering
payment.
⇒ Real-Time Integration CO->FI: From FI to CO has been available fro some
time in SAP. But the other way around (CO to FI) not. This involves changes in
characteristics , for example: 1. Periodic allocations (assessments, distribution,
transfer posting). 2. Manual transfer postings to CO. 3. Activity allocations. 4.
Settlement from orders or projects. CO reconciliation with FI always required the
reconciliation ledger, which was maintain in Cost Element Accounting. A periodic
program run carried out summary adjustment/reconciliation postings for each cost
element/expense @. This is no longer available due to the real-time integration
which also makes possible to reconcile the segment characteristic.
⇒ Variants for CO->FI real-time integration: Variants are used to configure 1.
the criteria for real-time integration and 2. the activation date for real-time
integration. Process: a. define variant. b. assign variant to CC. c. use checkboxes to
determine which characteristic changes will generate real-time FI line items. d.
define key date activation defining when reconciliation is possible through real-time
integration. e. it’s possible to create FI docs for CO docs entered before NGLA was
activated. f. define @ assignment to transfer secondary cost elements from CO to
FI.
⇒ Trace: CO->FI real-time integration can be logged with a trace which makes
possible to analyze the real-time integration at any time including the following
data: 1. Doc # of the original CO doc. 2. Whether it was a transfer or a test run. 3.
doc # of the follow-up doc in FI. 4. reason for transfer or failed transfer. 5. posting
mode: online posting or subsequent transfer. 6. posting date, posting time and user.
7. line item data for all posted docs to object and partner objects. Trace can be
activated in the real-time integration variant being then active for all users at all
times. Or can be deactivated or activated user-specifically at any time.

50
⇒ Doc flow: Navigation from the CO doc to the FI (reconciliation) doc generated
in real time is possible and in the opposite direction. This guarantees traceability of
the accounting docs. This bidirectional navigation is possible because the real-time
integration creates an FI follow-on doc for each activity and not just a totals posting
at the end of the month.

UNIT 5: PERIODIC PROCESSING

Closing Operations
⇒ NGLA: Can save user from many periodic closing and reconciliation
operations because sys already perform them in real time. Examples of eliminated
closing activities: 1. Maintenance and use of reconciliation ledger. 2. Balance sheet
adjustment. 3. Profit and Loss adjustment. 4. Maintenance and use of the various FI-
SL ledgers. 5. Many tasks also eliminated because technical support for segment
reporting is available. Other period-end closing activities are not eliminated
but have slightly changed: Balance carryforward, reclassification/sorting of
receivables and payables, flat-rate individual value adjustment.
⇒ Foreign Currency Valuation: If doc splitting is active, the inheritance of the
profit center and segment in the vendor and tax line items will be shown. Therefore,
the @s selected by the correction posting must have been defined as item
categories for dos splitting.
⇒ New: A valuation run requires the entry of a valuation area. This area must
be defined in customizing and be assigned a valuation method which defines as
before how valuation is run and with which valuation approach (such as the
maximum value principle for payables). Only for balancing valuation (not line item
valuation) you combine the valuation area with an accounting principle.
Valuation areas also apply if user wants to portray parallel accounting. If user only
needs local valuation approach, only one valuation area is necessary.
⇒ Posting: in order that a posting can be created, the expense and correction
@s have to be defined. @ maintenance is sufficient without valuation area
(blank).The FI entities from the original invoice/open items are inherited in the
foreign currency valuation docs if doc splitting is active. If wanted, it’s possible to
post revaluation amount online to the original CO object that was charged directly
in CO. Prerequisites: 1. doc splitting active (expense, revenue and correction
@s defined as items categories), 2. doc splitting characteristic (i.e. cost center)
defined for CO, 3. Revaluation @ defined as primary cost element. Result: Direct
Navigation to a CO doc from the respective foreign currency valuation docs.

UNIT 6: REPORTING
⇒ Data source: By default, after activating NGLA, reports only read tables for
the NGLA. Reading from classic GL accounting is not set but is possible. Any update
of the tables for the classic GL accounting should be deactivated after having run
and verified the first period-end closing. Classic and new forms of GL accounting
can be compared and also to compare leading and non-leading ledgers.
⇒ Balance sheet and P&L statement: classic report to create them is possible
to use even when NGLA is active. New in the classic report: select ledger form

51
which user wants to run de analysis. Additional entities can be selected (profit
center, segment, functional area, cost center).
⇒ Financial statements, an alternative: a new FI drilldown report is available
as an alternative to the conventional financial statements. Advantages: 1. More
flexible (navigation through nearly any characteristic). 2. Selection by standard
characteristics (profit center, business area, functional area and segment; as well as
CC, @#, and partner object) is possible directly in the screen. Navigation let user to
drilldown to an individual FI doc.
⇒ Other drilldown reports are available: 1. “transaction figures-@ balance”
gives a fast, easy GL @ balance list of all @s. GL @ balance display: 1. user can
select the desire ledger . 2. in customizing, user can define characteristics to be
applied in dynamic selections. 3. when double-clicking a balance value, the line
item display (with the GL view) appears.
⇒ Special features for Line Item Display (LID) for GL @s: 1. LID can be started
with info from the entry view or the GL view. The two views show diff results for @s
that are managed on an open item basis and that are split in doc splitting. It’s now
possible to call LID (in the GL view) for @s for which the LID indicator is not set in
the MR. 2. if opting for the LID with the GL view, user can choose the ledger to be
selected and include GL line items such as profit center, segment, functional area,
cost center.
⇒ Payables/Receivables using GL @ assignment: User can call their
payables/receivables not only using the line item display in the SLs but also using
standard drilldown reports that offer an easy way to classify line items using the SL
@ assignment and/or GL @ assignments (using profit center or segment).

52