Difference between SE16N and SE16H in SAP – What Really Matters?

To help every consultant understand, from Functional to Technical, let’s move away from technical jargon and look at this as the difference between a Microscope (SE16N) and a Data Laboratory (SE16H).

Here is what really matters, explained with real-world examples.

---

1. Joining Tables: The "No More VLOOKUP" Feature

In the old days (SE16N), you could only look at one table at a time. If you needed to see data from two tables, you had to download both to Excel and perform a VLOOKUP.

• The SE16H Advantage: You can create Outer Joins on the fly.
• Example: You are investigating a Sales issue. You need to see the Sales Order Header (VBAK) but also want to see the Material Description (MAKT) and the Item Status (VBUP) in the same view.
• The Result: In SE16H, you define a "Join" in the selection screen. You get one combined report immediately. No Excel required.

2. Aggregation: The "Instant Pivot Table" Feature

Consultants often need to summarize data (How much? How many?). In SE16N, you have to extract all rows and then use the "Total" button in the ALV grid, which can crash the system if there are millions of rows.

• The SE16H Advantage: It performs math at the Database Level. You can Group, Sum, Count, and find Min/Max values before the data even hits your screen.
• Example: You want to know the Total Stock Value in table MBEW grouped by Plant.
• The Result: Instead of loading 500,000 material rows, SE16H shows you 10 rows (one for each plant) with the total sum already calculated. It’s as fast as a Google search because HANA does the math.

3. Drill-Down: From the "Big Picture" to the "Small Detail"

If you use the aggregation feature in SE16H and see something suspicious, you don't have to start over.

• The SE16H Advantage: It supports interactive drill-down.
• Example: You see that Plant FR01 has a suspiciously high total stock value of €10 Million.
• The Result: You simply Double-Click the "€10 Million" cell, and SE16H automatically opens a new list showing exactly which Materials and Batches make up that specific total.

4. Working with HANA Views (CDS & Analytics)

In S/4HANA, a lot of data doesn't live in traditional "tables" anymore. It lives in CDS Views or HANA Calculation Views.

• The SE16H Advantage: It is designed to read these virtual structures. SE16N often shows errors or empty fields when trying to read complex S/4HANA virtual data.
• Example: You need to check the data in a "Virtual" Finance view that combines local and global currency.
• The Result: SE16H treats the View exactly like a table, allowing you to filter and sort normally.

---

⚖️ The "Cheat Sheet" for Consultants

If you want to...	Use SE16N	Use SE16H
Check the value of one specific document.	✅
Check if a field is changing during a process.	✅
Compare data across multiple tables.		✅
Get a Sum or Count of millions of records.		✅
Check data in a HANA / CDS View.		✅
Quickly find Top 10 Vendors by spend.		✅

 

💡 The Ultimate Tip for L'Oréal Consultants

If you are working on Root Cause Analysis (RCA) for a ticket, always start with SE16H.

Most bugs are caused by data inconsistencies between a "Header" and an "Item" (e.g., EKKO and EKPO). By using the Join feature in SE16H, you can see both at once and find the discrepancy in 30 seconds, rather than flipping back and forth between two SE16N windows.

Difference between BAPI vs BAdI in SAP

 

The fundamental question that often confuses people because the names are so similar. However, in the SAP ecosystem, they serve completely opposite purposes.

Think of it this way: A BAPI is a door to get into the SAP system, while a BAdI is a hook inside the system to change how it behaves.

Here is a detailed breakdown of the differences:

1. BAPI (Business Application Programming Interface)

The "Connector"

A BAPI is a specialized Function Module that allows external systems (or other ABAP programs) to interact with SAP business objects (like a Purchase Order, an Employee, or a Material).

• Purpose: To perform a specific business task (Create, Change, Get Detail, or List).
• Technically: They are stored in the Function Builder (SE37) and are always Remote-Enabled (RFC). This means a Java application, a website, or a mobile app can call them.
• Key Characteristic: Standardization. A BAPI is a stable contract. If you use BAPI_PO_CREATE1, SAP guarantees that this interface will remain the same even after an upgrade to a newer S/4HANA version.
• Example: You have a custom web portal where vendors submit invoices. You use a BAPI (BAPI_INCOMINGINVOICE_CREATE) to push that data into SAP and create the actual invoice document.

---

2. BAdI (Business Add-In)

