SAP's Open SQL

ABAP/4 code is portable between databases. To access the database in an ABAP/4 program you will code SAP's Open SQL. Open SQL is a subset and variation of ANSI SQL. The ABAP/4 interpreter passes all Open SQL statements to the database interface part of the work process (see Figure 1.27). There, they are converted to SQL that is native to the installed RDMS. For example, if you were running an Oracle database, your ABAP/4 Open SQL would be converted by the database interface to Oracle SQL statements.

If you use Open SQL, your SQL statements will be passed to the database interface. Using Open SQL has three main advantages. All of these advantages are implemented via the database interface.

PortabilityThe first advantage is the fact that your SQL statements will be portable between databases. For example, if for some reason your company wanted to switch from an Oracle to an Informix database, it could change the database, and your ABAP/4 code would continue to run without modification.

Buffering Data on the Application Server
Secondly, the database interface buffers information from the database on the application server. When data is read from the database, it can be stored in buffers on the application server. If a request is then made to access the same records, they would already be on the application server, and the request is satisfied from the buffer without having to go to the database. This buffering technique reduces the load on the database server and on the network link between the database and application servers, and can speed up database access times by a factor of 10 to 100 times.

Automatic Client Handling
The third advantage of using Open SQL is automatic client handling. With Open SQL, the client field is automatically populated by the database interface. This gives your development and testing teams many advantages, such as the ability to perform multiple simultaneous testing and training on a single database without interference from each other.

Roll-In/Roll-Out Processing

An ABAP/4 program only occupies a work process for one dialog step. At the beginning of the dialog step, the roll area and user context are rolled in to the work process. At the end of the dialog step, they are rolled out.

During the roll-in, pointers to the roll area and user context are populated in the work process. This enables the work process to access the data in those areas and so perform processing for that user and that program. Processing continues until the program sends a screen to the user. At that time, both areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work process. That work process is now free to perform processing for other requests. The program is now only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent, and will soon send another request.

When the next request is sent from the user to continue processing, the dispatcher allocates that request to the first available work process. It can be the same or a different work process. The user context and roll area for that program are again rolled in to the work process, and processing resumes from the point at which it was left off. Processing continues until the next screen is shown, or until the program terminates. If another screen is sent, the areas are again rolled out. When the program terminates, the roll area is freed. The user context remains allocated until the user logs off.

In a system with many users running many programs, only a few of those programs will be active in work processes at any one time. When they are not occupying a work process, they are rolled out to extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve high transaction throughput.

The 12 Cardinal Sins of ERP Implementation

There are twelve major reasons for why companies get bogged down or fail in implementing ERP.

