sap financial

SAP FINANCIAL Abstract

A sound foundation is necessary to compete and win in the global marketplace. The SAP ERP application supports the essential functions of your business processes and operations efficiently and are tailored to specific needs of your industry. SAP ERP, an application included in SAP Business Suite software, delivers these solutions

The world of finance and accounting is radically changing – convergence of accounting standards, greater expectation for transparency, more demand by your line of business partners for clarity. SAP can help.

With more than 30,000 best-run businesses in over 120 countries running our 45 country specific versions, SAP has enabled companies like yours to thrive in a business environment characterized by intensified competition, uncertain market conditions, and increased regulatory oversight.

SAP ERP Financials provides modular applications that enable our customers to tailor SAP solutions to your specific business needs:

• Core accounting and reporting capabilities • Financial supply chain management • Treasury • Shared services

These modular solutions help you quickly implement according to your current business needs, showcase quick ROI, and enable you to prepare for the future. Learn more

about the SAP ERP Financials features and functions, business benefits, and our many successful customers.

Introduction

To best serve customers, organizations are focusing more on the agility and speed of delivering products and services. The efficiency of the entire operational process chain impacts an organization's ability to serve its customers well. Operational excellence is the ability of an organization to achieve a high level of customer service, while reducing operating costs. An organization can then run its business at the speed of change with more agility, from its suppliers to its customers, no matter which changes occur in the market and in demand.

For many organizations, the SAP ERP Operations solution has become the software backbone that contributes to excellent performance supporting end-to-end operational processes in all key areas: procurement and logistics execution, product development and manufacturing, and sales and service. This excellence is a culmination of SAP's experience over more than 30 years, with thousands of successful customers in more than 25 industries.

With SAP ERP Operations, your organization can realize its full efficiency and cost-effectiveness potential. With smoother day-to-day operations, you can maximize your profitability, free up resources and budget so that you can invest more in innovation. Gaining competitive advantage, you can look toward the future, and operate as a best-run business over the long term.

With SAP ERP Operations, you can:

Automate and streamline operational processes with greater adaptability.

Increase productivity in your operations with a role-based solution and centralized information.

Extend collaboration to all value chain partners.

Improve operations performance with strategic business insight

C:\Program Files\Neevia.Com\Document Converter\temp\5373480_Enterprise_Structure__Master_Data.doc Page 1 of 13

SAP R/3 Enterprise Structure and Master Data (Financial)

DRAFT as of 02/25/10


SAP FINANCIAL Abstract

A sound foundation is necessary to compete and win in the global marketplace. The SAP ERP application supports the essential functions of your business processes and operations efficiently and are tailored to specific needs of your industry. SAP ERP, an application included in SAP Business Suite software, delivers these solutions

The world of finance and accounting is radically changing – convergence of accounting standards, greater expectation for transparency, more demand by your line of business partners for clarity. SAP can help.

With more than 30,000 best-run businesses in over 120 countries running our 45 country specific versions, SAP has enabled companies like yours to thrive in a business environment characterized by intensified competition, uncertain market conditions, and increased regulatory oversight.

SAP ERP Financials provides modular applications that enable our customers to tailor SAP solutions to your specific business needs:

• Core accounting and reporting capabilities

• Financial supply chain management

• Treasury

• Shared services

These modular solutions help you quickly implement according to your current business needs, showcase quick ROI, and enable you to prepare for the future. Learn more about the SAP ERP Financials features and functions, business benefits, and our many successful customers.

Introduction



To best serve customers, organizations are focusing more on the agility and speed of delivering products and services. The efficiency of the entire operational process chain impacts an organization's ability to serve its customers well. Operational excellence is the ability of an organization to achieve a high level of customer service, while reducing operating costs. An organization can then run its business at the speed of change with more agility, from its suppliers to its customers, no matter which changes occur in the market and in demand.

For many organizations, the SAP ERP Operations solution has become the software backbone that contributes to excellent performance supporting end-to-end operational processes in all key areas: procurement and logistics execution, product development and manufacturing, and sales and service. This excellence is a culmination of SAP's experience over more than 30 years, with thousands of successful customers in more than 25 industries.

With SAP ERP Operations, your organization can realize its full efficiency and cost-effectiveness potential. With smoother day-to-day operations, you can maximize your profitability, free up resources and budget so that you can invest more in innovation. Gaining competitive advantage, you can look toward the future, and operate as a best-run business over the long term.

With SAP ERP Operations, you can:

Automate and streamline operational processes with greater adaptability.

Increase productivity in your operations with a role-based solution and centralized information.

Extend collaboration to all value chain partners.

Improve operations performance with strategic business insight

Enterprise Structure The Enterprise Structure in R/3 refers to the organizational structure of the Institution. The organizational elements in this structure allow encapsulation of configuration settings and data in each module. For example, the company code organizational element encapsulates the financial accounting settings and data in the financial accounting module for an enterprise.



Each element in the R/3 enterprise structure is defined below. The R/3 module in which each organizational element appears is given in parentheses next to its name. The proposed University of Tennessee organizational elements are given under each organizational element. Client (Cross Application)

A client in R/3 is a technical entity containing configuration, master data and transactions for an organization. For example the organization may designate Client 100 in the production system PRD as the client in which data may be entered. Other clients may be used for development, testing and training. Proposal: The University will have only one production client in the productive

system – Client 100. Company Code (Financial Accounting - FI)

The Company Code is the smallest organizational unit for which a complete self-contained set of accounts can be drawn up for purposes of external reporting. Proposal: The University will use only one Company Code - UT.

Business Area (Financial Accounting - FI) Business areas are units, within an institution, for which a balance sheet and income statement can be produced. In higher education, business areas are typically used to represent fund groups such as Current Unrestricted, Current Restricted, etc. for which balance sheets and income statements are required.

In addition to balance sheets by fund groups, the University of Tennessee requires a separate internal balance sheet and income statement for each budget entity such as Knoxville, Martin, Chattanooga, etc. Proposal: The University will have business areas which represent a unique combination of Fund Group and Budget Entity. All existing fund groups and budget entities will be set up as business areas. For asset and liability entries, these



business areas will be entered by users. For revenue and expenditure entries, these business areas will be automatically defaulted from cost centers and WBS Elements. The following is a sample partial list of business areas identified: Fund Group Budget Entity Busine

ss Area

11 – Current Unrestricted Educational and General Funds

01 – Knoxville 1101

13 – Current Unrestricted Auxiliary Funds


21 – Current Restricted Educational and General Funds


23 – Current Restricted Auxiliary Funds


30 – Endowment Funds 01 – Knoxville 3001 40 – Life Income Funds 01 – Knoxville 4001 45 – Annuity Funds 01 – Knoxville 4501 51 – Unexpended Plant Fund 01 – Knoxville 5101 52 – Plant Funds for Retirement of Indebtedness


53 – Plant Funds for Renewal and Replacement


