As part of various SAP support/development engagements, consultants frequently find themselves taking up the task of effort estimation. These estimates usually constitute activities viz. Requirement gathering, Solution Design, Configuration, ABAP development, Functional Validation, Regression Testing and all other actions leading to a successful User-Acceptance-Testing (UAT). The objective of this blog is to help the readers in understanding this business-critical function by throwing some detail on the perspectives of 3 key stake-holders viz. Client, Developer and Consultant.




Similar to any business proposition, client stands as the principal stakeholder and end-beneficiary of the Requirement-Under-Development. Also, through continuous ERP add-ons/developments, it is the client who brings revenue to the associated consulting organization. So, consultants, while doing effort-estimates, should always keep the below things in mind:

1.       1. The proposal has become a reality only since the client is seeking a better-way of handling his business processes and is eyeing to achieve the same through an efficient SAP-driven solution.

2.       2. Businesses don’t look at solutions with a skewed-sense of short-term savings. Effectively, clients are always willing to pay an extra dollar for a well-designed holistic ERP offering.

3.       3. Most of the requirements may have to deal with revamping existing business processes or implementing a new legal regulation or may even involve extending the existing business template to expanding global operations with unique country-specific challenges. Since time is a crucial component in such situations with every additional day of delay costing the business dearly, consultants have to be meticulous in their effort-planning. The objective here should be ‘Get-it-Right-FirstTime’.

4.       4. As we often experience, Rework is an exorbitant cost we end up paying when we try to deliver an incomplete solution resulting through not-so-thoroughly-assessed estimates. This Rework is not only a pricy affair but also delays the entire delivery cycle with enormous adverse business impact.

5.       5. Further, repeated failures in delivering Complete and Defect-free solutions with-in agreed timelines will lead to an erosion of client’s trust on consulting organization’s capabilities. This is a grave situation for any firm to get into since this negatively impacts its revenues as well as tarnishes the brand image in the long run.


Developer: (Usually an ABAP expert in SAP parlance)


As it is the developer who transforms the on-paper solution to an ERP reality by doing the necessary ABAP development, before arriving at an accurate estimate, he/she should ensure the below:


1.       1. A clear and complete understanding of the expected solution with a fairly-good picture of best and alternative scenarios to build the same

2.       2. A candid approach in making the consultant (functional) aware of the hidden-limitations that may be tied to the solution in future. Here, it is of utmost importance for the consultant and developer to be on the same page in their understanding and approach. This can be achieved only through continuous interaction and information-sharing at every stage of development. Here, the consultant has to ensure the developer aware of the changes happening on a daily-basis. (Through sharing minutes of discussions held with business). Based on the same, if required, the efforts should be revisited.

3.       3. Before starting any part of development, the technical consultant has to ask for a functional specification document which could be as basic as the solution-in-brief to be developed or may even incorporate acute details like database tables to be used, smart forms to be modified, programs to be amended etc. depending on the scale of requirement. This achieved clarity will surely reflect in making accurate and realistic estimates.

          Finally, any development approach should be simple and performance-effective in its design. Ultimately, if the convenience and ease-of-usage factors are missing, the solution itself will lose its relevance.




      A Functional Consultant acts a bridge between the client and developer. Basically, it is the job of a consultant to understand the business requirements and map them to a good-workable detail so that the development team can accomplish the required ABAP changes for successful implementation of the desired SAP solution.


      The following are vital factors to be looked-in by a consultant while doing the critical activity of estimating efforts:


1.       1. Ask relevant questions first: By not jumping into any assumptions and evaluating his understanding of the requirement at every stage of discussion, a consultant can ensure an accurate-mapping of client’s business need. In this stage, consultant should ask as many questions as possible by appropriately sharing his valuable insights/experience in handling similar requirements.

This way, the business also can develop a fair overview of what to expect and any valid, reasonable drawbacks can be appreciated before implementation itself.


2.       2. One-Team Approach: The consultant has to work in-tandem with the developer by constantly interacting with the latter and sharing all vital inputs on a regular basis. Before arriving at any rough estimate, they both should agree on the solution-approach to be adopted.

Here, the consultant and technical expert should work as one team with crucial individual roles being mutually acknowledged and respected.


      In essence, businesses look for solutions which are efficient (satisfies the business need and easy-to-use), high on quality (defect-free) and which can be easily scaled up to meet future requirements. Effectively, effort estimation, as an activity, should not be looked in a myopic lens to hastily deliver the thing-at-hand at any cost but has to be viewed in a broader perspective to implement solutions constituting little regressive impact, minimal or no rework and ultimately, offering lot-more than the business desires through optimum usage of efficient SAP functionalities. This can only be achieved, when we, as consultants, try to comprehend the engagement from a developer and more-importantly, through a client’s business perspective.

This document is based on the video session on SAP Overview from the Learning Hub, document walks you through the SAP evolution, enterprise resource planning and implementation of SAP applications and components based on the needs of the companies, clients.


Business Example

A company implementing the SAP applications and components should have the knowledge on the following,

  1. Elements of an enterprise resource planning (ERP) system,

  2. SAP applications and components,

  3. Industry applications,

  4. SAP Solutions for small and midsize companies.


  Integrated computer based systems used to manage internal as well as external resources including tangible financial materials.

Edge-over of ERP are

  1. The flow of information between the business within the boundary,

  2. Common computing platform, uniform and enterprise wide system environment,

  3. Distributed across modular hardware and software servers which can be communicated on Local Area Network (LAN),

  4. Distributed designs, easy adaptation which requires no need of multiple copies.

R/3 has undergone many release cycles since its inception. Release cycles has extended functions, optimized applications and enhanced components.