1. Lack of Top Management Commitment: The propensity of top management to delegate the oversight of an ERP implementation to lower management levels often results in (1) being "out of touch" with critical events, or (2) the lack of understanding of the size, scope, and technical aspects of the project, and subsequently, the lack of proper commitment of time and resources required for a successful implementation. The result is a failure waiting to happen.
   
   
2. Inadequate Requirements Definition:  Surveys have shown that inadequate definition of functional requirements accounts for nearly 60% of ERP implementation failures. This is simply a matter of not comprehensively and systematically developing a quality set of functional requirements definitions. This leads to the second greatest cause of ERP implementation failures: poor package selection.
   
   
3. Poor ERP Package Selection: Poor package selection occurs when a company has inadequately developed functional requirements definitions. It also occurs when staff members assigned to ERP projects do not take the time to run the screens of the new system, as they would during their daily work tasks, to find out if the software package features are adequate for their needs. Another reason we have found is executives, familiar with an ERP system from a last job they held, implement the same system in their new company without defining functional requirements. We have also encountered companies who made major gaffes by selecting a package at the top levels of a company without intimately knowing its characteristics. What often results from this is the ERP package doesn't fit the organizational needs, or that the package selected takes longer to process daily work tasks. We have also seen executives select a distribution package for a manufacturing environment, or a manufacturing package for a distribution environment, for obscure reason, such as liking one salesman over another.
   
   
4. Inadequate Resources: The third greatest reason for ERP implementation failures is inadequate resources. Many companies will attempt to "save dollars" by doing everything on an overtime basis, whether or not there are adequate skills within the company, extending individual work loads to 150%. This approach can be a "kiss of death" for the program. Time and time again we run across this mistake in ERP implementations. The financial and emotional drain of what seems sometimes to be perpetual extensions, reschedules and delays of implementations takes its toll. People burn out after having put in extensive hours over a long period of time.
   
   
5. Resistance to Change/Lack of Buy-in: The lack of a change management approach as part of the program can prevent a program from succeeding. Resistance to change is quite often caused by (1) A failure to build a case for change, (2) Lack of involvement by those responsible for working with changed processes (3) Inadequate communication (4) Lack of visible top management support and commitment, and (5) Arrogance. A lack of buy-in often results from not getting end-users involved in the project from the very start, thereby negating their authorship and ownership of the new system and processes.
   
   
6. Miscalculation of Time and Effort: Another cause of ERP implementation failure is the miscalculation of effort and time it will take to accomplish the project. Companies who treat an ERP selection, evaluation and implementation comparable to buying a washing machine are doomed to failure.
   
   
7. Misfit of Application Software with Business Processes: One of the main causes of ERP implementation failure is the misfit of application software with the company business processes. This failure -- to examine underlying business process flaws, and integrate the applications with the business processes, causes loss of productivity and time, and ultimate benefits.
   
   
8. Unrealistic Expectation of Benefits and ROI: Another significant cause for ERP implementation failure is the unrealistic expectation of benefits and return on investment. Software providers are notorious for overstating the benefits in terms of ROI, when the total costs of the project have been understated. Often left out of the total costs are costs of planning, consulting fees, training, testing, data conversions, documentation, replacement staffing, and the learning curve performance drop. When this happens, a company doesn't stand a chance of achieving the ROI it anticipated.
   
   
9. Inadequate Training and Education: Another of the biggest causes of ERP implementation failure is inadequate education and training, which are almost always underestimated. ERP-related training is crucial as most employees must learn new software interfaces and business processes which affect the operation of the entire enterprise. The corporate culture is impacted by changes in the company’s business processes, and shortchanging this part of the ERP implementation leads to much pain and suffering downstream.
   
   
10. Poor Project Design and Management: A major mistake is to short-cut critical events in the project plan, such as time for documentation, redefining and integrating processes, or testing before "going live." Another common mistake is made when a company leaves out the self-examination of business processes and uses ERP to cover-up weaknesses. It is easier to buy software than to perform the more difficult task of identifying weaknesses and opportunities for improvement.
    
    
11. Poor Communications: One of the causes of ERP implementation failure is poor project communications, beginning with a failure to announce the reason for the up and coming effort, and continuing to advise the organization of the progress and importance of the ERP implementation to the company. Poor communications prevent different parts of the organization from assessing how they will be impacted by changes in processes, policies, and procedures. Communications are a vital part of managing change in a corporate environment.
    
    
12. Ill-advised Cost Cutting: Another of the key causes of ERP implementation failure is ill-advised cost cutting. In an effort to avoid temporary conversion costs, some companies take a very risky route and go live at multi-plant sites simultaneously, subjecting all plants or some plants to a total shutdown should there be a false start-up. This is suicidal. Others attempt to unrealistically compress the schedule in order to save on expenses, only to eventually overrun both schedule and budget. We feel that ROI should take a "back seat" when upgrading an important part of a company's infrastructure: the information system. Instead the implementation should be treated as an upgrade to the company infrastructure that is necessary to maintain or gain a strategic and competitive advantage.

Pragmatic Applications

The first corollary of ERP or information systems implementation is:  Information systems are part of a company infrastructure, and therefore are strategic to the company's survival and success. If a company does not consider IS as one of its critical success factors, chances are, the competition does.