54 – Invested in Plant Funds 01 – Knoxville 5401 60 – Loan Funds 01 – Knoxville 6001 90 – Agency Funds 01 – Knoxville 9001 11 – Current Unrestricted Educational and General Funds

02 – Space Institute 1102

16 – Current Unrestricted Hospital Funds

04 - Chattanooga 1604

26 – Current Restricted Hospital Funds 04 – Chattanooga 2604 Functional Area (Financial Accounting - FI)

The Functional Area is an organizational unit in Accounting that classifies the expenditures of an organization by function.



Proposal: The University will use functional areas to enable reporting by function. These functional areas will be defaulted from cost centers and WBS Elements. The following is a sample list of functional areas: Function Code Functional

Area 01 – Instruction 1010 02 – Research 1020 03 – Public Service 1030 04 – Academic Support 1040 05 – Student Services 1050 06 – Institutional Support 1060 07 – Operation and Maintenance of Physical Plant 1070 08 – Scholarships and Fellowships 1080 09 – Auxiliary Enterprises 1090 10 – Hospitals 1100 11 – Staff Benefits 1110 12 – Other Expenditures 1120 13 – Service Centers 1130

Figure 1 shows the financial accounting structures.

Business AreaBusiness AreaBusiness Area

Cur Unres E&GKnoxville

Client

CompanyCode UT Functional Area

Functional AreaFunctional AreaInstruction

Figure 1



Controlling Area (Controlling - CO) A Controlling Area in R/3 is the organizational unit within an institution, used to represent a closed system for cost accounting purposes. A controlling area may include one or more company codes which must use the same operative chart of accounts as the controlling area.

Proposal: The University of Tennessee will use only one Controlling Area – UT. Company Code UT will be assigned to Controlling Area UT.

Funds Management Area (Funds Management - FM)

A Funds Management Area in R/3 is the organizational unit within an institution, used to represent a closed system for funds management and budgeting. A Funds Management Area may include one or more company codes and one or more controlling areas. Proposal: The University of Tennessee will use only one Funds Management Area – UT. Company Code UT and Controlling Area UT will be assigned to Funds Management Area UT.

Figure 2 shows the relationship between the Company Code, the Controlling Area and the Funds Management Area.

Company CodeUT

Controlling AreaUT

FundsManagement

Area UT

Figure 2

Master Data Master data structures in R/3 represent data relating to individual objects, which remain unchanged over an extended period of time. This allows such data to be created once and used many times. Master data is also used to validate and classify transaction data for reporting.



Financial Accounting Master Data (FI) Chart of Accounts

The Chart of Accounts is a collection of general ledger accounts. Each company code is assigned to a chart of accounts, and the controlling area is assigned to the same chart of accounts. Proposal: Only one Chart of Accounts - UT will be used for the University of Tennessee. Company Code UT and Controlling Area UT will be assigned to Chart of Accounts UT.

General Ledger Accounts

The General Ledger Accounts (GL Accounts) are the structures that classify debit and credit values for accounting transactions in the FI module and form the basis for creating the balance sheets and income statements. There are five types of General Ledger Accounts in R/3 - assets, liabilities, fund balances, revenues and expenditures. Asset, Liability and Fund Balance GL Accounts can be used, in combination with business areas to create internal balance sheets by business area. Revenue and Expenditure GL Accounts represent the highest level at which revenues or expenditures are recorded by the Institution. They can be used in combination with business areas and functional areas to create income statements by function and business area. Revenue and expenditure can also be further broken down in the Controlling module.

Figure 3 shows the relationship between the chart of accounts and the company code:



Chart ofAccts UT

Company CodeUT

Assets

Liabilities

FundBalances

Revenues

Expenditures

Figure 3

Proposal: At the University of Tennessee several different existing codes will be mapped to R/3 General Ledger Accounts. Existing Code Type of R/3

Account Proposed Number Range

1. Assets AXXXXXXXX (e.g. A17010001 Cash on Hand Treasurer)

Asset Account 100000 through 199999 (e.g. 101001 Cash on Hand + Business Area 1117)

2. Liabilities AXXXXXXXX (e.g. A01560005 A/P Knoxville)

Liability Account 200000 through 299999 (e.g. 256005 Accounts Payable + Business Area 1101)

3. Type of Fund Balance or Reserve (e.g. 99 Balance or 84 Reserve for Encumbrances)

Fund Balance Account

300000 through 399999 (e.g. 399000 Unreserved Fund Balance or 384000 Fund Balance Reserved for Encumbrances)

4. Expenditure Object Codes (e.g. 391 Operating Supplies)

Expenditure Account

400000 through 499999 (e.g. 439100 Operating Supplies)



5. Ledger Activity Codes for Expenditures and Transfers Out (e.g. 050 Charges for Routine Expense) 6. Major and Minor Sources of Funds (e.g. 0101 Tuition and Fees Resident Enrollment) 7. Ledger activity codes for Income and Transfers In (e.g. 001 Endowment Income – UT Endowments) 8. Income activity codes XX (e.g. 01 Rent)

Revenue Accounts 700000 through 799999 (e.g. 701010 Tuition and Fees Resident Enrollment)

Controlling and Project System Master Data (CO, PS and PCA)

Revenue Elements Revenue elements are used to classify revenues in Controlling. They are linked to revenue GL accounts on a one-for-one basis and have the same number and description. E.g. Revenue Element 701010 Tuition and Fees Resident represents GL Account 701010 Tuition and Fees Resident in CO.

Cost Elements

Cost elements are used to classify costs in CO according to object of expenditure. Primary Cost Elements represent expenditure GL Accounts in CO. They are linked to Expenditure GL accounts on a one-for-one basis and have the same number and



description. E.g. Cost Element 439100 Operating Supplies represents GL Account 439100 Operating Supplies in CO. Proposal: Primary cost elements will be set up for all expenditure GL Accounts. Secondary cost elements are used for internal allocations within a controlling area such as overhead. These cost elements are not directly linked to an Expenditure GL account. Proposal: Ledger Activity Codes for 010 Facilities and Admin Costs and similar internally allocation costs will be mapped to secondary cost elements. Secondary cost elements will be set up in the range 500000 to 599999. E.g. 501000 - Facilities and Admin Costs.

Cost Center and Cost Center Hierarchy

A Cost Center is a unit within a controlling area that represents a revenue and cost collector for permanent activities. A cost center can be linked to a company code, a business area, a functional area, a fund, a fund center and a profit center allowing all these codes to be automatically defaulted when a user enters a cost center in a document. Costs and revenues posted to a cost center can thus be automatically posted to the company code, business area, fund, fund center and profit center linked to the cost center. A standard hierarchy of cost centers is required for the controlling area and is used by drill-down reports. In addition Cost Centers may optionally belong to additional alternative hierarchies that can also be used by drill-down reports. Proposal: The University will use Cost Centers to represent its current unrestricted income and expenditure accounts (I and E accounts) in R/3. All E accounts with seven-digit numbers will be represented by cost centers with the same seven-digit number. All I and E accounts with nine-digit numbers will be represented by cost centers with ten-digit numbers. The ten-digit number will be created by adding a zero in the eighth position in the ten-digit number. E.g. Account E01102401 will be represented by cost center E011024001. The standard cost center hierarchy will be used to represent the organizational groupings to show Fund Group >Budget Entity >Function > College or Division > Department> Cost Center (7 digit) > Cost Center (10 digit). An alternative hierarchy will be created to represent the State Appropriation hierarchy. Figure 4 shows the relationship between a cost center and other master data and organizational elements.



