TFIN50 Part 1 – Financial Accounting I (ECC)

Unit-by-unit study notes written from the course material. Every lesson of the course is covered in the same order as the original.

Unit 1: Core Financial Accounting (FI) Configuration

Lesson 1: Managing Organizational Units in Financial Accounting (FI)

Learn what a client, company code and the optional FI organizational units are, how to create a company code by copying, and how to assign it to a company ID and to a controlling area.

The organizational hierarchy

The client is the top node of an SAP ERP system. Technically it is a self-contained unit with its own master data, tables and transaction data; in business terms it corresponds to a corporate group. Anything defined at client level (for example exchange rates) is valid for every organizational unit below it and never has to be repeated. To log on through the SAP GUI a user needs a client key and a user master record inside that client.

The company code is the smallest organizational unit for which a complete, self-contained set of accounts can be kept and for which statutory financial statements (balance sheet and P&L) are produced. It is the only mandatory structure in SAP ERP Financials and the most important FI organizational unit. Because tax authorities in each country want a separate legal entity, an international group normally creates one company code per country. Rule of thumb: every entity that must publish its own balance sheet and P&L gets a company code.

Creating a company code

SAP recommends never building a company code from scratch. Instead use the IMG activity Enterprise Structure → Definition → Financial Accounting → Edit, Copy, Delete, Check Company Code (SPRO, or directly EC01) and the function Copy, delete, check company code. Copying transfers:

• the definition (basic data),
• the global parameters,
• the Customizing tables,
• the G/L accounts (optional – a dialog asks whether to copy the company-code segment of the G/L accounts; answer yes only if the target should use the same chart of accounts),
• the account determination.

Afterwards only the deviating settings need to be changed in Edit Company Code Data. The key is a four-character alphanumeric code that has to be entered with every company-code-specific posting or master record.

Country templates

Company code 0001 is delivered as a neutral template using the international chart of accounts INT. If a country template exists, the country installation program copies the country-specific Customizing into company code 0001; you then copy 0001 into your own company code. The same program can also prepare country-specific templates for controlling areas, plants, purchasing and sales organizations, credit control areas and FM areas. Two cautions: never use 0001 productively, because the country installation always overwrites it, and run the program only during an initial installation, never after an upgrade, because the country-specific Customizing structure may change between releases.

Optional organizational units in FI

Everything beyond the company code is optional and chosen according to legal or internal reporting needs. The guiding questions are: for which parts of the business is separate reporting required, and for which areas of responsibility must a separate balance sheet or P&L be produced?

Typical mapping of reporting requirements to organizational elements:

Anyone who wants balance sheets by profit center or segment must activate document splitting (Unit 4).

Controlling area assignment

The controlling area is the central organizational unit of Controlling: a closed structure within which costs and revenues are managed and allocated. Several company codes may share one controlling area (cross-company-code controlling) provided they all use the same operating chart of accounts and the same fiscal year variant. IMG path: Enterprise Structure → Assignment → Controlling → Assign company code to controlling area (OX19).

Lesson 2: Checking the Basic Settings in New General Ledger (G/L) Accounting

Understand how New G/L Accounting represents parallel accounting with a leading and non-leading ledgers, how it differs from the accounts approach, and how scenarios decide which fields the ledgers update.

Leading ledger and non-leading ledgers

New G/L Accounting delivers the leading ledger 0L with the totals table FAGLFLEXT. Each client has exactly one leading ledger; since EHP 7 a ledger other than 0L may be declared leading. Every company code is automatically assigned to the leading ledger, it cannot be deactivated, it carries the group valuation view, it is integrated with all subledgers and is updated in all company codes. Asset Accounting depreciation area 01 is always tied to it, and in the standard system only leading-ledger values flow to Controlling.

Non-leading ledgers run in parallel and are activated manually per company code, typically to represent a local accounting principle. They may use their own fiscal year variant and their own second/third parallel currency. Using several ledgers for several GAAPs is the ledger approach.

Accounts approach versus ledger approach

The accounts approach posts the different valuations to different G/L accounts and lets the financial statement version pick the relevant accounts per GAAP. It also works in classic G/L Accounting. SAP regards both approaches as equally valid.

Scenarios

A scenario specifies which fields of the general ledger view are updated when other components post to the ledger. Scenarios are delivered by SAP, cannot be created by customers, and are assigned to ledgers in Customizing (Financial Accounting (New) → Financial Accounting Global Settings (New) → Ledgers → Ledger → Assign Scenarios and Customer Fields to Ledgers). A ledger may carry one, several or all six scenarios; you need a ledger per accounting principle, never a ledger per scenario. Non-leading ledgers are optional, so scenario assignments to them are too.

Key Customizing paths

• Ledgers → Ledger → Define Ledgers for General Ledger Accounting: shows ledger ID, totals table and the leading flag.
• Ledgers → Ledger → Define and Activate Non-Leading Ledgers: per ledger, lists the company codes for which it is active, with their fiscal year variant and parallel currencies.
• Ledgers → Ledger → Assign Scenarios and Customer Fields to Ledgers.

Lesson 3: Outlining the Variant Principle

Recognize the recurring three-step pattern by which SAP ERP attaches shared properties to many objects.

The principle

Whenever several business objects share the same properties, SAP bundles those properties into a variant so that they are maintained once and reused. The method always has three steps:

1. Define the variant (give it a key and a description).
2. Determine the values of the variant (its content).
3. Assign the variant to the objects that should use it (e.g. company codes).

In FI the principle appears for field status variants, posting period variants and fiscal year variants. Knowing the pattern makes each of those Customizing areas immediately familiar: the same variant can be shared by many company codes, and a change to the variant affects all of them at once.

Lesson 4: Managing Fiscal Year Variants

Define how a fiscal year is split into posting and special periods, distinguish year-independent from year-specific variants, and assign a variant to a company code.

What the fiscal year variant contains

Business transactions have to be assigned to periods, so the fiscal year is defined as a variant and attached to the company code. A fiscal year variant holds the posting periods and the special periods: at most 16 periods in total, for example 12 posting periods plus 4 special periods (13–16). Special periods are not time intervals; they hold year-end closing postings. The system derives the posting period from the posting date; when the date lies in the last normal period the user may choose one of the special periods instead. Standard variants (e.g. K4) are delivered as templates.

Important limitation: the fiscal year variant says nothing about whether a period is open; that is handled by the posting period variant (Unit 3). It only defines how many periods exist and when they start and end.

