sap

Tue sday, August 27, 20 13

Financial Statements
The SAP ERP system provides a standard report (RFBILA00) for creating financial statements.
Financial statement versions are also used in the structured balance list, drilldown reporting, planning,
and transferring data to consolidation.
The financial statement version enables you to configure the report format such as whether to create
the report at the business area level, segment level, profit center level, company code level, and so on
(the document split must be activated to create financial statements for additional entities). You
determine the following:
Which items are to be included and the sequence and hierarchy of these items
The text describing the items
The charts of accounts and the individual accounts relevant to the report
The totals to be displayed
You define a financial statement version in two steps:
Enter it in the directory of financial statement versions
Define hierarchy levels and assign accounts
Each version must have the following special items
Assets
Liabilities
Profit
Loss
Profit and loss results
Accounts not assigned
Notes to Financial Statement
Non Assigned Accounts
The net profit or net loss is only determined from accounts that are assigned to the assets and
liabilities items. Accounts belonging to the items notes to financial statement (see above) or not
assigned are not taken into account
A financial statement version consists of a maximum of 20 hierarchy levels.
Assign items to each level. The system calculates a total/subtotal for each item, which is then
displayed when the program is run.
Assign texts to each item.
Assign the accounts whose balance and account name are to be listed to the lowest levels.
You can write additional texts for each item in a financial statement. You can write up to four lines of
text at the beginning and/or the end of an item.
You use account group assignment to determine in which cases the balance of a specific account group
is to appear in a specific financial statement item. (e.g. Bank with positive or negative balance)
Drilldown Reporting
Drilldown reporting is a tool that enables you to analyze G/L account transaction figures and financial
statements. You can also carry out variance analyses such as plan/actual comparisons, fiscal year
comparisons, and so on.
Drilldown reporting also provides functions for processing lists, such as sorting, conditions (threshold
values), ranking lists, and so on. You can also access SAP Graphics, SAP mail, and the Excel List viewer
from your report.

Characteristics and key figures form the basis of the drilldown report presentation. Characteristics
define how your data can be classified or provide a time reference. Key figures include stored values or
quantities and calculations based on these values and quantities. In G/L drilldown reports:
Characteristics can include company, company code, business area, segment, profit center, chart of
accounts, financial statement item, currency, fiscal year, period, and so on
Key figures can include total credit balance, total debit balance, balance sheet value, accumulated
balance, balance carry forward, and so on.
Each report consists of a number of lists that are divided into two categories according to their
content: drilldown lists and detail lists
Posted by michael issac at 4:56 AM No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest

Correspondence Overview
Correspondence is required in many areas of external accounting. Many companies strive to automate
their correspondence activities.
Periodic correspondence is triggered by specifications made in the master record, such as invoices and
account statements. The interval (weekly, monthly, and so on) is specified in the customer/vendor
master record
The correspondence creation process comprises the following steps:

Step 1: Request the required correspondence. Here, the system initially only notes internally which
correspondence types are to be created.

Step 2: The requested correspondence types are printed. Typically, correspondence is printed
automatically with a particular frequency, for example, dunning letters, account statements, and so
on. In certain cases, it is possible to print certain correspondence types individually and on demand.
The print request is sent to the spool system.
Basic types of correspondence:
1. Collective request with a selection program (for example, periodic bank statement)
2. Manual individual request (for example, open items list, bank account statement, individual
correspondence)
3. Automatic individual request (for example, payment notice)
You can generate correspondence directly from many screens in the system (manual individual
request).

Document creation

Display/change line items

Balance display

Line item processing

Payment
A correspondence type represents a type of letter in the system. You have to create a correspondence
type for every type of letter you need.
Data from several different company codes can be combined in one letter. Select the Cross Company
checkbox in the correspondence type and assign the company codes to correspondence company codes
in the IMG.
A correspondence type can have several different form letters. The individual forms are distinguished
by their form ID. This ID is assigned to the selection variant to make sure that the right letter is
printed.
If you are using different types of correspondence depending on the reason code, select the According
to Reason Code checkbox.
The check and payment document are created in two separate steps. When the check is created, the
check number, bank information, and the check recipient are printed on both the payment document
and the open invoice.
With the automatic payment program: This program creates several payment documents and checks
automatically. This program is used to pay several vendors at once.