SAP ECC (ERP Central Component) acts as a 'CORE' developed from ABAP (Advanced Business Application Programming - ABAP - SAP's own programming language).SAP Evolution.png


Different sizes - different products

  SAP Products comes on in individual applications and components commonly referred as 'Suites'.

  Suites are focused, flexible and comprehensive connected through SAP NetWeaver Platform which reduce cost of ownership and supports evolution of suites. This manages the organizational growth and specific functionality requirements which elevate customer service and boost integrated systems.

     Different Products - Different Sizes.png


SAP Business Suite

  Comprehensive group of suites and business application includes open integrated applications and cross company process across multiple platforms such as customers, employers and connected communities within the business application.

Business Suite.png


SAP Business All-in-One

  Industry specific solutions from qualified SAP Partner solutions or solutions created within SAP.

  Packages includes Marketing, Sales, Finance and Control, Human resource, Purchasing, Planning, Inventory Mgmt, Production.

  Cost effective in the implementation process and specialized areas for critical facets of the business.

Business All-in-One.png


SAP Business ByDesign

  Suitable for mid-size companies which enables transaprency and new business requirements with minimal cost and minimum time. This supports built-in service and support.

     Built-in Business Analytics have the following modules

            Executive Management                                    Support Meet your company goals

            Financial Management                                     Optimize your financials

            Customer Relationship Management               Focus on your customers

            Human Resource Management                       Manage your workforce

            Supply Chain Management                             Integrate your supply chain

           Project Management                                        Drive Project success

           Supplier Relationship Management                 Empower smarter purchasing

            Compliance Management                                 Facilitate full compliance

With minimal time, effort and cost this manages the software for you and for the successful deployment with minimal cost of ownership.Business ByDesign.png



SAP Business One

  Single affordable business management solution suited for big companies which integrates their entire business across sales, financials, services, operations. This adapts itself to unique and fast growth changing and can be implemented within few days as well as maintained easily. Readily extensible, integrated data processing with user adaptability. In this Managers are allowed to access strategic information while small industries can have streamline operations obtain instant and complete information which induces productivity increase and accelerate profitable growth.

Business One.png


SAP Business object portfolio

  From a product perspective includes group of technologies and applications and management includes Enterprise Information Management, Business Intelligence, Enterprise Performance Management, Governance, Risk and Compliance. Combining this with SAP business process platforms allows for a closed loop business effectively and efficiently in the process change for optimization and execution can be monitored as well as business queries can be responded in real time business scenarios.

Business Object Portfolio.png


Industry Packages

  Industry specific applications which are target specific are bundled and enriched with industry process and specifications.


Industry Packages.png


Note : This document handles the basic knowledge on SAP Applications and Components.

Feedbacks are welcome .. Happy knowledge sharing ..



Vivek Raj Kumar M.

Daily Inventory operations includes receipt and issue of goods. For goods issue, companies usually use the reservation process. A department in need of a material will create a reservation with a particular movement type (typically 201 but some use customized as well). Referencing the reservation, the stores department issues the required material to the concerned department.


Businesses however, may not find the process completely adequate. Consider the following case, a user department requires a material of certain quantity. He will need to put up the requirement for approval with his immediate manager or to the head of the department. Once approved, he may proceed further with the reservation. This is similar to the way a Purchase Requisition (PR) is processed. A PR is created when there a requirement of a material of which stock is not available in inventory or a completely new material is required. The PR needs to go through an approval process which is mapped in SAP as Release procedure. Rarely, may be for materials belonging to C category, a release procedure is not required for PR approval.


Standard SAP does not provide release procedure for reservation. A customised dashboard can be created of a release process for reservation. The Reservation BADI will also be used to create a flag indicator which will enable to differentiate a released reservation from an unreleased one. The approval may be single or multiple depending on the client requirement.


A similar setup can be made in case of issue of goods in case the Stores department also follow the above work process. This will require the usage MIGO BADI. It may be argued that such complexity is not suitable for all businesses, and a fair amount of abap development will be required to achieve this, but a lot of companies do use this process. Some may not require the approval steps to be included in SAP and go with emails or other communication in tracking the approval and create reservation in SAP only once it gets a go ahead.

So you’re finally in production with your package software. Users are giving feedback, the system is stabilizing, and your program team is starting to wind down. Now what? Work on your solution never stops, and these key topics have to be addressed: Maintenance / Support and Upgrades / Patches. Now, when compared with custom-coded application, these topics require some different thinking. First, by leveraging a package solution, your software vendor takes on the burden of providing you with patches and upgrades for your base software. They often can play a role in helping tune your application as well. Finally, your software vendor will almost always have escalation paths for complex support issues as they arise.

You can break down your RUN state in the following way: Business Enhancements, Performance Tuning, Support Services, Software Updates, and ongoing Program Support.

Business Enhancements

By the second day (if not the first), you will start to receive requests for business enhancements for the solution that just went into production. These could range from minor tweaks to missed requirements. The work efforts can also range from a few hours to more than 30 days of development. As these requests come in, you will need to set up a RUN state team that can move ideas through the software development life cycle and get to production on a daily, weekly, monthly or quarterly basis. Most importantly, you need to plan for a period of continuous development to address key enhancement requests immediately after going live. Ideally, your organization is already operating in a model of continuous development.

“Packaged software does a great job keeping up with regulatory and security issues and usually pushes these code updates via Notes, Patches or Hot Fixes.”

Performance Tuning

No matter how much performance testing was performed during the build of the package solution, you will have unexpected results when you hit production. Being prepared to have engineers at the ready to tune the infrastructure, database, middleware, and UX layers of the application will be critical to a good experience for your end users. Don’t plan on just turning this responsibility over to your support teams, but rather retain this in your engineering organization: the engineers that built the solution are in the best position to advise on how to tune it. This function is also something you will need to turn to after every major release or upgrade.

Support Services

Support, in this context, is defined as Level 1 and Level 2 support for both end users and the application itself. This typically means that they focus on usability issues for users who may not be trained up on the system yet, as well as data, integration or performance errors. What support organizations should not be doing immediately after the system goes to production is try to troubleshoot problems (i.e. recurring incidents) or fix “Missed Requirements.” Support should be focused simply on break/fix and consistency of service. Level 3 teams (i.e. engineers that implemented the system) should be on point for problems or missed requirements.

“Don’t plan on just turning this responsibility over to your support teams, but rather retain this in your engineering organization: the engineers that built the solution are in the best position to advise on how to tune it.”

Ideally, Level 3 teams are embedded with the Support teams during the first 90 days post-production. This will help with knowledge transfer and incident resolution as well as quality. If the Level 3 teams are on the hook for support in the first 90 days, they will have motivation to ensure quality in development leading to a stable production implementation. Finally, before full transition from the development teams to Support, there should be pre-defined criteria that must be met for the system to be turned over. For example, zero high incidents for 4 weeks running or zero open high problems.

One point to note is that many software vendors have programs that will evaluate the quality of your implementation and flag areas of concern. You can leverage these programs to hold your organization and your implementation partners accountable for the quality of their implementation.

Software Updates

Patches, Hot fixes, Upgrades, and Notes are all things your software vendor will push out. Sometimes these are on a quarterly basis, but with the pace of technology change and security, these can be as frequent as weekly. Packaged software does a great job keeping up with regulatory and security issues and usually pushes these code updates via Notes, Patches or Hot Fixes. These tend to be relatively straightforward to implement and require minimal regression testing if any at all.

Upgrades can be more complex and typically are delivering major functionality changes. In most cases, you will need to plan for full regression testing, which usually means spinning up a full project to manage the upgrade. In particular you will have to pay attention to your integrations, reports, security, and any customizations you may have made during your implementation. Taking an end-to-end approach to an upgrade initiative will be imperative to success. This means starting with what changes the users will experience, and ensuring data / master data is not impacted by the upgrade.

In summary, Package Software can provide a lower cost, faster to market approach to enable many business capabilities. Package Software brings built-in innovation and continued development, security and regulatory controls, tested code beds leading to more consistent system performance, and increased data quality.

Final Installment

For most companies that choose package software, they have multiple vendors that assist them in implementation. The vendor ecosystem often ends up being the software vendor, a system integrator responsible for the bulk of the implementation, a RUN state vendor, and a smattering of niche vendors or staff augmentation providers. Our supplemental article on Vendor Management will dig into how to best leverage your vendors to get the most out of them.

The Case for Package Software
The Case for Package Software, Part II
The Case for Package Software, Part III

I was inspired by the "Tip: how to find out the correct component when raising OSS messages" blog post. As mentioned in that post, not choosing the correct component when raising an incident will probably cause the processing to be delayed.


In the same way, a lot of people mention a runtime error in the issue description, but there is no information on this runtime error. Which error is it? When did it happen? And this will also cause the processing to be delayed because in order to find this out, the incident will have to go back to the customer at least once just to clarify this simple piece of information.


Sometimes the runtime error title (or also known as short dump) is mentioned, but just this title does not help us too much. Sometimes the date when it happened is missing, which will make it difficult to find it in transaction ST22 in the system. Hey, sometimes the user provided for support to use has no authorization to access ST22. It can also happen that the runtime error is attached to the message, but in the form of a screenshot, usually only showing the top information of this runtime error, but not the complete details. This can also cause message processing to be delayed.


There is an easy way to export a runtime error, with all of the relevant information, making it easy to attach to your OSS incident or to e-mails if you want to share them with someone else in your team. Follow these steps:


1) Go into ST22 transaction to find the runtime error:



