SAP easy learning

 Semantic groups can be set in DTP in the extraction tab. These are the fields from the source which are available for selection as semantic keys. The BW system while doing the loads will

 In Account receivables , there is a due date on which the outstanding amount has to be paid by the customer. If the due date is passed and the customer has still not paid, the amount becomes overdue and bucket calculation starts

 While loading the data from source to SAP BW system, the amount can be in local currency. If the user wants to see those amounts in USD in the BI reports, you can do the currency conversion either in the BI query designer or while loading the data to the cube. Steps for currency conversion in the data load- There is amount field in the source which is Amount type key figure and there is 0LOC_CURRCY field in source which holds the unit of this amount key figure like EUR or INR etc. Define a target info object say ZAMNT_LC for this field in the BW system with amount type key figure and unit as local currency- Map these objects as one to one from the source Define a new key figure in the target to hold the amounts in USD. Say for example, ZAMNT_USD. Go to tcode RSCUR and create a currency translation type say ZAM_USD- Give a description, go to the Exchange rate tab and give the exchange rate type. ( Exchange rate types are standard exchange rates available in the SAP system. You can see

 The exchange rate in the BW system may not be updated one. Also the business wants to see the amounts according to the exchange rates in the source. In such cases, you have to update the exchange rate in the BW system via process chain. Include the step ‘Execute ABAP Program’ in the process chain. Give the program name as ‘RSIMPCURR’. Create a variant for the program.

 While loading data to a standard DSO, a key figure can be updated as ‘Overwrite’ or ‘Summation’. With an overwrite option, the previous value of the key figure which is already there in the active table of the DSO will be overwritten with the new value. Whereas with the ‘Summation’ option, the values will be

 Navigational attributes are discussed a lot of times in BW. They have an advantage as these attributes can be used for navigation in a query. However there are lot many more advantages of navigational attributes. I will discuss today one such scenario where navigational attributes has saved a week’s time. The Scenario is like this- There are 2 characteristics used in a cube. One characteristic is an attribute of another and both the info objects are included in the cube. Info object           Is Attribute of Country                                Region Region Both country and region are included in the cube as separate characteristics and country is an attribute of Region. Hence the master data of REGION info object will look like below- Region Country North America USA Asia Pacific India Now suppose the fact and dimension tables in the cube store a wrong combination of the region and country value- Customer Region Country Item Revenue Quantity C1 North America USA PC 1000 2 C2 Asia

 The query designer formulas sometimes involve if then else kind of conditions or case statement type of logic. These type of logic can be easily given in the query designer, however the procedure is little tricky as you cannot write simple if statements in the query designer. Scenario – Suppose you have Amount and Net due date characteristics in the cube. The user gives the key date as query input. Based on the difference between the net due date and the key date, the query should return whether the amount is Due (i.e. net due date is in future as compared to key date) or Overdue (i.e. the net due date is passed as compared to key date). The query should also return the bucket information if the amount is overdue. Which means that the query should tell that the overdue amount falls in which bucket (>90, 61-90, 31-60 or 1-30). These buckets are assigned based on the number of days calculated earlier which is the difference between the net due date stored in the cube and the k

 Looking up a table while doing data load is a common scenario in SAP BW. Here the look up table can be active table of some other DSO. You can note a point here that cube cannot be used for look up. This is because, a cube has a fact table which is based on star schema. Hence the primary keys in a fact table will be dimension ids instead of the primary key values. Now coming to our scenario, suppose data is loaded from DSO1 to CUBE1.

 The number of times users have seen the BI reports can be analyzed in BW. All of this information is recorded as BW statistics automatically by the system provided the setting is activated for the targets. The data where the information is stored is the cube 0TCT_C01 [Front-End and OLAP Statistics (Aggregated)]. This cube is SAP standard cube and holds the usage statistics data. This comes under Technical Content info area in BW. The main info objects in the cube and their functions / meanings are summarized below-

  1. Managing Change Control and Transports This blog post addresses standards and guidelines related to changing and transporting objects within the SAP BI landscape.   1.1. General Standards and Guidelines Do not create BW objects and leave them in the $TMP package. If you need to prototype or experiment, you should do so in the Sandbox or Temporary TR created for that purpose. If you cannot use the sandbox, contact your development manager and the BI Platform Health team to discuss options. As you create objects, assign them the proper package (development class) and put them into the correct transport request, based on the standards described below. 1.1.1. Object Grouping and Sequencing Group objects logically, and release transports in the following order to minimize errors:

  1.1.  Querying 1. All queries should be built on multi-providers – even if it is to be built on a single InfoProvider. Multi-providers provide flexibility for the reporting layer.  Additional InfoCubes/DSO’s can be added in the future without much impact to the existing reports built. In cases where data needs to be combined using “joins,” InfoSets can be created. However, multiproviders should still be built on top of InfoSets for reporting. No end user reports should be built directly on InfoCubes, DSO’s or InfoSets. Any reports built directly on InfoCubes/DSO’s should be utilized from an IT perspective for data quality or support inquiries. 2. For reporting, standards will be set as it relates to the information stored within each data warehousing layer. InfoCubes should be used to access summarized information and, DSO’s or additional detailed InfoCubes should be used to access detailed information. Since the data warehousing architecture should include a DSO layer, this det

 This post describes the standard methods and architecture for extracting data from source systems and into the first ­level Data Targets. The preferred extraction method varies depending on the source system technology. The standard extraction methods appear in descending order from most to least desired. Developers must attempt to use the methods at the top of these lists before proceeding down to the less preferred methods.

 This post describes standards for building process chains in SAP BW at any generic development project.   Process Chain Names & Attributes Standards: Process chain technical names should begin with Z or as per your client naming conventions.   Guidelines Descriptions for meta chains (parent process chains that execute sub-­chains) should include “Meta” or “Parent.”   Display Groupings:  Standards Never leave a process chain under the default, “Not Assigned,” Display Grouping. Use the Display Components toolbar button ( ) to assign new process chains to the appropriate display grouping. Refer your client's SAP BW Naming Convention document for Display Grouping technical names Guidelines: If you have a large application composed of multiple logical subsystems, you may create multiple display groupings for your application. Doing so can help you organize your process chains by subsystem. Just make sure the name and description conform to the c

 The standards and guidelines in this post apply to situations where you must move flat files into the BW environment and load them through the BW flat file interface. You may only load from flat files when you absolutely cannot use the BW Service API, the DB Connect interface, or the Universal Data Connect interface to extract data into BW. File Locations on the BW System: As part of your solution implementation, you need to ask the Basis team to create at least one file system directory for your application’s flat files. You should request a folder under the following path; /usr/sap/interfaces/….. NOTE: Refer your client's SAP BW Naming Convention document for the details to follow naming convention. Managing Flat Files in BW Process Chains The BI Technology group has developed four custom process types to help you manage flat files in BW. You can find these process types under “General Services” in the Process Chain Maintenance tool. Their icons and desc

 This post describes best practices for building appropriate secondary indexes on DataStore Objects. General guidelines for placing secondary indexes on DataStore Objects: The presence of secondary indexes on an DataStore Object can greatly improve query performance, but it may slow down load performance. If your application does not have routine, frequent reads or reports on a DataS­tore Object, do not build secondary indexes on it.   Designing Secondary Indexes: Apply these general guidelines when determining the number and structure of secondary indexes on DataStore Objects:

 This post provides guidelines for managing space in the SAP BW Production environment in general. It describes these guidelines in the context of generic business intelligence goals, principles, and architecture.   Principles of Data Warehousing Data Retention: Data warehouses exist to serve as the “information memory” of an enterprise. Data warehouses record all the critical business transactions conducted by an enterprise, so decision makers and business strategists can leverage the information to meet their goals and objectives.   The Value of Historical Information: The business intelligence team must ensure that information captured in the data warehouse supports both the current, known requirements for analyses, but also supports the future, unknown requirements. Low ­level, historical transaction data captures information about past behavior of the enterprise that no other source of information provides. When we delete this data, we eliminate forever the ability of the enterpri

  Write ­Optimized DataStore Objects Consider the following important facts in mind before you choose to use a Write Optimized DataStore Object: The primary unique key to a WODS Object consists of Request ID, Data Packet ID, and Record Number. The system does not use the semantic key as the primary, unique key to the data. This means that each time you load a particular semantic key into a WODS Object, you get a new, unique record. Write ­Optimized DataStore Objects do not aggregate data. If you extract and load two records with the same logical key (or extract and load the same record twice,) both records appear in the WODS Object. No delta detection or extraction function exists for WODS Objects. When forwarding data to subsequent data targets, the system will forward the requests (loads) that have not yet moved to those targets. Note, however, that this can result in duplicate rows going to the subsequent target.   Use as the Enterprise Data Warehouse Layer – First Level Data Acquis

 This post describes generic standards and guidelines that apply to the use of standard BI objects delivered by SAP as part of the BI business content. Again, these may change as per your client's BW system standards. Activating Business Content Anyone with access to the sandbox may activate business content there. If you activate content in sandbox, make sure that you do not activate the content in the background (batch mode.) Instead, activate the content in the foreground and always keep any existing customization for the objects you activate. No one except the people allowed may activate business content in SAP BW development system.   If you need business content activated, contact one of those people and explain what you need activated.

 Both Ranges and Select-Options are used for maintaining Ranges. Select-Options are used for taking input from user on selection screen In case of Select-Options system itself creates an internal table In case of Ranges, the internal table should be defines explicitly The internal table contains four fields- Sign, Option, Low and High . Special operator IN is used in comparisons. SIGN The data type of SIGN is C with Lengh 1. Possible values are I and E. I stands for "inclusive" (operators are not inverted) E stands for "exclusive" (operators are inverted) OPTION The data type of OPTION is C with length 2. OPTION contains the selection operator. The following operators are available: if HIGH is empty, you can use EQ, NE, GT, LE, LT, CP and NP. if HIGH is filled, you can use BT (Between) and NB (Not Between) LOW To maintain lower limit of range. HIGH To maintain higher limit of range. Ex: SELECT-OPTIONS range_ex FOR sy-index. SELECT-OPTIONS matno FOR mara-matnr. RANG

 All the below system fields belong to the data dictionary (DDIC) Structure - SYST . SY-INDEX for loop counting SY-SUBRC condition of previous statement SY-FDPOS position of substring in main string (works with SEARCH) SY-ABCDE a string of 26 characters     SY-ULINE for horizontal lines of any length SY-VLINE for only one vertical character     SY-DATUM for application server's date SY-UZEIT for application server's current time SY-DATLO for Presentation server's date SY-TIMLO for Presentation server's current time     SY-DBSYS backend database name SY-HOST name of application server SY-SYSID name of the R/3 system SY-OPSYS name of application server's operating system     SY-MANDT Logon client number SY-UNAME Logon User name SY-LANGU Logon language     SY-MSGID message class name SY-MSGNO message number SY-MSGTY message type SY-MSGV1 message variable 1 SY-MSG

 These statements define data types or declare data objects which are used by the other statements in a program or routine. Ex: TYPES, DATA, TABLES, CONSTANTS, FIELD-SYMBOLS, PARAMETERS, SELECT-OPTIONS Constants   This keyword is for declaring constant identifiers. CONSTANTS PI TYPE P DECIMALS 3 VALUE '3.147'. Constants cannot be modified in the further program. Field-Symbols These are similar to pointers in C language. Used for referring to any type of data object in a program. FIELD-SYMBOLS: <FS1>, <FS2>. DATA:  A TYPE I, str(20) TYPE C. ASSIGN  A TO <FS1>. WRITE <FS1>.    //Value of A will be displayed ASSIGN STR TO <FS1>. WRITE <FS1>.   //Value of STR will be displayed. Types  This keyword is used to define new user defined data types. TYPES FLOATING TYPE P DECIMALS 6. DATA A TYPE FLOATING. DATA B TYPE FLOATING. Tables This keyword is used to create a structure in RAM corresponding to a database table. TABLES: mara, vbrk. Type-Pools Th

  Report Name Description Comments Lane Deficiency Report Report points out actual transit times per lane and compares it against transit tables in source system such as R3 where transportation details are stored   Deployment Scorecard Measures lane cost, mode cost, line haul costs, load factor, mode mix, short lead %, - Weekly, monthly &  yearly view. Data from the Freight Cost Detail & Accrual Tables in the source Freight Scorecard monthly/yearly network resupply orders.  Measures linehaul, fuel, accessories and volume against AOP and then illustrates the cost variance & impact Data from the Freight Cost Detail & Accrual Tables in the source Delivery Scorecard monthly/yearly network sales orders.  Measures linehaul, fuel, accessories and volume against AOP and then illustrates the cost variance & impact Data from the Freight Cost Detail & Accrual Tables in the source On Time Delivery Summary Report / Carrier Scorecard Measures on t

 Below are some of the common and handy commands for manipulating strings in ABAP. CONCATENATE To join multiple strings together into one string. DATA u(10) TYPE C VALUE 'Rust'. DATA v(10) TYPE C VALUE 'Iron'. DATA w(10) TYPE C VALUE 'Brown'. DATA str(30) TYPE  C. CONCATENATE u v w INTO str. CONCATENATE u v w INTO str SEPARATED BY '***'. SPLIT To separate a given string into multiple sub strings DATA str(30) TYPE C VALUE 'Rust Iron Brown'. DATA: u(10) TYPE C,               v(10) TYPE C,                w(10) TYPE C. SPLIT str AT ',' INTO u v w. WRITE: / u,        / v,        / w. TRANSLATE To convert a given string from one form to another form TRANSLATE str TO LOWER CASE. TRANSLATE str TO UPPER CASE. TRANSLATE str USING 'AXBY'. in the above example, all occurrences of A in str are replaced by X and B in str are replaced by Y. SEARCH to search for substring in a main string. SEARCH str for 'AD'.  // it is not

  Some Important Function Modules RANDOM_I4 FITRV_CALCULATOR HR_99S_MONTHS_BETWEEN_DATES MONTHS_BETWEEN_TWO_DATES RH_GET_DATE_DAYNAME DATE_GET_WEEK SPELL_AMOUNT F4_DATE F4_CLOCK F4_FILENAME Function Modules SE37 is the transaction code for creating function modules. A function module name has a practical minimum length of three characters and a maximum length of 30 characters Customer function modules must begin with Y_ or Z_ The name of each function module is unique within the entire BW system Function modules have a special screen used for defining parameters. Parameters are not defined via ABAP/4 statements. Leaving a function module is accompanied via the RAISE statement instead of check , exit or stop . Every function module should be assigned to a Function group. Function Group is to group all logically related Function Modules. Function Groups As stated before, a function group is a program that contains function modules. With each R/3 system, SAP supplies more than 5000 pre-e

 The SAP ECC system has some important standard tables which are used frequently for storing data and hence looked up for BW extraction. Below post lists some of them and provide a good understanding to a BW developer working on ECC extraction: MARA (General Material Data) FIELD              TYPE           LENGTH             DESCRIPTION MATNR          CHAR            18                        MATERIAL NUMBER MBRSH         CHAR             1                           INDUSTRY SECTOR MTART          CHAR             4                          MATERIAL TYPE MEINS           CHAR             3                           UNIT OF MEASUREMENT   MAKT (Material Descriptions) FIELD        TYPE            LENGTH      DESCRIPTION MATNR     CHAR           18                  MATERIAL NUMBER SPRAS        LANG          1                     LANGUAGE KEY MAKTX      CHAR           40                 MATERIAL DESCRIPTION   MARC (Plant data for Material) FIELD              TYPE             LENGTH        DES

  In BW related ABAP, you work mainly with tables. Tables are the essential data structures in the database system. Besides database tables, you can create internal tables which exist only during the runtime of your program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. The number of lines in an internal table is not fixed. Depending on requirements, the system  increases the size of internal tables at runtime. The data is stored on a row-by-row basis, where each row has the same structure. It has two different parts. Header Line (optional) and Body (Compulsory). Any value that comes to or goes from internal table, that travels through header line. The internal table with header lines are now obsolete. You can create explicit work area The statements for the access to individual rows

  Processing an Internal table To perform an operation on each and every record of an internal table LOOP AT <itab>.          Each record will be transferred to Implicit Header Line : : ENDLOOP. LOOP AT <itab> INTO <wa>. Each record will be transferred to an Explicit Header Line : : ENDLOOP. LOOP AT <itab> INTO <wa> FROM n1 TO n2.          to process a range of records : ENDLOOP. Inserting Lines into Tables Adding records either at the end or at the specified position. If index is not specified records will be added at the end of the table. To add a line to an internal table INSERT <line> INTO TABLE <itab> INDEX n. INTO addition is not required if inserting is done through implicit header line. To add several lines to an internal table. INSERT LINES OF <itab1> [FROM <n1>] [TO <n2>] INTO TABLE <itab2>. Appending Lines to Tables Adding records at the end of the table

 A data dictionary in computing terms is the source of information in which the system data is defined in a logical way. The data dictionary is the centralized and structured source of information for business applications. The ABAP data dictionary (DDIC) can be seen as a logical representation or a superior layer over the physical underlying database. The elements that make up a DDIC are known as metadata . Metadata is the computing term for the data whose function is to describe other data. An advantage of having a DDIC is avoiding inconsistencies when defining data types that will later be used in different parts of an application; this avoids redundancies and considerably decreases the cost of maintenance. When a type of data is defined in DDIC, it is available to any program or function module in the application. A change in the definition of a type of data in the DDIC automatically affects any other data, module, function, or program which has data or variables defined using the

  Client-dependent and client-independent table in ABAP In SAP, highest level of organization structure is client. Whenever we login to SAP system, we login to a specific client. Data in the R/3 system is categorized as client dependent and client-independent. Client dependent table: Client dependent tables are always client-specific. These cannot be accessed from any other client.. First column of any client-dependent table is always client (type MANDT) by default and it's a primary key, this field contains the client no. A client-dependent table may have different dataset for different clients. Client independent table: Client-independent table are cross-client i.e. independent of any client, so accessible from any other client and changes made in this table under one client, will be reflected in all the other clients. Hence, a client-independent table will always have same dataset for all clients. Identifying the client dependent and independent tables: Open the table DD02L in

  ABAP report program's structure Report Statement. Macro Definitions. Data Objects's Declarations. Selection-Screen Designing Statements. Selection-Screen Events. Main Program Events. List Screen Events. Subroutine Definitions. Most of the above sections are optional. REPORT keyword and Main program logic are mandatory. Data Types These are built-in types of SAP-ABAP language. DATA keyword and these Data Types together are  used to declare Data Objects. Data Objects are simply variables which represent Memory Locations in Application Server's temporary memory RAM. Type I Integer type for Integer numbers. Example: DATA var_num TYPE I. Creates a variable var_num with initial value 0. DATA var_num TYPE I value 45. Creates a variable var_num with initial value 45. Type F Floating point type for Floating point (Fractional) numbers. Example: DATA var_num TYPE F. creates a variable var_num with initial value 0.0 DATA var_num TYPE F VALUE '45.723'. creates a variable va

 Operators are symbols used to perform some operations on Data Objects. In ABAP language, at least one SPACE must be provided in both sides of every operator. Arithmetic Operators                   Statements also can be used instead of operators Relational Operators These are for comparing the item. Their result is always either True or False . =, <>, <,  >, <=, >= or their equivalents EQ, NE, LT, GT, LE, GE and a special operator BETWEEN AND for range checking Example: 5 < 3         is false. 5 GT 3      is True. 5 = 5         is True.                   Logical Operators For combining two or more conditions into a single condition. AND      OR       NOT   String Comparison Operators CO      Contains Only CA      Contains any CS       Contains String CP      Suits Pattern wildcard characters '*' stands for no. of chars '+' denotes any character They are usually used along with IF statement. Ex. IF 'ABAP' CO 'AB'.   //Condition is

 To execute different program parts in connection with certain conditions or to combine recurring statement sequences as  loops, you can use standard keywords like IF, CASE, DO, and WHILE in the flow control of a program. IF condition. ...... ELSE. ...... ENDIF. IF condition-1. ...... ELSEIF condition-2. ..... ELSEIF condition-3. ..... ELSEIF condition-n. .... ELSE. ENDIF. CASE variable. WHEN value-1. ..... WHEN value-2. ..... WHEN value-3. ..... WHEN OTHERS. ..... ENDCASE. DO n TIMES.   statement_block. ENDDO. WHILE log_exp.    statement_block. ENDWHILE. Statements which can be used optionally in loops... EXIT.                to come out of a loop suddenly CONTINUE.   to start the next iteration from middle of the loop CHECK.           to start the next iteration when condition fails.

 When library functions are used in calculations, at least one SPACE must be provided after the 1st bracket and before the last bracket of the function. Example: K = SQRT (16).       Now K contains a value 4 P = trunc( '34.567').    Now P contains a value 34    

 The ABAP Programming language allows you to concatenate consecutive statements with an identical left part into a chain statement. Chain statement: WRITE: spfli-cityfrom, spfli-cityto, spfli-airpto. Statement Sequence: WRITE spfli-cityfrom. WRITE spfli-cityto. WRITE spfli-airpto. You could for example, write the same statement like this: WRITE: spfli-cityfrom,        spfli-cityto,        spfli-airpto. Statement Sequence: sum = sum + 1. sum = sum + 2. sum = sum + 3. sum = sum + 4. Chain Statement: sum = sum + : 1, 2, 3, 4.  

  Parameters keyword allows the user to provide values for variables through the input screen. The input screen can be generated by the keywords Parameters or Select-options. Technically input screen is known as Selection Screen. It's screen number is standard and is 1000 . Ex. PARAMETERS A TYPE I. PARAMETERS file_name(40) TYPE C DEFAULT 'c:sample.txt'. The data types F(Float), STRING and XSTRING are not allowed with parameters. Parameters keyword can be used to generate Check boxes and Radio buttons on the selection screen.

  Domains A domain provided Technical attributes (type, length and possible values) for a field. The definition of domain in ABAP is same as that in Mathematics. In the world of Mathematics, a domain is defined as the set of input values that are valid for a given function. The same holds true for domains in ABAP. To understand this, let us first see what is the role of domains in ABAP data dictionary. Domains -> Data Elements -> (Structures, DB tables, program references etc.)

  Table Types Table types are type definitions for Internal tables. By using them you can declare internal tables in your program. Creating a table type Go to SE11, select Data type Radio button, provide a name for table type, and click Create button. Ex. ZTSCARR Select Table type radio button and click Continue. In the maintenance screen provide short text Provide an existing DDIC structure name as line type. Ex. SCARR under the tab initialization and access select the type of the internal table. Usually we create Standard tables. Finally Save and activate. In the future programs internal tables without header line can be created using this table type. Ex. DATA it_data TYPE ZTSCARR. Type Groups Type group is a DDIC object which is a collection of user defined Data types and constants. Creating a type group Go to SE11, select Type Group radio button and provide a name for it. Ex. ZBRSL, and click on Create button. In the maintenance screen, provide short text and start creating your

 VIEW is a DDIC object. It is used to join several tables to extract data from them with a common field relation. A view is a pseudo table which doesn't occupy any space in the database. It is stored in database as a PL/SQL statement. There are FOUR types of views. Database Views Projection View Maintenance View Help View We rarely create views. In some situations we create only database views. Instead of views we can use SELECT statements with JOINS  in the program itself. Database View

  OPEN SQL commands that are used on database tables are SELECT INSERT UPDATE MODIFY DELETE COMMIT WORK SELECT is used for getting records from dbtable. SELECT.... ENDSELECT. SELECT....  FROM TABLE INTO ITAB.

 TABLES SCARR. UPDATE SCARR. SET CARRNAME = 'india' WHERE CARRID = 'MP'. IF SY-SUBRC = 0. MESSAGE 'record is updated successfully' TYPE I. ELSE. MESSAGE 'record is not updated' TYPE 'I'. ENDIF.

 ******************************************* **displaying Raw Materials and Finished products **only from MARA table. DATA WA TYPE MARA. * **--WHERE clause is for filtering the records SELECT * FROM MARA INTO WA WHERE MTART = 'ROH' OR MTART = 'FERT'. WRITE: / WA-MATNR, WA-MBRSH, WA-MTART, WA-MEINS. ENDSELECT. * **************************************************

 *=================================================== *Filtering the fields *displaying 2 fields data from SCARR table (Airlines) *with the help of two individual variables *by declaring them with built-in-data types *==================================================== DATA CIDN(3) TYPE C. DATA CNAME(20) TYPE C. SELECT CARRID CARRNAME INTO (CID, CNAME) FROM SCARR. WRITE:/ CID, CNAME. ENDSELECT. ******************************************************* *displaying 2 fields data from SCARR table (Airlines) *with the help of two individual variables *by declaring them with DB Table field References DATA CIDN TYPE SCARR-CARRID. DATA CNAME TYPE SCARR-CARRNAME. SELECT CARRID CARRNAME INTO (CIDN, CNAME) FROM SCARR. WRITE:/ CIDN, CNAME. ENDSELECT.

 REPORT. *=============================================== *NUMBER_OF_DAYS_PER_MONTH_GET *This function module gives number of days in a given month of given year *=============================================== DATA DAY1 TYPE T009B-BUTAG. CALL FUNCTION 'NUMBER_OF_DAYS_PER_MONTH_GET' EXPORTING PAR_MONTH = '02' PAR_YEAR = '2012' IMPORTING PAR_DAYS = DAY1.   "Datatypes of parameters must match each other WRITE DAY1.

 *============================================================= *SPELL_AMOUNT *This function module converts amount into English words *============================================================= DATA WORDS1 TYPE SPELL. CALL FUNCTION 'SPELL_AMOUNT' EXPORTING AMOUNT = 679340232 IMPORTING IN_WORDS = WORDS1.  * WORDS1 is a structure with some components WRITE:/ WORDS1-WORD.

 BAPI stands for Business Application Programming Interface. These are remote enabled function modules (RFCs). BAPIs are used to Integrate SAP systems with Non-SAP systems These FM names start with BAPI_   *======================================================== *BAPI_COMPANYCODE_GETDETAIL *This function module gives address details of a company code *======================================================== DATA ADDRS1 TYPE BAPI0002_3. CALL FUNCTION 'BAPI_COMPANYCODE_GETDETAIL' EXPORTING COMPANYCODEID  = '1000' IMPORTING COMPANYCODE_ADDRESS = ADDRS1. WRITE/: ADDRS1-NAME, ADDRS1-STREET, ADDRS1-CITY, ADDRS1-COUNTRY. *================================================================ *BAPI_SALESORDER_GETLIST *This function module gives list of Sales orders in the form of an internal table *================================================================ DATA ORD TYPE BAPIORDERS. DATA INT_TAB TYPE TABLE OF BAPIORDERS. PARAMETERS PAR_CUST TYPE C LENGTH

 Below is the program in ABAP to prepare a question paper with 20 questions on Arithmetic operations on two numbers. The program will generate numbers and arithmetic operations randomly. The program will save these random questions in a .txt file on the local system. REPORT. *--Structure type TYPES: BEGIN OF TYP_NUM, N1 TYPE I, OP TYPE C, N2 TYPE I, CH TYPE C, END OF TYP_NUM. DATA OPT TYPE I. DATA WA TYPE TYP_NUM. DATA ITAB TYPE TABLE OF TYP_NUM. DO 20 TIMES. CALL FUNCTION 'RANDOM_I4' EXPORTING RND_MIN = 10 RND_MAX = 90 IMPORTING RND_VALUE = WA-N1. CALL FUNCTION 'RANDOM_I4' EXPORTING RND_MIN = 10 RND_MAX = 90 IMPORTING RND_VALUE = WA-N2. CALL FUNCTION 'RANDOM_I4' EXPORTING RND_MIN = 1 RND_MAX = 4 IMPORTING RND_VALUE = OPT. CASE OPT. WHEN 1. WA-OP = '+'. WHEN 2. WA-OP = '-'. WHEN 3. WA-OP = 'x'. WHEN 4. WA-OP = '/'. ENDCASE. WA-CH = '='. APPEND WA TO ITAB. CLEAR WA. ENDDO. CALL FU

 REPORT. *--Attaching type group to program TYPE-POOLS KCDE. *--Structure type TYPES: BEGIN OF TY-STD, RONO TYPE C LENGTH 4, NAME1 TYPE C LENGTH 20, GEN TYPE C LENGTH 6, FEES TYPE C LENGTH 10, END OF TY_STD. *--Header line and Internal table DATA WKA TYPE TY_STD. DATA ITABLE TYPE TABLE OF TY_STD. *--Header line and internal table for CSV data DATA IS_CSV TYPE LINE OF KCDE_INTERN. DATA IT_CSV TYPE KCDE_INTERN. *--Application server files are known as "Datasets" *--here "fname" is the Dataset DATA FNAME TYPE C LENGTH 40 VALUE 'StudentsInfo.txt'. *--Convert CSV flat file data into internal table CALL FUNCTION 'KCD_CSV_FILE_TO_INTERN_CONVERT' EXPORTING I_FILENAME = 'C:\Documents and Settings\Administrator\Desktop\Students.csv' I_SEPARATOR = ',' TABLES E_INTERN = IT_CSV. LOOP AT IT_CSV INTO IS_CSV. CASE IS_CSV-COL. WHEN 1. WA-RONO = IS_CSV-VALUE. WHEN 2. WA-NAME1 = IS_CSV-VALUE. WHEN 3. WA-GEN = IS_CSV-VALUE

 *--Attaching type group to the program TYPE-POOLS TRUXS. *--Structure Type TYPES: BEGIN OF TY_STD, RONO TYPE C LENGTH 4, NAME1 TYPE C LENGTH 20, GEN TYPE C LENGTH 6, FEES TYPE C LENGTH 10, END OF TY_STD. *--Header line and internal table DATA WA TYPE TY_STD. DATA ITAB TYPE TABLE OF TY_STD. *--Dummy Internal table for Function module purpose DATA IT_RAW TYPE TRUXS_T_TEXT_DATA. *--Application Server files are known as "Datasets" *--here "fname" is the Dataset DATA FNAME TYPE C LENGHT 40 VALUE 'Students.txt'. *--Convert Excel flat file data into Internal table CALL FUNCTION 'TEXT_CONVERT_XLS_TO_SAP' EXPORTING I_TAB RAW DATA = IT_RAW I_FILENAME = 'C:Documents and SettingsAdministratorDesktopstudents.xls' TABLES I_TAB_CONVERTED_DATA = ITAB. *--Sending data to Application Server OPEN DATASET FNAME FOR OUTPUT IN TEXT MODE ENCODING DEFAULT. LOOP AT ITAB INTO WA. TRANSFER WA TO FNAME. ENDLOOP. CLOSE DATASET FNAME.

 *--Structure type TYPES: BEGIN OF TY_STD, RONO TYPE C LENGTH 4, NAME1 TYPE C LENGTH 20, GEN TYPE C LENGTH 6, FEES TYPE C LENGTH 10. END OF TY_STD. *--Header line and internal table DATA WKA TYPE TY_STD. DATA INT_TAB TYPE TABLE OF TY_STD. *--Application server files are known as "Datasets" *--here "fname" is the Dataset DATA FNAME TYPE C LENGTH 40 VALUE "StudentsInfo.txt". *--Convert notepad file data into internal table CALL FUNCTION 'GUI_UPLOAD' EXPORTING FILENAME = 'C:Documents and SettingsAdministratorDesktopstudents.txt' HAS FIELD_SEPARATOR = 'X' TABLES DATA_TAB = INT_TAB. *--Sending data to Application Server OPEN DATASET FNAME FOR OUTPUT IN TEXT MODE ENCODING DEFAULT. LOOP AT INT_TAB INTO WKA. TRANSFER WKA TO FNAME. ENDLOOP. CLOSE DATASET FNAME.

 This post describes the procedure to look up a custom table in bw transformation. The business scenario can be calculation of certain key figures based on the entries in the table. This table can be custom table i.e. created by the user or any standard table too. The first step for doing a look up is to store all the table entries or selected table entries in a global internal table.

 We can write a program in the infopackage in BW to pick up a certain file based on its name from the application server and load it. This is required if there are multiple files in the same folder and only a certain file needs to be loaded out of those. Suppose we have a scenario like this: Business uploads the files for multiple sales division in a folder in the application server -  /usr/SAP/DEV/Reports/target_sales.csv.