With Post and print forms: This function creates individual payment documents and checks. The user
manually selects the invoices for payment. You use this function to pay a specific vendor or invoice.
Post: Creates individual payment documents after the user has manually selected the invoices for
payment. As in the previous example, you use this function to pay a vendor or a specific invoice using
pre-printed checks that are filled out manually or with a typewriter.
If errors are made, users must decide whether to reprint or void the check, or whether to void and
reverse the check and the payment document.
There are three ways to pay an invoice in the SAP system:
Checks can be voided (you have to give reason) before the print run in the following cases:
Accidentally damaged
Stolen
Destroyed
Checks can be voided after the print run in the following cases:
Not required because a cash payment is made instead
Torn during printing
Used for a test print
In each case, you have to decide whether the payment document needs to be reversed. The system
allows you to:
Reverse the check
Reverse the check then reverse the payment document separately
Reverse the check and the payment document simultaneously
When you void a check, the payment document, original invoice, and check register are updated. When
you reverse a document, a new reversal document is created.
The Check Register is a dynamic report that provides the following information:
All checks
Outstanding checks
Checks paid
Voided checks
After notification that the check has been cashed is received, the RFEBCK00 program transfers the
check amount from the check clearing account to the cash account. At the same time, the cashing date
(date the check was cashed) is entered in the payment document, original invoice, and check register
Pre-closing activities that begin in the old month include:
Posted by michael issac at 4:55 AM No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest

1.
2.
3.
4.

Bank Accounts
The International Bank Account Number (IBAN) 34 alphanumeric characters are an internationally
recognized and unique number that identifies a specific bank account. It was designed by the
International Organization for Standardization (ISO) and the European Committee for Banking Standards
(ECBS) to facilitate the handling of international payment transactions. We can enter it as follows:
The IBAN can only be entered in a vendor or customer master record if the business partner provides
his or her IBAN and requests the entry.
When you enter an IBAN for new bank details, the system can generate the country-specific bank
details for certain countries.
Each bank that is used must have a bank master record in the bank directory in the system.
Bank master data can be copied into the bank directory manually or automatically. Each bank master
record in the bank directory is uniquely identified by the bank country and a bank key.
The house bank is the bank used for internal business. A bank becomes a house bank when you assign a
house bank ID to it. The payment program uses the house bank ID to determine the bank to be used.
There are four ways to create bank master data:

When entering bank information in the customer or vendor master record, or in the Customizing for
house banks:
Using the Create Bank transaction in the Accounts Receivable/Payable master data menu.
The bank directory can be imported from disk or tape which can be obtained from one of the country
banking organizations.
Customers that use the lockbox function can create a batch input session that automatically updates
customer banking information in the master record.
.
The house bank ID and the account ID together uniquely identify an account. An account ID can only be
used once for each house bank. You can create several accounts, each with a separate account ID, for
each house bank. This combination is entered in a G/L account that represents the bank account in the
general ledger.
A G/L account must be created for each bank account. This G/L account is assigned to the bank
account and vice versa. Both accounts must have the same account currency.

Payment Run
The SAP payment program lets you automatically

Select open invoices to be paid or collected

Post payment documents

Print payment media, use data medium exchange (DME), or generate electronic data interchange (EDI)
The settings for the payment program are defined in three places:

In the master record for the business partner, for example: bank details and payment methods

In the items, for example, payment methods in the document, terms of payment, and so on

In Customizing for the payment program

The payment process consists of four steps:

Setting parameters: In this step, the following questions are asked and answered:
o What is to be paid?
o Which payment method is to be used?
o When is the payment to be made?
o Which company codes are to be considered?
o How are they to be paid?

Generating a proposal: Once you have entered the parameters the system starts the proposal run. It
generates a list of business partners and open invoices that are due for payment. Invoices can be
blocked or unblocked for payment.

Scheduling the payment run: Once the payment list has been verified, the payment run is scheduled. A
payment document is created and the general ledger and sub ledger accounts are updated.

Printing the payment media: The accounting functions are completed and a separate print program is
scheduled to generate the payment media
Payment Program Configuration
There are six configuration areas for the payment program:
1. All company codes (open items are automatically counted or included)
2. Paying company codes
3. Payment method per country
4. Payment method per company code
5. Bank selection
6. House banks
The first three areas only require minimum changes. The standard system contains the common
payment methods and their corresponding forms, which have been defined separately for each country.
1. All company codes