2) To see the runtime error details, double click a runtime error:



3) To export it, go to menu path System > List > Save > Local File:



4) A pop-up window will come up for you to choose in which format you'd like to save it. I'd recommend either the unconverted option which will save it in a .txt file or the HTML format:



5) Another pop-up window will come up for you to select a Directory where to save the exported file and also to give it a File Name:



6) Click on Generate and the file will be saved in the Directory you just defined:




That's it!


Just check the directory you selected to save the file in and it will be there.


The full runtime error (short dump) can now be easily shared! You can attach it to an OSS incident or any e-mails you might want to send your colleagues, you can save it on to a usb drive, ...

Before you even start considering package software, you need to have a good understanding of the business process you are trying to enable. More importantly, you need to know if this business process is the key differentiator that makes your company successful or is a supporting function like accounting. Package software for the most part excels at enabling these supporting functions. There are also many business processes that fall in between. They are more than just support functions, but not so highly specialized that they are truly differentiators. These often appear in supply chain, sales force automation, call center management, and product lifecycle management. Finally, there are industry specific processes. Many large package software companies like Oracle and SAP have industry vertical solutions that attempts to provide standard software for these processes.

In this first part we will dig into the following topics: Standard Processes, Speed-to-Market, Legacy Systems, On-premise Software, and Software as a Service.

Standard Processes
Package software is well suited to enable standard processes such as finance or human resources. As organizations start to consider package software, the first exercise they need to go through is a classification of their business processes. These business processes need to be broken into categories such as differentiating, competitive, and non-competitive. Enabling competitive and non-competitive processes with package software is a great place to start. Most differentiating processes will be too unique to easily enable them in package software solution. While there are many reasons to leverage package software for differentiating processes, that is a topic for another post.

Package software promises speed-to-market if you are able to accept its standard out of the box approach for your processes. This puts the onus of change on the business vs. the IT organization. For those package solutions that allow you to tweak their standard processes to better match yours through configuration, you can still enable your business process. However, there are several key areas that you must think through in order to move fast.

The first is data. Will you convert data or start your transactional history from scratch? Do you know where you master data lives and will you enable that in the new system or integrate with another system?

The second is integrations. How many upstream and downstream systems are required to integrate into the new solution? How flexible are those systems in changing their data structures to match the new package system? Will you need to create a translation layer to manage the data between the systems?

The third is performance. Do you have the internal infrastructure to manage the peak loads of the new system? Have infrastructure timelines been aligned to the overall implementation timelines? Do you know how the new system will scale?

These three components of data, integrations and performance are critical to understand in order to move fast. The good news is that many software vendors deal with these issues in every implementation and in some cases have built out methods to address these components. Unlike custom developed software, you have a starting point of where you need to begin in managing these risks to the ability to move fast.

Legacy Systems
We touched upon legacy systems a bit in the speed-to-market section above. So let’s dig a bit deeper on Data, Integration, Performance and Reporting.

