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.

Transporting table entries from one server to another

Scenario:  In this scenario, we would try to transport the table entries of table SCARR.

 

Go to transaction SE10. Click on Create.  

 

Following pop-up appears. Select Workbench request. (If the table is customizing table, then select customizing request)

 

Provide a short description to the request.

 

The request is displayed as shown below

 

Now double-click on the request, 

 

Go to change mode, and enter the following details:

 

Now click on the key button available under the name “Function” (As shown in the screenshot above). Following screen appears. Double-click on the first empty line. 

 

Here we can provide the entries that we would need to transport. For our demo purpose, we are transporting all the entries in SCARR belonging to client 800. 

 

Press Enter. Screen would look as follows:

 

Now you can check for the entries that would be transported as per the given condition, by clicking on the table button highlighted in the screenshot above. 

Select the third radio button “Table contents specified by current key”. 

 

Following entries would appear:

 

Click on Save. A warning message would appear. 

 

SAP issues a warning message when an application table is used. Following is the SAP help that would appear when we click on the message:

Ignore the warning message and click on Save. The request would appear as follows: 

 

Now transport this request to transport the data to any other system.

Business Benefits of SAP ERP

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 adaptability.
  • 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.

Sample Functional Specification Template

USER INTERFACE DESIGN SPECIFICATION
: Version 1.0 June 15, 2006 UI Contacts: Jane Smith (jsmith@somecompany.com) John Jones (jjones@ somecompany.com)

1     Table of Contents

1      Table of Contents. 2

2      Introduction. 3

3      . 4

3.1        . 4

3.2        . 4

4      Revision History. 5

2     Introduction

[Things you can discuss in the introduction:

·         The scope of this spec

·         Terminology / basic vocabulary

·         High-level flow

·         Areas that are covered in other specs / documents

·         Reference to a Common UI spec, patterns library, etc

·         References to other support documents such as research reports, prototypes, etc ]

3    

3.1   

[Things to consider including here:

·         Brief description of area

·         Definitions

·         Block flow for task area

·         Design rationale, etc ]

3.2   

[Notes specific to this screen]

Screen sample(s)	ID	Item	Description
Source: WireframeFileName.ai	A	[name of field, control, or input event]	[For field, describe contents, including text format, alignment, and any rules governing conditional text. For a control, describe its response to various input events, when it is enabled/disabled, options available, placement within the screen, etc. For input events, describe the response. The response may be a state change for this screen, navigation to a new context, etc. Include discussion of animations, error conditions, etc.]	[date of change]
	B
	C
	D
	E
	F
	G
	H
	I

3.3   

3.4   

…

4    

4.1   

4.2   

4.3   

…

5     Revision History

Version	Date	Author	Change	Bug(s)
1.0	June 15, 2006	Jane Smith	[List of items which were added, modified, or deleted.] [May include rationale for why change was made.]	[IDs of bug(s) associated with each change]

6     Open Issues

Version	Date	Author	Issues	Bug(s)
1.0	June 15, 2006	Jane Smith	[List of open issues] [Update to include resolutions once issues are closed]	[IDs of bug(s) associated with each issue]

Difference 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

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'.

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.