Material Master

Master data contains information, stores in a database for longer period of time and it is used for different application.

Different types of Master Data in SAP MM are: -
1. Material Master
2. Vendor Master
3. Info Records
4. Source list
5. Quota Arrangement
Materials are the goods that are subject of business. The material can be traded, used in manufacture, consumed, or produced

It is a Master file which contains information of a particular material, depending upon the views selected from the user departments.

Material type
It is a key that assigns the material to a group of materials such as Raw materials, trading goods. This allows you to manage different materials in a uniform manner in accordance with your company's requirements.
The Material type defines certain attributes of the material and has important control functions.

When creating a material master record, the material type determines
• Whether the material number is assigned internally or externally
• From which number range interval the material number comes
• Which screens are displayed
• The order in which screens are displayed
• Which department-specific data is displayed for the user to enter

Different Material Types available: -

ROH - Raw Material
FERT - Finished Product
HALB- Semi finished Product
HAWA- Trading goods
DIEN - Services
ERSA - Spare Parts
PIPE - Pipeline material
LEIH - Returnable Packaging
HERS- Manufacturer Parts
FGTR - Drinks
FOOD- Foods
FRIP - Perishable Goods

Material Group: -T Code WG21

Key that you use to group together several materials or services with the same attributes, and to assign them to a particular material group.

Price Control: - Two types of Price Controlled given by SAP

1. Moving Price – ‘V’

2. Standard Price- ‘S’

Standard Price:

Valuation using a standard price has the following features:

• All inventory postings are carried out at the standard price.
• Variances are posted to price difference accounts
• Variances are updated
• Price changes can be monitored

If a material is assigned a standard price (S), the value of the material is always calculated at this price. If goods movements or invoice receipts contain a price that differs from the standard price, the differences are posted to a price difference account. The variance is not taken into account in valuation.

Moving Average Price:Valuation using a moving average price results in the following:

• Goods receipts are posted at the goods receipt value.
• The price in the material master is adjusted to the delivered price.
• Price differences occur only in exceptional circumstances.

If a material is assigned a moving average price (MAP), the price is automatically adjusted in the material master record when price variances occur. If goods movements or invoice receipts are posted using a price that differs from the moving average price, the differences are posted to the stock account; as a result, the moving average price and the value of the stock change

SAP MM Introduction

SAP MM Transaction Codes

Procurement Process

SAP Landscapes

Landscapes like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into 3 landscape DEV, QAS and PROD.

-  DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.
-  QAS may again have multiple clients for ex: 300- Integration Test, 700 to 710 Training.
-  PROD may have something like a 200 Production.

These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario. 

Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage). As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving every time. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example). 

You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients. 

But in the Testing client you can not even access SPRO  (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practiced in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory. 

The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.

Introduction to SAP

ETL ( Extraction Transformation and Loading)

ETL Stands for Extraction, Transformation and Loading, its a process that has Database usage. Especially in Data Warehousing. It was also used during the Data Migration but not in all the cases.

Extract

The first part of an ETL process involves extracting the data from the source systems.

Most data warehousing projects consolidate data from different source systems. Each separate system may also use a different data organization/format. Common data source formats are relational databases and flat files, but may include non-relational database structures such as Information Management System (IMS) or other data structures such as Virtual Storage Access Method (VSAM)or Indexed Sequential Access Method (ISAM), or even fetching from outside sources such as through web spidering or screen-scraping. The streaming of the extracted data source and load on-the-fly to the destination database is another way of performing ETL when no intermediate data storage is required. In general, the goal of the extraction phase is to convert the data into a single format which is appropriate for transformation processing.

An intrinsic part of the extraction involves the parsing of extracted data, resulting in a check if the data meets an expected pattern or structure. If not, the data may be rejected entirely or in part.

Transform

The transform stage applies a series of rules or functions to the extracted data from the source to derive the data for loading into the end target. Some data sources will require very little or even no manipulation of data. In other cases, one or more of the following transformation types may be required to meet the business and technical needs of the target database:

• Selecting only certain columns to load (or selecting null columns not to load). For example, if the source data has three columns (also called attributes), for example roll_no, age, and salary, then the extraction may take only roll_no and salary. Similarly, the extraction mechanism may ignore all those records where salary is not present (salary = null).
• Translating coded values (e.g., if the source system stores 1 for male and 2 for female, but the warehouse stores M for male and F for female), this calls for automated data cleansing no manual cleansing occurs during ETL
• Encoding free-form values (e.g., mapping "Male" to "1" and "Mr" to M)
• Deriving a new calculated value (e.g., sale_amount = qty * unit_price)
• Sorting
• Joining data from multiple sources (e.g., look up, merge)
• Aggregation (for example, roll up — summarizing multiple rows of data — total sales for each store, and for each region, etc.)
• Generating surrogate-key values
• Transposing or pivoting (turning multiple columns into multiple rows or vice versa)
• Splitting a column into multiple columns (e.g., putting a comma-separated list specified as a string in one column as individual values in different columns)
• Disaggregation of repeating columns into a separate detail table (e.g., moving a series of addresses in one record into single addresses in a set of records in a linked address table)
• Look up and validate the relevant data from tables or referential files for slowly changing dimensions.
• Applying any form of simple or complex data validation. If validation fails, it may result in a full, partial or no rejection of the data, and thus none, some or all the data is handed over to the next step, depending on the rule design and exception handling. Many of the above transformations may result in exceptions, for example, when a code translation parses an unknown code in the extracted data.

Load

The load phase loads the data into the end target, usually the data warehouse (DW). Depending on the requirements of the organization, this process varies widely. Some data warehouses may overwrite existing information with cumulative information, frequently updating extract data is done on daily, weekly or monthly basis. Other DW (or even other parts of the same DW) may add new data in a historic form, for example, hourly. To understand this, consider a DW that is required to maintain sales records of the last year. Then, the DW will overwrite any data that is older than a year with newer data. However, the entry of data for any one year window will be made in a historic manner. The timing and scope to replace or append are strategic design choices dependent on the time available and the business needs. More complex systems can maintain a history and audit trail of all changes to the data loaded in the DW.

As the load phase interacts with a database, the constraints defined in the database schema — as well as in triggers activated upon data load — apply (for example, uniqueness, referential integrity, mandatory fields), which also contribute to the overall data quality performance of the ETL process.

• For example, a financial institution might have information on a customer in several departments and each department might have that customer's information listed in a different way. The membership department might list the customer by name, whereas the accounting department might list the customer by number. ETL can bundle all this data and consolidate it into a uniform presentation, such as for storing in a database or data warehouse.

• Another way that companies use ETL is to move information to another application permanently. For instance, the new application might use another database vendor and most likely a very different database schema. ETL can be used to transform the data into a format suitable for the new application to use.

• An example of this would be an Expense and Cost Recovery System (ECRS) such as used by accountancy, consultancies and lawyers. The data usually ends up in the time and billing system, although some businesses may also utilize the raw data for employee productivity reports to Human Resources (personnel dept.) or equipment usage reports to Facilities Management.

SAP Procurement Process Flow.

Determination of Requirements

The user department responsible is manually passing a requirement for materials to the purchasing department via Purchase Requisition. Purchase requests are generated when business runs the MRP and Request are also generated based in Consumption based planning (CBP) for Production and Engg.Stores. 

Determination of Source of Supply

The purchasing component helps the buyer determine the sources of supply. User use the determination of the source of supply to create Requests for quotation (RFQs) and then to enter quotations. User is accessing the existing Purchase Orders and Conditions in the System. 

Vendor Selection and Comparison of Quotations

The System is capable of simulating pricing scenarios and simplifies the selection of vendors by making price comparisons between the various quotations. 

Purchase Order Processing

The purchasing system adopts information from purchase requisition and the quotation to help to create Purchase Orders. They are also creating manual purchase order directly for stock, non-stock items, services etc. 

Purchase Order Monitoring

The buyer monitor the processing status of the purchase order online at any time and determine whether goods or an invoice have been received for the relevant purchase order item. 

Goods Receipt and Inventory Management

The Goods receiving requester confirms the receipt of the materials by simply entering the Purchase Order Number. The system compares the goods receipt quantity with the purchase order quantity. By specifying permissible tolerances, buyers can limit over deliveries and under deliveries of ordered materials.

Data Warehousing Introduction

A data warehouse is a type of computer database that is responsible for collecting and storing the information of a particular organization. The goal of using a data warehouse is to have an efficient way of managing information and analyzing data.

Despite the fact that data warehouses can be designed in a number of different ways, they all share a number of important characteristics. Most data warehouses are subject oriented. This means that the information that is in the data warehouse is stored in a way that allows it to be connected to objects or events which occur in reality. 

Another characteristic that is frequently seen in data warehouses is called a time variant. A time variant will allow changes in the information to be monitored and recorded over time. The information that exists in data warehouses is non-volatile. This means that it cannot be deleted, and must be held to be analyzed in the future. All of the programs that are used by a particular institution will be stored in the data warehouse, and it will be integrated together. The first data warehouses were developed in the 1980s. As societies entered the information age, there was a large demand for efficient methods of storing information. 

Many of the systems that existed in the 1980s were not powerful enough to store and manage large amounts of data. There were a number of reasons for this. The systems that existed at the time took too long to report and process information. Many of these systems were not designed to analyze or report information. In addition to this, the computer programs that were necessary for reporting information were both costly and slow. To solve these problems, companies begin designing computer databases that placed an emphasis on managing and analyzing information. These were the first data warehouses, and they could obtain data from a variety of different sources, and some of these include personal computers and mainframes. 

Spreadsheet programs have also played an important role in the development of data warehouses. By the end of the 1990s, the technology had greatly advanced, and was much lower in cost. The technology has continued to evolve to meet the demands of those who are looking for more functions and speed. There are four advances in data warehouse technology that has allowed it to evolve. These advances are offline operational databases, real time data warehouses, offline data warehouses, and the integrated data warehouses. 

The offline operational database is a system in which the information within the database of an operational system is copied to a server that is offline. When this is done, the operational system will perform at a much higher level. As the name implies, a real time data warehouse system will be updated every time an event occurs. For example, if a customer orders a product, a real time data warehouse will automatically update the information in real time. The offline data warehouse is a database that is updated on a regular from an operational system. 

With the integrated data warehouse, transactions will be transferred back to the operational systems each day, and this will allow the data to easily be analyzed by companies and organizations. There are a number of devices that will be present in the typical data warehouse. Some of these devices are the source data layer, reporting layer, data warehouse layer, and transformation layer. There are a number different data sources for data warehouses. Some popular forms of data sources are Teradata, Oracle database, or Microsoft SQL Server. 

Another important concept that is related to data warehouses is called data transformation. As the name suggests, data transformation is a process in which information transferred from specific sources is cleaned and loaded into a repository.

Data transformation can either be a manual or automated process. Code can be manually generated, or an ETL tool can be utilized. The device that is responsible for transforming the data will compare it to other systems. It will also placed the data in a specific standard. In addition to this, it will often be linked to other systems which can assist it. The goal of using a data warehouse is to store and monitor information in a way that allows it to easily tbe analyzed. The data held in the warehouse will typically remain on file for a year.

Key Data Warehouse systems and the most widely used database engines for storing and serving data for the enterprise business intelligence and performance management.

• SAP BW - Business Information Warehouse (SAP Netweaver BI)
• Microsoft SQL Server
• Teradata
• Oracle
• IBM DB2 (Infosphere Warehouse)
• SAS

SAP BW - Introduction

In this Blog we will some thing about SAP BW. The area in which SAP HANA is expected to revolutionize the way the Business Intelligence will work. 

In the fiercely increasing competition amongst corporations it has become mandatory to make quick and sound crucial business decisions based on analysis of business critical data. This is the point where data warehouses come into play. Although many companies are relying on data warehouses, they are still struggling to achieve positive results due to fragmented and inconsistent data. For them SAP’s Business Information Warehouse (BW) provides a complete information factory solution. BW is the central component in the SAP suite of applications with an added advantage of being a software package that can be used in both SAP and non-SAP environments.

SAP Business Information Warehouse (SAP BW) is the name of the Business Intelligence, analytical, reporting and Data Warehousing (DW) solution which is one of the major enterprise software applications produced by SAP AG. It was originally named SAP BIW, (Business Information Warehouse), but is now known as "SAP NetWeaver BI".

For the modern enterprise, time wasted due to data loss and inconsistencies is unacceptable, particularly when this can often be remedied easily through the use of a data warehouse. SAP introduced Business Warehouse Information Systems (BW) in the first half of 1997. This system approach consolidates the external and the internal sources of data into a single repository and provides preconfigured data that aids the organizations and enterprises in dealing with the data management and archiving. The SAP environment therefore expanded its horizon with the introduction and implementation of SAP BW to encompass new applications for the SAP R/3 administrators responsible for administering and maintenance of these data reserves.

T-Codes of SAP MM

IH09 - Display Material 
MM01 - Create Material  
MM02 - Change Material  
MM03 - Display Material 
MM50 - List Extendable Materials 
MMBE - Stock Overview 
MMI1 - Create Operating Supplies 
MMN1 - Create Non-Stock Material  
MMS1 - Create Service 
MMU1 - Create Non-Valuated Material 
 
ME51N - Create Purchase Requisition 
ME52N - Change Purchase Requisition 
ME53N - Display Purchase Requisition 
ME5A - Purchase Requisitions: List Display 
ME5J - Purchase Requisitions for Project 
ME5K - Requisitions by Account Assignment 
MELB - Purch. Transactions by Tracking No. 
 
ME56 - Assign Source to Purch. Requisition 
ME57 - Assign and Process Requisitions 
ME58 - Ordering: Assigned Requisitions 
ME59 - Automatic Generation of POs 

ME54 - Release Purchase Requisition 
ME55 - Collective Release of Purchase Reqs. 
ME5F - Release Reminder: Purch. Requisition 
 
MB21 - Create Reservation 
MB22 - Change Reservation 
MB23 - Display Reservation 
MB24 - Reservations by Material 
MB25 - Reservations by Account Assignment 
 
MB1C - Other Goods Receipts 
MB90 - Output Processing for Mat. Documents 
 
MB21 - Create Reservation 
MB22 - Change Reservation 
MB23 - Display Reservation 
MB24 - Reservations by Material 
MB25 - Reservations by Account Assignment 
 
MBRL - Return Delivery per Mat. Document 

MB1C - Other Goods Receipts 
MB90 - Output Processing for Mat. Documents 
 
MB1B - Transfer Posting 
 
MIBC - ABC Analysis for Cycle Counting 
 
MI01 - Create Physical Inventory Document 
MI02 - Change Physical Inventory Document 
MI03 - Display Physical Inventory Document 
MI31 - Batch Input: Create Phys. Inv. Doc. 
MI32 - Batch Input: Block Material 
MI33 - Batch Input: Freeze Book Inv.Balance 
MICN - Btch Inpt:Ph.Inv.Docs.for Cycle Ctng 
MIK1 - Batch Input: Ph.Inv.Doc.Vendor Cons. 
MIQ1 - Batch Input: PhInvDoc. Project Stock 
 
MI01 - Create Physical Inventory Document 
MI02 - Change Physical Inventory Document 
MI03 - Display Physical Inventory Document 
MI31 - Batch Input: Create Phys. Inv. Doc. 
MI32 - Batch Input: Block Material 
MI33 - Batch Input: Freeze Book Inv.Balance 
MICN - Btch Inpt:Ph.Inv.Docs.for Cycle Ctng 
MIK1 - Batch Input: Ph.Inv.Doc.Vendor Cons. 
MIQ1 - Batch Input: PhInvDoc. Project Stock 
 
MI01 - Create Physical Inventory Document 
MI02 - Change Physical Inventory Document 
MI03 - Display Physical Inventory Document 
MI31 - Batch Input: Create Phys. Inv. Doc. 
MI32 - Batch Input: Block Material 
MI33 - Batch Input: Freeze Book Inv.Balance 
MICN - Btch Inpt:Ph.Inv.Docs.for Cycle Ctng 
MIK1 - Batch Input: Ph.Inv.Doc.Vendor Cons. 
MIQ1 - Batch Input: PhInvDoc. Project Stock 
 
MI21 - Print physical inventory document 
 
MI04 - Enter Inventory Count with Document 
MI05 - Change Inventory Count 
MI06 - Display Inventory Count 
MI09 - Enter Inventory Count w/o Document 
MI34 - Batch Input: Enter Count 
MI35 - Batch Input: Post Zero Stock Balance 
MI38 - Batch Input: Count and Differences 
MI39 - Batch Input: Document and Count 
MI40 - Batch Input: Doc., Count and Diff. 
 
MI08 - Create List of Differences with Doc. 
MI10 - Create List of Differences w/o Doc. 
MI20 - Print List of Differences 
 
MI11 - Physical Inventory Document Recount 
 
MI07 - Process List of Differences 
MI37 - Batch Input: Post Differences 
 
CT01 - Create Characteristic 
CT02 - Change Characteristic 
CT03 - Display Characteristic 
 
CL01 - Create Class 
CL02 - Classes 
CL03 - Display Class 
CL04 - Delete Class 
CL2B - Class Types

SAP MM Introduction

We will Slowly move into the technical areas on SAP Rather than just having a look at the Generic Details about SAP. Now a Days there are some specialized modules available in SAP ERP to tackle the Specific Requirements of certain industries. We will First look at the MM(Material Management) Module in SAP. It is one of the biggest module in SAP.

This module mainly deals with the Procurement Process, Master Data (Material & Vendor Master), Inventory Management, Valuation of Material & Account Determination, Material Requirement Planning, Invoice Verification etc. This module is highly integrated with several modules in SAP.

SAP MM (Material Management) one the biggest functional module in SAP ERP. This module mainly deals with the Procurement Process, Master Data (Material & Vendor Master), Inventory Management, Valuation of Material & Account Determination, Material Requirement Planning, Invoice Verification etc. This module is highly integrated with several modules in SAP.

SAP Materials management (MM) covers all tasks within the supply chain, including consumption-based planning, planning, vendor evaluation and invoice verification. It also includes Inventory and Warehouse management to manage stock until usage dictates the cycle should begin again. Electronic Kan-ban/Just-in-Time delivery is supported.

Normal procurement process has the following steps:

• Determination of requirement
• Determination of source of supply
• Vendor selection
• Purchase order creation
• Purchase order monitoring
• Goods receipt
• Invoice verification

ASAP Implementation Methodology

ASAP methodology means nothing but standard process for implementation of SAP,  It consists of 5 phases.

Project preparation : consists of identifying team members and developing strategy as how to go. Look at the project scope document carefully it will tell you what SAP sub-modules in SAP you should be prepared for.It also Involves Project Plan preparation.

Business blueprint: Its the most Crucial phase in the entire project.

As is - Here you understand the existing business processes of the client . Your Business Process Owners collect all the ISO-documentation (if client is ISO certified), reports and forms at this stage and you analyze how and when the reports/forms are generated, where the data is coming from. You also do a Level -2 training for your BPO so he is made aware of all the required transactions in SAP.

Once this is over BPO can start learning with the consultants help more about SAP. This is crucial because if you miss out any transactions the BPO may forget about some of his Business processes which may come up later. It is a good practice to ask the BPO to make flow charts to explain business processes.

To-Be - Parallely you map these processes to SAP. Processes that you are not sure of as to whether they are present in SAP or not you try to do a configuration of those processes, and along with the BPO(Business process owner he is the clients employee who knows about the clients business processes probably a middle management guy, there can more than one), BPO involvement is required as he may be able to tell you his requirements better. Once you do the business modeling you will also be made aware of the gaps between as-is and to-be , here decisons have to be made as to wether a ABAP development/system modification is required or not and so on. Involve the BPO as much as possible and document everything it is good practice do not be lazy about it.Here the as-is and to-be and gap analysis is explained. This is the document that you will be using to do your configuration in the realization phase. Make sure that you prepare the AS IS documentation and the TO BE Documentation and get it signed-Off from the customer. If both of these documents are not signed off then there will be definitely some problems when we proceed further for implementation.


Realization phase: The purpose of this phase is to implement all the business and process requirements based on the Business blueprint.
    Here you do the configuration in the development server (there are three clients -development,quality, production). You also decide on the master data format, so that BPO can go collect the master data. You also gove ABAP specifications for forms, reports etc, system modifications etc. Unit testing: Your BPOs and a few key users sit down and test your configuration in your module only. It is good to test the BDCs that you need for uploading data at this stage so you have more realistic data and your BDCs are tested.

Final Preperation and Cut Over activities
Once all modules unit testing is over then the configuration is trasported to the Quality server, where testing for all the modules is done by BPOs and end user, this is to check if any problems are there in integration between various modules. Once all is okay from the QA server config is transported to the production server.
Go live preparation .  The collected master data is checked and the uploaded into production server(sever and client I have used interchangeably). Now you are ready for go live i.e. users can now use the production server.

GO-Live and support:The Go-live milestone is itself is easy to achieve; a smooth and uneventful Go-live is another matter altogether. Preparation is the key, including attention to what-if scenarios related not only to the individual business processes deployed but also to the functioning of technology underpinning these business processes and preparation for ongoing support, including maintenance contracts and documented processes and procedures are essential.

ERP - Why it is Required for an Organization

We have seen some thing about ERP and some thing About SAP which is the primary focus area of this Blog, But why all these ERP Softwares are required, Can't we manage all these activities with Custom developed softwares? 


The Answer for the above question lies in various Factors, they are 


Cost, 
  The Cost that involves in the Development of the new Custom software. While developing the software from the Scratch, you need to invest a lot in designing the process and then develop the code for the right from the scratch. Imagine the cost involved in all of them. Hence Organizations are increasingly adapt the ERP packages which are already built for the standard Business Process, you just need to implement them and customize the areas where there are some gap.


Best practice 
What are the key observation you see in any common enterprise is that they have many Business units and every second these departments exchange data and communicate with each other to achieve organizational goals collectively. It is clear that Communication and proper exchange of information helps better in achieving the goals of your organization. Every one is linked with each other for one or other needs say for eg. Sales exchange information with customers, sales provide information to marketing, marketing exchange communication with finance HR and so on. This is not just the basic case where the communication is internally, Exchange of information is with external customers also such as Share holders, creditors, vendors, etc. 


Adaptability with other vendors,
ERP allows you to introduce the latest technologies like Electronic Fund Transfer (EFT), Electronic Data Interchange (EDI), Internet, Intranet, Video conferencing, E-Commerce etc.

Most organizations across the world have realized that in a rapidly changing environment, it is impossible to create and maintain a custom designed software package which will cater to all their requirements and also be completely up-to-date. Realizing the requirement of user organizations some of the leading software companies have designed Enterprise Resource Planning software which will offer an integrated software solution to all the functions of an organization. 

Below is some of the major features of a basic ERP system which can help in one or the other ways.

ERP facilitates company-wide Integrated Information System covering all functional areas like Manufacturing, Selling and distribution, Payables, Receivables, Inventory, Accounts, Human resources, Purchases etc.,
It provides core corporate activities and increases customer service and thereby enhances the Corporate Image.
It provides a bridge between other departments to communicate and exchange data.
It not only communicates and exchange data between other departments but also helps across departments.
ERP helps for better Project Management.

It helps in eliminating most of the business problems like Material shortages, Productivity enhancements, Customer service, Cash Management, Inventory problems, Quality problems, Prompt delivery and so on
ERP not only addresses the current requirements of the company but also provides the opportunity of continually improving and refining business processes.
ERP provides business intelligence tools like Decision Support Systems (DSS), Executive Information System (EIS), Reporting, Data Mining and Early Warning Systems (Robots) for better decisions.

Components of ERP
• Sales and Marketing
• Master Scheduling
• Material Requirement Planning
• Capacity Requirement Planning
• Bill of Materials
• Purchasing
• Shop floor control
• Accounts Payable/Receivable
• Logistics
• Asset Management
• Financial Accounting

Service Oriented Architecture

SOA Concepts

Today, the concept of Service Oriented Architecture has become ubiquitous. Evidence from recent years establish that SOA is not just about hype, but a part of every major Business environment. The truth is, Service Oriented Architecture can be beneficial to Business only when it is utilized properly and when it is utilized to its potential. 

A Service-oriented Architecture is essentially a collection of services. these services communicate with each other. The communication can involve either simple data passing or it could involve two or more services co-ordinating some activity. Some means of connection services to each other is needed.

The technology of Web services is the most likely connection technology of service-oriented architectures. Web services essentially use XML to create a robust connection.

The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined is explained in Web Services explained. A service provider can also be a service consumer.

 

Service Oriented Architecture is no longer a theory – it has moved into the realm of actual initiatives that can ensure that Businesses and investors receive high returns on their investments. It is vital to possess a keen understanding of various Service Oriented Architecture concepts in order to decide whether Service Oriented Architecture is suitable for your Business or not.

Why use Service Oriented Architecture?

Vast majority of Businesses working in the field of Information Technology have to justify their projects with a return on their investments. This puts Information Technology, as a field under enormous pressure. Information Technology must boast requirements that are increasingly responsive and flexible to the shifting needs of different Businesses.

Firms dealing with Information Technology must also be able to face the challenge of taking on an array of software systems that may or may not be compatible with one another. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money.

While Service Oriented Architecture may not solve all the problems posed by the increasingly complex realm of Information Technology, employing SOA tactics can bring a lot of benefits and rewards to a company. Typically, these benefits fit into one of the following three categories:

-Standardized interfaces and data models 
-Re-use 
-Composability

SOA Elements

Let us now take a look at some of the key features of Service Oriented Architecture. The best way to go about doing this is to break SOA down into its acrimonial elements. We’ll start with the last letter first: A for Architecture.

We will first examine architecture in reference to Service Oriented Architecture. Usually, in the realm of software, architecture tends to define the overall intercommunication and definition of different high level components. To put it simply, it is how a solution is broken down into logical units – and how they operate with one another. In a way, Service Oriented Architecture is representative of an approach to architecture that focuses on how services are defined and how they interact with one another.

Service Oriented Architecture is not something you can just go out and purchase. It is a set of architectural principles. While you might be able to directly purchase certain middle-ware that enables services and technologies, they alone do not constitute a Service Oriented Architecture.

Let us consider the SO part of SOA. Being service oriented basically means that you are employing an architecture that consists of a variety of services. This might sound familiar to those who have had some experience in the past with Object Oriented Design. In fact, Object Oriented Design and Service Oriented Architecture do have a lot of things in common.

By thinking in terms of services, you are effectively considering how to make your Business function so that it stands on its own. This approach is enabled via the use of Service Oriented Architecture. It takes into consideration the needs of both providers and consumers of services.

The providers of services offer functionality in the form of interfaces to the service capabilities they are providing. The consumer then accesses those capabilities. Such consumers may be an application or even another service provider. So, for instance, a checking account service may offer a functionality set that relates to a particular checking account. Such an account may offer the possibility to make deposits, withdrawals, create new accounts, and more. These capabilities, you may notice, are very particular to the context of a checking account service. We have not yet stated whether such a service might be provided by an ATM machine, a bank teller, or software.

A lot of people tend to believe that this definition of Service Oriented Architecture is merely the latest way to describe the functionality of applications. The fact is, a lot of applications in today’s day and age have already been built with an end user in mind. Thus, an application may encapsulate a group of several different tasks that are somehow related, yet also retain some degree of discretion.

Service Oriented Architecture distinguishes itself in that the consumer of certain application functionality may very well be another service or application.

Once these principles of architecture have been applied, you will find yourself with a lot of services that are able to interact as a means of providing a specific functionality set with benefits for your Business. This is when re-use comes into the game. You are now able to quickly build up another solution that will reuse a lot of these services while also providing additional services that the Business may require. Such services are woven into software system. In this scenario, they co-operate as a means of achieving Business objective, while possibly participating in some other systems that offer similar service capability for a possibly different end solution.

SOA vs. Other Architectures

Some observers claim that Service Oriented Architecture is merely another way that services and software can be sold. But SOA is a lot more than merely a buzz word. At the beginning, software was a set of code that ran somewhere on a large mainframe computer. This was where input was provided in the form of, say, punch cards.

As computer technology began to evolve, users would make use of simple text based terminals as a means of entering data, schedule jobs, etc. But software continued to grow larger. Rarely would other forms of software be relied upon to do these jobs.

Business logic steadily evolved over time so that much of the interface was moved to individual users’ desktops, while core Business logic and storage remained on a back room main computer. A lot of these applications still function in Businesses around the globe.

Basic Screens in SAP

In this blog we will look into basic screen in the SAP. The screens are listed below.

1)      SAP Logon Screen,

2)      SAP Easy Access Screen

3)    Standard Report screen

SAP Logon Screen

The SAP R/3 System is a client server based system. The client concept enables the joint operation, in one system, of several enterprises that are independent of each other in business terms. During each user session you can only access the data of the client selected during the logon.

A client is, in organizational terms, an independent unit in the R/3 System. Each client has its own data environment and therefore its own master data and transaction data, assigned user master records and charts of accounts, and specific customizing parameters.

SAP systems are available in several languages. Use the Language input field to select the logon language for each session.

Multiple logons are always logged in the system beginning with Release 4.6. This is for security as well as licensing reasons. A warning message appears if the same user attempts to log on twice or more. This message offers three options:

• Continue with current logon and end any other logons in the system
• Continue with current logon without ending any other logons in the system (logged in system)
• Terminate current logon and the screen shot is as shown.

 

SAP Easy Access Screen

SAP Easy Access is the standard entry screen displayed after logon. Using the menu path Extras® Set start transaction you can select a transaction of your choice to be the default entry screen after logon.

You navigate through the system using a compact tree structure that you can adapt to your own specific requirements. Use the menu path Extras® Settings to change your view of the tree structure. You can use this to display technical names (transaction codes).

Enter a transaction code in the command field:

A transaction code (T-Code) is assigned to each function in R/3 (not each screen).

You can access the assigned transaction code from any screen in the R/3 System.

You can find the transaction code for the function you are working in under the Status option of the System menu.

For example, to display SAP Abap Editor data, enter “/n” and the appropriate

Transaction code (in this case “/nse38”).

Combination to make the cursor move from one (input) field group to the next. Use TAB to move between fields within a group.

The standard SAP screen consists of following elements.

Command field: You can use the command field to go to applications directly by entering the transaction code. You can find the transaction code either in the SAP Easy Access menu tree (see next slide) or in the relevant application under System® Status.

Menu bar: The menus shown here depend on which application you are working in. These menus contain cascading menu options.

Standard toolbar: The icons in the system function bar are available on all R/3 screens. Any icons that you cannot use on a particular screen are dimmed. If you leave the cursor on an icon for a moment, a small flag will appear with the name (or function) of that icon. You will also see the corresponding function key. The application toolbar shows you which functions are available in the current application.

Title bar: The title bar displays your current position and activity in the system.

Check boxes: Checkboxes allow you to select several options simultaneously within a group.

Radio buttons: Radio buttons allow you to select one option only.

Status bar: The status bar displays information on the current system status, for example, warning and error messages.

A tab provides a clearer overview of several information screens.

Options: You can set your font size, list colors, and so on here.