Data Transfer using LSMW IDOC processing with multiple segments

we need to post the document data (Header structure, BP item structure, G/L item structure..etc) using LSMW IDOC processing.
is it possible to transfer data for all these structures (Segments) in single file?

Thanks for the reply.
I am assuming when we are specifying the file in LSMW we are going to give the option to generate the file with include all structures.
could you please elaborate further is there any thing specific we need to do while configuring LSMW to get the file for all segments in the IDOC with field names which we are going to populate with data, so that we can use it for data transfer.
any help document will  be helpful.

Similar Messages

  • SAP Retail : Article Master Data Transfer using LSMW/ARTMAS05: EAN Error

    Hi Bjorn Panter,
    I want to thank you for providing very informative articles on the Master Data of ERP Retail.
    We are currently loading articles to SAP from legacy and use your articles on ERP Retail as part of our knowledge warehouse.
    We have encountered an error which has stumped our conversion.
    We are getting an M3 535 error stating that "First specify the main EAN for the unit EA".  We are using LSMW (IDOC Method, Basic Type ARTMAS05).
    Our MARM segments have generic and variants.  The UPC and UPC category (set to UC) are filled for the variants and blank in the segment containing the generic.
    Our MEAN segments contain variants only with the UPC and UPC category (set to UC) filled.
    Our UC EAN category is configured with a blank check digit algorithm and a number range of 12 digits.  We are loading our variants with EANs that are 12 digits.
    When debugged IDOC_INPUT_ARTMAS, I noticed that :
    In routine  MARM_UEBERGEBEN (in function module BAPI_MATERIAL_MAINTAINDATA_RT), this code clears our MARMX indicators :
       LOOP AT UNITSOFMEASURE.
        ART_DATA_EXISTS = 'X'.    "JH/05.01.00/4.6C Entkopplung der MALG
        IF UNITSOFMEASURE-FUNCTION NE C_MSGFN_D.   ->>>> this checks if our function code is 003 (which is a delete).
    *     TMFIELDRES aufbauen
          CLEAR UNITSOFMEASUREX.                   ->>>> Since we are doing a create, it clears the indicators in unitsofmeasureX
    To bypass this clear, I debugged the program and overlayed the indicators and marked UPC and UPC category as 'X'.  This worked and we were able to post our IDOC successfully... THe UPCs showed in the MARM and MEAN tables.
    However, knowing that there are a lot of Retail companies loading articles into their SAP system, it would seem odd that no one has reported this as a bug or no one has posted this issue in SDN.  I could not find any OSS note related to this issue either.
    Can you please help us figure out what is wrong ? Have you encountered this error in the past ?  Is there something in config that we should check ?  Should we look at fields in our segments ?
    Any help from you would be greatly appreciated.
    Thanks,
    Sarah

    Dear Sarah,
    please open an OSS customer message.
    Put in a valid IDOC ARTMAS number with this error and open your system.
    I guess either it is a bug in IODC structure or you found a bug in software.
    My colleages will take care.
    Regards
    Björn

  • Data transfer using ALE/IDOC into XML.

    Dear All,
    I have to transfer FI document data (FB01) from the sap system ,convert it into XML and dump it in 1 of the file servers.I want to do this using ALE/IDOC.Is it possible to do the same and how.Similarly i want to do the same for Vendor and Customer master i.e sending the data in XML format.
    Kindly Suggest how do i go about doin the same..Its very urgent.Please help.
    Thanks & Regards,
    Lailu Philip.

    In continuation:
    Example Purchasing & Selling scenario
    We will develop a custom IDoc to carry the billing number from the Service Receiver’s system to the Service Provider’s system. We will populate the IDoc in a user exit on the sending side and we will process the transaction on the receiving side using a custom function module and a BDC transaction call.
    No rule conversion, segment filtering or version conversion will be implemented in the model as described in Figure 1.
    Requirements
    • Working ALE environment - See ALE Basis Configuration Guide;
    • ALE scenario design together with the business requirement;
    • Development access; and
    • ALE configuration access.
    NOTES:
    1. All IMG references to transactions are located in the transaction SALE which is the ALE portion of the IMG
    2. This is one way of developing a scenario where no message control exists. If message control exist (EG. On purchase orders) then NAST can be used to call an outbound function module that would create the required IDocs.
    3. Extensive knowledge of IDocs and ALE basis configuration is required in order to understand this guide.
    2. OUTBOUND PROCESSING
    2.1. Create IDoc type (WE30) Client independent
    The IDoc type refers to the IDoc structure that you will require for your development. In our case the IDoc type is called ZINVRV01. This IDoc type will have 1 segment called Z1INVRV with 2 fields, LIFNR & XBLNR, in this segment. If you require many segments or nested segments then they are also created using the same procedure.
    We will create the IDoc of the following structure:
    ZINVRV01
    Purchasing and Selling - Invoice receipt reversal
    Z1INVRV P&S - Segment 1
    Segment fields
    LIFNR Vendor account number
    XBLNR Reference document number
    Figure 3: IDoc type ZINVRV01
    To create the IDoc type, follow these next few steps:
    • Enter transaction WE30 (ALE -> Extensions -> IDoc types -> Maintain IDoc type)
    • Type in ZINVRV01 and click on Basic IDoc type, click the Create icon
    • Click on Create new (we are creating an IDoc from scratch but you may want to copy another IDoc if it is similar to your requirements) and enter a description, and press enter
    • Click on ZINVRV01 and then on the Create icon
    • Enter Z1INVRV as the segment type (must start with Z1), check mandatory if the segment must exist (in this case check it), enter 1 in minimum number and 1 as maximum number. (Make the maximum number 9999999999 if there are going to be many of these segments in each IDoc. IE. When line items are passed via IDocs), click on Segment editor
    • Enter a description for your segment type and create
    • Enter a description for your segment, enter each field required in your IDoc, in our case type LIFNR across for Field name, DE structure and DE documentation, repeat for XBLNR and press enter to validate.
    • Save and generate, press back
    • To release the segment choose Goto, Release from the menu
    • Check the box on the line of your new segment
    • Save, back and enter
    • Your IDoc type structure should be displayed with your new segment
    • Save and back
    • To release the IDoc type choose Extras, Release type from the menu and Yes
    Your IDoc is now ready for use. If you need to add fields or segments to your IDoc type, you will need to cancel the release of the IDoc type as well as the segment release using a similar procedure followed above (except now you uncheck the release box for the segment and you choose cancel release for the IDoc type).
    2.2. Create message type (WE81) Client independent
    To create a new message type, follow these next few steps:
    • Enter transaction WE81 (ALE -> Extensions -> IDoc types -> Maintain message type for intermed. Structure -> Create logical message type)
    • Choose Create logical message type by double clicking on it
    • Click on change icon to enter change mode
    • Click on New entries to add a new type
    • Enter the required message type, in our case it is ZINVRV and an appropriate description
    • Save and exit.
    Your message type has now been created. The next step will be to link it to the IDoc.
    2.2.1. Link message to IDoc type (WE82 & BD69) Client independent
    To link the message type to the IDoc type follow these next few steps:
    • Enter transaction WE82 (ALE -> Extensions -> IDoc types -> Maintain message type for intermed. Structure -> EDI: Message Types and Assignment to IDoc Types)
    • Click on change icon to enter change mode
    • Click on New entries to create the link
    • Enter the message type ZINVRV and the BasicIDoc type as ZINVRV01
    • Save and exit
    • Enter transaction BD69 (ALE -> Extensions -> IDoc types -> Maintain message type for intermed. Structure -> Assign message type to IDoc for ALE)
    • Click on change icon to enter change mode
    • Click on New entries to create the link
    • Enter the message type ZINVRV and the BasicIDoc type as ZINVRV01
    • Save and exit
    Your IDoc is now linked to your message type. We still need to link object types and add the message to the model before we can use the message.
    2.2.2. Maintain object type for message type (BD59) Client independent
    The ALE objects are used to create links between IDocs and applications objects, to control the serialisation, to filter messages in the customer model and to use listings.
    For our own message type and IDoc you must maintain object types for the links.
    If you want to check the serialisation for the message type, then you must maintain object types for the serialisation. If no serialisation object has been maintained for a given message type, then the serialisation will not be checked for this message type.
    To add an object type to our message type, follow these next few steps:
    • Enter transaction BD59 (ALE -> Extensions -> ALE object maintenance -> Maintain object types)
    • Type in your message type ZINVRV and press enter
    • Click on New entries
    • Enter your object type, LIFNR (We need to use the vendor as a filter object), the segment name where LIFNR resides, Z1INVRV, a number 1 for the sequence followed by the actual field name LIFNR
    • Save and exit.
    You have now created an object that we’ll use as a filter object in the customer model to direct the flow of messages to the various logical systems based on the vendors in the filter of the message type ZINVRV.
    We now need to add our new message type to the distribution model.
    2.3. Configuring the Distribution Model
    This task is performed on your ALE reference client.
    2.3.1. Manual Configuration (BD64) Client dependent
    To manually configure the customer distribution model, read the ALE configuration procedure, and follow these steps:
    • Perform the Maintain customer distribution model directly function. (ALE -> Distribution customer model -> Maintain customer distribution model directly)
    • Specify the customer model you want to maintain and the logical system that is to be the sender of the messages OR create a new model. (Create model ALE with logical system ALELS1C400)
    • Choose the receiving systems to which the sending system must forward message type ZINVRV to.
    • For each receiving logical system allocate the message type necessary for communication to the receiving systems as per ALE configuration procedure.
    • Create filter objects (in our case LIFNR as the object type with the associated vendor number, 0000018001 with leading zeros, in the object area) for the message types.
    • Save the entries.
    NOTES:
    You cannot maintain a message type between the same sender and receiver in more than one customer distribution model.
    Only the owner is authorised to modify the model.
    To change the owner of a model, choose the 'Maintain ownership of customer distribution model' function. Make sure that all changes will be distributed to all systems that know the corresponding model. To do so, you can use the correction and transport system.
    To transport the customer distribution model you should use the Distribute customer model function of the IMG as described below.
    2.3.2. Distribute customer model (BD71) Client dependent
    After the customer model has been created centrally, it must be distributed to the other remote systems. This entails first of all setting up the communication for the distributed systems and then sending the model.
    2.3.2.1. Distribute Model (BD71) Client dependent
    This task is performed on your ALE reference client. To distribute the customer distribution model, read the ALE configuration procedure and follow these steps:
    • Make the settings for the communication with the other decentral systems, you have not set them yet.
    • Define the RFC destination for R/3 connections whose names correspond to the name of the corresponding logical system.
    • Create the output partner profile.
    • Distribute the customer model
    • Specify the name of the customer model.
    • You must specify the target system to which you want to distribute the customer model.
    • You must repeat this function for every distributed logical system.
    2.3.2.2. Maintain sending system partner profile (WE20) Client dependent
    With this function, you define the partner profiles for all outbound and inbound messages on the basis of the customer distribution model.
    After you have defined and distributed the customer model, you will have to maintain the partner profiles locally. To do this read the ALE configuration procedure.
    • Enter the output mode (background, immediately) and the package size for outbound processing.
    Requirements
    • The customer model must be maintained.
    • RFC destinations must be maintained.
    • The customer model must be distributed.
    • To ensure that the appropriate persons in charge are informed if a processing error occurs, you must make settings in: Error processing Maintain organisational units.
    2.4. Populate & distribute IDoc using ABAP
    An IDoc consists of a control record with structure edidc and one or more data records with structure edidd. The control record contains the sender and recipient of the IDoc, as well as information on the type of message.
    To be able to pass an IDoc to the ALE layer, you must set up a field string with structure edidc and an internal table with structure edidd. They are used to call function module master_idoc_distribute, which performs the save to the database and triggers the dispatch if necessary.
    2.4.1. Example code
    The code displayed below does the following:
    • populates our IDoc segment Z1INVR with the 2 fields XBLNR and LIFNR, populates the segment name and appends this to an internal table used to store the IDoc data;
    • populates the control record info with the message type and IDoc type; and
    • calls the MASTER_IDOC_DISTRIBUTE function module which distributes the IDoc as configured in the customer distribution model.
    Data declaration statements
    DATA: C_INVREV_SEGNAME(7) TYPE C VALUE 'Z1INVRV',
    C_INVREV_MESTYPE(6) TYPE C VALUE 'ZINVRV',
    C_INVREV_IDOC_TYPE(8) TYPE C VALUE 'ZINVRV01',
    Z1INVRV LIKE Z1INVRV,
    C_INVREV_DOCTYPE LIKE BKPF-BLART VALUE 'YY',
    IDOC_CONTROL LIKE EDIDC,
    T_COMM_CONTROL LIKE EDIDC OCCURS 0 WITH HEADER LINE,
    IDOC_DATA LIKE EDIDD OCCURS 0 WITH HEADER LINE.
    Move the document header into a structure
    LOOP AT DOC_HEAD_TAB INTO DOC_HEAD.
    ENDLOOP.
    Move the document item data into a structure
    LOOP AT DOC_ITEM_TAB INTO DOC_ITEM WHERE NOT ( LIFNR IS INITIAL ).
    ENDLOOP.
    Populate the IDoc segment’s field with the required data
    CLEAR Z1INVRV.
    Z1INVRV-LIFNR = DOC_ITEM-LIFNR. “Store vendor number for filter
    Z1INVRV-XBLNR = DOC_HEAD-XBLNR. “Billing number
    IDOC_DATA-SEGNAM = C_INVREV_SEGNAME. “Segment name
    IDOC_DATA-SDATA = Z1INVRV. “Segment data
    APPEND IDOC_DATA. “Populate IDoc internal table
    Move the control data info required for the distribution
    IDOC_CONTROL-MESTYP = C_INVREV_MESTYPE.
    IDOC_CONTROL-DOCTYP = C_INVREV_IDOC_TYPE.
    Call the distribute function with the required parameters
    CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' IN UPDATE TASK
    EXPORTING
    MASTER_IDOC_CONTROL = IDOC_CONTROL
    TABLES
    COMMUNICATION_IDOC_CONTROL = T_COMM_CONTROL
    MASTER_IDOC_DATA = IDOC_DATA
    EXCEPTIONS
    ERROR_IN_IDOC_CONTROL = 1
    ERROR_WRITING_IDOC_STATUS = 2
    ERROR_IN_IDOC_DATA = 3
    SENDING_LOGICAL_SYSTEM_UNKNOWN = 4
    OTHERS = 5.
    Figure 4: Outbound processing example code
    NOTE:
    For debugging purposes, use transaction WE05 (IDoc overview) to see check your IDoc status, or to see whether an IDoc was created/
    3. INBOUND PROCESSING
    3.1. Create Function Module
    This function module is called when a message type, of type ZINVRV, comes into the receiving system. This needs to be configured and is dealt with later in this section. The function module is passed the IDoc as a parameter.
    Example parameters
    Import parameters Reference field Opt Y/N
    INPUT_METHOD BDWFAP_PAR-INPUTMETHD N
    MASS_PROCESSING BDWFAP_PAR-MASS_PROC N
    Export Parameters Reference field Opt Y/N
    WORKFLOW_RESULT BDWFAP_PAR-RESULT N
    APPLICATION_VARIABLE BDWFAP_PAR-APPL_VAR N
    IN_UPDATE_TASK BDWFAP_PAR-UPDATETASK N
    CALL_TRANSACTION_DONE BDWFAP_PAR-CALLTRANS N
    Table Parameters Reference field Optional Y/N
    IDOC_CONTRL EDIDC
    IDOC_DATA EDIDD
    IDOC_STATUS BDIDOCSTAT
    RETURN_VARIABLES BDWFRETVAR
    SERIALIZATION_INFO BDI_SER
    Exceptions
    WRONG_FUNCTION_CALLED
    Example code
    The code displayed below does the following:
    • populates a BDC table with the IDoc info;
    • calls the transaction via a BDC call; and
    • updates the IDoc status according to the BDC error status.
    EXTRACT FROM: Z_IDOC_INPUT_ZINVRV
    Declaration of local variables
    DATA: C_SEGNAM(10) TYPE C VALUE 'Z1INVRV'.
    *-Loop through the IDOCs
    LOOP AT IDOC_CONTRL.
    *---Loop through the data for the IDOC
    LOOP AT IDOC_DATA WHERE DOCNUM = IDOC_CONTRL-DOCNUM.
    CASE IDOC_DATA-SEGNAM.
    WHEN C_SEGNAM.
    Here we get the info from the idoc table
    IT_Z1INVRV = IDOC_DATA-SDATA.
    ENDCASE.
    PERFORM REV_INV.
    ENDLOOP.
    PERFORM UPDATE_IDOC_STATUS.
    ENDLOOP.
    FORM REV_INV "Reverse invoice form
    Local variables & constants
    DATA: C_TCODE LIKE BKPF-TCODE VALUE 'VF11'. "BDC transaction code
    Now we can build the bdc table to call the reversal transaction start of screen 109
    CLEAR BDC_TAB.
    BDC_TAB-PROGRAM = 'SAPMV60A'.
    BDC_TAB-DYNPRO = '109'.
    BDC_TAB-DYNBEGIN = 'X'.
    APPEND BDC_TAB.
    Document number
    CLEAR BDC_TAB.
    BDC_TAB-FNAM = 'KOMFK-VBELN(01)'.
    BDC_TAB-FVAL = IT_Z1INVRV-XBLNR. "Billing document number
    APPEND BDC_TAB.
    OK Code for screen 109
    CLEAR BDC_TAB.
    BDC_TAB-FNAM = 'BDC_OKCODE'.
    BDC_TAB-FVAL = 'SICH'.
    APPEND BDC_TAB.
    Now we can call transaction 'VF11' with the populated bdc table. The transaction is called inside the idoc-contrl loop, so a transaction will be called for every idoc (journal). the transaction is called in no-display mode ('N') because this code runs in background as it is called by ale. The update is specified to be synchronous ('S') because we have to wait for the result to update the idoc status correctly.
    CALL TRANSACTION C_TCODE USING BDC_TAB MODE 'N' UPDATE 'S'.
    Store the return code for use in another form (status update)
    RETURN_CODE = SY-SUBRC.
    Here we check the return code, if there was an error, we put the transaction in a bdc session for the user to review and correct.
    IF SY-SUBRC NE 0.
    CALL FUNCTION 'BDC_OPEN_GROUP'
    EXPORTING
    CLIENT = SY-MANDT
    GROUP = 'ZINVRV'
    USER = C_ALE_USER
    KEEP = 'X'.
    CALL FUNCTION 'BDC_INSERT'
    EXPORTING
    TCODE = C_TCODE
    TABLES
    DYNPROTAB = BDC_TAB.
    CALL FUNCTION 'BDC_CLOSE_GROUP'
    EXCEPTIONS
    NOT_OPEN = 1
    QUEUE_ERROR = 2
    OTHERS = 3.
    ELSE. "No problems
    C_EXISTS = 'N'.
    Select from the billing document table to get sales doc number
    SELECT * FROM VBRP WHERE VBELN = IT_Z1INVRV-XBLNR.
    Select from the sales document table to get user status number
    SELECT SINGLE * FROM VBAP WHERE VBELN = VBRP-AUBEL AND
    POSNR = VBRP-AUPOS.
    Select from the status table to change the user status to pending
    SELECT * FROM JEST WHERE OBJNR = VBAP-OBJNR AND
    STAT LIKE C_USER_STATUS.
    IF JEST-STAT = C_US_PENDING. "User status is pending
    JEST-INACT = C_UNCHECKED. "Make pending the active status
    UPDATE JEST.
    C_EXISTS = 'Y'. "I.E. An entry is already in table
    ELSEIF JEST-INACT = C_UNCHECKED AND JEST-STAT NE C_US_PENDING.
    JEST-INACT = C_CHECKED. "Make everything else inactive
    UPDATE JEST.
    ENDIF.
    ENDSELECT.
    IF C_EXISTS = 'N'. "I.E. Pending has never been a status before
    JEST-OBJNR = VBAP-OBJNR.
    JEST-STAT = C_US_PENDING.
    JEST-INACT = C_UNCHECKED. "Make pending the active status
    INSERT JEST.
    ENDIF.
    ENDSELECT. "Select from VBRP (Billing document table)
    ENDIF.
    ENDFORM. " REV_INV
    FORM UPDATE_IDOC_STATUS.
    Now we check the CALL TRANSACTION return code and set IDOC status
    CLEAR IDOC_STATUS.
    IF RETURN_CODE = 0.
    WORKFLOW_RESULT = '0'.
    IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
    IDOC_STATUS-STATUS = '53'.
    IDOC_STATUS-UNAME = SY-UNAME.
    IDOC_STATUS-REPID = SY-REPID.
    IDOC_STATUS-MSGTY = SY-MSGTY.
    IDOC_STATUS-MSGID = SY-MSGID.
    IDOC_STATUS-MSGNO = SY-MSGNO.
    IDOC_STATUS-MSGV1 = SY-MSGV1.
    IDOC_STATUS-MSGV2 = SY-MSGV2.
    IDOC_STATUS-MSGV3 = SY-MSGV3.
    IDOC_STATUS-MSGV4 = SY-MSGV4.
    RETURN_VARIABLES-WF_PARAM = 'Processed_IDOCs'.
    RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
    APPEND RETURN_VARIABLES.
    ELSE.
    WORKFLOW_RESULT = '99999'.
    IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
    IDOC_STATUS-STATUS = '51'.
    IDOC_STATUS-UNAME = SY-UNAME.
    IDOC_STATUS-REPID = SY-REPID.
    IDOC_STATUS-MSGTY = SY-MSGTY.
    IDOC_STATUS-MSGID = SY-MSGID.
    IDOC_STATUS-MSGNO = SY-MSGNO.
    IDOC_STATUS-MSGV1 = SY-MSGV1.
    IDOC_STATUS-MSGV2 = SY-MSGV2.
    IDOC_STATUS-MSGV3 = SY-MSGV3.
    IDOC_STATUS-MSGV4 = SY-MSGV4.
    RETURN_VARIABLES-WF_PARAM = 'ERROR_IDOCS'.
    RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
    APPEND RETURN_VARIABLES.
    ENDIF.
    APPEND IDOC_STATUS.
    ENDFORM. " UPDATE_IDOC_STATUS
    Figure 5: Inbound processing example code
    3.1.1. Debugging inbound FM
    Use transaction WE19 to test inbound function module in debugging mode. Also use WE05 to view the IDocs and their statuses.
    3.2. Maintain ALE attributes
    The inbound function module needs to be linked to the message type and the message type needs to be linked to the appropriate inbound process code at the partner profile level before the scenario is enabled. These steps are described below in detail.
    3.2.1. Link Message Type to Function Module (WE57) Client independent
    To link a message (ZINVRV) type to a function module (Z_IDOC_INPUT_ZINVRV) follow these steps:
    • Enter transaction WE57 (ALE -> Extensions -> Inbound -> Allocate function module to logical message)
    • Select an entry (EG. IDOC_INPUT_ORDERS) and copy
    • Type in module name Z_IDOC_INPUT_ZINVRV
    • Type in basic IDoc type as ZINVRV01
    • Type in message type as ZINVRV
    • Type object type as IDOCINVOIC (Invoice document) - Used for workflow
    • Direction should be set to 2 for inbound
    • Enter and save
    3.2.2. Define FM settings (BD51) Client independent
    • Enter transaction BD51 (ALE -> Extensions -> Inbound -> Define settings for input modules)
    • Click on New entries
    • Type in the name of the new function module Z_IDOC_INPUT_ZINVRV
    • Enter 0 for mass processing in the output column
    • Save and Exit
    3.2.3. Maintain process codes (WE42) Client dependent
    A process code needs to be maintained on each client. It then needs to be linked to the message via the partner profiles on each client. This allows the various clients to use a unique function module for the same message type.
    To maintain the process code follow these steps:
    • Log on to the appropriate receiving system client
    • Execute WE42 (ALE -> Extensions -> Inbound -> Maintaining process codes inbound)
    • Choose Inbound with ALE service
    • Choose Processing with function module
    • Click on Processing with function module and choose create icon
    • Click on New Entries
    • Type in process code ZINR and give it a description and save
    • Now you are asked to Please maintain codes added in ALE entry methods, enter and choose Z_IDOC_INPUT_FIRVSL and copy it. You should choose a FM similar to your one.
    • Enter your process code ZINR
    • Enter your function module Z_IDOC_INPUT_ZINVRV
    NOTE: The next 6 steps are used in workflow error handling.
    • Enter IDPKFIDCMT in object type
    • Enter MASSINPUTFINISHED in End event
    • Enter IDOCINVOIC in IDoc object type
    • Enter INPUTERROROCCURREDFI in IDoc start event
    • Enter INPUTFINISHEDFI in IDoc End event
    • Enter IDOCINVOIC in Application object type
    You will need to determine the task associated with object IDOCINVOIC, and then assign the appropriate position to it. This position will then receive the application error messages via workflow.
    To set up the workflow area please consult the Workflow config guide.
    3.3. Create inbound partner profile
    For each message type you need to maintain the inbound partner profiles.
    3.3.1. Maintain receiving system partner profile (WE20) Client dependent
    To maintain inbound partner profiles read the document ALE configuration procedure:
    • Add the message type ZINVRV with process code ZINR.
    • Enter the output mode (background, immediately) for inbound processing and NO message code.
    • Enter the position S and choose the ALE administrator 50000085. This position will then receive all the technical ALE errors via workflow.
    3.4. Test
    Once the inbound function module has been debugged the scenario should be ready to test in its entirety. If problems occur, read through the relevant areas of this document to check your configuration or code.
    Hope this will help you,
    If you  want me to explain more, you can give me your email id.
    Reward with points incase you are satisfied.
    Regards,
    Sushama

  • Data Transfer Using ALE/IDOC

    Dear All,
              I have to implement an ALE\IDOC scenario and i am totally new to this.I have a web based software from where i need to pull data into SAP.
               The moment billing takes place in my web based software i have to pull the required data and generate an accounting document number in SAP using transactions FB01 er FB60 and FB70 depending on vendor or customer Invoice which means i need to have my vendor and customer master data in place before this.The IDOC  which i would be using is FIDCCP01.My question is:
    The web based software can generate both an XML and EDI file into a domain from where SAP can fetch it. Now,
    1. If they can generate an EDI file which format should it be in?
    2.If EDI file generation is possible through that web based software its structure should be exactly the same as my IDOC structure right?
    3. What would then be the process on SAP side to pick that   EDI file data?
    4. Does the transaction WE16 help in picking up an XML file format or an EDI format and convert it automatically into an IDOC and how do we go about it?
    5. Now when this idoc is going to generate accounting documents against those billing documents if the customer or vendor does not exist is there a way by which i can first create this vendor\customer in the master and then continue using some other abap tool?
    6. Could an email be generated automatically when teh document is posted?
    I know these are a lot of  questions but i really need an answer to this.
    If u have an answer my alternate email id is [email protected]
    Awaiting your reply shortly.
    Thanks & Regards,
    Lailu Philip.

    1. XML Format
    2. Message type INVOIC01 or INVOIC02 format
    3. You need to write a Z program to read data from that path and use FM IDOC_XML_FROM_FILE to convert that XML file to IDOC.
    4. Use transaction we60 with above message type it will all help you need. we16 is for testing it could not be used for a solution.
    5. In your Z program check before the XML is ubmitted for processing whether the customer exist by select on KNA1 if not use FM BAPI_CUSTOMER_CREATE to create and same for vendor.
    6. You need to implement workflow for this.....
    Reward points it this helps

  • ISSUE:regarding production version tab of MRP4 of  data transfer using BD10

    Hi all,
    This is regarding production version tab of MRP4 of  data transfer using ALE idoc (BD10).
    When i transfer the data using BD10 the production version is received at receiving end through segment
    but not created in MRP4 view tab.An error is coming as-
    "You wanted to maintain the master record of the material AB_06.04.09(2). However, it is already being processed by the user EBGABAP and is therefore locked."
    I logged in as-EBGABAP
    Please help me resolve the issue.
    Thanks
    Edited by: sanu debu on May 6, 2009 11:08 AM
    Edited by: sanu debu on May 6, 2009 11:09 AM
    Edited by: sanu debu on May 6, 2009 11:11 AM

    >
    sanu debu wrote:
    > Hi,
    > I have to upload production version tab data of  MRP4 view(MM01).Please suggest a function  moduleor bapi  for the same.
    >
    > Thanks.
    >
    > Edited by: sanu debu on May 6, 2009 3:24 PM
    BAPI_MATERIAL_SAVEDATA can be used, populate the respective fields in input parameter PLANTDATA

  • Does the data transfer used in the back up in time capsule included in the data allowance from my service provider?

    Is the data transfer used in the backup with airport time capsule included in the data allowance with my service provider?

    gheefromsa wrote:
    I am using Ethernet cable to connect TC to the modem. I am only backing up my mac book air within range of the TC. So I guess it will be OK from your reply. As a trial I did interrupt the back up by turning off the TC, disconnecting the Ethernet cable, turning TC back on. The mac would not connect wirelessly with the TC without the Ethernet connection.
    It is not using ISP .. absolutely for sure. Well 99.999%.. absolute tends to be only in maths.
    But you did the test wrongly.. I said to disconnect the modem.. during the backup.. not turn off the TC.. obviously once interrupted the TC will not work again until everything is plugged in.. but it will work even bridged for a short time.. just unplug the WAN port from the modem.
    The test is moot now.. as I can give you a 99.999% promise it is not using ISP.

  • How to upload different views of customer master data using LSMW-IDOC

    I need to upload customer master data  using LSMW Idoc method for my client. Now customer will have different views like main view, Sales data, Company code data, Partner function data etc. And except main data all other data can be multiple for each customer. We are going to upload data from tab delimited .TXT file. Should I propose different LSMW for upload different views for the customer from different .TXT files? or we can upload all the customer related data (like main view data and partner function data )from a single .TXT file. Kindly suggest which one in convenient and how we can prepare the data file in both cases.

    convinient is the method that you can handle.
    but as the guy who loads the data you have to load the data like they are available, like it is convinient for others to prepare the data.
    In general there is no problem to use an IDOC method to load a customer master with multiple comany codes and several sales orgs in one shot.
    the data can be in one source file, but need then to be maintained in a certain way
    Example1: all data in 1 structure
    GD1 - CC1 - SO1
    GD1 - CC2 - SO2
    GD1 - CC2 - SO3
    in this case the GD (general data) is redundand in each line which has different Company code data or different Sales Org data
    Example2: all data in 3 sturcures but one file
    GD1
    .CC1
    .CC2
    ..SO1
    ..SO2
    ..SO3
    Example3: data delivered in 3 files - you join the files in LSMW, they must have a common identifier like the old customer number in the beginning of each file
    FILE General data:
    GD1
    GD2
    GD3
    file Compamy code data:
    CC1
    CC2
    CC3
    file Sales org data:
    SO1
    SO2
    SO3
    LSMW is flexible and can handle each of this scenarios, are you flexible too?

  • Multiple Source Structure in single flatfile using lsmw idoc method

    Hi Abapers,
                we have a requirement for Business partner Data mIgration into CRM system using LSMW idoc method,I got a flat file
    which has multiple source structures like(header structure,Tax structure,Mailstructure,Identification structure,bankdetails structure,card strcuture........etc of 12 structures) with identification for each structure. can any one help me how to handle this in lsmw or any link of this kind of scenario will be helpful for me .
    Thanks and Regards,

    Hi Saeed,
    For example if you want t create bom through lsmw then we will *** two files one header and other item one.In the same way .In lsmw start by keeping the idoc method i will only propose at second step how many files it need. Just map the idoc and see. Post if need more help.
    Regards,
    Madhu.

  • LSMW Update Process with IDoc

    Hi Experts,
      We have an LSMW project to upload to create new activity in the CRM server and it has been working fine. Now we want to modify the project so that the existing data gets "updated" instead of creating a new activity.
    My question is..
    Is it possible to make data "updates" using LSMW.
    I tried adding more fields in  the existing project and now i get this error when i try to update. "Activity already exists in the system"
    I'd really appreciate your help and inputs.
    Thanks in advance
    Mani

    Hi Mani,
    I have gone through your query.
    When you use LSMW Idoc method to create the Activity with in the CRM system, you can definitely use the same project to update the Activity details as well. Follow the simple rules below.
    1. With the Basic type you have used to create Activity, in the rules for the segments change the task to Update.
    2. With this change done, for the segments you need to update the data, change and save them.
    3. After all these you can create and process the Idocs so that the activity details are updated.
    LSMW can be used to create, update and make changes with in permissible business objects. So definitely this update can be done. I hope this helps.
    Regards,
    Venkat

  • Problem initiating process with multiple operations using HTTP/SOAP

    Hi,
    I have defined a process which has multiple operations. My process starts with a pick activity containing onMessage branches for each possible operation. When I initiate this service using the BPEL console, I choose one of the operations and everything works fine.
    However, when I initiate this process using an HTTP/SOAP web service call using JMeter, always the first branch is executed regardless of the message I send.
    My operations are document/literal. Due to some restrictions, I cannot define a SOAPAction for the operations. Could this be the problem? Is there a workaround for this? If this is not the problem, what could be the cause?
    I'm using version 10.1.2.1.
    Any help will be appreciated. Thanks in advance..

    hi i am using 10.1.3 and still i can not initiate a process with multiple operations. Is there anybody to tell if pick activity works fine and if there are some points to consider?
    If there is a problem is there any solution to make a process with multiple operations?

  • I was just copying my data from stand by phone by using phone to phone data transfer but phone also locked with i cloud login of stand by phone what to do

    i was just copying my data from stand by phone by using phone to phone data transfer but phone also locked with i cloud login of stand by phone what to do

    If it's a hardware problem, then the phone will need to be replaced.
    There is no magic that can fix a hardware problem.

  • Sales Order Creation using LSMW IDOC method.. ( Custome Interface)

    Hi ABAP'rs,
                     Please provide me LSMW steps for creating Sales Order using IDOC method.
                            Thanks and Regards,
                                                  Param.

    LSMW-IDOC in General
    LSMW – Step by Step Guide: Legacy System Migration Workbench is an R/3 Based tool for data transfer from legacy to R/3 for one time or periodic transfer.
    Basic technique is Import data from Spreadsheet / Sequential file, convert from source format to target format and import into R/3 database. LSMW not part of standard R/3, if we need this product email [email protected]
    Advantages of LSMW:
    • Most of the functions are within R/3, hence platform independence.
    • Quality and data consistency due to standard import techniques.
    • Data mapping and conversion rules are reusable across projects.
    • A variety of technical possibilities of data conversion.
    • Generation of the conversion program on the basis of defined rules
    • Interface for data in spreadsheet format.
    • Creation of data migration objects on the basis of recorded transactions.
    • Charge-free for SAP customers and partners.
    Working With LSMW:
    Use TCODE LSMW
    Objects of LSMW:
    •Project – ID with max of 10 char to Name the data transfer project.
    • Subproject – Used as further structuring attribute.
    • Object – ID with max of 10 Characters, to name the Business object .
    • Project can have multiple sub projects and subprojects can have multiple objects.
    • Project documentation displays any documentation maintained for individual pop ups and processing steps
    User Guide: Clicking on Enter leads to interactive user guide which displays the Project name, sub project name and object to be created.
    Object type and import techniques:
    • Standard Batch / Direct input.
    • Batch Input Recording
       o If no standard programs available
       o To reduce number of target fields.
       o Only for fixed screen sequence.
    • BAPI
    • IDOC
    o Settings and preparations needed for each project 
    Preparations for IDOC inbound processing:
    • Choose settings -> IDOC inbound processing in LSMW
    • Set up File port for file transfer, create port using WE21.
    • Additionally set up RFC port for submitting data packages directly to function module IDoc_Inbound_Asynchronous, without creating a file during data conversion.
    • Setup partner type (SAP recommended ‘US’) using WE44.
    • Maintain partner number using WE20.
    • Activate IDOC inbound processing.
    • Verify workflow customizing.
    Steps in creating LSMW Project:
    • Maintain attributes – choose the import method.
    • Maintain source structure/s with or without hierarchical relations. (Header, Detail)
    • Maintain source fields for the source structures. Possible field types – C,N,X, date, amount and packed filed with decimal places.
    • Fields can be maintained individually or in table form or copy from other sources using upload from a text file
    • Maintain relationship between source and target structures.
    • Maintain Field mapping and conversion rules
    • For each Target field the following information is displayed:
    o Field description
    o Assigned source fields (if any)
    o Rule type (fixed value, translation etc.)
    o Coding.
    o Some fields are preset by the system & are marked with Default setting.
    • Maintain Fixed values, translations, user defined routines – Here reusable rules can be processed like assigning fixed values, translation definition etc.
    • Specify Files
    o Legacy data location on PC / application server
    o File for read data ( extension .lsm.read)
    o File for converted data (extension .lsm.conv)
    • Assign Files – to defined source structures
    • Read data – Can process all the data or part of data by specifying from / to transaction numbers.
    • Display read data – To verify the input data being read 
    Convert Data – Data conversion happens here, if data conversion program is not up to date, it gets regenerated automatically.
    • Display converted data – To verify the converted data
    Import Data – Based on the object type selected
    • Standard Batch input or Recording
    o Generate Batch input session
    o Run Batch input session
    • Standard Direct input session
    o Direct input program or direct input transaction is called
    BAPI / IDOC Technique:
    • IDOC creation
    o Information packages from the converted data are stored on R/3 Database.
    o system assigns a number to every IDOC.
    o The file of converted data is deleted.
    • IDOC processing
    o IDOCS created are posted to the corresponding application program.
    o Application program checks data and posts in the application database.
    Finally Transport LSMW Projects:
    • R/3 Transport system
    o Extras ->Create change request
    o Change request can be exported/imported using CTS
    • Export Project
    o Select / Deselect part / entire project & export to another R/3 system
    • Import Project
    o Exported mapping / rules can be imported through PC file
    o Existing Project data gets overwritten
    o Prevent overwriting by using
    ‘Import under different name
    • Presetting for Inbound IDOC processing not transportable.
    Reward if useful.
    regards
    santhosh reddy

  • Data transfer thru lsmw via bapi

    how to perform data transfer thru lsmw via bapi.
    Thanks.
    Regards
    Rama

    HI
    BAPI stands for Business API(Application Program Interface).
    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
    A BAPI are standard SAP function modules provided by SAP for remote access. Also they are part of Businees Objest Repository(BOR).
    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) such as VB or JAVA. in this case u only specify the business object and its method from external system in BAPI there is no direct system call. while RFC are direct system call Some BAPIs provide basic functions and can be used for most SAP business object types. These BAPIs should be implemented the same for all business object types. Standardized BAPIs are easier to use and prevent users having to deal with a number of different BAPIs. Whenever possible, a standardized BAPI must be used in preference to an individual BAPI.
    The following standardized BAPIs are provided:
    Reading instances of SAP business objects
    GetList ( ) With the BAPI GetList you can select a range of object key values, for example, company codes and material numbers.
    The BAPI GetList() is a class method.
    GetDetail() With the BAPI GetDetail() the details of an instance of a business object type are retrieved and returned to the calling program. The instance is identified via its key. The BAPI GetDetail() is an instance method. BAPIs that can create, change or delete instances of a business object type
    The following BAPIs of the same object type have to be programmed so that they can be called several times within one transaction. For example, if, after sales order 1 has been created, a second sales order 2 is created in the same transaction, the second BAPI call must not affect the consistency of the sales order 2. After completing the transaction with a COMMIT WORK, both the orders are saved consistently in the database.
    Create( ) and CreateFromData! ( )
    The BAPIs Create() and CreateFromData() create an instance of an SAP business object type, for example, a purchase order. These BAPIs are class methods.
    Change( )
    The BAPI Change() changes an existing instance of an SAP business object type, for example, a purchase order. The BAPI Change () is an instance method.
    Delete( ) and Undelete( ) The BAPI Delete() deletes an instance of an SAP business object type from the database or sets a deletion flag.
    The BAPI Undelete() removes a deletion flag. These BAPIs are instance methods.
    Cancel ( ) Unlike the BAPI Delete(), the BAPI Cancel() cancels an instance of a business object type. The instance to be cancelled remains in the database and an additional instance is created and this is the one that is actually canceled. The Cancel() BAPI is an instance method.
    Add<subobject> ( ) and Remove<subobject> ( ) The BAPI Add<subobject> adds a subobject to an existing object inst! ance and the BAPI and Remove<subobject> removes a subobject from an object instance. These BAPIs are instance methods.
    BAPI-step by step
    http://www.sapgenie.com/abap/bapi/example.htm
    list of all bapis
    http://www.planetsap.com/LIST_ALL_BAPIs.htm
    for BAPI's
    http://www.sappoint.com/abap/bapiintro.pdf
    http://www.sappoint.com/abap/bapiprg.pdf
    http://www.sappoint.com/abap/bapiactx.pdf
    http://www.sappoint.com/abap/bapilst.pdf
    http://www.sappoint.com/abap/bapiexer.pdf
    http://service.sap.com/ale
    http://service.sap.com/bapi
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf
    http://www.planetsap.com/Bapi_main_page.htm
    http://www.topxml.com/sap/sap_idoc_xml.asp
    http://www.sapdevelopment.co.uk/
    http://www.sapdevelopment.co.uk/java/jco/bapi_jco.pdf
    Also refer to the following links..
    www.sappoint.com/abap/bapiintro.pdf
    www.sap-img.com/bapi.htm
    www.sap-img.com/abap/bapi-conventions.htm
    www.planetsap.com/Bapi_main_page.htm
    www.sapgenie.com/abap/bapi/index.htm
    Checkout !!
    http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
    http://techrepublic.com.com/5100-6329-1051160.html#
    http://www.sap-img.com/bapi.htm
    http://www.sap-img.com/abap/bapi-conventions.htm
    http://www.sappoint.com/abap/bapiintro.pdf
    u can check the below the material also
    Example Code
    U need to give the step_nr, item_nr, cond_count and cond_type so the correct conditon will be updated. If no condition exists for the given parameters, a new condition will be created.
    U can find these parameters for a particular condition type in table KONV.
    *& Form saveTransactionJOCR
    text
    --> p1 text
    <-- p2 text
    FORM saveTransactionJOCR .
    data: salesdocument like BAPIVBELN-VBELN,
    order_header_inx like bapisdh1x,
    order_header_in like bapisdh1,
    return type standard table of bapiret2 with header line,
    conditions_in type standard table of bapicond with header line,
    conditions_inx type standard table of bapicondx with header line,
    logic_switch like BAPISDLS,
    step_nr like conditions_in-cond_st_no,
    item_nr like conditions_in-itm_number,
    cond_count like conditions_in-cond_count,
    cond_type like conditions_in-cond_type.
    salesdocument = wa_order_information-VBELN.
    LOGIC_SWITCH-COND_HANDL = 'X'.
    order_header_inx-updateflag = 'U'.
    conditions
    clear conditions_in[].
    clear conditions_inx[].
    clear: step_nr,
    item_nr,
    cond_count,
    cond_type.
    step_nr = '710'.
    item_nr = '000000'.
    cond_count = '01'.
    cond_type = 'ZCP2'.
    CONDITIONS_IN-ITM_NUMBER = item_nr.
    conditions_in-cond_st_no = step_nr.
    CONDITIONS_IN-COND_COUNT = cond_count.
    CONDITIONS_IN-COND_TYPE = cond_type.
    CONDITIONS_IN-COND_VALUE = 666.
    CONDITIONS_IN-CURRENCY = 'EUR'.
    append conditions_in.
    CONDITIONS_INX-ITM_NUMBER = item_nr.
    conditions_inx-cond_st_no = step_nr.
    CONDITIONS_INX-COND_COUNT = cond_count.
    CONDITIONS_INX-COND_TYPE = cond_type.
    CONDITIONS_INX-UPDATEFLAG = 'U'.
    CONDITIONS_INX-COND_VALUE = 'X'.
    CONDITIONS_INX-CURRENCY = 'X'.
    append conditions_inx.
    CALL FUNCTION 'BAPI_SALESORDER_CHANGE'
    EXPORTING
    SALESDOCUMENT = salesdocument
    ORDER_HEADER_IN = order_header_in
    ORDER_HEADER_INX = order_header_inx
    LOGIC_SWITCH = logic_switch
    TABLES
    RETURN = return
    CONDITIONS_IN = conditions_in
    CONDITIONS_INX = conditions_inx
    if return-type ne 'E'.
    commit work and wait.
    endif.
    ENDFORM. " saveTransactionJOCR
    Bdc to Bapi
    The steps to be followed are :
    1. Find out the relevant BAPI (BAPI_SALESORDER_CHANGE for VA02).
    [for VA01 use BAPI_SALESORDER_CREATEFROMDAT2]
    2. Create a Z program and call the BAPi (same as a Funtion module call).
    2. Now, if you see this BAPi, it has
    -> Importing structures.
    eg: SALESDOCUMENT: this will take the Sales order header data as input.
    -> Tables parameters:
    eg: ORDER_ITEM_IN: this will take the line item data as input.
    Note :
    Only specify fields that should be changed
    Select these fields by entering an X in the checkboxes
    Enter a U in the UPDATEFLAG field
    Always specify key fields when changing the data, including in the checkboxes
    The configuration is an exception here. If this needs to be changed, you need to complete it again fully.
    Maintain quantities and dates in the schedule line data
    Possible UPDATEFLAGS:
    U = change
    D = delete
    I = add
    Example
    1. Delete the whole order
    2. Delete order items
    3. Change the order
    4. Change the configuration
    Notes
    1. Minimum entry:
    You must enter the order number in the SALESDOCUMENT structure.
    You must always enter key fields for changes.
    You must always specify the update indicator in the ORDER_HEADER_INX.
    2. Commit control:
    The BAPI does not run a database Commit, which means that the application must trigger the Commit so that the changes are read to the database. To do this, use the BAPI_TRANSACTION_COMMIT BAPI.
    For further details... refer to the Function Module documentation for the BAPi.
    Bapi to VB(Visual Basic)
    Long back I had used the following flow structure to acheive the same.
    Report -> SM59 RFC destination -> COM4ABAP -> VB.exe
    my report uses the rfc destination to create a COM session with com4abap. com4abap calls the vb.exe and manages the flow of data between sap and vb exe.
    You need to have com4abap.exe
    If com4abap is installed you will find it in sapgui installatin directory , C:\Program Files\SAPpc\sapgui\RFCSDK\com4abap.
    else refer OSS note 419822 for installation of com4abap
    after making the settings in com4abap to point to the vb program and setting up rfc destination in sm59 to point to com4abap session , you can use the following function modules to call the vb code.
    for setting up com4abap and rfc destination please refer to the documentation for com4abap.
    Invoke NEW DCOM session
    call function 'BEGIN_COM_SESSION'
    exporting
    service_dest = service_dest "(this will be a RFC destination created in SM59)
    importing
    worker_dest = worker_dest
    exceptions
    connect_to_dcom_service_failed = 1
    connect_to_dcom_worker_failed = 2
    others = 3.
    call function 'create_com_instance' destination worker_dest
    exporting
    clsid = g_c_clsid
    typelib = g_c_typelib
    importing
    instid = g_f_oid
    exceptions
    communication_failure = 1 message g_f_msg
    system_failure = 2 message g_f_msg
    invalid_instance_id = 3
    others = 4.
    call function 'com_invoke' destination worker_dest
    exporting
    %instid = g_f_oid
    %method = 'UpdatePDF'
    sntemp = g_v_const_filent
    snsysid = sy-sysid
    snflag = 'N'
    tables
    rssaptable = g_t_pdfdetail1
    %return = g_t_pdfdetail1 "t_test
    exceptions
    communication_failure = 1 message g_f_msg
    system_failure = 2 message g_f_msg
    invalid_instance_id = 3
    others = 4.
    then close the com session , using
    FM delete_com_instance
    FM END_COM_SESSION
    http://help.sap.com/saphelp_nw2004s/helpdata/en/7e/5e114a4a1611d1894c0000e829fbbd/frameset.htm
    http://www.sapgenie.com/abap/bapi/example.htm
    http://help.sap.com/saphelp_46c/helpdata/en/9b/417f07ee2211d1ad14080009b0fb56/frameset.htm
    http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
    http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
    http://techrepublic.com.com/5100-6329-1051160.html#
    http://www.sap-img.com/bapi.htm
    http://www.sap-img.com/abap/bapi-conventions.htm
    http://www.sappoint.com/abap/bapiintro.pdf
    http://www.sapgenie.com/abap/bapi/example.htm
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf
    http://techrepublic.com.com/5100-6329-1051160.html#
    http://www.sap-img.com/bapi.htm
    http://www.sap-img.com/abap/bapi-conventions.htm
    http://www.sappoint.com/abap/bapiintro.pdf
    BAPI - BAPIs (Business Application Programming Interfaces) are the standard SAP interfaces. They play an important role in the technical integration and in the exchange of business data between SAP components, and between SAP and non-SAP components. BAPIs enable you to integrate these components and are therefore an important part of developing integration scenarios where multiple components are connected to each other, either on a local network or on the Internet.
    BAPIs allow integration at the business level, not the technical level. This provides for greater stability of the linkage and independence from the underlying communication technology.
    LSMW- No ABAP effort are required for the SAP data migration. However, effort are required to map the data into the structure according to the pre-determined format as specified by the pre-written ABAP upload program of the LSMW.
    The Legacy System Migration Workbench (LSMW) is a tool recommended by SAP that you can use to transfer data once only or periodically from legacy systems into an R/3 System.
    More and more medium-sized firms are implementing SAP solutions, and many of them have their legacy data in desktop programs. In this case, the data is exported in a format that can be read by PC spreadsheet systems. As a result, the data transfer is mere child's play: Simply enter the field names in the first line of the table, and the LSM Workbench's import routine automatically generates the input file for your conversion program.
    The LSM Workbench lets you check the data for migration against the current settings of your customizing. The check is performed after the data migration, but before the update in your database.
    So although it was designed for uploading of legacy data it is not restricted to this use.
    We use it for mass changes, i.e. uploading new/replacement data and it is great, but there are limits on its functionality, depending on the complexity of the transaction you are trying to replicate.
    The SAP transaction code is 'LSMW' for SAP version 4.6x.
    Check your procedure using this Links.
    BAPI with LSMW
    http://esnips.com/doc/ef04c89f-f3a2-473c-beee-6db5bb3dbb0e/LSMW-with-BAPI
    For document on using BAPI with LSMW, I suggest you to visit:
    http://www.****************/Tutorials/LSMW/BAPIinLSMW/BL1.htm
    What are the methods to migrate data from a legacy system to SAP?
    LSMW is used for migrating data from a legacy system to SAP system, or from one SAP system to another.
    Apart from standard batch/direct input and recordings, BAPI and IDocs are available as additional import methods for processing the legacy data.
    The LSMW comprises the following main steps:
    Read data (legacy data in spreadsheet tables and/or sequential files).
    Convert data (from the source into the target format).
    Import data (to the database used by the R/3 application.
    But, before these steps, you need to perform following steps :
    Define source structure : structure of data in the source file.
    Define target structure : structure of SAP that receives data.
    Field mapping: Mapping between the source and target structure with conversions, if any.
    Specify file: location of the source file
    Of all the methods used for data migration like BDC, LSMW , Call Transaction which one is used most of the time?
    How is the decision made which method should be followed? What is the procedure followed for this analysis?
    All the 3 methods are used to migrate data. Selection of these methods depends on the scenario, amount of data need to transfer. LSMW is a ready tool provided by SAP and you have to follow some 17 steps to migrate master data. While in BDCs Session method is the better choice because of some advantages over call transaction. But call transaction is also very useful to do immediate updation of small amout of data. (In call transaction developer has to handle errors).
    SO Bottom line is make choice of these methods based of real time requirements.
    These methods are chosen completely based on situation you are in. Direct input method is not available for all scenario, else, they are the simplest ones. In batch input method ,you need to do recording for the transaction concerned. Similarly, IDoc, and BAPI are there, and use of these need to be decided based on the requirement.
    Try to go through the some material on these four methods, and implement them. You will then have a fair idea about when to use which
    You can create lsmw for data migration as follows (using session method):
    Example for xk01 (create vendor)
    Initially there will be 20 steps but after processing 1 step it will reduced to 14 for session method.
    1. TCode : LSMW.
    2. Enter Project name, sub project name and object name.
    Execute.
    3. Maintain object attributes.
    Execute
    select Batch Input recording
    goto->Recording overview
    create
    recording name.
    enter transaction code.
    start recording
    do recording as per ur choice.
    save + back.
    enter recording name in lsmw screen.
    save + back
    Now there will be 14 steps.
    2. MAINTAIN SOURCE STRUCTURES.
    Here you have to enter the name of internal table.
    display change
    create
    save + back
    3. MAINTAIN SOURCE FIELDS.
    display change
    select structure
    source_fields->copy fields.
    a dialogue window will come .
    select -> from data file
    apply source fields
    enter No. of fields
    length of fields
    attach file
    save + back
    4. MAINTAIN STRUCTURE RELATIONS
    display change
    save + back
    5. MAINTAN FIELD MAPPING & CONVERSION RULE
    display change
    click on source field, select exact field from structue and enter
    repeat these steps for all fields.
    save+back
    6. MAINTAIN FIXED VALUES, TRANSACTION, USER DEFINED
    execute
    save + back
    7. SPECIFY FILES.
    display change
    click on legacy data
    attah flat file
    give description
    select tabulatore
    enter
    save + back
    8. ASSIGN FILE
    execute
    display change
    save + back
    9. IMPORT DATA.
    execute
    display change
    save + back
    10. DISPLAY IMPORTED DATA
    enter ok, it willl show records only.
    back
    11. CONVERT DATA
    execute
    display change
    save + back
    12. DISPLAY CONVERTED DATA
    execute
    display change
    save + back
    13. CREATE BATCH INPUT SESSION
    tick keep batch input folder
    F8
    back
    14. RUN BATCH INPUT SESSION.
    sm35 will come
    Object name will be shown here
    select object & process
    Regards
    Pavan

  • Create Purchase info record using LSMW idoc method

    Hello Friends,
    I am trying to update Purchase Info records using LSMW Standard program RM06IBI0.
    But it is not updating the condition price details and scale Quantity.
    For that the  form  suggessted LSMW IDOC method. with : Message Type         COND_A / COND_A02.
    But i dont know is the info record created earlier to this step or else we can create both using this method
    at a time ?  Does anybody please suggest.
    ( Actually Purchase Info record created using transaction  ME11 ).
    Regards,
    Phaneendra

    you first create the info record and subsequently you load the conditions.
    become familiar with the condition tables and its key first. Check How table A017 and A018 are maintained.
    Intresting is the field VAKEY which is actually the link to your info record.
    This is a combination of vendor, material, purchasing org, plant , and info record indicator.
    data:  begin of ZZVARKEYA,
            ZLIFNR like LFM1-LIFNR,
            ZMATNR like MARc-MATNR,
            ZEKORG like LFM1-EKORG,
            ZWERKS like MARC-WERKS,
            ZINFTYP like EINE-ESOKZ,
            end of zzvarkeyA.

  • Import Product Price and Condition using LSMW IDoc method

    Hi Friends,
    I am working on the Product Import to CRM from flat file using LSMW IDoc method using the "CRMXIF_PRODUCT_MATERIAL_SAVE" message type.
    I am able to import the entire product with its required details except the Price and its conditions.
    Can anyone please let me know which structure or with message type to be used to import the Product Price and condition using the IDoc method.
    Please pass on your valuable comments.
    Thanking you,
    Naveen

    Hi Naveen.
    I am doing the same thing but only the product gets created and the details like short text, unit etc. do not get populated. The idoc gets processed successfuly. Can you share the fields that are required to be mapped or are mandatory.

Maybe you are looking for