1 SAP NOTES

BASIC SETTINGS Enterprise structure: It is a structure in the R/3 system organized by the functions like products, purchases, sales accounting & costing by fulfilling the legal requirements of the country. In the E.S we portray the organizational structure of client business in the R/3 system. For portraying the company structure, different Accounting, Logistics and Human Resources organization units are provided. In enterprise structure we map the organization structure of client business in R/3 system & we define different organizational units. This structure allows us for configuration settings & for flow of data in each module. ERP integrates all the functions in to one system so the functions are not independent they are dependent on each other. DEFINITION I Financial accounting

Define company (optional activity)

TC :OX15 Company: A company is an organizational unit which represents a business organization for which individual financial statements are created according to the relevant management requirements. If organization uses different clients the company will appear as internal trading partner. In company definition we store the basic data for each company Company key (6) Country (mandatory) Language Currencies (global company currency): The currency of a company that belongs to a corporate group. A company can comprise one or more company codes. All company codes for a company must work with the same operational chart of accounts & fiscal year. The currencies used can be different. In sap system consolidation functions in financial accounting are based on companies.

Define company code (mandatory activity)

TC: OX02 Company code: Represent the legal entity for which a complete set of G/L accounts can be drawn up for external reporting purpose. The company code is the central organizational unit of external accounting within the Sap system. We must define at least one company code before implementing the financial accounting component. Business transactions relevant for FI are entered, saved, & evaluated at company code level. At least one company code must be specified in each client A company code can have 3 currencies in total. One which is called the local currency (i.e. company code currency) and 2 parallel currencies can be configured. When you do that the system has the flexibility to report in the different currencies. Up to four currencies can be used for each company code. They are transaction, local, and up to two optional parallel currencies. Company Code is a legal entity for which financial statements like Profit and Loss and Balance Sheets are generated In company code definition the following information is specified Company code key Company code name

2
Address data Country /local currency (mandatory): The currency of a company code in which ledgers are maintained. Country key Language key Company code global parameters Company code defaults - Business area balance sheet - Propose default value date - Propose fiscal year - Negative postings allowed. - Company code is productive It does not allow for changes in production client if we select the check box. Once the company code is live this check box helps prevent deletion of many programmes accidentally. This check box is activated just before go live.

Define

business area (optional activity) TC:OX03 Business area: is a geographical area which consists of several lines of business for which financial statements are prepared We can create financial statements for business areas & we can use these statements for various internal reporting purpose. Business area balance sheet is enabled at company code global settings.

TC: OB45 Credit control area is an organizational unit in which we specify the credit limits for customers A credit control area (CCA) is used to set and control credit limits for customers. It includes one or more company codes. There can only be one CCA per company code. Customers in several company codes can exist under several CCA's. As part of credit management, an individual customers credit limit is set based on an individual credit control area or across several credit control areas.

Define credit control area

Define consolidation business area

TC:OCC1 A consolidation business area is an organizational unit which represents a central business area within a business organization and that has a balance sheet which can be included in business area consolidation.

Define financial management area

II Controlling

TC:OF01 Financial management area is an organizational unit from where funds are monitored & controlled.

Define controlling area

TC:OX06 Controlling area : is an organizational unit under which controlling activities of cost center acctg, product costing ,profit center accctg, profitability analysis are stored & this is used for internal reporting purpose. Controlling area it is an organizational unit which represents the internal management organization structure under which controlling activities are performed. A Controlling area can have the following 2 type of relationship with a Company code a. Single Company code relation b. Cross Company code relation

3
This means that one single controlling area can be assigned to several different company codes. Controlling can have a one is to one relationship or a one is to many relationship with different company codes.

Create operating concern

TC:KEP8 The operating concern is an organizational unit in accounting which structures an enterprise from the profitability analysis point of view.

ASSIGNMENTS Financial accounting Assign company code to company Assign company code to credit control area Assign company code to financial management area Assign controlling area to financial management area Assign business area to consolidation business area Controlling Assign company code to controlling area Assign controlling area to operating concern

Assigning business area to company code (optional) 1. At the time of posting transactions at company code level, system will ask for which business area, we are posting 2. To eliminate the restriction of a business area to a particular company code i.e. same company codes can use the same business area. 3. Business area is at client level. Which means other company codes can also post to the same business area. FI The SAP Financial Accounting (FI) Module provides integrated, on-line, real-time functionality for processing, recording and maintaining the financial accounting transactions of the business for external reporting purposes. Chart of accounts TC: OB13 Chart of accounts is a chart which consists of list of G/L accounts having complete G/L master & its own set of values. Company codes for a company must use the same operational chart of accounts & fiscal year, & these are used in both financial accounting & cost accounting. Chart of accounts provides framework for the rendering of values to ensure an orderly rendering of accounting data. For each G/L account, the chart of accounts contains the account number, account name, and the information that controls how an account functions and how a G/L account is created in a company code. A single Company code can have only one Chart of Accounts assigned to it. The Chart of Accounts is nothing but the list of General Ledger Accounts. The definition of chart of accounts contains: - chart of accounts key - description General information - Maintenance language -length of G/L acct number

4
Controlling integration -manual or automatic creation of cost elements Consolidation -group chart of accounts Status - Blocked indicator

The maintenance language is the language in which account descriptions are maintained. The length of the G/L account number can be from 1 to 10 digits. Using the type of integration between G/L accounts and cost elements, we can control how the cost element master data is maintained when maintaining the master records of G/L accounts. We can manually maintain the cost elements, but it is also possible to have the cost elements automatically be created when creating G/L accounts. However, this is only possible if a default value has been entered for the cost element type, since the system assume that no cost element needs to be created if no default value exists.

A group account number can be entered into a G/L-account. This group account number is used for reporting across company codes which use different charts of accounts. If a group chart of accounts is entered into the chart of accounts, the system makes this field a required entry in the G/L master account and verifies that the group account number entered exists in the group chart of accounts. A chart of accounts which is not yet completed can be blocked so that no company code can use it until ready. COAs can be created with single maintenance language and can be blocked

Types

1. Operational COAs: contains the list of G/L accts that we use for postings in company code
during daily activities. These are used for reporting purpose.(mandatory)

2. Group COAs: contains the G/L accts that are used by the entire corporate group. This allows the
company to provide reports for the entire corporate group. These are used for consolidation purpose.(optional) A one to one relationship exists between the group account number and the operational account number in the G/L master. 3. Country specific COAs: contains the G/L accts needed to meet the countrys legal requirements. These are used to submit reports for the country(govt)(optional) Two company codes with different chart of accounts we can consolidate their activities In that case either we need to write an ABAP programme or we need to implement the Special Consolidation Module of SAP. If both the company codes use the same chart of accounts then standard SAP reports give us the consolidate figure. Every G/L Account master record must be created at the COA level before it can be created for a Company Code. The COA segment contains information such as the Account Number, Account Name, and Account Group. Once used group COAs can be used for another operational chart of accounts, but once used country specific G/L acct cannot be used for another operational COAs Account group Homogeneous grouping of the G/L accounts in the chart of account level. Account groups are defined for the standard chart of accounts. Account group determines: - The data that is relevant for the master record. - The number interval from which the number is selected when a G/L acct is created. - The screen layout for creating G/L accts in the company code specific area.