Year-independent variants

If every year has the same number of periods with the same start/end days, the variant is year-independent. Two flavours:

Example from the course: a fiscal year from April to March with six periods; January–March still belong to the old fiscal year and therefore carry year shift -1.

Year-specific variants

A variant is year-specific when period start/end dates differ between years or when some years have a different number of periods. If all years have the same number of periods, only the period dates per year need to be entered. A year with fewer periods than usual is a shortened fiscal year, needed when closing must happen early (change of fiscal year start, sale of the company). The shortened year and its number of periods must be defined before the period dates; a shortened year can only have fewer periods.

Configuration

• Financial Accounting (New) → Financial Accounting Global Settings (New) → Ledgers → Fiscal Year and Posting Periods → Maintain Fiscal Year Variant (Maintain Shortened Fisc. Year) (OB29): variant key, description, calendar-year flag, number of posting periods, number of special periods; sub-dialog Periods for month/day/period/year shift.
• … → Assign Company Code to a Fiscal Year Variant (OB37).

Lesson 5: Identifying the Basic Functionality of Currency Keys and Exchange Rate Types

Understand how currencies and exchange rate types are defined, how translation ratios and quotation types work, and which tools cut the effort of keeping exchange rates current.

Currency keys and exchange rate types

Every currency is identified by a currency key; SAP delivers the standard ISO keys and each key may carry a validity date. Exchange rate types separate rates by purpose – valuation, conversion, translation, planning. The most common are M (average rate, used for posting and clearing), G (bank buying rate) and B (bank selling rate). Rates are maintained per exchange rate type and currency pair, with a validity date, in table TCURR.

Translation ratios

Before rates can be entered, the translation ratio (e.g. 1:1 or 1:1000) for each exchange rate type and currency pair must be maintained. Normally this is a one-off job, but because inflation can change the relationship, ratios are time-dependent.

Tools that reduce maintenance

Only one tool can be used per exchange rate type, but different types may use different tools. The efficient combination recommended by the course: base currency for the average rate type M, spreads for B and G. Rates can also be loaded automatically: report RFTBFF00 imports market data files (MultiCash format), and RFTBDF07 / RFTBDF14 use a datafeed interface with RFC for real-time transfer.

Direct and indirect quotation

With local currency EUR and foreign currency USD:

• Direct quotation: 1 USD = 1.2663 EUR – the price of one unit of foreign currency in local currency.
• Indirect quotation: 1 EUR = 0.7897 USD – the price of one unit of local currency in foreign currency.

The quotation setting applies system-wide, not per application or country. Per currency pair you declare one quotation as the standard; a rate entered in the other quotation is highlighted. Prefixes distinguish the two during entry and display:

SAP Note 783877 collects FAQs on currency translation.

Worklists for exchange rate maintenance

When many people maintain TCURR, problems arise: wrong rates, wrong quotation, long scrolling in a huge table, and the table cannot be edited by several users at the same time. Since SAP R/3 Enterprise you can define worklists and maintain them with transaction TCURMNT: each worklist shows only the relevant rates and quotation, can be protected by authorizations, is small and clear, and different worklists can be processed in parallel.

Unit 2: Master Data

Lesson 1: Maintaining General Ledger (G/L) Accounts

Understand how a chart of accounts and its account groups structure G/L master data, how the chart-of-accounts and company-code segments work together, and how to control, create and mass-change G/L accounts, including group and country charts of accounts.

The chart of accounts

A chart of accounts is a variant (define → values → assign) that holds the structure and the basic information of all G/L accounts. It is identified by a four-character key and defined with:

Every company code must have exactly one chart of accounts assigned, but – variant principle – one chart can serve many company codes. FI and CO share the chart, so company codes that do cross-company-code controlling must use the same operational chart (in the course example CC1000 and CC2000 can, CC2000 and CC3000 cannot). Useful reports: RFSKPL00 (G/L account list of a chart), RFSKVZ00 (account directory with chart and company code data), RFSKTH00 (account assignment manual with the account texts).

Two segments of a G/L account

A G/L account consists of a chart of accounts segment and one company code segment per company code that uses the account. The chart segment is entered once and is valid for every company code; it holds the account number, short and long text, control fields (account group, P&L/balance sheet indicator, P&L statement type), consolidation fields (group account number, trading partner) and texts managed by text ID and language. It can be translated so that the account name appears in the user's logon language. Keywords support searching.

The company code segment adds the data that governs posting and account management in that company code: account currency, tax category, reconciliation account indicator, line item display, sort key, field status group, house bank, interest calculation data. Because the number and name live in the chart segment, an account keeps the same number and name in all company codes, while each company code can set its own control data (e.g. tax category on in one company code and off in another). A company code that does not need an account simply creates no segment for it; another company code in the group may use the same number for, say, a foreign-currency balance sheet account.

The layout of the master-data tab pages (number of tabs, titles, field groups and their position, separate layouts for central, chart-specific and company-code-specific processing) is configurable; SAP delivers layouts that can be copied and assigned to a chart or account group.

Balance sheet versus P&L accounts

The chart segment declares the account type, which decides what happens at balance carryforward:

With only one retained earnings account the system fills the key automatically when a P&L account is created; with several, the user must choose one per P&L account.

Account groups

Accounts of the same kind (cash, material, asset, P&L…) are gathered into account groups. The account group is a required field in the chart segment and does two things: it carries a number range so that accounts of one type share a number interval (G/L intervals may overlap), and it controls the field status of the company code segment, i.e. which fields appear when a company code segment is maintained. Example: force line item display to required for the cash-account group so every cash account shows its line items. SAP delivers predefined groups; IMG: Financial Accounting (New) → General Ledger Accounting (New) → Master Data → G/L Accounts → Preparations → Define Account Group (OBD4).

Field status of G/L master data

Each field (or field group, e.g. the three interest-calculation fields) can be Hide (not used), Display (visible but unchangeable), Required or Optional. Account currency and field status group are always required and cannot be changed. Even a hidden field may still hold a value that takes effect.

The field status is normally driven by the account group; a second, transaction-dependent layer (Define Screen Layout for Each Transaction: Create, Change, Display) is used mostly to protect fields after creation – e.g. set the currency of a GBP cash account to Display in the Change transaction. When the two layers disagree the higher priority wins, in the order Hide > Display > Required > Optional. In a Display transaction fields can only be displayed or hidden. Setting a layer to Optional everywhere effectively switches it off, because Optional always loses.

