Reports

[Former Member]

Hi Gurus,

Please tell me how to find out new reports in sap sd?

[Former Member · Accepted solution]

Hi Friend,

There are many ways to get reports and reports are nothing but to retrieve the required data in a specific format in SAP.

TOP-10 REPORTING TOOL ESSENTIALS FOR SAP R/3

An overview of SAP R/3 reporting tools as well as examination of the general reporting opportunities SAP R/3 clients have before them.

Introduction

SAP applications (R/3 in particular) are not known for robust and user-friendly reporting – rather, it is known for the very lack of these features. However, no one can claim you cannot report effectively from SAP R/3. This dichotomy of viewpoint is when you consider SAP R/3 has multiple resident reporting tools.

Therefore, users facing the choice of which transactional reporting tool to select for a particular reporting need quickly discover their choice of reporting tool is as important as the report itself.

Knowledge learned in this article can be put to use when:

• Users require a general understanding of how various transactional reporting tools are used within SAP R/3 (up to version 4.6D)

• Users require a general understanding of the various methods of transactional report development within SAP R/3 (up to version 4.6D)

• Users require a general understanding of how various R/3 reporting tools are used in concert with Crystal Reports (up to version 4.6D) to support transactional reporting.

SAP R/3 Reporting Tools

The most widely used release of SAP R/3 is 4.6C and this release includes over 4,000 ready-to-use reports (2,500 – 3500 reports in releases 4.0x – 4.5x). However, since R/3's introduction, many organizations find these standard reports lacking in depth, clarity, ease of distribution and user friendliness.

To develop new reports, or to modify existing reports, report developers within the SAP R/3 universe have several transactional reporting tools to choose from – some are better choices than others for specific reporting needs.

As is well known, SAP R/3 clients have particular reporting needs. In a nutshell, it's a select few who truly embrace the reports R/3 provides.

This is a strange state of affairs when you consider the multiple reporting tools R/3 provides: Report Painter/Writer, ABAP queries, ABAP (customized) reports, R/3 delivered ABAP reports, InfoSets, etc.

With all those to choose from, the question is; “ Why are SAP R/3 users struggling with reporting? ”

Some would point to the area of the data:

1. Is it the way in which it is managed within R/3?

2. Is it the middle-layer storage techniques SAP employs (pool and cluster tables, transparent tables, etc)?

3. Could it be a universal problem with transactional data systems?

This begs the question: should enterprises perform all their reporting tasks strictly from data warehouses or data marts (even for transactional reporting)? My short answer is; no.