5
An Account group controls the data that needs to be entered at the time of creation of a master record. Account groups exist for the definition of a GL account, Vendor and Customer master. It basically controls the fields which pop up during master data creation. Retained earnings account (Basic setting) Retained earnings account is an account which carries the surplus of P&L statement to the respective balance sheet. Before creating any account, first we have to create a surplus acct under Reserves and Surplus. P&L stmt acct type X- Operating profit (India) Y- Non operating profit In G/L master P&L acct system will automatically transfer P&L balances to reserves and surplus acct. Balance sheet system will automatically carry forward B/S balances to next year. If we determine during a fiscal year that mistakenly designated a G/L account as a P&L account instead of a balance sheet account, we need to change its master record. We then have to rerun the program SAPF011 to correct the balances of the G/L accounts carried forward. Fiscal year It is an accounting year with 12 posting periods & 4 special periods for which the company produces individual financial statements. Fiscal year is nothing but the way financial data is stored in the system. 4 Types of fiscal year variant (system defined) V3 April to March + 4 special periods (non calendar year &year independent K4- Jan to Dec + 4 special periods (calendar year &year independent) V6- July to June + 4 special periods (non calendar &year independent) V9- Oct to Sep + 4 special periods (non calendar &year independent) Fiscal year variant Contains the definition of posting periods & special periods. We have 12 periods in SAP and also four special periods. These periods are stored in what is called the fiscal year variant. Special periods are used for postings which are not assigned to time periods, but to the process of year-end closing. SAP does not allow the sum of the normal posting periods and the special periods to exceed 16. When there are more than 16 periods required, the Special Purpose Ledger with up to 366 posting periods may be used. The fiscal year variant only defines the amount of periods and their start and finish dates. The fiscal year variant does not include the information as to whether a period is open or closed; this is maintained in another table. The system derives the posting period from the posting date. When the posting date falls within the last normal posting period, the transaction may be posted into one of the special periods. To separate business transactions in to different periods, a fiscal year with posting periods has to be defined. Fiscal year can be 1. Year dependent 2. Year independent 3. Calendar 4. Shortened 1. Year dependent fiscal year means the start and end date of the PP of some FY will be different from the dates of other FY, and / or if some FY use a different no of posting period .for particular year only

6
we maintain fiscal year variants & for another year we want to give fiscal year variant again for next year. 2. If each fiscal year of a fiscal year variant uses the same number of periods, and the posting periods always start and end at the same day of the year, the variant is called year-independent. A yearindependent fiscal year variant can be defined as the calendar year a non-calendar year If the fiscal year is defined as the calendar year, the posting periods are equal to the months of the year. Therefore a calendar year variant must have 12 posting periods. If the fiscal year is defined as a non-calendar year, the posting periods need to be defined by assigning ending dates to each period. A non-calendar year can have between 1 and 16 posting periods. If the noncalendar year does not start at January 1st the periods of the year which belong to the former or the coming fiscal year must get an annual displacement indicator (-1, +1). We need not maintain fiscal year variants for every year. -1 if the fiscal year is later than the calendar year +1 if the fiscal year is before the calendar year 3. Calendar year If fiscal year is the same as the calendar year, then the fiscal year begins on January 1, twelve posting periods are available; the periods correspond to calendar months. We need not have to define the individual periods. The system automatically uses the calendar months. 4. Shortened fiscal year: Fiscal year that contains less than twelve months. (Year dependent & non calendar year). A shortened fiscal year could be necessary in the following cases, for example:

Establishment of a company Changeover from a calendar year to a non-calendar fiscal year, or vice versa.

In shortened fiscal year, we maintain as year dependent because we are restricting to a particular year not to other years. Activities Maintain fiscal year variant TC: OB29 Assigning fiscal year variant to company code TC: OB37 Posting period A period within a fiscal year for which transaction figures are updated. Every transaction that is posted is assigned to a particular posting period. The transaction figures are then updated for this period. Special period A posting period which is used to divide the last regular posting period for closing operations. Special periods are used for postings which are not assigned to time periods but to process the year end closing activities. We use special periods for any financial adjustment entries (book adjust, tax adjust) in the last period like auditor suggestions. The definition for fiscal year will be given in posting period variant. PPV determines which periods are open and which are closed. To prevent documents from being posted to a wrong posting period, desired periods can be closed. Usually the current posting period is open & all other periods are closed. At the end of a period it is usually closed & the next period is opened by entering a range in to the posting period variant which encompasses this period .It is possible to have as many periods open as desired. Posting period variant

7
A posting period variant controls the status (open or closed) of posting periods for document creation and maintenance. It can also control the posting status by account types and ranges of accounts within account types. Posting Period Variants make it possible to maintain the status of Posting Periods independent of the Company Code (one Posting Period Variant can be assigned to multiple company codes). The Posting Period Variant is assigned to a company code in the Company Code Global Parameters in the IMG. Relevant dates in sap Document date/ party bill date /invoice date: The date on which document is entered. This date is manually at the time of data entry. This can be in the past, current or future. Document date (day of creation of the original document). Posting date/goods receipt date /delivery date: The date on which a business transaction is transferred in to one or more accounting ledgers on document entry or Date which is used when entering the document in Financial Accounting or Controlling. When entering the document using a foreign currency ,posting date is used to determine the exchange rate if the translation date is not entered. Entry date /quality approval date: the system date of the document. Sap takes the date on the server as the entry date. This is the date which is visible on the document header. Translation date: is the exchange rate date for postings in foreign currency. Exchange rate is picked up from the exchange rate table based on this date. Value date: it the date from which terms are effected. This date can be defaulted o system date. It is mainly used for bank transactions. Base line date: it the date from which the payment terms are effected or the date from which due date is derived. Baseline date is the date from which the payment terms begin to calculate. This default can be overwritten. The R/3 system uses the document principle: Postings are always stored in document form. The document remains as a complete unit in the system until it is archived. A document is identified by the combination of document number company code fiscal year The R/3 FI document consists of a document header (information which applies to the entire document) 2 to 999 line items (information which is specific to that line item). When posting documents via the AC interface (for example from SD, MM, or other applications), FI line items are created, which are identical in almost every field.

Two of the most important control keys are: The document type for the header The posting key for the line items

Document It is a proof of business transaction or it is a result of posting in financial accounting. Document has two components - Document header - Document line item Documents can be

8
Original documents: include incoming invoices, bank statements, & carbon copies of outgoing invoices. Processing documents: include accounting documents, sample documents, & recurring entry documents. Sample & recurring entry documents are simply templates to simplify entry of accounting transactions. Accounting documents are a representation of the original documents in the sap system. Document header Document header includes document number, document dates, posting period, document currency, exchange rate. A document can have only one header. I. Document number ranges: for each document type, number ranges have to be created. Documents are numbered based on the number range defined in the document type. Number ranges are defined as internal or external and linked to a number range code in a table. Document numbers must be unique. The document number ranges define the allowable range in which a document number must be positioned & cannot overlap. One number range can be assigned to more than one document type. When creating number range we specify - number interval - whether internal or external number range - Fiscal year. Number ranges for document are company code dependent. These can be copied from fiscal years for easy maintenance every year. Number ranges are to be created in the production client. We can Transport it also by way of request but creating in the production client is more advisable Types Internal number ranges: R/3 system assigns a sequential number, which lies in the relevant number range interval. External number ranges: in this type number range is assigned by the user or by an external system. Both internal & external numbers lies in the relevant number range interval &we have to maintain two number range interval. II. Document type: (Defined at client level) - It is a key which is used to classify accounting documents &distinguishes the business transactions to be posted. - It determines the document where to be stored at the same time for which account type it is to be posted. In document type we specify number range, default exchange rate type, account type applicable for asset, customer, vendor, material, G/L acct, & control data in which we mention whether the document type should be allowed for inter company postings, negative postings & also we can make ref, and header field data as required entry also helps filling of physical document. Document line item Line item is a part of a document containing information on a single item. A document can have multiple line items ranging from 2 to 999 Line item includes - Amount - Account number - Posting key - Additional details specific to the transaction being posted. All line items within an accounting document receive a number with which they can be identified. The numbers are assigned consecutively by the system when entering the document.

9
Bulk change of line item- this function allows us to change a whole group of line items simultaneously, instead of having to change individual items in the documents. The data we can change using this function are: 1. The payment terms and payment block 2. The house bank and payment method

Posting key (defined at client level & apply for all company codes) Is a key which is used to classify accounting document and distinguish between business transactions controls the posting to accounting type assigns document numbers Two character numerical key that controls the entry of line items. The posting key: Defines the type of account (e.g., Customer, Vendor, G/L account, Material, Asset) Determines whether the entry is a debit or credit Indicates special properties (e.g. Reversal Posting Key, Special G/L transaction, etc.) Data entry screen for the line item via the field status group Posting keys are automatically derived for most of the logistics transactions while manual entry of posting key possible for FI transactions. Posting key be defaulted for Screens. The relationship between posting keys and accounts. Each posting key is linked to a specific account type and determines if the entry to that account will be a debit or credit entry. Document principle The document principle requires that one FI document is created for every business transaction. Each document receives a unique number. It is a 1:1 relationship. Field status group It is a hierarchical structure where there are all related field on clubbed under one field status group. Field status groups control the fields that are displayed while entering any document. Field status group is a group of fields with their different statuses control the field status at line item document entry. The options available is one can have the fields only for display or one can suppress it or make it mandatory. So there are three options basically... The field status group is stored in the FI GL Master & posting keys. Fields are represatory areas which lie under a line item. In any document we will have debit or credit. Debit- 70 fields Credit- 70 fields When we post a document to fill all 140 fields it requires so much time, hence fields can be suppressed, required, optional. Field requirements will be based on the account we are using. Field status group is a mandatory field in G/L creation. Any type of line item will be controlled by 4 types field status groups G/L acct field status group Acct group field status group(for G/L master) Posting key field status group Transaction type (asset accounting) Field statuses are of four types: Obligatory(required) Optional

10
Suppress Display Field status variant is a constant which groups the field status groups. Field status groups have to synchronize with acct & posting key. If a document is posted to a sub ledger account, the field status group of the reconciliation account will apply. Gate way to enter in to line item is called portal. We cant enter field status group in the customer & vendor master records& these are determined from their respective reconciliation accounts Document status Documents with a special function are indicated by a document status. Examples include sample documents and recurring entry original documents. - Normal document A- Clearing document B - Reset clearing document D - Recurring entry document M - Sample document S - Noted items V - Parked document W - Parked document with change of document ID Z - Parked document which was deleted Screen variants for document entry These are the special screens for documents for several specific functions. (Defining screen variants in enjoy screens) Account types A key that specifies the accounting area to which an account belongs. System uses five account types to control postings A- Assets K- Vendors D- Customers M- Material S- G/L account During document type creation we have to ascertain for which all account types it can be used. The account type is required in addition to the account number to identify an account because the same account number can be used for each type. Tolerance group Is an authorization group which allows the payment differences. The max amounts are defined per company code in tolerance group. Types: Maintained tolerance group: In this we give an identification i.e. we mention authorization group Null tolerance group: a group without any identification group is called null tolerance group. Every tolerance group is to be assigned to a user ID. Tolerance groups can be 1. G/L tolerance group(Clearing) 2. Employee tolerance group Tolerance group for G/L account G/L tolerance group is an authorization group which settles the amount differences of the G/L account.

11
For G/L acct clearing, tolerance groups define the limits within which differences are accepted & automatically posted to predefined accounts. The groups defined are assigned in the G/L master record. In tolerance group we mention the amount tolerances & percentage tolerances Tolerance group for employees Employee tolerance group is an authorization group which settles the line item differences for customers, vendors. In the tolerance groups for employees we give user wise upper limits for posting. - The max document amount the employee is authorized to post. - The max amount the employee can enter as line item in a customer/vendor account. The max cash discount (%) employee can grant in a line item - The max acceptable tolerance for permitted payment differences for the employee. - Payment differences are posted automatically within a certain tolerance group. Disadvantages 1. Tolerance is given at the account level not at the transaction level 2. No flexibility i.e. within the allowable limits we have to settle amount differences authorization will not be given.

more than that

Creation of tolerance group at company code level & assigning is at account level. We can create as many tolerance groups as we like. Every user can be explicitly assigned to a tolerance group. If a user is not assigned to any special tolerance group, then entries in the tolerance group _ (null) are valid for them. This is the default tolerance group. Monthly closing process in SAP. The only technical requirements of period-end closing are to close the current posting period and to open the new one. Month-end reports can be run after the posting period has been closed. There are additional business processes (e.g., valuing foreign currency open items and G/L accounts, analyzing open items and accounts that will be closed out, etc.) that should also be completed for proper control, even though they are not required for closing. The annual closing process in SAP. 1. 2. 3. 4. 5. Execute the month-end closing process for the last period. Run the balance sheet adjustment programs and make any manual adjusting entries. Generate year-end reports. Carry G/L, customer, and vendor accounts forward. Open the new posting period. G/L Master

G/L master specifies the complete structure of G/L accounts. It contains the data needed by the general ledger to determine the accounts function. G/L account controls the posting of accounting transactions to G/L accounts & the processing of the posting period. General Ledger (G/L) - sub module where financial accounting data for a legal entity is recorded. Two ways to create a G/L account.

1. Create the account at the COA level 2. create the account at company code level (Step-by-Step) 3. Create the G/L account centrally, which allows account to be created at the chart of account level and company code level at the same time.

12
Sample account: A sample account is a template that can be used to create GL accounts. When used, the information defined in the sample account is defaulted into the company code segment of the GL account being created. A sample account is not an actual account in the G/L. Company code data on a GL account master record is categorized as Account Control, Account Management, and Document Creation Control. Examples of the data included for each of these. Account Control: Account Currency Defining balance in local currency Defining the tax category Defining posting without tax allowed. Reconciliation Account for Account Type Account Management: Open Item Management Line Item Display Sort Key Document Creation Control: Field Status Group Post automatically only Company code specific area contains the data that may vary from one company code to another, such as the currency in which the account may be posted. The relationship between the Sort Key and the Assignment Field. The Sort Key defines the field(s) used to populate the Assignment field when a document is posted in the GL. The assignment field is used as a sort criterion when displaying GL account line items. Purpose of the assignment field is used to sort line items when they are first displayed. It is populated based on the definition of an accounts sort key. This field does not have to be displayed in a line layout. The lines are displayed in the order of numbers, capital letters, and lower-case letters. The sort key determines what appears in the assignment field. It is made up of at least one field on a document. It may consist of combination of complete and partial fields up to a maximum of 18 characters The assignment field is used to sort line items when they are first displayed. It is populated based on the definition of an accounts sort key. This field does not have to be displayed in a line layout. The lines are displayed in the order of numbers, capital letters, and lower-case letters. Reconciliation account When posting items to a subsidiary ledger like customers/vendors the SAP system automatically posts the same data to the general ledger at the same time. This Facilitates preparing financial statements at any time without having to transfer totals from the sub ledger to the general ledger. Each subsidiary ledger has one or more reconciliation accounts in the general ledger for example we can have one reconciliation account for domestic customers& another reconciliation account for foreign customers. Each customer account or vendor account is assigned to reconciliation account. Reconciliation account type

13
This field to indicate G/L accounts as being reconciliation accounts. Reconciliation account type definition in company code segment of G/L accounts controls all sub- ledger postings without any reconciliation for all real entries. Open item management: For accounts where open items /cleared items need to be managed, the open item management indicator in the master record is set that for account. Balance of an account with open item management is equal to the balance of the open items. Line item display: To use line item display to display the document line items from the account for line item display, the system lists all the line items for an account. This should not use Line item display for the following accounts: - Reconciliation accounts - Sales revenue accounts - Material accounts - Tax accounts Posting without tax allowed: If this indicator is selected in G/L account no tax code needs to be entered when posting to this account. If a tax code is entered, it is checked according to the tax category for this account. This Is normally used if taxable & non taxable postings are to be entered to an account at the same time. In such a case we normally set up own tax code for non taxable transactions. We can manually enter data into the assignment field& it does not effect. I.e. we can enter data manually in to the assignment field which will overwrite the entry made by the sort key. 1. G/L accounts are attached to the lowest level of the financial statement hierarchy. 2. The General Ledger receives simultaneous postings from other sub modules within FI like Accounts Receivable (FI-AR), Accounts Payable (FI-AP), and Asset Accounting (FI- AA) modules. (3) Features of the FI-GL module. Multiple currency capability Flexible real-time reporting Real-time transaction entry Views / Tabs in G/L Master: Type/ description Control data Create /bank/ interest Key word/ translation Information (COA) Information (company code) G/L account assignments for automatic postings are done at chart of accounts level. Automatic line items Automatic line items are additional lines added to documents by SAP to balance the transaction being entered. These additional lines are based on configuration of additional account assignments Examples include exchange rage differences, balance carried forward, down payments, cash discounts, and tax postings. Examples of GL accounts that are to be posted automatically through the system Stock and Consumption accounts are instances of GL accounts that Should be automatically posted to. In the GL account master record, a check box exists wherein the automatic posting option is selected called Post Automatically Only

14
Chart of accounts data on a G/L master record is categorized as G/L account number Account group Whether it is a P&L acct or B/S account Description(short text & long text) Group account number Trading partner This contains the data that is a valid for all company codes. Different options to create G/L account: 1. copy from chart of accounts 2. copy from company code 3. Copy with reference to a range of accounts. 4. copy from a sample account 5. Manual creation of account. Parking document: Parking is a type of release procedure. The document which requires release approval from the respective authorization group to eliminate wrong postings. It is a document which is generated when a document is positioned for approval from appropriate authority & then posted at a later date. Park documents can be used in different areas: - cash transactions - new employee joins - purchase transactions A parked document is a type of preliminary posting. Parking documents do not update any data in the system, such as transactional figures (except for cash management). However, we can evaluate parked documents since preliminary postings are linked to the reporting functions in financial accounting. Parked documents can be completed, checked, and then posted at a later date, even by a different entry clerk. We can park data for customer, vendor, general ledger and asset accounts. For deleted park document we can view the document header data but not line items Approval process for parked documents. An important use of parked documents is to allow for an approval process before a document can be posted. When a clerk parks a document for his managers approval, the clerk must manually notify his manager of the parked document. SAP workflow may be used to automate the approval process of preliminary postings. An invoice may be parked by an accounts clerk and a workflow message sent automatically to the supervisor. When a parked document is posted, the number is simply transferred over as the newly posted document number. In park documents we can change the document, posting, translation date, period, fiscal year (document header) but not currency Most fields in a document can be changed up until it is posted. After that, only fields that do not have a financial impact can be changed (e.g., text fields). In the document header, only the reference document and text can be changed. Fields mandated by GAAP (Generally Accepted Accounting Principles) cannot be changed (e.g., account number, amount, posting key). Steps:

15
1. Creation of parked document (F-65) 2. To check whether balance is updated or not. 3. Sending system message for cashier for release approval 4. Senior employee checks 5. To check account balance whether it is updated or not. 6. System message by senior employee, that he released the document. 7. Display changes to the released document.(FBV5) 8. Display parked documents (FBV0) Hold Document: It is a temporary document which can be hold for short period of time, when the information available is not sufficient to complete the document & post it once the information is available. These documents are used by companies like I owe you. Ex: stores person takes money in advance only cash outflow is known, for that purpose we hold the document. For hold documents we can give number range at the time of posting. We can delete the hold documents. Held documents can be reopened for making the updations & can be posted. Temporary Document Number (for Incomplete Documents) When a document is held, only a preliminary document number is assigned. The temporary document number with the name of the user who has entered the document is used to identify the document. Steps: 1. Creation of hold document (F-02) 2. Display hold documents ( F-02) Differences between parked documents and held documents Parked Documents Assigned a document number All fields can be changed. Can be viewed by any other user. Used for approval Can be viewed through line item display When we delete the park document, number will be blocked. Held Documents Temporary document number controlled by the user ID Document header data cannot be changed, other Fields can be changed. Can only be viewed by the creator Used for adjustment purpose. Cannot view through line item display No blocking of numbers Because it takes the temporary document number. Can only be viewed during document entry through Open Held Doc Held documents cant be parked

Documents linked to accounts even though amounts do not update balances Park document cannot be hold.

Sample documents:

16
Sample documents are like templates which can be taken as reference while making postings. These documents are used for year end provisions. We can post any number of documents taking one sample document as reference. It helps end users to save time in posting transactions. We have to define the number range for sample documents (X2). Sample document Cannot add new line items Not all fields are changeable Can only use one at a time

Accrual /Deferral documents: This document is replacement to sample document. These documents are used for other than year ending provisions. When a transaction takes place first & then a payment transaction it is called accrual transaction. When payment transaction takes place first & the service transaction it is called deferral transaction. To ensure that expenses are posted to the correct period, we can enter accrual / deferral documents & then reverse them in a later step. Accrual (payable): is expenditure before any key date after that key date its an expense. (Ex: rent outstanding) Deferral (receivable): is a receipt before any key date after that key date its revenue. (Ex: prepaid rent) In accrual /deferral document we mention the reversal date. & we reverse on particular date. Due to the disadvantages in sample document, accrual documents are used. 1. Employee difference: The person who makes provision & the person who makes payment & clearing are different. 2. Timing difference: if there are number of transactions then timing may be different. There is not much of difference between the accrual /deferral & sample documents only presentation difference but there will be no effect on the ledger. Difference between accrual/deferral & sample documents: Sample document 1. Amount can be changed Accrual document 1. Amount cannot be changed

2. Cannot be posted, instead it is stored & it is a 2.accrual document can be posted template which can be used as reference for postings. 3.When there is no restriction on The amount to be paid Use this type of document. we 3. When there is restriction on the amount to be can paid we can Use this type of document. 4. In accrual we create provisions in this month & reverse it in the next month. Number of people will make provisions at different dates &we can reverse at a time.

4. In sample document we cannot reverse it.

Recurring documents Are the templates which are used as reference for periodic postings like hire purchase installments in which amount & date is fixed. Number range interval for recurring documents (X1)

17
Recurring entry Static document Fields cannot be changed Posting occurs after periodic posting program is run and batch input session is executed. Recurring entries are business transaction entries that occur on a regular basis such as monthly rental expenses or insurance payments. Recurring entries can be configured and processed in SAP A) Setup of recurring entry reference document (document header, line items, validity period, run times) B) Run recurring posting program periodically (create batch input session for all the recurring entries during a period) C) Process the batch input session (system will create the journal entries). The data that can never be changed in recurring entries Posting keys Accounts Line item amounts