The second corollary of ERP or information systems implementation is: ERP and information systems are there to support business functions and increase productivity, not the reverse.
The driver for an ERP implementation should be to increase a company's competitiveness, not the adoption of a new religion that bends or distorts how a company conducts its business.

The third corollary of ERP or information systems implementation is: Learn from the successes and failures of others and don't attempt to reinvent the wheel of ERP implementation practice. There are time-proven approaches that can enhance the success of the ERP implementation.
Here are a few:

High Employee Involvement:
Get as many employees to participate heavily as practicable in accomplishing the functional requirements definition. The workers know their work and what they need to compress time. If they do not, use an outsider who does. Use a knowledgeable team to review and select packages. Get as many employees as practicable involved in the implementation phase. This will foster ownership and buy-in.

A Comprehensive and Systematic Approach:
Use a comprehensive and systematic master plan that addresses all parts of an ERP systems implementation: development of IT strategy, requirements definition, review/selection of software, hardware, communications, unit testing, systems testing, conversion, resources, education/training, resistance to change, etc.

Adequate Resources:
Provide adequate technical and administrative resources to allow employees breathing room. Perform cost/benefit analyses so that you know how much the entire implementation is going to cost and identify the results that will be achieved.

Extensive Education & Training at all Levels:
Provide adequate training for most employees, including upper and middle management.

SAP New GL Configuration

INTRODUCTION

This material is applicable for SAP ECC 5 and ECC 6 version.
SAP has introduced a new concept called as SAP New GL structure. Let us understand this concept of SAP New GL structure and its use.

Typically in SAP you can depict parallel accounting, which means you can carry out valuations and closing operations for a company code according to local accounting principle and a second accounting principle (parallel) i.e. the group accounting principle.

Until version 4.7 you could carry out the parallel accounting only by using additional accounts.

Certain GL accounts are common between 2 the accounting areas. Certain GL accounts applicable only for local reporting
Certain GL accounts applicable only for group reporting. This kind of a set up requires 2 retained earnings accounts.
The disadvantage of this set ups is lot of GL accounts are required and sometimes reconciliations become difficult.

To do away with the above approach SAP has now introduced the SAP New GL structure. In this approach parallel accounting is depicted using an additional ledger.

The data for one accounting principle is stored in the general ledger. This ledger is known as the Leading ledger or Leading valuation view.

For each additional (parallel) accounting principle, you create an additional ledger

The advantages of this approach are:-

1. You do not have to create any additional G/L accounts
2. You manage a separate ledger for each accounting principle
3. You can use the standard reporting functions to create a financial statement
4. You can have different fiscal year variants attached to each of the additional ledger.
5. You can make manual postings to any of the additional ledgers.

Configuration Scenario:
A Grp of companies (Parent company) is a multinational company with companies across the world with base in Germany. The company has decid ed to implement SAP for its subsidiary G Ltd located in India. A Grp of companies have to use the common chart of accounts. The currency in India is INR. The Parent company wants the accounts to be prepared based on Calendar year January to December. The Financial reporting should be in EURO.

G Ltd has a local reporting requirement under the companies act
G Ltd also has a tax requirement to prepare it Accounts based on accounting period April to March.

Based on the above requirements we need to configure the following using the SAP New GL Structure

Create company code 9101 – G Ltd. The company code currency– INR
Parallel currencies to be implemented – EURO
Common chart of accounts – YCCA
Ledger 0L (leading valuation view) reporting period – Jan to December for group reporting
Ledger Y1 (additional ledger) for local reporting under the companies act.
Ledger Y2 (additional ledger) for local tax reporting period (April to March)

1. Creating Company Code

Company code is the basic organizational unit in FI (Financial accounting) for which a balance sheet and profit & loss account can be drawn. We create company code 9101 (G Ltd.) which is located in country India.