Reconciliation accounts

A reconciliation account is a G/L account that collects the postings of a subledger (customers = receivables, vendors = payables, also assets). Every posting to a subledger account is simultaneously written to its reconciliation account, so the general ledger is always complete and in balance with the subledgers. The account type is set in the field Reconciliation account for account type in the company code segment and the account then serves only that type. Direct postings to a reconciliation account are not possible.

Line item display and open item management

Transaction figures are the debit and credit totals of an account; the balance is their difference. The Line item display flag (company code segment) decides whether only totals are updated (user sees the balance only) or whether the key data of each line item is additionally written to an index table so items can be listed online. Because this costs storage and time, use it only where no other view of the items exists; report RFSEPA01 activates it retroactively. In New G/L this flag only concerns the entry view; in the general ledger view line items of all accounts are always visible, because the subledger alone cannot explain the ledger (e.g. profit center and segment created by document splitting exist only there).

Open item management makes every item either open or cleared, which is the prerequisite for checking that a transaction has an offsetting entry; open and cleared items can be listed separately. It requires line item display, can be switched on or off only when the balance is zero, and is typical for bank clearing, GR/IR clearing and salary clearing accounts. If OI management is set up per ledger, ledger-group-specific clearing is available.

Account currency

Ways to create and change G/L accounts

• One-step (centrally): chart and company code segment together – FS00.
• Two-step: chart segment first (FSP0), company code segment afterwards (FSS0).
• Copy: create with reference to another account; copy a whole company code segment to another company code; copy an entire chart of accounts including account determination; copy the financial statement version.
• Data transfer: program RFBISA00 and batch input interfaces, adapted by the ABAP team, for migrating charts of accounts.
• Collective processing (OB_GLACC11/12/13): change chart data, company code data or descriptions of many accounts at once, even across charts, by selecting the fields and entering a new value that replaces the old one. Check carefully – changes take effect on saving and can have wide consequences.

Group chart of accounts and country chart of accounts

Multinational groups often need a consolidated statement although some company codes must use legally prescribed local charts. Two solutions:

Course scenario: European company codes (Spain, Germany, UK) use INT, US and Canada use CAUS, so controlling works within each region; country charts serve local reporting and group chart CONS consolidates INT and CAUS.

Lesson 2: Creating Profit Centers and Segments

Learn what the segment characteristic is for, how it is derived from the profit center, what to do when derivation is impossible, and how segments can be reorganized.

The segment characteristic

The segment is a standard FI account assignment object below the company code, designed to analyse business activity areas such as markets or products and to satisfy the segment reporting rules of IFRS 8 and US GAAP. Business area and profit center could also be used, but both were historically used for other purposes, so SAP added the segment as a clean object. IFRS 8 describes a business segment as a part of the company that earns revenues and incurs expenses (including internal ones), whose results are regularly reviewed by the chief decision-maker for resource allocation, and for which separate financial information exists.

Deriving the segment

The standard derivation is to store a segment in the profit center master record: every posting to the profit center then automatically carries the segment; a profit center without a segment produces no segment posting. SAP Note 1035140 states the rules: segments are officially supported only together with profit centers; automatic derivation works only via profit centers; in many logistics transactions a segment cannot be entered manually; and various standard interfaces ignore segments. When derivation from the profit center is not possible, New G/L with document splitting offers manual entry, the BAdI FAGL_DERIVE_SEGMENT, substitution rules, or assignment via standard accounts. Profit Center Accounting originated in CO but, because of its importance for external reporting, now lives in FI (New G/L); management must decide whether it serves internal or external accounting.

Reorganizing segments

Changing the segment of profit centers (e.g. moving profit centers 1 and 3 to a new segment SEGA) touches far more than the profit center master: G/L totals of open-item-managed accounts, receivables, payables and asset reconciliation totals, asset master records and allocation cycles all carry the old segment. The Reorganization of Segments function supports and executes such re-assignments, including merging segments, with two roles: the reorganization manager (chief accountant/central controller) who owns the plan, and the object list owners (FI/CO accountants) who process their objects.

Master data transactions

Lesson 3: Managing Customer and Vendor Accounts

Learn the segment structure of customer and vendor master records, central versus decentral maintenance, account groups and number ranges, one-time accounts, the three competing field status layers, and dual control with sensitive fields.

Structure of customer and vendor master records

Like G/L accounts, subledger accounts are segmented, but with three levels:

Reports RFBIDE10 (customers) and RFBIKR10 (vendors) copy master data from one company code to another.

Central versus decentral maintenance

Master records can be maintained centrally (all segments in one transaction, e.g. XD01/XK01) or decentrally (FI maintains its data with FD01/FK01, SD/MM maintain theirs). Which to choose is an organizational decision; the AR and SD teams (or AP and MM teams) must agree on configuration and ownership. Decentral creation increases the risk of incomplete or duplicate records: run RFDKAG00 (customer master comparison) or RFKKAG00 (vendor master comparison) to find and fix incomplete accounts, use the match code before creating, and activate the automatic duplicate check.

Important fields

• Search terms – abbreviations of the name according to company conventions.
• Group key – user-defined key to collect partners belonging to one corporate group; usable in reports, processing and match codes.
• Accounting clerk – ID whose name is printed on correspondence and used to sort dunning and payment proposal lists.
• Explanatory text in every segment.
• Line item display and open item management are standard for every customer/vendor account.

Creating with reference copies only partner-independent data (not the address, for instance); SAP suggests one reference account per account group. The initial screen lets you jump directly to any tab of a segment.

Account groups and number ranges

The account group is entered on the initial screen and, in FI, cannot be changed afterwards (SD partner roles allow some changes, e.g. ordering address to ship-to). Customer and vendor number ranges are separate and must not overlap. Each range is internal (system assigns the next free number; current number can be displayed) or external (user assigns, may be alphanumeric, not sequential, so no current number). One number range may be assigned to several account groups. IMG: Financial Accounting (New) → Accounts Receivable and Accounts Payable → Customer/Vendor Accounts → Master Data → Preparations for Creating … → Define Account Groups with Screen Layout (OBD2 customers, OBD3 vendors) and Assign Number Ranges to … Account Groups.

One-time accounts

For partners you deal with rarely, create a one-time customer or vendor master record (special account group). It holds no partner-specific data – those fields are hidden – because many partners share it; name, address and bank details are typed into the document at posting time.