The posting date is determined by either the run date or the run schedule & field values can be changed in recurring document. Difference between sample & recurring documents Recurring Sample 1. No flexibility 1. Flexibility 2. Date is fixed (cash book date) 2.Date is not fixed. Reversal document: The document which is generated when we reverse a posting. Types of reversals: - individual document reversal - reversal of reverse document - mass reversal - cleared document reversal - accrual/deferral reversal For reversal of a document we have to reversal reason. Reversal reason is a reason which enables the reversal of a document. Reversals are of two types: 1. Negative reversals: It will reverse the document by reducing the transaction burden. Here it reverses without any document i.e, reversing debit with credit. 2. Alternative reversals: It will reverse the document by allowing a new transaction. Ex: Rent, salaries. Document reversal automatically reverses entries and creates a new document with reference to the original posting. Therefore, document reversal offers a better audit trail than manually adjusting entries to correct errors. We can reverse a document only if: *0 The document has no cleared line items The document contains only D, K or S items (customer, vendor or G/L items) *1 The document was posted with the FI system (not SD or MM) All specific values (such as cost center) are still valid Difference between a Traditional Reversal and a True Reversal.

account line

18
A Traditional Reversal results in a debit entry being offset by a credit entry. When viewing the account balance, we will see entries in both the debit and credit columns. A True Reversal posts a negative amount to the entry in question. When viewing the account balance, the entry appears to be removed from the system. Both reversals offer a complete audit trail, and the reversal documents are identical except for an indicator noting the type of reversal. - The original document contains no cleared items - If a reversal date is not specified, the system reverses the document using the posting date of the document to be reversed. - A new document number is created for the reversal of a document. Negative postings: Indicator that the transaction figures on the original side of the account are reset again rather than being increased on the other side of the account when documents are reversed. A precondition for negative postings is, however, that document types which allow line items to be flagged individually as negative postings have been defined. We have to define this in Customizing for document types. We must permit the negative postings per company code We have to define reasons for reversal. Advantages of reference documents: They simplify data entry and help reduce errors. Examples of reference documents Sample documents, Account assignment model (Complex Postings) Account assignment template (Enjoy Postings) Recurring document or Recurring Entry. Account assignment model can be used If the currency is defined then the model can only be used for postings in that specific currency Can use more than one when posting documents Most fields are changeable after it has been created May only be used with complex postings Account assignment template The only reference document that can be used in the Enjoy Posting screen. Created directly in the Enjoy Posting screen The posting does not need to be complete. Primarily used to post transactions to General Ledger Accounts rather than sub-ledger accounts since it does not save customer or vendor numbers. The only mandatory field is the Name that is provided by the user. Difference between a sample document and an account assignment model. Sample documents will not allow for additional line items to be added nor do they have the ability to change all of the pre-assigned fields. The account assignment model supports both features. The account assignment model allows amounts to be distributed between multiple accounts based on ratios. Sample

19
documents allow distribution of amounts by dollar amounts only - no percentage or ratio calculation is performed by the system. Reason code The reason code determines how the payment difference is handled: If the difference is going to be charged to a different G/L account or If a new item will be generated Also, the reason code determines which correspondence type is sent to the customer to notify them of the discrepancy. Difference between the Hold Data and Set Data functions. Hold Data -> data defaults into fields and is editable Set Data -> data defaults into fields and is not editable

The three primary types of data in the system Master Data is constant over a long period of time. Transaction Data is created by a transaction in the system. Transactions can be created manually or automatically. Table Data is the data that is specifically configured for a clients business. Examples of Master Data & transaction data: Invoice - (Transaction) Vendor - (Master) Goods Receipt - (Transaction) Material - (Master) GL Account - (Master) GL Account Posting - (Transaction) Interest calculation Two types: 1. Balance interest calculation(B) 2. Item interest calculation(P) Steps: A) Interest calculation global settings: 1. Define interest indicator (interest calculation type) TC :(OB46) Interest indicator is a key which controls the interest calculation i.e., it determines whether it is an balance interest calculation or item interest calculation 2. Specify the terms for interest calculation TC: OBAA Under Interest indicator we mention interest calculation frequency, calendar to be followed for interest calculation The following data is stored under the interest indicator:

The calendar type used for defining the days due for interest. You can choose between the bank, French, Japanese, and Gregorian calendars Interest rates and conditions Form for the lists

B) Interest calculation

20
3. Define Reference interest rates TC: OBAC Under ref interest rate key we mention the date from which the interest rate is effected. Reference interest rate is the rate at which we borrow or pay the money. 4. Define Time dependent terms TC: OB81 We calculate interest calculation for credit & debit items Under interest indicator we mention for debit & credit items the effective dates. 5. Define interest values TC: OB83 Under reference interest rate we mention the interest rate & the effective date. C) Interest posting 6. Maintain acct determination for interest calculation: TC: OBV2 In account determination we assign G/L accounts. D) Assigning the interest indicators, & interest calculation frequency in master records E) We run the interest TCS: Balance interest calculation General ledger: F.52 Accounts receivable: F.26 Accounts payable: F.44 - Balance Arrears calculation Accounts receivable: F.2A Without open items F.2B - With open items F.2C - Without postings Accounts payable: F.4A - Without open items F.4B - With open items F.4C - Without postings Balance interest calculation Fields in the master record There are four fields in the company code-dependent data area of master record that are relevant for balance interest calculation. In order to calculate interest on account balances, the interest calculation report references the interest indicator from the account master record. The most important specifications for interest calculation are stored in this indicator, such as the rules used for calculating interest and the interest rate. The interest indicator must belong to the interest calculation type "balance interest calculation". Interest calculation frequency In this field you enter a number of months, which determines how often the interest calculation program is to be run. However, it is only necessary to make an entry in this field if you are planning to have the system determine the interest calculation period automatically. The interest calculation period always refers to the field Key date of last int.calc. You can also define an interest calculation frequency under an interest indicator. However, the entry in the master record has higher priority. Key date of last int.calc. (Interest calculation)

21
After the interest calculation program has been run in the background, it enters in this field the upper limit of the interest calculation period. This date is used by the system to automatically determine the interest calculation period for an account. Date of last int.calc. Run In this field the report enters the CPU date of the last balance interest calculation run. This information is necessary in order to determine whether interest must be calculated for items with a value date in the past. These are items which are posted to a period for which interest has already been calculated All accounts that you want to be included in the interest calculation run must have an entry in the field Interest indicator in their master record. If you want to block an account for interest calculation, you should remove the interest indicator. The balance interest calculation program is controlled using the following specifications:

Data from the account master record. This includes, for example, the interest indicator which the report uses and data used for determining the interest calculation period for the account. Specifications stored in the interest indicator. These include, among other things, the interest rates to be used. Specifications made for the balance interest calculation run, such as selection criteria which limit the accounts to be included in the run.

Item interest calculation The interest calculation process is as follows:

First the program identifies the items on which interest is to be calculated according to the rules defined in the interest indicator, and any additional specifications we make when executing the program. The rules determine the items and transaction for which interest can be calculated, such as:
o o o

Cleared or open items only All clearing transactions or only those with a payment (thereby excluding uncleared credit memos and payments on account). Credit and debit items or only debit items. If interest is to be calculated on credit items (for example, credit memos and payments on account), it is calculated in the same way as for debit items.

The program then determines the days for which interest is to be calculated, taking into account the calendar type.
o

There are basically two factors involved in interest calculation: the lower and upper limit of the calculation period we specify for the interest calculation run, and the time period between the net due date and the date of the payment document (or the clearing date for credit memos determined per item). The program selects those items in which the period between the net due date and clearing date falls within the lower and upper limit of the calculation period. If the lower limit of the calculation period is suppressed, the system uses the value from the Last key date field in the master record as the lower limit. We can specify whether interest should be calculated as of the date of the last interest calculation. That is, only those items still open as of the date of the last run will be included in the new run. Cleared items are only included if the clearing date is later than the date of the last interest calculation.

22
o

Tolerance days may be specified in the interest indicator. These are added to the due date for net payment, but are only relevant for selecting the items to be included in the interest calculation run. Interest is always calculated as of the due date for net payment without taking into account any tolerance days. You can also define transfer days for cleared items. This is a way of making allowance for when payments take longer than usual to transfer or when the relevant accounts are not cleared promptly. Transfer days are subtracted from the date of the payment document or from the clearing date.

After determining the items on which interest is to be calculated, the program works out the amount in local currency. In doing so, it takes into account any interest rate changes within the calculation period, and if a minimum amount is specified for the interest indicator, it compares the calculated interest amount with the minimum amount. By specifying a minimum amount, you can prevent letters from being created and sent to vendors for insignificant interest amounts. Lastly, correspondence is created if the calculated interest exceeds the minimum amount. The form containing information for the correspondence is defined in the interest indicator. However, we can specify a different form in each interest calculation run.

Clearing Clearing can be defined as the process of matching debits and credits. An example is matching payments with invoice items. Clearing accounts can also be used as a temporary offset to a process e.g., A typical example would be GR/IR Account in SAP (Goods Received/Invoice Received Account) Clearing can be of three types: 1. Full clearing 2. Partial clearing 3. Residual clearing. In partial clearing (payment) it clears the original invoice with the amount and creates new line item for cleared amount. Until full amount is paid it will show as cleared item & it will display as open items. In residual clearing (Payment) it leaves the original invoice amount and creates new line item for the remaining amount. For the amount be cleared new line item will be created & the amount paid will come as cleared. Only presentation is different in both partial &residual clearing. Prerequisites for document clearing Account must be managed on the open item management. We have to tick in the in the General Ledger Master Record called Open Item Management. It helps us to manage the accounts in terms of cleared and uncleared items. An example of posting with clearing: An invoice posted to a customer's account. This invoice is regarded as an open item because at this point it is unpaid. The customer pays the invoice and the payment is allocated to it. The invoice is cleared with the payment and the resulting balance is zero. An example of account clearing: Manually clearing an open invoice with a related credit memo and payment on account. A clearing transaction always creates a clearing document. Using the posting with clearing function, we enter the document line items and then select the open items that are to be cleared. If the total amount of selected open items equals the amount of entered line items, the system clears the open items by creating one or more offsetting entries. If the total amount of selected open items does not equal the amount of entered line items, the system allows you to post the differences.

23

Posting with clearing can be done for several accounts, account types and for any currency simultaneously. The posting with clearing transaction may be performed manually or automatically by using the automatic payment program. Using the account clearing function, choose and match those existing open items from an account that balance to zero. The system marks them as cleared and creates a clearing document. The clearing document number and the clearing date is entered in the cleared open items. The clearing date can be the current date or a date that the user determines. The account clearing function will work for any open item managed account in G/L, A/R and A/P. It is generally used with bank sub-accounts and clearing accounts. With this transaction you can only clear items from one account. Since most of the time postings do not have to be made during account clearing, the clearing document usually contains no line items. However, if line items from different business areas are part of the clearing procedure, the system may require clearing entries to balance the business areas. The account clearing transaction may be performed manually or automatically by using the automatic clearing program.

Open item management: Collects the dues at the time of the posting & it controls the payments & payment authorizations. When selected (at the company code level), this setting will allow items in the account to be matched against an offsetting item and closed. The GR/IR account is an example of an account that should be managed on an open item basis. Open items are incomplete transactions, such as a vendor invoice which has not been paid. In order for an open item transaction to be considered complete, the transaction must have been cleared. A transaction is considered cleared when an offset value is posted to an item or group of items, so that the resulting balance of the items is zero. Documents with open items cannot be archived and stay in the system until all open items are cleared. Financial statement version: An FSV (Financial Statement Version) is a reporting tool and can be used To depict the manner in which the final accounts like Profit and Loss Account and Balance Sheet needs to be extracted from SAP. It is freely definable and multiple FSV's can be defined for generating the output for Various external agencies like Banks and other statutory authorities. Validations/Substitutions in SAP are defined for each functional area eg Assets, Controlling etc at the following levels 1. Document level 2. Line item level These need to be specifically activated and setting them up are complex and done only when it is really needed. Often help of the technical team is taken to do that.

Accounts payable Accounts Payable records all accounting transactions for dealings with vendors. Much of its data is obtained from purchasing (Materials Management). A/P submodule where vendor transactions are recorded and administered within FI

24
The FI-AP module is a closely integrated with the Materials Management (MM) module. The Accounts Payable module supports the Procurement Cycle. A/P is a subsidiary ledger which is used when material management module is not implemented. Used for material purchases & services. When MM module is implemented A/P is used for service vendors. Subsidiary ledger: accounting which includes a sub ledger as a debtors, creditors, or assets. Sub ledger provide more detailed information on the reconciliation account in the G/L A ledger that has the purpose of representing business transactions with customers and vendors. Sub ledgers in assets accounting are ledgers that represent the development of asset values.

Internal trading partner: is a business partner with whom we maintain the business relations to develop our business. These are like vendors, customers. A vendor is a business partner to whom amounts are payable for goods delivered or services performed. Exs: of such services or goods include goods required business services required