Starting with Data, you will need to understand the quality of the data that exists in the legacy environment. If you are converting from a custom developed application or even an old package solution, you most likely have more flexible data rules than what the new system has. This will inevitably lead to challenges during data conversion to the new system. The payoff is structured data that will ensure data quality and consistency, easing future data consumption. Start data activities in parallel with the rest of the integration activities, otherwise you will find this track lagging and it will ultimately hold up your go-live.

Reporting should also be started in parallel with data and the whole program. Understanding what the new software package enables is important and educating the users to what is available out of the box is critical. What usually is not available from a software package is ad-hoc reporting. If this is a requirement, you will need to move data between the transaction system and your data warehouse solution. In addition, if analytical reports are required vs. standard historical reporting, this too may need to be built off of your data warehouse. Though many software vendors are migrating to in-memory systems that allow for very fast data analysis without having to migrate data between systems. These issues are similar to issues faced in custom solutions or packages due to the performance issues of doing data analysis against the transaction system.

Integration is another challenging effort to making software packages to work in a heterogeneous architecture environment. Embedding your integration team into your overall implementation team is a great way to ensure that integrations are completed on time. Cataloguing your integrations and determining if you can leverage a services architecture vs. a point-to-point integration may ease your overall development and simplify your architecture in general. The biggest challenges in developing integrations is incompatibilities in the data structure between the systems, performance of the interface, and access to knowledgeable subject matter experts on both systems. These integration challenges hold true regardless of custom or package software solutions.

Finally, performance of legacy systems and more importantly the interfaces are often over looked. For example, if there is expectation of real-time updates of data, but the source system from legacy operates on a nightly batch, there is no way to facilitate real-time data. Interface performance tends to be a more common challenge with legacy systems, where data flowing the interface is disrupted, leaving the new software package lacking the relevant data for the business to do its job. Fault tolerance in your interfaces is required to ensure a seamless experience by your users. Finally, the package itself needs to be performance tested. The software vendor will have great statistical data proving performance, but you must plan to validate its performance in your own environment.

On-Premise Software vs. Software as a Service (SaaS)
Software as a Service has grown tremendously over the past decade. This includes traditional software vendors adding SaaS offerings to there product lists. The hard part is deciding if SaaS, Hosted, or On-premise software is the way to go. In evaluating these options the following themes emerge for all of them as points of consideration: Security, Performance, Customizations, and Support.

Let’s start with On-Premise Software. If your business is concerned about having secure data, hosting your solution within your data center or on dedicated hardware within your data center provider’s offering is a must. By hosting your solution you control who has access to the data, have control of your network and physical access and don’t risk security breaches during transit of data. Many SaaS providers don’t segregate your data from their other customer’s data, increasing the risk that your data could be exposed inappropriately.

On-premise software also puts you in control of performance. You are able to scale, as you need too. If you have integrations from your software package to legacy systems, keeping data movement within your network is often faster than moving it over the Internet to your SaaS provider.

If you require customizations, you are able to control and manage that due to having the source code on premise where you can access it as you please. SaaS providers gain their scale by not allowing customizations and typically prohibit customers from making any change to the core code, limiting the extensibility of the solution.

Finally, there is support. On-premise software supported by your company falls within your support SLA’s. SaaS providers may not align to your internal SLA’s and for upgrades and outages; they often don’t have to avoid business sensitive times due to their business models. For example a SaaS provider may have an eight hour SLA for a severity one issue, while your internal SLA for severity one issues is 4-hours.

SaaS solutions have many benefits around Speed-to-Market, Scalability, Costs, and Performance. Due to the limited ability to do any customizations or configurations SaaS is often very turnkey resulting in speed-to-market. Pricing models tend to be lower cost at the start due to the subscription model vs. license model of traditional software. This means you don’t have to invest in costly infrastructure or the time to order, install, or configure that hardware.

From a performance perspective, many SaaS providers invest heavily in their data centers beyond what most companies may invest in their own data centers, leading to higher availability. The issue is that when they do have an outage, you don’t have control over recovery.

When considering SaaS solutions focus on the following business functions as a place to start: travel and expense management, training, knowledge management, sales force automation and talent management.

Please add your own perspectives on your experiences with Package Software. In the next installment we will discuss the Secrets of Making Packages Work in more depth. Topics will include a deeper dive on integration, data conversion, user interfaces, customizations, skills, and system integrators.

Links to Part II and Part III

When creating OSS messages, a lot of people have no clue on which component to use. So they just choose a common component such as BC-ABA, FI-GL or just randomly choose one component. This will cause the message processing to be delayed. Here I would like to share how to find out the correct component.



In general SAP distinguishes components according to its products. If it is R/3 then the component is distinguished according to package/programs. Below are some examples. The rule is to find out the corresponding package.


1. If you have the program name.


Go to SE38-> find out the package of the program -> double click on the package name



2. If you have the transaction name


Goto transaction SE93 -> display the transaction -> double click on the package name



3. If you have the function module name.


     Goto transaction SE37 -> display the FM -> goto Attributes tab-> double click on the package name



4.  As shown in the above 3 examples, no matter it is Table(SE11), Business object (SWO1) , or BADI (SE18), try to find the attributes of the object and you will find package, then application component.


5. Service market place  


1). Regarding on how to open system connections (R/3, WTS, HTTP…) and issues regarding the connections.


Component: XX-SER-NET-HTL



2). Regarding S users on service market place.




authorization: XX-SER-SAPSMP-ACC



6. Others


If the product is not SAP R/3 and you have no idea which component should be used, just give a call to the hotlines listed in SAP note 560499 (Global Support Customer Interaction: Telephone/fax/e-mail) and they will help you to find out the proper component.

A long time ago I found a very useful tool to help you when you need to translate a term or word for other language. Obviously you are very afraid to use the google translator and write something completely different. I'm pretty sure that you don’t want to include something bad in a selection-screen hahaha… So, the SAP has a tool to help us: SAPTERM (tcode) or


SAP Term helps with translations and sometimes give to you the definition in other language as well… Furthermore, the terms comes divide in modules in case the meaning be different in each module.





Hope that




Hello All,


This blog will give an insight to a feature in SAP known as Documentary Batches. documentary batches to ensure that partial stocks of a material are traceable, without it being necessary to manage the stock of the material in batches. documentary batches defer from the concept of batch. below is a tabular comparison of batch management and documentary batches taken from


