Re: Difference between conversion and interface

Posted: Feb 26, 2008 8:38 PM in response to: chaithu yeduguru

E-m this me

Interface: it is a program that performs communication with External system from SAP. There are two types of interfaces: 1. Inbound Interface: External system sends the data to SAP 2. Outbound Interface: SAP sends the data to External system.

Let's take a scenario: There are two Systems SAP ERP and Seibel CRM Scenario1: Whenever an Order is created in Seibel CRM system it has to be transferred to SAP where the Order confir and Billing will be performed. This can be enabled by using IDOC as inbound interface.

Scenario2: Whenever a New customer is Created in SAP ERP this customer data has to be transferred to Seibel CRM IDOC / RFC. Basically interfaces are implemented using RFC, BAPI, ALE/IDOC.

INTERFACE programs are the ones which are run at regular intervals, say weekly, monthly or even daily. Here the lega continues to co-exist along with SAP system, the legacy system might be useful for certain functionalities but the data m thru SAP transactions for complex data maintenance at regular intervals. Interface Program Conversion: Migration of data from Legacy system before GO Live (One time data transfer). So Conversions are always INBOUND interfaces. Conversions are performed using Batch input(BDC), LSMW and BAPI.

CONVERSION programs are the ones which have one time usage, usually when a legacy system is being replaced by SAP, then the data has to be mapped from the legacy system to SAP system. Here the data to be converted is given on uploaded to SAP tables mostly using LSMW only. Conversions programs are BDC,BAPI and LSMW programs in which related tables from the flat files.Those are one time programs.

Interface programs are those programs in which you fetch the data from the application server and process on theose d helpful when you have to run any program in the backgroup when the presentation server is not working. Conversion Program In Simple CONVERSIONS : Converting Legacy System DATA into a flat file INTERFACES : Converting Flat File into SAP Regards, Chandru

Re: difference between AT NEW and ON CHANGE
Posted: Mar 13, 2008 10:48 AM in response to: bindu hima

E-mail this message


Hi, When we use At new for a field, it will trigger whenever there is any change in al lthe fields from the left to that of the particular field. But when we use On change of it triggers only when there is any change in the particular field. At new can only be used inside loop. On change of can used outside the loop. No logical Expressions can be added with at new. Logical expressions like AND OR can be used with on change of. When AT NEW occurs, the alpha-numeric fields have * in their value,where as in case of On Change, the alphanumeric fields have their Corresponding value, of that particular record, where the Event gets fired. On Change of executes for the first value of field too, this is not the case with At New. On change of cannot be used in ABAP objects At new can be used in this. Reward if helpful. Regards, Ramya Re: difference between rfc & bapi
Posted: Mar 25, 2008 4:53 PM response to: jyothi nutakki in E-mail this message Reply

BAPI stands for Business Application Program Interface & RFC stands for Remote Function Call Major difference betwen Bapi and RFC is that BAPIS are use for communication between SAP and Non SAP system whereas RFCs are used for communicating within sap system only.. A BAPI is remotely enabled function module ie it can be invoked from remote programs like standalone JAVA programs, web interface etc.. You can make your function module remotely enabled in attributes of Function module but BAPI are standard SAP function modules provided by SAP for remote access. BAPI are RFC enabled function modules. the difference between RFc and BAPI are business objects.You create business objects and those are then registered in your BOR (Business Object Repository) which can be accessed outside the SAP system by using some other applications (Non-SAP) .

Re: difference between type and like
Posted: Apr 7, 2008 12:38 PM in response to: abap spider

E-mail this message


Hi, Type is used to refer an built in data type. EG: Types: value type c. Like is used to refer data objects. EG: data: value1 like value. Reward if helpful Re: Tcode for table maintenance generator
E-mail this message Reply

Posted: Mar 14, 2008 11:37 AM in response to: Harshu Madap