Vendors may be of service vendors or MM vendors, service vendors like job work, asset purchases, and professional charges,contractors. vendor accounts are made up of two areas: A vendor account is defined for all company codes at the client level. General data, such as the vendor's address, is also stored here. Postings cannot be made to the account in a company code until company code-specific settings have been made, such as the agreed Upon terms of payment. Vendor accounts are always open item management accounts (default setting) In the same way as G/L accounts, vendor accounts can be combined in various account groups so that they can be organized and managed more easily. The accounts in an account group usually have similar characteristics. For example, we can have one account group for domestic vendors, one for vendors abroad, one for affiliated vendors, and one for one-time accounts.

Account group Account group controls the data needs to be entered at the time of creation of master record. The account group controls the numbering for the Vendor master record. A number range is assigned to an account group. The account group also determines the field status group and is used to designate one time accounts. These are created at client level & we can use for different company codes. The account group determines the number interval for assigning the account number to the vendor whether or not the number in internally or externally assigned, and what fields are mandatory, suppressed, displayed and optional.

25
The three levels for field status groups that determine the screen layout for a vendor master record Account group Company code Activity type

Vendor master Contains the data of all vendors with which a company conducts business. It is a collective term for all vendor master records. The three segments of a vendor master record General data - account name, address Company code level - payment terms Purchasing data - Terms and conditions

The General Data section of the vendor master record Address and Communication Account Control(customer) Bank Details

The Company Code section of the vendor master record. Account Management Payment Data Automatic Payment Transactions Dunning data

Purchasing organization section of the vendor master record Conditions (order currency, payment terms, minimum order value) Sales Data (Salesperson, Telephone) Control Data (GR based invoice verification, evaluated acknowledgment required, automatic PO).

receipt

settlement,

A complete vendor account consists of the following three segments: General data at the client level Company code segment Purchasing organization segment

Usually at minimum, the purchasing organization segment of the purchasing organization which is assigned to the company code has to be created. Note: There may be other purchasing organizations doing business with the vendor as well. The account number is assigned to the vendor at the client level. This ensures that the account number for a vendor is the same for all company codes and purchasing organizations.

When creating customer/vendor master records, the account group is entered on the initial create screen. In financial accounting, once the customer/vendor account is created, its account group cannot be changed. However, when using partner functions in sales and distribution, in some cases the account group can be changed from, for example, an ordering address to a ship-to address

26
We can have one person making changes to a customer or vendor while another person is responsible for validating the changes, usually for critical customer/vendor changes. First we have to define the fields for dual control in the customer/vendor master records in the IMG. If we define a field in the customer/vendor master record as sensitive, the corresponding customer/vendor is blocked for payment if the entry is changed. The block is removed when a second person with authorization checks the change and confirms or rejects it. The confirmation for the changes can be made for a single customer/vendor or we can get a list. This list can be restricted by: Customer/Vendor Company code Accounts not yet confirmed Accounts refused Accounts to be confirmed by me. We can display the changes to customer and vendor master records for multiple accounts using the reports RFDABL00 or.

One time accounts: One time accounts are managed for business partners with whom business is carried out only once or rarely One special master record is needed for all one time accounts. Specific data on the business partner, such as address and bank data, is not entered in the master record but in the document itself. Reconciliation account Reconciliation account is a parallel account which will be updated parallely in general ledger whenever we post in the subsidiary ledger. A reconciliation account is a G/L account that is defined within each customer/vendor master record. By posting to a customer/vendor account, the reconciliation account balance is automatically updated. Creditor is a recon account for the vendors. Recon account Will take automatic action in parallel. In SAP we use the term reconciliation account, in normal accounting its a control account. Payment terms for vendor master can be maintained at two places accounting view purchasing view

The payment term in the accounting view of the vendor master comes in to picture if the transaction originates from the FI module. If FI invoice is posted (FB60) to the vendor. Payment terms are defaulted from the accounting view of the vendor master. The payment terms in the purchasing view of the vendor master comes in to picture if the transaction originates from the MM module. A purchase order is created in the SD module. The payment terms are defaulted in the purchase order from the purchasing view of the vendor master. Two levels for creating vendor accounts. Client level Company code

The customer and vendor code are at the client level. That means any company code can use the customer and vendor code by extending the company code view. Vendor Invoice payments can be made through 1. Manual payments without the use of any output medium like cheques etc. 2. Automatic Payment program through cheques, Wire transfers, DME (data medium exchange) etc.

27
Automatic payment program It is a back end program for giving the payment to parties like customers, vendors) automatically APP is used in order to overcome the difficulties like - manual check update - If we have number of vendors & number of invoices manual updation of check is difficult. The Payment Program is set to maximize cash discounts when paying open vendor items. It creates a list of proposed vendor items to be paid and suggests payment methods for each proposed payment. The user has the ability to make any changes before payments are made. Note: The payment program selection strategy (e.g., maximization of cash discounts) is configurable. Payment run can be done twice a day, weekly, monthly. Advantages: 1. Checks the due date automatically. 2. Maximizes the cash discount. 3. Issue a covering letter along with a check. 4. It automatically generates the list. 5. It updates the check register. 6. Pass entry & clear the party account. APP is used by cash rich companies. Payment Program Configuration - Set up paying and sending company codes - Payment methods per country - Payment method per company code - Bank Selection (rank banks, available amounts, G/L account assignment) Check Lot Configuration - Per house bank and account Running the Payment Program (application side) - Maintain parameters (company codes, payment method, next run date, vendors, Additional Log) - Schedule Proposal - Display/Edit Proposal - Create Variant for Print Program - Schedule Payments (clears vendors accounts) - Schedule Print (cuts checks) Automatic program configuration The following are the steps for configuring the automatic payment. Step 1 Co. code for Payment transaction - Define sending and paying company code. Tolerance days for payable Minimum % for cash discount Maximum cash discount Special GL transactions to be paid

28
Step 2 Paying company code for payment transaction Minimum amount for outgoing payment No exchange rate diff Separate payment for each ref Bill/exch payment Form for payment advice Sender details. Step 3 Payment methods per country Whether it is outgoing or incoming payment Check or bank transfer or B/E Whether allowed for personnel payment Required master data Doc types Payment medium programs Currencies allowed Step 4 Payment method per company code for payment transactions Set up per payment method (A method that specifies how payment is to be made: check, bill of exchange, or bank transfer.) and co. code The minimum and maximum amount. Whether payment per due day Bank optimization by bank group or by postal code or no optimization Whether foreign currency allowed Customer/Vendor bank abroad allowed Attach the payment form check Whether payment advice required Step 5 Bank Determination for Payment Transactions Rank the house banks as per the following Payment method, currency and give them ranking nos Set up house bank sub account (GL code) Available amounts for each bank House bank, account id, currency, available amount Value date specification Automatic payment program run The payment program was developed for international payment transactions with customers and vendors, and can be used for both incoming and outgoing payments. However, it is more commonly used for outgoing payments. The automatic payment process comprises several stages.

Run date: The run date is used for identifying the parameters. It is the date on which the program is to be carried out as planned. However, a program run at an earlier or later date is also possible. Next posting date: This date is needed in order to check the due date of payables. If an item is already overdue on the date of the next payment run, or would lose cash discount, the system pays the item in this payment run. The general rule for receivables is that they cannot be paid until the baseline date for payment has been reached. Such items are paid on or after the baseline date for payment, regardless of when the next payment run is scheduled for.

29

The first stage involves maintaining the parameters. You use the parameters to define which accounts and items the payment program is to include in the automatic payment run. The following facors are considered by the system in a payment run 1. payment method specifications in the IMG 2. specifications in the vendor master record s 3. information in the documents(incoming invoices) 4. specifications made when maintaining the payment run parameters. The second stage is the proposal run. During the proposal run, the system: Checks the accounts and documents specified in the parameters for due items Groups due items for payment Selects the relevant payment methods, house banks, and partner banks Proposal:it enables us to make the payment against invoices & we can give the start the payment run in the proposal. The third stage involves checking and editing the payment proposal. This step can be omitted, but you are advised to check that the data is accurate before actually running the payment program.

The fourth stage is the actual payment run( it enables us to generate the invoices) During the payment run, the system: Posts payment documents Clears open items Prepares data for the printing of payment media

The final stage is printing. Payment media are generated in this step, which means that: Payment media are printed IDocs are generated for EDI Payment data is sent to DME administration If you do not wish to work with the payment proposal, you can combine the steps "Start proposal run", "Edit proposal", "Start payment run", and "Start printout" in one step. Immediately after entering the parameters, you can create, post, and print payments.

The payment program is controlled at three parameter levels. Company Code Payment Method Bank The dates relevant for the payment program (PP) open item selection are 1. Document date of an open item (falling into the range specified in the PP parameters) 2. Baseline date (important for calculating due date and discounts) 3. Next posting date specified in the PP parameters The payment program determines and selects open items based on baseline date & payment terms. The payment program can use a different house bank for each different payment method. House bank master data must be created in advance, before assigning the house bank to a payment method in the payment program configuration. A house bank can be assigned to a business area within the payment program configuration. In customization settings for banks in the automatic payment run we can select several payment methods per country We can specify by bank and method the anticipated number of day before the bank account is debited, & we can also determine the banks to be used for payments according to postal code.

30
Payment terms: - Payment Terms are established to represent the due date for payment of invoices. - Payment terms are identified using a four character alphanumeric key. For each payment term, the system can default a Baseline Date. The Baseline date is the date from which the payment terms begins to calculate. This default can be overwritten. - Payment terms data can be changed manually when creating a transaction. The system will prompt the user with a warning message acknowledging the change. Terms of payment are conditions established between business partners to settle the payment of invoices. The conditions define the invoice payment due date and the cash discount offered for early settlement of the invoice. Within R/3, some common payment terms have been predefined; new payment terms may be created as required. Payment terms enable the system to calculate a cash discount and invoice due date. In order to perform this calculation, the system needs the following three data elements: Baseline date: The date from which the due date is derived. Cash discount periods: The period during which the discount is allowed to be taken. Cash discount percentage rate: The rate used to calculate the discount value.

When processing a document, the payment term is entered in order for the system to calculate the required conditions of payment. The payment term will be defaulted if it has been assigned on the master record, or can be entered or changed by the user during transaction processing.

General: The day limit is the calendar day up to which the payment term may apply, allowing date dependent payment terms. The description of a payment term consists of three elements: A system determined explanation which is a sales related description for printing on invoices, and a user defined explanation. Account type determines the subsidiary ledger in which the payment term can be used. If you use payment terms for vendors and customers, it is useful to maintain them using different payment term keys and then to only use them for one account type: This avoids such mishaps as changing the cash discount from 3% to 2% for terms you use for a customer without changing the terms for a vendor (unintentionally) at the same time.

Base line date calculation: Baseline Date: The baseline date is the starting date the system uses to calculate the invoice due date. The following rules apply when defining the calculation of the baseline date: The default values from which the baseline date can be determined are as follows: No Default'; Posting Date'; Document Date' or Entry Date Specifications for calculating the baseline date: The specified fixed day used to override the calendar day of the baseline date. The number of month(s) to be added to the calendar month of the baseline month.

To calculate the cash discount, a percentage rate is entered into the payment term. The number of days that the percentage is valid for is also entered on the same line. Additional fixed days or months can be added on as well. The days and months specified in the payment term are used in conjunction with the baseline date to calculate the correct discount amount for the payment date.

31

Up to three discount periods can be entered.

Day limit Day limits allow date dependent payment terms. Several versions of a payment terms key can be defined with each version having a different day limit. The day limit is the posting day up to which the payment term version may apply. In the case of payment terms that depend on whether the base date of the payment terms is prior to the 15th, a twopart payment term can be entered under the same payment term key. The payment term key is updated to include the entry of the day limit entered. In this manner, two entries exist in which different payment terms can be entered. The following payment terms require a date to be entered for the day limit: Documents with an invoice date between the 1st and the 15th and due at the end of the following months Documents with a later invoice date and due on the 15th of the following month

Installment payments

An invoice can be paid over several months using an installment plan, or a portion of the invoice amount may be retained for payment at a later date. The total invoice amount is divided into appropriate amounts as per the plan and each separate amount is then due on different dates. The system will perform the above function automatically by using a holdback/ retainage payment term. A holdback/ retainage term is defined by setting the holdback/ retainage flag and not assigning discount days or percentages. The holdback/retainage payment term is further defined using an installment number, installment percentage rate and an installment payment term. The percentage rates specified must total 100%. The system will create a line item for each installment specified. Each line item amount will be equivalent to the installment percentage rate of the total primary amount, and the sum of the line item amounts will equal the total primary amount. The line items will have payment terms as defined by the installment plan. Depending on the national regulations of your country, the cash discount base amount will be the net value (sum of G/L account and fixed assets line items, taxes not included) or gross value (including taxes). You must decide per company code or per jurisdiction code how the system determines the cash discount base amount. The cash discount amount is entered in the invoice either manually or automatically by the system using the rates in the payment terms. It can be changed even after the invoice is posted. When an open item on a customer or vendor account is cleared, the possible cash discount is posted automatically to an account for cash discount granted or cash discount taken.

Payment block Payment Control: With the help of block keys, which can be entered in line items or accounts, it is possible to block line items or accounts for payment or entry. These block keys can also be entered in payment terms. A payment method (for each country, the system has payment methods defined that you can use in that country) is entered in the line items or the accounts. Like payment blocks, payment methods can be entered in the payment terms. A block key and payment method defined in a payment term will be defaulted in the line item when the payment term is used. If you are using SD, pay special attention to note 132701 as well as note 217021.

32
Net procedure: The accounts for cash discount granted or cash discount taken are defined in configuration If you post a vendor invoice with a document type for the net procedure, the amount posted to the expense or balance sheet account is reduced by the cash discount amount. The same amount is also posted to a cash discount clearing account to clear the document. When using the net procedure, the cash discount amount is automatically posted when the invoice is posted. When you clear the document, the system carries out a clearing posting to the cash discount clearing account. If the invoice is paid after the cash discount deadline, the lost cash discount is posted to a separate account. The cash discount clearing account must be managed on an open item basis. Elements of the payment transaction Select the payment method and bank Select the items for payment Calculate the payment amount, taking account for cash discount periods. Post the payment document Print the payment medium

A payment transaction can be carried out either manually via A/P document entry outgoing payments or automatically by means of the payment program.

We can attach the check payment form &it is attached to the payment method per company code. An invoice which has been cleared by the payment program can only be reversed after the cleared line items have been reset. The payment program get bank information Vendor /customer master record A) Open item B) PP configuration ( payment method, house bank) We can change the recon account in the vendor master Reconciliation account can be changed in the vendor master provided that authority to change has been configured. Also any change we make to the reconciliation account is prospective and not retrospective. The old items and balances do not reflect the new account only the new transactions reflect the account. The bank optimization options for efficient payments within the payment program are