Functions for "Real" Batches

Used for Documentary Batches?

Batch master

Yes, but only to a limited extent. (Can be automatically created by the system on goods receipt.)

Where-used list


Batch determination


Batch status management

Yes, but no link to stock

Batch numbering

No. You can enter batch numbers manually in the dialog; automatic entry is only possible using the Business Add-In (BAdI) VBDOCUBATCH.

Batch stock

No. Stock only at storage location level - no stock at batch level.

Batches in other SAP products (for example, SAP APO)

No. No integration with other SAP products such as SAP APO, SAP CRM or SAP BW.

(A material that is subject to documentary batch management requirement in SAP R/3 or ERP is treated as a material that is not subject to batch management requirement in other SAP products.)

Derivation of batch data

Yes. (Derivation of batch data from documentary batches requires a batch master record.)

Batch Information Cockpit

No, or only in the worklist

Batch worklist


Class assignment



How to Configure Documentary Batches in SAP:

Activate Documentary Batch:

SPRO Path:  SPRO -> Logistics General -> Batch Management -> Documentary Batches -> Activate Documentary Batch



Define Entry Per Material Type:

SPRO Path:  SPRO -> Logistics General -> Batch Management -> Documentary Batches -> Define Entry Per Material Type

In this activity you define for each material type, whether and to what extent, you want to use documentary batches.



Define Entry for manual process:

SPRO Path:  SPRO -> Logistics General -> Batch Management -> Documentary Batches -> Define Entry for manual process steps

In this activity, you make the following settings:

  How documentary batches are handled in certain process steps

  In which functions documentary batches must be entered.

  How many documentary batches are expected (system proposal)

  Whether a quantity check is carried out when documentary batches are entered and whether a system message of type warning or error should be issued.





We’ve finally arrived at the last instalment of our SAPinsider 2013 video series! Over the last 2 months we’ve had the pleasure of getting contributions from Mico Yuk, Luke Marson, Babak Hosseinian, Martin Gillet and Joshua Fletcher.  Together I believe they have created an impressive body of content and provided us with a wide coverage of the event in Amsterdam for those who didn't have the chance or didn't want to go this year. 


As the SAPinsider event is getting ready for its second run over in Singapore, 3rd-5th September, I wanted to wrap Amsterdam up and get the ball ready for the guys at the next event.


This blog and the last part of the series will be going over my impressions from the three days I spent at the conference. It should give the viewer a generic idea of the picture SAP is trying to paint with their current product catalogue and reasons why you should consider attending future SAPinsider events and why you maybe shouldn’t.


Before loading SAPinsider up on praise I wanted to raise a few negatives from the event, which I hope they will take on as constructive feedback.


  1. As an exhibitor at the event I found it an issue that they had not allocated enough room in the schedule for quality networking. It’s clear that at the core of the SAPinsider conference there’s a focus on content excellence and the sessions build around each of the technology streams (HR, CRM, FI, BI and GRC in this case) were reflecting that. It excels in this and I was impressed by the presenters they had organised to attend the event. However, due to the tight schedule of the sessions there was rarely time enough to network and fully explore the potential for meeting SAP professionals, customers and partners. If they were to get a slightly more commercial edge and dedicate more time in the schedule for networking, I think it would have a positive effect and increase the interest from exhibitors and attendees. I managed to meet the guys I interviewed in the series on a mix of after conference hours and lucky breaks.
  2. Another slight negative was the sheer amount of technology they were trying to cover. Compressing HR, FI, CRM, BI and GRC into a three day event is a lot. Too much, in my opinion. I’ve had quite a few comments on this topic from people I met and spoke with in the aftermath of the conference and there were several overlapping sessions they missed out on, as they couldn’t be two places at once. Many of the attendees are not only interested in getting information on one domain of the SAP portfolio but rather gain a wider knowledge of several. If this could be accommodated for future events, it would be excellent.


Now without further ado, let’s now move on to the video and wrap this up:



I hope everyone enjoyed the series and will come back for more when we get our next project on its legs and uploaded. If you got any comments for me on this or the earlier submissions in the series you are very welcome to post it and I’ll get back to you right away.


Part 1 of the series:Mico Yuk BI2013 - SAPinsider Video series part 1 of 6

Part 2 of the series: Luke Marson HR2013 - SAPinsider Video series part 2 of 6

Part 3 of the series: Babak Husseinian GRC2013 - SAPinsider Video series part 3 of 6

Part 4 of the series: Martin Gillet HR2013 - SAPinsider Video series part 4 of 6

Part 5 of the series: Joshua Fletcher BI2013 - SAPinsider Video series part 5 of 6



Before taking my leave, I would once again recommend all of you to go back and enjoy the other 5 parts of the series. Excellent content and sharp insight! Thanks to Mico, Luke, Martin, Babak and Josh for managing their crazy schedules to meet up with me. See you all soon I’m sure!

Vishal Mehta

Taming the Monster

Posted by Vishal Mehta Aug 5, 2013

Utilization of SAP discussed.

This article examines some of the major challenges faced by industries running on SAP in leveraging their staff and existing investment in an era of constrained budgets and expanded demands. The feature is predominantly written from the perspective of the C level executive with some reference to the technical, distinguishing points of our solution. Although our partner has developed very innovative and cutting-edge technology that SAP users will enjoy, our solution readily delivers four key economic advantages:


  • Reuse of current investment,
  • Simplification of increasingly complex business processes,
  • Increase in productivity, and
  • Lower maintenance costs.


We describe some of the challenges created by the current trends in ERP implementation specific to SAP, and the potential solution.


Executive Summary


CIO’s face the challenge of adapting to an increasingly complex software world with yesterday’s tool sets. The Internet, e-commerce, internal integration demands, supply chain re-engineering, and customer relationship management are all contributors to the growing demands on today’s developer. How do we deal with all this complexity and the difficulty in employing the necessary IT talent to successfully wade through this quagmire? Conceptually, the perfect system would be one in which we could reuse our software, describe software architecture so that a non-expert could successfully execute and simplify complex business modeling, and automate most user tasks.