Below steps to create Table Maintenance generator. 1) go to se11 check table maintanance check box under attributes tab 2) utilities-table maintanance Generator-> create function group and assign it under function group input box. also assign authorization group default &NC& . 3) select standard recording routine radio in table table mainitainence generator to move table contents to quality and production by assigning it to request. 4) select maintaience type as single step. 5) maintainence screen as system generated numbers this dialog box appears when you click on create button 6) save and activate table One step, two step in Table Maintenance Generator Single step: Only overview screen is created i.e. the Table Maintenance Program will have only one screen where you can add, delete or edit records. Two step: Two screens namely the overview screen and Single screen are created. The user can see the key fields in the first screen and can further go on to edit further details. Creating a T-code of that. Go to se93. Then create the new T.code. Under that select parameter Transaction.

Then give the sm30 in the t.code in default values tab. Check the checkbox skip initial screen in classification tab. Click checkbox inherit gui attributes.. Now below.. In the default values.. WRITE viewname = give ur table name. show = X save and check it once... Now u can able to call ur table through ur new t.code... Hope this helps. Regards Vinayak

1.Why are SAPscripts client-dependent and Smart Forms client-independent? QUESTION POSED ON: 27 MAY 2006 QUESTION ANSWERED BY: Mark Smithson SAPscript technology is based on a mainframe product from the 1980s, while Smart Forms have only been around since (roughly) 2001. With that sort of time gap, there are bound to be significant differences between the two tools. As you have noted correctly, client dependence is a fundamental one.
Although SAPscript has had some incremental improvements over time, its forms have always been -- under the hood -- relatively passive objects, with minimal embedded logic. These forms were designed to be driven and controlled by ABAP programs, much in the way ABAP programs read in database tables to produce reports; if you ever download a SAPscript form (e.g., via utility program RSTXSCRP), and look at the portable text file it produces you'll see what I mean. Many text objects (e.g., invoice header texts) are bound directly to documents which are clientdependent, so it makes sense for these text objects to also be client-dependent. From a complexity standpoint, SAPscript forms are close enough to these text objects where I can see how it made sense at the time to make them client-dependent too. Conversely, a Smart Form is significantly more robust and complex. For instance, it can contain program nodes and nested tables with patterns. When a Smart Form is compiled, it generates an ABAP function module – and these are always client-independent. This is appropriate, given that this form has more in common with an ABAP program than its predecessor. For instance, when a print program calls a Smart Form, the form itself takes over to produce output, without any further direction from the print program. In fact, the join is so seamless that I often find myself using a Smart Form's Initialization section for logic to handle any data gathering not handled by the print program. I would never even think to attempt this with SAPscript. I suspect several factors figured into SAP's decision to make Smart Forms client-independent, including customer feedback. There are significant advantages to client-independence. For instance, a change made in one development client happens immediately across all development

clients. Among other things, this means we don't have to waste time figuring which client contains the most recent version -- they all do! In addition, transporting Smart Forms is easier, since we can safely bundle them together in the same transport as their client-independent print programs (no worry about mixing client-dependent and independent objects). 2. difference between the versions of 4.7 and ecc5 n ecc6. The basic difference is Java. 4.7EE works on ABAP, where as ECC6.0 works JAVA+ABAP SAP ECC is part of the SAP ERP application (actually it is the minimal installation of SAP ERP). SAP ERP runs on SAP NetWeaver. So when you get SAP ERP you get SAP NetWeaver. - SAP ECC 5.0 is part of SAP ERP 2004 Which runs on SAP NetWeaver 04 - SAP ECC 6.0 is part of SAP ERP 6.0 (2005)Which runs on SAP NetWeaver 7.0 (2004s) 4.7 is three tier architecture but ecc 5 and 6 is n-tier architecture.