In my opinion, the issue is never the data, nor is it the how the data is managed or stored. Reporting from a transactional system should be straightforward and transparent to the users. Although R/3 transactional data (by its very nature) is not consolidated (as in a data mart or warehouse) it does exist in a usable and useful (read real-time) format. Therefore, I cannot subscribe to the posit that only aggregated data (some would say ‘dead data') is best for transactional reporting.

Bottom line: it's the reporting tools we employ .

Here's a brief review of the reporting tools SAP R/3 users have at their disposal:

• ABAP list reports (customized and R/3 delivered)

• Report Writer / Report Painter

• ABAP queries

• InfoSets

• Ad-Hoc Query Tool

• Crystal Reports (using the Business Objects' Integration Kit for SAP)

ABAP List Reports

As is commonly known, using ABAP to generate reports equates to developing and running a shell program containing several key pieces. The data for the report must be identified, retrieved and temporarily stored, manipulated (typically applying either business rules or some other adjustments) sorted and finally, displayed in columns and rows. The ABAP developer makes use of ABAP Functions (essentially sub-routines) to accomplish these various tasks. There is a high-level of skill and effort required to accomplish these tasks within a reasonable amount of time. A clue to the required skill set is the fact that all ABAP reports are saved as ABAP programs.

And that is the issue re ABAP reports – they are time and cost intensive.

Finally, there is maintenance; correcting or implementing even a simple layout modification requires the same skill set to develop the report – making maintenance a costly and time-consuming affair.

However, there are some types of data (and hence reports) ABAP reports excel at – here is an incomplete list:

• Cross-module reporting (i.e., FI and HR data combined into one report)

• Complex data manipulation

• Logical database reliance reporting

• Sophisticated user interface reports (i.e., requiring user input of variables for specific processing steps)

Report Writer / Report Painter Reports

The majority of reports end users use in the R/3 System is Report Painter reports. Most of these reports (@ 80+ %) began as Report Writer reports.

The major difference is Report Painter uses a graphical interface (analogous to Notepad and MS Word).

Very few R/3 users employ Report Writer – however, many still use, modify and develop reports using Report Painter. Report Painter permits complex groupings and drill-down reporting – very useful for such applications as FI-CO and SD. It can also be used interactively – allowing users to enter variables for specific steps; thereby permitting ‘drill-across' functionality.

However, Report Painter does have its limitations; it can display only numeric data (excluding column headers) – therefore, short text, etc. is not available. It is much easier (quicker) to modify than ABAP and requires no ABAP expertise – however, many combine Report Painter with ABAP reports to fill-in many of the missing pieces. Layout design is archaic and rudimentary ~ therefore; many use Report Painter to ‘retrieve and massage the data' and eventually export it into Excel for end use.

ABAP Queries

ABAP Queries are extremely useful: they can retrieve data from tables and logical databases alike. ABAP Queries permit a ‘snapshot' of the current R/3 data.

SAP has made it possible for R/3 users to develop queries using little, if any, ABAP code. However, knowing table and fields (data schema) and some SQL knowledge (outer-joins/inner-joins, etc.) is still required.

ABAP Query reports are typically simple listing and totaling reports (unlike a balance sheet or an income statement requiring complex groupings – for example, a cash or revenue line consisting of several accounts on a financial statement). Such complex groupings require the query to read various tables multiple times to appropriately total and sort the accounts. For complex tasks such as this, the other R/3 tools (such as Report Painter which uses “sets” for these groupings) are better suited for reports with complex and integrated groupings.

Calculated fields are commonly used within queries for ‘data massaging' – permitting the added benefit of applying business rules or ad-hoc data manipulation via formulas. However, to apply these modifications requires knowledge of ABAP syntax. The ability to apply modifications at the field level (known as a Local Field ) is an extremely powerful and important aspect of the ABAP Query tool – a feature which should be employed more often. When coupled with the Use of InfoSets, this tool provides even more flexibility.

Queries are also typically used in the form of simple lists. The most common format is the ALV or the ABAP List Viewer. However, statistical and ranked lists are also provided – each requiring user input during the execution of the query. Simple lists can be exported into Excel, or if installed, Crystal Reports.

What Are the Prerequisites for Using the ABAP Query Tool?

• An understanding of the data dictionary and perhaps some ABAP programming:

While an ABAP programming background is not critical to use this tool, knowledge of the data dictionary and some basic programming is helpful. If you are not familiar with the data dictionary, or do not possess basic programming skills, you may want to enlist the help of a basis/tools expert at some point. These skills will come in handy when the query you are building needs additional tables, additional fields or table joins.

• Knowledge of required database tables and fields:

Before starting to develop a query, you should know the required tables and fields. To execute a query, data must be present in the tables you are accessing. A general understanding of the fields and how they are stored in the database is also helpful. For example, the posted dollar amount in an FI document is stored as an absolute number. The system uses the posting key to determine if the actual value is positive or negative. To show the correct amount in your query you need to create an additional field in the InfoSet which checks the posting key to determine the correct amount. The correct amount is stored in the additional field for your queries.

• R/3 System settings:

An administrator must make the required settings to allow a user to work with ABAP Queries.

• R/3 Authorizations:

End users and system administrators must have appropriate authorizations to use ABAP Queries.

• Development for Transport:

Local vs. Global – when developing a query, you are given the choice: develop a ‘Local' or ‘Global' query. If you intend to promote the query out of DEV to either QA or PRD, Global is your best choice . A Global query permits the R/3 Basis system to transport all associated objects. Otherwise, if developed locally, it is not intended for transport – if you decide you need to transport the query, you must know the name and location of all associated objects and manually transport each one.

In summation: ABAP Queries are extremely powerful and useful tools for transactional reporting; providing you can supply the necessary knowledge required to use them and are satisfied with the output results.

InfoSets

An SAP InfoSet (formerly known as a Functional Area) is crucial for ABAP query usage (in SAP versions 4.6A – onward).

The reason for InfoSets being important is because many R/3 clients find themselves faced with how to develop useful reports from an application using 20k+ tables. In addition, many clients desire to use third-party reporting tools; i.e., Crystal Reports.

At its simplest definition, an InfoSet determines which tables and/or fields within a table queries may reference. To accomplish this, InfoSets are typically based upon table joins or logical databases (LDBs). Therefore, an InfoSet is, for lack of a better term, a form of ‘Super View.'

Since InfoSets are used with later versions of SAP – versions that are more User Role dependant – ABAP queries are also similarly affected. The tool for maintaining queries within the SAP query is called the InfoSet Query – a tool suitable for developing general queries and for ad-hoc reporting.

The InfoSet Query is suitable for reporting in all areas of the SAP R/3 system. A special feature is its Human Resources (HR) module component. When the InfoSet Query is used within HR for ad-hoc reporting, the name Ad-Hoc Query is used instead of InfoSet Query. InfoSet Queries use the SAP List Viewer (aka ALV – ABAP List Viewer) as its standard output medium. This means after executing a query, the output list is displayed within the ALV.

The queries created by the InfoSet Query can be processed with other SAP query tools. Conversely, queries generated with other SAP Query tools may be processed with the InfoSet Query tool.

Remember: because the InfoSet Query uses the ALV as its standard output each query can only output one list. Queries created via the SAP Query tool using a single-level list for output could contain; a basic list, up to nine ranked lists and up to nine statistics per query

Note: Unlike when you develop an ABAP Query, you cannot define and use Local Fields within an InfoSet Query.

Special Note: InfoSets using logical databases (an LDB) and InfoSets without underlying datasets have largely the same structure

Because a logical database (LDB) is a hierarchical structure of tables, an InfoSet without an underlying database is based on a single (sequential) table. Therefore, you can think of an InfoSet without an underlying database (LDB) as a special kind of InfoSet that uses a logical database consisting of a single table .

You can link tables using InfoSets – this brings us back to knowledge of the underlying data schema and the required joins. The output is best used via the screen; as opposed to print. Once again, most export the results into Excel for distribution and to have a usable layout.

Ad-Hoc Query Tool

Starting with SAP version 4.0b, the Ad-Hoc Query tool was made available within the HRIS (Human Resources Information System). As is the case with ABAP queries, developers are not required to have ABAP programming skills to use the tool.

However, the same caveat pertains to Ad-Hoc Queries as to ABAP queries ~ basic Functional Area data schema knowledge is required to use the tool. In other words, you must know which are the correct tables and fields to use within the query. Furthermore, a basic understanding regarding how to join the fields between tables (inner, outer and equal joins) is also required – therefore, some understanding of the SQL language is helpful as well.

That being said, the Ad-Hoc Query tool has proven itself to be of great benefit for HR functional users – specifically; it consults the HR InfoTypes to derive its data – and InfoTypes are the building blocks of the HR module. The only restriction is: the data must reside within an InfoType . There is one other restriction: only 99 InfoTypes may be used by Ad-Hoc Query end-users.

In versions 4.6a and above, the InfoSet query tool (which has access to all modules within R/3) uses the logical databases: PNP, PCH and PAP within the HR module – just as in versions 4.0b and above, the Ad-Hoc Query tool does.

The InfoSet query tool supports two types of reporting:

• HR Ad-Hoc reporting

• General query development

Ad-hoc reporting is possible in both query areas (Global and Standard (Local)). In the Global area, they are always saved in a temporary development class – end-users create and save their queries in the usual Query area. However Global area queries lack the typical transport link to the ABAP Workbench Organizer – therefore, an InfoSet query is known within the HR module as an Ad-Hoc Query . Finally, HR Ad-Hoc queries automatically initiate default values, i.e., the specified query area and user group parameters – meaning an end-user who starts the InfoSet query, using the HRIS, will either go directly to the initial screen of the InfoSet query, where the assigned InfoSet is displayed, or can choose between several assigned InfoSets.

Crystal Reports (using the Business Objects' Integration Kit for SAP)

In the past, SAP clients had two choices: make do with what is delivered (and risk end users not using the reports) or make the ongoing capital investment in ABAP-customized reports. It remained this way until 1998 when Seagate Software (later Crystal Decisions and now Business Objects) developed its first generation SAP Open SQL driver (the QuickStart Driver for SAP™). Crystal Reports 6 and Seagate Info 6 were its flagship products at that time. This early driver has evolved into a robust R/3 report solution and its evolution continues to this day.

Today's integrated suite of Crystal reporting and deployment tools (known collectively as Business Objects XI) allows SAP report developers to make use of SAP's powerful programming language – ABAP (known as ABAP/4, designating it uses a 4th generation programming language – or 4GL). The ability of Crystal Reports to make use of ABAP equates to time and dollar savings – i.e., previously developed ABAP reports and/or queries may be integrated into a complete enterprise reporting solution. Therefore, corporate end users without SAP access may now enjoy the benefits of SAP data within their own customized reports.

Never intended as a replacement for SAP reports (including in-production ABAP and Report Painter reports) this 3 rd party reporting solution from is still the best adjunct/complimentary R/3 reporting tool on the market. No other 3 rd party reporting tool achieves what the Crystal suite of tools provide to the SAP R/3 customer – and in June of 2002, SAP began bundling the Crystal tool into its release of BW – the first such non-SAP product to be bundled.

The Crystal SAP reporting tool has been successfully implemented at many organizations around the world – from SAP R/3 customers requiring reports for as few as 50 SAP end users to organizations needing reports for over 110,000 SAP end users.

Because the Business Objects' Integration Kit for SAP software interface accesses the R/3 environment at the ABAP Dictionary application layer, the following benefits exist:

1. Customary analysis into R/3 data structures, because it uses same interface layer as an ABAP program

2. Rapid development environment with graphical interface for report development

3. Straight-forward local and server installation and setup, providing access to all R/3 HR InfoTypes without requiring any extemporizing or ad-hoc metadata configuration

4. An intuitive environment for business users to schedule and view R/3 reports without having knowledge of the underlying R/3 environment

5. Supported Functional area power users are able to develop complex SAP reports without having to understand the ABAP programming environment. Business Views and/or Universes may be employed to further hide the complexity of the underlying R/3 environment

6. The ability to integrate R/3 data with disparate data from non-R/3 sources; such as a ‘best of breed' application's relational database (i.e., Oracle, SQL Server, MS Access), text files, spreadsheets, etc.

7. Full respect of SAP R/3 security re roles and profiles

The SAP R/3 Data Dictionary is a data management system (DMS). The principle functions performed by a data dictionary include the following tasks:

• The management of all data definitions (metadata)

• The ability to provide information for evaluations

• Managing the underlying support for software development

• Providing support for documentation

• Ensuring its data definitions are: reliable, flexible and always up-to-date

With respect to Crystal Reports, the data structures permitted for use for reporting (i.e., Transparent Tables, Pool Tables, Cluster Tables and Views) are all defined within the Data Dictionary.

Because Crystal Reports will access the SAP R/3 environment via the Data Dictionary, only those R/3 data types defined within the Data Dictionary may be referenced from within the Crystal tool. However, unlike ABAP reports, ABAP Queries, etc, Crystal Reports is not ‘tied' to a particular Logical Database; therefore developers can create cross-module reports very quickly and easily.

From this Data Dictionary point of view; here is a brief look at the supported data table types:

• Transparent Tables

Transparent tables contain the majority of R/3 application / business intelligence data. These tables may be linked to other transparent tables to access information from other application areas within the R/3 system (i.e., cross-module reporting)

• Pooled Tables & Cluster Tables

Cluster and Pool tables are tables made up of a logical grouping of other database tables or data elements. These table types are primarily used to store application configuration and process-step control information rather than the actual application data (HR module is the exception regarding cluster tables)

• Database Views

The R/3 system provides the user with the ability to define application-specific views of the underlying data. This allows data from several tables to be summarized in a useful and logical manner.

In addition, Crystal can make use of new or existing ABAP Queries, Ad-Hoc Queries, Functions, InfoSets, etc. – thereby leveraging the development investments a customer has made. But as mentioned at the beginning; Crystal is not a replacement for these SAP reporting tools – therefore, the first question to be asked is, “What business need compels me to develop this report in Crystal ?”

In summation: prudent and knowledgeable use of Crystal Reports (including Business Objects Enterprise for report scheduling, additional security distribution, etc) brings a new level of sophistication and report development ease-of-use. These qualities are lacking in most of the SAP-included tools.

Conclusion

We have reviewed the most common reporting tools employed within the SAP R/3 System and each tool has its strengths and weaknesses. But does each tool meet the basic requirements for what an ERP reporting tool should possess?

Therefore; in no particular order I present the 10 key elements I believe all ERP reporting tools should contain:

1. Total ease of use – minimize the learning curve. Users must be able to rapidly learn how to create their own customized reports, ‘run' the reports and display them. It should be even easier (if all a user needs to do is view a report)

2. Quicker return on your software investment -- time saved in training and in using the reporting tool

3. Flexibility – the proper tool must be able to read off several data sources at once. For example, Not only can you report off of your R/3 data, but PeopleSoft data (if you use it) and other data kept on legacy boxes. This is called a ‘ managed reporting environment ' (a future article will cover this critical issue)

4. Respecting ERP security settings – your people in marketing should not have access to financial and/or HR data must always be protected

5. Save time and money when creating your firm's customized reports – in SAP for example, ABAP programmers are expensive and time-intensive. The tool must beat this benchmark by several factors

6. Finished-report deployment strategies – via e-mail, hard copy, web (PDF, HTML, XML, etc), Lotus Notes format, etc. This output should be automatic and not require human intervention or actuation

7. Rapid implementation and training – your people should be 80% self-sufficient in the shortest time

8. Maintenance of the finished reports should not be an issue. Newer versions of the ERP software should have minimal or no impact on reports you have created. Also, report modification should be quick and not require arcane technical knowledge (as ABAP is).

9. Use of a 3 rd party reporting tool must not degrade the performance of your ERP system. It should quickly retrieve the required data (after applying the necessary filters) and be capable of ‘data massaging' off-line. This can be desirable for select R/3 functional areas

10. The reporting tool must respect your business rules – business rules are what differentiate your SAP R/3 system from your competitors. You must not have the reporting tool replicate your business rules (there might be a one-off exception) – access to the Data Dictionary and/or the Logical Databases is a must.

[Former Member]

SD REPORTS

Reports: Reports consist of data, which is expected to be reveiwed or checked the transaction taken in said period. Reports are useful for analysis of decision taking for future activities.

Some of the standard reports for SD & its configuration guide is as under:

Standard SAP SD Reports:=

Statistic Group:

Purpose – To capture data for Standard Reports, we require to activate Statistic Group as under:

--> Item category (Configuration)

--> Sales document type (Configuration)

--> Customer (Maintain in Master data)

--> Material (Maintain in Master data)

When you generate statistics in the logistics information system, the system uses the combination of specified statistics groups to determine the appropriate update sequence. The update sequence in turn determines for exactly which fields the statistics are generated.

Configuration:

IMG --> Logistics Information System (LIS) --> Logistics Data Warehouse --> Updating --> Updating Control --> Settings: Sales --> Statistics Groups -->

1. Maintain Statistics Groups for Customers

2. Maintain Statistics Groups for Material

3. Maintain Statistics Groups for Sales Documents

4. Assign Statistics Groups for Each Sales Document Type

5. Assign Statistics Groups for each Sales Document Item Type.....

All Standard Reports which are available are as under:

SAP Easy Access: Information Systems -> Logistics -> Sales and distribution ->

1. Customer -> Incoming orders / Returns / Sales / Credit memos / Sales activities / Customer master / Conditions / Credit Master Sheet

2. Material -> Incoming orders / Returns / Sales / Credit memos / Material master / ...

3. Sales organization -> Sales organization / Sales office / Sales employee

4. Shipping point -> Deliveries / Returns

5. SD documents -> Orders / Deliveries / Billing documents ...

& so on.

Some of the Standard reports in SD are:

Sales summary - VC/2

Display Customer Hierarchy - VDH2

Display Condition record report - V/I6

Pricing Report - V/LD

Create Net Price List - V_NL

List customer material info - VD59

List of sales order - VA05

List of Billing documents - VF05

Inquiries list - VA15

Quotation List - VA25

Incomplete Sales orders - V.02

Backorders - V.15

Outbound Delivery Monitor - VL06o

Incomplete delivery - V_UC

Customer Returns-Analysis - MC+A

Customer Analysis- Sales - MC+E

Customer Analysis- Cr. Memo - MC+I

Deliveries-Due list - VL04

Billing due list - VF04

Incomplete Billing documents - MCV9

Customer Analysis-Basic List - MCTA

Material Analysis(SIS) - MCTC

Sales org analysis - MCTE

Sales org analysis-Invoiced sales - MC+2

Material Analysis-Incoming orders - MC(E

General- List of Outbound deliveries - VL06f

Material Returns-Analysis - MC+M

Material Analysis- Invoiced Sales - MC+Q

Variant configuration Analysis - MC(B

Sales org analysis-Incoming orders - MC(I

Sales org analysis-Returns - MC+Y

Sales office Analysis- Invoiced Sales - MC-E

Sales office Analysis- Returns - MC-A

Shipping point Analysis - MC(U

Shipping point Analysis-Returns - MC-O

Blocked orders - V.14

Order Within time period - SD01

Duplicate Sales orders in period - SDD1

Display Delivery Changes - VL22

Shipment List Planning - VT11

List of Incomplete Shipments -Try VT04/VT11/VT32

Delivery without Shipments -Use VL06O

Reward if useful