TFIN52 Part 2 – Financial Accounting II (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: Special General Ledger Transactions

Lesson 1: Managing the Application View for Special General Ledger Transactions

Learn what a special G/L transaction is, how it differs from a normal subledger posting, which classes and types exist, and how to carry out down payments, guarantees and individual value adjustments from the application side (SAP ERP ECC).

Reconciliation accounts: the starting point

Every customer or vendor master record carries a reconciliation account in its company code segment. Whenever an invoice or credit memo is posted to the subledger (AR or AP), the system simultaneously updates the transaction figures of that reconciliation account in the general ledger. This is what lets you build a balance sheet directly from G/L balances without hunting through the subledger. The reconciliation account number is visible on each FI document.

Why "special" G/L transactions exist

Some AR/AP transactions must not be mixed with ordinary receivables and payables for goods and services, either for internal management reasons or for legal reporting (e.g. down payments received are liabilities, not reductions of receivables; guarantees made only belong in the notes). SAP solves this with a special G/L indicator entered on the line item: the posting still goes to the customer/vendor account, but in the G/L it is routed to an alternative reconciliation account (a "special G/L account") instead of the one in the master record. The transaction is therefore shown separately both in the subledger (filterable in line item display) and in the G/L.

Special G/L classes (what the transaction is about)

Special G/L types (how the posting technically behaves)

The special G/L indicator's configuration decides which of three posting mechanics is used. These types are often confused with the classes above, so keep them apart.

Noted items are managed as open items on the customer/vendor account and on the special G/L account, so line item display must be active on those accounts. The payment program and dunning program can both pick up noted items (a down payment request can be dunned or collected by direct debit).

Guarantees of payment (type 1 example)

You agree to stand surety for a customer for EUR 10,000. You post a "guarantee made" to the customer with the special G/L indicator; the system books it to the special G/L account "Guarantees of payment made" and automatically to the clearing account for guarantees made. When the liability ends you reverse the statistical posting. Guarantees made appear in the notes to the balance sheet; guarantees received (vendor side, indicator with account type K) are recorded the same way but are not reported. In the training system the guarantee goes to 196100 with automatic offset to 196110.

Down payment request (type 2 example)

A down payment request is a noted item reminding you (or the customer) that a down payment is due. No transaction figures change, so the customer balance is unaffected even though the item appears in the line item list. Customer requests let the payment program collect the amount automatically (requires collection authorization); vendor requests let the payment program pay the down payment. Dunning is also possible.

Down payment received (type 3 example)

The customer pays EUR 11,000 against a request. The incoming payment is recorded on the customer account and on the alternative reconciliation account "Down payments received", with the bank (clearing) account you select as offsetting entry. Because a down payment received before the service is performed is a payable, it must not reduce the receivables reconciliation account; the special G/L account is reported in the payables area. After the invoice is issued the down payment must be transferred (cleared) to the normal reconciliation account.

Customer down payment procedure

1. Request the down payment (noted item, indicator F or A as target; F-37). No balances change; payment/dunning program can act on it.
2. Receive the down payment (F-29): shown as a payable on the special G/L account "Down payments received" in the payables area; the receivables reconciliation account is untouched.
3. Invoice the customer when goods/services are delivered (FB70); the system warns that a down payment exists.
4. Clear the down payment against the invoice (F-39): the amount leaves the special G/L account and becomes an ordinary payment on the normal reconciliation account.
5. Clear the remaining payment when the customer settles the balance.

The vendor side mirrors this: down payment request (F-47) → down payment made (F-48) → vendor invoice → down payment clearing (F-54) → final payment.

Individual value adjustment (IVA)

At year-end, disputed or doubtful receivables are adjusted individually. The special G/L procedure fits because the adjustment is recorded on the customer account and on the special G/L account "Individual value adjustments for receivables" at the same time. Steps:

1. The original receivable is on the customer account (normal reconciliation account, e.g. 140000).
2. Post the IVA without tax using indicator E and posting key 19 (F-21 transfer without clearing): credit customer with indicator E (lands on 142000), debit the expense account "Expense from individual value adjustment" (210100). The expense is now correctly in the income statement.
3. After the balance sheet key date the IVA is cleared again, i.e. reversed (FB08).
4. If the receivable turns out to be uncollectable, the final write-off is posted to "Expenses for uncollectable receivables" against the regular reconciliation account, not via the special G/L account.

Transactions used in this lesson

Lesson 2: Maintaining Special General Ledger Transactions

Understand the Customizing behind special G/L indicators: the special posting keys, the properties of an indicator, account determination for alternative reconciliation accounts and for automatic offsetting entries, and how to create your own indicator.

Special posting keys

Special G/L transactions are entered with dedicated posting keys that are flagged with the "special G/L" attribute. In the standard system these are:

Whenever one of these keys is used, a special G/L indicator must be supplied in the line item; the system needs it to find the alternative account.

Alternative reconciliation accounts (special G/L accounts)

These are ordinary G/L accounts you create in FI and mark as reconciliation accounts for account type D or K. Unlike normal customer/vendor reconciliation accounts, line item display is normally switched on, so you can list the individual special G/L items. The field status group controls the entry screen layout for postings to them.

What you can adapt

Special G/L transactions are delivered preconfigured, but you may change the reconciliation/special G/L account assignments, choose different posting keys or indicators for individual transactions, and change the automatic posting settings (accounts, posting keys, account assignment rules). An indicator is always defined per account type: customer down payments and vendor down payments are configured separately even if they share the letter A.

Properties of a special G/L indicator

Account determination

Per chart of accounts, each combination of account type + indicator maps every normal reconciliation account to a special G/L account. At posting time the system takes the reconciliation account from the master record, looks up this table and posts to the special G/L account instead. For statistical indicators a second table (accounts for automatic offsetting entry) stores the fixed clearing account per account type + indicator, e.g. DG (customer guarantee made) → 196110, KG (vendor guarantee received) → 196410 in chart INT.

IMG paths (Financial Accounting (New))

• Accounts Receivable and Accounts Payable → Business Transactions → Postings with Alternative Reconciliation Account → Other Special G/L Transactions → Define Alternative Reconciliation Account for Customers (and for Vendors): indicator properties plus the recon-account/special-G/L-account mapping (FBKP-style maintenance, also OBXR/OBXT).
• Same node → Define Accounts for Automatic Offsetting Entry: clearing accounts for statistical postings.

Building your own indicator: three patterns

1. Noted item (e.g. tracking containers lent to customers): create the indicator with the noted-item flag, assign posting keys 09/19, and store an alternative reconciliation account. Nothing else is needed because there is no offsetting entry.
2. Statistical item with automatic offsetting entry (guarantee pattern): store the alternative reconciliation account AND a clearing account in the automatic-offsetting-entry table.
3. Transaction with manual offsetting entry (free offsetting): store the alternative reconciliation account only; the user enters the offsetting G/L account during posting.

Lesson 3: Understanding Purchasing (MM Integration)

See how the standard MM three-way match creates FI documents and how, with business function LOG_MMFI_P2P (EhP4/EhP5), down payments can be planned in the purchase order, posted from the Down Payment Monitor and cleared inside Logistics Invoice Verification.

The three-step (three-way match) procedure

1. Purchase order – created in MM only; no FI posting.
2. Goods receipt – a material document updates stock; an FI document debits the stock or consumption account and credits the GR/IR clearing account.
3. Invoice receipt – the vendor invoice in Logistics Invoice Verification creates an FI document debiting GR/IR and crediting the vendor.

Goods receipt and invoice receipt may arrive in either order. GR/IR is managed on an open-item basis so you can check that every invoice has a goods receipt and vice versa. The document types for the FI documents generated by MM are set in configuration.

Down payments in the procurement process (ECC enhancement packages)

Before EhP4 a down payment was a pure FI action that merely referenced the PO number. With business function LOG_MMFI_P2P activated (EhP4; EhP5 adds compatibility with active document splitting), the flow becomes:

1. Create the PO and record down payment data on the item's Invoice tab: DP category (e.g. V = voluntary down payment), down payment percentage or amount, DP date.
2. Post the down payment from the Down Payment Monitor (ME2DP): select the PO (red traffic light = open), choose "Down pmnt", which jumps into the vendor down payment posting (F-47/F-48 screen) with indicator A prefilled; a warning about the commitment appears.
3. Post the goods receipt with reference to the PO (MIGO).
4. Enter the vendor invoice in Logistics Invoice Verification (MIRO) with PO reference. The system displays a message that down payments on current assets exist; before posting you can press Down Payment Clearing, enter the amount to clear and post invoice and down payment clearing in one step.

Lesson 4: Understanding Sales and Distribution Integration

Follow the SD order-to-cash cycle and see how a down payment agreement in the sales order's billing plan produces FI noted items and down payments with indicators F and A, up to clearing against the final invoice.

Phases of a sales transaction

1. Sale – the sales order is created; it is a sales document and triggers no FI posting.
2. Shipping – a delivery document is created; picking via a transfer order in warehouse management; the goods issue creates an MM material document and an FI document (debit cost of goods sold, credit stock). Billing is only possible after the goods issue.
3. Billing – the billing document in SD prints the invoice and simultaneously creates the FI document (debit customer, credit revenue).

The document flow shows all documents belonging to one transaction, including their status.

SD/FI down payment process

1. A down payment agreement is stored in the sales order as a billing plan with a down payment date.
2. When the billing-plan date arrives, a down payment request is billed with billing type FAZ. The customer receives a letter stating amount and due date; in FI the request is posted automatically as a noted item with special G/L indicator F.
3. The incoming payment is posted as a down payment with indicator A, selected from the open requests ("Add Down Payment"). It is assigned to the sales order and the request shows as cleared in the SD document flow; the down payment appears among the customer's open items with indicator A.
4. With partial or final invoices the down payments are carried over as "down payments to be cleared": FI removes them from the special reconciliation account and places them on the normal reconciliation account from the master record, so they reduce the customer's open receivables.

Unit 2: Parking Documents

Lesson 1: Managing Document Parking (Basics) and Hold Documents

Understand the two ways to save an incomplete FI document without posting it, and why parking is the more powerful option.

The problem

A clerk entering a ten-line document cannot determine the cost center for line nine. The document cannot be posted because it is incomplete, and if the clerk simply leaves the transaction, everything typed so far is lost. Both Hold Document and Park Document let you keep the data entered so far and finish later.

Hold Document

• Temporarily saves the entry, complete or not.
• No document number is assigned; the user types a temporary name (e.g. 1000##) when holding and finds the document under that name later (Edit → Select Held Document, or the Templates tree → Held Documents).
• No transaction figures updated, and the data is not available for any evaluation.
• Can be completed and posted later, or deleted (Edit → Delete Held Document). Danger: held documents are easily forgotten.

Park Document

• Also allows incomplete documents; extensive input checks are skipped.
• A real document number is drawn from the document type's number range exactly as for a posting (externally assigned numbers must be supplied).
• No transaction figures are updated, but the data is available for real-time evaluations (e.g. amounts from parked documents can be included in the advance return for tax on sales/purchases).
• Available both in the classic posting transactions and in the Enjoy single-screen transactions (FV70 customer, FV60 vendor, FV50 G/L).
• Can be completed, changed, posted or deleted later; must be complete before it becomes an FI document; obsolete parked documents should be deleted.
• Substitutions are not supported for parked documents; they run only when the document is converted into an accounting document.
• Commonly used to implement the dual-control principle: areas of responsibility are modelled through authorizations (one person enters, another checks and posts).

Hold vs. park at a glance

Lesson 2: Processing Parked Documents

Learn what happens technically when you park, change, post or delete a parked document, which fields can and cannot be changed, and how parked documents appear in reporting.

Parking details

• An optional completeness check can be run when parking (balance zero? all required fields such as posting key and account filled?).
• Account assignment templates may be used; posting with reference to another document is not possible for parking.
• Cross-company-code transactions can be parked: only one parked document is created in the initiating company code; the two real documents with the cross-company number are created at posting.
• Saving a parked document updates no transaction figures, asset values or control totals; no automatic postings (tax, discounts) are generated and the balance is not checked, although the document overview displays the balance.

Uses and scope

Document parking serves three purposes: temporary storage of input values; multilevel models such as dual control and approval procedures; and work distribution via worklists to speed up processing. It is available for customer invoices/credit memos, vendor invoices/credit memos and G/L account postings.

Changing parked documents

Header and item fields and amounts can be changed as often as needed; the document change rules that protect posted documents do not apply. Changeable: dates, amounts, accounts, account assignment objects. Not changeable: currency, document type, document number, company code. Changes can be made individually (FBV2) or via document/line item lists for several documents, and every change is logged and viewable before or after posting (FBV5, and the "Display of Changed Documents" report with the Parked Documents option).

Posting parked documents

Parked documents are posted individually (FBV0 or from the single-screen transaction) or from a selection list; the list afterwards shows which documents posted successfully and lets you post-process the ones that failed (e.g. missing CO assignment). A batch input session can also be generated. When a parked document is converted:

1. The normal posting checks run.
2. A complete FI document is written to the document database.
3. The change history of the parked document is kept.
4. The document number stays the same.
5. Transaction figures are updated.
6. The parked document data is deleted; the entering user is recorded in the document header.

Deleting parked documents

Deletion is meant for exceptional cases. The number is not lost: displaying the deleted number in FBV3 shows a header with document status Z ("parked document that was deleted") and no line items, so there is no gap in the number range.

Posted vs. parked document

Transactions

Lesson 3: Managing Document Parking and Workflow

Get the fundamentals of SAP Business Workflow (dimensions, architecture, events, tasks, work items, Business Workplace) and see how FI uses workflow variants, release groups and subworkflows to implement amount release for parked documents.

Workflow basics

A business process answers five questions, grouped into four process dimensions: organizational structure (who does the work), process structure (in which order), function (what is done) and information (which data is used). The process is modelled graphically and stored as parameters; at runtime the workflow manager (the SAP system) performs the organizational tasks, sends the right work at the right time to the right person, supports processes spanning several systems, and provides each recipient with the information needed for the next step. SAP delivers workflow templates that can be used, adapted or replaced by your own.

Three-tier architecture

Events, tasks, work items

• A workflow starts with a triggering event, defined per object type in the BOR and raised by the application. Example: the account-assignment-approval workflow (template WS0100000 in the course) starts with the event raised when a parked document is saved as complete.
• Tasks are the steps of the process; each refers to a BOR object type and method. Even a one-step process can be a workflow definition.
• Each task has possible processors (groups of employees); in the workflow step you name responsible processors and may exclude users. At runtime the system intersects possible and responsible processors, removes exclusions, and sends the work item to the result.
• When one processor accepts (reserves) a work item it disappears from the other inboxes; executing it calls the object method. Typical workflow tasks: posting invoices, releasing purchase requisitions, changing material masters, approving leave, creating customers, deleting POs.

For each step, design decides: which object/method (what work), which processors (who, for dialog steps) and the work item text shown in the recipient's inbox.

Business Workplace

Three areas: the selection tree on the left (inbox, outbox with started workflows, documents), the worklist top right (work items grouped under the Workflow folder, with special folders for overdue/missed-deadline items), and the work item preview bottom right where decisions can already be made. Work items are executed by double-click, which starts the application with the data; attachments (SAPscript, Office, web pages) can be viewed and added. Only one user can process a work item at a time; Put back releases a reserved item to status Ready; if explicit confirmation is required, cancelling the end dialog leaves the item as Performed until Set to completed is chosen, and until then it can still be executed or forwarded.

FI configuration for parked-document workflow

1. Create a workflow variant for document parking in FI Customizing and specify whether document release is active and from which minimum amount.
2. Assign the variant to company codes (Financial Accounting Global Settings (New) → Global Parameters for Company Code → Enter Global Parameters, field Workflow variant; course uses variant 1000 "IDES FIPP-WF variant"). A company code without a variant releases nothing; one variant may serve many company codes.
3. Optionally give customers/vendors a release group in the master record so that different partners follow different release procedures. If none is set, the initial (blank) release group is used.
4. The release approval path is derived from workflow variant + document type + release group.
5. Release approval path + amount determine the subworkflow and the releasing user(s).

The subworkflow is triggered when the parked document is first saved ("Save as completed"). The parked document's Workflow tab shows that release is required and which approval path applies; the originator can follow progress in Business Workplace → Outbox → Started Workflows → Workflow Log (with the Processor view listing who may release). The releaser finds the item under Inbox → Workflow → grouped by task "Release Amount", executes it, checks the document and presses Release; afterwards the document can be posted.

Unit 3: Validations and Substitutions

Lesson 1: Understanding the Basics of Validation and Substitution

Understand what validation and substitution do, the five steps needed to put one into operation, which application areas and callup points exist in FI, and how the formula editor and activation work.

Validation vs. substitution

Both run through the Rule Manager at the moment of entry; both are needed because standard table/master-data checks cannot cover company-specific rules (e.g. "this account only with this cost center").

Five steps to operate a validation or substitution

1. Choose the application area.
2. Choose the callup point.
3. Define the validation/substitution (steps with prerequisite, check/replacement, message).
4. Assign it to an organizational unit (company code for FI; company code or company for FI-SL; controlling area for CO).
5. Activate it for the callup point.

Application areas

Area + callup point define the field pool available for prerequisites and checks, and together they determine the Boolean class (which dimensions and message classes may be used).

SD is not an application area. Each application decides which structures and fields it releases.

Callup points in FI

Matrix operators for callup point 3 (a blank must separate keyword and opening parenthesis): SUM ( ) document total, AVG ( ) average, MAX ( ) and MIN ( ) largest/smallest line value, GROUP BY to compare groups of totals.

Formula editor

Rules are built from operands (table fields, sets, exits, constants), logical operators (AND, OR, NOT) and comparison operators. The editor checks syntax step by step, including parentheses, so only correct statements can be saved. Default view shows short descriptions; Settings → Technical names shows table-field names; Expert mode lets you type the statement directly.

Assignment and activation

• One validation/substitution can serve several company codes, but per company code and callup point only one validation and one substitution can be active.
• Activation levels: 0 inactive, 1 active for dialog and batch input, 2 active except for batch input.

Lesson 2: Maintaining and Executing Validations

Build a validation step by step (prerequisite, check, message), know the message types and the Boolean syntax options, and activate and test it with a real posting.

Structure of a validation

A validation contains up to 999 steps. Each step has three parts:

1. Prerequisite – when true, the step is relevant.
2. Check – evaluated by the Rule Manager; if the check is FALSE the message is raised.
3. Message – from a message class (course uses Z1), with up to four placeholders (&) filled from fields you assign as message variables.

Course example (callup point 2): if account 473110 is used, the check verifies the cost center is not an administration cost center; otherwise an error forces a correction.

Boolean statement techniques

Simple statements can be combined with AND/OR/NOT into complex ones.

Maintenance path and activation

• IMG: Financial Accounting (New) → Financial Accounting Global Settings (New) → Tools → Validation/Substitution → Validation in Accounting Documents (activation table OB28); Environment → Validation opens the maintenance tool (GGB0).
• In the tree choose the callup point (Line Item), create the validation, add a step, fill prerequisite and check with the formula editor (select structure BSEG, field, operator, constant), maintain the message via Environment → Maintain messages, enter the message number and message variables (e.g. BSEG-HKONT for &1).
• Simulate (Validation → Simulate) with test values before activating.
• Activate with New Entries: company code, callup point 2, validation name, activation level 1.

Lesson 3: Maintaining and Executing Substitutions

Define a substitution (prerequisite + replacement) with the three substitution methods, understand which fields may be substituted, and activate and verify a profit-center substitution.

Structure of a substitution

Up to 999 steps; each step has a prerequisite and one or more replacements. When the prerequisite is true, the entered value(s) are replaced and processing continues; when false, nothing happens. A single step can replace several fields. The syntax for prerequisites is the same as for validations and may use rules and sets. Example: fill the Functional Area depending on cost center type.

Substitution methods

The target field must be released for substitution by the application (the "Substitutable fields" dialog lists them per Boolean class, e.g. class 009 for FI line items). For each selected field you pick a method:

Maintenance path and activation

• IMG: Financial Accounting (New) → Financial Accounting Global Settings (New) → Tools → Validation/Substitution → Substitution in Accounting Documents (activation table OBBH); Environment → Substitution opens the tool (GGB1).
• Create the substitution under Line Item, Insert Step, choose field BSEG-PRCTR, method Constant value, define the prerequisite in the formula editor, enter the constant under Substitutions.
• Simulate (Substitution → Simulate); note that simulation input is case-sensitive.
• Activate in OBBH: since only one substitution per company code and callup point may be active, overwrite the existing entry (Z0001 in the course) with your substitution, level 1.
• Verify by posting and checking the Profit Center in the coding block ("More" button) and in the posted document.

Lesson 4: Using Additional Techniques for Substitutions and Validations

Use rules to package reusable Boolean logic and sets to replace long value lists, and combine them in a substitution; note SAP's advice to maintain these objects in development and transport them.

Rules

• A rule is a named Boolean statement that can be used inside a prerequisite, a check, or another rule. Technically it is just a prerequisite/check stored separately.
• Use a rule when the logic is complex or needed in several places (e.g. the same prerequisite in a validation and a substitution). Example: RULE1 AND BKPF-BLART <> 'SB' – the system evaluates RULE1 first, then the document type condition.
• Rule names have at most 11 characters. Rules can also be used in matrix validations at callup point 3.

Sets

• A set is a flexible, centrally maintained data structure for ordered value lists and hierarchies, originating in FI-SL and used in validations, substitutions, ledger selection, allocations (assessment/distribution), planning, roll-ups and currency conversion.
• For performance, prefer basic or single-dimension sets over long OR chains or user exits.
• Syntax: table-field IN set-name, e.g. check that a user in set USER-GROUP posts only to accounts in set ACCOUNT-MANAGEMENT.
• Multisets combine sets over several fields (dimensions) for cross-validation, e.g. administrative accounts 476510/476520/476530 must be posted with cost centers 1000/1100/1200/1300.
• Sets are created with GS01 (Special Purpose Ledger → Tools → Set Maintenance): set name, table (BSEG), set type Basic set, field name (HKONT, MATNR), description and value list.

Transport recommendation

Define validations, substitutions and rules only in the development or test system and transport them to production.

Combining rules and sets

1. Create basic sets for the value lists (accounts, materials).
2. Create a rule at the relevant callup point whose definition is BSEG-HKONT IN set1 AND BSEG-MATNR IN set2 (sets picked via the Set directory button).
3. Create the substitution step and use the rule (Rules tab in the formula editor) as prerequisite; enter the constant.
4. Simulate (choose structure BSEG as data view), activate in OBBH, test with a posting.

Unit 4: Data Archiving in FI

Lesson 1: Outlining the Basics and Classifications of Data Archiving

Define data archiving, separate it from reorganization, backup and document storage, and understand the motives, the division of roles and the three-step archiving process.

Definition

Data archiving moves complete data objects consistently out of the SAP database tables into archive files held outside the database (typically on an external storage system). Because a business object is spread over many tables, SAP bundles the logically related tables into an archiving object; the archiving programs then write every table entry belonging to the object together, so nothing is left behind and business consistency is guaranteed. Archived data is compressed, archiving runs online (no system shutdown), and only data from completed business processes may be archived (test data rarely reaches that state).

What archiving is not

Why archive

• Technical: better and stable response times, less database administration effort (backup, recovery), shorter downtime for upgrades, recoveries and offline backups. Larger databases cost more at every query and every upgrade.
• Legal and business: country-specific retention rules, access for auditors and tax authorities, possible reuse of data. Archives are hardware- and software-independent so they remain readable after upgrades.

Roles and goals

Archiving is executed by system administrators, not by FI application managers; the FI application manager coordinates with the department and auditors, confirms retention periods, performs FI-specific Customizing and monitors the process. Administrators want the smallest possible database, the FI department wants the most data online: archiving is a negotiated compromise. Long-term goals: keep database volume roughly constant and archive proactively rather than reactively; plan archiving from the start of the implementation because volumes grow quickly after go-live.

The archiving process

1. Write: the write program reads the data to be archived and creates one or more archive files.
2. Store: the archive files are placed in an external storage system and administered so they can be found later.
3. Delete: the deletion program reads the archive file and only then removes the corresponding records from the database.

Writing and deleting alone is not enough; the files must be stored and managed so they remain accessible.

Lesson 2: Maintaining Data Archiving

Learn the anatomy of an archiving object, the three Customizing layers (Basis, cross-object, object-specific) plus FI-specific account-type and document-type runtimes, and the checks the FI archiving programs perform.

Archiving object

The smallest unit that can be archived and deleted completely. It consists of:

• Data declaration: all database tables that make up the application object.
• Customizing settings: object-specific parameters for the procedure.
• Programs: a write program (sequentially writes objects to archive files), a deletion program (deletes what has been read from the archive), and a display/read program.

Customizing layers

All reached via the Customizing button in SARA (Tools → Administration → Administration → Data Archiving).

The data archiving monitor (SAR_SHOW_MONITOR) shows all archiving objects that have run, details of each session, progress bars and open alerts; it only works if cross-object Customizing allows the write/delete programs to update monitoring information.

Archiving logic: what the FI programs check

Master data can only leave the system if the department has set a deletion indicator in the master record, which proves the record is no longer needed.

Document archiving runtimes

• Account type life: per company code, account type and account interval, a minimum number of days (the "life") plus the secondary index runtime. For account types D and K enter the reconciliation account numbers in the interval. The most precise entry wins (entries with * are least precise). Index runtime must be ≥ account runtime; as long as the archive index exists, documents and line items can still be displayed from the archive.
• Document type life: per company code and document type, a minimum number of days. Missing entries or empty values default to 9999 days.
• Reference dates: posting date (clearing date for open-item-managed accounts) compared with the key date of the run. The longer of document-type and account-type runtime decides how long a document stays.

Course examples: account runtime 90 days for customers and vendors, 60 days for G/L accounts, 360 days for promotional-gift accounts (audited at year end), 180 days for reconciliation account 140100 in company code 0001. Document type runtime: 30 days for all (* / *), 90 days for KR in 0001, 120 days for closing-entry type SB in all company codes.

Lesson 3: Executing Data Archiving for Exemplary FI Objects

Run an archiving session in SARA (variant, user, start time, spool), monitor it, and apply it to FI documents, G/L transaction figures and G/L master records, in the recommended order documents → transaction figures → master data.

Scheduling an archiving run

The run is a background job started from SARA with the Write button. The program selects data objects, checks each against its constraints, and writes archivable objects to the file; if automatic deletion is configured, the deletion job starts as soon as a file is closed, otherwise you schedule deletion later and select the archive files to process.

1. Archiving variant: selection of data plus test or production mode (variants can usually be reused only after the jobs are deleted).
2. Execution user: needs authorization object S_ARCHIVE (restrictable per archiving object), authorizations for the application transactions, and background authorization S_BTCH_JOB.
3. Start time: as for any standard background job (e.g. Immediate).
4. Spool parameters: logs can be long, so avoid immediate printing (course uses output device LP01 without immediate output).

FI archiving objects

AOBJ lists per object which tables are archived and which are only deleted: for FI_DOCUMNT the secondary index tables BSAD, BSAK, BSAS and BSIS are deleted, not archived. Retrieval (reload) programs exist, and every session writes administration data.

Monitoring

• Background tools: job log and spool list (SM37, reachable from SARA via Job overview); jobs are named ARV_<object>_WRI<timestamp>.
• CCMS monitor sets / data archiving monitor.
• Logs: application-specific log if provided (down to document level), otherwise the standard log with number of objects, tables, entries and file sizes. Spool clean-up deletes logs, so store them externally.
• SARA → Administration shows a short log per archiving session; the job log names the file and OS path created.

Archiving FI documents (FI_DOCUMNT)

The program checks header and items; if any check fails, the whole document stays.

• Header: document type runtime exceeded; minimum number of days in system exceeded; documents with withholding tax stay at least 455 days; recurring, parked and sample documents are ignored.
• Items: no open items (only cleared items or items on accounts without OI management); account type runtime exceeded.
• The key date per run is the reference for all runtimes; default is the execution date.

Archived documents remain readable through the Archive Development Kit (ADK) read programs; FB03 asks whether to include archived data and shows the document with the message that it is already archived. The archive search strategy in the processing options controls how archives are searched (speed vs. hit accuracy). Write program: FI_DOCUMNT_WRI; selection by company code, document number, fiscal year/period, document type, minimum days, key date; processing options test/production mode, detail log, log output (list and application log).

Archiving G/L transaction figures (FI_TF_GLF)

Transaction figures are the debit and credit totals per account and period from which the financial statements are built; they stay in the system at least two years. They can be archived only when all posting periods of the fiscal year are closed (close them in Open and Close Posting Periods for the relevant variant, course: 9000). Write program FI_TF_GLF_WRI selects ledger (0L), company code, account, record type (actual and plan) and "to fiscal year". After deletion the balance display (FAGLB03) for that year is empty.

Archiving FI master data (FI_ACCOUNT)

G/L accounts, customers, vendors and banks can be archived when the business agrees and legal requirements are met. Typical sequence: first set a posting block, later set the deletion flag (chart of accounts segment and/or company code segment, FS00 → Mark for deletion). The deletion flag is a hard prerequisite, so authorization to set it should be restricted. Write program for FI_ACCOUNT selects chart of accounts (INT), company code and account; the company code segment and optionally the chart of accounts segment are archived; afterwards FS00 reports that the account is not available.

Unit 5: Document Splitting

Lesson 1: Configuring Document Splitting

Explain the purpose and mechanics of document splitting in New General Ledger Accounting (SAP ERP ECC 6.0), configure the basic settings, analyse postings in the general ledger view and expert mode, and create customer-specific splitting rules.

Motivation

International requirements such as segment reporting need financial statements below company code level. A vendor invoice whose expense lines carry two different segments only has the segment on the expense lines; the vendor (payable) line and the tax line have none. Document splitting projects the G/L characteristics onto every line of the document (in the general ledger view) so that a complete balance sheet per characteristic can be produced. The same applies to Profit Center and Business Area. Document splitting is only needed when you want a balance sheet for a characteristic; if an income statement is enough, do not activate it.

Process steps and supporting mechanisms

1. Passive split: when clearing (e.g. a payment), the account assignments of the cleared items are copied to the clearing lines.
2. Active (rule-based) split: lines without assignment (vendor, tax, cash) are split according to the base lines defined in a splitting rule.
3. Zero-balance clearing lines: if a characteristic does not balance to zero within the document (e.g. a transfer from profit center A to B), the system adds clearing lines on a zero-balance clearing account so that both the document and each dimension balance.

Inheritance and default account assignment (constant) work between steps 2 and 3. SAP Note 1085921 documents splitting with worked examples.

Basic Customizing

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

Zero balance and Mandatory field indicators

• Neither set: the system still tries to enrich all lines; if it cannot, the document is posted anyway, possibly unbalanced per characteristic or with empty characteristics. No characteristic balance sheet is possible.
• Zero balance set: each posting balances to zero per characteristic (clearing lines are generated if needed). Postings with an initial value are still allowed; those initial values appear as a pseudo "default" in the characteristic balance sheets.
• Mandatory field set in addition: no G/L-view line may be left without the characteristic, so the sum of all characteristic balance sheets equals the company code balance sheet. Set both when the characteristic is a reporting entity needing a full balance sheet (SAP Note 826357 for Profit Center).
• Setting only Mandatory field without Zero balance is not recommended (e.g. HCM postings only obey the Zero balance flag; SAP Note 1039346). If you merely want receivables/payables by profit center without full balance sheets, set neither.

Rule-based (active) splitting: the building blocks

Example: vendor invoice KR (0300/0001) with two expense lines (477000, 417000, different assignments) and 10% tax. The vendor line (03000) and tax line (05100) are "items to be split" with base item category 20000 (expense), so they are split in proportion to the expense lines and each characteristic balances to zero.

Simulation and expert mode

Since ERP 6.0 you can simulate both the data entry view and the general ledger view before posting (Document → Simulate General Ledger). The Expert Mode button shows the splitting method, the document type used for derivation, business transaction and variant, the item category of each line and which lines served as base for each split. Use it to diagnose errors that would otherwise terminate the posting.

Passive splitting (follow-up processes)

When an invoice is paid (manually or by the payment run), the payment document inherits the invoice's account assignments: the vendor clearing line, the cash discount lines and the bank line are split in the same ratio as the original invoice. The standard rule for payments of vendor invoices is delivered. In the vendor line item display the invoice and payment look as before; only the G/L view shows the split. A residual item created by a partial payment is likewise split passively in the invoice's ratio.

Inheritance

If all account-assigned lines of a document carry the same characteristic values, inheritance copies these values to the remaining lines (bank, tax, petty cash) even without a matching splitting rule, so simple documents balance per characteristic without extra Customizing.

Zero-balance creation and corrections

Reposting an amount from one segment to another produces clearing lines on the zero-balance clearing account. If an invoice was posted and paid with a wrong segment, correct expense and vendor items manually; note that customer/vendor lines cannot receive a profit center by manual entry (it must come from splitting), so vendor-to-vendor or customer-to-customer adjustments are not possible and a clearing account must be used instead.

Typical posting errors

• No base item category defined for the Cash Account (or VAT) item category in the business transaction/variant assigned to the document type (e.g. SA with 0000/0001).
• Segment or profit center cannot be inherited because assignments are not unique.

Remedy: either use a document type with a suitable business transaction (an FB50 posting that is really a payment should use a type classified as Payments 1000) or modify/create a rule, which requires a customer-defined splitting method first.

Creating a customer method and rule

1. Define a new splitting method (Extended Document Splitting → Define Document Splitting Method).
2. Copy the standard rules with their item categories into it (Define Document Splitting Rule).
3. Assign the new method (valid for all company codes in the client).
4. Adjust or add rules/variants as required and classify the relevant document types.

Wizards (business function FIN_GL_CI_2, EhP4)

• Configure Document Splitting (FAGL_WZ_SPLIT_CONF): guides through classifying G/L accounts and document types, defining characteristics for G/L and CO, zero-balance clearing account, post-capitalization of cash discount to assets, constants, activation and a Customizing check.
• Create Document Splitting Rule (FAGL_WZ_NEW_RULE): create a business transaction variant, take over assigned item categories, copy an existing rule, edit the rule (items to be split / base item categories), assign a document type, optionally simulate the rule against an already posted document.

The wizards are support tools only; you still need to understand splitting and must test every process using a document type you re-assign.

Course example: customer down payment split across profit centers

A customer down payment (DZ, 1000/0001) of EUR 11,000 with two down payment lines (2,200 to PC 1000 and 8,800 to PC 1402) splits the customer special G/L lines (170000, item category 02100) and tax lines 1:4, but the bank line (04000) is not split and the document cannot be posted, because in the standard rule 02100 is not a base item category for 04000. Solution: copy DZ to a new document type (e.g. AJ), create variant Z0## of business transaction 1000 by copying rule 1000/0001, add base item category 02100 for item category 04000, and assign the new document type to the new variant. The down payment then splits correctly.

Unit 6: New Asset Accounting

Lesson 1: Explaining the Functionality and Architecture of New Asset Accounting

Describe the improvements new Asset Accounting brings over classic FI-AA and the new posting architecture based on an operational entry document and ledger-group-specific valuation documents.

Why new Asset Accounting

Classic FI-AA was built around depreciation area 01 as the fixed "leading" area and needed delta depreciation areas to represent a parallel valuation under the New G/L ledger approach; APC values of parallel areas were posted periodically. New Asset Accounting removes these constraints.

For each accounting principle exactly one depreciation area posts in real time (exception: investment support areas on the liabilities side, where one of them is designated as the real-time poster).

New posting architecture

1. The operational entry document (e.g. the vendor invoice part) posts to the technical clearing account for integrated asset acquisition, without a ledger group, so it hits all ledgers. It never updates the asset; the asset master is used only for checks (completeness, posting allowed).
2. From it the system derives one valuation document per ledger group. Each clears the technical clearing account in its own view (so the account always has zero balance) and posts to the asset reconciliation account, updating the asset subledger with the values of that accounting principle.

Prerequisites for activating new Asset Accounting (figure): New General Ledger Accounting active, the ledger approach or accounts approach for parallel accounting set up consistently, the required business function (FIN_AA_PARALLEL_VAL) switched on, and the Customizing adjustments of Lesson 2 completed; the switch can be set to "in preparation" before full activation.

Lesson 2: Configuring New Asset Accounting

Know the new FI-AA Customizing menu and the mandatory adjustments: ledger group assignment and posting indicators per depreciation area, value/parameter takeover rules, parallel currencies, quantity-update area, technical clearing account and alternative document types.

Required Customizing changes

Technical clearing account requirements

• Balance sheet account, defined as reconciliation account for account type A (assets).
• Line item display inactive.
• Not used in any other FI-AA account determination.
• "Posting without tax allowed" flag set.

It is posted by asset acquisitions and investment support measures. Separate technical clearing accounts per account determination are possible, e.g. when different field status behaviour is needed per asset balance sheet account.

Lesson 3: Using New Asset Accounting

Post and analyse asset transactions in the new architecture: integrated acquisition with activation differences, deactivated depreciation areas, ledger-group-specific retirements, the depreciation run and the Asset Explorer.

Documents created by an integrated acquisition

• Operational entry document: vendor against technical clearing account, posted with the entered document type, no ledger group; asset data used only for checks.
• Valuation document parts, one per accounting principle / ledger group (possibly with a different document type such as AA): technical clearing account against asset reconciliation account; the asset subledger is updated.
• In document display switch valuations with the Ledger Groups button and currency types with the Display Currency button.

Activation differences: if an amount is capitalised under one accounting principle but not under another (e.g. EUR 200 not capitalised under local GAAP), the system creates the operational document, two LG-specific documents and a third document that posts the non-capitalised EUR 200 to expense for the local GAAP ledger.

Further rules: the technical clearing account always balances to zero; accounting-principle-specific documents are always created; a different asset reconciliation account per accounting principle is possible; the technical clearing account is posted even if an accounting principle is not represented on the asset; if no accounting principle is represented by an area posting APC online, an error is raised (changeable to a warning, in which case only statistical areas are updated).

Deactivated depreciation areas

Only the relevant accounting principles are represented on an asset or asset class through their depreciation areas, and FI-AA postings affect only those. P&L postings for the other accounting principles are handled manually. If an accounting principle is not represented by an online APC-posting area, the posting is redirected to the "account for non-operating expense" (T095-KTNAIB).

New document display

All documents produced by one business transaction and valid for one valuation are shown together. Example cross-company acquisition: operational AP document in company code FIAA (no LG), the equivalent document in company code FIA1 (no LG), and the LG-specific valuation document for the asset in FIA1; select "0L + Initial" to see the leading valuation.

Transactions used

Lesson 4: Migrating from Classic General Ledger Accounting to New General Ledger Accounting

Distinguish legacy data transfer from migration, know the questions and sequencing of a New G/L migration project, the phase model with its dates, and the components of the mandatory SAP General Ledger Migration service.

Legacy data transfer vs. migration

A new implementation with subsequent legacy data transfer and a migration from classic to New G/L are both separate projects with full project phases. Neither is a simple table swap: both have technical and process-related dimensions. SAP Note 756146 describes the default configuration and activation of New G/L (new installations have New G/L active by default).

Setting up a migration project

• Which SAP components are in use (FI-SL, PCA, cost-of-sales ledger, business area balance sheets)?
• Is parallel accounting (several accounting principles) required?
• Target configuration: which FI characteristics (segment, profit center, ...) should New G/L carry; period accounting or cost-of-sales accounting for the P&L?

Sequence for existing customers: first the technical upgrade to SAP ERP as its own project; then the New G/L implementation project, of which data migration is one part. Do not combine the migration with a chart-of-accounts conversion or other complex changes. New G/L is activated at client level, so all company codes of the client migrate together.

Phase model

Date example (fiscal year = calendar year, today 23 March 20XX): recommended migration date 1 January 20XX+1, earliest possible 1 January 20XX, sample activation 1 May 20XX+1, document splitting validation active as soon as possible and no later than 1 January 20XX+1. If today is 23 October 20XX the realistic migration date may slip to 1 January 20XX+2 depending on scenario and readiness; 1 January 20XX is only theoretical.

SAP General Ledger Migration service

The service is obligatory and supports (but does not run) the customer's project; consulting is not included. Components:

Migration scenarios 1–5 (from classic G/L) are taught in course AC212; scenarios 6, 7 and 8 cover subsequent implementation of additional New G/L functions (e.g. a non-leading ledger, SAP Note 1378630; changing the leading accounting principle, SAP Note 1330451) and also require the service plus enhancement packages/business functions. The migration web page (service.sap.com/glmig) collects the information needed before starting.