For doing the configuration we use the following path on the SAP application screen:-

SAP Menu >> Tools >> Customizing >> IMG >> SPRO - Execute Project >>


Configuration for all the modules will be done here. The above path will not be referred henceforth; we will directly refer to the IMG node.

SAP Customizing Implementation Guide >> Enterprise Structure >> Definition

>> Financial Accounting >> Edit, Copy, Delete, Check Company Code

Double click on Edit Company Code data



By selecting the second option Edit Company Code data you have to manually configure all the subsequent assignments.

By selecting the first option all the configuration and tables get copied automatically along with assignments. This option should be selected in case of rollouts.

In the Copy option you need to click on COPY AS ICON to copy a company code from an existing company code. You can copy from existing com pany code delivered by SAP.

You can select a four-character alpha-numeric key as the company code key. This key identifies the company code and must be entered when posting business transactions or creating company code-specific master data, for example.

We will cover the FI configuration from scratch and not copying configuration from an existing company code.



Click on and update the following fields:



The company code should be always kept numeric.

Country: The country where company code is located and the balance sheet and income statement which will be prepared according to that country law. Here the company is located in India so, we have selected the country id IN (INDIA).

Currency: It is the local reporting currency of the country. In this case it is INR (Indian rupees) since the company is located in India.

Click on Address and update the following fields

Click

Click

Company code 9101 is created in SAP

2. Ledgers (New)
2.1.1 Ledger
2.1.1.1 Define Ledgers for General Ledger Accounting
You define the ledgers that you use in General Ledger Accounting. The ledgers are based on a totals table. SAP recommends using the delivered standard totals table FAGLFLEXT.

The following types of ledgers are available:

Leading Ledger

The leading ledger is based on the same accounting principle as that of the consolidated financial statement. It is integrated with all subsidiary ledgers and is updated in all company codes. You must designate one ledger as the leading ledger.
In each company code, the leading ledger automatically receives the settings that apply to that company code: the currencies, the fiscal year variant, and the variant of the posting periods.

In our scenario the group reporting is handled by the Leading Ledger.

Non-Leading Ledger

The non-leading ledgers are parallel ledgers to the leading ledger. They can be based for example on local accounting principles

You must activate a non-leading ledger by company code.
For each ledger th at you create, a ledger group of the same name is automatically created. 

In our scenario the local reporting is handled by the Non- leading ledger.

IMG >> Financial Accounting (New) >> Financial Accounting Global Settings (New) >> Ledgers >> Ledger >> Define Ledgers for General Ledger Accounting

0L is the Leading Ledger.

Click on


Update the following:-


Click On:

Click



Click

2.1.1.2 Define Currencies of Leading Ledger

IMG >> Financial Accounting (New) >> Financial Accounting Global Settings (New) >> Ledgers >> Ledger >> Define Currencies of Leading Ledger

Here you specify the currencies to be applied in the leading ledger. You can make the following settings for each company code

Click on

Update the following:-

Click 



Now update the following:-



Click on

2.1.1.3 Define and Activate Non-Leading Ledgers

IMG >> Financial Accounting (New) >> Financial Accounting Global Settings (New) >> Ledgers >> Ledger >> Define and Activate Non-Leading Ledgers

Here you make the following settings for the non -leading ledgers for each company code:
You activate the non-leading ledgers in the company code.

You can define additional currencies beyond that of the leading ledger. The first currency of a non-leading ledger is always the currency of the leading ledger (and hence that of the company code). For the second and third currencies of a non-leading ledger, you can only use currency types that you have specified for the leading ledger.

You can define a fiscal year variant that differs from that of the leading ledger. If you do not enter a fiscal year variant, the fiscal year variant of the company code is used automatically.

You can specify a variant of the posting periods.



Update the following:-



Click on

Update the following:-

Click On
Click on

Now update the following:-



Click on

Update the following:



Take a drop down in the field FV (Fiscal year variant)