Figure 4 Work Breakdown Structure Element (WBS Element) and WBS Element Group

A WBS element is an element in a project work breakdown structure (WBS) and is used as a revenue and cost collector for activities with discrete start and end dates. At least one WBS element must exist in a project. A WBS element can be linked to a company code, a business area, a functional area (through substitution), a fund, a fund center and a profit center allowing all these codes to be defaulted when a user enters a WBS Element in a document. Costs and revenues posted to a WBS Element can be automatically posted to the company code, business area, fund, fund center and profit center linked to the WBS Element. Additionally, collected costs may be billed or automatically transferred to cost centers or GL Accounts periodically. There is no standard hierarchy required for WBS elements. WBS Elements can be grouped together into WBS Element Groups for reporting. Proposal: The University will use WBS Elements to collect revenues and costs associated with cost-reimbursable grants, and all other funds other than current unrestricted funds.

Cost CenterE011024001

Functional Area Instruction

Profit Center L011002401Chemistry

Fund E011024001

Fund Center U011002401Chemistry

Business AreaCur Unrest E&G Knoxville

Company Code UT



Thus WBS elements will be used to collect revenues and costs for current restricted funds, endowment, annuity and life income funds, plant funds, loan funds and agency funds. For example a balance account for restricted funds (B Account) with a nine-digit number, will be represented by a WBS Element with a nine-digit number. The nine-digit number will be created by replacing the fourth and fifth digit with two zeros. E.g. Account B01991024 will be represented by WBS Element B01001024. An expenditure account for restricted funds (R Account) with a nine-digit number will be represented by a WBS Element with a ten-digit number. The ten-digit number will be created by adding a zero in the eighth position. E.g. Account R01102410 will become WBS Element R011024010. Related B and R accounts as in the above case will appear in the same project structure. Figure 5 shows the relationships between a WBS Element and other master data and organizational elements.

FI - Accounts Receivable and Accounts Payable

Introduction to Accounts Receivable and Accounts Payable The following topics are an introduction to the Accounts Receivable and Accounts Payable application components. They also explain how to make system settings for these components.

Accounts Receivable and Accounts Payable: Overview The Accounts Payable application component records and administers accounting data for all vendors. It is also an integral part of the purchasing system: Deliveries and invoices are managed according to vendors. The system automatically makes postings in response to the operative transactions. In the same way, the system supplies the Cash Management application component with figures from invoices in order to optimize liquidity planning. Payables are paid with the payment program. The payment program supports all standard payment methods (such as checks and transfers) in printed form as well as in electronic form (data medium exchange on disk and electronic data interchange). This program also covers country-specific payment methods. If necessary, dunning notices can be created for outstanding receivables (for example, to receive payment for a credit memo). The dunning program supports this function. Postings made in Accounts Payable are simultaneously recorded in the General Ledger where different G/L accounts are updated based on the transaction involved (payables and down payments, for example). The system contains due date forecasts and other standard reports that you can use to help you monitor open items. You can design balance confirmations, account statements, and other forms of reports to suit your requirements in business correspondence with vendors. There are balance lists, journals, balance audit trails and other internal evaluations available for documenting transactions in Accounts Payable. The Accounts Receivable application component records and administers accounting data of all customers. It is also an integral part of sales management. All postings in Accounts Receivable are also recorded directly in the General Ledger. Different G/L accounts are updated depending on the transaction involved (for example, receivables, down payments, and bills of exchange). The system contains a range of tools that you can use to monitor open items, such as account analyses, alarm reports, due



date lists, and a flexible dunning program. The correspondence linked to these tools can be individually formulated to suit your requirements. This is also the case for payment notices, balance confirmations, account statements, and interest calculations. Incoming payments can be assigned to due receivables using user-friendly screen functions or by electronic means such as EDI and data telecommunication. The payment program can automatically carry out direct debiting and down payments. There are a range of tools available for documenting the transactions that occur in Accounts Receivable, including balance lists, journals, balance audit trails, and other standard reports. When drawing up financial statements, the items in foreign currency are revalued, customers who are also vendors are listed, and the balances on the accounts are sorted by remaining life. Accounts receivable is not only one of the branches of accounting that forms the basis of adequate and orderly accounting. It also provides the data required for effective credit management, (as a result of its close integration with the Sales and Distribution component), as well as important information for the optimization of liquidity planning, (through its link to Cash Management). To process receivables-related dispute cases, for example, payment reductions, you can use the component SAP Dispute Management.

Maintaining Current Settings You access current settings by choosing Environment → Current settings in the Accounts Receivable or Accounts Payable menu.

You can then carry out the following activities:

• Specify currency translation rates

• Enter planned amounts for the payment program

• Open and close posting periods

• Create worklists for processing open items and displaying line items and balances

To carry out one of these activities, click the Execute icon next to it. You can display documentation about each current setting by placing the cursor on the title of the activity and choosing Extras → Display document.

Customer Master Data Purpose In the SAP System, all business transactions are posted to and managed in accounts. You must create a master record for each account that you require. The master record contains data that controls how business transactions are recorded and processed by the system. It also includes all the information about a customer that you need to be able to conduct business with him.



Implementation Considerations For information about the system settings necessary for creating master records, see the Implementation Guide (IMG) for Accounts Receivable and Accounts Payable.

Integration Both the accounting (FI-AR) and the sales (SD) departments of your organization use customer master records. By storing customer master data centrally, you enable it to be accessed throughout your organization, and avoid the need to enter the same information twice. You can also avoid inconsistencies in master data by maintaining it centrally. If the address of one of your customers changes, for example, you only have to enter this change once, and your accounting and sales departments will always have up-to-date information.

You have to implement the Sales and Distribution (SD) application component in order to enter and process customer master records for order processing, shipping, and billing. For more information, see the Sales and Distribution documentation.

Features Specifications you make in master records are used:

• As default values when you post items to the account

For example, the terms of payment you specify in the master record are defaulted for document entry.

• For processing business transactions

Account control data, such as the number of the G/L reconciliation account

For example, the dunning procedure, the date of the last dunning notice, and the address are required for the automatic dunning process.

• For working with master records

You can prevent certain users from accessing an account by setting up authorization groups.

• For communication with the customer

For example, the address and telephone and fax numbers.

• For the sales department

Order processing, shipping, and billing data.

Vendor Master Data Business transactions are posted to accounts and managed using those accounts. You must create a master record for each account that you require. The master record controls how business transactions are recorded and processed by the system.



Specifications you make in master records are used:

• As default values when you post items to the account. For example, the terms of payment you specify in the master record are defaulted for document entry.

• For processing business transactions For instance, bank details and the payment methods (check or bank transfer, for example) are required for automatic payments.

• For working with master records. You can prevent certain users from accessing an account by setting up authorization groups.

In addition, line item display and open item management are defined automatically for each vendor account.

This section explains the concept of vendor master data and describes how to create, display, change, block, and delete vendor master data.

For more information about system settings for creating vendor master records, see the Implementation Guide for Financial Accounting under Accounts Receivable and Accounts Payable.

Business Partner Master Data (LO-MD-BP)

Purpose The following types of business partner are defined in the ERP system:

� Partner type customer A customer is a business partner with whom you exchange goods and services. Two types of customer are defined in the ERP system:

• � Internal customers (own sites)

• � External customers

� Partner type vendor A vendor is a business partner from whom goods and services can be procured. Two types of vendor are defined in the ERP system:

• � Internal vendors Normally you only maintain distribution centers as internal vendors.

• � External vendors You select external vendors from companies offering an assortment of goods and services on the market, with the help of guidelines drawn up by your Purchasing department.

� Other partner types A contact person is an example of another business partner in the ERP system.



. Data on business partners is stored in master records. The system uses this data in a number of business transactions, proposing the data in the appropriate fields when, for example, you create sales or purchase orders.

Implementation Considerations Storing the master records centrally and making master data the only source of information for all system functions means that you enter data only once. If a business partner changes address, you enter the new address once.

Integration Because customers are also debit-side business partners in accounting, customer master records are used in Financial Accounting and Sales and Distribution. Because vendors are also credit-side business partners in accounting, vendor master records are used in Financial Accounting and Purchasing. Because sites are customers from the point of view of delivery, each site has a customer master record. Sites use purchase orders to order goods from external vendors. A distribution center is a site that is also an internal vendor, as it supplies merchandise to other sites.

Account Balances and Line Items Purpose When you post business transactions to accounts, the system automatically updates the account balance, and notes which items from the document were posted to the account. It is therefore possible to view the account balance and line items for every customer account.



Features The following section describes what is displayed in the account balance and how you can call up this display. It also describes how to display line items and use additional functions while in the display function.

Posting with Clearing Use Using the posting with clearing function, you enter document line items and then select the open items to be cleared. Once you have fulfilled all the prerequisites for clearing, the system clears the open items. The system generates one or more offsetting postings for the open items to be cleared.

The following example is reflected in the figure below.

1. A customer pays several receivables amounting to 5,000 USD by check. You enter the amount in the incoming checks account.

2. To clear the receivables on the customer account, you choose the open items and complete the document entry transaction.

3. The amount you enter and the items you select must balance to zero. The system automatically posts the incoming payment to the customer account.

4. The system flags the open items as cleared.

All four steps are performed in one procedure. Features

In the clearing transaction, the system generates a clearing document that consists of the items you entered manually, and the offsetting entries it created automatically to balance the document to zero. The document then balances to zero.



The system then flags these items as cleared. It enters a clearing document number and the clearing date in the cleared document items. These are the selected items and the items for the offsetting posting. The clearing date is usually the posting date. If however, the items you select for clearing have a posting date that comes after the posting date of the clearing document, the system uses the most recent posting date as the clearing date. The following illustration shows the item that the system posted automatically in the above example. The item is cleared, and the corresponding document line item contains the clearing data.

There are three functions you can choose from for posting with clearing. You can use a basic function for any type of business transaction in which items need to be posted and cleared simultaneously. The two other functions are specially designed for incoming and outgoing payments.

Some special G/L transactions, such as bills of exchange, are cleared using special functions. For more information about special G/L transactions, see Special G/L Transactions: Down Payments and Payment Guarantees and Special G/L Transactions: Bills of Exchange.

Activities

You can:

• Clear several accounts and account types

• Clear items in any currency

• Clear items and post any differences

• Clear items and enter any number of line items (for example, bank charges)



You can also carry out posting with clearing and account clearing automatically using the payment program. Usually, you run the payment program to pay vendor invoices. However, you can also use the payment program if you and your customers have agreed on a debit memo procedure (collection or direct debit procedure).

Prerequisites for Clearing The following prerequisites must be fulfilled in order for open items to be cleared:

• The accounts must be managed on an open item basis.

• The accounts that can be cleared automatically must be defined in Customizing for Financial Accounting.

• The items to be cleared cannot trigger a posting, for example, cash discounts or exchange rate differences.

• The items cannot be special G/L transactions. You use special functions to clear these items. For more information about clearing special G/L transactions, see Special G/L Transactions: Down Payments and Payment Guarantees



Vendor Master Data Use

The vendor master database contains information about the vendors that supply an enterprise. This information is stored in individual vendor master records. A vendor master record contains the vendor’s name and address, as well as data such as:

• The currency used for ordering from the vendor

• Terms of payment

• Names of important contact persons (sales staff)

Since, to the accounts department, vendors are generally creditors (accounts payable), the vendor master record also contains accounting information, such as the relevant control account (reconciliation account) in the general ledger.

Therefore, the vendor master record is maintained by both Accounting and Purchasing.

The purchasing data pertaining to a vendor must have previously been maintained before you can order from the vendor.



The accounting data pertaining to a vendor must have previously been maintained before you can enter the vendor's invoices in the system for payment.

Features

How is the Vendor Master Record Structured?

Vendor master records contain important data on your vendors. You can also store data in the vendor master record that applies to certain specific organizational levels (e.g. company code, purchasing organization, plant) within your enterprise.

The vendor master record consists of three areas:

1. General data

Data that applies equally to each company code within your enterprise (address, telephone number, language in which you communicate with your vendor, etc.).

2. Company code data

Data kept at company code level (payment transaction data or number of control account, for example).

3. Purchasing data

Data that is of importance with regard to your enterprise’s purchasing activities and which is kept at purchasing organization level (such as contact person or terms of delivery).

The following Data Retention Levels of particular relevance to the wholesale/retail trade exist below the "purchasing organization" level:

Vendor Sub-Range (VSR)

Plant



Vendor sub-range/plant

In addition to the data applicable to a specific purchasing organization, you can maintain purchasing data or partner roles for a certain plant or vendor sub-range (terms of payment or Incoterms, for example) that differ from that at the purchasing organization level. Data specific to sub-levels that varies from that stored for the higher-level purchasing organization in this way is referred to simply as different data.

For more information, refer to the sections Maintaining Different Data, Partner Roles in Purchasing, and Vendor Sub-Range in Purchasing.

What is the Function of the Account Group?

You must assign each vendor whose data you wish to store in the SAP System to an account group.

The account group determines, for example, that only those screens and fields of the vendor master record that are needed for the relevant role of your business partner are displayed and ready to accept user input.

The account group determines:

• The type of number assignment and the number range from which the account number used by the system to identify the vendor is assigned

• Whether or not a one-time vendor is involved

