Z-Reports are many times nothing but Repairs at the transaction level. The cost is giving away the advantages of using standard SAP reports and taking all the risks attached to Z-reports.
Abstract
In the next couple of paragraphs, I would argue that Z-Reports are many times nothing but Repairs at the transaction level. I would point at the advantages of using standard SAP reports on the one hand and the risks of Z-reports on the other hand. Thereafter, I will suggest a framework that enables the business end-users to extend SAP reports without the need to copy them. I will show how this framework leverages the advantages of standard SAP reports and minimize the cost of reusing them. I will end by pointing the boundless possibilities to enhance the framework
Standard vs. locally developed Z-Reports.
An SAP vanilla system is shipped to customers with a set of reports that help end-users to query the application. Standard SAP reports are ABAP-based executable programs that read data from the database, manipulate it, and generate an output based on the filter criteria selected by the end-user. Alas, often those SAP standard reports are falling short to fulfill all customers’ needs. Using the ABAP integrated development environment (IDE), customers will employ developers to code their own reports. Those Z-reports, named after the customer namespace (letters Z & Y) assigned by SAP, will be used by the organization’s end-users instead of the SAP standard ones.
The advantages in Standard SAP report
When SAP ships a standard report it is held liable for that report in relation to accuracy, scope, performance, and authorization. That very same report will serve all SAP customers, in different languages, using different currencies and unit of measures. In addition, no-one would think of a standard SAP report that lacks authorization checks – That’s not an option. Needless to say that SAP invests heavily to make sure that each and every report it ships will hold the standard. Yet, even if SAP failed to meet all these requirements, the enormous number of users’ invocations will force SAP to perfect that report with time. Years filled with heavy use by customers, cycles of OSS incidents and notes, yield an, almost Darwinian, mechanism of perfection.
Moreover, in case of changes in standard scenarios, SAP is responsible for adjusting the reports correspondingly.
Z-Reports, on the other hand, do not receive the same resources and attention – Not even close. No organization may afford to invest so much in a single report and thus, by definition, SAP standard reports define the highest quality bar.
Z-Report – the Why?
Nevertheless, organizations keep investing in those Z-Reports. Among the most common reasons to develop Z-Reports are missing data columns and site-specific information reside in locally developed DB tables (AKA Z-Tables).
During my ABAP programming period, I have participated in countless meetings that looked, more or less, the same: A business end-user requires an SAP report “Plus” – Where the “Plus” refers to the additional things (extras) he/she needs on top of the standard SAP report. Another requirement might be demand for a new UI – WebDynpro ABAP/ WebDynpro Java back in the days and UI5 today.
All these– accelerates inevitably the development of new Z-Reports.
To rewrite a standard report, three main steps are taken by the ABAP developer:
- Copying/imitating the original SAP logic
- Adding the Extras
- Coding the UI
Code and Object Repair
The SSCR (SAP Software Change Registration) is a procedure for registering all manual changes to SAP source code and Dictionary objects. In SAP documentation related to the SSCR one may find the following warning:
Modifications severely reduce SAP’s warranty obligations concerning the software it delivers. Despite this reduced liability, SAP will continue to try and support customers who have modified their systems themselves.
In addition, as soon as the object (SAP source code and Dictionary objects) was locally repaired, the SAP automatic note mechanism may cease to affect it. Hence, modifications/fixes done by SAP notes to a repaired object will not be applied to it w/o manual code adjustments implemented by the organization.
All in all, deserting Standard means losing both warranty and authenticity of the repaired object – Nothing to take lightly.
Yet, the process of writing a Z-report conceals the described two drawbacks: SAP will neither be held liable for problems in that report nor be able to fix/modified it along with the corresponding original one.
Yet, while each repair is seriously argued and discussed, coding a Z-report takes place almost silently.
Root cause analysis
Mark Twain has often been quoted as saying: “Everybody talks about the weather but nobody does anything about it“. Or in other words, as long as no way exists to avoid those Z-Reports, we will treat them like the weather.
The same applies to the process by which business end-users keep downloading reports to Excel for further data manipulation. Downloading data to Excel – the eighth wonder of the world – comes with a great cost. Losing trust (Authentication, Authorization and Audit-trail), living out of SAP context (no drill-downs, DB lookups, and data write-back), and lacking a single corporate truth and language – to name a few.
At the end of the day, both problems – Z-reports and downloading data to Excel alike – are treated like the weather. We need them to keep the work done and since we have no way to avoid them, and thus all we can do is talk about them.
A new line of thinking
It appears as if Man has more control over the weather than is commonly thought. It started many years ago with a technology to draw-in rains and today we are far better in this field. Yet, the weather is not the topic in question, but merely an example of things that on the surface may look untouchable.
What if we could avoid coping standard SAP reports altogether?
Let’s think of a framework by which the original SAP report is invoked in the background and its content (data and metadata) is retrieved. Then, based on the metadata, a corresponding ALV is dynamically created to which the report’s data is incorporated. This way, we have the standard report content as a baseline – avoiding the drawbacks of source code Repairs.
Now, we have endless options to enrich the report:
By adding “Extra” data columns of types formula, DB Lookup, and Input we could enhance the original report as needed. Do note that the newly added data columns are saved aside in DB tables referencing the original report’s records – leaving the original report intact.
Another feature, content-wise, is enhancing the Authorization layer: By adding record/column authorization checks, the presented data could be further distinguished. Now, based on the SAP authorization concept, end-users may or may not see content at cell-level granularity.
As far as presentation is concerned, we can improve the UX by allowing conditional formatting, something that’s well familiar for Excel users. This way, data cells could be reformatted to indicate specific conditions. Another extension can be grouping all data in a tree-like format that allows users to easily find their way through data.
To recap on the framework’s phases, it starts with the Baseline to which new content is added. The resulted data is intersected against Authorization and salted with enhanced UX.
This process is executed every time the framework is invoked or refreshed. Meaning, changes in the baseline data will be reflected in the newly-created report.
What’s next
Building the framework using micro-services will make it flexible allowing easy enhancements to handle even more use cases.
For instance, we can give away the downloads-to-Excel altogether as this framework could be – with time – enhanced to support all the needed features that exist in Excel: Free cell coloring, pivot tables, and graphs to list a few.
In addition, this framework is absolutely not limited to SAP standard reports as the baseline. The framework could be easily enhanced to support Z-reports, ABAP queries and even plain DB tables (or CDS): Just like that, set a DB table as a baseline, get its structure & content, set authorization and present it – everything could be done in production and No ABAP skills are needed.
By the same token, the framework is – by all means – not limited to SAPGUI as its sole UI. The content could be easily and generically displayed in other UIs such as UI5.
Epilogue
It’s like eating the cake and leaving it whole. A free meal by which we keep getting all the good of the standard SAP reports and still can enhance it to suit our needs – Spending expensive resources only on the Extras – the things we are missing from the standard (baseline).
Thus, in many aspects, this disruptive technology may change the way people interact with SAP.
I will leave you with Oscar Wild who once said that “Conversation about the weather is the last refuge of the unimaginative”.