GuiXT Software Suite allows corporations to adopt a ‘user-friendly’ and ‘intuitive’ SAP by introducing a modular scripting technology that dramatically increases productivity with its powerful automation and customization features. Web interactivity and external application interactivity with SAP is introduced; which takes business processes to an entirely new level. Repetitive processes with excessive data entry and navigation cease to be painful, and instead become automated templates that dramatically accelerate processes. All of the above is achieved without adding or modifying the underlying business logic (ABAP code) of SAP. Core component of GuiXT is included as a part of SAP GUI 4.6 installation and therefore is a part of every SAP client installation.


We estimate that with complete training and adoption of customized processes throughout an organization, a process that requires few days of product training and few weeks of consulting, the product can deliver total ROI gains for SAP’s past infrastructure investment of 50% plus.


GuiXT Software Suite layers into an organization’s existing SAP implementation to seamlessly bridge together disparate technologies available for enterprise implementation. Most organizations have made significant investments in existing SAP model to achieve the luxury of enjoying ‘user-friendly’ and ‘intuitive’ interface to simplify their processes; however, these investments have not produced the expected results, because they are either difficult to develop using or they achieve the results by altering the underlying business logic of SAP, which becomes difficult to maintain and cannot address future changes without heavy development costs and time. GuiXT shields the developer from ABAP and allows them to focus on writing business logic.


Current Challenges


With ever increasing changes, CIO’s of companies are acutely aware of the need to choose the right technologies that will enable them to remain agile and to respond rapidly to the changing demands of the marketplace. The pace is demanding with changing distribution patterns, globalization of commerce, and mergers and acquisition activity allowing little time for reflection.


Recently, the push has been for user interfaces to be simple, clear, and intuitive. Users want a system that is easy to learn and use, and is flexible. Challenges faced by CIO’s of SAP customers are, having:


  • User-friendly screens,
  • Error-free and tedium-free data entry,
  • Low training and maintenance costs,
  • Automated business processes, and
  • Integration with web and other applications.


We would be able to describe GuiXT of having multi-dimensional value, which would address and overcome the aforementioned challenges, both in less time and less cost.

Reuse of current investment


With the growth of the Internet and interdependent software systems, the need to leverage existing systems has grown enormously. Call of the hour is ‘reusable’ systems. Solutions that are reusable and scalable to prevent or minimize costly upgrades would be ideal.


GuiXT not only ensures reuse of current investment, but also spares future recurring investments, in terms of training and retraining SAP users. Ease of use; scalability; reliability; manageability; and flexibility are some of the highlights of GuiXT solutions.


The Solution


You can use GuiXT components to implement a whole range of screen customization options. With GuiXT Software Suite (GuiXT, InputAssistant, Designer, and Viewer), you can:


  • Combine and consolidate SAP screens to reduce the number of screens users have to wade through; in most cases up to a single screen,
  • Change the layout (i.e. refine terminology or delete/move screen elements) of any SAP screen to improve productivity and reduce errors in data entry,
  • Add relevant documentation by integrating web based help within SAP GUI itself, and reduce training costs,
  • Add automation driven by one-click process; hence simplifying the business processes.




Components Overview


  • GuiXT (Shipped with SAP GUI) – Allows you to change text and remove redundant data-entry fields in R/3 without touching core R/3 data. The runtime engine is bundled with SAP GUI.
  • InputAssistant – InputAssistant allows you to streamline business processes by combining stock R/3 screens and transactions into a customized, personalized, error-free data-entry screen.
  • Designer – Allows you to add or change R/3 text and remove redundant data-entry fields in R/3 by simple mouse ‘click-drag-drop’ operations, without touching core R/3 data. The result of the screen modifications are GuiXT scripts.
  • Viewer – Allows you to embed any HTML or RTF page inside any R/3 screen for Help or Internet lookup.




  • Ease of use – Screen customizations are done using Designer, a WYSIWYG tool that empowers users to click-drag-drop elements in an editable SAP GUI screen.
  • Scalability – GuiXT supports wide range of implementation sizes; from small businesses to large corporations. GuiXT supports R/3 installations 3.x and above.
  • Reliability – Since GuiXT is bundled within SAP, it eliminates the need of any additional development activity within SAP.
  • Manageability – Personalization and customization are script-driven. GuiXT scripts (simple ASCII text files) can be stored and managed within R/3 database.
  • Flexibility – Once GuiXT is activated, all SAP transactions become candidates for simplification and personalization. All it takes is additional GuiXT scripts.



  • For Users:
    • Intuitive R/3; Easy to understand and use
    • Process automation; Minimal errors
    • Tedium-free; Smart and quick data-entry
    • Huge time savings; Allows them to focus on their actual tasks
  • For Management:
    • Proven and scalable (bundled by SAP AG)
    • Data consistency and integrity
    • No ABAP necessary; Ensures swift implementation
    • Transparent deployment
    • Low cost; Less training for users
    • Error-free, streamlined processes; Increased productivity


Access to all information, documentation, tutorials, downloads and examples at Synactive site:

Vishal Mehta

Staying Live With SAP

Posted by Vishal Mehta Jul 19, 2013

You cast off all legacy systems and installed SAP; SAP ties it all together – but it costs. And did you achieve answers to your problems? Or are you contemplating to look for an alternative, because the migration introduced new problems?


ERP-centric companies are missing out on the full potential of a solution as rich as SAP, because they are failing to appreciate the implications – and continuing to make the mistakes of traditional systems development and integration. SAP implementation projects are suffering from ‘undue focus’ on technology, lack of user interface, lack of attention to human and organizational needs, lack of evaluation, and very little integrated working – internally between systems.


Measuring RoI is an essential prerequisite of any IT investment today. But the big problem is that it is far from quantifiable. And if the investment is as huge as an SAP implementation, the aforementioned problem becomes magnified. Spending on IT is no longer identified as an expense, but as an investment. And RoI is based on cash flow analysis. It is also true that management, and not technology, will ensure success or failure. Integration of business objectives with IT solutions succeeds only when management if committed to ensure a smooth transition of change management. “Leveraging staff and current investment” is the biggest faced challenge.