The "Enhancer"

A BAdI is an Object-Oriented enhancement point provided by SAP within the standard source code. It allows developers to add custom logic to standard SAP processes without modifying the standard code (which would be a "modification").

• Purpose: To change or extend the logic of a standard SAP transaction.
• Technically: They are based on ABAP Objects (Classes and Interfaces). You define an interface in SE18 and implement it in SE19.
• Key Characteristic: Flexibility. A BAdI allows you to say: "When the standard SAP code reaches this point, run my custom logic too."
• Example: When a user saves a Purchase Order in transaction ME21N, you want to check if the total amount exceeds €10,000. If it does, you want to trigger a custom warning. You would implement a BAdI (like ME_PROCESS_PO_CUST) to add this validation logic.

---

⚖️ Comparison Table

Feature	BAPI	BAdI
Full Form	Business Application Programming Interface	Business Add-In
Main Goal	Data Exchange: Getting data in or out.	Customization: Changing how standard code works.
Technology	Function Modules (Procedural/RFC).	ABAP Classes & Interfaces (OO).
Call Direction	Usually called from outside the object.	Usually called from inside standard SAP code.
Integration	Used for Interfaces (OData, PI/PO, External Apps).	Used for custom business rules/validations inside SAP.
Transaction	BAPI (Explorer) or SE37.	SE18 (Definition) / SE19 (Implementation).
Analogy	Using a Remote Control to turn on the TV.	Opening the TV and changing a wire to make the screen brighter.

---

🔄 How they work together (The S/4HANA Reality)

In a project at Global Beauty Tech, you will often use both at the same time:

1. The BAPI Trigger: You call a BAPI from an external system to create a Sales Order.
2. The BAdI Hook: While that BAPI is running the standard SAP logic to create the order, it hits a "Hook" where your custom BAdI implementation lives.
3. The Logic: Your BAdI runs a custom  check (e.g., checking if the customer has a specific beauty-tech loyalty tier) and modifies the discount field before the BAPI finishes saving the data.

💡 Summary for your Debugging Mindset:

• If you are debugging a BAPI, you are checking if the Input Data provided from the outside is correct.
• If you are debugging a BAdI, you are checking why the Internal Logic of a standard transaction is behaving unexpectedly.

Debugging is an essential skill for any SAP professional in S/4 HANA

  

Debugging is an essential skill for any SAP professional, especially in complex S/4HANA environments where logic spans across multiple layers.

Moving beyond "random stepping" (brute-force F5/F6) into a specialized debugger mindset will significantly reduce your Root Cause Analysis (RCA) time. Here is an explanation of the tricks you mentioned:

1. Watchpoint on Value Change

A Watchpoint allows you to stop the execution of a program only when the value of a specific variable changes. This is a lifesaver when you are dealing with large loops (e.g., an internal table with 10,000 rows) and you want to see why the 5,432nd row is causing an error.

• How to do it: In the Debugger, click the Create Watchpoint button (Ctrl+Shift+F8). Enter the variable name.
• The Pro Tip: You can add a Free Condition. For example, if you only want to stop when lv_status changes to 'E', enter the condition: lv_status = 'E'. The debugger will then ignore all 'S' or 'W' changes and only stop at the error.

2. Skip Code During Debugging

Sometimes you encounter a block of code (like a specific validation or an authority check) that you know is failing but want to "bypass" to see if the rest of the program works correctly.

• How to do it: Use the "Go to Statement" feature (see point 3) to move the execution cursor past the unwanted logic.
• Warning: Be careful; if the skipped code was supposed to populate a variable used later, you may need to manually fill that variable in the "Variables" tab to prevent a dump.

3. Jump to the Exact Line/Statement (Shift + F12)

This is the "teleportation" trick. It allows you to move the yellow execution arrow to a different line without executing the code in between. You can move it forward (to skip code) or backward (to re-run a block of code with different values).

• How to do it: Place your cursor on the target line and go to Debugger -> Step -> Go to Statement, or simply press Shift + F12.
• Use Case: If a function module just returned an error, you can change the input variables manually, "Jump" back to the start of the function call, and run it again without restarting the entire transaction.

4. Use JDBG for Background Jobs

Debugging a background job is tricky because it doesn't have a UI session. JDBG allows you to "simulate" the job execution in your own foreground session.