Three layers of field status

The three definitions compete and the highest priority wins: Suppress > Display > Required > Optional. Display transactions only display or suppress. Set a layer to Optional to let the account group decide. The transaction-dependent layout is not company-code specific.

Dual control with sensitive fields

Under the dual control principle one person changes critical master data and another confirms it. In Customizing (Define Sensitive Fields for Dual Control) you list the sensitive fields, e.g. ADRC-SORT1 (search term 1) or bank data; the definition is client-wide, not per company code. When a sensitive field is changed the account is blocked for payment until an authorized user confirms or rejects the change – singly (FK08 / FD08) or from a list (FK09 / FD09) that can be restricted by account, company code, and status (not yet confirmed, rejected, to be confirmed). Change history for all accounts: RFDABL00 (customers), RFKABL00 (vendors).

Unit 3: Document Control

Lesson 1: Configuring the Header and Line Items of Financial Accounting (FI) Documents

Learn the document principle, the two control keys of an FI document (document type for the header, posting key for the line items), document number ranges, and how field status groups and variants decide which fields appear during document entry.

The document principle

SAP ERP posts every business transaction as a document that stays in the system as a complete unit until it is archived. A document is uniquely identified by document number + company code + fiscal year. It consists of a header (data valid for the whole document, e.g. dates, document type, currency, reference, header text) and 2 to 999 line items. Logistics components post through the AC interface, which creates accounting line items that are nearly identical in most fields; SAP Note 36353 explains how to summarize such documents.

One business transaction may create several documents: a goods receipt produces a material document (inventory data) and an accounting document (accounts and amounts). Other transactions, such as a purchase order, create no accounting document at all because they do not touch accounting. Related documents are linked so that the whole business process can be traced. Reports: RFBELJ00 compact document journal (key header and item data of selected documents); RFBUEB00 / RFBUEB01 to locate documents; RFBNUM00 to find gaps in document numbering.

Document types

The document type classifies business transactions and controls the header. It is defined at client level, so it applies to all company codes; SAP delivers types that can be copied or changed. IMG: Financial Accounting (New) → Financial Accounting Global Settings (New) → Document → Document Types → Define Document Types for Entry View (OBA7).

Important standard types: AB allows all account types; the others should be restricted (e.g. DG customer credit memo posts only to D and S). RV is the default for SD billing documents and RE for MM invoice verification; with external numbering the billing document number is passed on as the FI document number if still free. The payment program posts most of its documents with type ZP. Other common types seen in the course: SA (G/L document), KR (vendor invoice), KG (vendor credit memo), DR (customer invoice), DZ (customer payment), KZ (vendor payment).

Document number ranges

Number ranges are defined per company code and must not overlap. IMG: Document → Document Number Ranges → Documents in Entry View → Define Document Number Ranges for Entry View (FBN1).

One number range may be shared by several document types. Intervals can be copied from one company code to another or from one fiscal year to the next. New G/L specific: if non-leading ledgers use a different fiscal year variant, separate number ranges (internal assignment only) are kept for the general ledger view and assigned under Define Document Types for Entry View in a Ledger / Define Document Types for General Ledger View.

Posting keys

The posting key is the line-item control key, also client-wide. It determines the account type to which the item posts, whether the item is a debit or credit, and the field status of the line item; additionally it flags whether the item is payment-related (for payment history and payment notices) and sales-relevant (updates the sales figures of a customer, e.g. a customer invoice). SAP recommends keeping the standard keys; changing them means updating every table that references them, and asset/material keys work only if those components are configured.

Because subledger accounts have no field status group, their postings are differentiated through many different posting keys (01–19 customers, 21–39 vendors, 70/75 assets, 89/99 materials). G/L postings are differentiated by field status groups instead, so 40 and 50 are sufficient.

Document field status: field status groups and variants

Which fields appear during document entry depends on the transaction and the account: an expense item needs cost center and tax data, a cash item does not. SAP divides the entry fields into groups and defines per field status group whether each field is hidden, required or optional. Field status groups are collected in a field status variant, which is assigned to the company code(s) (Ledgers → Fields → Define Field Status Variants, OBC4; Assign Company Code to Field Status Variants, OBC5); no posting is possible until the variant is complete, and normally all company codes share one variant. Each G/L account carries a field status group in its company code segment (e.g. G001 general, G004 cost accounts, G005 bank accounts); copy and adapt the delivered groups. For postings to subledger accounts the field status group of the reconciliation account applies.

The field status of the posting key and of the field status group are combined and the higher priority wins (Hide > Display > Required > Optional), with two exceptions: the business area field is made ready for input by activating business area financial statements in the company code (field status can then only choose required/optional), and tax fields are only enterable for tax-relevant accounts. Combining Hide with Required produces an error.

Lesson 2: Managing Posting Periods

Learn how the posting period variant opens and closes periods per account type and account interval, how the two (three) period intervals and authorization groups work, and how the system derives the period from the posting date.

Open and closed periods

The fiscal year variant defines the periods; the posting period variant decides which of them are currently open. Normally only the current period is open and all others are closed; at period end the old period is closed and the next one opened by adjusting the ranges. Any number of periods may be open, and during year-end closing the special periods are opened for closing entries. Following the variant principle, one posting period variant can be assigned to many company codes, which are then opened and closed together.

IMG: Financial Accounting (New) → Financial Accounting Global Settings (New) → Ledgers → Fiscal Year and Posting Periods → Posting Periods → Define Variants for Open Posting Periods (OBBO), Open and Close Posting Periods (OB52), Assign Variants to Company Code (OBBP).

Checks by account type

If all account types should be treated alike, the + line is enough. Otherwise periods can differ by type – e.g. customers open while vendors are already closed. The account interval (from/to account) always refers to G/L accounts; for subledger types you enter reconciliation accounts, so customers or vendors with a particular reconciliation account can be treated differently from the rest.

Period intervals and authorization

During closing two periods must be open simultaneously, therefore each line has two period intervals. Interval 1 can be protected by an authorization group: only users holding authorization object F_BKPF_BUP with that group value may post in it. Use interval 1 for the special periods and give the authorization only to the closing accountants. New G/L adds a third interval that governs FI postings triggered by the real-time integration CO → FI; if it is empty, intervals 1 and 2 apply to those postings as well. New G/L also allows opening and closing periods for individual account assignment objects (e.g. keep profit center 1000 open while profit center 2000 is closed) in the Customizing section Opening and Closing Posting Periods by General Ledger Account Assignment Objects.