Most commonly posed questions:

  • Can we reuse current investment?
  • Can we simplify increasingly complex business processes?
  • Can we increase productivity?
  • Can we lower maintenance costs?


Until the early nineties, the relationship between an organization’s investment in IT and its impact on the performance and productivity was never seriously measured. Perhaps, the most critical reason was one’s inability to segregate the benefits based on ‘Deployment of IT’ vis-à-vis ‘Deployment of robust processes.’ Only if an organization has the latter approach to an SAP implementation, will it see the value and reap the benefits in the longer run. In accordance with the above approach, it must be added that SAP demands a fundamental change in the processes followed by business and the people who work those processes.


Change, being painful by nature, discourages many to take the second approach. However, if you install SAP as software without changing the ways people do their jobs, you may not see any value at all – and the new software (SAP) could slow you down by simply replacing the old legacy software that everyone was used to. On the other hand, if you are able to use SAP to improve ways your people take orders, manufacture goods, fill timesheets, for example, you will see value from it.


SAP, in spite of being one of the largest and most successful vendors of enterprise resource planning (ERP), ironically is a misnomer. For one, it DOES NOT help your planning. Resource – and the ownership of that resource in any business – is a hazy term. What is right about it is the enterprise part. It successfully integrates all departments and functions across a company onto a single computer system that serves the particular needs of different departments. Organizations opting for SAP as their ‘back-office software’ have one or more of the following reasons – to integrate financial information; integrate customer order information; standardize and speed up core business processes – manufacturing, financial services – but whatever be the case; reduce inventory, non-performing assets – as the case may be; and standardize HR information.


Business benefits aside, SAP as an ERP delivers well on three necessary objectives – consistency and reliability of data across the organization; streamlined transaction processing; and operations-level reporting.


Which is a better approach – Going for an ERP vendor like SAP or going for specialized point products? Opinions vary, based on a survey of several successes and failures in either case. Important is to base your evaluation on your business case, the strength of transaction processing backbone, and the desired room for sophistication. At times, an ERP like SAP is not able to handle a function vital for the company. In such cases, a specialized third-party product can be interfaced to deliver the result. For example, Mohan Breweries and Distilleries Ltd implemented SAP R/3; they found that they needed far superior functionality in the insurance area. They opted for IVL’s iNSUR/3, a comprehensive add-on package with SAP R/3 ERP solution that addresses the needs of enterprises in the areas of insurance and claims management. The company was able to authenticate information on numerous critical data of the insurance processes and cut down nearly 50% of excess manpower costs. It could increase the efficiency of the supply chain by integrating the routine insurance related activities into SAP R/3 Business Framework.


SAP is generic enough to cater to 24+ industries. As much as this being a strong point in favor, it introduces a major limitation – Usability! And this compromise cannot be escaped from, internally. The reason is commonsensical – in making itself applicable to diversified industries, diversified processes, SAP was forced to provide innumerable data elements packaged logically in discrete screens and transactions; terminology used on-screen is also generic in nature for the same reason. Following table captures the common ‘effects’ faced by most customers, and the ‘causes’ leading to those symptoms.



  • Tedious and error-prone data entry
  • Users spending more time on SAP than their primary tasks
  • Steep learning curve
  • High costs in training and re-training



  • UI peppered with inconsequential data elements
  • SAP by nature is more transaction-driven than process-driven
  • Complex and excessive navigation to perform a task
  • Imprecise and confusing terminology for your industry


Whatever industry you are in, “it’s all about productivity!” Productivity suffers if end-users are not comfortable with ‘what they see’ on screen and ‘how they interact’ with the screen. SAP evolution from R/2 to R/3 to Frogdesign look (EnjoySAP) has made a conscious effort to bring home better usability. However the spectrum traversed on this front is and is going to be limited because of the earlier mentioned fact – the generic nature.


Better usability can be achieved by internal and/or external customization and consolidation. For example, ABAP, the architectural language of SAP, can be used to re-configure, modify UI screens based on specific business process needs. Similarly, an external program (third-party) may be used to integrate with SAP in order to better the user experience. Or a combination of both! Important factors helping evaluate the approach are captured in the following points.


The solution:



  • change the underlying business logic of SAP
  • incur extra overhead in terms of heavy maintenance and upgrade costs
  • reduce system performance
  • affect data integrity



  • increase productivity and efficiency
  • minimize or eliminate training and maintenance costs
  • allow users to focus on their primary tasks
  • provide flexibility in terms of deployment and configuration


For example, Rexam Beverage Can Americas implemented SAP R/3 to use its PM (Plant Maintenance) module for mapping their processes, for example – creating a maintenance work order; releasing the work order; and printing the work order – all of which they wanted to happen within 30 seconds. The Plant Manager of Rexam, New Jersey, Mr. Steve Foster and his team of professionals, during SAP training, found the interface neither simple enough nor fast enough to enable what they had in mind. “We had this idea of creating a maintenance system that looked like an ATM (automated teller machine),” says Foster. “No one’s ever been trained on how to run an ATM, yet everyone can use one. Why should it be any more difficult to create a work order in SAP?”


Foster and team found what they needed in a then little known product called GuiXT (software bundled within SAP R/3), developed by Synactive GmbH. With the help of a Synactive consultant, a Rexam programmer was able to use GuiXT to create an SAP PM interface that does, in fact, resemble an ATM in its simplicity. The basic menu screen contains just 10, touch-screen, function push buttons, each of which triggers a series of standard SAP functions that run in the background, but are transparent to the user. In some cases, a single button launches SAP transactions that would have otherwise required the user to navigate 12 to 15 separate screens using standard SAP interface, Foster says.




The result, according to Foster, is that Rexam training requirements for the SAP PM system were cut from an estimated 40 hours per machine operator – which would have been required using a standard SAP interface – to 4 hours with the simplified GuiXT enabled SAP interface. Multiplied times the 1,500 plant operators who would be using the system, that’s a savings of 54,000 hours. “We more than recovered the cost of GuiXT license in the training savings alone,” Foster observes. Moreover, the simplicity of GuiXT interface enabled Rexam to largely meet the 30-second goal for its users. “I’d say we’re hitting that 30-second goal about 80% of the time, and for the other 20%, it’s less than 45 seconds,” Foster notes.