• How to do it:
1. Go to transaction SM37.
2. Select a job (it can be in "Finished" or "Scheduled" status).
3. In the command field (where you usually type /n), type JDBG and hit Enter.
• Note: The debugger will start at the very beginning of the background processing system (the wrapper). You will need to press F8 (Continue) or set a breakpoint in your specific program to reach your custom code.

5. Search where a Table/Field is being changed

In S/4HANA, data might be changed by BAdIs, Enhancements, or standard code. Finding the exact spot can be like finding a needle in a haystack.

• The Trick: Use Breakpoints at Statement.
• How to do it: In the "Breakpoints" tab, click "Create Breakpoint". Choose "Breakpoint at Statement".
• For Internal Tables: Use APPEND, MODIFY, or INSERT.
• For Database Tables: Use UPDATE, MODIFY [dbtable], or INSERT [dbtable].
• The debugger will stop every time any internal table is modified, allowing you to check the stack to see if it's the one you're interested in.

6. Debug Update Task Separately

By default, the debugger stops when the "Main" session ends. However, many SAP transactions save data using CALL FUNCTION ... IN UPDATE TASK, which runs in a separate process. If your error happens during the "Saving" phase, a normal debugger won't catch it.

• How to do it:
1. In the Debugger, go to Settings -> Change Debugger Profile/Settings.
2. Check the box "Update Debugging".
3. Press F8. When the main program finishes, a new debugger window will automatically pop up specifically for the update process.

7. Script/Trace Mindset (Not random stepping)

Random stepping (F5/F6) is a "linear" mindset. For complex S/4 logic, you should use a "circular" or "analytical" mindset using ABAP Trace (SAT) or Debugger Scripts.

• ABAP Trace (SAT): Instead of debugging, run the transaction through SAT. It gives you a "hit list" of every method and function called. You can then see exactly where the time was spent or which validation was triggered.
• Debugger Scripting: In the Debugger, there is a "Script" tab. You can write a small ABAP script inside the debugger.
• Example: "Every time this line is hit, write the value of variable X to a log and continue running."
• This allows you to analyze a program's behavior over 1,000 iterations without ever pressing F6.

---

Summary Table for your reference:

Trick	Shortcut / Command	Best for...
Watchpoint	Ctrl+Shift+F8	Finding when a specific variable changes in a loop.
Jump	Shift+F12	Re-running code or skipping faulty validations.
JDBG	Command: JDBG	Troubleshooting finished or failing Background Jobs.
Update Debug	Debugger Settings	Errors that occur only during the "Save" process.
SAT Trace	Transaction: SAT	Understanding the overall flow of an unknown program.

 

Various methods are available for debugging in ABAP

Here's a breakdown of the most common ones:

Ø  1. /h (Traditional Debugger):

This is the classic and most common way to start the ABAP debugger. You can enter /h in the command field of any SAP screen, and the next time you execute a transaction or program, the debugger will start. This method is widely used and provides a comprehensive set of debugging features.

Ø  2. Setting Breakpoints:

BREAK-POINT Statement: You can insert the BREAK-POINT statement directly into your ABAP code. When the program execution reaches this line, the debugger will be triggered. This is useful for targeted debugging of specific parts of your code. You can set breakpoints for specific users as well.

External Breakpoints: You can set external breakpoints for specific user IDs. This is useful when debugging code that is executed by other users. Use transaction SAAB to maintain external breakpoints (also accessible from Utilities->Settings->ABAP Editor->Debugging).

Breakpoint at Statement: While in the ABAP Editor (SE38, SE80), you can set a breakpoint directly in the code by double-clicking in the left-hand margin next to the line number. This is a convenient way to debug during development.

Watchpoints: These allow you to stop the debugger when the value of a specific variable changes.

Ø  3. Transaction SE38 / SA38 (ABAP Editor):

When executing a program from the ABAP Editor (SE38 or SA38), you have options to start the debugger:

With Variant: This allows you to specify input values for your program before it starts and enter debugging mode.

Debugging: Starts debugging immediately when you execute your program.

Ø  4. Transaction SM50 (Work Process Overview):

This transaction shows you the currently active work processes. You can select a process and choose "Debug" to attach the debugger to a running program. This is useful for debugging programs that are already in execution.

Ø  5. Transaction ST05 (Performance Trace):