E071 – Table for transport requests for the objects LSMW - it would not ask for the TR. Just we need to import and export mechanism
1. Run Tcode LSMW in source system. 2. in the menu bar choose Extras-->Export. Now give the filename and save in your desktop. 3. Now login to destination system. again execute LSMW. 4. Now goto Extras-->Import.Give your file which was downloaded earlier. 5. Now tool bar click on import with diffrent name option and give your new project and subprojectname. 6. Now execute all steps. Or else The "cleaner" way is using normal transport procedure via "Extras->Generate Change Request". This will transport the entire project though, not possible to transport a single object this way.

For smart forms version comparison is not possible.
How to move the test variant? Run the program RSTRANSP and give the name of the program and the variant name. It will create a transport request for the variant. the rest of the process is the same as is the case with all other transport requests.

ABAP Questions: As on 30/11/07:
1) If any problems are on the values like decimals rounded values, truncated values. Once check in Program: Attributes  Fixed Point Arithmetic Check box. If it is not checked, check and verify the program output. 2) For any newly created Form routines in the already existed programs, must be update the navigation index for those form routines. Path for updating: Program: Utilities  Update Navigation Index 3) To add new buttons to standard ALV List in our programs, this is the procedure to follow: 1. Copy the standard PF STATUS from the std program: SAPLKKBL and status: STANDARD_FULLSCREEN in to our program. 2. And then pass this PF STATUS to function module: REUSE_ALV_GRID_DISPLAY. Ex code as follows:
REPORT zptest1. TYPE-POOLS : slis. DATA: t_fieldcat TYPE slis_t_fieldcat_alv, wa_fieldcat LIKE LINE OF t_fieldcat, "Field catalog t_eventcat TYPE slis_t_event. DATA: t_vbap TYPE TABLE OF vbap, wa_vbap TYPE vbap. DATA: l_repid TYPE sy-repid. SELECT-OPTIONS: s_vbeln FOR wa_vbap-vbeln. SELECT mandt vbeln posnr FROM vbap INTO TABLE t_vbap WHERE vbeln IN s_vbeln. IF sy-subrc = 0. SORT t_vbap BY vbeln posnr. ENDIF. wa_fieldcat-col_pos = '1'. wa_fieldcat-fieldname = 'VBELN'. wa_fieldcat-seltext_l = 'SONo'. wa_fieldcat-outputlen = 10. APPEND wa_fieldcat TO t_fieldcat . CLEAR wa_fieldcat. wa_fieldcat-col_pos = '2'. wa_fieldcat-fieldname = 'POSNR'. wa_fieldcat-seltext_l = 'Itm'. wa_fieldcat-outputlen = 6. APPEND wa_fieldcat TO t_fieldcat . CLEAR wa_fieldcat.

CALL FUNCTION 'REUSE_ALV_EVENTS_GET' EXPORTING i_list_type = 0 IMPORTING et_events = t_eventcat. l_repid = sy-repid. CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' EXPORTING * I_INTERFACE_CHECK ='' * I_BYPASSING_BUFFER = * I_BUFFER_ACTIVE ='' i_callback_program = l_repid i_callback_pf_status_set = 'SET_PF_STATUS' i_callback_user_command = 'USER_COMMAND' * I_CALLBACK_TOP_OF_PAGE ='' * I_CALLBACK_HTML_TOP_OF_PAGE ='' * I_CALLBACK_HTML_END_OF_LIST ='' * I_STRUCTURE_NAME = * I_BACKGROUND_ID ='' * I_GRID_TITLE = * I_GRID_SETTINGS = * IS_LAYOUT = it_fieldcat = t_fieldcat * IT_EXCLUDING = * IT_SPECIAL_GROUPS = * IT_SORT = * IT_FILTER = * IS_SEL_HIDE = * I_DEFAULT = 'X' * I_SAVE ='' * IS_VARIANT = it_events = t_eventcat * IT_EVENT_EXIT = * IS_PRINT = * IS_REPREP_ID = * I_SCREEN_START_COLUMN =0 * I_SCREEN_START_LINE =0 * I_SCREEN_END_COLUMN =0 * I_SCREEN_END_LINE =0 * IT_ALV_GRAPHICS = * IT_ADD_FIELDCAT = * IT_HYPERLINK = * IMPORTING * E_EXIT_CAUSED_BY_CALLER = * ES_EXIT_CAUSED_BY_USER = TABLES t_outtab = t_vbap * EXCEPTIONS * PROGRAM_ERROR =1 * OTHERS =2 . IF sy-subrc <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. *---------------------------------------------------------------------* * FORM SET_PF_STATUS *---------------------------------------------------------------------* *

