Sort, sum & preprocess in FINSTA01 IDOC

HI,
I have an issue in lockbox processing.
When data is received from bank into SAP, FINSTA01 idoc gets created in SAPThis idoc contains check details and invoice reference details. There is a preprocessor which sorts and sums invoice references. But, I observed that invoices are not getting sorted and summed in idocs.
Please help me out to find out the reason why this preprocessor is not working as expected.
Thanks & Regards,
Bharath Kumar

Similar Messages

  • SAP Lockbox Processing (EDI 823) via FINSTA01 IDoc

    I am trying to implement lockbox processing in SAP using the FINSTA01 IDoc. I have not found any documentation regarding the data mapping. Does anybody have experience with this? If so, I could really use a sample data mapping document.
    Any help would be appreciated.

    Hi,
    Sorry,
    Three times the same URL  has copied,
    Click to the URL and check :
    http://help.sap.com/saphelp_erp2005/helpdata/en/57/f1fc3768b56d00e10000009b38f842/frameset.htm
    1) Importing Lockbox Data
    2) Postprocess Lockbox Data
    This might help you,
    http://ifr.sap.com/catalog/query.asp?namespace=urn:sap-com:ifr:FI:470&type=idoc&name=FINSTA01
    Regards
    Agasthuri Doss

  • FINSTA01 IDOC mapping

    Hi ,
    Are there any standard mappings available for FINSTA file format to FINSTA01 IDOC ?
    Regards
    Saravana

    Hi SaravanaKumar
    My Name is Ashokkumar
    Currently in Denmark. I am in very urgent need of the mapping for EDIFACT FINSTA to SAP R/3 FINSTA01.
    I hope you would have somehow managed to get the mapping file.  Shall I request you to send me the mapping file I need it very badly now.
    Thanks in Advance
    Ashok ([email protected])
    +0045 23212447 (mobile)

  • FINSTA01 IDOC configuration

    Hi Guys,
    Just wanted to check what are the configuration required at FI level for FINSTA01 Idoc. Any document will be apppreciated.
    my email is [email protected]
    bye ... aj

    Dear boghendra
    check the links
    [IDoc Structure |http://help.sap.com/saphelp_46c/helpdata/en/92/58ca56417011d189ec0000e81ddfac/frameset.htm]
    [General Construction of the IDoc|http://help.sap.com/saphelp_46c/helpdata/en/1a/0e37cd539911d1898b0000e8322d00/frameset.htm]
    thanks
    G. Lakshmipathi

  • FINSTA01 idoc in EDI

    Hi All,
         Presently im working on edi, Are there any mappings available for <b>EDI 823 file</b> format to <b>FINSTA01 IDOC ?</b> in EDI
    I hope you would have somehow managed to get the mapping file. if u have any related stuff ie: edi823 file  to incoming edi ( finsta01 idoc in SAP ). Please send me to
       Email [email protected]
    Thanks in Advance,
    Nirupama reddy

    Nirupama,
    Are you able to get the mappings for X12 to FINSTA01. If u did, can you help me with that. my email: [email protected]
    Manohar,
    The link you gave does not work.
    Thanks,
    Gopi

  • Activate standard sum segment in INVOIC iDoc

    Dear experts,
    I am not sure if I am in the right board but I hope you can point me in the correct direction.
    I have to map INVOICE02 to INVOIC EDIFACT format and in the sum segments of the EDIFACT message
    I need a sum of all discounts.
    Now in WE60 I checked the INVOIC02 structure and saw that in E1EDS01, QUALF='020' I get the sum of "allowances/charges".
    But in my iDoc example I do not have an E1EDS01, QUALF='020'.
    How can I "activate" or add that standard sum segment to my INVOICE02 iDoc?
    Thank you for your help and best regarsd,
    Peter

    Hello TW Typewriter,
    thank you for your comment. Yes, other fields are populating. Yes, there are discounts given in the invoice.
    I checked one of the invoices in SAP ERP and in the head under "Conditions" I can see that there are 2 different Z-rebates and field that contains the sum of the two rebates.
    But that sum I can't find in the iDoc.
    I guess I have to sum up discounts myself implementing a user exit and looping over all the positions with possible discounts.
    Thank you again and best regards,
    Peter

  • Numbers is not retaining the values of my sorted SUMs in a column.

    I just switched to Numbers 3.0.1
    I have a two tables: Table 1 has a large set of data. Table 2 has various sums of the data from Table 1 (added by using the SUM function). Pretty simple stuff.
    My problem is when I go to sort the data (SUMs from Table 1) in Table 2 using the ascending/descending option all of the data in the column changes and makes no sense.
    Older version of Numbers just sorted the data in the column numerically (ascending or descending).
    Does anyone have a fix for this?

    I find the new way Numbers handles cell references during a sort to be a little odd.  First let's talk your problem then I'll mention another.
    I think for your problem, you need to use "preserve row" on all your cell references.  Otherwise the references become "relative".  For example, if you have =SUM(Table 1::A2:A3) in cell B4 of Table 1 before the sort and it moves to cell B5 after the sort, the formula will become =SUM(Table 1::A3:A4). The formula moved down one row so the cell references also moved down one row.  Seems like a strange result but you can prevent it by using =SUM(Table 1::A$2:A$3)
    For the other problem, let's say you leave Table 2 (the sums) alone and sort Table 1 instead. This also changes all the sums. It makes sense what it is doing but I haven't yet figured out a way to make it do what it used to do.
    If you look at your SUM formulas, they will stay exactly the same after the sort.  If it was =SUM(Table 1::A1:A10) before the sort it will still be exactly that after the sort.  But now you have different numbers in those cells in Table 1 so your sum is different.  In Numbers '09, it would have turned into something like =SUM(A5,A9,A2:A3,A19,.....) as it readjusted to sum up the exact same cells as before. I can''t figure out how to make a SUM or an addition or any other calculation follow a cell around during a sort.

  • Getting FLBP to run after posting IDOC of type FINSTA01

    Hi experts:
    We are getting an EDI 820 feed from Chase of customer payments. That feed is taken by PI an an IDOC for each payment is created of type FINSTA01. After it processes we need the automatic matching program FLBP to run immediately after the status 53 of the IDOC to clear open invoices.
    1) Is there a segment field I can populate in FINSTA01 to make this happen automatically - I didn' see one.
    2) Is there a user exit where I can set a parameter to force the FLBP to take place at the end? If so, what user exit and what do I need to set?
    3) If not, is there a user exit that occurs after the successful processing (status 53) of the IDOC, where I could call that transaction? I can't find one.
    I really don't want to create a custom IDOC for this to tack that code on the end of the process. My fallback solution is to create a job to run FLBP but I can't tie it to the successful completion of a FINSTA01 IDOC.
    Any ideas would be much appreciated.
    Thanks,
    Scott

    no answer

  • Open Item Clearing IDOC

    Hello,
    Does anyone know if there's an idoc that can clear open items as you would in a t-code like F-32?  I know of the LOCKBX FINSTA01 idoc, but we don't need the lockbox piece and just want to do a post with clearing.
    Appreciate the help,
    Kevin

    You can try to use REMADV (PEXR2002) idoc but it is a payment also. If it is just a clearing that you want to do, why don't you use F.13 ?
    Or create your own idoc, doing a call trasaction of F-32.

  • Idoc related issues

    Hi
    We have designed an alv report that will display idoc details for FINSTA01 idoc.
    On clicking release button on the alv output.
    I have to work on the following requirement.
    "Map FINSTA01 to PEXR2001 to create idoc. Show the report with new idoc no and old idoc no"
    Is there any function module to map the above idocs? How we will do that. Please give me details.After mapping how can I generate a new PEXR2001 idoc programmatically.
    Regards,
    Sucheta.

    Hi
    I have used the following code for this functionality. Please suggest where I am wrong.
    CALL FUNCTION 'IDOC_READ_COMPLETELY'           "To read the segments of finst01 idoc
      EXPORTING
        DOCUMENT_NUMBER                = tb_output-idoc
    IMPORTING
       IDOC_CONTROL                   = wa_edidc
      NUMBER_OF_DATA_RECORDS         =
      NUMBER_OF_STATUS_RECORDS       =
    TABLES
      INT_EDIDS                      =
       INT_EDIDD                      = tb_edidd
    EXCEPTIONS
       DOCUMENT_NOT_EXIST             = 1
       DOCUMENT_NUMBER_INVALID        = 2
       OTHERS                         = 3
    IF SY-SUBRC <> 0.
    MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
             WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
    ENDIF.
         * Get data from the Idoc segments
    data: wa_edidd like line of tb_edidd.
    data: wa_Z1EXNA12 type Z1EXNA12, wa_Z1EXNA13 type Z1EXNA13, wa_Z1EXNA14 type Z1EXNA14,
          wa_Z1EXNA15 type Z1EXNA15, wa_Z1EXNA16 type Z1EXNA16, wa_E1IDKU1 type E1IDKU1,
          wa_E1EDK03 type E1EDK03, wa_E1EDK02 type E1EDK02,
          WA_E1IDT01 type E1IDT01 , wa_E1IDB02 type E1IDB02, wa_E1EDKA1 type E1EDKA1,
          wa_E1IDPU1 type E1IDPU1 , wa_E1IDKU7 type E1IDKU7.
          LOOP AT tb_edidd INTO wa_edidd.
            CASE wa_edidd-segnam.
              WHEN 'E1IDKU1'.
              wa_E1IDKU1 = wa_edidd-sdata.
              WHEN 'E1EDK03'.
              wa_E1EDK03 = wa_edidd-sdata.
              WHEN 'E1EDK02'.
              wa_E1EDK02 = wa_edidd-sdata.
              WHEN 'E1IDT01'.
              wa_E1IDT01 = wa_edidd-sdata.
              WHEN 'E1IDB02'.
              wa_E1IDB02 = wa_edidd-sdata.
              WHEN 'E1EDKA1'.
              wa_E1EDKA1 = wa_edidd-sdata.
              WHEN 'E1IDPU1'.
              wa_E1IDPU1 = wa_edidd-sdata.
              WHEN 'E1IDKU7'.
              wa_E1IDKU7 = wa_edidd-sdata.
              WHEN 'Z1EXNA12'.
              wa_Z1EXNA12 = wa_edidd-sdata.
              when 'Z1EXNA13'.
              wa_Z1EXNA13 = wa_edidd-sdata.
              when 'Z1EXNA14'.
              wa_Z1EXNA14 = wa_edidd-sdata.
              when 'Z1EXNA15'.
              wa_Z1EXNA15 = wa_edidd-sdata.
              when 'Z1EXNA16'.
              wa_Z1EXNA16 = wa_edidd-sdata.
            endcase.
            clear wa_edidd.
          endloop.
          data: tb_idoc_contrl type standard table of edidc with header line,
                tb_idoc_data type standard table of edidd with header line,
                tb_idoc_status type standard table of BDIDOCSTAT with header line,
                tb_ret_var type standard table of BDWFRETVAR with header line,
                tb_serial_info type standard table of BDI_SER with header line.
           clear wa_edidd.
          loop at tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1IDKU1'.
           wa_E1IDKU1-BGMTYP = 'PEX'.
           wa_E1IDKU1-BGMNAME = 'REMADV'.
           tb_idoc_data-sdata = wa_E1IDKU1.
           append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1EDK03'.
           tb_idoc_data-sdata = wa_E1EDK03.
           append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1EDK02'.
           tb_idoc_data-sdata = wa_E1EDK02.
           append tb_idoc_data.
         tb_idoc_data-DOCNUM = wa_edidc-docnum.
          tb_idoc_data-segnam = 'E1IDK02'.
          tb_idoc_data-E1IDK02 = wa_E1IDK02.
          append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1IDT01'.
           tb_idoc_data-sdata = wa_E1IDT01.
           append tb_idoc_data.
            tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1IDB02'.
           tb_idoc_data-sdata = wa_E1IDB02.
           append tb_idoc_data.
          tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1EDKA1'.
           tb_idoc_data-sdata = wa_E1EDKA1.
           append tb_idoc_data.
            tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1IDPU1'.
           wa_E1IDPU1-DOCNAME = 'PEX'.
           tb_idoc_data-sdata = wa_E1IDPU1.
           append tb_idoc_data.
          tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'E1IDKU7'.
           tb_idoc_data-sdata = wa_E1IDKU7.
           append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'Z1EXNA12'.
           tb_idoc_data-sdata = wa_Z1EXNA12.
           append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'Z1EXNA13'.
            tb_idoc_data-sdata = wa_Z1EXNA13.
            append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'Z1EXNA14'.
            tb_idoc_data-sdata = wa_Z1EXNA14.
            append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'Z1EXNA15'.
            tb_idoc_data-sdata = wa_Z1EXNA15.
            append tb_idoc_data.
           tb_idoc_data-DOCNUM = wa_edidc-docnum.
           tb_idoc_data-segnam = 'Z1EXNA16'.
            tb_idoc_data-sdata = wa_Z1EXNA16.
           append tb_idoc_data.
          endloop.
          move wa_edidc to tb_idoc_contrl.
           wa_edidc-DOCTYP = 'PEXR2NA1'.
           wa_edidc-MESTYP = 'REMADV'.
           wa_edidc-IDOCTP = 'PEXR2002'.
           wa_edidc-cimtyp = 'PEXR2NA1'.
    DATA: W_DOCNUM TYPE EDIDC-DOCNUM.
           CALL FUNCTION 'IDOC_WRITE_AND_START_INBOUND'
             EXPORTING
               I_EDIDC                             = WA_EDIDC
             DO_COMMIT                           = 'X'
            IMPORTING
              DOCNUM                              = W_DOCNUM
             ERROR_BEFORE_CALL_APPLICATION       =
             TABLES
               I_EDIDD                             = TB_IDOC_DATA
           EXCEPTIONS
             IDOC_NOT_SAVED                      = 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.
    data: tb_status type table of  BDIDOCSTAT with header line.
    append wa_edidc to tb_idoc_contrl.
    CALL FUNCTION 'IDOC_INPUT_REMADV'
      EXPORTING
        INPUT_METHOD                = 'A'
        MASS_PROCESSING             = ' '
    IMPORTING
      WORKFLOW_RESULT             =
      APPLICATION_VARIABLE        =
      IN_UPDATE_TASK              =
      CALL_TRANSACTION_DONE       =
      TABLES
        IDOC_CONTRL                 =  tb_idoc_contrl
        IDOC_DATA                   = TB_IDOC_DATA
        IDOC_STATUS                 = tb_idoc_status
        RETURN_VARIABLES            = tb_ret_var
        SERIALIZATION_INFO          = tb_serial_info
    EXCEPTIONS
      WRONG_FUNCTION_CALLED       = 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.
         endif.
    The problem is tb_ret_var is returning nothing. When I am testing the newly generated idoc w_docnum of 'IDOC_WRITE_AND_START_INBOUND' fm in we19 it is generating a new idoc no. But the status of that idoc is 56. I am not getting the payment advice no.
    Please suggest what to do next
    regards
    Sucheta

  • MT940 to FINSTA01 mapping

    Dear all,
    We want to map standard MT940 file format to FINSTA01 Idoc to post Electronic Bank statement in to Sap.
    Does any one know how to map MT940 format to FINSTA01 Idoc ( to which segements and fields of the IDoc ).
    If any of you have information regarding this please do share the information.
    Thanks & Regards,
    Sravan

    That's possibly the best answer
    Just to add, if you have the Idoc already imported into IR, then create a new message mapping object, then import the Idoc message structure as the target message in the mapping. There you should see a few fields marked in "RED" color. Those are fields you must map as they are mandatory fields (occurance 1:1) and without mapping those target fields, you cannot even activate the message mapping object.
    So that way you know which fields you must map on the IDoc side..............for the rest of the fields.....I think Jakub has given you the best suggestion
    Regards,
    Suddha

  • Triggering an idoc

    hi all,
    could someone explain me , different ways to trigger an idoc.
    thanks in advance,
    suma sailaja pvn

    IDoc Types:
    IDoc type structure can consist of several segments, and each segment can consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments and arrangement of the segments. Segments define a set of fields and their format.
    An IDoc is an instance of an IDoc Type and consists of three types of records.
    i.     One Control record: each IDoc has only one control record. The control record contains all the control information about an IDoc, including the IDoc number, the sender and recipient information, and information such as the message type it represents and IDoc type. The control record structure is same for all IDocs.
    ii.     One or Many Data records: An IDoc can have multiple data records, as defined by the IDoc structure. Segments translate into data records, which store application data, such as purchase order header information and purchase order detail lines.
    iii.     One or Many Status records: An IDoc can have multiple status records. Status record helps to determine whether an IDoc has any error.
    Message in IDoc Type:
    A Message represents a specific type of document transmitted between two partners.
    Outbound Process in IDocs:
    Outbound process used the following components to generate an IDoc. A customer model, and IDoc structure, selection programs, filter objects, conversion rules, a port definition, an RFC destination, a partner profile, service programs, and configuration tables.
    The Customer Model:
    A customer model is used to model a distribution scenario. In a customer model, you identify the systems involved in a distribution scenario and the message exchanged between the systems.
    Message control:
    Message control is a cross application technology used in pricing, account determination, material determination, and output determination.  The output determination technique of Message control triggers the ALE for a business document. Message control separates the logic of generating IDocs from the application logic.
    Change Pointers:
    The change pointers technique is based on the change document technique, which tracks changes made to key documents in SAP, such as the material master, customer master and sales order.
    Changes made to a document are recorded in the change document header table CDHDR, and additional change pointers are written in the BDCP table for the changes relevant to ALE.
    IDoc Structure:
    A message is defined for data that is exchanged between two systems. The message type is based on one or more IDoc structures.
    Selection Program:
    Is typically implemented as function modules, are designed to extract application data and create a master IDoc. A selection program exists for each message type. A selection program’s design depends on the triggering mechanism used in the process.
    Filter Objects;
    Filter Objects remove unwanted data for each recipient of the data basing on the recipients requirement.
    Port Definition:
    A port is used in an outbound process to define the medium in which documents are transferred to the destination system. ALE used a Transactional RFC port, which transfers data in memory buffers.
    RFC Destination:
    The RFC destination is a logical name used to define the characteristics of a communication link to a remote system on which a function needs to be executed.
    Partner Profile:
    A partner profile specifies the components used in an outbound process(logical name of the remote SAP system, IDoc Type, message type, TRFC port), an IDoc’s packet size, the mode in which the process sends an IDoc (batch versus immediate), and the person to be notified in case of error.
    Service Programs and Configuration Tables:
    The outbound process, being asynchronous, is essentially a sequence of several processes that work together. SAP provides service programs and configuration tables to link these programs and provide customizing options for an outbound process.
    Process flow for Distributing Transactional Data:
    Transactional data is distributed using two techniques: with Message control and without message control.
    Process flow for Distributing Master Data:
    Master data between SAP systems is distributed using two techniques: Stand alone Programs and Change Pointers.
    Triggering the Outbound Process via Stand-Alone Programs:
    Stand-Alone programs are started explicitly by a user to transmit data from one SAP system to another. Standard Programs for several master data objects exist in SAP.  Ex. The material master data can be transferred using the RBDSEMAT program or transaction BD10.
    The stand-alone programs provide a selection screen to specify the objects to be transferred and the receiving system. After the stand-alone program is executed, it calls the IDoc selection program with the specified parameters.
    Triggering the Outbound Process via Change Pointers:
    The change pointer technique is used to initiate the outbound process automatically when master data is created or changed.
    A standard program, RBDMIDOC, is scheduled to run on a periodic basis to evaluate the change pointers for a message type and start the ALE process for distributing the master data to the appropriate destination. The RBDMIDOC program reads the table TBDME to determine the IDoc selection program for a message type.
    Processing in the Application Layer:
    The customer distribution model is consulted to make sure that a receiver has been defined for the message to be transmitted. If not, processing ends. If at least one receiver exists, the IDoc selection program reads the master data object from the database and creates a master IDoc from it. The master IDoc is stored in memory. The program then calls the ALE service layer by using the function module MASTER_IDOC_DISTRIBUTE, passing the master IDoc and the receiver information.
    Processing in the ALE Interface Layer:
    Processing in the ALE Layer consists of the following steps:
    •     Receiver Determination: The determination of the receiver is done through Customer Distribution Model.
    •     IDoc Filtering: if an IDoc filter is specified in the distribution model for a receiver, values in the filter are compared against the values in the IDoc data records. If a data record does not meet the filter criteria, it is dropped.
    •     Segment Filtering: For each sender and receiver combination, a set of segments that are not required can be filtered out.
    •     Field conversion: Field values in data records are converted by using the conversion rules specified for the segment.
    •     Version change for segments: Segments are version-controlled. A new version of a segment always contains fields from the preceding version and fields added for the new version. Release in IDoc type field of the partner profile to determine the version of the segment to be generated.
    •     Version change for IDocs: IDocs are also version controlled. The version is determined from the Basic Type field of the partner profile.
    •     Communication IDocs generated: The final IDoc generated for a receiver after all the conversions and filtering operations is the communication IDoc. One master IDoc can have multiple communication IDocs depending on the number of receivers identified and the filter operations performed. IDoc gets the status record with a status code of 01 (IDoc Created).
    •     Syntax check performed: IDoc goes through a syntax check and data integrity validation. If errors found the IDoc get the status of 26 (error during syntax check of IDoc – Outbound). If no errors found the IDoc gets the status 30 (IDoc ready for dispatch – ALE Service).
    •     IDoc dispatched to the communication Layer: In the ALE process, IDocs are dispatched using the asynchronous RFC method, which means that the sending system does not await for data to be received or processed on the destination system. After IDocs have been transferred to the communication layer, they get a status code 01 (Data Passed to Port OK).
    Processing in the Communication Layer:
    To dispatch an IDoc to a destination system, the system reads the port definition specified in the partner profile to determine the destination system, which is then used to read the RFC destination. The RFC destination contains communication settings to log o to the remote SAP system. The sending system calls the INBOUND_IDOC_PROCESS function module asynchronously on the destination system and passes the IDoc data via the memory buffers.
    Inbound Process in IDocs:
    An inbound process used IDoc structure, posting programs, filter objects, conversion rules, a partner profile, service programs, and configuration tables to post an application document from an IDoc.
    Posting Program:
    Posting programs, which are implemented as function modules, read data from an IDoc and create an application document from it. A posting program exists for each message. Each posting program is assigned a process code. A process code can point to a function module or a work flow. In the standard program process codes always point to a function module.
    Ex. The posting program for message type MATMAS is IDOC_INPUT_MATMAS which has a process code MATM.
    Workflow:
    A workflow represents a sequence of customized steps to be carried out for a process. The workflow management system is used to model the sequence, identify information required to carry out the steps and identify the person responsible for the dialog steps.
    Partner Profile;
    A partner profile specifies the components used in an inbound process (partner number, message type, and process code), the mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.
    Process flow for the Inbound process via a Function Module:
    In this process, IDocs are received from another system and passed to the posting function module directly.
    1.     Processing in the communication Layer:
    The IDOC_INBOUND_ASYCHRONOUS program, triggered as a result of an RFC from the sending system, acts as the entry point for all inbound ALE processes. The IDoc to be processed is passed as an input parameter. Control is transferred to the ALE/EDI layer.
    2.     Processing in the ALE/EDI Interface Layer:
    •     Basic integrity check: A basic integrity check is performed on the control record.
    •     Segment Filtering and conversion: Filtering out unwanted segments and carry out any required conversion of field values.
    •     Creation of Application IDoc: The application IDoc is created and stored in the database and a syntax check is performed. If there are errors it gets status code of 60 (Error during Syntax check of IDoc – Inbound). At this point a tangible IDoc, which can be monitored via one of the monitoring transactions, is created and the IDoc gets status code 50 (IDoc Added).
    •     IDoc Marked ready for Dispatch: IDoc gets the status code 64 (IDoc ready to be passed to application).
    •     IDoc is passed to the posting program: The partner profile table is read. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program immediately using the program RBDAPP01.
    3.     Processing in the Posting Module:
    The process code in the partner profile points to a posting module for the specific message in the IDoc. The posting program implemented as a function module either calls a standard SAP transaction by using the Call Transaction command for posting the document or invokes a direct input function module.
    The results of execution are passed back via the function module’s output parameters. If the posting is successful IDoc gets the status code 53 (Application Document Posted) or it gets status code 51 (Error: Application Document Not Posted).
    Reward Points if useful.

  • Posting Idoc from XML port to FTP

    Hello Experts,
    I have a business case, where the xml generated from and xml port has to be posted on to an FTP. Presently we are doing it manually by getting the xml from CG3Y T-Code and posting it on to FTP manually. Is there any way for posting the Idoc.xml directly on to the FTP, without our intreaction?
    Can this be done by customizing the ALE config,s? Or we need to wirte an ABAP code?
    Another concern is that every time, I generate an IDoc, the previous IDoc is over written. Can this process, changed so that the previous dosent get overwritten insted it creates a new xml, every time we tigger and Idoc.
    Thanks,
    Suma

    Hi Suma,
    To FTP the IDoc.xml you can use shell script which will FTP the IDocs to the FTP server. This shell script can be scheduled on the application server at OS level to be executed at a given frequency (say every 10 mins).
    The other way of doing this is maintain the shell script details in the Outbound Trigger of the XML File port and set the radio button in partner profile to Start Subsystem in Outbound parameters tab. This will make the shell script to be executed after the IDoc is written to the XML File port.
    If you are not intersted in writing shell scripting, you can directly use the HTTP xml port. This is very easy to use and you can have tight integration. When ever an Idoc is triggerd this will direclty send it accross the HTTP server and from you can make use of it. On any tomcat you can create a HTTP server. If you are using Websphere product as integraion then, it is directly proived by IBM. I suggest you to go for the HTTP rahter doing it on XML Port.
    You have a disadvantage for XML port that ever time you generate an Idoc it will be over written. So there is chance that you may miss some of the Idoc's.
    Thanks,
    Srikanth

  • Provide the java code for the following scenario.

    Hi Experts,
    I have tried with all the combinations for this scenario. As per my understanding i require java code for the following scenario
    so that it becomes easy........
    I require a Message mapping for this Logic.
    In the Source there are 4 fields and, the Target side, the fields should appear like this.
    Source Structure- File
    Record
    |-> Header
    Order_No
    Date
    |-> Item
    Mat_No
    Quantity
    Target Structure-IDoc
    IDoc
    |-> Header
    |-> Segment
    Delivery_Order_No
    Recv_Date
    |-> Item
    |-> Segment
    Delivery_Order_No
    Material_Num
    Recv_Quantity.
    The Logic is for every Order number an IDOC is generated.And if the Material num matches then the quantity should be added. and important note is that the material numbers are different for every order number. That means if a material number is 2 in the order number A. Then the material number can never be 2 in any of the order numbers.Here is the following with an example for the above scenario.
    For example:-
    we have
    Source Structure- File
    Order-no Date Mat_No Quantity
    1 01/02/2011 A 10
    1 01/02/2011 B 15
    1 01/02/2011 A 10
    2 01/02/2011 C 10
    2 01/02/2011 C 10
    3 01/02/2011 D 20
    3 01/02/2011 D 10
    3 01/02/2011 E 25
    Target Structure-IDoc
    Delivery_Order_No Recv_Date Material_Num Recv_Quantity
    1 01/02/2011 A 20
    1 01/02/2011 B 15
    2 01/02/2011 C 20
    3 01/02/2011 D 30
    3 01/02/2011 E 25
    So for this example total of 5-Idocs created. That means for this example if Order_No is 1 When the Mat_No is A the quantity gets added. For this Scenario 1 IDoc with four Fields 2 in Header(Delivery_Order_No, Recv_Date) and 2 in Item(Material_Num, Recv_Quantity) is generated by adding the quantity field in the Target Side. Similarly if Order_No is 1 when the Mat_No is B then separate IDoc is generated with four Fields 2 in Header(Delivery_Order_No, Recv_Date) and 2 in Item(Material_Num, Recv_Quantity) in the Target Side. Similarly, if Order_No is 2 when the Mat_No is C, an IDoc is generated with four Fields 2 in Header(Delivery_Order_No, Recv_Date) and 2 in Item(Material_Num, Recv_Quantity) by adding the quantity field in the Target Side. ike wise the process goes on upto 3.Kindly do the needy..
    Kindly provide the java code.
    Thanq very much in advance..

    what i have understood from ur example is that u want to generate an idoc for unique combination of  Order-no and Mat_No
    if yes then chk the below mapping..
    change the context of Order_No, Date, Mat_No and Quantity to Record (right click-> context)
    1)
    Order-no
    ----------------------concat[;]---sort----splitbyvalue(valuechanged)-----collapse context---IDoc
    Mat_No
    2)
    Order-no
    --------concat[;]---sort----splitbyvalue(value changed)---collapse context---UDF1--splitbyvalue(each value)--Delivery_Order_No
    Mat_No
    3)
    Order-no
    -----------concat[;]---sortbykey----------------------- \
    Mat_No                       /                            \
    Date--------------- /                                       \
    ----------------------------------------------------------FormatByExample-----collapsecontext---splitbyvalue(each value)----Recv_Date
    Order-no                                                 /
    -----------concat[;]---sort----splitbyvalue(value changed)
    Mat_No
    4)
    Order-no
    --------concat[;]---sort----splitbyvalue(value changed)---collapse context-UDF2--splitbyvalue(each value)--Material_Num
    Mat_No
    5)
    Order-no
    -----------concat[;]---sortbykey
    Mat_No                       /
    Quantity --------------- /
    ----------------------------------------------------------FormatByExample-----SUM(under statistic)----Recv_Quantity
    Order-no
    -----------concat[;]---sort----splitbyvalue(value changed)
    Mat_No
    UDF1:
    String [] temp= a.split(";");
    return temp[0];
    UDF2:
    String [] temp= a.split(";");
    return temp[1];

  • Need Mapping logic for the following scenario

    Hi everyone,
    I need a mapping logic for the following scenario.
    For the same order no with same material no, the quantity should be summed and only one idoc should be created.
    For the same order no with different material no, no need to sum the quantity and only one idoc should be created.
    For example:
    Source Structure:
    Ord No      Mat No      QTY
    12               1               2
    13               1               3
    13               2               1
    12               2               4
    15               1               5
    14                3              7
    12               1              6
    Target Structure:
    Ord No      Mat No      QTY
    12               1               8
    12               2               4
    13               1               3
    13               2               1
    14               3              7
    15               1              5
    Thanks in Advance

    Try the graphical mapping as shown below using concat with a space as delimite and UDF to split the value again by space.
    1. Idoc node
    (RootContext)
    OrdNo
         |concat[ ] -> sort[asending] -> SplitByValue -> collapseContexts -> Idoc
    MatNo                case sensitive    [ValueChange]                              
    (RootContext)
    2. OrdNo
    OrdNo(RC)
         |concat[ ] -> sort[asending] ->SplitByValue->collapseContexts->SplitByVale-> UDF to fetch ordno  -> OrdNo
    MatNo(RC)           case sensitive    [ValueChange]                [eachValue]   (return var1.split(" ")[0];)
    3. MatNo
    OrdNo(RC)
         |concat[ ] -> sort[asending] -> SplitByValue ->collapseContexts->SplitByVale-> UDF to fetch ordno  -> MatNo
    MatNo(RC)              case sensitive    [ValueChange]                  [eachValue]   (return var1.split(" ")[1];)
    4. Qty
                   [asending,case sensitive]               
                   --  sortByKey -----> formatByExample -> sum ->Qty
    OrdNo(RC)           |          |          ^          
         |concat[ ] -> |            Qty(RC)          |
    MatNo(RC)           |                |     
                   --sort[asending]-> SplitByValue
                       case sensitive    [ValueChange]
    Regards,
    Sunil Chandra

Maybe you are looking for