Optimization by bank group - Money transfer is made from the house bank to the bank of the customer/vendor as fast as possible. To use this feature, assign all banks (in the master record) to a bank group (which you define). Optimization by postal code - Selection of the house bank according to the location of the customer/vendor. Alternative payee On occasions, we might not want to send payment to a vendor (invoicing party) for a payable that exists.

33
In general, the payment recipient (the person who is going to receive the payment) and the invoice issuer (vendor) are identical. However, a payment can also be effected for an alternative payee. For this to happen, we must first specify the alternative payee. In the standard system we can specify the alternative payee in the following ways:

Entering the data (name, address, bank details, and so on) in open items, if this is the only item to be paid to an alternative payee. Entering the account number of the alternative payee in the company code-specific area of the master record of the vendor, if an alternative payee is only necessary in certain company codes for the vendor. Entering the data (name, address, bank details, and so on) in the general area of the master record of the vendor, if payments are to be made to an alternative payee.

The above information is listed in order of priority. For example, if an alternative payee is specified in open items, this has priority over the specification in the master record. The same applies to customers. If we want to enter the alternative payee in the line item, the field payee in document must be marked in the general data area of the vendor or customer master record. This makes it possible to enter the necessary master data for the payee by marking the field Alternative payee when posting to the customer or vendor account. If we clear between customers and vendors, the payment program always uses the specifications from the vendor master record. No entries are contained for one-time accounts for the payment recipient in master data. These specifications are entered during the creation of a document. The payment program then determines the payee from the information given in the document line item. You must enter the possible payment methods in the master record of the one-time account. At the client and company code level, an alternative payer/payee can be entered. The input into the company code segment has higher priority than at the client level. There are several options to use this functionality within the master record. If you select the Individual specification field, during invoice entry, you can enter individual payee/payer information on a customer/vendor that is not created in R/3. If the alternative payee/payer is an existing customer or vendor, the vendor/customer number(s) can be entered on the master record as a permitted payee/payer. During invoice entry, one of these payer(s)/payee(s) can be chosen using match codes. If an alternative payer is entered, the money to clear the due open items of the account is collected from the alternative payer. If an alternative payee is entered, the money the company has to pay to clear the items due is sent or transferred to the alternative payee (the amount normally sent to the vendor would be sent, for example to the company managing the bankruptcy).

If one company is used as both vendor and customer, then the corresponding vendor master number must be entered in the client level of the customer master and vice versa, the vendor and customer records that are to be linked may have different account numbers, once properly linked, sales invoices and purchase invoices for this company will automatically clear against each other. Tolerances for vendors. The tolerances are used for dealing with differences in payment and residual items which can occur during payment settlement. We specify the tolerances under one or more tolerance groups. & allocate a tolerance group to each vendor via the master record. For each tolerance group, we specify the following:

34

Tolerances up to which differences in payment are posted automatically to expense or revenue accounts when clearing open items The handling of the terms of payment for residual items, if they are to be posted during clearing

Based on the client requirement, the transaction can be Blocked or Posted with a Warning in the event of the Tolerances being exceeded. Tolerances are nothing but the differences between invoice amount and payment amount or differences between goods receipt amount and invoice amount which is acceptable to the client. In vendor master record it is possible to activate for duplicate invoice at document entry & we can

block a vendor to prevent financial transaction for one company code or for all company codes. Bank Reconciliation in SAP Initially the payment made to a Vendor is posted to an interim bank clearing account. Subsequently, while performing reconciliation, an entry is posted to the Main Bank account. We can do bank reconciliation either manually or electronically. We can default certain values for particular fields for e.g. company code. It is possible to default for certain fields where a parameter id is present. Go to the input field to which you want to make defaults. Press F1, and then click technical info push button. This opens a window that displays the corresponding parameter id (if one has been allocated to the field) in the field data section. Enter this parameter id using the following path on SAP Easy access screen System User profile Own data. Click on parameter tab. Enter the parameter id code and enter the value you require to default. Save the user settings. If a user attempts to make a posting to an account that has been marked for deletion When attempting to post a business transaction to an account marked for deletion, a warning message will appear. Since it is only a warning (versus a hard error), the message can be overridden by pressing the enter key and the transaction can be complete In addition to marking an account for deletion, what additional step is recommended to prevent postings It is recommended that in addition to marking an account for deletion, the account is also blocked. Blocking the account will ensure future postings are not made until the account can be deleted. We can duplicate vendor master records from being created A check for duplicates can be configured to prevent the creation of more than one master record for the same vendor. This check is configured on address match code fields and occurs when creating new accounts or when changing the address on an existing account. Credit memo:

35
A posting that reduces the balance of receivables / payables. The term credit memo refers to the credit memo from the vendor. Therefore posting a credit memo always leads to a debit posting on the vendor account. Credit memos are used if the quantity invoiced is higher than the quantity received or if part of the quantity was returned. Accounting entries are: vendor account is debited and GR/IR account is credited. Credit memos can be included in the payment program to reduce the final invoice value paid. Invoice related credit memos: Credit memos can be linked to the original invoice by entering the invoice number in the invoice reference field during document entry. In this case, the payment terms are copied from the invoice so that the invoice and the credit memo are due on the same date. Other credit memos: Payment terms in other credit memos are not valid and are due at the document date. To activate the payment terms on these non-invoice related credit memos, enter a V in the invoice reference field during document entry. Correspondence: Party statement of account for internal business partners for a specific period of time. Advantage: we can know the vendor purchases for a particular period.

Accounts receivable: Accounts Receivable records all accounting transactions related to business with customers. Much of its data is obtained from Sales and Distribution. Accounts Receivable (A/R) - sub-module where customer transactions are recorded and administered within FI. The Accounts Receivable (FI-AR) module is closely integrated with the Sales & Distribution and Material Management modules. FI-AR supports the Sales cycle Customer: A business partner from whom receivables are due for, among other things, goods delivered, services performed and rights transferred. As with G/L accounts and vendor accounts, customer accounts are also made up of two areas: A customer account is defined for all company codes at the client level. General data, such as the customer's address, is also stored here. Postings cannot be made to the account in a company code until company code-specific settings have been made, such as the agreed upon terms of payment. A/R is a subsidiary ledger which is used when sales & distribution module is not implemented. When SD is implemented A/R is used for asset sale, scrap sale other than product sales. Customer master Contains the data of all customers with which a company conducts business. It is a collective term for all customer master records. Account Group determines the numbering for a customer master record. A number range is assigned to an account group. Number ranges can be defined to force the system to automatically assign a number to a master record or to force the user to manually assign a number to a master record. Field status can be defined at three levels within the system: -customer account level

36
-company code level -activity type level. Payment terms for customer master can be maintained at two Places i.e. accounting view and the sales view. The payment term in the accounting view of the customer master comes into picture if the transaction originates from the FI module. If an FI invoice is posted (FB70) to the customer, then the payment terms is defaulted from the accounting view of the customer master. The payment term in the sales view of the customer master comes into picture if the transaction originates from the SD module. A sales order is created in the SD module. The payment terms are defaulted in the sales order from the sales view of the customer master. Three segments of a customer master record General data - account name, address, vendor ,group key Company code level - payment terms, reconciliation account, sort key, tolerance group, payment method ,dunning procedure , interest indicator Sales data - shipping information, billing information, partner functions. Two levels of a customer master record from a financial perspective Client level: Data at this level pertains to all company codes in which the customer master record is opened. Company Code level: Company specific data is entered at this level and can vary for each company code. Customer master records are used by both the Financial Accounting (FI) component and the Sales and Distribution (SD) component. If a company also uses the SD application component, we can create and maintain customer master records either together or separately as follows:

Separately for the company code Separately for the sales area (order processing, shipping, and billing information about the customer) Centrally for both the company code and sales area in one step

We need the Sales and Distribution (SD) application component in order to enter data in the sales area. There are three different ways of processing master records since they are often created and maintained by different departments. In some companies, accounting and sales personnel maintain the general area together and their own areas separately. In other companies, customer master records are maintained centrally. Payment advice notes are early notices containing detailed information about incoming payments. Payment advice notes can be used for automatically finding and allocating open items for clearing. Instead of entering selection criteria and processing the open items, all we have to do with this method is specify the payment advice number. The flow between customer and vendor involving payment advice. The customer receives goods and sends payment. The vendor sends goods and receives payment.

37
The customer executes his payment program, which generates payment advice notes. These payment advice notes are sent to the vendor, who processes them, clears the open items, generates clearing documents. We can clear customer and vendor open items from the same company together, if we crossreference the customer/vendor numbers in the master records. The system can post the difference between the two open items as a new open item. Dunning The process of automatically notifying customers/vendors that they have overdue items and requesting payment from customers with past due invoices. The 4 basic parameters of a dunning procedure 1) Dunning level Up to 9 dunning levels may be defined. A customer/vendor can only be dunned in a certain level if he has already been dunned in the previous level. Dunning level: A numeral indicating how often an item or an account has been dunned. 2) Minimum amount a user defined overdue amount of the total account balance that must be exceeded to reach a dunning level. 3) Dunning charges these charges are used to cover postage and handling of the dunning letter. Dunning charges are not reflected in the G/L. we can define dunning charges for each dunning level. 4) Dunning text a form written in SAP Script. It can be shared by more than one dunning level. What determines how often a customer can be dunned? Where is this configured? Once an account has been dunned at a certain level, it must meet the criteria at the next level before it can be dunned again. These settings are configured in the dunning area and linked in the customer master. A dunning procedure can be assigned to a dunning area or to customer/vendor master records. A customer has three items in arrears. Which open item determines the next dunning letter sent? Assuming Dunning by Level is not selected, the item at the highest dunning level determines which dunning letter will be sent. Grace period: A grace period is the period during which an overdue item will not be dunned. An item, whose days in arrears are smaller or identical to the grace period, is treated as not due for the current notice. Minimum days in arrears: Minimum days in arrears are the number of days overdue after which a dunning notice will be sent. Credit Control Areas come above the Company Code, and Dunning Areas come below the Company Code. Dunning procedure:

38
A pre-defined procedure in which we specify how customers or vendors are dunned. For each procedure, the user defines

Number of dunning levels Dunning frequency Amount limits Texts for the dunning notices

For every dunning procedure, we need to define the number of dunning levels, dunning frequency, minimum amounts and dunning activities. Dunning environment contains: 1. Company code data: we determine that whether dunning should be done by dunning area or by dunning level Reference Company code: This is used to determine the notices. form names for printing dunning

Dunning company code: If we wish to use cross-company code dunning, we must assign the company codes that we wish to include to a dunning company code. The dunning company code is assigned to itself. 2. Dunning area: it is an optional unit in the organizational structure used to group customers/vendors for dunning and it can be based for certain policies or organizational units such as divisions. It can be company as a whole or region wise or location wise. An organizational unit within a company code from which dunning is conducted. The dunning procedure is controlled and the dunning notices are sent separately per dunning area. A dunning area can represent the following:

Division Distribution channel Sales organization Business area

3. Dunning keys: A tool that identifies items to be dunned separately, such as items you are not sure about or items for which payment information exists. 4. Dunning block reasons: The reason why a certain open item or all the open items of a customer or vendor, cannot be dunned. 5. Interest: for calculating dunning interest to be calculated for customer account, in interest indicator we mention the interest rates.

39
Interest indicator in dunning procedure becomes effective if there is no interest calculation indicator entered in the master record. Otherwise the indicator in the master record has priority. If there is no indicator at either level (dunning procedure or master record), i.e. 'BLANK' is entered, then no dunning interest is calculated by the system 6. Dunning grouping: The dunning grouping key represents a rule according to which the open items of the account are to be grouped together for dunning notices. Dunning categories: 1. Dunning levels 2. Dunning charges 3. Minimum amounts 4. Dunning texts 5. Special G/L indicator Defining dunning procedure at client level but assigning dunning texts at company code level There are varying levels that can be used by the client depending upon the business relationship with their customer. a company code can have many dunning areas Dunning functions: 1. Select items for dunning 2. Calculating dunning levels 3. Calculating dunning charges and dunning interest 4. Issuing dunning notices. 5. Managing dunning history The R/3 System provides us with a tool that automatically analyzes all the open items and duns any items that are overdue. The system determines a dunning level, which is in accordance with the number of days in arrears. The dunning level determines which dunning charges and interest are charged, as well as which dunning text is selected. A dunning history keeps a record of which dunning notices have been issued. We can trigger automatic dunning for a single account (individual dunning notice), or we can have the dunning program carry out automatic dunning for a selected number of accounts. Dunning is controlled by the dunning procedure. A dunning procedure must be entered in every account that is to be included in automatic dunning. A dunning procedure that is valid for one-time customers is entered in one-time accounts. We can define as many different dunning procedures as we wish. The R/3 System comes with a number of standard dunning procedures that can be used as a template for additional procedures. we can specify how the dunning run is to be executed by entering parameters in the dunning program. we can use the parameters of an existing dunning run as a template and adjust the dates to meet your requirements. Typical parameters are the company codes and accounts that are to be included in the dunning run.

During the dunning run, accounts are selected and checked for overdue items. The system then checks whether dunning notices should be sent and assigns the relevant dunning levels. All dunning data is stored in a dunning proposal. The dunning proposal can be edited, deleted, and recreated as often as required until the accounting clerk is satisfied with the result. This step can be omitted. Dunning notices can be printed as soon as the dunning run is finished. In one step, the system prints the dunning notices and updates the dunning data in the master records and documents. Dunning history: The data recording the course of a specific dunning procedure.

40
Special General/Ledger transactions Special G/L transactions are special transactions in accounts receivable and accounts payable that are displayed separately in the general ledger and the sub ledger. This may be necessary for reporting or for internal reasons. For example, down payments must not be balanced with receivables and payables for goods and services. Consequently, they are treated as Special G/L transactions in the General Ledger (FIGL) Accounts Payable (FI-AP) and Accounts Receivable (FI-AR) application components.