* ........ * *---------------------------------------------------------------------* * --> PT_EXTAB * *---------------------------------------------------------------------* FORM set_pf_status USING pt_extab TYPE slis_t_extab. SET PF-STATUS 'STANDARD_FULLSCREEN1'. ENDFORM. *---------------------------------------------------------------------* * FORM user_command * *---------------------------------------------------------------------* * ........ * *---------------------------------------------------------------------* * --> P_UCOMM * *---------------------------------------------------------------------* FORM user_command USING p_ucomm LIKE sy-ucomm l_selfield TYPE slis_selfield. IF sy-ucomm = 'EIFF'. * l_selfield-refresh = 'X'. REFRESH t_vbap. CALL TRANSACTION 'VA03' AND SKIP FIRST SCREEN. " USING t_vbap. WRITE: / 'List'. LEAVE SCREEN. SET SCREEN 0. ENDIF. ENDFORM. * * * In the form routine: USER_COMMAND, l_selfield-refresh = ‘X’ is used to refresh the displaying list in the ALV.

4) In the declaration of the fields always better to use DATA ELEMENTS or TABLE-FIELDNAME. Instead of declaring it to be as “ TYPE c “. Some times it causes DUMP.
EX: DATA: 5) what is the output for the following statements. PROGRAM ZPTEST1. INITIALIZATION. START-OF-SELECTION. END-OF-SELECTION. TOP-OF-PAGE. WRITE: / 'Hello'.

A) Nothing will be happen, it doesn’t display anything. If we write WRITE,SKIP or ULINE in the Program, then it will display the ‘Hello’ in the output.

As On 12.05.2008:

OSS Notes – Tables: CWBNTCI CWBNTCONT CWBNTCUST CWBNTDATA CWBNTFIXED CWBNTGATTR CWBNTHEAD CWBNTLOG CWBNTMSG CWBNTSTATT CWBNTSTATV CWBNTSTXT CWBNTVALID Assignment of Note to correction instructions Data container for release data on the SAP Customer attribute for Note Compressed data for OSS Notes SAP Note completed by delivery event Table for Any Note Attributes Header table for OSS Notes in customer sys Assignment to log file SAP Notes Message Log Texts: Processing Status of SAP Notes Fixed Values for Processing Status Short text for a Note Validity table for Notes

SD,MM & FI/CO Document flow: MM flow: Purchase Requisition Request for Quotation Quotation from different vendors Price comparison Purchase order send to vendors Goods receipts Logistic invoice verification SD flow: Enquiry Quotation Sales order processing Delivery Billing (VA11) (VA21) (VA01) (VL01) (VF01) (ME51) (ME41) (ME47) (ME49) (ME22) (MIGO) (MIRO) SALES & DISTRIBUTION MODULE RELATED TABLES: Cycle: Enquiry->Quotation->Sales Order->Delivery(Picking, Packing, Post Goods Issue and Shipment)->Billing-> Data to FI TABLES and Important Fields: VBAK: Sales Document(Header Data) (VBELN) VBAP: Sales Document(Item Data) (VBELN,POSNR,MATNR,ARKTX,CHARG)