• Which data retention levels below the purchasing organization are allowed (for example, vendor sub-range)

• Which partner determination schemas are valid



You maintain the account groups in Customizing for Logistics General under Business Partners � Vendor � Control � Define Account Groups and Field Selection (Vendor).

The standard system contains the account groups vendor (0001), invoicing party (0006), and one-time vendors (with internal number assignment) (CPD). The account group for One-Time-Accounts causes the address, communication, and bank data fields to be suppressed during creation and maintenance of a vendor master record. You must then enter this information later on, at the time you create a purchasing document.

You can change the account group of an existing vendor master record. To do so, choose Master data ��Vendor ��Central��Account Group Change from the Purchasing menu. (This may be necessary, for example, if a further application comes into use.)

In this case, please note that fields that were previously suppressed in Create mode may be ready to accept input when the master record is changed.

For more information, refer to the documentation FI General Ledger Accounting under Account Group.

How are the Vendor Master Records Numbered?

Each vendor master record is assigned a unique number (the vendor's account number used by Financial Accounting). You need this number to call up the master record or to enter purchase orders. A vendor has the same account number in all company codes.

The type of number assignment and the number range are determined through the account group that you enter when you create a master record.



The number can be assigned internally by the system or by the user (i.e. externally) when a master record is created. For external number assignment, alphanumeric numbers are also allowed.

The system ensures that the numbers are always unique. With internal number assignment, the system assigns numbers consecutively from a given range. With external number assignment, it prevents an already used number from being reused.

For more information on this topic, refer to the documentation LO Business Partner Master Data.

See also:

Maintaining Vendor Master Records

Maintaining Vendor Master Records

Use

If you wish to store information on your vendors in the SAP System, the following functions are available:

• Create vendor master record

• Change vendor master record

• Block vendor master record

• Use one-time vendor

• Display list of vendors

Procedure

Create Vendor Master Record

1. Choose Master data

® Vendor ® Central ® Create from the Purchasing menu.



2. Enter the purchasing organization and an account group. If you want to use another vendor master record as a reference, enter the account number of that vendor in the Vendor (creditor) field (under Reference). Press

ENTER.

3. The Create Vendor: Address screen appears. Enter the address and press

ENTER.

4. The Create Vendor: Control screen appears. On this screen, enter the accounting data needed by the payment and dunning program, and data for declarations to the tax authorities. Also populate the Debtor (customer) field where necessary (the data in this field is needed in the case of deliveries to the vendor in connection with

Returns and Subcontracting Components.

Press ENTER and enter the necessary data on the subsequent screens that appear.

5. On the Purchasing Data screen, enter purchasing-specific data such as the order currency or the key for the terms of payment and then press

ENTER.

You can record the Terms of Payment that you agree with a vendor in the vendor master record. They automatically appear as default values in any purchase orders created for the vendor in question; however, you can change them as needed.

Terms of payment can also be entered in the vendor's invoice. These are then applied by the payment program.

6. The Create Vendor: Partner Roles (partner functions) screen appears. Maintain the necessary partner roles on this screen. (See

Partner Roles in Purchasing.)



7. Click to save the vendor master record.

Change Vendor Master Record


® Vendor ® Purchasing ® Change.

2. Enter the vendor number and the purchasing organization, and select the data you wish to change. Press

ENTER.

3. Enter your changes and click to save your input.

Block Vendors

Suppose you would like to prevent further deliveries from a vendor who has supplied goods of poor quality. You can freeze or "block" the vendor account in the vendor master record.

Once you have set the blocking indicator in the vendor master record, purchase orders can no longer be placed with this vendor. The "blocked" status for the vendor applies until such time as you cancel the blocking indicator.

To block a vendor, proceed as follows:


® Vendor ® Purchasing ® Block. Enter the vendor number and the purchasing organization. Then press ENTER.

2. A screen appears, on which you can indicate whether the vendor is to be blocked for a specific purchasing organization or for all purchasing organizations.

If QM is active within the procurement function, you can impose a block for quality reasons. (See the documentation Quality Management (QM) Overview of Procurement Activities)

Click to save your input.



You can block a vendor for an individual material via the source list.

For more information, refer to the section Optimized Purchasing.

Use One-Time-Vendor

You can create special vendor master records for vendors from whom you procure goods only once or rarely, so-called One-Time Vendor Master Records.

For example, suppose you order goods from a vendor with whom you usually do not place orders, because your main vendor was not able to supply the required items. In this case, you would use a "one-time vendor" master record.

In contrast to other master records, a "one-time vendor" master record is used for several vendors. The purpose of this is to avoid the unnecessary creation of an excessive number of individual vendor master records. For this reason, you may not store any vendor-specific data in a "one-time vendor" master record.

When creating a "one-time vendor" master record, you must assign a one-time account group. This account group determines that the vendor-specific fields are suppressed. You don’t need to enter this data until the time a purchasing document (e.g. a PO) is created.

When you create a purchasing document with a one-time vendor, you will be asked to enter the vendor address. Enter the vendor’s name and address.

Like all other master records, you can display, block, or delete one-time vendor master records.



Display List of Vendors

You can create a list of different vendors. This list contains important information on individual vendors: the purchasing organizations for which material was procured from a vendor, the terms of payment, and the blocking status of the vendor, for example.


® Vendor ® List displays, then Purchasing list.

2. Enter your selection criteria and run the analysis.

Creating Your Own Customer Master Record Prerequisite

You create a customer master record in company code 1000 using a reference customer. The order currency is to be DEM. If somebody has already converted the order currency of the reference customer, this scenario will not work and you will have to create the customer without using a reference.



Usage

This customer was previously invoiced in DEM. At the beginning of 1999, this customer converts to the euro and wants sales orders to be created and billed in euros.

Procedure

1. Call up the transaction as follows:

Menu Path Logistics � Sales and Distribution � Master Data � Business Partners � Customer � Create � Complete

Transaction Code XD01

2. On the Create Customer: Initial Screen, enter the following data:

Field Data

Customer Your own customer number (greater than or equal to 96000)

Company code 1000

Sales organization 1000

Distribution channel 10

Division 00

Account group Sold-to party



Reference customer 1000

Reference company code 1000

Reference sales organization 1000

Reference distribution channel 10

Reference division 00

3. Choose .

4. On the Create Customer: General Data screen, in the Address tab, enter the following data:

Field Data

Description Any

Search term Any search term

Street/House number Any

Postal code/City 5 figure code (numerical)/any city

Country DE

Transportation zone D000070000

Language DE



5. Choose .

If the system asks you to enter a VAT registration number, enter DE and any nine-figure number.

6. Choose Company code data.

The Create Customer: Company Code Data screen appears.

7. Choose the Account management tab. The system defaults reconciliation account 140000 from the master record of the reference customer.

8. Choose the Payment Transactions tab. Terms of payment ZB01 is also defaulted from the master record of the reference customer.

9. Choose Sales Area Data.

The Create Customer: Sales Area Data screen appears. On the Orders tab, the order currency is DEM.

10. Choose the Shipping tab page. Shipping condition 02 is transferred from the material master record of the reference customer.

11. Choose the Billing Document tab. The Incoterms CIF/Berlin and terms of payment ZB01 are copied from the master data record of the reference customer.

12. Enter the following data:

Field Data

Tax class 1 (liable for tax)

13. Choose .

The system confirms that your customer master record has been created.



14. Choose .

15. Choose until the overview tree appears.

Special G/L Transactions: Down Payments and Payment Guarantees

The following topics explain the basic principles behind special G/L transactions including information on down payments and payment guarantees. They also explain which default settings you need to make in Customizing.

For detailed information on Customizing settings, access the Financial Accounting Implementation Guide and read the information about the activity Business Transactions to be found under Accounts Receivable and Accounts Payable.

Special G/L Transactions: Overview

Special G/L transactions are special transactions in accounts receivable and accounts payable that are displayed separately in the general ledger and the subledger. 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 (FI-GL) Accounts Payable (FI-AP) and Accounts Receivable (FI-AR) application components.

Special G/L transactions are already available in the standard system. However, you can change the specifications or define your own special G/L transactions.

This section describes:

• How the system manages special G/L transactions and the advantages of this procedure



• What you need to know for the special G/L transactions "down payment" and "guarantee" and how you adapt these transactions to your company-specific requirements

• How you create your own special G/L transactions

The settings necessary to be able to post bills of exchange are described in Special G/L Transactions: Bills of Exchange.

The Basic Principles of Special G/L Transactions

Special G/L transactions are special transactions in accounts receivable and accounts payable that are displayed separately in the general ledger and the subledger. This is achieved by posting to alternative reconciliation accounts, instead of posting to the reconciliation accounts for receivables and payables.

The following special G/L transactions are available:

• Down payments and down payment requests



• Bills of exchange receivable, bills of exchange payable and checks/bills of exchange

• Bank bills

• Payment requests

• Guarantees

• Reserves for bad debt

• Security deposits

These special procedures are displayed separately from other receivables and payables on the balance sheet either for legal reasons, such as with down payments, or for control reasons, such as with guarantees received. A separate special G/L account is created for each special G/L transaction. As a result, it is possible to display each transaction in the balance sheet without having to carry out any transfer postings and to receive an overview via the account limited to this procedure only.



What are the Different Types of Special G/L Transactions? In the SAP System, distinctions are made between different types of special G/L transaction. These distinctions are made according to business-related and technical factors. On the business side, a distinction is made between:

� Bills of exchange

� Down payments

� Miscellaneous special G/L transactions, such as guarantees On the technical side, a distinction is made between:

� Postings with a freely-definable offsetting entry. These include down payment and bill of exchange postings.

� Postings with a preset offsetting entry. These transactions are called statistical postings.

� Postings without an offsetting entry. These procedures are called noted items.

Statistical Postings

Statistical postings are transactions where you always post to the same offsetting account. For example, when you post interest due, you always post to the offsetting account "interest revenue". To simplify the posting procedure, you can define the number of the account required for the offsetting entry in the system. The system then posts the offsetting entry automatically. Also when you clear open items in an open item account, the system automatically clears the relevant open items in the offsetting account.



Noted Items

Special G/L transactions are also used to manage noted items. These are postings that are not displayed in your accounts but are only to remind you of outstanding payments due or to be made. You can process them with the payment program or dunning program. As a result, it is possible to dun outstanding down payments or to make down payments with the payment program. To do this, you enter and store a down payment request . This special document does not update the account balance: it is merely managed as a line item in the open item account and the special G/L account. Therefore, you should always mark the Line item display option for these accounts.

The same procedure is used in Spain, Italy and France to issue bills of exchange automatically with the payment program. The noted item required for this is called a bill of exchange payment request. You can find more information in Special G/L Transactions: Bills of Exchange

Special G/L Transactions: Bills of Exchange

The following topics explain how to post and process bills of exchange. For detailed information on Customizing settings, access Configuring the System Using the Implementation Guide and read the information about



the activity Business Transactions to be found under Accounts Receivable and Accounts Payable.

Calling Up the SAP Reference IMG

To display the SAP Reference IMG, proceed as follows:

1. From the SAP System main menu, choose Tools ��Accelerated SAP � Customizing ��Edit project, then SAP Reference IMG.

The IMG structure appears.

2. Place the cursor on Financial Accounting and choose Edit � Expand, or click on the plus sign to display the subheadings under Financial Accounting.

You will see the IMG for Financial Accounting Global Settings, General Ledger Accounting, and Accounts Receivable and Accounts Payable.

3. Place the cursor on either Financial Accounting Global Settings, General Ledger Accounting, or Accounts Payable and Accounts Receivable, and expand the structure until you find the configuration activity you require.

4. To display the documentation for the activity, double-click the text icon next to the activity. You can maintain the settings by double-clicking the Execute icon.

5. Make the required configuration settings and save them.

6. Return to the IMG structure display by choosing Goto � Back.

Bills of Exchange Receivable: Introduction

Bills of exchange are a form of short-term finance. If your customer pays by bill of exchange, he does not make payment immediately, but only once the



period specified on the bill has elapsed (three months, for example). Bills of exchange can be passed on to third parties for refinancing (bill of exchange usage).

A bill of exchange can be discounted at a bank in advance of its due date (discounting). The bank buys the bill of exchange from you. Since it does not receive the amount until the date recorded on the bill, it charges you interest (discount) to cover the period between receiving the bill of exchange and its eventual payment. Some form of handling charge is also usually levied.

If you do not use the bill for refinancing in this way, you can either present it to your customer for payment on the due date, or deposit it at a bank shortly before the due date for collection. The bank charges you a collection fee for this service.

In some countries, you can also pass on a bill of exchange to a third party as a means of payment. You may pass it on to a vendor, for example, to clear your own payables (means of payment).

You can also sell your bills of exchange receivable abroad (forfaiting). When you use the bill in this way (otherwise known as non-recourse financing of receivables) you are freed, on the sale of the bill, from any liability to recourse.

When you deposit a bill of exchange receivable at a bank, you can make use of the following two functions offered by the system:

� You can create a bill of exchange presentation list for your bank. If required, the system posts this bill of exchange usage automatically. This procedure applies to bills of exchange not yet due, for example in Italy.

� You can present the bill of exchange at your bank and post the bill of exchange usage manually.

In the general ledger, the bill liability is managed in separate G/L accounts that offset the entry in the bank account.



Once the due date has been reached and the country-specific protest period has elapsed, you reverse the bill liability. You are no longer subject to any liability to recourse. The protest period enables the last holder of a bill to make use of his or her right of recourse whereby he or she demands that one of the parties recorded on the bill of exchange make payment of the amount. The protest is an official record that the drawee has not paid the bill of exchange.

By accepting a bill of exchange you incur costs which the customer pays if the bill is due later than the invoice. When you post a bill of exchange payment, you therefore levy bill of exchange charges on your customer. These can include interest charges (discount), and collection fees. You can enter the bill of exchange charges when you post the bill or you can have the system calculate them automatically. Any combination of the above-mentioned bill of exchange charges is possible. The charges are levied on the customer automatically. Generally, bill of exchange charges are due net immediately. If you require special terms of payment for the charges, these can be defined in the customer master record.

In some countries, you must record bills of exchange receivable in a bill of exchange list. The bill of exchange list is a subsidiary ledger and contains all the essential data of incoming bill of exchange receivables. The day of expiration of the bill of exchange and the address data of the issuer are included in this list.

In the system, you can distinguish between rediscountable and non-rediscountable bills of exchange. Rediscountable bills of exchange must meet country-specific conditions that allow a commercial bank to pass on the bill of exchange for rediscounting to the State Central Bank. In Germany for example, the following conditions exist:

• Three "good" signatures on the bill of exchange.

• Remaining life may not exceed three months.



• Bill of exchange must be payable at a State Central Bank city, that is a city in which the State Central Bank has an office.

Commercial banks cannot pass on non-rediscountable bills of exchange to the State Central Bank for rediscounting. By distinguishing these two types of bills during entry, you can have the system display them separately in the balance sheet. The special G/L indicator indicates the type of bill of exchange entered. The bills of exchange are posted to different special G/L accounts. When a change to the status of a bill of exchange occurs, transfer postings are necessary before preparation of the balance sheet. For example, a non-rediscountable bill of exchange becomes rediscountable if its remaining life has changed.

If such a distinction is not required in your country, you will post all bills of exchange receivable using the same special G/L indicator.

Posting Procedure for Bills of Exchange Receivable

For bills of exchange receivable, there are three events which are posted in Financial Accounting:

1. Payment by Bill of Exchange Firstly, the payment by bill of exchange is posted and used to clear the receivable against the customer. There is a now a bill of exchange



receivable which is recorded on the customer account and the special G/L account.

2. Bill of Exchange Usage If the bill of exchange is used for refinancing and is passed on to a bank, then the bill of exchange usage must be posted. The bill of exchange liability (liability to recourse) that you now have is recorded on special accounts in the system until it has expired.

3. Cancel the Bill of Exchange Liability Once the due date of the bill of exchange has elapsed, including any country-specific period for the bill of exchange protest, you can cancel the bill of exchange receivable for your customer and the bill of exchange liability.

Posting a Bill of Exchange Receivable

This topic illustrates the posting procedure for a bill of exchange receivable by means of an example. The subsequent topics describe the specifications that are necessary for posting.



1. You have a receivable amounting to 11,400 DM from your customer. This receivable is displayed on the customer account and on the reconciliation account for receivables from goods and services.

The customer settles the receivable on June 10th with a bill of exchange. When clearing the receivable, the following postings are made:

2. You post the bill of exchange to the customer account. In the general ledger, the receivable is posted automatically to the special G/L account for bill of exchange receivables. A bill of exchange receivable now exists which is recorded on the customer account. Since it is a special G/L transaction, the bill of exchange receivable is managed separately from the other receivables.

3. From the customer account you choose the receivable to be cleared by the bill payment. The system posts the clearing amount to the customer account and to the reconciliation account for receivables from goods and services. It also indicates the original receivable as cleared.



The bill charges are also entered when entering the bill of exchange receivable. They are then passed on to the customer.

In our example, the bill charges give rise to the following postings:

4. Five percent of the bill of exchange amount is calculated as the discount charge (570 DM). The tax on sales/purchases amounts to 14 percent. It is automatically calculated on the discount charges (79.80 DM). These amounts are posted to the corresponding revenue accounts.

5. The system automatically posts the bill charges (649.80 DM) to the customer account.

See also:

Payment Transactions

The following describes the functions of payment transactions:

• Manual or electronic account statement

You access this function by choosing Accounting ®->Financial accounting ® Banking ® Input ® Bank statement.



• Lockbox

You access this function by choosing Accounting ® Financial accounting ® Banking ® Input ® Lockbox.

• POR procedure

You access this function by choosing Accounting ® Financial accounting ® Banking ® Input ® POR procedure.

• Automatic payment

You access this function by choosing Accounting ® Financial accounting ® Banking ® Outgoings ® Automatic payment.

Creating a Report for Financial Statement Analysis

Use

In a report for financial statement analysis, you can compare the development of the financial statement values. You can make a comparison for the following time periods:

• Yearly comparisons

• Semi-annual comparisons

• Quarterly comparisons

• Monthly comparisons

In a report, you can valuate both actual and plan data. That is, you can run actual/actual comparisons as well as actual/plan comparisons.

Prerequisites

In your financial statement analyses, you can use variables. These have to be predefined in Customizing. In the G/L Account Information System, you can only use global variables. To define global variables, in Financial



Accounting Customizing choose General Ledger Accounting � Information System � Drilldown Reports (G/L Accounts) � Define Global Variables.

The reports for financial statement analyses are based on the financial statement version. The desired financial statement version has to be defined in Customizing. To define a financial statement version, in Financial Accounting Customizing choose General Ledger Accounting � Business Transactions � Closing � Document � Define Financial Statement Version.

Activities

To create a report for financial statement analysis, proceed as follows:

1. Create a form for a financial statement analysis.

This form is a one axis form with key figure. This means that you only have to define the columns of the form.

You can find additional information under Creating Forms for Financial Statement Analysis.

2. Create a report using the form as the basis.

You can find additional information under Creating Reports for Financial Statement Analysi



Documentary Payments (SD-FT-LOC)

Purpose Foreign Trade's Documentary Payments component enables you to create a master record of a letter of credit and assign it to a Sales and Distribution (SD) document transaction. This record is called a financial document in the SAP system. By assigning a financial document to a transaction, you can ensure that the data in the SD document for the transaction complies with the terms of the financial document. Financial documents significantly reduce the risk involved in foreign trade transactions. For exporters, they help ensure payment on time and in full. For importers, they help ensure that the goods they pay for are exactly what they ordered. They also ensure that they have actually been shipped.

The financial document in SAP's Foreign Trade System is not only used for letters of credit. It can also be used to represent



documents against payment (d/p) or documents against acceptance (d/a).

Implementation Considerations Use this component if you use financial documents in transactions with foreign customers. For example, you may require a financial document if you are unsure of a particular customer’s ability to pay. In addition, some governments require financial documents for trade with other countries.

Integration The Documentary Payments component is completely integrated in the Sales and Distribution (SD) Credit Management component to ensure that financial documents are harmonized with other forms of payment security such as payment cards. As an example of this integration, if the value of a sales order exceeds the value of its corresponding financial document, Credit Management will block the sales order. This component performs consistency checks between financial document master records and both sales orders and deliveries. It also updates financial document master records with data from sales orders, deliveries, and invoices.

Features � Creates and maintains financial document master record data

� Manages different types of LOCs, such as revocable and irrevocable documents

� Proposes payment guarantee procedures

� Supports the input of multiple banking partners involved in a documentary payment transaction

� Ensures accurate financial document master records by requiring two authorized users to activate financial documents

� Assigns financial documents to SD documents



� Simulates the assignment of financial documents to sales documents

� Proposes a payment guarantee type in SD documents

� Performs consistency checks (completeness and plausibility) of FT data in customer master records

� Verifies SD document data against financial documents and blocks SD documents if discrepancies exist

� Includes financial document data in printed documents required for an export transaction

� Monitors financial documents allowing the display of financial documents currently in the system, blocked documents and sales documents assigned to the financial documents

� Displays graphics that show the proportion of a financial document’s value already assigned to SD documents

Customizing for Withholding Tax Reports of Real Estate Objects

To generate the withholding tax reports correctly for real estate objects, you must make settings in Customizing for Financial Accounting (New) (FI) under

Financial Accounting Global Settings (New) Withholding Tax Extended Withholding Tax Basic Settings India Define Section Codes .



Customizing Conversion of Taxes at Official Exchange Rate

Use In Indonesia, when you enter a document in a foreign currency and it contains taxes, Indonesian law dictates that the taxes must be calculated in the local currency (IDR) using the exchange rate as published by the tax office (see Tax Invoices in Foreign Currency).

Activities 1. In Customizing for Financial Accounting (FI), choose Financial

Accounting Global Settings → Tax on Sales/Purchases → Basic Settings → Plants Abroad → Activate Plants Abroad, and set the Plants Abroad Activated indicator.

2. In Customizing for SAP NetWeaver, choose General Settings → Set Countries → Define Countries in mySAP Systems. Enter country currency IDR and the exchange rate type you defined for Indonesia.

3. Maintain the exchange rates for the currencies and dates as required.

4. In Customizing for FI, choose Financial Accounting Global Settings → Global Parameters for Company Code → Enter Global Parameters. In the Crcy Transl. for Tax (Foreign Currency Translation for Tax Items) field, enter 1 (Manual exchange rate entry possible

Configuring the System Using the Implementation Guide

Some system settings for Accounts Receivable and Accounts Payable, such as those for check management, must be made in Customizing.

The following descriptions are based on the SAP Reference IMG. If you are working with an Enterprise IMG or your own projects, you may see slightly different paths than the ones listed here.



The SAP Reference IMG lists all the activities that you need to carry out to configure your SAP System.

You can execute functions and display documentation about these functions from the IMG structure.

For more information about system settings (function descriptions and instruction manuals), see the CA - Customizing Manual.

Calling Up the SAP Reference IMG

To display the SAP Reference IMG, proceed as follows:

1. From the SAP System main menu, choose Tools ��Accelerated SAP � Customizing ��Edit project, then SAP Reference IMG.

The IMG structure appears.

2. Place the cursor on Financial Accounting and choose Edit � Expand, or click on the plus sign to display the subheadings under Financial Accounting.

You will see the IMG for Financial Accounting Global Settings, General Ledger Accounting, and Accounts Receivable and Accounts Payable.

3. Place the cursor on either Financial Accounting Global Settings, General Ledger Accounting, or Accounts Payable and Accounts Receivable, and expand the structure until you find the configuration activity you require.

4. To display the documentation for the activity, double-click the text icon next to the activity. You can maintain the settings by double-clicking the Execute icon.

5. Make the required configuration settings and save them.



6. Return to the IMG structure display by choosing Goto � Back.

Searching for Activities in the SAP Reference IMG

Using the Find function, you can search for a specific word or character string within the IMG’s structure titles.

Proceed as follows:

1. From the IMG structure display screen, choose Edit � Find.

2. Enter your search term (word or character string).

3. Select the type of search and hit list display.

4. Confirm your entries.



Figure 5 Profit Center and Profit Center Hierarchy

A Profit Center is an organizational unit in R/3, within which costs and revenue can be analyzed. Costs and revenues posted to cost centers and WBS Elements can be automatically posted to profit centers. A standard profit center hierarchy is required and is used by drill-down reports, and multiple alternative profit center hierarchies can be created to be used by drill-down reports.

Functional Area Research

Profit Center L011002401Chemistry

FundB01001024

Fund Center U011002401Chemistry

Company Code UT

Business AreaCur Rest E&G Knoxville

WBS ElementB01001024

WBS ElementR011024010

FundR011024010



Proposal: The University will use Profit Centers to represent its reporting organization units in R/3 so that reports can be created across cost centers and WBS element by organizational unit. The profit center number will be based on the department number. For example, department 011002401 will be mapped to profit center L011002401. The standard profit center hierarchy will be used to represent the reporting organizational groupings to show Budget Entity >College or Division > Department.

Funds Management Master Data Commitment Item and Commitment Item Hierarchy

Commitment items represent budget and fund accounting classifications of GL Accounts and cost elements in the Funds Management Module. They are thus used to reflect the type of revenues and expenditures being budgeted and also to detail balances for each fund in FM. Proposal: The University will create Commitment items for each Budget Object Code (two digit). For example budget object code 11 – Admin and Professional Salaries will be mapped to commitment item 11 - Admin and Professional Salaries. In addition, all fund balance GL accounts will be mapped to FM on a one-for-one basis and assets and liabilities GL accounts will be mapped to Commitment Items on a many-to-one basis.

Figure 6 shows the relationship between GL accounts, cost elements and commitment items:

Assets GL Account

Liabilities GLAccount

Fund Balance GLAccount

Assets CommitmtItem

LiabilitiesCommitmt Item

Fund BalanceCommitmt Item



Figure 6 Fund

A fund represents the lowest level of funding requiring a budget. The fund master includes an application of fund and one or more sources of funds. Budget rules can be specified separately for each fund.

Proposal: The University will use Funds for storing the budgets and actuals for all its accounts. Only one application of fund will be created for the Current Unrestricted fund group but individual Sources of funds will be created to represent each account. The current unrestricted sources of funds will have the same numbers as the cost centers representing such accounts (seven-digit or ten-digit number). For all other fund groups an application of fund and a source of funds



will be created for each account. These sources and applications of funds will have the same number as the WBS Element representing such accounts (ten-digit number). Attributes such as the Vice-Chancellor and Dean/Department codes will be entered into user defined fields on the fund master.

Funds Center and Funds Center Hierarchy

A fund center is the organizational unit responsible for preparing and monitoring the budget for one or more funds. Fund centers are organized into a hierarchy along which the budget flows. Since the budget flows along the fund center hierarchy, no alternative hierarchies are allowed.

Proposal: The University will create fund centers based on the reporting organization hierarchy of Budget Entity> College or Division> Department. The fund center number will be based on the department number. For example, department 011002401 will be mapped to fund center U011002401.

Name: Title: Signature: Date: -________________

_______________

_______________

________________

_______________

_______________

________________

_______________

_______________

sap financial

Documents

sap solutions

sap erp application

sap erp financials

sap business suite software

sap erp operations solution

business processes

specific business needs

business benefits