A. Control Data
Payment relationships that apply across all company codes are defined here.
Sending Company Code -whose payment methods are accepted (sub ledger accounting) Company code
A pays for company code B. Company code B is the sending company code. If no sending company code
is defined, the paying company code is interpreted as the sending company code.

Paying Company Code: This is the company code that processes outgoing payments. This is the
company code that records the bank postings. The sub ledger postings are recorded in the sending
company code.

Payment Method Supplements: These are two-character alphanumeric codes that are taken from the
business partners master record that is transferred to the document when the payment is posted.

Advantage:
o The payment media can be sorted and printed separately according to payment method supplement
(such as sent to a vendor in the same building by internal mail; functions as a mail box stop (internal
dispatch method)).
o Vendor/Customer Sp. G/L Transactions to be paid specifies which special general ledger transactions can
be processed with the payment program.
B. Cash Discount and Tolerances

You can define a minimum discount limit for outgoing payments. If the discount is less than this limit,
it is ignored and the payment is not made until the due date for net payment.

The maximum discount setting causes the maximum discount to be used, even if the cash discount
period has been exceeded.

Tolerance days for payables specify the number of days by which the cash discount period and period
for net payment may be exceeded (delayed payment).
2. Paying company code

The minimum amount for incoming/outgoing payment specifies the minimum amount required to make
an incoming or outgoing payment.

The forms that will be used for each paying company code.

If you choose no exchange rate differences, the full exchange rate differences are not posted until the
bank posting has been received.

The Separate Payment for Each Reference setting specifies that a payment can only be used to pay
invoices and credit memos that have the same payment reference.

Define how many bills of exchange are created for each account during the payment run for the bill of
exchange payment method.

Control which open items for the bill of exchange payment method are to be considered during the
payment run using the due date specifications
3. Payment Method per country

Payment method either for outgoing or incoming payment

Characteristics for classifying the payment method: What is the method of payment and what are its
characteristics?

Postal bank/postal check account

Allowed for Personnel Payments

Requirements in the master records, for example, address required for check Posting details:

Document types for postings

Payment media info: Print programs; standard programs RFFOD* (such as RFFOD__S) or PAYMENT
MEDIUM WORKBENCH

Key in the code line: For the bank; for example, 51 on bank transfers

Permitted currencies (if no entry is made -valid for all currencies)

Payment Method per company code
1. Minimum and maximum payment amounts -The breakdown amount has the following function:
Payments that exceed this amount are analyzed to see whether a split into several payments is
possible, with the specified amount as the maximum.
2. Whether payments abroad and foreign currencies are allowed


Foreign business partner allowed (address)

Customer/vendor bank abroad allowed (bank country)

Foreign currency allowed

o Grouping of items:
o Single payment for marked items: Items that contain this payment method are paid individually; if an
item does not contain a payment method with the result that the payment method is determined from
the master record, it can be paid together with other items.
o Payment per due day: Specifies that only items that are due on the same day are paid with a single
payment.
o Bank Selection Control -Settings for selecting the house bank
No optimization
Optimization by bank group: Every bank can be freely assigned to a bank group; the program looks for
a solution where two banks are used that are assigned to the same bank group.
Optimization by post code: Allows you to choose the house bank based on the business partners
location.
4. Bank Selection
o The order in which the house banks are used is determined as follows: The payment method/currency
determines which house bank is used first, second, third, and so on.
o For each combination of house bank and payment method, you can specify the:
o Offsetting account for the sub ledger posting (bank subaccount)
o Clearing account: For payments by bill of exchange, the offsetting entry for the bill of exchange liability
at the bank is made here.
o Available funds in each bank. Note that the amount field is not updated automatically after each
payment run.
o These sub-accounts are managed with open items so that users can manage the status of the payments.
o The number of days up to the value date is the probable number of days until a debit memo or credit
memo is entered in the bank account. The number of days is usually added to the posting date to
produce the expected debit or credit memo date on the bank account for cash management and
forecast purposes.
o The value date is usually calculated from the posting date of the payment run plus the number of days
up to the value date.
o The incoming and outgoing payment functions have a bank charges field for entering all types of bank
charges. For incoming payments, the system subtracts the bank charges from the clearing amount. For
outgoing payments, it adds the charges to the clearing amount. The system also posts the charges to an
expense account. To do this, it requires a posting key and an account assignment, both of which are
already defined in the standard system
Running Payment Program
Every payment program run is identified by two fields:
o Run Date it is recommended as the actual date when the program is executed. Its main purpose is to
identify the program run
o Identification -The identification field is used to differentiate between program runs that have the same
run date.