Enquiry, Quotation, Sales Order are differentiated based on Doc. Type(VBTYP field) in VBAK,VBAP Tables( for Enquiry VBTYP = A, for Quotation 'B' & for Order it is 'C'.) LIKP: Delivery Table (Header Data)(VBELN,LFART,KUNNR,WADAT,INCO1) LIPS: Delivery Table (Item Data)(VBELN,POSNR,WERKS,LGORT,MATNR,VGBEL) (LIPS-VGBEL = VBAK-VBELN, LIPS-VGPOS = VBAP-POSNR) VTTK: Shipment Table (Header Data)(TKNUM) VTTP: Shipment Table (Item Data)( TKNUM,TPNUM,VBELN) (VTTP-VBELN = LIKP-VBELN) VTFA: Shipping Document Flow(TKNUM,VBELV,VBELN) VTPA: Shipping Partners data(VBELN,PARVW,KUNNR,PERNR) VTTS: Stages in Shipment(TKNUM,TSNUM,TSTYP) VTSP: Transport Stage/Shipment Item Allocation(TKNUM,TSNUM,TPNUM) VEKP: Handling Unit: Header(Packing)(VENUM,VSTEL) VEPO: Handling Unit: Item (Packing)(VENUM,VEPOS,VBELN) VBRK: Billing Table(Header Data)(VBELN,FKART,BELNR) VBRP: Billing Table(Item Data)(VBELN,POSNR,FKIMG,NETWR,VGBEL,VGPOS) (VBRP-AUBEL = VBAK-VBELN, VBRP-VGBEL = LIKP-VBELN) Apart from these tables there are lot of other tables which starts with ‘V’, but we use the following tables frequently. VBUK: All Sales Documents status & Admn. Data(Header)(VBELN,VBTYP) VBTYP= ‘C’(Sales Order) VBTYP=’J’(Delivery) VBTYP=’M’(Invoice) VBUP: Sales Documents status & Admn. Data(Item)(VBELN,POSNR) VBEP: Sales Doc. Schedule Lines Data(VBELN,POSNR,EDATU,WMENG) VBKD: To get sales related Business data like Payment terms etc.(VBELN,ZTERM) VBFA: sales document flow data(VBELV,VBELN,POSNV,VBTYP) VBPA: Partner functions Data(VBELN,PARVW,KUNNR,LIFNR) VEDA: Contract Data(VBELN,VPOSN) VEDAPO: Contract Data(VBELN,VPOSN) KONA: Rebate Agreements (KNUMA,VKORG,VTWEG,SPART) VBRL: SD Document: Invoice List(VBELN,POSNR,VBELN_VF,NETWR,KUNAG) VKDFS: SD Index: Billing Indicator(FKTYP,VBELN,FKART,VKORG) VBSK: Collective Processing for a Sales Document Header(SAMMG,SMART) VBSS: Collective Processing: Sales Documents(SAMMG,VBELN,SORTF) VRKPA: Sales Index: Bills by Partner Functions(VBELN,BELNR,KUNDE,PARVW) VRPMA: SD Index: Billing Items per Material(MATNR,VBELN,BELNR,KUNNR) TVLKT: Delivery Type: Texts(LFART,VTEXT) KNA1: Customer Master-General(KUNNR,NAME1,LAND1) KNB1: Customer Master(Company Code)(KUNNR,BUKRS,PERNR) KNC1: Customer Master Data (Transaction Figures)(KUNNR,BUKRS,GJAHR) KNVK: Customer Master Contact Partner(PARNR,KUNNR,NAME1) KNVV: Customer Master sales data(KUNNR,VKORG,VTWEG,KDGRP) KNBK: Customer Bank Details(KUNNR,BANKS,BANKL,BANKN) KNVH: Customer Hierarchy (HITYP,KUNNR,VKORG,VTWEG,SPART) KNVP: Customer Master Partner Functions(KUNNR,PARVW,KUNN2) KNVS: Customer Shipment data(KUNNR,VSTEL,TRANS) KNVI: Customer Tax data(KUNNR,ALAND,TATYP) LFA1: Vendor Master-General (LIFNR,NAME1,ORT01) LFB1: Vendor Master(Company Code)(LIFNR,BUKRS,PERNR) LFC1: Vendor Master (Transaction Figures)(LIFNR,BUKRS,GJAHR) MARA: Material Master-General (MATNR,MTART,MATKL) MARC: Material Master-Plant data(MATNR,WERKS,EKGRP) MARD: Material Master- St.Location Data(MATNR,WERKS,LGORT,LABST) EBEW: Sales Order Stock Valuation(MATNR,VBELN,BWKEY,BWTAR) TVKO: Sales Organizations(VKORG) TVTW: Distribution Channel(VTWEG)