You can even assign a dif ferent posting period variant to this ledger




Click on

2.1.1.4 Assign Scenarios and Customer Fields to Ledgers


IMG >> Financial Accounting (New) >> Financial Accounting Global Settings (New) >> Ledgers >> Ledger >> Assign Scenarios and Customer Fields to Ledgers


In this IMG activity, you assign the following to your ledgers:


Scenarios

This determines what fields in a ledger are updated when it receives posting from other application components.

Custom Fields

You can add custom fields (that you have alread y defined) to the ledger.


Versions
This enables you to make general version settings for the ledger that depend on the fiscal year. In the versions, you specify whether actual data is recorded, whether manual planning is allowed, and whether planning integration with Controlling is activated.





Select



Click




Click





Click




Click on








Click on

Click




Click

Select


Click

Click on


Update the following:-





Click on


To assign Profit center update you need to have profit center module active.


Click


Select



Click

Click on


Update the following:-





Click on


2.1.1.5 Define Ledger Group

IMG >> Financial Accounting (New) >> Financial Accounting Global Settings (New) >> Ledgers >> Ledger >> Define Ledger Group

Here you define ledger groups. A ledger group is a combination of ledgers for the purpose of applying the functions and processes of general ledger accounting to the group as a whole.

When posting, for example, you can restrict the update of individual postings to a ledger group so that the system only posts to the ledgers in that group. You can combine any number of ledgers in a ledger group. In this way, you simplify the tasks in the individual functions of General Ledger Accounting. When a ledger is created, the system automatically generates a ledger group with the same name. In this way, you can also post data to an individual ledger or access it when using functions where you can only enter a ledger group and not ledgers.


You can change t he name of the ledger group that was taken from the ledger.


You only have to create those ledger groups in which you want to combine several ledgers for joint processing in a function.


You do not need to create a ledger group for all ledgers because the system automatically posts to all ledgers when you do not enter a ledger group in a function.

Representative Ledger of a Ledger Group

The system uses the representative ledger of a ledger group to determine the posting period and to check whether the posting period is open. If the posting period for the representative ledger is open, the system posts in all ledgers of the group, even if the posting period of the non-representative ledgers is closed. Each ledger group must have exactly one representative ledger:

If the ledger group has a leading ledger, the leading ledger must always be identified as the representative ledger.

If the ledger group does not have a leading ledger, you must designate one of the ledgers as the representative ledger. If the ledger group has only one ledger, this ledger is then the representative ledger. If the ledger group has more than one ledger, the system checks during posting whether the representative ledger was selected correctly. This check is based on the fiscal year variant of the company code:

We do not want to group the ledgers, therefore we do not do any configuration here.





Select




Double click







Select Y1



Double click







Similarly you can check Y2

2.1.1.6 Activate New General Ledger Accounting


IMG >> Financial Accounting >> Financial Accounting Global Settings >>

Activate New General Ledger Accounting (FAGL_ACTIVATION )


By activating New General Ledger Accounting, you achieve the following:

1. The functions for new General Ledger Accounting become available.
2. In the SAP Reference IMG, the previous Financial Accounting menu is replaced by the Financial Accounting (New) menu. Under Financial Accounting Global Settings (New) and General Ledger (New), you can make the settings for New General Ledger Accounting.
3. You activate the tables of new General Ledger Accounting so that your posting data is written to them.

If you already use classic General Ledger Accounting in your production system, you need to perform the migration of this data before you activate


Note: 

“SAP” is a trademark of SAP AG, Neurottstrasse 16, 69190 Walldorf, Germany. SAP AG is not the publisher of this material and is not responsible for it under any aspect.

Warning and Disclaimer

While every precaution has been taken in the preparation of this material, sapexperts.blogspot.com assumes no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information or instructions contained herein. It is further stated that the publisher is not responsible for any damage or loss to your data or your equipment that results directly or indirectly from your use of this material.

Courtesy: www.sapficoconsultant.com