All documents that were entered up to the Docs entered up to date are included in the payment run.
The posting date is the date when the general ledger is updated with the postings. This date is
defaulted from the run date on the previous screen.
If multiple company codes are listed, they have to be separated by commas.
The company codes in a payment run must be in the same country.
For each country, we defined payment methods that can be used within that particular country. From
these payment methods, choose the ones to be used in the current payment run.

o
o
o
o

o
o
o

o
o
o
o

If you use more than one payment method in the payment run, remember that the order in which you
enter them is important. The method entered first has first priority; the next has second priority, and
so on. The system makes the payment using the highest priority possible after the check.
What happens in the proposal run?
The items to be paid are selected (based on the search criteria entered with the parameters).
The items for the payments are collected and payment methods and bank details assigned.
If the system cannot find a payment method or bank details, the items are added to the exception list.
The proposal and exception list are generated after the proposal run.
How is the due date determined for payables?
A vendor item is paid if the following applies at the next payment run (taking the tolerance days into
account):
The discount has expired.
A lower discount should be received.
The net due date would have been exceeded.
Once the proposal run is completed, the system generates two reports: the payment proposal list and
the exception list. You can edit these reports online or print them.
The proposal list shows the business partners and the amounts to be paid or received.
Any exceptions are also listed here. Users can drill down several times to view and change the details
of the individual payment items
There are several ways to configure a payment block:
If a problem arises during the invoice verification process, the invoice is usually blocked for payment.
If there is a reason why a vendor should not be paid, you can create a payment block in the master
record.
When an AP invoice is entered, an invoice may be blocked for payment.
You can define additional payment blocks in the system. Users can also specify whether the payment
block can be removed when payments are processed.

After you have edited the payment proposal, the system uses it as a basis for the actual payments.
What happens during the payment run?
1. Payment documents are created or posted.
2. Open items are cleared.
3. Postings are made to general ledger and sub ledgers
It is advisable to use bank subaccounts for posting incoming and outgoing payments, for example,
accounts for outgoing checks, outgoing transfers, incoming checks and transfers received.
There are many advantages to using subaccounts. You can reconcile the bank account balance at any
time with the corresponding G/L account. Subaccounts are generally managed on an open item basis
and with line item display.
The document type for payment documents is defined in the country-specific specifications for the
payment method. For cross-company-code payments, you can enter a further document type that is
used for the clearing postings. Both document types must be defined using internal number
assignment.
Documents from the payment run contain the date and identification number (for example, 19940301ID) of the run in the document header text.
For calculating the value date of check payments, you can enter a check cashing time in the master
data. This has priority over the days to value date for checks
The print run starts the standard print programs, which can both generate the payment media (such as
checks) and provide the files (DME) for transfer to the banks.
Individual steps:
o The payment media, payment advice notes, and payment summary are sent to the print administration
o The DME payment data is sent to DME administration
o Intermediate documents are created for selected payments and forwarded to the EDI subsystem.
A print program is assigned to each payment method for each country.

o
o
o

o
o
o
o