Determining the period

At entry the user types the posting date; the system derives posting period and fiscal year from it using the fiscal year variant, checks the posting period variant, and updates the transaction figures of that period. The account balance display shows the figures per period.

Lesson 3: Managing Posting Authorizations

Learn how tolerance groups for employees cap the amounts and cash discounts a user may post and how users are assigned to them.

Tolerance groups for employees

In Financial Accounting Global Settings (New) → Document → Tolerance Groups → Define Tolerance Groups for Employees (OBA4) you define, per company code and group, the upper limits that apply when posting and clearing:

Assigning users

Create as many groups as needed and assign users explicitly in Assign User/Tolerance Groups (OB57). Every company code must have the blank tolerance group: it holds the limits valid for all users without an explicit assignment, i.e. the typical employee. Users with unusually high or low limits get a named group (e.g. SUPV) attached to their user ID. This is another instance of the variant principle: define the group, fill in the values, assign it to users.

Lesson 4: Creating Simple Documents in FI

Learn the single-screen Enjoy posting transactions for G/L documents, customer and vendor invoices and credit memos, and the aids (templates, held documents, text keys) they offer.

The Enjoy posting screen

One screen design serves G/L account postings (FB50), customer invoices (FB70) and credit memos (FB75), and vendor invoices (FB60) and credit memos (FB65). The screen has three areas:

1. Header (tabs Basic data, Payment, Details…): invoice/document date, posting date, reference, text, currency, amount, Calculate tax flag and tax code; for AR/AP transactions also the business partner, whose name, address and bank data appear after Enter, with an Open items button to list the account's open items. The frequently used fields are on the first tab, the rarer ones on the other tabs.
2. Information area showing the account balance.
3. Line item table at the bottom: G/L account, debit/credit indicator (S/H), amount, tax code, text, cost center/profit center…; the account name appears after confirmation; columns can be resized and reordered, items copied.

A document type can be defaulted per Enjoy transaction in Customizing and overwritten if the field is enterable; without a default the standard types are proposed (KR for vendor invoices, DR for customer invoices, SA for G/L). If the document type field is missing, change Editing options → Doc.type option to "Entry with short name". The tree on the left offers screen variants, account assignment templates and held documents. When the balance is zero the document can be posted, parked (saved incomplete, no transaction figures) or held (temporarily saved without document number). Document → Simulate shows the full document including tax lines before posting. The classic complex posting transactions (F-02, F-22, F-43…) remain available via the menu, but you cannot jump from them into the Enjoy screen.

Line item text

Each item can carry an explanatory text. A leading asterisk * marks the text for external use (correspondence, dunning notices, payment advices); the asterisk itself is dropped on the printout. Four-character text keys defined in Customizing expand automatically into predefined text templates when typed in the text field.

Unit 4: Posting Control

Lesson 1: Analyzing Document Splitting

Understand the entry view and general ledger view of a New G/L document, how document splitting produces zero balances for profit center or segment, the passive/active/zero-balance steps, and the Customizing behind it.

Two views of a document

In New G/L every FI document has a data entry view (how the creator entered it and how it appears in the subledgers) and a general ledger view (how it is stored in the leading and non-leading ledgers). Both views always exist; this cannot be switched off. Classic G/L has only one view, which corresponds to the entry view. Without document splitting both views are identical.

What document splitting does

Document splitting (also called online split) distributes line items that carry no reporting characteristic – typically the vendor/customer line and the tax line – according to the lines that do carry one (the expense or revenue lines), so that every characteristic such as profit center, segment or business area balances to zero within the document. This is what makes a complete balance sheet below company code level possible. In the course figure a vendor invoice with two expense lines (accounts 477000 and 417000, different profit centers/segments) is shown: in the general ledger view the vendor and tax lines are split proportionally to the two expense lines. The split is visible only in the general ledger view; the entry view still shows the original unsplit lines. Document splitting is only for companies that need (or want) an additional reporting dimension on the balance sheet.

The three steps

Customizing

IMG: Financial Accounting (New) → General Ledger Accounting (New) → Business Transactions → Document Splitting.

• Splitting method: SAP delivers 0000000012; copy it to a Z version (e.g. Z000000012) before changing rules.
• Classify G/L accounts for document splitting (item categories such as expense, revenue, customer, vendor, tax) and classify document types (business transaction, e.g. 0200 customer invoice, 0300 vendor invoice, and variant 0001).
• Activate document splitting: activation is per client; deactivation is per company code; nevertheless the decision to split is made at company code level, and all company codes of a client share one splitting method.
• Inheritance: if an account assignment is unique in the document, it is inherited by all lines that have none – always switch it on.
• Default account assignment: a constant (defined first in Customizing) fills a characteristic when nothing is entered or derived. Convenient but risky: it masks wrong splitting rules, so test without the constant first.

SAP Note 1085921 documents splitting in detail; splitting can be introduced later only by migrating existing data (migration scenario 6). Note 891144 warns that once active, splitting settings cannot be changed or corrected by program because the information is spread over FAGLFLEX* totals/object tables and FAGL_SPLINFO.

Lesson 2: Maintaining Default Values

Learn the user-level and company-code-level defaults that cut repetitive input during posting: parameter IDs, editing options, user settings, proposed document types/posting keys, proposed fiscal year and value date, and the maximum exchange rate deviation.

User-specific defaults

• Parameter IDs in the user master (SU3, tab Parameters) pre-fill fields that rarely change, e.g. company code (BUK) or currency, reducing input errors.
• Editing options (FB00 or the Editing options button): for document entry you can hide fields you do not need (foreign currency, cross-company code) and set options for the Enjoy screens, e.g. whether the document type is hidden, displayed or entered as short name; for document display you choose List Viewer layouts; for open item processing you choose line layouts and posting options such as partial payment or residual item.
• User defaults: logon language, date format, decimal notation, default printer. To simplify administration, create a dummy user with the accounting department's settings and copy it for new users.

System and accounting defaults

• The current date is proposed as posting date; the company code of the last document is proposed for the next one; a document must balance to zero before posting.
• Each business transaction proposes a document type and posting key – e.g. vendor invoice: KR with credit posting key 31.
• Propose fiscal year (company code setting): when displaying/changing documents in a company code with year-dependent numbering, the last document number and fiscal year are proposed.
• Propose value date (Document → Default Values → Default Value Date): the CPU date is proposed as value date – needed for Cash Management.
• Maximum exchange rate deviation (Global Parameters for Company Code → Currencies → Maximum Exchange Rate Difference → Define Maximum Exchange Rate Difference per Company Code): if the rate entered in the document header deviates from the rate in the exchange rate table by more than this percentage, a warning flags a probable input error.