While primarily used for performance analysis, the SQL trace within ST05 can indirectly help with debugging by showing you the exact SQL statements being executed by your program. This can help pinpoint issues with database access.

Ø  6. Transaction SAT (Runtime Analysis):

SAT is used for performance analysis but can also be valuable during debugging to analyze the program flow and identify potential bottlenecks or unexpected behavior.

 

Ø  Choosing the Right Debugging Method:

Ø  The method you choose depends on the situation:

v /h: Quick and easy for general debugging.

v Breakpoints: Targeted debugging of specific code sections.

v SE38/SA38: Convenient for debugging during development.

v SM50: For debugging running processes.

v ST05 and SAT: Useful for performance-related debugging and analyzing program flow.

 

Ø  Remember to deactivate debugging mode (/hx) when you're finished to avoid performance issues on the system.

 

Ø  This overview provides the most commonly used methods. More specialized debugging techniques exist for specific scenarios, but this should cover most everyday debugging tasks in ABAP.

Simple explanation about SAP BRF+/BRFplus

 

                           SAP Business Rules Framework plus (BRF+) is a powerful tool within the SAP ecosystem for defining and managing business rules, providing a centralized, transparent, and agile way to handle the complex logic driving various business processes.

Let's explore it with examples:

What is SAP BRF+ ?

Ø  BRF+ is essentially a rule engine, a separate "brain" that makes decisions based on provided information. This "brain" is decoupled from the specific application, allowing the same rules to be used across different SAP modules (like Finance, Logistics, HR, etc.) and even non-SAP systems.

Ø  This replaces hardcoding logic directly into applications, which can be difficult to maintain. BRF+ lets you define these rules in a user-friendly environment, ranging from simple calculations and validations to complex decision trees.

Ø  It enables you to define business rules without the need of writing ABAP code.

Ø  The generated Business Rules can be incorporated into other SAP programs or Substitution/Validation rules.

Ø  BRF+ is not new and even not directly related to SAP S/4HANA, but with the release of SAP S/4HANA 1610, BRF+ gained more attention since it is launched as the go-to solution for some business processes. The most important ones are the changes in output management for Billing and Purchasing.

Ø  It is a part of SAP NetWeaver ABAP stack.

Ø  The t-code used is BRF+ or BRFplus.

 Key Features and Benefits, Illustrated with Examples:

Centralized Rule Management: Imagine a company with different discount rules for various customer groups scattered across multiple sales systems. BRF+ consolidates these rules into one central repository, simplifying maintenance and ensuring consistency.

Transparency and Auditability: If a discount is applied incorrectly, BRF+ allows you to trace back exactly which rule was applied, when, and by whom, providing full transparency and aiding in issue resolution.

Improved Agility and Flexibility: Let's say a new customer group requires a special discount. With BRF+, a business user can quickly create and deploy this new rule without needing a developer to change code, enabling faster responses to market demands.

Reduced Development Costs and Time: A validation rule for customer credit limits can be defined once in BRF+ and used across sales, finance, and delivery processes, avoiding redundant development effort and saving time and resources.

Simplified Governance and Control: For regulatory compliance (e.g., SOX), BRF+ ensures that all financial calculations follow approved rules and provides a clear audit trail for demonstrating compliance.

 Examples of BRF+ Applications:

Calculating Discounts: A retail company uses BRF+ to determine discounts based on customer segment, purchase volume, and promotional offers.

Validating Data: A bank uses BRF+ to validate customer data during account opening, ensuring all required information is provided and accurate.

Determining Eligibility: A government agency uses BRF+ to determine eligibility for social benefits based on applicant income and other criteria.

Routing Workflows: An insurance company uses BRF+ to route claims to the appropriate department based on claim type and severity.

Managing Pricing: A manufacturing company uses BRF+ to manage complex pricing rules based on product configuration, raw material costs, and market conditions.

 

Why is it so Popular in the SAP World?

                      BRF+'s popularity stems from its ability to streamline complex business logic, enhance agility, cut development costs, and boost transparency. It empowers businesses to be more adaptable, improve decision-making, and ultimately achieve better results.

                     In essence, BRF+ offers a more modern, efficient, and flexible way to manage business rules in SAP, moving away from hardcoded logic towards a centralized, transparent, and business-user-friendly approach. This is why it has gained so much traction within the SAP community.

 