A print program is assigned to each payment method for each country when it is configured. To run the
print programs, the system needs at least one variant for each print program and payment method.
If several variants are assigned to a print program, the system runs the program once for each variant.
The first print program run by the payment program is the print program RFFOEDI1. This program
chooses all the payments that were selected for EDI. Intermediate SAP documents are created for
these payments and forwarded to the EDI subsystem. The EDI subsystem then transforms the
intermediate documents into EDI data, which is sent to the bank.
With Data Medium Exchange, a file is created that contains all the relevant payment information in
accordance with the banking rules of the country in question. The DME file is stored in Data Medium
Administration and can be downloaded to a data medium. You can also print out the DMEaccompanying
note. The data medium and the DME accompanying note are then sent to the bank.
The DME file can be either stored in the SAP TemSe (TEMporary SEquential file) within the SAP System
or in the PC file system. In the SAP TemSe, the file cannot be accessed by unauthorized external users
The print program:
Assigns check numbers to payment documents
Updates the payment documents and original invoice documents with the check information
Prints checks and accompanying documents
Payment Medium Workbench
PMW is used to create payment media. The user is provided with a generic payment medium program
for all payment medium formats whose variants are to be entered in Customizing. The user can create
the structure of the note to the payee and choose different notes to the payee according to their origin
(vendors, customers, personnel, travel expenses, treasury, online payments, and so on).
Developers, consultants, and system administrators have simple tools for changing delivered formats
without modification or setting up new formats. Well-known development tools (Data Dictionary,
Function Builder, and so on) and the new Data Medium Exchange Engine (DMEE) are integrated,
enabling PMW to function like a workbench. without modification or setting up new formats. Wellknown development tools (Data Dictionary, Function Builder, and so on) and the new Data Medium
Exchange Engine (DMEE) are integrated, enabling PMW to function like a workbench.
Simple, modification-free options for adjusting delivered formats to meet customer or bank
requirements (including individual selection parameters for the payment medium program). Simple
tools for creating new formats (no programming experience required to use the DMEE). Customizing to
structure the note to the payee. Standardized creation of advice notes with the new RFFOAVIS_FPAYM
program. Improved performance, especially for large payment runs
A payment method becomes a PMW payment method in only four steps:
The payment medium format is assigned to the payment method after you have determined that you
want to use PMW. You may have to enter a substitute format.
The note to the payee is assigned to the payment method by origin. Here you can use the examples
provided by SAP: SAMPLE 02 as the note to payee for FI-AP and FI-AR and SAMPLE 00 for all others
(origin remains blank), for example.
You enter the form for the accompanying sheet provided by SAP in the payment method for each
company code (under Next Form).
And finally, you must create and assign selection variants.

Additional info on PMW

Set the PMW payment medium formats
Release information on PMW
Documentation on the generic payment medium program
Integration of check management in PMW
Creation of cross-payment run payment media
PMW connection to online payments
Conversion Steps for a Payment Method:
1. Switch to PMW (radio button) in the payment method definition/country.
2. Enter an existing PMW format in the payment method definition/country. Hint: Note the
documentation buttons for the PMW and the individual PMW format.

3.
4.
5.
6.

1.
2.
3.

Assign notes to payee (general and/or origin specific) to the payment method definition/country (for
example, SAMPLE 02 for origin FI-AP and FI-AR)
Assign a PMW form for accompanying sheets
Remove the form for document-based payment medium (if you have not already done so)
Create and assign selection variants for each payment group.
When the payment media are created for a payment with a PMW payment method, the program
SAPFPAYM_SCHEDULE is launched.
This first carries out a pre-service. The pre-service processes the data supplied by the payment run
again specifically for the PMW:
The payments are sorted according to PMW format and other format-specific fields.
Payment groups are created based on the level of granularity (one payment medium file is usually
created later for each group).
The note to payee is formed
The granularity is specified in the definition of the payment medium format and determines how the
payment media are to be output separately in payment groups. A payment group usually corresponds to
one payment file.
Every PMW format (with or without a supplement) has up to three types of text fields for reference
information (text box on the left in the PMW Format graphic above).
Type 1: Invoice information (classic note to payee)
Type 2: Internal reference (in case the payment media is returned)
Type 3: External reference (for the business partner)
Debit Balance Check

In some cases, the payment run can result in payments being made even though the account has a
debit balance.
The debit balance check can be carried out after a payment proposal has been created. The check
offsets the entire due debit items without an incoming payment method against the proposed
payments. If the resulting debit balance or credit balance is less than the minimum payment amount,
the payments are added to the exception list and the account is placed on a list of blocked accounts.
The relevant accounts remain blocked even if the payment proposal is then deleted.
Program RFF110S is used to schedule the payment program SAPF110S in the background. The selection
screen for this program essentially features the same parameters as transaction F110.
The program RFF110S, in turn, can automatically run four additional programs consecutively.
To prevent outgoing payments despite a due debit balance, the program RFF110S should first be
scheduled as a proposal run. Following this, the program RFF110SSP should be called automatically to
perform the debit balance check.
After the debit balance check, the program RFF110S is called again automatically. This time, however,
as an update run with possible generation of the payment media
The programs can be scheduled to run periodically using job management or the Schedule Manager.