TSPA: Divisions(SPART) TVKOV: Distribution Channels for S.Orgn(VKORG,VTWEG) TVKOS: Divisions for S.Orgn(VKORG,SPART) TVTA: Sales Areas(VKORG,VTWEG,SPART) TVBUR: Sales Offices(VKBUR,ADRNR) TVKBT: Sales Office Texts(VKBUR,SPRAS,BEZEI) TVKBZ: Sales Office Sales Area(VKORG,VTWEG,VKBUR) TVKGR: Sales Group(VKGRP) TVGRT: Sales Group Texts(VKGRP,SPRAS,BEZEI) TVBVK: Sales Group to Sales office(VKBUR,VKGRP) TVKWZ: Plants S.Orgn(WERKS,VKORG) T171T: Sales District Texts(BZIRK,BZTXT,SPRAS) TVLA: Loading Points(LSTEL) TVST: Shipping Points (VSTEL) TVSWZ: Shipping Point to Plant(VSTEL,WERKS) TVPT: Item Categories (PSTYV) TINC: Customer Incoterms(INCO1) T077D: Customer Account Group (KTOKD) T001W: Plants (WERKS) T001L: Storage Locations (LGORT) T499S: Locations(WERKS,STAND,KTEXT) TWLAD: To get address of Storage Location and Plant(LGORT,ADRNR) TVAK: Sales Document (Order) Types (AUART) TVAU: Sales Documents: Order Reasons (AUGRU) TVFK: Billing Document Types (FKART) TVLK: Delivery Types(LFART) TVSB: Shipping Conditions (VSBED) TTDS: Transportation Points(TPLST) TVKT: Account Assignment Groups (KTGRD) KONV: Condition Types pricing)(KNUMV,KSCHL,KWETR) ADRC: To get Addresses of Partners(ADDRNUMBER,NAME1) VBBE: Sales Requirements: Individual records(VBELN,POSNR,MATNR) VBBS: Sales Requirement totals Record(MATNR,WERKS,LGORT,CHARG) VBKA: Sales Activities Data(VBELN,KTAAR) VBPV: Sales Document Product Proposal(VTWEG,MATNR,KUNNR,CHARG) T682: Access Sequences (KOZGF) T682T: Access Sequence Texts (KOZGF,VTXTM) T683: Pricing Procedures (KALSM) T683T: Pricing Procedures Texts(KALSM,KAPPL,SPRAS,VTEXT) T685: Pricing Condition Types (KSCHL) T685T: Condition Type Texts(KSCHL,SPRAS,KAPPL,VTEXT) KONH: Conditions (Header)(KNUMH,KAPPL,KSCHL) KONP: Conditions (Item)(KNUMH,KOPOS,KAPPL,KSCHL) KONV: Conditions (Transaction Data)(KNUMV,KSCHL,KBERT,KWERT) KOND: Conditions (KNUMD,ZUSKO,KSCHL) MATERIAL MANAGEMENT MODULE: Cycle: Purchase Requisition->Request for Quotation(RFQ)->(Vendor Evaluation)->Purchase Order(PO)>Goods Receipt Note(GRN)->Invoice Verification->Data to FI TABLES and Important Fields: LFA1--Vendor Master-General (LIFNR,NAME1,ORT01) LFB1--Vendor Master(Company Code)(LIFNR,BUKRS,PERNR)