Simple explanation about IDOC with definition , structures & message types

What is IDOC?

IDOC is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.

In other words, an IDOC is like a data file with a specified format which is exchanged between 2 systems which know how to interpret that data.

IDOC stands for ” Intermediate Document”

IDOC Basics

We can view an IDOC using transaction WE02 or WE05

IDOC Consists of 3 Parts mainly

Control Record:

The administration part (Control Record)- which has the type of idoc , message type, the current status, the sender, receiver etc. This is referred to as the Control record.

Ø  All control record data is stored in EDIDC table. The key to this table is the IDOC Number

Ø  It contains information like IDOC number, the direction(inbound/outbound), sender, recipient information, channel it is using, which port it is using etc.

Ø  Direction ‘1’ indicates outbound, ‘2’ indicates inbound.

Data Record:

The application data (Data Record) – Which contains the data. These are called the data records/segments.

Ø  Data record contains application data like employee header info, weekly details, client details etc

Ø  All data record data is stored in EDID2 to EDID4 tables and EDIDD is a structure where you can see its components.

Ø  It contains data like the idoc number, name and number of the segment in the idoc, the hierarchy and the data

Ø  The actual data is stored as a string in a field called SDATA, which is a 1000 char long field.

Status Record :

The Status information (Status Record)- These give you information about the various stages the idoc has passed through.

Ø  Status record is attached to an I-DOC at every milestone or when it encounter errors.

Ø  All status record data is stored in EDIDS table.

Direction : ‘1’ indicates outbound, ‘2’ indicates inbound.

 

Ø  Outbound :Statuses 1-42 are for outbound

Ø  Inbound: statuses 50-75 are for inbound

 

IDOC Types

Ø  Basic type

                The basic type defines the core structure and content of an IDoc. It represents the standard definition of a specific business document, like a purchase order, invoice, or sales order. The basic type determines the segments (data fields grouped together) that are included in the IDoc, the sequence of those segments, and the data types within each segment. Think of it as the blueprint or template for a particular kind of IDoc. It's identified by a name, for example, ORDERS01 (for purchase orders).

 

Key Characteristics of Basic Types:

•Fixed Structure: The structure of a basic type is predefined and cannot be easily modified.

•Reusable: They are designed to be used across various applications and business processes.

•Standard Segments: They typically include standard segments common to many IDoc types, like control information, partner information, and status information.

•Basis for Extensions: Basic types serve as the foundation for creating extension types, allowing for customization without altering the original standard.

 

Ø  Extension

             An extension type builds upon a basic type by adding custom segments or fields to accommodate specific business requirements. It allows you to enhance the standard IDoc structure without modifying the underlying basic type. This ensures compatibility with standard processes while incorporating company-specific data. For example, you might want to add a field for a customer loyalty number to the standard purchase order IDoc. You would create an extension type based on ORDERS01 to incorporate this additional field.

 

Key Characteristics of Extension Types:

 

Customization: They enable tailoring IDocs to meet unique business needs without disrupting standard functionality.

Inheritance: They inherit all the segments and fields from the underlying basic type.

Flexibility: You can add, delete, or modify segments and fields within the extension type.

Version Control: Extensions are managed with versions, allowing for controlled updates and modifications.

List of IDOC Message Types

Ø  ORDERS - Purchase Order

Ø  ORDCHG - Purchase order Changes

Ø  DESADV - Shipping Notifications

Ø  INBDLV - Inbound Delivery

Ø  REMADV- Payment Advice Processing

Ø  MATMAS - Material Master

Ø  ARTMAS - Article Master

Ø  CREMAS - Supplier Master

Ø  DELINS - Forecast Delivery schedule

Ø  MBGMCR- Post goods movement

Ø  ORDRSP - PO Confirm

Ø  SHPCON - Ship Confirmation/PGI

         

Purchasing:

Ø  ORDERS (Purchase Order): This is the core IDoc for transmitting purchase orders to vendors. It contains all the necessary details about an order, such as materials ordered, quantities, prices, delivery dates, and other conditions. Think of it as the electronic equivalent of a paper purchase order.

 

Ø  ORDCHG (Purchase Order Change): Used to communicate changes to an existing purchase order. This could include modifications to quantities, delivery dates, prices, or other order details. It ensures that both the buyer and vendor are working with the latest version of the order.

 