Transactions involving subsidiary ledgers are tied to the general ledger through the reconciliation account defined in the sub-ledger master record. Special general ledger indicators use the subsidiary ledger master records but are connected to the general ledger via alternative reconciliation accounts. The configuration of the special general ledger indicator determines if the posting will be an actual G/L posting, a noted item in the general ledger, or a statistical entry. Special G/L transactions are already available in the standard system. However, we can change the specifications or define your own Special G/L transactions Special G/L transactions are multi-step transactions that post to different reconciliation accounts that are typically used in vendor/customer transactions. These transactions are processed this way because, for example, in the case of a down payment, the customer payment is received before an invoice is created. Since no service has been provided, the customers down payment is actually a liability to the vendor.

Examples of special G/L transactions are down payment requests, down payments, interest, bills of exchange and guarantees. In special G/L transactions, we use standard posting keys and there are different from other posting keys Customer: Debit 09 Vendor: Debit 29 Credit 19 Credit 39 The posting keys are different from other posting keys because they have the Special G/L check box selected. Special G/L indicators used are They are one character indicators (delivered standard in the system), which identify the type of special G/L transaction being executed. For example, A" indicates a down payment, and "G" indicates a guarantee. They must be entered so the system can determine the correct special G/L accounts. Special G/L Indicator : Indicator that identifies a special G/L transaction. Special G/L transactions include down payments and bills of exchange. The indicator triggers the use of an alternative reconciliation account for special business transactions in the sub ledger. These transactions are not balanced with the receivables and payables form goods and services. There are many uses for special G/L transactions. These transactions can be grouped into 3 basic categories: Down Payment Related: R/3 provides special pre-configured programs and screens which handle the request, receipt and application of down payments. They can be used in the A/P or A/R application components and are are contained on the standard R/3 menus. Down payment processing has also been integrated into the R/3 dunning and payment processing programs. Bill of Exchange Related: bill of exchange processing is used to handle country-specific requirements. R/3 contains special pre-configured programs and screens which use special G/L transaction functions to meet these requirements. Bill of exchange options are contained on the standard R/3 A/R and A/P menus and are integrated into other FI functions. Other Transactions: Other miscellaneous types of business transactions use the special G/L transaction functions. To access these types of transactions, there is an option under document processing in A/P and A/R entitled "Other". It is also possible to direct individual financial document line items to an alternate reconciliation account by using the special G/L indicator. This will control the type of processing that will take place when the business transaction is entered.

41
Special G/L transaction types: There are three types of special G/L transactions, and their relationship to the general ledger is the key distinction There are 3 ways that special G/L entries can be recorded in the system. This is controlled by the G/L indicator of the line item being entered. Real Postings are part of the balance sheet. They are postings with a freely-definable offsetting entry. Example: The posting of a down payment received. Automatic offsetting entries are transactions that are always posted to the same offsetting account. They are typically part of the balance sheet appendix. Example: Posting a guarantee. Noted items are postings that are not intended to be displayed in the general ledger but are only to remind you of outstanding payments due or to be made. Example: A down payment request.

Steps involved in the customer down payment process. Step 1 - Down Payment Request. When requesting a down payment it becomes a noted item in FI, so no actual financial document is created. (Special G/L Acct.) -----------------------------X (Noted) | Step 2 - Down Payment Receipt. The down payment is received and posted to the bank and to the customer. The down payment request is cleared with the actual down payment. Cash -------------------X | Step 3 - Service Provided/Customer Invoiced (Recon. Acct.) -------------------X | Sales Revenue ------------------| X (Special G/L Acct.) ------------------------| X

Step 4 - Clear Down Payment. The down payment is cleared against the invoice, which reclassifies the down payment to the regular reconciliation account. Step 4: A/R (Recon. Acct.) ------------------| X Down Payment Received (Special G/L Acct.) ------------------X |

Step 5 - Final Payment Received (Recon. Acct.) ------------------| X Cash --------------------X |

42
(True (True ) ) A request for down payment is a noted item. When a request for down payment is posted, the system creates a document.

Officially, the system creates a document when a request for down payment is posted, however, because it is a noted item, no transaction figures are updated in the general ledger. Instead, a onesided entry is recorded in the customer or vendor account. The system also makes an entry in the special G/L account down payment request but it creates no monetary entry in the general ledger.

Advance payment to vendors: (1) Down payment request: A down payment request is a noted item. It does not change any account balances. You can dun and pay automatically on the basis of down payment requests. (2) Down payments received: A down payment received represents a liability on your books. It thus may not change the balance of the "Receivables" reconciliation account. You manage down payments received in the alternative G/L account Down Payments Received" in the payables area of the balance sheet. (3) Customer invoice: When goods are delivered or services performed, the customer receives an invoice. (4) Apply Down Payment to Invoice: At this point the down payment is no longer a down payment. Make the offsetting posting for it. Then it can be posted as a payment to account. (5) Clear the down payment from your accounts. Note: The procedure for down payments paid is exactly the same as that for down payments received. The down payment is actually made with the payment program. Bill of exchange: Bills of exchange are a form of short-term financing. By paying an invoice by bill of exchange, your customer receives a longer payment period (three months, for example). If you wish, you can pass this bill on to third parties for refinancing . It can be discounted at a bank in advance of its due date in which case the bank would charge you interest. See the online help for more information. Bills of exchange are treated as special G/L transactions in the FI system. These transactions are therefore automatically recorded separately from other transactions in the sub-ledger and are posted to a special G/L account in the general ledger. As a result, we can display an overview of bills of exchange activity at any time. we can post bills of exchange receivable, bills of exchange payable, and outgoing & incoming checks/bills of exchange. An example of a bill of exchange receivable without charges is illustrated above: (1) The receivable is recorded in the customer's account. (2) Customer initiates payment using bill of exchange. The balance is now tracked with bills receivable rather than in normal A/R balance. (3) The bank collects the funds from the customer's account on the date specified. (4) The collected amount is deposited into your companies bank account. (5) The amount is applied to the customer's account and the appropriate accounts are cleared. Guarantees: Guarantees made are shown in the notes to the balance sheet. Guarantees received, however, are not displayed on the balance sheet. Nevertheless, it is a good idea for internal purposes to have an overview of the guarantees that we have received. In the SAP System, therefore, we can manage guarantees made and received separately from other business transactions - as special G/L transactions.

43
Controlling Controlling area : is an organizational unit under which controlling activities of cost center acctg, product costing ,profit center acctg, profitability analysis are stored & this is used for internal reporting purpose. Controlling area it is an organizational unit which represents the internal management organization structure under which controlling activities are performed. A Controlling area can have the following 2 type of relationship with a Company code a. Single Company code relation b. Cross Company code relation This means that one single controlling area can be assigned to several different company codes. Controlling can have a one is to one relationship or a one is to many relationship with different company codes. Cost element accounting: Cost elements describe the origin of costs. Cost elements are defined as either primary or secondary. Pimary cost elements arise through the consumption of production factors that are sourced externally. Secondary cost elements arise through the consumption of production factors that are provided internally (that is, by the enterprise itself). Every Profit and Loss GL account that needs to be controlled has to be Defined as a cost element in SAP. Just as in FI General Ledger Accounts Exist, in Controlling we have Cost element. Each FI General Ledger Account which is a Profit and Loss Account is Also created as a Cost element in SAP Primary Cost Elements are those which are created from FI general Ledger Accounts and impact the financial accounts e.g. Traveling Expenses, consumption account in fact any Profit and Loss GL account The primary cost element is one type of master data in controlling. Before we can create a new primary cost element, certain prerequisites need to be fulfilled: 1. Controlling area must be defined. 2. The G/L account must be defined. These cannot be created independently bcoz for primary cost element we need G/L account Secondary Cost Elements are those which are created only in Controlling and does not affect the financials of the company. It is used for internal reporting only. The postings to these accounts do not affect the Profit or Loss of the company. Categories of primary cost elements: 1 Primary costs/cost-reducing revenues: for expenditure accounts if we create cost element. 3 Accrual/deferral per surcharge: used for CO provisions 11 Revenues: used for sales accounts 12 Sales deduction: used for sales commission, trade discount. 22 External settlement: used for settlement from internal orders to G/L accounts i.e. from Co to FI Categories for secondary cost elements: 21 Internal Settlement: Cost elements of this category is used to settle order costs to objects in Controlling such as cost centers, pa segments etc.

44
31 Order/Results Analysis: Used to calculate WIP on the order/project 41 Overhead Used to calculate indirect costs from cost centers to orders 42. Assessment Used to calculate costs during assessment 43 Internal Activity Allocation Used to allocate costs during internal activity allocation such as Machine Labour etc Version: Utilization of version control, or maintaining multiple planning versions, can enhance a Co build complex planning scenarios. Enables us to perform consolidations using different valuations and run separate comparisons and simulations based on different financial statement data. Cost Center Accounting: How is cost center accounting related to profit center? In the master data of the Cost Center there is a provision to enter the Profit center. This way all costs which flow to the cost center are also Captured in the profit center. Cost centers are basically created to capture costs e.g. admin cost center , canteen cost center etc Profit centers are created to capture cost and revenue for a particular Plant, business unit or product line. What is a cost element group? Cost element group is nothing but a group of cost elements which help One to track and control cost more effectively. You can make as many number of cost element groups as you feel necessary by combining Various logical cost elements. What is a cost center group? In a similar line the cost center group is also a group of cost centers Which help one to track and control the cost of a department more effectively. You can make as many number of cost centers as you feel necessary by combining various logical cost centers Infact you can use various combinations of cost center group with the cost element group to track and control your costs per department or across departments What is the difference between Distribution and Assessment? Distribution uses the original cost element for allocating cost to the Sender cost center. Thus on receiving cost center we can see the original Cost element from the sender cost center. Distribution only allocates Primary cost. Assessment uses assessment cost element No 43 defined above to allocate cost. Thus various costs are summarized under a single assessment cost element. In receiver cost center the original cost Breakup from sender is not available. Assessment allocates both primary As well as secondary cost. What are the other activities in Cost center? If you have a manufacturing set up entering of Activity prices per cost Center/activity type is an important exercise undertaken in Cost center Accounting. What is a Activity Type? Is a unit in a controlling area that classifies the activities performed in a cost center (activity types in production cost center are machine hours or finish units) Examples of Activity Type could be Machine, Labour Utilities

45
Cost centers represent areas of responsibility/management areas that generate and influence costs. Cost objects: A cost object means a cost or a revenue collector wherein all the costs or revenues are collected for a particular cost object. Examples of this could be cost center, production order, internal order, projects, sales order What is the cost element (expense) I want to control and what is the cost object (i.e. either the production order, sales Order, internal order) I am using to control this cost element. Sounds Confusing read it again it is very simple Controlling is all about knowing the cost element and the cost object. Every time pose this question to yourself what is the cost element what is the cost object. At the end of the period all costs or revenues in the cost object are settled to their respective receivers which could be a gl account, a cost center , profitability analysis or asset. Number ranges: We create number ranges for business transactions in controlling. For every posting in CO the R/3 System generates a numbered document. The document numbers are unique to each controlling area, since each number is assigned only once. The system generates a document number for each business transaction. Business transactions are classified according to CO transactions. We must assign each transaction to a number range interval& We can define several business transactions in one number range interval. Each component in Controlling uses specific business transactions. When activating a CO component we must make sure that all business transactions used by the component have been assigned to number ranges. Otherwise we will not be able to call up the business transactions in the System. Period end closing activities: 1. Assessment: In this we allocate both primary & secondary costs, after allocation in receiving cost centers we cannot get cost element wise values. 2. Periodic posting: we can transfer only primary cost elements, sender can be any cost object i.e. it may be a cost center, order, and after allocation we can see cost element wise value. 3. Distribution: we can transfer only primary cost elements, sender should be preferably be a cost center, and after allocation we can see cost element wise. 4. Indirect activity allocation: used for allocation of quantities & values Internal orders: An internal order is used to accumulate cost for a specific project or task for a specific time period and it is therefore used for a short period with a specific deadline. Internal order will usually settle to cost centers (and not vice versa) according to the settlement rule in the order setup. Internal Orders are basically used for tracking of costs, which are Proposed to be incurred over on a short term basis and time tracking is not of much essence. E.g. an Advertisement campaign. Sales Promotion and Exhibition expenses etc. An internal order can therefore used to group all expenses incurred

46
Internal order can be of two types: 1. statistical order: no settlement only for information or decision making 2. Real order: settlement possible & can be settled to G/L account, asset, cost center. Difference between Assessment & settlement cycle: An assessment cycle distributes costs from one cost center to various other cost centers. We cannot assess from a cost center to an internal order or vice versa. Assessment cycles are only between cost centers. Settlements are used for orders. In the setup of each order is a settlement rule. In this settlement rule we tell the system to which cost centers the cost in the order must be settled. Typically we will execute the following procedure at month ends 1. Settle all orders this will settle all costs on orders to cost centers. 2. Run assessment cycles- Now that we have costs against cost centers from orders. We can distribute costs between cost centers with assessments. Costs are posted to an order. When we process a purchase order we post to the internal order and not to the cost center. We then settle the order on month ends to post to the relevant cost centers. it is very important to settle these orders otherwise FI & CO will not balance on the system. Internal orders can also be used as statistical orders. This will be specified in the setup of the order. We dont settle statistical orders. When posting costs, we will post to the cost center and the order simultaneously. Both have to be specified when posting journals or purchase orders against statistical orders. Settlement profile: (Real orders) All the costs or revenues which are collected in the Production order or Sales order for example have to be settled to a receiver at the end of the period. This receiver could be a a gl account, a cost center, profitability analysis or asset. Also read the question What is a cost object in the Section Controlling. In order to settle the costs of the production order or sales order a settlement profile is needed. In a settlement profile you define a range of control parameters for settlement. You must define the settlement profile before you can enter a settlement rule for a sender. The Settlement Profile is maintained in the Order Type and defaults during creating of order. . Settlement profile includes:1) the retention period for the settlement documents. 2) Valid receivers GL account, cost center, order, WBS element, fixed asset, material, profitability segment, sales order, cost objects, order items, business process 3) Document type is attached here 4) whether 100% validation, % settlement, equivalence numbers, variances to costing based CO-PA 5) Allocation structure and PA transfer structure is attached to the settlement profile e.g. A1 The settlement profile created is attached to the order type. Transfer or Allocation structure The transfer structure is what helps in settling the cost from one cost object to the receiver. It is maintained in the Settlement profile defined above. The Transfer structure has 2 parts: a) Source of cost elements you want to settle b) Target receiver whether it is a Profitability segment or fixed asset or cost center So basically for settling the costs of a cost object you need