Lesson 3: Configuring Change Control

Learn which fields of a posted document may still be changed, how document change rules are defined, and how changes are logged and reported.

What can be changed

A posted document can be changed (FB02), but only in fields that do not affect the accounting substance. Changeable by default: in the header the reference and header text; in the line items the assignment, text and payment terms (and other payment-related fields such as payment block or dunning data). Amount, posting key, account and anything else that influences reconciliation can never be changed – that requires a reversal. Every change is logged with field, old and new value, user, date and time; report RFBABL00 lists document changes, selectable by company code, document number, fiscal year, change date and user.

Document change rules

IMG: Financial Accounting Global Settings (New) → Document → Rules for Changing Documents → Document Change Rules, Line Item (and Document Header). A rule is defined per field name (e.g. BSEG-ZUONR) and differentiated by:

For each rule the flag Field can be changed is set or not, and additional stipulations can restrict the change to cases where: the posting period is still open; the item is not yet cleared; the item is a customer debit or vendor credit (i.e. an invoice-like item); the document is not an invoice-related credit memo; and not a credit memo from a down payment.

Lesson 4: Configuring Document Reversal

Learn how to reverse incorrect documents individually or en masse, the difference between normal reversal and negative posting, and the role of reversal reasons.

Reversal basics

Errors are corrected by reversing the wrong document and posting it again correctly; this keeps a full audit trail. The reversal functions (FB08 individual, F.80 mass reversal; FBU8 for cross-company code documents) work for G/L, customer and vendor documents. A reversal reason must always be entered; the reason also controls whether the reversal date may differ from the original posting date (otherwise the original posting date is used). A document containing cleared items cannot be reversed until the clearing is reset (FBRA). The document type used for the reversal comes from the reverse document type of the original document type.

Normal reversal versus negative posting

Negative postings can also be used for transfer postings of wrongly assigned items: the item is removed from the wrong account by a negative posting (figures reset) and posted to the right account normally – but only with a document type that explicitly permits negative postings.

Lesson 5: Configuring Payment Terms and Cash Discounts

Learn how terms of payment determine due dates and cash discounts, where they are defaulted from, how day limits and installments work, and how cash discounts are posted under the gross and net procedures.

Terms of payment

Terms of payment are the conditions agreed with a business partner: the due date and the cash discount granted for payment within certain periods. From a baseline date, the discount terms (days) and discount percentages the system calculates due date and discount. SAP delivers terms (e.g. 0001 immediately due, 0002 14 days 3 % / 30 days 2 % / 45 days net) and you can add your own in Accounts Receivable and Accounts Payable → Business Transactions → Incoming Invoices/Credit Memos → Maintain Terms of Payment (OBB8).

Terms stored in the master record are defaulted at posting and may be overwritten. Where they come from depends on where the invoice originates:

For a vendor invoice a fixed cash discount amount or percentage can be entered in the Cash discount field, independent of the payment date. Credit memos: an invoice-related credit memo (invoice number in Invoice reference) inherits the invoice's terms and is due with it; for other credit memos the terms are ignored and the memo is due on the baseline date – unless you enter V in the invoice reference field to activate the terms.

Fields of a payment term

Block key and payment method can be set during posting, in the company code segment of the master record, or in the payment term.

Day limits and installments

Day limits create two-part terms under one key, e.g. invoices dated up to the 15th are due at the end of the following month, invoices after the 15th on the 15th of the month after next – two entries with day limits 15 and 31. Installment payments split an invoice into partial amounts with different due dates: flag the term as installment (no discount data), then define each installment with number, percentage (must total 100 %) and its own payment term. The system creates one line item per installment with the respective term.

Cash discount base and posting procedures

Depending on national law the cash discount base is the net amount (G/L and asset items without tax) or the gross amount (including tax, e.g. Germany, Switzerland); this is set per company code (or highest jurisdiction level) in the global parameters.

Lesson 6: Maintaining Taxes and Tax Codes

Learn which tax systems SAP ERP supports, how the tax calculation procedure, tax codes, rates and account keys work together, and how tax accounts and tax categories on G/L accounts are set up.

Tax systems and types

SAP ERP handles taxes on sales and purchases (VAT), US sales and use tax, country-specific additional taxes (investment tax in Norway, clearing tax in Belgium) and withholding tax. Rates may be defined nationally (uniform) or at state/jurisdiction level; the US has more than 67,000 jurisdictions, so external tax software is often connected through SAP's generic interface. Some countries (Canada, India, Brazil) tax on both levels. The system checks or calculates the tax amount, posts it to tax accounts, and adjusts tax for cash discounts and other deductions. The tax base is the expense/revenue amount, taken gross (including cash discount) or net (after cash discount) as national law requires, set per company code or top jurisdiction level.

Tax calculation procedure

Every country has a preconfigured tax calculation procedure (e.g. TAXD, TAXUSJ with jurisdiction codes, TAXUSX for an external tax package) assigned to the country. It consists of:

• a sequence of steps, each with a from step telling where its base value comes from;
• tax types (condition types, e.g. MWS output tax, VST input tax) valid for the country; the condition type decides whether the base is "percentage included" or "percentage separate";
• account keys (transaction keys, e.g. MWS, VST, NVV) used for automatic account determination – use the delivered keys.

Tax codes and rates

The tax code entered in the document links the item to the calculation procedure. It belongs to a country key, or to country + jurisdiction code in jurisdiction-based countries, where codes are also date-dependent (document or posting date can be chosen as the valid date). IMG: Financial Accounting Global Settings (New) → Tax on Sales/Purchases → Calculation → Define Tax Codes for Sales and Purchases (FTXP): properties (name, tax type A output / V input, check indicator), the rate per tax type, and the tax accounts per chart of accounts. Usually one rate is entered; several rates appear for example when 10 % input tax is 40 % non-deductible – 6 % deductible input tax plus 4 % non-deductible. Zero-rate codes are needed for tax-exempt items that must still be reported and for tax-exempt transactions such as goods issues. The check indicator turns a deviation between calculated and entered tax into an error instead of a warning; it is not set for input tax codes because the amount from the vendor's invoice must be posted as printed.

