Tuesday, August 27, 2013



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


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:



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.
1.       Each bank that is used must have a bank master record in the bank directory in the system.
2.       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.
3.       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.
4.       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 partner’s 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 partner’s 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.
·         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?
o   The items to be paid are selected (based on the search criteria entered with the parameters).
o   The items for the payments are collected and payment methods and bank details assigned.
o   If the system cannot find a payment method or bank details, the items are added to the exception list.
o   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):
o   The discount has expired.
o   A lower discount should be received.
o   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:
o   If a problem arises during the invoice verification process, the invoice is usually blocked for payment.
o   If there is a reason why a vendor should not be paid, you can create a payment block in the master record.
o   When an AP invoice is entered, an invoice may be blocked for payment.
o   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, 19940301-ID) 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.
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:
o   Assigns check numbers to payment documents
o   Updates the payment documents and original invoice documents with the check information
o   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. 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.
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:
o   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.
o   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.
o   You enter the form for the accompanying sheet provided by SAP in the payment method for each company code (under Next Form).
o   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.       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)
4.       Assign a PMW form for accompanying sheets
5.       Remove the form for document-based payment medium (if you have not already done so)
6.       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:
1.       The payments are sorted according to PMW format and other format-specific fields.
2.       Payment groups are created based on the level of granularity (one payment medium file is usually created later for each group).
3.       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.