LFC1--Vendor Master (Transaction Figures)(LIFNR,BUKRS,GJAHR) LFM1—-Pur.Orgn. Related Vendor Data (LIFNR,EKORG) MARA--Material Master-General (MATNR,MTART,MATKL) MARC--Material Master-Plant data(MATNR,WERKS,EKGRP) MARD--Material Master- St.Location Data(MATNR,WERKS,LGORT,LABST) MAKT--Material Descriptions(MATNR,MATKL,MAKTX) MBEW--Material Valuation Data(MATNR,BWTAR) MVKE—-Material Master: Sales related Data(MATNR,VKORG,VTWEG) MDKP--MRP related data(Header)(DTART,MATNR,PLWRK,PLSCN) MDTB—-MRP Table(DTNAM,DTPOS,PLANR) MCHA--Batches (MATNR,WERKS,CHARG) MCHB—-Batch Stocks(MATNR,WERKS,LGORT,CHARG) EBAN-- Pur.Reqn. Data (BANFN,BNFPO,BADAT,MATNR) EBKN-- Purchase Requisition Account Assignment(BANFN,BNFPO,VBELN) EINA—- Purchase Info.Record (General Data)(INFNR,MATNR,LIFNR) EINE-- Purchase Info.Record (Pur.Orgn Data )(INFNR,EKORG) ELBK-- Vendor Evaluation Header Data(LIFNR,EKORG,KLASS) ELBM-- Vendor Evaluation: Material-Related Item(LIFNR,MATNR,EKORG,INFNR,HKRIT) ELBP—- Main Criteria for Vendor Evaluation (LIFNR,EKORG,HKRIT) EKKO-- Purchase Order Data (Header)(EBELN,BSTYP,BSART) EKPO-- Purchase Order Data (Item)(EBELN,EBELP,MATNR) RFQ and PO are differentiated by Doc Type(BSTYP)in EKKO table. For RFQ it is ‘A’ and for PO it is ‘F’. MKPF-- GRN Data (Header) (EBELN,BLDAT,BUDAT,XBLNR,BKTXT) MSEG-- GRN Data (Item)(MBLNR,BWART,LIFNR,MATNR,EBELN) Apart from this there are lot of tables which begin with 'M'& 'E', but we use the following very often. EQUK--Quota(header) (QUNUM,MATNR) EQUP—-Quota(item) (QUNUM,QUPOS,LIFNR) ESLH--Service Package Header Data (PACKNO,EBELN,VBELN) ESLL--Lines of Service Package (PACKNO) ESUH--Ext. Services Management: Unpl.Service Limits: Header Data(PACKNO) ESKN--Account Assignment in Service Package(PACKNO) EKKN--Account Assignment in Purchasing Document(EBELN,EBELP,VBELN) EKBE--PO History Data (EBELN,EBELP,BELNR,BLDAT,MATNR,VGABE) EKBZ--PO History with delivery Costs(EBELN,BELNR,LIFNR,XBLNR) EKET--Schedule lines data of a PO (EBELN,EINDT,SLFDT) EKES--Vendor Confirmations Data(EBELN,EBTYP,EINDT,XBLNR) T001W-- Plants (WERKS) T001L-- Storage Locations (LGORT) T300—- Warehouse Numbers(LGNUM) T301—- Storage Types(LGNUM,LGTYP) T320—- Assign. Storage Location to WM Warehouse(WERKS,LGORT,LGNUM) T163F--Confirmation Texts(EBTYP,EBTXT) T156-- Movement Types(BWART) T024-- Purchasing Groups(EKGRP,EKNAM) T024E--Purchase Organizations(EKORG,BUKRS) T024W--Plants Assign to Purchase Organization (WERKS,EKORG) T161-- Purchasing Document Types(BSTYP,BSART) T163-- Item Category’s in Purchasing Documents(PSTYP) T149D--Valuation Types(BWTAR) T134-- Material Types(MTART) T179—- Material Product Hierarchies(PRODH) T179T—-Material Product Hierarchies: Texts(PRODH,SPRAS,VTEXT) TJ02T—-System status texts(ISTAT,SPRAS,TXT30) STKO-- BOM(Bill of Material)(Header)( STLTY,STLNR,STLAL)

STPO—- BOM(Bill of Material)(Item)( STLTY,STLNR,STLKN,STPOZ) STPU-- BOM Sub-Item (STLTY,STLNR,STLKN) STPN-- BOM Follow-Up Control (STLTY,STLNR,MATNR) STST-- Standard BOM Link (STOBJ,STLNR,STLAN,STLAL) STZU—- Permanent BOM data( STLTY,STLNR,STLAN,ALTST) RKPF-- Document Header: Reservation(RSNUM,BWART,ANLN1,KOSTL) RBKP-- Document Header: Invoice Receipt(BELNR,BLART,GJAHR,BUDAT) RSEG-- Document Item: Incoming Invoice(BELNR,BUZEI,EBELN,MATNR) FI Flow Basically there are 5 major topics/areas in FI, 1. GL Accounting related tables are SKA1, SKB1 Master data BSIS and BSAS are the Transaction Data 2. Account Receivables- related to Customer All the SD related data when transferred to FI these are created. Related Tables BSID and BSAD 3. Account Payables - related Vendor All the MM related documents data when transferred to FI these are created Related Tables BSIK and BSAK All the above six tables data is present in BKPF and BSEG tables You can link these tables with the help of BELNR and GJAHR and with Dates also. 4. Special Purpose Ledger.. which is rarely used. 5. Asset Management In CO there are Profit center Accounting Cost center Accounting will be there. Cross-Application Components -> Financial. tm you will go through this link Check this Link it out for tables check out link.. Take a look at this.

Regards, Satish As on 16.05.08 1. In LSMW, for IDoc processing the following steps are prerequisite in the development phase. Need to maintain ports, partner types and partner numbers. And then give the message type and basic type in the 4 options screen. 2. LSMW Supports on inbound processing not outbound processing.

Client - In commercial, organizational, and technical terms, a self-contained unit in an SAP system with separate master records and its own set of tables. Value table: Value table is a domain level checking .In some cases you can see when you define a domain that all the table fields or structure components referring to this domain should be checked against a certain table. This information can be stored in the domain by entering a value table. A check is not implemented by simply entering a value table! The check against the value table only takes effect when a foreign key has been defined Check table: Check Table is the dependent table to which the relationship is defined using foreign keys. The contents of the check table field are shown in the input help for the referenced field.. While creating a table if you want to be sure that a field can have some values and these are in a certain table, you can give IT this table as CHECK TABLE. Important Difference The contents of the check will be used as an input help(F4 Help) for a particular field on which a check table is assigned. But the contents of Value Table are never used in Input Help. Check Table: The ABAP Dictionary allows you to define relationships between tables using foreign keys. A dependent table is called a foreign key table, and the referenced table is called the check table. Each key field of the check table corresponds to a field in the foreign key table. These fields are called foreign key fields. One of the foreign key fields is designated as the check field for checking the validity of values. The key fields of the check table can serve as input help for the check field. Value Table: Prior to Release 4.0, it was possible to use the value table of a domain to provide input help. This is no longer possible, primarily because unexpected results could occur if the value table had more than one key field. It was not possible to restrict the other key fields, which meant that the environment of the field was not considered, as is normal with check tables. In cases where this kind of value help was appropriate, you can reconstruct it by creating a search help for the data elements that use the domain in question, and using the value table as the selection method. Check table will be at field level checking. Value table will be at domain level checking ex: scarr table is check table for carrid.

Sign up to vote on this title
UsefulNot useful