Tax postings and account determination

Normally the calculated tax is posted as a separate line to a tax account. For certain account keys (e.g. NVV, non-deductible input tax or sales tax payables) the tax is distributed onto the expense or revenue lines instead. Automatic account determination (Posting → Define Tax Accounts, OB40) assigns to each account key the tax account(s), the posting keys (40/50 recommended) and the rules (whether determination depends on tax code and/or account key). Exchange rate differences from tax adjustments in foreign currency normally go to the regular exchange rate difference account; per company code you can instead let the tax exchange rate be entered manually or taken from posting/document date and post the resulting difference to a special account.

Tax category on G/L accounts

Tax accounts usually get Post automatically only. Posting without tax allowed permits posting to a tax-relevant account without a code – required for foreign customers without jurisdiction code. Cash discount accounts need a tax category so that tax adjustments can be posted.

Lesson 7: Posting Cross-Company Code Transactions

Learn how one business transaction spanning several company codes is posted as linked documents with automatic clearing lines, how clearing accounts are configured, and how tax is handled.

Concept

Cross-company code transactions occur with central procurement (one company code buys for others), central payment (one pays for others) or intercompany sales. Since a document belongs to exactly one company code, the system creates one document per company code and inserts automatically generated lines on clearing accounts (receivable/payable between the companies) so that each document balances. All documents share a cross-company code transaction number built from the first document number + first company code + fiscal year, stored in every header for the audit trail. Display with FBU3, reverse with the dedicated cross-company reversal FBU8, report with RFBVOR00.

Clearing accounts

IMG: General Ledger Accounting (New) → Business Transactions → Prepare Cross-Company Code Transactions (OBYA). For each pair of company codes you define the clearing account and posting key for receivables (debit) and payables (credit) in both directions; the clearing account can be a G/L account, a customer or a vendor account (the posting key identifies the type). Every possible pair needs an entry: three company codes need 3 × 2 = 6 assignments; with a designated clearing company code only 2 × 2 = 4 are needed.

Tax in cross-company code postings

Course example: a vendor delivers goods to company codes 1000 and 2000 but invoices only 1000. The invoice is entered in 1000 with part of the expense in 2000; clearing and tax lines are generated automatically. The whole tax is posted to the company code of the first line item – so enter the vendor/invoice item first – and is not split by expense. Use the function only if the transaction is not tax-relevant or the company codes form one taxable entity; in countries such as Japan or Denmark where tax must sit where the expense arose, distribute it afterwards with report RFBUST10.

Lesson 8: Configuring Real-Time Integration

Learn how New G/L replaces the periodic reconciliation ledger with real-time CO→FI integration, how to define and assign an integration variant, and how to trace the follow-on documents.

Concept

Many CO postings (repostings, assessments, distributions, activity allocations) change FI-relevant characteristics – profit center, segment, business area, functional area – or move costs between company codes. In classic G/L these were reconciled periodically through the reconciliation ledger; in New G/L real-time integration CO→FI posts a follow-on FI document immediately for each CO document, giving valid ad-hoc reporting and governance transparency. It only works if the CO-relevant entities are present in FI (e.g. functional area derivation for cost-of-sales accounting, scenarios assigned to the ledgers). Cases: postings between CO objects with different FI characteristics, and cross-company-code cost postings.

Variants for real-time integration

IMG: Financial Accounting Global Settings (New) → Ledgers → Real-Time Integration of Controlling with Financial Accounting → Define Variants for Real-Time Integration, then Assign Variants for Real-Time Integration to Company Codes.

The follow-on document

One FI document is created in real time per CO document. It needs no clearing accounts unless the CO activity changes a balancing entity (then zero-balance lines are added). Navigation works in both directions between FI follow-on document and CO document. Trace analysis: FAGLCOFITRACEADMIN shows whether each document was transferred and in which mode (e.g. O = online posting). In the IDES system classic Profit Center Accounting is still active, so a separate profit center document is created as well.

Unit 5: Financial Document Clearing

Lesson 1: Performing Open Item Clearing

Understand the two clearing transactions (account clearing and post with clearing), the automatic clearing program, the assignment field as sort criterion, the manual payment screen, automatic clearing postings and the reset of clearing.

Open items and clearing

An open item is an incomplete business transaction, e.g. an unpaid invoice. A transaction is complete when a clearing posting brings a group of items to a zero balance; the items then carry the clearing document number and clearing date (today or a user-defined date). Documents with open items cannot be archived. Clearing always produces a clearing document. Typical flow: invoice posted (open) → customer pays and the payment is assigned to the invoice → both items cleared. Manual clearing is common for bank sub-accounts and clearing accounts, debit memo procedures, and vendor refunds.

Automatic clearing program

The clearing program (F.13 / F13E, SAPF124) clears G/L and subledger accounts automatically. It groups items of an account that agree in company code, account type, account number, reconciliation account, currency and special G/L indicator, plus up to five user-defined criteria from header or item (e.g. assignment, reference) configured per account type and account range in Prepare Automatic Clearing (OB74). Groups whose local-currency balance is zero are cleared with a clearing document. Not cleared: noted items, statistical postings and some bill-of-exchange special G/L transactions, down payments (unless matching down payment clearing items exist), and items with withholding tax.

The assignment field

The assignment (BSEG-ZUONR) is filled automatically according to the sort key in the master record (company code segment of the G/L account or business partner). It can combine up to four fields with a total of 18 characters, e.g. document number (10) + posting date (6). Sort key = purchase order number fills the partner item with the PO number; sort key = cost center fills G/L items with the cost center. Line item display and clearing sort by this field, which is why the clearing program often groups on it. For SD billing, reference and assignment of the billing document (configurable: PO, order, delivery or billing number) are copied into the FI document, so the originating sales document can be traced and used as selection criterion.

Manual payment process

A manual payment clears open items by hand: an incoming payment (AR) clears an open debit, an outgoing payment (AP) an open credit. Three steps: enter the header, select the open items, save. The header has three parts:

On the Process open items screen all unassigned items (invoices, credit memos, payments) are listed, active or inactive according to the editing options (Selected items initially inactive). The document can be posted when Amount entered equals Assigned (not assigned = 0). The cash discount is proposed from the item's payment terms and may be overwritten as amount or percentage within the tolerance limits. Simulate to see automatic lines; if a mistake is found later: reset clearing, reverse, re-enter.

Automatic postings and cross-company payments