Conceptually, from a CIO’s perspective, the perfect system would be one in which one could reuse invested software, describe software architecture so that a non-expert could successfully execute and simplify complex business modeling, and automate user tasks – all of the above with no or least maintenance.

Can you find or build one? Are you willing to Change?

Functional consultant comes across many business requirements where they need to design/consult business scenario where interaction of ECC is required from another system. I will describe a very simple business requirement related to this and how can functional consultant get it expedited with the help of technical team. In the future blogs, I will describe how to expedite the other simple business requirements of ERP interface with the other systems.



Portal Screens contain fields which have values maintained in a drop-down, so that the end user can select values from it.


For these fields, they need to connect to the ECC system, where the values for each field are stored in customizing tables/maintenance views/value range in domains.


An interface is required to enable users in the portal to get the valid values of various fields from ECC.


This interface is supposed to read values from ECC and present the values to the users on the portal.

In portal, these fields are not available for the free text user input and can be filled only with values from drop downs coming from SAP ECC.



Since the requirement is to get the values from ECC, for various fields belonging to different tables/views/domains, the need is to design a dynamic approach, where-in the user can fetch values for any field belonging to any table/view/domain, without having to worry for the scope of search help functionality.


We requested the technical team to build the code dynamically, with no single static value. This enables the end user to search for any field irrespective of any search location. Also there is a provision to restrict/filter values based on certain conditions.




The interface takes the RFC approach for communication between the PORTAL and SAP ECC systems. The interface is synchronous and thus follows the request-response mode.

PORTAL places a request to ECC by providing the field name, table/view/domain name and the filter conditions. The ECC fetches values from the respective location and sends back the response to PORTAL with the relevant field values.


In lay-man terms following is the design


It is commonly understood among all the SAP MM Functional consultants that any field in SAP associated with a F4 value, has its value stored in the following three locations :


  • TABLE [Values maintained in check tables]- Example, all the possible values of “Plant” can be searched in the table T001W
  • VIEW [Values maintained in maintenance views]-For example all the possible values of “Product Hierarchy” can be searched from the view “V_T179”
  • DOMAIN [Values maintained in the ValueRange of a Domain]- For example all the possible values of “Procurement type” can be searched from the domain “DD07T”


So our interface should support the above explained types of searches for the various fields.






Signature is very important in interfaces. In a lay-man terms, a signature is a discipline of interaction between two systems. Signature specifies the import & export fields between the two interface systems. Here our systems are portal & SAP ERP.



    • Provide the nature of search the interface needs to perform
    • Possible Values are TABLE , VIEW , DOMAIN
    • Provide the table/view/domain name of search
    • Example: for Warehouse Number provide T300T.
  • FILTER [ A table of field names & conditions]
    • FIELD_NAME : The name of the field for which search help is to be performed
    • FIELD_CONDITION: A Filter to restrict the values to be retrieved.




For Sales Org, our input will look the following.




FIELD_NAME_VALUES: A table of entries containing the results grouped according to the fields given in the input.

FIELD_NAME_AND_VALUES: A table of 3 fields [Warehouse No, Descr. , Language]



Assume 52 entries have been maintained in SAP ECC for Warehouse with English description.


  • FIELD_NAME_VALUES [52 entries]
  • [1st entry]FIELD_NAME_AND_VALUES [3 entries]
  • [2nd entry]FIELD_NAME_AND_VALUES [3entries]

SO ON………


  • [52nd entry]FIELD_NAME_AND_VALUES [3entries]


An example of the support document is attached which can be provided to technical team with functional specifications.





Since the technical approach taken is dynamic, it is thus not limited to a specific project. It can be re-used across different SAP projects which need to carry out search help across SAP systems in the RFC mode.

Just by establishing the RFC connection across 2 SAP systems, this function module can be utilized to realize the search help functionality.

Hence RE-USABILITY is the object’s prime distinguishing attribute.


The algorithm can be further extended easily to support more search types. There is no need to disturb the signature of the interface. Just adding a small piece of code to support the additional search types would suffice. So the extension of the object is pretty simple and straight-forward.

Any ERP implementation is very different than other software implementations. ERP cuts across variety of functions within organization and involves change in terms of ways of working and processes. Companies invest a lot of money,energy and time to implement ERP but at times the journey is not as straight and smooth as expected .



In this blog, I will discuss few of the key things which organization and it's consulting partner should keep in mind during a ERP implementation.


  • C- suite executive buy-in and bringing everyone onboard- ERP implementation involves a lot organizational change for which people may not be ready due to psychological or other reasons. Due to this, implementation partner and customer core team faces a lot of resistance and makes the implementation much more challenging.  Implementation needs top executive direction and guidance to ensure the needed change is been adopted and accepted across board.


    Company's all employees needed to be brought on-board with the concept of ERP and benefits it will bring in their day to day work. Once everyone understand the way ERP is going to help and enrich their day to day work, the further implementation journey becomes easier and successful. 



  • One step at a time: Baseline implementation followed by bespoke exotic processes - ERP implementation involves too many organizational changes , and adopting best practices. I feel it is more pragmatic approach to start with implementing the baseline solution and then plan for bespoke processes applicable for any particular category or country with in business.



  • Capture the right data point  - The axiom I learnt in my school days computer class- 'Garbage in results garbage out' and ERP systems are no exception to this rule.  Implementation team  should take special attention on capturing and migrating the master and transaction data from legacy systems to new ERP systems. Data is the heart of ERP system and without correct data the best implemented business process in ERP systems would fail to deliver.



  • Training end users - End users training plays a very vital role in ERP implementation projects. Training programs should be designed by keeping in mind the non-technological workforce which will use the system to perform day to day tasks/transactions. Unless  users are not comfortable using the system, they will  try to find ways to perform the same task outside the system with manual processes. This can cause severe issues with system figures/status not matching with actual condition.



Filter Blog

By author:
By date:
By tag: