- Shopping Bag ( 0 items )
Ships from: Parma, OH
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
Ships from: Newport, United Kingdom
Usually ships in 1-2 business days
Note: The Figures, Tables and/or Exhibits mentioned in this chapter do not appear on the web.
R/3 is a comprehensive business software package designed to run on various client-server platforms. R/ 3 includes a series of programs with various functions for accounting, logistics, and personnel management. R/ 3 was ported from a mainframe package (R/ 2) to client-server platforms and released in 1992. For the user, R/ 3 differs from R/ 2 primarily in the following ways:
Both R/ 2 and R/ 3 are based on a table-driven design. They are complex pack-ages. R/ 3 has the "feel" of having an object-oriented design. Flexibility implies complexity. This book is divided into five chapters:1. Overview
R/ 3 is divided into the following groups of modules:
SAP enhances these modules and also develops other modules. They also supply certain industry-specific programs (for vertical markets), such as programs for the oil industry, publishers, hospitals, and banks. Contact SAP for details about other modules and vertical market applications.
In addition, R/ 3 includes a software development system (Development Workbench). This development system includes:
ABAP/ 4 is an SAP-proprietary, fourth-generation programming language with syntax that vaguely resembles Pascal. You or your programmers can use the ABAP language to develop data interface programs to transfer your data to or from your existing systems and R/ 3. You can also use ABAP, and possibly the other programming tools, to develop custom reports and even to modify the functions supplied by SAP. All R/ 3 application modules are developed completely with ABAP. SAP supplies the ABAP source code to these applications. Although it is tempting and comparatively easy to modify this code, beware of modifying the supplied programs. If you modify the source code, you are unlikely to obtain technical support from SAP, since they can never know exactly what you modified and how it altered their code. Furthermore, even if your modifications were clearly and completely documented, which almost never happens, you cannot be sure that you can apply these same modifications to the next release of the software from SAP. In other words, modifications greatly complicate and sometimes prevent upgrading to the next version of the software.Integration
From a business perspective, the R/ 3 modules are well integrated. However, the chart of accounts and the main master files are common to all necessary modules. The primary points of integration (shared master data) are as follows:Shared Master Data Modules
This book is concerned with using FI. It also covers briefly the integration of FI with the other modules. For example, a general ledger account (G/ L account) in FI is called a cost element in CO. Most of all, FI is designed for legally required external reporting, such as a financial statement (balance sheet and P& L), VAT, and required transaction journals. Sales tax calculation, processing, and reporting, which is required in the United States only, is done with third-party add-on software from either Vertex or AVP.
CO is designed for internal reporting by cost center (department), profit center, or market segment.
Customer master records are common to FI and SD. These records contain screens that you usually maintain in the accounts receivable department and screens that you usually maintain in the order processing, customer service, warehouse, or logistics department. You can have multiple ship-to addresses for one bill-to address. In this way, a central, common customer database is available to all departments. Using SD, you update G/ L accounts for all customer shipments and returns in real time. How you maintain customer master records depends on your organization.
Similarly, vendor master records are common to FI and MM. These records contain screens that you usually maintain in the accounts payable department and screens that you usually maintain in the purchasing, receiving, warehouse, or logistics department. In this way, you can keep a central, common vendor database available to all departments. How you maintain vendor master records depends on your organization.
You can use MM to manage both quantities and values of inventory at the same time. In other words, you can use MM to keep track of the count of products in stock, as well as the value of the products in stock. Using MM, you update G/ L account balances of all stock movements in real time. How you keep material master records depends on how you organize, or possibly reorganize, your company and on how you keep your physical inventory.INTERNATIONAL APPLICATION
R/3 was originally developed to test inexpensively the R/ 2 functionality on personal computers. This design includes menus, screens, reports, error messages,and on-line help in multiple languages, functions to process transactions and accounts in multiple currencies, and functions and reports that comply with accounting regulations (legal requirements) anywhere that SAP does business. If the regulations change, then SAP usually delivers anylegally required new or changed report or function promptly. (Call SAP for details.)
You can enter and display numbers and dates according to various local formats, which each user can set and reset. See the section "Setting User Defaults."Multilingual
If you have licensed and installed the proper language tapes, you can log in in various languages. You then see the menus, data entry screens, error messages, report parameters, report headings, and on-line help in your login language. You can even be logged in twice-- in two languages at the same time. This could be useful for technical support, if you have a multilingual company and wish to have a common language for technical support.
For financial reporting in multiple languages, you can translate your chart of accounts and the text of your financial statement without licensing the language tape for the other language.
Depending on the version, module, and language of R/ 3 being used, the translation is not complete. Since the program was developed in German, missing translations are usually filled in with the German text. Also, the SAP terminology in English does not always correspond to standard accounting terminology in English. As much as practical, this book defines an SAP term the first time that it is used, but uses standard accounting terms.Multicurrency
Since R/3 is object-oriented software, you can specify the currency of the following business objects in FI:
Note that the currency is not a field in a customer record, nor in a vendor record. One and the same customer could purchase from you in two or more different currencies. FI includes programs to revalue open items, such as al Application invoices posted in foreign currency, and general ledger accounts, such as bank accounts, denominated in foreign currency.
Specifically, you can keep a global chart of accounts, while at the same time permit each local company to keep a legally required chart of accounts. If you have central data storage capacity, possibly requiring a wide-area network, you could also keep a global customer database, for example for order entry, shipping, invoicing, and collection.Multicompany
You can keep the accounts for multiple companies (and inventory in multiple plants) on the same system. If you record transactions for multiple companies, you should, if possible, use the same machine and the same login client for all companies. In this way, you can readily consolidate the companies later without sending tapes or files to load. Aconsolidated financial statement eliminates intercompany receivables, intercompany payables, intercompany revenues, intercompany expenses, profits on intercompany transfers of inventory, profits on intercompany transfers of fixed assets, and the investment of the head office in the equity of the subsidiary. You can use either the North American (step-by-step) or the European (simultaneous) method of consolidation.CLIENT-- SERVER-DATA DESIGN
R/3 is commercial application software. It requires an operating system and a database. R/ 3 runs on popular commercial operating systems, such as various versions of UNIX and Windows NT, and various databases, such as Informix, SQL Server, and Adabas for client-server machines. (Call SAP for the latest details.) After you install the operating system and the database, R/ 3 runs in three abstract layers:
The application layer is the "engine" of R/ 3. For example, it contains the program logic that validates the data entry screens. This layer also contains the programs to process your business transactions, such as invoices and payments, and to produce your reports, such as balance sheets and profit and loss statements. When you log in, the application layer receives your login ID and password. It reads the file of valid login IDs and passwords, validates your login ID and password, and then displays a startup menu. You can run the application and the data layer on the same machine, particularly if your load and number of users is low to begin with (in a test system). Alternatively, you can logically attach one or more application servers to one and the same database server. An identical copy of the data dictionary is kept on every application server attached to the same database server.Data (RDBMS)
The data layer contains the links to whichever of the required SAP-compatible databases that you use. This layer records the data in SAP tables, such as a table of valid login IDs and passwords. These SAP tables are either transparent (in the same format) to the database or compressed (in an SAP-proprietary format). This layer also retrieves the data when you make an inquiry or run a report. In effect, this layer simply reads and writes data in your database. Note that you can mix UNIX and NT systems in the same installation. For example, you could run the application server on an NT machine and the database server on a UNIX machine. However, to mix systems, words (data) must be consistently stored in either little-endian or big-endian format on all machines.R/3 Application Processes
An R/3 process corresponds to an operating system process. A process is a program running in memory. The three-layer design always includes at least the following processes:
Some other processes, for internal and external communications, may also be running at the same time. Depending on your system load, you can have more than one of each of these processes running at the same time. For example, depending on your license and the number of active users, you can have several dialog processes, several update processes, and several batch processes running at the same time. If you have many users, you can balance the load by adding one or more machines with application servers (dialog processes). You can then assign each machine to a specific set of users, for example by site or location. For example, in a global company, you could assign each application server machine to a different region or to a different module.REQUIREMENTS FOR INSTALLATION Hardware
How much hardware you require depends on the number of active users, which applications you actually use, the load on the system by your data interfaces to other applications, the load on your system by any custom programs you may have developed, and what your actual volume of data is. (See your hardware manufacturer or SAP for details.) Although you might require more and could make do with less, in general, you require at least the following hardware to run R/3 (in a small test system on one machine):
Make sure that the equipment is properly installed and configured.Software
See your hardware manufacturer, database supplier, and SAP for the latest details of compatible versions required. You require the following software to run R/ 3:
Make sure that you order compatible versions of the operating system, database, and R/ 3. Also make sure that the operating system, TCP/IP, database, and front-end software, such as Windows, are properly installed and configured.Network
R/3 requires a TCP/ IP local area network (LAN). You can also run R/ 3 in a transcontinental configuration over a wide area network (WAN) with one or more data lines capable of transmitting IP (Internet protocol) packets at least 64 kbps. For example, you could run the application layer and the database layer on one continent, such as North America, while you run the presentation layer, such as Windows PCs, on another continent, such as Europe. Alternatively, you could dial in to an application layer with a 14.4 kbps modem and run R/3 remotely. Due to the volume of data transferred, the application layer and the database layer should always run on the same LAN. The reverse con-figuration is, of course, also possible. If the network ran reliably and without congestion, then it would appear to your users that they have a local application with local printing. Depending on the number of active users, your pattern of usage, and volume of data, you may require more data transmission capacity (bandwidth) than 64k. Note that Windows NT requires even more bandwidth than UNIX.Installing R/3
Contact SAP for details. To protect their copyright on the software, SAP tends to control installations carefully and who is allowed to install the software.STARTING TO USE R/3 Implementing SAP
The keys to finishing your SAP R/ 3 implementation project are: clear goals, clear roles, and training (with a train-the-trainer approach). In most cases, FI is implemented first or in parallel with the other modules, such as CO (cost accounting), AM (fixed assets), MM (purchasing), and SD (order entry and invoicing). Each software implementation project is different, depending on your company's goals and existing systems. Nevertheless, the following is a proven step-by-step method to set up and start to use SAP R/3:
1. Analyze your current systems. Why are you dissatisfied with your current systems? If you are not dissatisfied, why are you thinking of changing one or more of your current systems? What are the interfaces (transfer of data between systems) in your current systems? What financial reports do you currently prepare regularly? How many companies do you account for? If you do international financial reporting, how do your current systems handle this? What problems do you have with your current accounting system? How could it be improved? Have your organization, markets, or applicable regulations changed since the current system was installed? How? Often, at this stage, it is advisable to receive training in SAP R/ 3 and to compare the functions in your current systems with the functions in R/ 3. Often, there is a gap. During the project, you can usually resolve most of this gap, either by developing an interface to a current system, by developing a custom report with the ABAP/ 4 programming language included with R/ 3, or possibly by modifying your procedures. Sometimes, this stage is called the "As-Is Analysis."
2. Analyze your business requirements and strategy. Why are you thinking of changing your system? What is your business strategy? What is your inter-national strategy? How can your financial reporting support these strategies? What are your legal and internal financial reporting requirements? What are your most frequent transactions, besides customer invoices, payments from customers, vendor invoices, and payments to vendors? How will your organization, markets, or applicable regulations likely change in the future? At the end of this stage, define clearly any gaps there are between your business requirements and the functionality of the package. Be aware that you have licensed a package and not a piece of custom software that was developed specifically for your company. Develop a plan to resolve any gaps between required functions in your current systems and available functions in SAP. Usually, you can resolve these gaps by developing an interface program or by developing a custom report with the ABAP/ 4 programming language. As a last resort, you can modify the package, since SAP supplies all ABAP/4 source code with your license. However, beware of modifying the package to add fields or func-tions. If you modify the source code, then these modifications can be difficult or impossible to repeat when you upgrade the software to the next version. If these gaps are too wide, then stop the project and do not implement the package. Sometimes this stage is called the "To-Be Analy-sis." It is also known as a feasibility study.
3. Define and configure your financial organization-- groups (one or more company codes), credit control areas (one or more company codes), company codes (usually legal entities or units of organization that prepare an independent balance sheet and profit and loss statement), and business areas (any units that prepare an internal balance sheet and profit and loss statement across company codes). If you are setting up SD, define and configure your sales organizationÑ sales organizations (usually regional), distribution channels (for example, wholesale, retail, and direct), and divisions (usually by type of product or service). If you are setting up MM, define and configure your purchasing and stockkeeping organization-- plants (storage or production facilities), storage locations (for example, bonded and non-bonded sections of a warehouse), and purchasing organizations (groups of buyers).
4. Configure your master data. In this stage, you determine which fields are required, optional, or suppressed for each account group for each type of master record (general ledger account, customer, or vendor). You also determine how these master records are to be numbered, when they are entered later. Test the entry of all required types of master records.
5. Configure your transaction data. In this stage, you determine what types of journals you keep (by the so-called document type) and how the transactions in each journal are to be numbered. Test the entry of all required types of transactions, except payments to vendors.
6. Design, develop, and test any data interfaces (programs required to transfer data from existing systems to SAP, and possibly from SAP to your existing systems). This is often the most complicated and time-consuming step in the whole project, since it requires in-depth knowledge of the data (file and record) formats in your current systems, as well as the cooperation of your technical people. The most frequent interfaces to be developed have to do with transferring customer master data, vendor master data, and customer invoices from whatever system you use to enter orders and print invoices. If you will use SD (the SAP module for order entry, shipping, and invoicing), then you can print invoices and post them to FI without an interface. Otherwise, you usually require some programs to transfer your customer invoice data and post it by batch input into FI. SAP can read in customer, vendor, and invoice data from any external system, but you first have to convert your data to the SAP batch input format. To finish your project quickly, it is advisable to develop only the minimal number of interfaces necessary to integrate the new system with your current systems.
7. Design, develop, and test any printed forms to be printed by the system, such as checks to vendors, dunning letters to customers, account state-ments to customers, purchase orders to vendors (MM Purchasing), and invoices to customers (SD). This stage includes setting up and testing the automatic payment program to pay vendors (and employee travel expenses, if configured properly) based on due dates of invoices. It also includes setting up and testing the dunning program to prepare dunning letters to customers based on overdue invoices.
8. Review the requirements for financial reporting. Test the reports supplied with the package based on test data that you enter. Most of all, the supplied reports were intended to meet legal reporting requirements. It is not advisable to develop nor to modify these supplied reports, since it can be difficult or impossible to repeat any modifications, when you upgrade to the next release of the package.
9. Test the configuration, data entry, and reporting thoroughly. It is advisable to run the new system in parallel to your current systems for at least one month, if your people will accept this extra workload.
10. Train your users thoroughly. Before you train your users, make sure that the trainer is trained.
11. Document your specific procedures for entering data and preparing reports. Also document your configuration, so you can repeat it later, if necessary. It is also advisable to document any custom programs that you have developed, so that you and your programmers understand what the purpose of the program is and how to maintain it. Also, document any custom procedures that you have, such as end-of-month closing procedures.
12. Load your data and start the new system.
These projects can take 3-- 12 months, depending on the complexity of your current systems, your requirements, and the interfaces.