47
to define the Transfer structure where you mention what are the costs you want to settle and the target receiver for that. This information you fit it in the settlement profile which contains various other parameters and this settlement profile is defaulted in the Order type. So every time a order is executed the relevant settlement rule is stored and at the month end by running the transaction of the settlement of orders all the cost is passed on to the receiver So to put in simple terms: a) We define cost object which could be a Production order a sales order b) we collect costs or revenues for it c) we determine where you want to pass these costs or revenues to for eg if the sales order is the cost object all the costs or revenues of a sales order could be passed to Profitability Analysis

INTEGRATION: Integration is the process by which data entered in one module is used by or updates another module on a real-time basis. Integration can be of two types: 1. Manual integration/sample testing 2. Module integration/ unit integration

Manual integration: The integration within the module ex: if we post in F-02 & it should update in FS10N Module integration: The integration between the modules ex: if we post any application i.e., goods receipt (MIGO) then automatically accounting document has to be generated in FI based on the module integration or integration testing. FI& MM Integration:

Plant: it is a place where materials are produced, or goods and services are provided The Plant is an operating area or branch within an enterprise. It plays an important role in material valuations, inventory management, MRP, production, costing and plant maintenance. In configuration a plant is assigned to a company code. A plant can only belong to one company code; however, multiple plants can be assigned to the same company code. Under plant we define the storage location.

48
Division: An organizational unit based on responsibility for sales or profits from saleable materials or services. Purchasing Organization: The purchasing organization is responsible for the complete processing of purchasing activities (such as requests for quotations and purchase orders). It maintains information relevant to vendors and pricing to support the most efficient and cost effective acquisition of goods. A Quotation is a document created in the Sales & Distribution module that records information about materials possibly desired by a customer or prospective customer. The material number, price and alternative items are usually included on a quotation. MM organization structure: 1. Material requisition 2. Purchase requisition 3. Enquiry quotations& price quotations 4. Purchase order 5. Goods receipt ( Inv RM to GR/IR ) 6. Invoice verification ( GR/IR to Inv RM) 7. RM consumption ( RM consmp to Inv RM) 8. production receipt ( Inv FG to COGS) Five major activities (in the order they occur) in the Procurement Cycle. Purchase Requisition (MM) Purchase Order (MM) Goods Receipt (MM) Invoice Verification (MM) Vendor Payment (FI)

1. A Purchase Requisition is a document that identifies an organizations demand for a product or service from an outside vendor. It is an internal document (i.e., it is not visible to the vendor or any other outside organization). Two ways a Purchase Requisition can be created Automatically as a result of a Materials Requirements Planning (MRP) run. Manually by a user.

2. A Purchase Order is a legal contract between a buyer and a vendor. It lists the materials or services to be purchased on specified terms and conditions (quantity, price / pricing conditions, delivery date). Four steps necessary for creation of a Purchase Order. Source Determination Vendor Selection Purchase Order Processing Purchase Order Follow-Up Invoice verification is the process of matching Vendor Invoices to the Purchase Order and Goods Receipt documents. For matched vendor invoices, a payable is automatically created in the FI General Ledger.

49
Different types of goods movements

1. Goods receipts 2. Goods issues, and 3. Transfer postings.

Three different types of Materials Management documents. Order documents Goods receipt documents Invoice Receipt documents

1. Order documents can be viewed only in Materials Management. 2. Goods and Invoice Receipt documents can be viewed from both Materials Management and Financial Accounting modules. An Outline Agreement documents a long-term arrangement with a vendor to provide materials or services at an agreed price. It is valid for a period of time or until a pre-defined total quantity or total value is reached. Different types of Outline Agreements are Contracts and Scheduling Agreements A Goods Receipt document is created when goods are received at a plant/warehouse. At this time, an accounting document is created to make a General Ledger entry, and a materials document is created to record changes in physical inventory. When invoices are received from a Vendor, an Invoice Receipt document is created in the system. This document can be linked to a Purchase Order, a Goods Receipt, a Delivery Note, or a Vendor. In addition to the materials document, an accounting document is created, which updates the relevant Vendor Account (sub-ledger) and General Ledger Accounts. Invoice verification provides a link between Materials Management and the Financial Accounting, Controlling and Asset Accounting modules. When a Vendor invoice is posted in the system, 5 things will happen An Invoice Receipt document is created The Material Master record is updated when appropriate. The Purchase Order History is updated when appropriate. Entries are posted to the appropriate General Ledger Accounts The Vendor account (Sub-ledger) is updated.

Vendor Invoice is posted the following accounts are effected A debit is posted to the GR/IR Clearing Account and a credit is posted to the Vendor Account. At the same time, a credit is posted to the appropriate General Ledger Reconciliation Account (i.e., A/P account) assigned to the Vendor. Four types of variances in Invoice Verification are Quantity Variance Price Variance Order Price Quantity Variance Schedule Variance

50
The three-step verification (3-way match) is the standard procedure for posting procurement transactions in FI. The procedure contains the following three steps: Purchase order this transaction is completed in MM. No postings are made in FI. Goods receipt to update the inventory, a material document is created in MM. At the same time, a document is created in FI with which the value of the goods is posted to the materials account (debit) and the goods receipt/invoice receipt account (credit) in the general ledger. Invoice receipt the vendor invoice is posted in MM, which automatically creates a document in FI. The FI document contains the invoice amount that is posted to the goods receipt/invoice receipt account (debit) and the vendor account (credit). The last two steps can be completed in reverse order, depending on the order in which the goods and the invoice are received. The goods receipt/invoice receipt account ensures that goods were received for each invoice and vice versa.

At chart of account level FI-MM, FI-SD account determination settings are done. Additional settings which are required while maintaining or creating the GL codes for Inventory accounts are: In the Inventory GL accounts (Balance sheet) we should select the Post automatically only tick. It is also advisable to maintain the aforesaid setting for all FI-MM accounts and FI-SD accounts. This helps in preserving the sanctity of those accounts and prevents from having any difference between FI and MM, FI and SD. Valuation area: Is the level at which material valuations are carried out. It corresponds to either a single plant or all plants within a company code. Material group: grouping of materials and services according to their characteristics. GR/IR account: GR/IR is an interim account. In legacy system if the goods are received and the invoice is not received the provision is made, in SAP at the Goods receipt It passes the accounting entry debiting the Inventory and crediting the GR/IR Account .Subsequently when an invoice is recd this GR/IR account is debited and the Vendor account is credited. That way till the time that the invoice is not received the GR/IR is shown as uncleared items. The GR/IR (Goods received/invoice received) clearing account program reclassifies the entries in the GR/IR account as either assets or liabilities for reporting purposes. At the end of a period the company can be in a situation where goods have been received but an invoice has not, or vice versa. Therefore, there may be a debit or credit balance in the GR/IR account. The GR/IR account is used to post to whenever goods that are not get invoiced have been received or when invoice arrive by the delivery of goods. During the time between the invoice being created & delivery of goods, there can be timing difference, in order to accommodate this time difference a GR/IR account is maintained temporarily to record the transactions. Entire process of Invoice verification from GR to Invoice verification in SAP with accounting entries. A goods receipt in SAP for purchased material is prepared referring a purchase order.

51
When goods receipt is posted in SAP the accounting entry passed is:Inventory account Debit GR/IR account credit A GR/IR (which is Goods receipt/Invoice receipt) is a provision account which provides for the liability for the purchase. The rates for the valuation of the material are picked up from the purchase order. When the invoice is booked in the system through Logistics invoice verification the entry passed is as follows:GR/IR account debit Vendor credit Tolerances for Invoice verification The following are instances of tolerances that can be defined for Logistic Invoice Verification. 1. Small Differences 2. Moving Average Price variances 3. Quantity variances 4. Price variances Based on the client requirement, the transaction can be Blocked or Posted with a Warning in the event of the Tolerances being exceeded. Tolerances are nothing but the differences between invoice amount and payment amount or differences between goods receipt amount and invoice amount which is acceptable to the client. Valuation and Account assignment in SAP This is actually the link between Materials Management and Finance. The valuation in SAP can be at the plant level or the company code level. If we define valuation at the plant level then we can have different prices for the same material in the various plants. If we keep it at the company code level we can have only price. Across all plants. Valuation also involves the Price Control .Each material is assigned to a material type in Materials Management and every material is valuated either in Moving Average Price or Standard Price in SAP. These are the two types of price control available. Valuation class: TC: OMSK The valuation class allows the user to group together materials with similar properties so they can be managed under the same stock account. Examples of Valuation Class (a) Finished Products (b) Raw Materials (d) Semi-Finished Products The Valuation Class in the Accounting 1 View in Material Master is the Main link between Material Master and Finance. This Valuation Class

52
Along with the combination of the transaction keys (BSX, WRX, GBB, PRD) defined above determine the GL account during posting. We can group together different materials with similar properties by Valuation class. Eg Raw material, Finished Goods, Semi Finished We can define the following assignments in customizing: 1 .All materials with same material type are assigned to just one valuation Class. 2. Different materials with the same material type can be assigned to Different valuation classes. 3. Materials with different material types are assigned to a single valuation Class. Once a material is assigned to a valuation class in the material master record, we can change it only if the stocks for that material are nil. If the Stock exists for that material, and then we cannot change the valuation class. In such a case, if the stock exists, we have to transfer the stocks or issue The stocks and make the stock nil for the specific valuation class. Then Only we will be able to change the valuation class. Valuation grouping code/ valuation modification key/valuation modifier: If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), then we assign different valuation grouping codes to these valuation areas. Then we must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code. In TC: OMWD (define valuation grouping code) we give a link between the valuation area, company code, chart of accounts, valuation grouping code. If the valuation area &plant are the same, plant is assigned to company code, with that we get the link between company code, valuation area, chart of accounts. FI& MM integration is based on three rules: 1. In material master we specify valuation class 2. For valuation class we assign G/L accounts based on the nature of transaction. 3. At the time of material receipt /issue, the stores person enters the movement type, material number & quantity, and then accounts will be updated automatically based on the account assignment to valuation class, which is specified in material master. Transaction keys / internal processing key/ account /event keys: The transaction keys are used to determine accounts or posting keys for line items which are created automatically by the system. The transaction keys are defined in the system and cannot be changed by the user (56 keys) Posting transactions are predefined for inventory management and inventory verification transactions relevant to accounting. Transaction keys are relevant for posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. We need not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management).only we have to do is to assign the relevant G/L account to each posting transaction. FI MM settings are maintained in transaction code OBYC. Within these there are various transaction keys to be maintained like BSX,WRX,GBB,PRD etc. In each of these transaction keys you specify

53
the GL accounts which gets automatically passed at the time of entry. Few examples could be: BSX- Stands for Inventory Posting Debit GBB-Stands for Goods Issue/Scrapping/delivery of goods etc PRD- Stands for Price Differences.

FI- SD integration FI-SD account determination? The FI-SD account determination happens through an access sequence. The system goes about finding accounts from more specific criteria to less specific criteria. Thus first it will access and look for the combination of Customer accounts assignment grp/ Material account assignment grp/ Account key. If it does not find account for the first combination it will look for Customer account assignment grp and account key combination. Further if it does not find accounts for the first 2 criterias then it will look for Material account assignment grp/Account key. If it does not find accounts for the all earlier criterias then finally it will look for Account key and assign the GL code. Thus posting of Sales Invoices into FI are effected on the basis of a combination of Sales organization, Account type, or Customer and Material Account assignment groups and following are the options available. a. Customer AAG/Material AAG/Account type b. Material AAG/Account type c. Customer AAG/Account type For each of this option you can define a Gl account. Thus the system uses this gl account to automatically pass the entries. Five steps in the Sales Cycle Sales Order : SD Module Deliver Note : SD Module Goods Issue : MM Module Billing Document : SD Module Receive Payment: FI Module

Of the five steps listed above, the following generate accounting documents Goods Issue: Debit COGS and Credit Inventory Billing Document: Debit Accounts Receivable and Credit Sales/Revenue Payment Receipt: Debit Cash and Credit Accounts Receivable

Activities in the Sales Cycle Inquiries, Quotations, Sales Order Processing, Credit Management, Delivery Processing, Goods Issue Processing, Billing Document Processing, Incoming Payment Processing, Automated General Ledger Update Inquiry: An Inquiry is a document created in the Sales & Distribution module that represents a query from a customer or prospective customer.

54
Quotation: A Quotation is a document created in the Sales & Distribution module that records information about materials possibly desired by a customer or prospective customer. The material number, price and alternative items is usually included on a quotation. Sales order: A Sales Order is a contractual agreement between a Sales Organization and a customer concerning goods to be delivered or services rendered. Delivery note: The Delivery Note is a document created in the Sales & Distribution module that initiates the shipping activities associated with delivering materials to a customer When a Sales Order is processed, the system automatically executes the following functions The system automatically executes: Credit Checking Pricing Material Availability Checking Transfer requirements to Materials Requirements Planning (MRP) Shipping Point and Route Determination A Goods Issue is a document posted in the Materials Management module that is used as the source document for recording changes in stock levels associated with delivering materials to customers and for recording the financial impact of such transactions in the General Ledger. A Billing Document is a document posted in the Sales & Distribution module, which supports the creation of Customer Invoices, Credit or Debit Memos, and the recording of the financial impact of these transactions in the General Ledger. As a result of a Billing Document, integration to the Financial Accounting module occurs with the automatic creation of an Accounting Document containing the following accounting entries: Debit to the Customer Account and the appropriate General Ledger Reconciliation Account assigned to it. Credit to the appropriate General Ledger Revenue Account.

Asset Management:

Asset management - includes the entire lifetime of the assets from purchase order or the initial acquisition through retirement. To a large extent the system automatically calculates the values for depreciation, interest, insurance. It determines all masters & values relating to assets in the organization. Asset management helps to manage the fixed assets in a proper way & in calculating the depreciation timely. It is a sub module in FI , it serves as a subsidiary ledger to the FI General Ledger, provides detailed information on transactions involving fixed assets. Asset management provides an organizational structure for assets. Chart of depreciation: Chart of depreciation is the top hierarchy in Asset management; it gives a complete structure for depreciation areas & contains the list of depreciation areas. Under the Chart of depreciation all the

55
depreciation calculations are stored. COD cannot be created independently so we have to copy the COD All general ledger accounts are defined in the chart of accounts. FI-AA works with the chart of accounts assigned to the company code in FI. we can select this according to our requirements (for example, global, industry-specific, or country-specific charts of acounts). As the chart of depreciation is country-specific, SAP provides model charts of depreciation for many countries. These contain pre-defined depreciation areas, but we can also define our own chart of depreciation (by copying and changing). Each depreciation area represents a specific type of valuation (for example, book depreciation or tax depreciation). we can also define your own depreciation areas in the chart of depreciation. Each company code uses one chart of accounts and one chart of depreciation. All or several company codes can work with the same chart of accounts and the same chart of depreciation. In general, we are required to calculate values for assets for different needs, both internal and external (such as book depreciation and cost depreciation). Therefore, the Asset management component enables to manage values for assets in parallel in up to 99 depreciation areas. The chart of depreciation, therefore, is a directory of depreciation areas organized according to business management requirements. A depreciation area is always assigned to only one chart of depreciation. Chart of Accounts/Chart of Depreciation The assignment of a company code to a chart of accounts is independent from its assignment to a chart of depreciation. This means that several company codes can use the same chart of accounts, although they have different charts of depreciation (and vice versa). In the General Ledger, we define different charts of accounts. Each company code is assigned to exactly one chart of accounts. The chart of accounts is used for the account assignments within Asset management. The account assignment is controlled by means of the asset class in Asset management. We have to specify an account determination in each asset class. In this account determination, we specify the G/L accounts in which automatic posting takes place for different transactions. The most important control feature in the Asset accounting company code is the chart of depreciation . It contains the parameters (such as the depreciation keys) that are used for calculating asset values in a given country. We have to assign each company code, in which assets are managed, to exactly one chart of depreciation. An Asset Accounting company code can have one of the following statuses:

Production status: Transfer of legacy asset data from your previous system is finished. We can only change values by posting. Legacy data transfer status: we can enter and change values using legacy data transfer. Posting is not possible. Test status: we can change values by legacy data transfer or posting.

Copy chart of depreciation

56
To minimize the time and energy involved in Customizing, country-specific defaults are provided in the standard system where possible. COD cannot be created independently so we copy from reference chart of depreciation.

Depreciation area: it is just like a diary which consists of complete information about depreciation. Depreciation areas determine the type of calculation methods for depreciation. Depreciation areas are created at chart of depreciation level. Examples of depreciation areas: 1. 2. 3. 4. Asset class: It is a variant which consists of information about account determination, screen layout, number range for creating assets. The asset class is the main criterion for classifying assets & consists of complete structure for creating the asset master. Every asset must be assigned to only one asset class. Examples of asset class are Plant& Machinery, Furniture Fixtures, and Computers etc. The asset class also contains the GL account which is debited when any asset is procured. It also contains the GL accounts for depreciation calculation, scrapping etc Whenever we create an asset master we need to mention the asset class for which we are creating the required asset. In this manner whenever any asset transaction happens the GL accounts attached to the asset class is automatically picked up and the entry passed. Fixed assets are categorized into asset classes, for example, vehicles, furniture, machines. The asset class consists of a master data section and a depreciation area section. Asset classes are created at client level. They are then assigned to at least one chart of depreciation, so we can complete the asset class with default values for the depreciation areas. we can suppress individual depreciation areas in each asset class, for example investment support areas which are only applicable to certain classes. For each depreciation area, the depreciation attributes for the assets can either be proposed with the option of changing, or they can be mandatory. Several charts of depreciation can also be assigned to an asset class. This ensures that the asset class catalog is uniform despite using different charts of depreciation The asset class is the main criterion for classifying assets. Each asset has to be assigned to only one asset class. we can specify certain control parameters and default values for depreciation calculation and other master data in each asset class. Assets that are to appear in different places/balance sheet items (for example, buildings and machines) have to be assigned to different asset classes. There is also at least one special asset class each for assets under construction and low value assets. we can also create separate asset classes for intangible assets and leased assets. There are separate functions available for leasing.

Book depreciation: for external reporting purpose Tax depreciation: for tax reporting Group depreciation: for consolidation purpose costing depreciation : for internal reporting

Account determination

57
It is just like a tree for maintaining the data flow between the G/L & asset management we have to maintain the account determination. It determines the type of asset & it gives us framework to maintain asset classes & to maintain the main assets & sub assets. Asset management rules: 1. 2. 3. 4. Sub asset is to be created with reference to main asset. Main asset is to be created with reference to asset class. Account determination is specified in asset class. For account determination we assign G/L accounts.

Integration between the G/L & asset management is with reference to account determination.

Bank accounting: Bank accounting is ,however ,not a true subsidiary ledger , like A/P ,A/R, and asset accounting ,since it does not have its own set of sub ledger accounts. Rather, it posts directly to G/L accounts. Unlike customer, and vendor master records, the bank master records may be maintained on the configuration side in SAP. They are also created on the application side in the Banking and Treasury sections. House bank: A house bank refers to the bank a company uses for receivables and/or payments. It is any bank with which company code does business. Each house bank contains a companys bank accounts. It also contains a bank key that defines address and control data for the bank. The house bank establishes a link between the various G/L cash accounts and the actual bank accounts. A House Bank is a bank where a company code has an account(s). Each bank account is represented in the SAP System by a combination of house bank ID and account ID. This combination is then entered in a G/L account and represents the bank account in the general ledger. There is thus a relationship: Bank account at house bank <--> combination house bank and account ID <--> G/L account The represented relationships should always be a one-to-one relationship. Relationship between a bank account and a G/L account master record A G/L account master record must be created for each bank account. The house bank and account ID must be entered in the GL account master record to ensure the accounting transactions involving the bank account will be reflected in the general ledger Bank country key Identifies the country in which the bank is located. The country key defines the rules according to which bank data, such as the bank and account numbers, is to be validated.

Bank key The Bank Key is a unique country-specific code. The system uses a combination of the Country Code/Bank Key to identify the house bank.

58
Account ID. Each of the bank accounts created within a house bank must be assigned a unique freely definable fivecharacter Account ID. The Account ID is used for the payment program specifications and in the account master records to make a reference to the bank account. This account ID together with the ID for the house bank uniquely defines a bank account. Bank directory The bank directory contains the addresses and valid control data (such as Swift code) of all banks used in the SAP System. The bank directory can either be: Automatically imported, as long as the bank directory is available on diskette and an import program exists for this data Or manually created If a bank is set up in the bank directory, this information could then, for example, be accessed when entering the bank information in a customer or vendor master record. You would only need to enter the country of the bank and the country key; the system would determine the name and address in the background. Data entry in the bank directory: Automatically, if master data exists for the Bank Directory on tape or disk. ). Data can also be manually entered when creating a customer or vendor master record, a one-time account, or by directly creating an account. The Bank Directory contains complete details about each house bank. Bank transfers are used quite extensively in many countries. This slide contains an overview showing the programs which are responsible for various postings. Outgoing bank transfers: The payment program creates the bank transfer and posts in to the outgoing payment account. At the same time, the open vendor items are paid. The cash flow appears on the account statement and the bank accounting session creates the posting "Outgoing cash to bank". Incoming bank transfers: Incoming bank transfers appear on the bank statement. The account statement function posts the incoming cash using the bank accounting session. The posting record is "bank to incoming cash". The sub ledger accounting session clears the paid items in the customers account. The account statement function obtains the assignment information from the "notes to payee" field. SWIFT The Society for Worldwide Interbank Financial Telecommunication. Within the context of international payment transactions, the SWIFT code (standard throughout the world) enables banks to be identified without the need to specify an address or bank number. SWIFT codes are used mainly for automatic payment transactions. Defining House Bank: 1. House bank master data: Bank country, Bank key 2. Bank data: Bank name, region, street, city, bank branch, SWIFT code bank group, bank number. 3. Data medium exchange: bank number, account number, ISO currency code. The International Organization for Standardization. (ISO)

59
Organization that develops international standards to support commerce, science, and technology. 4. EDI partner profiles Bank accounts: 1. Account Id 2. Bank accounting data (bank account number, currency, G/L account. Foreign currency transactions 1. Currency: medium of exchange of value The date format can be defined by the country. 2. Exchange rate: it is the relation between two currencies Or the rate which is used to translate an amount in to another currency. The following exchange rate types exist - Buying rate (G) - Bank selling rate (B) - Average rate (M) - Historical exchange rate - Key date exchange rate. For posting & clearing the system uses the exchange rate type M (average rate).This exchange rate type must be entered in the system & we must enter the exchange rates for this type. Exchange rate in the system serves the following purposes: 1. posting & clearing 2. To translate amounts posted or cleared in foreign currency or to check a manually entered exchange rate during posting or clearing. 3. Foreign currency: a currency that differs from the company code currency is called foreign currency. Prerequisites for posting a document using foreign currencies. Local currency must be defined in the Company Code Global Parameters The foreign currency must be defined in the Currency Code Table A translation ratio must beset between the foreign and local currencies An exchange rate must be defined between the foreign currency and the local currency in the Exchange Rate Table 4. Average rate: A settlement exchange rate used in foreign exchange transactions. It is the arithmetic mean between the bank buying rate and bank selling rate. 5. Translation ratio: the relationship between the two monetary units of foreign currencies. A translation enables SAP to process extremely large or small exchange rates that would exceed the maximum allowable number of digits (i.e., 9999.99999 or 0.00001). 6. Bank selling rate (B): The rate at which a bank offers goods, foreign currency, or securities.

60
When bank sells Indian currency with foreign currency then it will be considered as bank selling i.e. we are selling foreign currency. 7. Bank buying rate (G): The rate at which a bank buys goods, foreign currency, or securities. When bank buys Indian currency & give us US $ then it will be considered as bank selling i.e. we buying the foreign currency. Conversion of Rs to another currency: Bank buying - Rs to $ Bank selling - $ to Rs Bank selling is more than bank buying.

8. Exchange rate difference: the amount arising where a foreign currency amount is translated in to
different exchange rates.

9. conversion factor: determines conversion rates for converting currency rates .its works like ratios
us$ : Inr (1:45) Direct quotation/price notation: a currency value expressed in units of the local currency per unit of foreign currency.1 Usd =0.925 Inr Indirect quotation/volume notation: a currency value expressed in units of the foreign currency per unit of local currency. 1Inr =1.808 Usd Relevant currencies in SAP Currency: it is a medium of exchange of value. A company code can have 3 currencies in total. One which is called the local currency (i.e. company code currency) and 2 parallel currencies can be configured. System has the flexibility to report in the different currencies. In case if 2 currencies are configured. (Company code currency and a parallel currency) there is no need for an additional ledger. In case the third parallel currency is configured and is different than the second currency type, we need to configure additional ledger. Local currency: The currency of a company code in which ledgers are maintained. When we post a document R/3 always track the local & transaction currency. Group currency: The currency which is used for consolidation statements. This currency is defaulted in the client settings. Global Company currency: A currency which is used for internal trading partner. The currency of a company that belongs to a corporate group. Hard currency:

61
The currency which is used in countries with high rates of inflation. If company have operations in 2 countries& if we post a document in one currency it will automatically updated in other currency whichever we selected as hard currency. Transaction currency: The currency in which the transactions are posted. Index based currency: A currency which used in some countries with high inflation as a comparison currency for purposes of statutory reporting. An alternate payment currency is a currency that is specified in the header of a payable or receivable. When specified, the open item will be paid in the alternate currency not the document currency. It is typically used when consolidating payments into a single currency or when the document currency is difficult or too expensive to obtain. A base currency is set up to eliminate the need for entering every possible exchange rate combination into the exchange rate table. A base currency is established on the exchange rate type table for a specific exchange rate. The base currency and base rate are then used to translate from Currency A to the base currency and then from the base currency to Currency B. The available currency types are transaction, group, hard, index, global, and company code (local). The list is not exhaustive as other modules may also have their own currency types (e.g., controlling area currency). Examples If an account has been set up for a USD company code with account currency USD. When postings are made to this account, the transaction will be managed in what currency? USD - If the currency specified on an account is the same as the local currency (the company code currency), then the transactions posted to the account are managed in the local currency. If an account has been set up for a USD company code with account currency MXN. When postings are made to this account, the transaction will be managed in what currency? Both MEX and USD - If the currency specified is not the same as the local currency, then transactions posted to the account are posted in the specified foreign currency (MXN), and the local currency (USD). Document obtain exchange rate information From the Exchange rate table From a manual entry in the document exchange rate field Exchange rate types are used for foreign currency revaluations and postings. B (Bank Selling Rate) G (Bank Buying Rate) M (Average Rate) - The default rate type for posting documents. EURO - Used for exchange rates between EU member nation currencies (e.g., DEM:FRF) EURX - Used for exchange rates between an EU member nation currency and a non-member nation currency (e.g. DEM:USD) The exchange rate difference key is defined in the account master records of G/L accounts managed in foreign currency. It is the key that defines which gain/loss account is updated when the G/L account is revalued.

62
An exchange rate difference accounted for when posting and clearing an invoice in foreign currency The exchange rate difference between the invoice and payment is accounted for in a gain/loss account defined by the exchange rate difference key. It is posted automatically. Accounts managed in a foreign currency are valued. Each account managed in foreign currency is defined with an exchange rate difference key. This key identifies a valuation gain/loss account that is updated when the account is valued using program RFSBEWOO. The valuation process itself takes the difference between the original exchange rate used in the transactions and the current exchange rate and posts the difference to a gain or loss account. Difference between valuation of open items and valuation upon receipt of payment. When valuing open items, the system will post any differences to an unrealized gain/loss account. When payment is actually received, the difference becomes a realized gain/loss. Foreign currency valuation: To valuate open items in foreign currency & foreign currency balance sheet accounts as part of the closing operations. A procedure for determining at a key date the value of the current assets and liabilities posted in foreign currency. Assets and liabilities are valuated using the unit account method of valuation which means that the individual open items are valued. If this is not possible (because the account is not managed on an open item basis) the balance of the account is valuated instead. To know the exchange gain / exchange loss arising from fluctuations in exchange rates we do foreign currency revaluation in the month end and post the gain/loss to respective accounts so that there will not be nay effect on the balance sheet. Valuation can be month end valuation or year end valuation. If there are number of foreign currency term loans in that case instead of prolong the risk /loss to the last month &if there are number of fluctuations then we do month end revaluation. If fluctuations are less then we do year end fluctuations.