Don’t just revise your module concepts. Prepare for these 21 technical questions too.Here are the questions listed:
- How do you gather requirements from business users?
- What is a Functional Specification document? What are its key components?
- Explain the difference between WRICEF and RICEFW
- What is the difference between Technical and Functional Specifications?
- How do you handle functional testing of custom developments?
- What are the different types of SAP Enhancement techniques?
- Explain the difference between a User Exit, BADI, and Enhancement Point
- What are IDocs? How do they work in SAP?
- What is the use of LSMW in SAP?
- What is the purpose of the TCode SE16N in SAP?
- What are the common status codes in IDoc processing, and what do they mean?
- What is the difference between BAPI and BADI in SAP?
- What is the use of transaction code SE11 in SAP?
- What is the use of transaction code SE18 and SE19 in SAP?
- What is the difference between Classical BAdI and New BAdI (Enhancement Spot)?
- What is a Transport Request in SAP and how does it work?
- What are Smart Forms and how are they different from SAP Scripts?
- Explain how you debug an issue that spans across FI and MM modules
- What is the role of the functional spec and technical spec in custom development?
- How do you handle missing data in IDoc processing?
- What is the difference between implicit and explicit enhancements in SAP?
Answers:
1. How do you gather requirements from business users?
Gathering requirements from business users is one of the most critical responsibilities of a techno-functional consultant. This process ensures that the SAP solution meets the actual business needs rather than just theoretical best practices.
Step-by-Step Process:
1. Prepare for the Requirement Session
Understand the current business process (As-Is process).
Review any existing documentation or reports.
Identify the stakeholders (business heads, process owners, end-users).
2. Conduct Requirement Workshops or Interviews
Organize workshops or one-on-one meetings with relevant business users.
Use open-ended questions to uncover pain points and expectations.
“What challenges are you currently facing in the procurement process?”
“How do you track your financial entries today?”
3. Document the As-Is and To-Be Processes
Create process flowcharts or process maps to visualize the current (As-Is) and proposed (To-Be) scenarios.
Highlight areas where SAP standard processes can be used and where enhancements are needed.
4. Capture Functional Requirements
Clearly document what the user wants the system to do.
Specify business rules, required fields, validation logic, and calculations.
5. Analyze for Gaps
Compare business needs with SAP standard capabilities.
Identify gaps that need custom development (e.g., Z-reports, custom workflows).
6. Create Business Blueprint / Requirement Specification
Consolidate findings in a Business Blueprint or Requirement Specification document.
Get sign-off from business users to avoid misunderstandings later.
7. Validate Through Prototyping
Where possible, build quick prototypes in the SAP system to validate understanding.
Get feedback from users before moving to full development or configuration.
Best Practices:
Always involve both end-users and process owners.
Use visual tools like process diagrams and mock screens.
Validate assumptions before documenting.
Maintain version control and sign-offs.
2. What is a Functional Specification document? What are its key components?
A Functional Specification (FS) document in SAP is a detailed blueprint prepared by functional consultants that translates business requirements into a format understandable by technical teams (typically ABAP developers).
It defines what needs to be built — not how to build it.
Purpose of a Functional Specification
Acts as a communication bridge between functional and technical teams.
Ensures the ABAP team develops exactly what the business needs.
Provides a single point of reference during development, testing, and support.
Key Components of a Functional Specification Document
| Section | Description |
| 1. Document Title and Version | Name of the development, version number, date, author. |
| 2. Objective/Purpose | A short summary of the business requirement. Why is the development needed? |
| 3. Background/Business Context | Detailed explanation of the current business process and the problem or gap that needs to be addressed. |
| 4. Scope | What is included and excluded in this requirement? Clearly defines the boundaries. |
| 5. Trigger/Source | What will trigger this development? (e.g., a transaction code, event, schedule, or user action). |
| 6. Input Data | Data the development will receive (e.g., fields, selection criteria, tables). |
| 7. Processing Logic | Business rules, calculations, validations, and logic that must be applied. |
| 8. Output Format | Description of expected output — report layout, screen format, file structure, etc. |
| 9. Error Handling | How should the system behave in case of missing data, failed validation, etc. |
| 10. Security/Authorizations | Any specific roles or authorizations needed to access or execute. |
| 11. Dependencies/Assumptions | Other developments or processes this relies on. Assumptions made while writing FS. |
| 12. Testing Criteria | How will this be tested? Include test cases, data, and expected outcomes. |
| 13. Appendix | Supporting screenshots, mockups, sample output files, etc. |
3. Explain the difference between WRICEF and RICEFW
Both WRICEF and RICEFW are acronyms used to classify custom objects in SAP projects. Although the terms contain the same letters, the order may vary depending on company or consultant preference — but they refer to the same types of developments.
What Does RICEFW/WRICEF Stand For?
| Letter | Component | Description |
| R | Reports | Custom-developed reports (classical, ALV, interactive) not available in standard SAP. |
| I | Interfaces | Connections to external systems (e.g., SAP to third-party using IDOCs, BAPIs, APIs). |
| C | Conversions | One-time data migration (e.g., legacy vendor/customer data to SAP). |
| E | Enhancements | Modifications or extensions to standard SAP functionality (e.g., user exits, BADIs, enhancement points). |
| F | Forms | Output documents such as invoices, purchase orders (using SmartForms, Adobe Forms, or SAPScript). |
| W | Workflows | Automated approval processes (e.g., PO approval, leave request approval). |
Key Differences between Each Component
| Component | Example |
| Reports | Custom report to display overdue GRs per plant. |
| Interfaces | Integration between SAP and a bank for payment confirmation. |
| Conversions | Migrating open sales orders from legacy system to SAP using LSMW or BAPIs. |
| Enhancements | Adding custom logic during MIRO using user exit. |
| Forms | SmartForm to print delivery note in a custom layout. |
| Workflows | Manager receives approval request for a new vendor creation. |
Why It Matters:
WRICEF/RICEFW classification helps project teams categorize all custom developments.
Ensures proper planning, testing, and documentation for each development type.
4. What is the difference between Technical and Functional Specifications?
Both Functional Specification (FS) and Technical Specification (TS) documents are crucial in SAP projects, especially for custom developments. They serve different purposes and are written by different types of consultants, but they complement each other.
Functional Specification (FS)
| Aspect | Details |
| Prepared By | Functional Consultant |
| Purpose | Describes what the system should do, based on business requirements. |
| Audience | Business users and technical team |
| Contents | – Business process description- Input fields and validation rules- Processing logic (in business terms)- Output layout- Test scenarios |
| Focus | Business logic and functional requirements |
| Example | “Create a report that shows all overdue POs by vendor and plant with totals per vendor.” |
Technical Specification (TS)
| Aspect | Details |
| Prepared By | ABAP Developer / Technical Consultant |
| Purpose | Describes how the requirement from the FS will be implemented in the system. |
| Audience | Technical team, peer developers, QA team |
| Contents | – Table names and fields- Data fetch logic (joins, select statements)- Enhancement framework used (user exit, BADI, etc.)- Performance considerations- Program architecture |
| Focus | System-level implementation details |
| Example | “Fetch data from EKKO and EKPO tables where delivery date < SY-DATUM, sort by vendor, and display using ALV Grid.” |
Key Differences at a Glance
| Feature | Functional Spec | Technical Spec |
| Language | Business-friendly | Developer-friendly |
| Created By | Functional Consultant | Technical Consultant |
| Goal | Describe what is needed | Describe how it will be built |
| Visibility | Shared with business | Internal to technical team |
5. How do you handle functional testing of custom developments?
Functional testing ensures that a custom development — whether it’s a report, form, enhancement, interface, or workflow — meets the business requirement as described in the Functional Specification (FS). As a techno-functional consultant, you’re responsible for validating that the logic works correctly from a business process perspective.
Step-by-Step Approach to Functional Testing
1. Understand the Requirement Thoroughly
Revisit the Functional Specification document.
Understand the input parameters, expected outputs, and business logic involved.
2. Create Functional Test Cases
Define test cases that cover all possible scenarios:
Positive cases (correct data)
Negative cases (missing/wrong data)
Boundary cases (edge values or dates)
Example: For a custom PO report, test for:
Vendor A in Plant X
Vendor B with no POs
POs with future delivery dates
3. Prepare Test Data
Use real or close-to-real test data (e.g., POs, invoices, cost centers).
Coordinate with the BASIS team if data refresh or client copy is needed.
4. Execute the Development
Run the custom program/form/interface/workflow in the test environment (QAS or Sandbox).
Use various inputs and selection parameters.
5. Validate the Output
Compare the system’s output with expected results from the test case.
Check:
Field values
Calculations
Data filters
Authorization restrictions
Format and alignment (especially for forms)
6. Log Defects (if any)
If issues are found, report them to the technical team with:
Screenshot
Steps to reproduce
Test data used
Expected vs actual result
7. Re-test After Fixes
Once corrected, re-run the test to ensure the issue is resolved.
Repeat for all test cases until the development is functionally sound.
Additional Functional Testing Tips:
Always test with end-to-end scenarios (e.g., from PR to payment).
Include edge cases (e.g., zero values, blank fields).
Ensure user roles and authorizations are respected.
Involve end-users for UAT (User Acceptance Testing) where required.
6. What are the different types of SAP Enhancement techniques?
Enhancement techniques in SAP allow us to modify or extend standard SAP functionality without changing the core code. As a techno-functional consultant, knowing the right enhancement method ensures that business requirements are fulfilled safely and upgrade-compliantly.
Types of SAP Enhancement Techniques
| Category | Enhancement Type | Description |
| Classic | User Exits | Predefined FORM routines in standard programs (procedural). Only one implementation allowed. |
| Customer Exits | Function module-based exits (CALL CUSTOMER-FUNCTION) provided by SAP. | |
| Modern | BADIs (Business Add-Ins) | Object-oriented exits. Allow multiple implementations and are reusable. |
| Enhancement Points (Explicit & Implicit) | Points defined in ABAP code where custom logic can be added without modification. | |
| Other | BTE (Business Transaction Events) | Used mainly in FI module for event-based enhancements. |
| Customer Fields / Append Structures | Add custom fields to standard tables and screens (using APPEND or screen exits). | |
| VOFM Routines | Custom routines in SD for pricing, copying controls, and requirements. |
1. User Exit
Found in programs as FORM USEREXIT_….
Used for modifying standard logic in specific TCodes (e.g., VA01, MIRO).
Example: Validate shipping condition in USEREXIT_SAVE_DOCUMENT_PREPARE.
2. Customer Exit
Function module-based enhancement (e.g., EXIT_SAPLV60B_001).
Grouped under Enhancement Project (TCode: CMOD).
Tied to standard SAP program points via SMOD.
3. BADI (Business Add-In)
Object-oriented and flexible.
Located via SE18/SE19.
Example: Implement ME_PROCESS_PO_CUST to validate PO fields at item level.
4. Enhancement Points
Found in code as:
Explicit: Defined by SAP developers
Implicit: Automatically available at start/end of programs, functions, includes
Implemented using TCode: SE18 or enhancement implementation tools.
5. BTE (Business Transaction Events)
Mostly used in Finance (FI) module.
Registered in TCode: FIBF.
Example: Add logic during vendor open item clearing.
6. Customer Fields & Screen Exits
Add custom fields to standard tables via append structures.
Add those fields to standard screens via screen exits (SE51 or CMOD).
Example: Add “Region Code” to Customer Master (XD01).
7. VOFM Routines
Used in SD module.
Custom logic for pricing, output determination, copy controls.
Accessed via SPRO → SD → VOFM routines.
7. Explain the difference between a User Exit, BADI, and Enhancement Point
In SAP, when the standard functionality doesn’t meet business needs, we enhance the system using tools provided by SAP — without modifying the core code. These tools include User Exits, BADIs, and Enhancement Points, commonly used by techno-functional consultants and developers.
1. User Exit
| Feature | Description |
| Type | Classic enhancement technique (procedural ABAP) |
| Available in | SAP ECC and earlier systems |
| Usage | Predefined empty subroutines (e.g., FORM USEREXIT_…) where you can write custom code |
| Example | Add validation during sales order saving (VA01) using USEREXIT_SAVE_DOCUMENT_PREPARE |
| Limitation | Only one implementation possible; not object-oriented |
2. BADI (Business Add-In)
| Feature | Description |
| Type | Object-oriented enhancement technique |
| Available in | SAP ECC and S/4HANA |
| Usage | SAP-defined enhancement points that allow developers to add custom logic via implementing classes |
| Example | Implement BADI ME_PROCESS_PO_CUST to add checks during PO creation |
| Flexibility | Multiple implementations possible (especially in filter-based BADIs) |
| Advantages | Cleaner, reusable, object-oriented code structure |
3. Enhancement Point / Enhancement Framework
| Feature | Description |
| Type | Modern enhancement technique in SAP |
| Available in | SAP ECC (later versions) and S/4HANA |
| Usage | Enhancement points are predefined hooks in the standard code where you can inject custom logic using Enhancement Spots |
| Example | Add a custom check in standard function module using an explicit enhancement point |
| Types | Explicit (defined by SAP) and Implicit (automatically available at start/end of programs) |
| Advantages | Multiple enhancements allowed, clean separation of custom code |
Key Differences at a Glance
| Feature | User Exit | BADI | Enhancement Point |
| ABAP Style | Procedural | Object-Oriented | Procedural or OO |
| Multiple Uses | No | Yes | Yes |
| Flexibility | Limited | High | Very High |
| Best for | Legacy Enhancements | Modern Enhancements | Custom Insertions in Standard |
8. What are IDocs? How do they work in SAP?
IDoc (Intermediate Document) is a standard data structure used in SAP to exchange information between SAP systems or between SAP and external systems. IDocs are at the heart of EDI (Electronic Data Interchange) and system integration in SAP.
What is an IDoc?
| Feature | Description |
| Full Form | Intermediate Document |
| Type | ASCII text-based data container |
| Use Case | Data exchange between systems (e.g., create a Sales Order from external CRM) |
| Components | Control record, Data records, Status records |
| Example | Send PO from SAP to a vendor → ORDERS05 IDoc |
Structure of an IDoc
Control Record (EDIDC)
Contains sender/receiver info, IDoc type, message type.
Data Records (EDID4)
Actual transactional data in segments (e.g., vendor, PO header/item).
Status Records (EDIDS)
Logs status of processing (e.g., 03 – data passed to port, 12 – IDoc successfully posted).
Common IDoc Types and Message Types
| Process | Message Type | IDoc Type |
| Sales Order | ORDERS | ORDERS05 |
| Purchase Order | ORDERS | ORDERS05 |
| Inbound Delivery | DESADV | DESADV01 |
| Goods Receipt | WMMBID | WMMBID02 |
| Invoice | INVOIC | INVOIC02 |
| Material Master | MATMAS | MATMAS05 |
How IDocs Work: Inbound & Outbound
1. Outbound IDoc (SAP → External System)
Triggered by an event (e.g., PO creation).
Data is formatted into an IDoc and sent via Port (RFC, file, EDI).
Status codes show successful sending (e.g., 03).
2. Inbound IDoc (External → SAP)
External system sends IDoc to SAP via port.
SAP interprets data using Function Module (in Process Code).
Triggers creation of object (e.g., sales order).
Key TCodes for IDoc Monitoring & Processing
| TCode | Purpose |
| WE02 / WE05 | Display IDoc |
| BD87 | Reprocess IDoc |
| WE19 | Test IDoc (IDoc simulator) |
| WE20 | Partner profiles |
| WE21 | Port definitions |
| WE30 | IDoc type editor |
| WE60 | IDoc documentation |
Real-Time Example
A 3rd party logistics provider sends delivery status to SAP.
SAP receives DESADV IDoc.
SAP updates delivery document automatically via inbound IDoc.
Status 53 indicates successful posting.
9. What is the use of LSMW in SAP?
LSMW (Legacy System Migration Workbench) is a tool provided by SAP to facilitate the data migration process from legacy systems to SAP. It helps functional and technical consultants upload master data and transactional data without extensive ABAP development.
Key Use Cases of LSMW
| Scenario | Example |
| Master Data Upload | Customer, Vendor, Material Master |
| Transactional Data Upload | Purchase Orders, Invoices, Sales Orders |
| One-time Historical Data Migration | Asset balances, open items |
| Mass Data Maintenance | Changing payment terms for many vendors |
Methods Available in LSMW
| Method | Description |
| Direct Input | Data is loaded directly using standard SAP programs. |
| Batch Input Recording (BDC) | Simulates screen input using a recording (like BDC). |
| Standard Batch/IDoc | Uses standard SAP IDocs to post data. |
| BAPIs | Calls SAP BAPIs for posting data (advanced but cleaner integration). |
LSMW Process Flow (Step-by-Step)
TCode: LSMW
Step 1: Define Object Attributes
Here, define how you want to upload the data.
Choose the method of data transfer:
- Standard Batch/ Direct Input
- Direct Input Recording
- BAPI Method
- IDoc Method
For most practical cases, “Batch Input Recording” is commonly used.
Step 2: Define Source Structures
Define the structure of your input (legacy) data file.
Example:
For Material Master upload – you may define one structure with fields like:
MATNR, MATKL, MEINS, MTART, MAKTX, etc.
Step 3: Define Source Fields
Specify all fields that exist in the source file (Excel/Text).
Step 4: Define Structure Relations
Link your source structure to the corresponding target SAP structure.
Step 5: Define Field Mapping and Conversion Rules
Map source fields (legacy data) to target SAP fields.
Here you can define default values, translation rules, or fixed values.
Step 6: Maintain Fixed Values, Translations, User-Defined Routines
Optional step to handle data transformations – for example, converting date formats, or mapping legacy plant codes to SAP plant codes.
Step 7: Specify Files
Upload your legacy data file (usually a .txt or .csv file) from your PC or server.
Step 8: Assign Files
Assign your uploaded file to the source structure defined earlier.
Step 9: Read Data
System reads the file and checks for format correctness.
Step 10: Display Read Data
Verify if all rows and columns were read properly by the system.
Step 11: Convert Data
System applies the mapping and conversion rules to transform legacy data into SAP format.
Step 12: Display Converted Data
Validate that converted data looks correct and ready for upload.
Step 13: Create Batch Input Session
Creates a Batch Input Session.
Step 14: Execute this session to post data into SAP.
Here, SAP will simulate user entries (like manually entering data in MM01, FS00, etc.)
Example Scenario
Upload 1,000 new vendors using LSMW:
Prepare Excel file with vendor details
Use a BDC recording of MM01
Map fields in LSMW
Upload, convert, and post
Advantages of LSMW
No coding required
Fast and repeatable process
Useful for both initial migration and mass updates
Supports multiple upload methods
10. What is the purpose of the TCode SE16N in SAP?
SE16N is the enhanced version of SE16, and it’s used to view table contents in SAP. It’s an essential tool for both functional and technical consultants for data analysis, validation, and troubleshooting.
Key Uses of SE16N
| Use Case | Example |
| Check master data | View material data from MARA or vendor data from LFA1 |
| View transactional data | See PO history from EKBE, accounting docs from BSEG |
| Debug data issues | Look at open vs cleared items in BSID/BSAD |
| Download to Excel | Export query results for reporting or validation |
| Perform quick filtering | Apply WHERE conditions like document date, company code |
SE16N vs SE16
| Feature | SE16 | SE16N (New) |
| UI Experience | Older format | User-friendly layout |
| Field Search | Manual | Auto-suggest enabled |
| Download options | Limited | Enhanced with ALV grid |
| Change mode | X | Possible (if activated with /H) |
Example: Find Vendor Invoices
Open SE16N
Enter table: BSEG
Enter filters:
BUDAT (Posting Date) = >= 01.07.2025
BUKRS (Company Code) = 1000
LIFNR (Vendor) = 200001
Click Execute (F8) to view the line items.
Commonly Accessed Tables via SE16N
| Table | Description |
| MARA | Material Master (general) |
| BKPF | FI Document Header |
| BSEG | FI Document Line Items |
| EKKO | Purchasing Document Header |
| EKPO | Purchasing Document Item |
| LFA1 | Vendor Master |
| KNA1 | Customer Master |
Advanced Features
Technical field names view
Multiple field filters
Use wildcards (* and +)
Download results as Excel / Spreadsheet
Sort and layout customization
Note on Table Editing:
You can technically enable change mode with /H debugging, but it’s strongly discouraged unless under supervision, as it can corrupt data. SE16N is mainly for display purposes.
11. What are the common status codes in IDoc processing, and what do they mean?
Each IDoc in SAP carries status codes that indicate its processing stage or outcome. These codes are stored in the status record of the IDoc (EDIDS table) and are visible in WE02, WE05, or BD87.
Common Outbound IDoc Status Codes (Direction = 1)
| Status | Meaning |
| 01 | IDoc generated |
| 03 | Data passed to port (successfully sent to middleware or partner) |
| 06 | Error during transmission |
| 12 | IDoc successfully processed (if looped back to SAP) |
Common Inbound IDoc Status Codes (Direction = 2)
| Status | Meaning |
| 64 | IDoc ready to be processed (not yet started) |
| 51 | Error during application processing (e.g., missing material, customer master) |
| 53 | Successfully posted in the application layer |
| 56 | IDoc could not be assigned to a process code |
| 68 | IDoc with errors, no further processing |
Important IDoc Lifecycle Status Flow (Inbound)
IDoc Created (Status 64)
↓
IDoc Processed Successfully → Status 53
↓
Error During Processing → Status 51
Important IDoc Lifecycle Status Flow (Outbound)
Application triggers IDoc → Status 01
↓
IDoc Sent to Port → Status 03
↓
Transmission Failure → Status 06
How to Use Status Codes in Troubleshooting
| Action | Based on Status |
| Reprocess stuck IDoc | If status = 64, use TCode BD87 |
| Check for business errors | If status = 51, go to WE02 or WE05 and read error message |
| Confirm successful transmission | If status = 03 or 53, no issues exist |
| Resolve partner profile issues | If status = 56, check WE20 settings |
TCodes to Monitor and Fix IDoc Statuses
| TCode | Purpose |
| WE02 / WE05 | View IDoc structure and status |
| BD87 | Reprocess IDocs with status 64 or 51 |
| WE19 | Test IDoc manually (simulate) |
| WE20 | Maintain partner profiles |
| WE09 | Search IDocs by content |
12. What is the difference between BAPI and BADI in SAP?
BAPI and BADI are both powerful tools in SAP, but they serve different purposes and are used in different contexts. Understanding the difference is essential for any techno-functional consultant.
What is BAPI (Business Application Programming Interface)?
BAPI is a standardized function module provided by SAP.
Used for data exchange between SAP and external systems, or for programmatic access to SAP functions.
Remote-enabled: Can be called from non-SAP systems (e.g., Java, .NET).
Ensures data integrity by using SAP’s business logic.
Think of BAPIs as “official entry points” to SAP business processes.
Example of BAPI:
BAPI_PO_CREATE1 – Used to create Purchase Orders
BAPI_CUSTOMER_CREATEFROMDATA1 – Create a customer master
BAPI_GOODSMVT_CREATE – Post goods movement
What is BADI (Business Add-In)?
BADI is an object-oriented enhancement technique.
Allows developers to inject custom logic into SAP standard processes.
Used within SAP, not for communication with external systems.
Supports multiple implementations (flexible and reusable).
Think of BADI as a “plug-in point” to enhance or modify standard SAP behavior without changing the code.
Example of BADI:
BADI_MATERIAL_CHECK – Add validation when material is saved
BADI_SD_CUST_HEAD – Enhance sales document header logic
Key Differences Between BAPI and BADI
| Feature | BAPI | BADI |
| Purpose | Access SAP business functions | Enhance SAP standard logic |
| Type | Function Module (RFC-enabled) | Object-Oriented (interface-based) |
| Used By | External systems, ABAP programs | ABAP developers inside SAP |
| Custom Logic | No | Yes (custom implementation) |
| Multiple Usage | One BAPI, one use | Multiple BADI implementations |
| Remote Enabled | Yes | No |
When to Use What?
| Situation | Use |
| Create PO from a mobile app | BAPI_PO_CREATE1 |
| Add a custom check before saving a material | BADI_MATERIAL_CHECK |
| Automate sales order creation via middleware | BAPI_SALESORDER_CREATEFROMDAT2 |
| Add a custom field calculation in invoice logic | BADI_SD_CUST_ITEM |
13. What is the use of transaction code SE11 in SAP?
SE11 is the Data Dictionary (DDIC) transaction in SAP. It’s one of the most powerful tools in SAP for both technical and functional consultants. It allows you to create, view, and manage SAP’s data definitions such as tables, views, data elements, domains, and search helps.
Key Uses of SE11
| Task | Purpose |
| Display or create a table | Standard or custom transparent/pool/cluster tables |
| View table contents | Display table structure, fields, technical settings |
| Create/modify data types | Domains and data elements |
| Build views and joins | Database views, projection views, help views |
| Create search helps | Value help for input fields (F4 help) |
| Analyze technical relationships | See foreign keys, indexes, and dependencies |
SE11 Components
| Component | Description |
| Table | Defines a database table structure (e.g., BKPF, BSEG, MARA) |
| Data Element | Semantic layer (e.g., EBELN – PO number) |
| Domain | Technical properties like data type and length |
| View | Logical view of data from one or more tables |
| Search Help | F4 Help (input help) for user inputs |
| Lock Object | Manages locking mechanism to avoid parallel updates |
Example Use Cases
Functional Consultant:
Want to find the field and table where Payment Terms are stored?
→ Use SE11 to explore LFA1 or BSEG.
Techno-Functional Consultant:
Need to add a new field in a custom Z-table?
→ Use SE11 to enhance structure or create new table.
Workflow Triggering:
Want to check if a field exists to be used in a workflow condition?
→ Use SE11 to validate field types and domains.
Real-Life Scenario
Suppose you want to find out where the Document Type for vendor invoices is stored.
Go to SE11
Open table BKPF
Look for field BLART (Document Type)
Click on Data Element → See Field Label
Click on Domain → Understand its value range or domain fixed values
14. What is the use of transaction code SE18 and SE19 in SAP?
These two TCodes are key tools for implementing Business Add-Ins (BAdIs) — SAP’s modern enhancement framework.
SE18 – BAdI Definition
Used to display or explore the BAdI definition
Lets you see:
Interface name
Methods available
Filters (if any)
Multiple-use options
You do not implement anything here
Think of it as the “blueprint” or “design” of an enhancement spot
Example:
Go to SE18
Enter BAdI name: ME_PROCESS_PO_CUST
You’ll see:
Interface: IF_EX_ME_PROCESS_PO_CUST
Methods like PROCESS_HEADER, PROCESS_ITEM
SE19 – BAdI Implementation
Used to create and manage your own implementations of a BAdI
You write custom code inside the method of a BAdI implementation
You can create:
Single implementation
Multiple implementations (if allowed)
You activate the logic here
Example:
Go to SE19
Create Implementation: ZPO_CUSTOM_LOGIC
Choose ME_PROCESS_PO_CUST
Implement method PROCESS_ITEM
Add code to send email or perform validation
METHOD if_ex_me_process_po_cust~process_item.
DATA: lv_matnr TYPE ekpo-matnr.
lv_matnr = im_item->get_data( )->matnr.
IF lv_matnr IS INITIAL.
MESSAGE ‘Material number cannot be blank’ TYPE ‘E’.
ENDIF.
ENDMETHOD.
Relationship Between SE18 & SE19
| TCode | Purpose |
| SE18 | View/Analyze BAdI definition |
| SE19 | Create/Implement the logic |
Think:
SE18 = Blueprint
SE19 = Builder
Where Used in Projects?
PO/PR validations (ME_PROCESS_PO_CUST)
FI Document posting enhancements (FAGL_DOCUMENT_SPLIT)
Vendor master custom validations (VENDOR_ADD_DATA)
HR Infotype enhancements (HRPAD00INFTY)
BAdI Types You Might See
| Type | Description |
| Classical BAdI | Older enhancement type (single implementation) |
| New BAdI (Enhancement Spot) | Modern object-oriented BAdI (multiple implementations, filter-based) |
| Filter-Dependent BAdI | You can restrict logic based on a filter like company code or country |
15. What is the difference between Classical BAdI and New BAdI (Enhancement Spot)?
SAP provides two main types of BAdIs:
Classical BAdI – older version, limited functionality
New BAdI (Enhancement Spot Framework) – modern, flexible, object-oriented
Both are used to enhance SAP standard behavior without modifying original code.
Key Differences
| Feature | Classical BAdI | New BAdI (Enhancement Spot) |
| Introduced in | SAP 4.6c | SAP NetWeaver 7.0 and higher (ECC 6.0, S/4HANA) |
| Implementation Count | Usually single-use | Allows multiple implementations |
| Filter Option | Not available | Yes (filter-dependent BAdIs) |
| Technology | Uses SE18/SE19, interface-based | Uses Enhancement Spot, class-based |
| Interface | Implemented via custom class | Uses IF_BADI_INTERFACE & enhancement spot |
| Performance | Slightly less optimized | More efficient (SAP kernel-supported dispatching) |
| Multiple-use / Conflict Handling | No conflict resolution | Supports fallback, priority, filters |
| TCode for Definition | SE18 | SE18 |
| TCode for Implementation | SE19 | SE19 (or Enhancement Implementation menu) |
How to Identify a BAdI Type
In SE18, when you open the BAdI:
If you see Interface-based definition → it’s Classical
If you see Enhancement Spot, Implementing Class, Filters → it’s New BAdI
Example Comparison
| Task | Classical BAdI | New BAdI |
| Add custom check to PO | ME_PROCESS_PO_CUST | ME_PROCESS_PO_CUST (converted as new BAdI in S/4HANA) |
| Country-specific logic in invoice | Not possible directly | Use filters for country key (e.g., LAND1) |
Real-Life Use Case for New BAdI
You want to apply different validation rules per company code when a Purchase Order is created.
Use New BAdI ME_PROCESS_PO_CUST
Add filter parameter: BUKRS (company code)
Create separate implementations per company
Each company can now have its own logic, all within the same enhancement spot.
Summary Table
| Aspect | Classical BAdI | New BAdI |
| Multiple Implementation | No | Yes |
| Filters Supported | No | Yes |
| Performance Optimized | Less | More |
| Object-Oriented Design | Partial | Fully |
16. What is a Transport Request in SAP and how does it work?
A Transport Request (TR) in SAP is a package that collects all the changes (customizations or developments) made in the system and transports them from one SAP system to another, usually from Development → Quality → Production.
Why Is It Important?
SAP systems usually follow a 3-system landscape:
Development (DEV) → Quality/Testing (QAS) → Production (PRD)
Changes made in DEV must be transported safely and consistently to other systems without manual rework. This is what Transport Requests are for.
Components of a Transport Request
| Field | Description |
| TR Number | Unique ID like DEVK900123 |
| Owner | User who created the TR |
| Description | Explains the change or object |
| Type | Workbench / Customizing |
| Objects | What’s being transported (e.g., program, table, config, etc.) |
Types of Transport Requests
| Type | Description |
| Workbench Request | For ABAP developments (programs, tables, views) |
| Customizing Request | For configuration settings (SPRO changes) |
| Relocation Request | For transferring objects between packages |
How Does It Work?
Change is made (e.g., Z-report, table config)
System prompts for a transport request (or you create one manually)
Changes are recorded inside the TR
TR is released in DEV using SE09 or SE10
The Basis team imports the TR into QAS → then PRD
How to Create and Manage TRs?
SE09 → Workbench requests
SE10 → Both Workbench & Customizing
SE01 → Transport Organizer (Advanced)
TR Number Format
| Example | Meaning |
| DEVK900123 | DEV = system ID, K = Workbench, 900123 = number |
| DEVC900456 | C = Customizing request |
Release Process (Very Important)
A transport has:
Main Request
One or more Tasks under it
First, you release the tasks
Then you release the main request
The release creates cofiles and data files for migration
Real-Life Example
You created a custom table ZSALES_DATA and a report ZSALES_REPORT.
Both were captured in a Workbench Request.
Once development is complete:
Release it in SE09
Basis imports it to Quality system
After testing, it goes to Production
17. What are Smart Forms and how are they different from SAP Scripts?
Both Smart Forms and SAPScripts are SAP tools used for designing and printing forms (invoices, purchase orders, delivery notes, etc.), but Smart Forms is the more modern and flexible approach.
What is a Smart Form?
Smart Forms:
Are graphical-based tools used to design forms
Allow drag-and-drop elements (text, tables, windows, graphics)
Use Smart Styles for formatting
Generate function modules automatically (which are then called in ABAP)
Key Differences: Smart Forms vs SAP Scripts
| Feature | Smart Forms | SAP Scripts |
| Designer | Graphical (drag-drop) | Script-based (SE71 layout editor) |
| Output Control | Logic & layout in one place | Logic in print program, layout in SE71 |
| Maintenance | Easier (no scripting knowledge needed) | Complex (older interface) |
| Reusability | Uses Smart Styles | Uses Styles & Standard Texts |
| Debugging | Possible using function module | Difficult |
| Performance | Better (generated function modules) | Comparatively slower |
| Print Program Required? | Yes (calls generated FM) | Yes (calls SAPScript form) |
| Translation | Integrated in transaction SMARTFORMS | In transaction SE63 |
How Smart Forms Work
Use SMARTFORMS to design the form (layout + logic)
SAP generates a function module for that form
You call that FM from your print program
Output is generated (PDF/Print)
Example ABAP Call:
DATA: fm_name TYPE rs38l_fnam.
CALL FUNCTION ‘SSF_FUNCTION_MODULE_NAME’
EXPORTING
formname = ‘ZSMART_INVOICE’
IMPORTING
fm_name = fm_name.
CALL FUNCTION fm_name
EXPORTING
control_parameters = ls_ctrl
output_options = ls_out
user_settings = ‘X’
EXCEPTIONS
others = 1.
Real-Life Usage
| Document | Tool Recommended |
| Customer Invoice | Smart Form |
| Purchase Order Print | Smart Form |
| Legacy form | SAPScript (older implementations) |
| Label/Sticker Printing | Smart Form |
TCodes to Remember
| TCode | Purpose |
| SMARTFORMS | Create/Change Smart Form |
| SE71 | Create SAPScript |
| SE78 | Upload Logos |
| SMARTSTYLES | Define Fonts & Styles |
| SE63 | Translations |
18. Explain how you debug an issue that spans across FI and MM modules
In SAP, issues that span across modules like FI (Financial Accounting) and MM (Materials Management) often occur during goods movements, invoice postings, or account determinations. Debugging such cross-functional issues requires a structured approach involving functional flow understanding and technical tools.
Common Scenarios Where FI-MM Overlap
| Scenario | Process Involved |
| Goods Receipt (MIGO) | Triggers accounting document (FI) |
| Invoice Verification (MIRO) | FI document created for vendor liability |
| Price difference or GR/IR clearing | FI adjustments triggered by MM events |
Step-by-Step Debugging Approach
Step 1:
Understand the Business Process
Ask the user: What is the TCode? What is the error message?
Clarify: Is it a posting error? Wrong amount? Missing GL?
Example: “When I post a GR in MIGO, no FI document is created.”
Step 2:
Reproduce the Issue
Try the same transaction in QA/test system using same data (material, vendor, plant, etc.).
Note any error messages, short dumps (ST22), or update terminations (SM13).
Step 3:
Check Configuration First
OBYC settings (TCode: OBYC) – is the correct GL account mapped?
Master data – is the material extended to plant? Valuated? Costed?
Step 4:
Debug the Standard Program
Use /h before executing the action (e.g., in MIGO or MIRO).
Set breakpoints in key function modules or user exits:
| Common FM / Includes | Purpose |
| MB_DOCUMENT_BADI | Custom logic during MM posting |
| MRM_HEADER_CHECK, MRM_ITEM_CHECK | Invoice Verification |
| BAPI_GOODSMVT_CREATE | Used in custom GR BAPI scenarios |
| AC_DOCUMENT_CREATE | Triggering accounting document |
Step 5:
Check IDocs or BAPIs (if interface involved)
If this is via interface/API, check IDoc status in WE02/WE05.
Analyze status 51 messages (e.g., “Account key WRX not maintained”).
Step 6:
Trace Table Updates
Check related tables:
MM side: MKPF, MSEG
FI side: BKPF, BSEG
GR/IR: RBKP, RSEG, BSIM
Compare if MM document is created but FI is missing or inconsistent.
Step 7:
Use Transaction-Specific Logs
MIGO: Go to “Display FI Document” link.
MIRO: Check simulation view before posting.
Use MB5T, MB5S, MB5L for inventory inconsistencies.
Real Example:
A user posts MIRO for a PO, but FI document shows wrong tax.
Debug:
Check condition type in PO (e.g., MWST)
Validate tax code mapping in OB40
Put a breakpoint in MRM_CALCULATE_TAX to see how tax is derived
Check if any custom logic in MRM_ITEM_CHECK modifies tax line
19. What is the role of the functional spec and technical spec in custom development?
In SAP custom development, Functional Specifications (FS) and Technical Specifications (TS) are two critical documents that ensure smooth communication and execution between functional consultants, technical developers, and business users.
They act as a blueprint for building the solution exactly as per the requirement — functionally and technically.
1. What is a Functional Specification (FS)?
Prepared by: Functional Consultant
Purpose: Translates the business requirement into SAP terms with detailed rules and logic (but not code).
Audience: Technical developer, tester, and business approver.
Key Sections in FS:
| Section | Description |
| Business Requirement | What the user wants to achieve |
| Background | Existing process or pain point |
| Input Fields | Data input and sources (e.g., selection screen) |
| Business Logic | Rules to be applied (e.g., totals, filters) |
| Output Requirements | What should be displayed or printed |
| Impacted Transactions | Related TCodes or process flows |
| Validations & Controls | Any mandatory checks or restrictions |
| Test Cases (Optional) | Sample scenarios with data |
Example: FS for Custom Vendor Aging Report
| Section | Details |
| Requirement | Show vendor balances as per aging buckets |
| Input | Vendor No., Company Code, Date Range |
| Logic | Split balances into 30/60/90 days |
| Output | ALV with totals, drilldown to FBL1N |
| Related TCodes | FBL1N, ZVEND_AGING |
| Tables | BSIK, BSAK, LFA1 |
2. What is a Technical Specification (TS)?
Prepared by: Technical (ABAP) Consultant
Purpose: Converts the FS into actual technical steps/code design.
Audience: Developers, reviewers, and testers.
Key Sections in TS:
| Section | Description |
| Program Type | Report, BDC, BAPI, Smartform, Enhancement |
| Table/Field Mapping | Table names, field logic, joins |
| Pseudocode/Logic | Modular logic steps in plain language |
| Error Handling | How errors will be captured |
| Performance Tuning | Use of indexes, select optimizations |
| Security Consideration | Auth checks, data access level |
| Transport Details | Package name, request ID |
| Test Instructions | How to run/test the program |
Example: TS for ZVEND_AGING Report
| Section | Details |
| Tables Used | BSIK, BSAK, LFA1 |
| ALV Type | CL_GUI_ALV_GRID |
| Logic Flow | 1. Fetch open items → 2. Calculate due date → 3. Bucket into 30/60/90 |
| Events | TOP-OF-PAGE, USER_COMMAND for FBL1N drilldown |
| Auth Checks | Company Code & Vendor Number restrictions |
FS vs. TS – Summary Comparison
| Criteria | Functional Spec (FS) | Technical Spec (TS) |
| Written By | Functional Consultant | Technical Consultant (ABAP) |
| Focus | What the system should do | How the system will do it |
| Level | Process-level understanding | Code-level understanding |
| Audience | Business + Developer | Developer + Reviewer |
| Approval Needed By | Business & Dev Lead | Dev Lead & QA |
Best Practice:
Always review FS and get sign-off from the business user before writing TS.
TS must include all technical edge cases, performance handling, and security checks.
Both FS and TS should be stored in a project repository (e.g., Solution Manager, SharePoint).
20. How do you handle missing data in IDoc processing?
In SAP, IDocs (Intermediate Documents) are used for data exchange between systems (SAP ↔ SAP or SAP ↔ non-SAP). Missing data in IDoc processing can lead to failed documents, status 51 errors, and broken integrations. Handling this effectively is key for a techno-functional consultant.
Common Causes of Missing Data in IDocs
| Type of Data | Examples |
| Master Data | Missing customer, vendor, material |
| Configuration | Missing output type, partner profile |
| Transactional Data | Missing delivery number, PO item |
| Mapping Errors | Incorrect segment-field assignment |
| Enhancements | Custom code not populating fields |
Step-by-Step Approach to Handle Missing Data
1️ Monitor the IDoc
Use the following TCodes:
WE02 / WE05 – IDoc list with statuses
BD87 – Reprocess failed IDocs
WE19 – Test tool to simulate/resend IDocs
Check Status Code:
| Status | Meaning |
| 03 | Successfully processed |
| 51 | Error in processing |
| 64 | Ready for processing |
In Status 51, double-click the error message for root cause.
2️ Analyze the Error Message
Common examples:
“Material XXX does not exist” → Missing MM master
“GL account not found in company code” → OBYC/OB41 issue
“Plant XXX not defined” → Org data issue
3️ Compare with a Successful IDoc
Open a working IDoc (WE02) and compare:
Segment structure
Data in segments
Message type and partner profile
Look for:
Empty mandatory fields
Incorrect qualifiers (e.g., in E1EDK01)
Wrong data format (e.g., date YYYYMMDD vs. DD.MM.YYYY)
4️ Check Partner Profile (WE20)
Make sure:
Correct partner type (LS, KU, LI) is used
Message types and processing code are properly defined
Output mode is set (immediate/manual)
5️ Debug the IDoc Processing FM
Use WE19 to simulate the IDoc and /h to set a breakpoint in function module like:
IDOC_INPUT_INVOIC_MRM – Incoming vendor invoice
IDOC_INPUT_DELVRY – Inbound delivery
IDOC_INPUT_ORDERS – Sales Order creation
You can analyze why certain fields are not being filled or processed.
6️ Check Enhancements and User Exits
IDoc processing often includes custom logic in:
User exits (e.g., EXIT_SAPLVEDI_001)
BAdIs (e.g., EDI_DATA_MAPPER)
Z logic in IDoc_INPUT_xxx function modules
If custom logic forgets to populate key fields (e.g., plant, tax code), data will be missing.
7️ Fix and Reprocess
Fixes may include:
Extending missing master data (material/vendor)
Correcting mapping logic
Updating the source system if it’s sending invalid data
Then reprocess via:
BD87 – Restart failed IDoc
WE19 – Resend with corrected data (for testing)
Real Example:
Inbound Order IDoc fails with “Sales Org missing”
Steps:
Open IDoc in WE02 → Check E1EDK14 segment for Sales Org
Found empty field → Mapping missed this value
Update source system mapping → Resend IDoc via WE19
Now, order created successfully (status 03)
21. What is the difference between implicit and explicit enhancements in SAP?
In SAP, enhancements allow developers to inject custom code into standard SAP programs without modifying the original source. Enhancements are classified as Implicit or Explicit based on how and where they are provided.
What is an Explicit Enhancement?
Explicit Enhancements are manually created and explicitly defined in the SAP standard code by SAP itself using special statements like:
ENHANCEMENT-POINT
ENHANCEMENT-SECTION
These act as predefined “hooks” where developers can insert their logic.
Key Features of Explicit Enhancements
| Feature | Details |
| Defined by | SAP (in standard code) |
| Visibility | Clearly marked in code with ENHANCEMENT keywords |
| Tool Used | SE18 / SE80 |
| Flexibility | High – you can either append code or replace entire section |
| Upgrade-Safe? | Yes |
Example:
ENHANCEMENT-POINT Z_MY_ENH_POINT SPOTS ES_SALES_ORDER.
” Custom logic can be implemented here
END-ENHANCEMENT-POINT.
You can implement this enhancement via SE80 or directly in the program editor.
What is an Implicit Enhancement?
Implicit Enhancements are automatically available at certain locations in all ABAP programs, even if SAP didn’t explicitly define them.
They are not marked in the code, but are known system rules that allow enhancements at:
Start and end of every FORM routine
Start and end of every Function Module
Start and end of every Method
Start and end of includes
Key Features of Implicit Enhancements
| Feature | Details |
| Defined by | SAP (system rules, not manually) |
| Visibility | Not shown unless you open “Enhancement Mode” |
| Tool Used | Right-click in SE80 or SE38 (Enhancement Implementation) |
| Flexibility | Limited (only certain positions allowed) |
| Upgrade-Safe? | Yes |
Example:
You open a method in a standard class.
You right-click at the end of the method and choose “Enhancement Implementation → Create Implicit Enhancement”
Your logic runs after the standard method logic
Implicit vs. Explicit Enhancement – Comparison
| Feature | Implicit Enhancement | Explicit Enhancement |
| Defined By | SAP automatically (system-defined points) | SAP developers (with ENHANCEMENT-POINT keyword) |
| Visibility in Code | Not visible unless in enhancement mode | Clearly visible with statements |
| Location Flexibility | Only at start/end of forms, functions, methods | Anywhere SAP defines them |
| Activation Tool | SE80 / Right-click method area | SE80 / Enhancement spot |
| Custom Code Isolation | Yes (separate enhancement implementation) | Yes |
| Risk in Upgrades | Safe | Safe |
Real Use Case:
You want to log additional data whenever a Sales Order is saved.
Use explicit enhancement if there is a ENHANCEMENT-POINT in the SAPMV45A program.
If not available, check for implicit enhancement at the end of method SAVE_DOCUMENT_PREPARE.
Leave a Reply