Ø  ORDRSP (Purchase Order Confirmation/Response): Sent by the vendor back to the buyer as a confirmation or rejection of a purchase order, or to suggest changes. It might contain updated delivery dates, confirmed quantities, or explanations for rejected items.

 

Ø  INBDLV (Inbound Delivery): Represents a delivery of goods from a vendor. It contains information about the expected delivery date, shipping details, and the materials included in the delivery. This allows the buyer to prepare for receiving the goods.

 

Ø  REMADV (Remittance Advice): Used in payment processing to provide details about which invoices are being paid. It links payments to specific invoices and helps with reconciliation. (You listed "Payment Advice Processing" which is the function this IDoc supports, not the IDoc type name itself).

 

Ø  MBGMCR (Post Goods Movement): Documents the movement of goods within the company after they are received. This allows for updating inventory levels and tracking the movement of materials through the warehouse.

 

Logistics and Supply Chain:

Ø  DESADV (Despatch Advice/Shipping Notification): Sent by the vendor to notify the buyer that goods have been shipped. It contains details about the shipment, including tracking information, carrier details, and the shipped quantities. This allows the buyer to track the shipment and plan for its arrival.

 

Ø  DELINS (Forecast Delivery Schedule): Used to communicate planned future deliveries from a vendor. This helps the buyer anticipate upcoming shipments and adjust their planning accordingly. It's essentially a forecast of deliveries.

 

Master Data:

Ø  MATMAS (Material Master): Used to exchange information about materials, including descriptions, units of measure, weights, and other attributes. This ensures that both systems have consistent information about the materials being traded. Crucial for data synchronization between systems.

Ø  ARTMAS (Article Master - often industry-specific): Similar to MATMAS but often used in specific industries like retail or fashion, for managing articles or finished goods. It contains information specific to the industry, such as sizes, colors, or styles.

Ø  CREMAS (Customer Master/Supplier Master): You listed this as "Supplier Master," but CREMAS typically refers to Customer Master. For vendors/suppliers, the IDoc type LIFNR is associated with the Vendor Master. These IDocs are used to exchange information about business partners, including addresses, contact details, payment terms, and other relevant information.

Shipping and Delivery:

Ø  SHPCON - (Shipping Confirmation/Post Goods Issue - PGI): Confirms the shipment of goods and updates the delivery status. This is often linked to the creation of a goods issue document in the shipping system.

 

Key Considerations:

Ø  Versions: These IDoc types can have different versions (e.g., ORDERS01, ORDERS02, etc.), each with slight variations in structure.

Ø  Segments: Each IDoc type is composed of segments, which contain the specific data fields.

Ø  Customization: Companies often customize these standard IDocs by adding custom segments to accommodate specific business needs.

 

IDOC Message Status

Inbound IDOC:

51 - Application Document Not Posted

52 - Application Document Not fully Posted

53 - Application Document Posted

Outbound IDOC:

01- IDOC Generated

02 - Error Passing data to Port

03- Data Passed to port OK

IDOC Reprocessing Method

WE19 - With help of Existing IDOC no we can make the field changes then new IDOC no will be   generated

BD87 - Pass new IDOC no and process it

IDOC Partner Profiles - WE20

Ø  BP - Benefits Provider

Ø  GP - Business Partner

Ø  KU - Customer

Ø  LI - Vendor

Ø  LS - Logical System

Ø  US – User

The Outbound Process

Steps Involved –

1. Create segments(WE31)
2. Create an idoc type(WE30)
3. Create a message type (WE81)
4. Associate a message type to idoc type(WE82)
5. Create a port(WE21)
6. If you are going to use the message control method to trigger idocs then create the function module for creating the idoc and associate the function module to an outbound process code
7. Otherwise, create the function module or stand-alone program which will create the idoc
8. Create a partner profile(WE20) with the necessary information in the outbound parameters for the partner you want to exchange the idoc with. Trigger the idoc.

The Inbound Process

Steps Involved-

1. Creation of basic Idoc type (Transaction WE30)
2. Creating message type (Transaction WE81)
3. Associating the Message type to basic Idoc type (Transaction WE82)
4. Create the function module for processing the idoc
5. Define the function module characteristics (BD51)
6. Allocate the inbound function module to the message type(WE57)
7. Defining process code (Transaction WE42)
8. Creation of partner profile (Transaction WE20)