Clearing triggers automatic postings for tax adjustments on cash discounts, bank charges and exchange rate differences; their accounts come from the account determination seen earlier. For manual cross-company-code payments, assign a clearing transaction (incoming/outgoing payment) to the pair paying company code / company code paid for; the open items of both company codes are then offered for selection.

Resetting clearing

FBRA resets the clearing of a single clearing document: the clearing data is removed from the items, which become open again; the change is logged in change documents; in AR the payment history and credit limit are corrected. Optionally the clearing document can be reversed in the same step.

Lesson 2: Managing Payment Differences

Learn the three tolerance group types, how permitted payment differences are evaluated, and how differences outside tolerance are handled as partial payments, residual items or write-offs with reason codes.

Three kinds of tolerance groups

Permitted payment differences

Both the employee group and the customer/vendor group contain limits for cash discount adjustment and for unauthorized deductions (revenue/expense from over-/underpayment), each as an amount and – for deductions – also a percentage; all in local currency. A difference is posted automatically only if it lies within both groups; the lower limit always wins. Course example: a difference below 3.00 (employee) and 2.00 (customer) is written off as cash discount adjustment; a difference below 200 / 100 currency units and below 2.5 % / 2.0 % is written off as unauthorized deduction – so for an open item of 1,000 the cap is 20 (2 %), for 100,000 it is 100 (the amount cap).

Processing differences

When an open item is cleared with a difference the system compares the difference with the tolerances. Inside tolerance it is posted automatically as cash discount adjustment or as unauthorized deduction to the account defined for the difference. Outside tolerance the user must decide:

Reason codes

Reason codes (Incoming Payments Global Settings → Overpayment/Underpayment → Define Reason Codes, OBBE, per company code) describe why a difference occurred and can be attached to difference postings, partial payments and residual items; Distribute difference lets you split a difference over several reason codes. Optional functions of a reason code: control the type of payment notice sent to the customer; determine the G/L account to which the difference is posted automatically (flag "charge off via separate G/L account", accounts in OBXL); exclude disputed residual items from the credit limit check. Reason codes also support analysis and follow-up of differences.

Lesson 3: Managing Exchange Rate Differences

Understand how realized exchange rate differences arise when foreign-currency open items are cleared, how they interact with valuation at period end, and how gain/loss accounts are determined.

Realized differences at clearing

When an open item in foreign currency is cleared at a different rate than it was posted, the local-currency amounts differ. The system posts this realized exchange rate difference automatically to a gain (revenue) or loss (expense) account defined in Customizing and stores the realized difference in the cleared line item. If the item had already been valuated for the financial statements (foreign currency valuation at period end posts the unrealized gain/loss to a balance sheet adjustment account and an expense/revenue account), the clearing first reverses the adjustment-account posting and then posts the remaining difference as realized gain or loss.

Account determination

Every reconciliation account and every G/L account with open items in foreign currency must have gain and loss accounts assigned for realized differences (General Ledger Accounting (New) → Periodic Processing → Valuate → Foreign Currency Valuation → Prepare Automatic Postings for Foreign Currency Valuation, OBA1, transaction KDF). The granularity of the assignment can be:

In the same place the accounts for unrealized valuation differences (balance sheet adjustment account, valuation gain/loss) are maintained, which is why the clearing can reverse the valuation correctly.

Unit 6: SAP Simple Finance Add-on for SAP Business Suite powered by SAP HANA

Lesson 1: Outlining the Benefits of the SAP Simple Finance Add-On

Understand the in-memory vision behind SAP HANA, the business benefits it brings to FI and CO, the new unified FI/CO architecture of the Simple Finance add-on, and the migration paths from classic or New G/L.

The SAP HANA vision

Classic landscapes keep three copies of the data – a transaction layer (OLTP), an analysis layer (OLAP/BW) and an acceleration layer – each with its own data model. This creates silos, latency and reconciliation work. SAP HANA aims at one in-memory, column-oriented database for both OLTP and OLAP: a single copy of the data, less hardware, no replication latency, and faster processes and analyses. To get the full benefit, developers must change paradigm: instead of reading data into the application server and calculating there, calculations are pushed down to the database layer ("code-to-data").

Impact on Financials

The Simple Finance add-on

The add-on targets customers who want the HANA business benefits on premise (not in the cloud) on top of their existing SAP Business Suite powered by SAP HANA. It contains the new HANA-based SAP Accounting and Cash Management and tighter integration between ERP and BPC (Business Planning and Consolidation).

Problem with the classic architecture: FI line items (BSEG) and CO line items (COEP) were linked only at header level. Consequences: heavy reconciliation when granularity differs (e.g. payroll posts more FI than CO items), difficult reporting between FI and CO-PA, and no single report combining the legal view with responsibility or market-segment detail.

New architecture: the account becomes the leading dimension for both FI and CO views; FI dimensions (company code, business area, segment, profit center…) and CO dimensions (cost center, order, WBS element, product, customer, region…) are stored together on one combined line item. Results:

• Reduced reconciliation between FI and CO.
• A one-document view through the logical link of BSEG and COEP; drill-down from an aggregated P&L to line items by customer, product or region; detailed queries over all spend categories; journal entries linked to their source documents (sales order, material movement…); selection from roughly 400 fields thanks to HANA speed.
• Modern UIs, cockpits and embedded BI; harmonized internal and external accounting; faster closing and reporting; lower total cost of finance.

Note the ECC-to-S/4 lineage: Simple Finance 1.0 introduced the universal-journal idea (no totals tables, FI and CO converged) that later became ACDOCA in S/4HANA Finance.

Migration requirements

Key statements from the course: the migration to the G/L in SAP Accounting is short and can be done at any period end; a migration guide and monitor are provided and no SAP migration service is mandatory; changes to coding block, interfaces, security and reporting are optional; New G/L is not a prerequisite – classic G/L customers can migrate directly, their data is transferred automatically into the new structures, and EC-PCA and FI-SL may remain in place; the G/L in SAP Accounting offers the same capabilities as New G/L, reuses its data structures, and is optimized for HANA (better reporting, convergence with CO, no totals tables). Customers already running a New G/L migration project with a 2015 go-live should finish it first. The one hard prerequisite is that the ERP system already runs on the HANA database. Useful references: SAP Note 1976487 (adjusting customer programs to the simplified data model), help.sap.com/sfin100, the Administrator's Guide for Simple Finance Add-On 1.0.