Tracking the Transaction Code for the IMG activities

Tracking the Transaction Code for the IMG activities

Go to SPRO -> SAP Reference IMG
Now click on “Additional Information” à Additional information à Display Key à IMG Activity

You would see the activity names on every transaction in IMG now (as shown below)

Note the corresponding activity.
Now to transaction SE16 and enter the name CUS_IMGACH
Enter the activity name as shown below:

Execute and you would get the transaction code

GAP Analysis

GAP Analysis

Gap means small cracks. In SAP world or in Information Technology world, gap analysis is the study of the differences between two different information systems or applications( ex; existing system or legacy system with Client and new is SAP), often for the purpose of determining how to get from one state to a new state. A gap is sometimes spoken of as "the space between where we are and where we want to be."

Gap Analysis is undertaken as a means of bridging that space. Actual Gap Analysis is time consuming and it plays vital role in Business Blueprint [AS IS Process] stage.A through Gap Analysis will identify the gaps between how the business operates and its needs against what the package can can't do.
For each gap there will be one of three outcomes which must be recorded and actioned,

1. GAP must be closed and customized software can be developed
2. GAP must be closed but software cannot be written therefore a workaround is required
3. GAP does not need to be closed.

A point worth mentioning here is that at time people confuse between user-exits and Gap Analysis. User exits are standard gate ways provided by SAP to exit the standard code and we can write our own code with the help of ABAP workbench, its not new functionality which we are trying to build in sap but its slight enhancement within the same code.

Gap analysis is start point of Realization and once business Blueprint is finished we have to find the realization of sap system for client requirement and there will be certain gaps when compared to system fit. Those gaps can be closed either by re-engineering of business process to fit with SAP or we have to use USER exits in case of small deviations or complete enhancements with the help of ABAP to fit with the SAP system.

The Gaps can differ from company to company. Most commonly, however, missing functionality is industry-specific.

Examples:

1. MGM Studios and Lycos sometime back worked with SAP to develop its new intellectual property management and media advertising management functionality, respectively.

2. A leading Oral care product company wanted the promotion of free-goods where they wanted 'Buy one get 2 different products free'.

Unit of Measure - Rounding of decimal places

Unit of Measure - Rounding of decimal places

Before we proceed to configuration settings, we first check the default behavior of decimal places for a unit of measure.
Let us try creating a Purchase Requisition.
We have entered the following entry for buying Coffee of 52.5KG.

Press Enter and enter the other necessary information like valuation price, G/L account, cost center and others. Come back to the above screen.
Now the screen would look like:

You could notice that three decimal points are shown.
Now let’s create one more entry, without any decimal points.

You could notice that no decimal points are shown in the case of second line item.
Now, let us look at the configuration settings for the Unit of Measure (UoM).
Go to transaction CUNI.

Now select “Mass” as the dimension.

Click on “Units of measurement”. Following screen appears:

Now double-click on KG.

In the above screen, you can notice that “Decimal pl. rounding” is set as 3. Due to this, the quantity in our Purchase Requisition has automatically set to 3. If the decimal places entered by the user are more than this, then it would be rounded to 3 decimal places. Also, you can notice that the “Decimal places” is set to blank. If this is set, then the quantity would be displayed with that number of decimal places. For example, if you enter the quantity as 50, system would display as 50.00.

Differences between Implementation, Support, Upgrade and Roll out projects

Differences between Implementation, Support, Upgrade and Roll out projects

Implementation

Customer wants to install SAP/Include different modules of SAP viz. MM/SD/FI/CO/PP etc. This is implementation project. Here one needs to integrate several modules, migrate data from Legacy system to SAP system. Need to prepare interfaces/RFC's to interact with 3rd party systems.

Support

Customer has already installed SAP & wants to give the work of maintaining those systems. This is support project

Upgrade

Customer has SAP Version 4.6b and wants to update his version i.e. wants to go to Version 4.7. This is upgrade project

Rollouts

Customer has upgraded his version & wants to rollout country specific changes.This is rollout project

SAP ERP - Business Benefits

SAP ERP

Business Benefits

SAP ERP delivers a comprehensive set of integrated, cross-functional business processes. With SAP ERP, you can gain the following benefits:

Improve alignment of strategies and operations:

Run your enterprise in accordance with strategy and plans, accessing the right information in real time to identify concerns early. Pursue opportunities proactively. Achieve corporate objectives by aligning workforce and organizational objectives. Find the best people and leverage their talent in the right job at the right time.

Improve productivity and insight

Leverage self-services and analytics across your organization. Improve operational efficiency and productivity within and beyond your enterprise.

