Author: Rudramani Pandey

  • SAP Node.js Development in MTA

    Preface – This post is part of the SAP Multi-Target Application (MTA)  series.

    Introduction

    To ease the problem of developers, SAP has provided MTA services where we directly call any API under node.js file and this node.js is then utilized by UI5 App as an API. Hence, we neither need any destination setup nor crucial APIs are getting exposed. Thus SAP Node.js Development in MTA is a very important concept.

    SAP Node.js App Structure

    As it can be seen below, under our App folder xs.js we have many files and folders. In this section we will be mainly focusing upon package.json, config.json and server.js.

    PACKAGE.JSON

    This is a file, where we define all the packages/libraries that will be used by our Node.js App. You can find some of them will be already defined/provided by SAP. You need to just add the one that you will be using with its version, as shown below:

    {
      "dependencies": {
        "@sap/xsenv": "^1.2.9",
        "@sap/xsjs": "^4.0.1",
        "express": "~4.15",
        "passport": "~0.3.2",
        "@sap/xssec": "^2.1.11",
        "node-sap-logging": "0.3.0",
        "sap-hdbext-promisfied": "1.0.0"
      },
      "description": "my description",
      "devDependencies": {
        "@sap/xsjs-test": "^3.0.2"
      },
      "files": [],
      "main": "server.js",
      "name": "xs.js",
      "scripts": {
        "start": "node server.js",
        "test": "node testrun.js"
      },
      "engines": {
        "node": "8.x"
      },
      "version": "1.0.0"
    }
    

    CONFIG.JSON

    This is a local JSON file created to store all the calling APIs details. These details are the APIs provided by Blockchain Application Enablement Service.

    {

    “tokenUrl”: “YOUR_TOKEN_URL”,

    “blockServUrl”: “YOUR_BLOCKCHAIN_URL”,

    “authorization”: “Basic YOUR_UNIQUE_API_KEY”

    }

    SERVER.JS

    Under this file we will be writing all the Node.js codes, as shown below [just an example]:

    /*eslint no-console: 0, no-unused-vars: 0*/		
    "use strict";
    var https = require("https");
    var request = require("@sap/xsjs/node_modules/request");
    var xsjs = require("@sap/xsjs");
    var xsenv = require("@sap/xsenv");
    var port = process.env.PORT || 3000;
    var express = require("express");
    var globalBody;
    var app = express();
    var configData = require("./config.json");
    var options, data, token;
    
    // setting Response
    app.set('json spaces', 1400);
    app.use(function (req, res, next) {
      res.setHeader("Access-Control-Allow-Origin", "*");
      res.setHeader("Access-Control-Allow-Credentials", "true");
      res.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
      res.setHeader("Access-Control-Allow-Headers",
        "Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, access-control-allow-origin, cache-control"
      );
      next();
    });
    
    // configure token
    var headeroptions = {
      method: 'GET',
      url: configData.tokenUrl,
      qs: {
        grant_type: 'client_credentials'
      },
      headers: {
        'cache-control': 'no-cache',
        Authorization: configData.authorization
      }
    };
    
    // get proof history
    request(headeroptions, function (error, response, body) {
      if (error) throw new Error(error);
      data = JSON.parse(body);
      token = data.access_token;
    
    var proofoptions = {
        method: 'GET',
        url: configData.blockServUrl + '/logon',
        headers: {
          'cache-control': 'no-cache',
          'Content-Type': 'application/json',
          Accept: 'application/json',
          Authorization: 'Bearer ' + token
        }
      };
      request(proofoptions, function (error, response, body) {
        if (error) throw new Error(error);
        console.log(body);
        globalBody = body;
      });
    
    });
    
    // update proof history
    app.get('/UPDATE_OBJECT_HISTORY', function (req, res, next) {
      var uname = req.query.USERNAME;
      var pass = req.query.PASSWORD;
      var dats = req.query.TIMESTAMP;
      // Get Token
      var tokenoptions = {
        method: 'GET',
        url: configData.tokenUrl,
        qs: {
          grant_type: 'client_credentials'
        },
        headers: {
          'cache-control': 'no-cache',
          Authorization: configData.authorization
        }
      };
        request(tokenoptions, function (error, response, body) {
          if (error) throw new Error(error);
          data = JSON.parse(body);
          token = data.access_token;
        var	dataoptions = {
            method: 'PATCH',
            url: configData.blockServUrl + '/logon',
            headers: {
              'cache-control': 'no-cache',
              'Content-Type': 'application/json',
              Accept: 'application/json',
              Authorization: 'Bearer ' + token
            },
            body: {
              USERNAME: uname,
              PASSWORD: pass,
              TIMESTAMP: dats
            },
            json: true
          };
    
          request(dataoptions, function (error, response, body) {
            if (error) throw new Error(error);
              res.json(globalBody);
          });
      });
    });
    
    // send proof history as response
    app.get('/GET_PROOF_HISTORY', function (req, res, next) {
      res.json(globalBody);
    });
    
    options = {
      anonymous: true, // remove to authenticate calls
      auditLog: {
        logToConsole: true
      }, // change to auditlog service for productive scenarios
    };
    
    // configure token HANA
    try {
      options = Object.assign(options, xsenv.getServices({
        hana: {
          tag: "hana"
        }
      }));
    } catch (err) {
      console.log("[WARN]", err.message);
    }
    
    // configure UAA
    try {
      options = Object.assign(options, xsenv.getServices({
        uaa: {
          tag: "xsuaa"
        }
      }));
    

     

    Once, we are done with the Node.js development we need to run our file, then only we will be able to access it. For that we will run it as shown below:

    Node.js Development in SAP MTA

    Once, we will run it, we will get an API in node.js console and the same will be utilized in the UI5 App.

  • SAP Web IDE Setup for MTA

    Preface – This post is part of the SAP Multi-Target Application (MTA)  series.

    To setup MTA, we will initially need access of SAP Web IDE. Once you have access of the SAP Web IDE, follow the given steps to configure an MTA application:

    Step 01: Open your web IDE and right click on your workspace and click Project from Template under New as shown below:

    MTA Setup step 01

    Step 02: Choose category as All categories, environment as Cloud Foundry and search Multi-Target Application as shown below:

    MTA Setup step 02

    Step 03: Select Multi-Target Application and click Next. Give a project name and its description in upcoming screens and also check mark “Use HTML5 Application Repository” as shown below and click Finish:

    MTA Setup step 03

    This project will be empty as of now with only one .yaml file.

    Step 04: For our UI5 App, we will need an HTML5 Module. Right click on your project and select HTML5 Module under New, as shown below:

    MTA Setup step 04

    Select Category as SAP Fiori Application and search UI5. Select SAPUI5 Application as shown below:

    MTA Setup step 05

    Later, give a Module Name and Namespace for UI5 application. Then proceed to further screens and finish. It will add a HTML module under your MTA application. In our case, we have kept both names same as shown below:

    MTA Setup step 06

    Step 05: For our Node.js App, we will need a Node.js Module. Right click on your project and select Node.js Module under New, as shown below:

    MTA Setup step 07

    Give a module name (xs.js, in our case), a description, and check mark “Enable XSJS support” as shown below, and click finish:

    MTA Setup step 08

    Step 06: Now, we are ready to push our App to Cloud Foundry so that the API that we are going to make is always up and accessible worldwide. For this, we will change the Project Settings so that our project points to the correct cloud foundry settings.

    Right click on your project and click Project Settings under Project as shown below:

    MTA Setup step 09

    Here, you need to click on Cloud Foundry under Project section and just select the available API Endpoint. It will bring all other data as shown below [This will be prefilled unlike the image shown below]:

    MTA Setup step 10

    Now, we are ready to deploy/build our project. For that just click Build as shown below, it will take care of everything by itself.

    MTA Setup step 11

    That’s it. Now, we are ready to work on our coding part of the API.

  • What is SAP MTA: Multi-Target Application

    Preface – This post is part of the SAP Multi-Target Application (MTA)  series.

    Introduction

    A Multi-Target Application (SAP MTA) is a package comprised of multiple libraries, application and resource modules. These have been created using different technologies and deployed to different runtimes but have a common life-cycle. You can bundle different modules together, describe them along with their inter-dependencies to other modules, services, and interfaces, and package them in an Multi-Target Application(MTA) . Please read MTA Documentation by SAP for more info.

    A Multi-Target Application can have both UI5 and other open source app implementation. We can deploy Java, Node.js and all other SAP cloud platform services.

    SAP MTA Architecture

    MTA Architecture
    MTA Architecture

    It is clear from the architecture flow diagram above that using our UI5 App, we will be calling a Node.js API which in return will be calling a Blockchain Application Enablement Service. This Enablement Service will help us to communicate with the Multichain environment. Both this UI5 App and Node.js files will co-exist under MTA Application that we will discuss in upcoming sections.

    Prerequisites and Restrictions

    We need to consider the following limits for the SAP MTA deployment on SAP Cloud Foundry deploy service:

    • Maximum size of the MTA archive: 4 GB
    • Maximum size of MTA module content: 4 GB
    • Maximum size of MTA resource content: 1 GB
    • Maximum size of MTA descriptors (mtad.yaml and MANIFEST.MF): 1 MB

    References

    To learn more about SAP MTA, we recommend to go through following SAP official documentations:

    Topic References
    Multi-Target Application development descriptor Inside an MTA Descriptor
    How to deploy the Multi-Target Application Cloud Foundry Command Line Interface
    Multi-Target Application deployment descriptor Defining MTA Deployment Descriptors for Cloud Foundry
    Multi-Target Application archive Defining Multi-Target Application Archives
    Multi-Target Application extension descriptor Defining MTA Extension Descriptors
    Multi-Target Application module types and parameters MTA Module Types, Resource Types, and Parameters for Applications in the Cloud Foundry Environment
    How to deploy the Multi-Target Application Cloud Foundry Command Line Interface
  • Relational Distributed Database and Blockchain

    Preface – This post is part of the Blockchain Basics series.

    Distributed Database

    A Relational Distributed Database is a database management system which utilizes the Primary Key(PK) and Foreign Key(FK) relationship. Almost every ERP solutions use Relational database. In simple context, this database divides all data based on relations among them. For example, data of employee can be saved into three tables i.e. Employee Details table, Employee Address table and Employee Salary table where each table has Employee ID as a common key.

    Blockchain Ledger

    A Blockchain can be defined as a decentralized database, or simply a decentralized linked list, where list of records (called blocks) are linked via cryptography. By decentralized, we intend that there is no single database where all records are saved rather the same set of data is saved in numerous databases. A block in a Blockchain contains catalogue of records (known as transaction data), a timestamp (i.e. UNIX time) and a cryptographic hash of previous block (hash converts the previous block data into a fixed length of random characters).

    Difference between Distributed database and Blockchain

    Both the database systems mentioned above carry their own advantages and disadvantages. Let us have a look on the basic differences between these database systems:

    Relational Distributed Database Blockchain Ledger
    Controlled by an Admin No Admin, everyone shares same data
    Access limited to view data Anyone can access (public) Blockchain
    Access limited to write data Anyone with right consensus can write
    Relational Databases are fast Blockchain, due to verification process, are slow
    No history trace of edited data unless log table is maintained History of data is maintained via hashing
    High performance & confidentiality High provenance and immutability

    Comparison between Database & Blockchain

  • What is a Database

    Preface – This post is part of the Blockchain Basics series.

    Introduction

    A database (DB) is an organized collection of information, just like a notebook, where you can read, write, update and delete data. It is one of the essential tools of all the organizations using computer technology. A database is also known as ledger. A ledger in accounting stands for a principal book where transactions are saved by date. In digital format these books take form of excel or DB. Going on further, wherever we discuss about ledger, it will stand for database.

    Types of Database

    There are different types of DB which are categorized based on their data saving format and structure. In this section we will discuss following two databases relevant to this paper:

    • Relational Database
      A Relational Database is database management system which utilizes the Primary Key(PK) and Foreign Key(FK) relationship. Almost every ERP solutions use Relational DB. In simple context, this ledger divides all data based on relations among them. For example, data of employee can be saved into three tables i.e. Employee Details table, Employee Address table and Employee Salary table where each table has Employee ID as a common key. The relationship among these tables can be seen below:
      A Relational Database
    • Blockchain
      A Blockchain can be defined as a decentralized database, or simply a decentralized linked list, where list of records (called blocks) are linked via cryptography. By decentralized, we intend that there is no single ledger where all records are saved rather the same set of data is saved in numerous databases. A block in a Blockchain contains catalogue of records (known as transaction data), a timestamp (i.e. UNIX time) and a cryptographic hash of previous block (hash converts the previous block data into a fixed length of random characters). This process of saving blocks is illustrated below (You can make your own blocks here):

      A Blockchain Database
      A Blockchain
  • What is Web Dynpro in SAP ABAP

    Preface – This post is part of the SAP ABAP Web Dynpro series.

    Introduction

    Web Dynpro in SAP ABAP is a standard technology which is used to create web-based applications using ABAP programing language. Web Dynpro includes many graphical development tools which are included in ABAP workbench. Because of the use of a graphical tool, it seems to be more user-friendly.

    Definition and Creation

    Definition

    Web Dynpro applications are built using declarative programming techniques based on the MVC (Model View Controller) architecture. For developing the Web Dynpro entities, the Object navigator (TCODE SE80) is used.

    Creation: Basic steps are:

    Goto SE80 Tcode -> Repository Browser -> Create web Dynpro component -> In the component, the Main view will be created, in that view insert elements as per the requirement. Here we have created just the page header. There are various elements that can be created, for example, dropdown elements, rows, columns, etc.

    After the creation, the whole web Dynpro component needs to saved and activated.

    Creation of Web Dynpro in SAP ABAP

    Steps for all the creations steps are shown below in the picture:

    Step 01:

    web dynpro Object Navigator

    Step 02:

    Create web dynpro App

    Step 03:

    web dynpro Connectivity browser

     

    Step 04:

    web dynpro in SE80

     

    Step 05:

    web dynpro layout

    Step 06:

    web dynpro root

    Step 07:

    web dynpro Insert Element

     

    Step 08:

    web dynpro Create Element

    Step 09:

    web dynpro properties

     

    Step 10:

    web dynpro explorer

    Step 11:

    web dynpro Application

     

    After the creation of the Web Dynpro application, right click on the application and test it. The auto generated URL will open in the internet explorer.

    NOTE: In case the URL is not working then the connection can be checked in SICF Tcode, whether the connection is active in that particular system or not. (By default it is automatically activated in the system).

    Path: SICF (TCODE) -> default_host  -> sap -> public -> bc -> web dynpro

     

    Architecture

    As stated earlier Web Dynpro in SAP ABAP applications are built on the MVC architecture. So now we will explain the MVC design in Web Dynpro.

    1.Model: Model basically means the part which contains data, that means all the business logic will be implemented in the model part only. So in simple word we can say the model is a section which will provide the data.

    2.View: View is the part where the user will be able to see the data.

    3.Controller: The data that is processed in the model, needs to be displayed in the view. But to control the flow between model and view we need this part called a controller.

    Pre-requisites to learn Web Dynpro in SAP ABAP

    1. Core ABAP Programming: Core ABAP programming is prerequisites because as stated earlier in the architecture section the logic for providing data will be written in the model. So the for that ABAP programming skill is required. If one is aware of the ABAP skill then it will be very easy to implement any business logic as per the requirement.

     

    1. Object-Oriented Programming: Oops knowledge is definitely beneficial in web dynpro applications because the as we are talking about the model and controllers these are all nothing but the classes which we implement by creating the objects for it.

     

    1. MVC Architecture: As discussed in the previous section, it is important to know the MVC design pattern to understand the web dynpro application for ABAP. Because the whole point of the application is to model the data and display it to the user which is happening with this design.

    Benefits of Web Dynpro 

    1. There are many benefits of using Web Dynpro as like:
    2. Due to the uses of graphical tools in Web Dynpro , implementation of coding part is reduced.
    3. Use of MVC design ensures the separation of layout and business data.
    4. There is a feature of data binding for the elements created in the view of Web Dynpro, due to which it enables the direct transport of data.
    5. It can run on number of platforms.
  • SAP ABAP Unit Testing Class

    Preface – This post is part of the Object Oriented ABAP series.

    Introduction

    ABAP unit testing is a methodology for software development. Whenever we create a class, it is mandatory to create its test class to check the behavior of our code if it is working exactly as it was expected.  While developing any object, it helps the developer to cover all possible scenarios. With ABAP unit test class, we can also check the coverage of code lines.

    Definition

    ABAP unit test class provides a methodology to test the individual source of code to determine if they are fit to use.

    The global class CL_UNIT_ASSERT contains a method that can be used for testing, the following are the most common methods:

    1. ASSERT_EQUALS – Checks the equality of two data objects.
    2. ASSERT_DIFFERS – Checks for the difference between two data objects.
    3. ASSERT_BOUND – Checks for the validity of the reference of a reference variable.
    4. ASSERT_INITIAL – Checks whether the reference of a reference variable is invalid.
    5. ASSERT_NOT_INITIAL – Checks whether the data object is not having its initial value.
    6. ASSERT_SUBRC – Checks for the specific value of SY-SUBRC.

    Program

    Below is a method ‘GET_ORDER_DATA’ of class ‘ZCL_PROD_ORD_TEST ‘  to fetch the operation details from the production order.

    Note: Local Test Class will get generated automatically through test class generation wizard.

    Method get_order_data

    Figure 1: Method get_order_data

    OSQL test double Framework : To remove the dependency from database tables.

    Unit Test Class

    Figure 2 : Unit Test Class

    Mocking virtual database tables to test the behavior of code.

    Unit Testing of Method GET_ORDER_DATA

    Figure 3: Unit Testing of Method GET_ORDER_DATA

    Advantages

    1. ABAP Unit provides excellent support for test-driven development in ABAP.
    2. You can run tests quickly and easily right from the development environment.
    3. You can navigate back and forth between a test class and the production code.
    4. With ABAP Unit test class, there is no such dependency on availability on test data to test the functionality.
    5. Fewer bugs reported with ABAP unit testing and less time wasted.
  • SAP MM Tables

    Preface – This post is part of the SAP MM series.

    Introduction

    In this section we have discussed SAP MM Tables. We have provided the table name with its description as well as its explanation. Feel free to ask the name of the SAP MM tables that we have missed in the comment section.

    Material master:

    MARA- Material Master: General data

    It is a standard SAP table which is used to store general material data information.

    MAKT- Material Master: Description

    It is a standard SAP table which is used to store material descriptions information.

    MARM- Material Master: Unit of Measure

    It is a standard SAP table which is used to store units of measure for material information.

    MARC- Material master: Plant data

    It is a standard SAP table which is used to store plant data for material information.

    MARD- Material master: Storage location

    It is a standard SAP table which is used to store storage location data for material information.

    MAST- Material link to BOM

    It is a standard SAP table which is used to store material to BOM link information.

    MBEW- Material valuation

    It is a standard SAP table which is used to store material valuation information.

    It will show the stock as on current date. And not period wise details of stock is available.

    MBEWH- Material Valuation: History

    It table is updated whenever there is change in Moving Average Price.

    It is basically the History table for MBEW – Material Valuation table.

    MLGN- Material Master: WM Inventory

    It is a standard SAP table which is used to store Material Data for Each Warehouse Number information.

    MLGT- Material Master: WM Inventory type

    It is a standard SAP table which is used to store Material Data for Each Storage Type information.

    MVKE- Material Master: Sales <Sales Org, Distr Ch>

    It is a standard SAP table which is used to store Sales Data for Material information.

     

    MLAN- Material Master: Tax indicator

    It is a standard SAP table which is used to store Tax Classification for Material information.

    MAPR- Material Master: Forecast

    It is a standard SAP table which is used to store Material Index for Forecast information.

     

    Vendor master:

    LFA1- Vendor Master: General data

    It is a standard SAP table which is used to store Vendor Master (General Section) information.

    LFB1- Vendor Master: Company data

    It is a standard SAP table which is used to store Vendor Master (Company Code) information.

    LFM1- Vendor Master: Purchasing Data (Purchasing organization)

    It is a standard SAP table which is used to store Vendor master record for purchasing organization.

    LFM2- Vendor Master: Purchasing Data (Plant, Vendor subrange)

    It is a standard SAP table which is used to store purchasing data for vendor master record.

     

     

    Purchasing:

    EBAN   Purchase requisition: items

    It is a standard SAP table which is used to store Purchase Requisition information.

    EBKN   Purchase Requisition: account assignment

    EBKN is a standard SAP table which is used to store Purchase Requisition Account Assignment information.

    EKKO   Purchasing document header

    EKKO is an SAP table used to store Purchasing Document Header information.

    EKPO   Purchasing Document: Item

    It is a standard SAP table which is used to store Purchasing Document Item information.

    EKET    Purchasing Document: Delivery Schedules

    It is a standard SAP table which is used to store Scheduling Agreement Schedule Lines information.

    EKKN- Account assignment in purchasing document

    It is a standard SAP table which is used to store Account Assignment in Purchasing Document information.

    EORD- Purchasing Source List

    It is a standard SAP table which is used to store Purchasing Source List information.

    EIPA- Order price history record

    It is a standard SAP table which is used to store Order Price History information.

    EKAB- Release documentation

    It is a standard SAP table which is used to store Release Documentation information.

    EKBE- Purchasing document history

    It is a standard SAP table which is used to store History per Purchasing Document information.

    EKBZ- Purchasing document history: delivery costs

    It is a standard SAP table which is used to store history of delivery costs information per purchasing document.

    EINA- Purchase Info Record: General

    It is a standard SAP table which is used to store purchasing info record for general data information.

    EINE- Purchasing info record: purchasing organization data

    It is a standard SAP table which is used to store purchasing info record for purchasing organization.

     

     

    Inventory Management:

    ISEG- Physical inventory document items

    It is a standard SAP table which is used to store Physical Inventory Document Items information.

    MKPF- Material document: Header

    It is a standard SAP table which is used to store Header: Material Document information.

    MSEG- Material document: item

    It is a standard SAP table which is used to store Document Segment: Material information.

    RKPF- Reservation: Header

    It is a standard SAP table which is used to store Document Header: Reservation information.

    RESB- Reservation: Item

    It is a standard SAP table which is used to store Reservation/dependent requirements information.

     

    Invoice Verification:

    MYMFT- FIFO results table

    It is a standard SAP Table which is used to store FIFO Results Table information.

    MYMP1- Receipt data LIFO/FIFO valuation

    It is a standard SAP Table which is used to store Receipt Data LFIO/FIFO Valuation information.

    RBCO- Document item, incoming invoice account assignment

    It is a standard SAP Table which is used to store Document Item, Incoming Invoice, Account Assignment information.

    RBDIFFKO- Invoice Verification: conditions

    It is a standard SAP Table which is used to store Invoice Verification – Conditions information.

    RBDIFFME- Invoice Verification: quantity differences

    It is a standard SAP Table which is used to store Batch Invoice Verification – Quantity Differences information.

    RBDRSEG- Invoice Verification batch: invoice document items

    It is a standard SAP Table which is used to store Batch Invoice Verification: Invoice Document Items information.

    RBKP- Document header: incoming invoice

    It is a standard SAP Table used to store Document Header: Invoice Receipt information.

    RBTX- Taxes: incoming invoice

    It is an SAP Table used to store Taxes: Incoming Invoice information.

    RBVD- Invoice document: summarization data

    It is a standard SAP Table which is used to store Invoice Document – Aggregation Data information.

    RBVDMAT- Invoice Verification: summarization data, material

    RKWA- Consignment withdrawals

    It is a standard SAP Table used to store Consignment Withdrawals information.

    RSEG- Document item, incoming invoice

    It is a standard SAP Table which is used to store Document Item: Incoming Invoice information.

  • SAP MM Tcodes

    Preface – This post is part of the SAP MM series.

    Important T-codes in MM

    In this section we will discuss all the SAP MM Tcodes. These transactional codes are sub divided into groups for your better understanding. Feel free to ask the Tcodes which we have missed in the comment section.

    Material Master Tcodes

    Create material master : MM01

    Change material master : MM02

    Display material master : MM03

    Material master list : MM60

    Display Material document : MB03

    Vendor Master Tcodes

    Create vendor master : XK01

    Change vendor master : XK02

    Display vendor master : XK03

    Source list Tcodes

    Maintain source list : ME01

    Display source list : ME03

    Change source list : ME04

    Purchase Requisition Tcodes

    Create Purchase Requisition : ME51N

    Change Purchase Requisition : ME52N

    Display Purchase Requisition : ME53N

    Release Purchase Requisition : ME54

    Collective release of Purchase Requisition : ME55

    Assign source of supply to requisitions : ME56

    Request for Quotation Tcodes

    Create Request for quotation :  ME41

    Change Request for quotation : ME42

    Display Request for quotation : ME43

    Purchase Order Tcodes

    Create Purchase Order : ME21N

    Change Purchase Order : ME22N

    Display Purchase Order : ME23N

    Release Purchase Order : ME29N

    Reservation Tcodes

    Create Reservation : MB21

    Change Reservation : MB22

    Display Reservation : MB23

    Reservation by Material : MB24

    Reservation by Account Assignment : MB25

    Goods Receipt Tcodes

    Create Goods Receipt : MIGO

    Cancellation/display Goods Receipt : MIGO

    Physical Inventory Document Tcodes

    Create Physical Inventory Document : MI01

    Change Physical Inventory Document : MI02

    Display Physical Inventory Document : MI03

    Enter Inventory Count : MI04

    Change Inventory Count : MI05

    Display Inventory Count : MI06

    Post Inventory Difference : MI07

    List of Inventory Difference : MI20

    Invoice Verification Tcodes

    Display Of Invoice Document : MIR5

    List Of GR/IR Balance : MB5S

    MM configuration Tcodes

    Create Company : OX15

    Create Company Code : OX02

    Create Plant : OX10

    Create Storage Location : OX09

    Create Purchasing Organization : OX08

    Create Purchasing Group : OME4

    Assign Plant to Company Code : OX18

    Assign Purchasing Organization to Company Code : OX01

    Assign Purchasing Organization to Plant : OX17

    Assign output device to Purchasing Group : OMGF

    Assign tax indicator to Plant : OMKN

  • SAP MM Organizational Structure

    Preface – This post is part of the SAP MM series.

    Introduction

    In the SAP ERP, SAP MM Organizational Structure is used to represent the legal and organizational structure of the company. The organizational structures form a framework according to which the whole business runs.

    The organizational structure in Material management consists of the following levels:

    • Client
    • Company Code
    • Plant
    • Storage location
    • Purchasing Organization
    • Purchasing Group

    The following diagram represents the organizational structure of SAP MM:

    SAP MM Organizational Structure
    SAP MM Organizational Structure

    Let’s discuss them briefly.

    Client

    A client is a group or combination of legal, organizational, business and/or administrative units with a common purpose. It is the highest hierarchy of the organizational structure in SAP.

    Company code

    A company code represents an independent unit within a client. This organizational unit is created in finance and the same is linked with the Materials Management module. Each company code maintains its own balance sheet and its own profit and loss statement.

    Plant

    A plant is an operational unit in a company code. In SAP, the plant is a broad term depending on the functionality.  As in Material management, it is referred to as a facility where materials are stored, and inventory is maintained. Whereas in the Production planning module, it is referred to as a facility where materials are produced.

    Storage location

    A storage location is an organizational unit where stocks are kept physically, and inventory is maintained. A plant can consist of multiple storage location which differentiates between different materials are stocked in a plant.

    Purchasing Organization

    A purchasing organization is an organizational unit responsible for procuring materials/services for one or more plants. It is responsible for negotiating general conditions of purchase with vendors and holds legal responsibility for all external purchase transactions.

    Purchasing organizations can be centralized or decentralized. In centralized, a single purchasing organization is assigned to one or more plant whereas in decentralized, different purchasing organization is assigned to a different plant.

    Purchasing group

    A purchasing group is an organizational unit responsible for day-to-day procurement activities in an organization. It may be an individual or group of individuals responsible for carrying out procurement activities.