Reduce costs through increased flexibility

Use enterprise services architecture to improve process standardization, efficiency, and daptability. Extend transactions, information, and collaboration functions to a broad business community.

Support changing industry requirements

Take advantage of the SAP NetWeaver platform's latest open, Web-based technology to integrate your end-to-end processes seamlessly.

Reduce risk

Solve complex business challenges today with SAP, your trusted partner for long-term growth, with 30 years of experience working with organizations of all sizes in more countries than any other vendor. Join SAP's world-class partner network, uniquely qualified to support the best business practices in more than 25 industries.

Improve financial management and corporate governance

Gain deep visibility into your organization with financial and management accounting functionality combined with business analytics. Increase profitability, improve financial control, and manage risk.

Optimize IT spending

Integrate and optimize business processes. Eliminate high integration costs and the need to purchase third-party software. Deploy other SAP Business Suite applications incrementally to improve cash flow and reduce costly borrowing.

Gain higher ROI faster

Install SAP ERP using rapid-implementation techniques that cost less than half what traditional approaches cost. Leverage preset defaults and prepackaged versions available for specific industries.

Retain top performers

Retain your top performers through clearly defined career and development plans. Link employees' performance to compensation programs such as variable pay plans and long-term incentives.

Provide immediate access to enterprise information

Give employees new ways to access the enterprise information required for their daily activities.

What are Functional Specifications?

Functional specifications (functional specs), in the end, are the blueprint for how you want a particular report and transaction to look and work. It details what the report will do, how a user will interact with it, and what it will look like. By creating a blueprint of the report or transaction first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect.A key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has, ideally, all of their questions answered about the report or transaction and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed.

Functional Specification:

A functional specification (or sometimes functional specifications) is a formal document used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users. The functional specification is a kind of guideline and continuing reference point as the developers write the programming code. (At least one major product development group used a "Write the manual first" approach. Before the product existed, they wrote the user's guide for a word processing system, then declared that the user's guide was the functional specification. The developers were challenged to create a product that matched what the user's guide described.) Typically, the functional specification for an application program with a series of interactive windows and dialogs with a user would show the visual appearance of the user interface and describe each of the possible user input actions and the program response actions. A functional specification may also contain formal descriptions of user tasks, dependencies on other products, and usability criteria. Many companies have a guide for developers that describes what topics any product's functional specification should contain.For a sense of where the functional specification fits into the development process, here are a typical series of steps in developing a software product:

Requirements:

This is a formal statement of what the product planners informed by their knowledge of the marketplace and specific input from existing or potential customers believe is needed for a new product or a new version of an existing product. Requirements are usually expressed in terms of narrative statements and in a relatively general way.Objectives: Objectives are written by product designers in response to the Requirements. They describe in a more specific way what the product will look like. Objectives may describe architectures, protocols, and standards to which the product will conform. Measurable objectives are those that set some criteria by which the end product can be judged. Measurability can be in terms of some index of customer satisfaction or in terms of capabilities and task times. Objectives must recognize time and resource constraints. The development schedule is often part or a corollary of the Objectives.Functional specification.: The functional specification (usually functional spec or just spec for short) is the formal response to the objectives. It describes all external user and programming interfaces that the product must support.Design change requests: Throughout the development process, as the need for change to the functional specification is recognized, a formal change is described in a design change request.

Logic Specification:

The structure of the programming (for example, major groups of code modules that support a similar function), individual code modules and their relationships, and the data parameters that they pass to each other may be described in a formal document called a logic specification. The logic specification describes internal interfaces and is for use only by the developers, testers, and, later, to some extent, the programmers that service the product and provide code fixes to the field.

User documentation:

In general, all of the preceding documents (except the logic specification) are used as source material for the technical manuals and online information (such as help pages) that are prepared for the product's users.Test plan: Most development groups have a formal test plan that describes test cases that will exercise the programming that is written. Testing is done at the module (or unit) level, at the component level, and at the system level in context with other products. This can be thought of as alpha testing. The plan may also allow for beta test. Some companies provide an early version of the product to a selected group of customers for testing in a "real world" situation.

The Final Product:

Ideally, the final product is a complete implementation of the functional specification and design change requests, some of which may result from formal testing and beta testing. The cycle is then repeated for the next version of the product, beginning with a new Requirements statement, which ideally uses feedback from customers about the current product to determine what customers need or want next.Most software makers adhere to a formal development process similar to the one described above. The hardware development process is similar but includes some additional considerations for the outsourcing of parts and verification of the manufacturing process itself.