Modified the idoc

I have modified MATMAS idoc in the basic idoc type, then how to get the modified version(new segment) reimported in the integration repository ,as we can import only the normal idoc in IR.?

Hi Suresh,
If i am not wrong you have extended Matmas Idoc.
Even this extended Idoc can be imported in IR with procedure same as you do for importing normal Idoc.
If you have different requirement pls clarify the question.
Thanks,
Anurag Garg.

Similar Messages

Function module to read the the idoc

Hi abap gurus,
   I have an inbound idoc coming form a wms system .The IDOC is for goods recieved . how can I read the idoc to update the inbound delivery data in the sap system ? Is there any function module to read the data from teh inbound idoc ?

Hi Gaurab,
Creating a Function Module (Direct Inbound Processing)
This step describes how to create a function module which is identified by the IDoc Interface using a new process code and called from ALE (field TBD52-FUNCNAME). Direct inbound processing using a function module (not using a workflow) always includes the ALE layer. This setting (processing with function module and ALE layer) is identified by the value 6 in the field TEDE2-EDIVRS, which is read by the function module IDOC_START_INBOUND. IDOC_START_INBOUND then calls ALE.
Prerequisites
You must have completed the required steps in Defining and Using a Basic Type .
Procedure
Choose Tools ® ABAP Workbench ® Development ® Function Builder, and create a new function module.
Create the segments as global data in your function group. The function module should copy the application data from the segments into the corresponding application tables and modify the IDoc status accordingly. If an error occurs, the function module must set the corresponding workflow parameters for exception handling.
Activate the function module: From the initial screen of the Function Builder select .
In the example, create the function module IDOC_INPUT_TESTER with a global interface. The function module is called when an IDoc of type TESTER01 is received for inbound processing. You will assign an application object ("standard order") to this IDoc type and therefore maintain tables from SD. To do this, call transaction VA01 using the command CALL TRANSACTION. Please note that the intention here is not to simulate a realistic standard order, but only to illustrate how data reaches application tables from an IDoc table via segment structures (form routine READ_IDOC_TESTER) and how the function module triggers an event for exception handling (by returning suitable return variables to the ALE layer in the FORM routine RETURN_VARIABLES_FILL).
A comprehensive example of the code for an inbound function module is provided in the ALE documentation in the SAP Library under Example Program to Generate an IDoc. This function module, for example, also checks whether the logical message is correct and calls a (fictitious) second function module which first writes the application data and then returns the number of the generated document. In addition, status 53 is only set if the application document was posted correctly.
Administration parameters for IDOC_INPUT_TESTER
Application abbreviation
V (Sales and Distribution)
Processing type
Normal, start immediately
Interface for IDOC_INPUT_TESTER (global interface)
Formal parameters
Reference structure
Explanation
Import parameters
INPUT_METHOD
BDWFAP_PAR-INPUTMETHD
Describes how the function module is to be processed (example: in the background)
MASS_PROCESSING
BDWFAP_PAR-MASS_PROC
Mass inbound processing? (indicator)
Export parameters
WORKFLOW_RESULT
BDWFAP_PAR-RESULT
Set to 99999 if an event is to be triggered for error handling.
APPLICATION_VARIABLE
BDWFAP_PAR-APPL_VAR
Variable freely available from application for workflow
IN_UPDATE_TASK
BDWFAP_PAR-UPDATETASK
Asynchronous update? (indicator is not set in example)
CALL_TRANSACTION_DONE
BDWFAP_PAR-CALLTRANS
Transaction called? (indicator is not set in example)
Table
IDOC_CONTRL
EDIDC
IDoc control record
IDOC_DATA
EDIDD
IDoc data records
IDOC_STATUS
BDIDOCSTAT
IDoc status records for ALE
RETURN_VARIABLES
BDWFRETVAR
IDoc assigned to Object type method parameters.
SERIALIZATION_INFO
BDI_SER
If several IDocs are to be processed in a certain sequence: this structure contains the necessary information
Example
FUNCTION IDOC_INPUT_TESTER.
""Globale Schnittstelle:
*"       IMPORTING
*"             VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD
*"             VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC
*"       EXPORTING
*"             VALUE(WORKFLOW_RESULT) LIKE BDWFAP_PAR-RESULT
*"             VALUE(APPLICATION_VARIABLE) LIKE BDWFAP_PAR-APPL_VAR
*"             VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK
*"             VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS
*"       TABLES
*"              IDOC_CONTRL STRUCTURE EDIDC OPTIONAL
*"              IDOC_DATA STRUCTURE EDIDD
*"              IDOC_STATUS STRUCTURE BDIDOCSTAT
*"              RETURN_VARIABLES STRUCTURE BDWFRETVAR
*"              SERIALIZATION_INFO STRUCTURE BDI_SER
initialize SET/GET Parameter and internal tables
PERFORM INITIALIZE_ORGANIZATIONAL_DATA.
Move IDOC to internal tables of application
PERFORM READ_IDOC_TESTER.
call transaction Order Entry VA01
PERFORM CALL_VA01_IDOC_ORDERS USING ERRORCODE.
set status value
perform write_status_record using errorcode.
return values of function module
PERFORM RETURN_VARIABLES_FILL USING ERRORCODE.
ENDFUNCTION.
FORM INITIALIZE_ORGANIZATIONAL_DATA.
initialize SET/GET parameters
   SET PARAMETER ID 'VKO' FIELD SPACE.
   SET PARAMETER ID 'VTW' FIELD SPACE.
   SET PARAMETER ID 'SPA' FIELD SPACE.
   SET PARAMETER ID 'VKB' FIELD SPACE.
   SET PARAMETER ID 'VKG' FIELD SPACE.
initialize internal tables
   REFRESH BDCDATA.
   CLEAR BDCDATA.
   CLEAR BELEGNUMMER.
   CLEAR ERRTAB.
   REFRESH ERRTAB.
   REFRESH XBDCMSGCOLL.
   CLEAR XBDCMSGCOLL.
ENDFORM.                    " INITIALIZE_ORGANIZATIONAL_DATA
FORM READ_IDOC_TESTER.
PERFORM INITIALIZE_IDOC.
LOOP AT IDOC_DATA
   WHERE DOCNUM = IDOC_CONTRL-DOCNUM.
    CASE IDOC_DATA-SEGNAM.
header data
      WHEN 'E1HEAD'.
        MOVE IDOC_DATA-SDATA TO E1HEAD.
        PERFORM PROCESS_SEGMENT_E1HEAD.
position data
      WHEN 'E1ITEM'.
        MOVE IDOC_DATA-SDATA TO E1ITEM.
        PERFORM PROCESS_SEGMENT_E1ITEM.
    ENDCASE.
ENDLOOP.
only when there were one or more items
CHECK FIRST NE 'X'.
APPEND XVBAP.                        "last one
ENDFORM.                    " READ_IDOC_TESTER
FORM INITIALIZE_IDOC.
CLEAR XVBAK.
REFRESH XVBAP.
CLEAR XVBAP.
POSNR = 0.
FIRST = 'X'.
ENDFORM.                    " INITIALIZE_IDOC
FORM PROCESS_SEGMENT_E1HEAD.
requested date of delivery
WLDAT = E1HEAD-WLDAT.
delivery date
XVBAK-BSTDK = E1HEAD-BSTDK.
customer number
XVBAK-KUNNR = E1HEAD-AUGEB.
order number
XVBAK-BSTNK = E1HEAD-BELNR.
division
XVBAK-SPART = E1HEAD-SPART.
distribution channel
XVBAK-VTWEG = E1HEAD-VTWEG.
sales organization
XVBAK-VKORG = E1HEAD-VKORG.
order type
XVBAK-AUART = E1HEAD-AUART.
do not fill incoterms (inco1, inco2)
customer function
CALL CUSTOMER-FUNCTION '001'
       EXPORTING
            PI_VBAK621           = XVBAK
       IMPORTING
            PE_VBAK621           = XVBAK
       TABLES
            PT_IDOC_DATA_RECORDS = IDOC_DATA.
ENDFORM.                    " PROCESS_SEGMENT_E1HEAD
FORM PROCESS_SEGMENT_E1ITEM.
position number
XVBAP-POSNR = XVBAP-POSNR + 1.
amount
XVBAP-WMENG = E1ITEM-MENGE.
unit
CALL FUNCTION 'ISO_TO_SAP_MEASURE_UNIT_CODE'
       EXPORTING
            ISO_CODE = E1ITEM-BMEINH
       IMPORTING
            SAP_CODE = XVBAP-VRKME
       EXCEPTIONS
            OTHERS    = 0.
material number
XVBAP-MATNR = E1ITEM-LMATNR.
CALL CUSTOMER-FUNCTION '002'
       EXPORTING
            PI_VBAP621           = XVBAP
       IMPORTING
            PE_VBAP621           = XVBAP
       TABLES
            PT_IDOC_DATA_RECORDS = IDOC_DATA.
APPEND XVBAP.
ENDFORM.                    " PROCESS_SEGMENT_E1ITEM
FORM CALL_VA01_IDOC_ORDERS USING ERRORCODE.
call transaction first dynpro
PERFORM DYNPRO_START.
call transaction double-line entry
PERFORM DYNPRO_DETAIL2.
incoterms
PERFORM DYNPRO_HEAD_300.
call transaction item datas
PERFORM DYNPRO_POSITION.
PERFORM DYNPRO_SET USING 'BDC_OKCODE' 'SICH'.
determine input method
IF INPUT_METHOD IS INITIAL.
    INPUT_METHOD = 'N'.
ENDIF.
call transaction VA01
CALL TRANSACTION 'VA01' USING    BDCDATA
                         MODE     INPUT_METHOD
                         UPDATE   'S'
                         MESSAGES INTO XBDCMSGCOLL.
errorcode = SY-SUBRC.       " remember returncode for status update
ENDFORM.                    " CALL_VA01_IDOC_ORDERS
form write_status_record using errorcode.
FILL IDOC_STATUS
IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
IF ERRORCODE = 0.
IDOC_STATUS-STATUS = BELEG_GEBUCHT. "value 53
   GET PARAMETER ID 'AUN' FIELD BELEGNUMMER.
   IDOC_STATUS-MSGID = 'V1'.
   IDOC_STATUS-MSGNO = '311'.
   IDOC_STATUS-MSGV1 = 'Terminauftrag'.
   IDOC_STATUS-MSGV2 = BELEGNUMMER.
ELSE.
    IDOC_STATUS-STATUS = BELEG_NICHT_GEBUCHT. "value 51
    IDOC_STATUS-MSGID = SY-MSwGID.
    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.
ENDIF.
APPEND IDOC_STATUS.
ENDFORM.
FORM DYNPRO_START.
PERFORM DYNPRO_NEW USING PROGRAMM_AUFTRAG
                           DYNPRO-EINSTIEG
                  CHANGING LAST_DYNPRO.
ordertype
PERFORM DYNPRO_SET USING 'VBAK-AUART' XVBAK-AUART.
sales organization
PERFORM DYNPRO_SET USING 'VBAK-VKORG' XVBAK-VKORG.
Distribution channel
PERFORM DYNPRO_SET USING 'VBAK-VTWEG' XVBAK-VTWEG.
Division
PERFORM DYNPRO_SET USING 'VBAK-SPART' XVBAK-SPART.
Sales office
PERFORM DYNPRO_SET USING 'VBAK-VKBUR' XVBAK-VKBUR.
Sales group
PERFORM DYNPRO_SET USING 'VBAK-VKGRP' XVBAK-VKGRP.
ENDFORM.                    " DYNPRO_START
FORM DYNPRO_NEW USING    PROGNAME
                         DYNPRONR
                CHANGING LAST_DYNPRO.
CLEAR BDCDATA.
BDCDATA-PROGRAM = PROGNAME.
BDCDATA-DYNPRO = DYNPRONR.
BDCDATA-DYNBEGIN   = 'X'.
APPEND BDCDATA.
LAST_DYNPRO = DYNPRONR.
ENDFORM.                    " DYNPRO_NEW
FORM DYNPRO_SET USING    FELDNAME
                         FELDINHALT.
CLEAR BDCDATA.
CHECK FELDINHALT NE SPACE.
dynpro field name
BDCDATA-FNAM = FELDNAME.
contents
BDCDATA-FVAL = FELDINHALT.
APPEND BDCDATA.
ENDFORM.                    " DYNPRO_SET
FORM DYNPRO_DETAIL2.
okcode
PERFORM DYNPRO_SET USING 'BDC_OKCODE' PANEL-UER2.
fix dynpro number 4001
PERFORM DYNPRO_NEW USING    PROGRAMM_AUFTRAG
                               '4001'
                      CHANGING LAST_DYNPRO.
order party
PERFORM DYNPRO_SET      USING 'KUAGV-KUNNR' XVBAK-KUNNR.
purchase order number
PERFORM DYNPRO_SET      USING 'VBKD-BSTKD'   XVBAK-BSTNK.
requested delivery date
PERFORM DYNPRO_DATE_SET USING 'VBKD-BSTDK'   XVBAK-BSTDK.
purchase order date
PERFORM DYNPRO_DATE_SET USING 'RV45A-KETDAT' WLDAT.
ENDFORM.                    " DYNPRO_DETAIL2
FORM DYNPRO_DATE_SET USING    FELDNAME
                              FELDINHALT.
DATA: DATE TYPE D.
CLEAR BDCDATA.
CHECK FELDINHALT NE SPACE.
BDCDATA-FNAM = FELDNAME.
WRITE FELDINHALT TO DATE.
BDCDATA-FVAL = DATE.
APPEND BDCDATA.
ENDFORM.                    " DYNPRO_DATE_SET
FORM DYNPRO_HEAD_300.
PERFORM DYNPRO_SET USING 'BDC_OKCODE' PANEL-KKAU.
incoterms part 1
IF NOT XVBAK-INCO1 IS INITIAL.
   PERFORM DYNPRO_SET USING 'VBKD-INCO1' XVBAK-INCO1.
ENDIF.
incoterms part 2
IF NOT XVBAK-INCO2 IS INITIAL.
   PERFORM DYNPRO_SET USING 'VBKD-INCO2' XVBAK-INCO2.
ENDIF.
PERFORM DYNPRO_SET USING 'BDC_OKCODE' 'BACK'.
ENDFORM.                    " DYNPRO_HEAD_300
FORM DYNPRO_POSITION.
LOOP AT XVBAP.
dynpro item double line entry
PERFORM DYNPRO_SET USING 'BDC_OKCODE' 'UER2'.
    IF XVBAP-POSNR = 1.
material number
      PERFORM DYNPRO_SET      USING 'VBAP-MATNR(01)'   XVBAP-MATNR.
order quantity
      PERFORM DYNPRO_SET      USING 'RV45A-KWMENG(01)' XVBAP-WMENG.
desired delivery date
      PERFORM DYNPRO_DATE_SET USING 'RV45A-ETDAT(1)' WLDAT.
sales unit
      PERFORM DYNPRO_SET      USING 'VBAP-VRKME(1)'   XVBAP-VRKME.
    ELSE.
     PERFORM DYNPRO_SET      USING 'BDC_OKCODE'      'POAN'.
material number
      PERFORM DYNPRO_SET      USING 'VBAP-MATNR(02)'    XVBAP-MATNR.
order quantity
      PERFORM DYNPRO_SET      USING 'RV45A-KWMENG(02)' XVBAP-WMENG.
desired delivery date
      PERFORM DYNPRO_DATE_SET USING 'RV45A-ETDAT(02)'   WLDAT.
sales unit
      PERFORM DYNPRO_SET      USING 'VBAP-VRKME(02)'    XVBAP-VRKME.
    ENDIF.
ENDLOOP.
ENDFORM.                    " DYNPRO_POSITION
FORM RETURN_VARIABLES_FILL USING ERRORCODE.
allocate IDOC numbers to Workflow output parameters
IF MASS_PROCESSING <> SPACE.
    IF ERRORCODE = 0.
      RETURN_VARIABLES-WF_PARAM = PID.
      RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
      APPEND RETURN_VARIABLES.
      RETURN_VARIABLES-WF_PARAM = APO.
      RETURN_VARIABLES-DOC_NUMBER = BELEGNUMMER.
      APPEND RETURN_VARIABLES.
      WORKFLOW_RESULT = C_WF_RESULT_OK.
    ELSE.
      RETURN_VARIABLES-WF_PARAM = EID.
      RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
      APPEND RETURN_VARIABLES.
      WORKFLOW_RESULT = C_WF_RESULT_ERROR.
    ENDIF.
ELSE.
    IF ERRORCODE = 0.
      RETURN_VARIABLES-WF_PARAM = APE.
      RETURN_VARIABLES-DOC_NUMBER = BELEGNUMMER.
      APPEND RETURN_VARIABLES.
      WORKFLOW_RESULT = C_WF_RESULT_OK.
    ELSE.
      WORKFLOW_RESULT = C_WF_RESULT_ERROR.
    ENDIF.
ENDIF.
ENDFORM.                    " RETURN_VARIABLES_FILL
Globale Daten von IDOC_INPUT_TESTER
TABLES: E1HEAD, E1ITEM.
DATA: BEGIN OF BDCDATA OCCURS 500.
        INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDCDATA.
DATA: BEGIN OF XVBAK.                 "Kopfdaten
     INCLUDE STRUCTURE VBAK621.
DATA: END OF XVBAK.
DATA: BEGIN OF XVBAP OCCURS 50.        "Position
       INCLUDE STRUCTURE VBAP.
DATA: WMENG(18) TYPE C.
DATA: LFDAT LIKE VBAP-ABDAT.
DATA: KSCHL LIKE KOMV-KSCHL.
DATA: KBTRG(16) TYPE C.
DATA: KSCHL_NETWR LIKE KOMV-KSCHL.
DATA: KBTRG_NETWR(16) TYPE C.
DATA: INCO1 LIKE VBKD-INCO1.
DATA: INCO2 LIKE VBKD-INCO2.
DATA: YANTLF(1) TYPE C.
DATA: PRSDT LIKE VBKD-PRSDT.
DATA: HPRSFD LIKE TVAP-PRSFD.
DATA: END OF XVBAP.
DATA: BEGIN OF DYNPRO,
      EINSTIEG          LIKE T185V-DYNNR VALUE 101,
      KKAU              LIKE T185V-DYNNR,
      UER2              LIKE T185V-DYNNR,
      KBES              LIKE T185V-DYNNR,
      ERF1              LIKE T185V-DYNNR,
      PBES              LIKE T185V-DYNNR,
      PKAU              LIKE T185V-DYNNR,
      PEIN              LIKE T185V-DYNNR,
      EID1              LIKE T185V-DYNNR,
      POPO              LIKE T185V-DYNNR,
      EIPO              LIKE T185V-DYNNR,
      KPAR              LIKE T185V-DYNNR,
      PSDE              LIKE T185V-DYNNR,
      PPAR              LIKE T185V-DYNNR,
      KDE1              LIKE T185V-DYNNR,
      KDE2              LIKE T185V-DYNNR,
      PDE1              LIKE T185V-DYNNR,
      PDE2              LIKE T185V-DYNNR,
      PKON              LIKE T185V-DYNNR,
      END OF DYNPRO.
DATA: BEGIN OF PANEL,
      KKAU              LIKE T185V-PANEL VALUE 'KKAU',
      UER2              LIKE T185V-PANEL VALUE 'UER2',
      KBES              LIKE T185V-PANEL VALUE 'KBES',
      ERF1              LIKE T185V-PANEL VALUE 'ERF1',
      PBES              LIKE T185V-PANEL VALUE 'PBES',
      PKAU              LIKE T185V-PANEL VALUE 'PKAU',
      PEIN              LIKE T185V-PANEL VALUE 'PEIN',
      EID1              LIKE T185V-PANEL VALUE 'EID1',
      EIAN              LIKE T185V-PANEL VALUE 'EIAN',
      POPO              LIKE T185V-PANEL VALUE 'POPO',
      EIPO              LIKE T185V-PANEL VALUE 'EIPO',
      KPAR              LIKE T185V-PANEL VALUE 'KPAR',
      PSDE              LIKE T185V-PANEL VALUE 'PSDE',
      POAN              LIKE T185V-PANEL VALUE 'POAN',
      PPAR              LIKE T185V-PANEL VALUE 'PPAR',
      KDE1              LIKE T185V-PANEL VALUE 'KDE1',
      KDE2              LIKE T185V-PANEL VALUE 'KDE2',
      PDE1              LIKE T185V-PANEL VALUE 'PDE1',
      PDE2              LIKE T185V-PANEL VALUE 'PDE2',
      PKON              LIKE T185V-PANEL VALUE 'PKON',
      KOAN              LIKE T185V-PANEL VALUE 'KOAN',
      END OF PANEL.
DATA: BEGIN OF ERRTAB OCCURS 20,
       TRANS LIKE TSTC-TCODE,
       ARBGB LIKE T100-ARBGB,
       CLASS(1) TYPE C,
       MSGNR LIKE T100-MSGNR,
     TEXT LIKE T100-TEXT,
       TEXT(123) TYPE C,
       MSGV1 LIKE SY-MSGV1,
       MSGV2 LIKE SY-MSGV2,
       MSGV3 LIKE SY-MSGV3,
       MSGV4 LIKE SY-MSGV4,
      END OF ERRTAB.
*---- Hilfsfelder     -
DATA: PROGRAMM_AUFTRAG LIKE T185V-AGIDV VALUE 'SAPMV45A'.
DATA: LAST_DYNPRO      LIKE T185V-DYNNR,
      WLDAT            LIKE VBAK-BSTDK,
      POSNR            LIKE VBAP-POSNR,
      FIRST(1)         TYPE C VALUE 'X'.
DATA: BEGIN OF XBDCMSGCOLL OCCURS 10.
        INCLUDE STRUCTURE BDCMSGCOLL.
DATA: END OF XBDCMSGCOLL.
Terminauftrag ( Auftragsart wird fest gesetzt !)
DATA:   BELEGNUMMER LIKE VBAK-VBELN.
DATA:   ERRORCODE LIKE SY-SUBRC.
Statuswerte fuer IDOC-Status
DATA:   BELEG_NICHT_GEBUCHT LIKE TEDS1-STATUS VALUE '51'.
DATA:   BELEG_GEBUCHT       LIKE TEDS1-STATUS VALUE '53'.
*- Direktwerte für Return_variables -
data:
    eid like bdwfretvar-wf_param value 'Error_IDOCs',
    pid like bdwfretvar-wf_param value 'Processed_IDOCs',
    apo like bdwfretvar-wf_param value 'Appl_Objects',
    ape like bdwfretvar-wf_param value 'Appl_Object'.
*- Direktwerte für Workflow_Result -
DATA: C_WF_RESULT_ERROR LIKE BDWFAP_PAR-RESULT VALUE '99999'.
thanks
karthik
DATA: C_WF_RESULT_OK    LIKE BDWFAP_PAR-RESULT VALUE '0'.

Modifying Matmas01 Idoc type

Hi ,
I have a requirement where if a mterial has more than 1 warehouse then the segement 'E1MLGNM ' should be populated that many times.How can this be acheived?
Do I need to create an extension?
Please help

If that segment is a repetitive one, then you will have to fill this multiple times and append that to the IDOC.
The max number this segment can occur is 9999, so you will have to just append this so many times. You don't have to modify the IDOC.
Regards,
Ravi
Message was edited by: Ravikumar Allampallam

This Question is related to IDOC , that how to modify the existing IDoc

hi All,
am getting some problem that ,
i have created the IDOC for sales orders by using (ORDERS), so i was able to create IDOC,but my requrement is to modify the exising IDOC.
how i can go through?.
what are the F.M to use?

Hi,
Check the FM being used for inbound posting for your message type. See if there is a user exit available for you to update data contained in the IDoc.
If there isn't any, then you might have make a copy of the existing inbound processing FM and modify code to address your requirements. This will involve setting up your Z* FM for inbound posting (rather than system's standard FM) through configuration. For more details on how make these settings, take a look at http://www.sapgenie.com/sapgenie/docs/ale_whitepaper.doc.
Regards

Modified idoc values are not reflecting in the IDOC display (ie we02)

Hello Team
I wrote one inbound interface for posting GR by using the IDOC MBGMCR03. In the inbound FM, i wrote some code for retrieving some data and mapping to its relevant fields of the segments. It is working fine but when i see the idoc values in WE02/WE05, i am not able to see the values which i have added in the FM. so please suggest me how to get the values in the IDOC display.
Regds
Raj

Hello Team
Thanks for your replies. Let me put my question in this way to you.
In the inbound FM (ie idoc_input_mbgmcr), i have fetched some values from SAP by using the values which came from PI to that IDOC through mapping. what ever the values i have fetched from SAP in inbound FM, i have mapped them to the relevent segments and finally the complete structure i have passed to BAPI, where it will post GR. All these things are working fine, idoc is also getting successfull.
But when i go and see the successfull idoc values, it is not showing the values which i have mapped in inbound FM. Now i want those values in that Final idoc.
So pls check and suggest.
Regards
Rj

Automatic (EDI) vendor posting fails - can I update the IDOC mapping?

Hi -- I am testing a new intercompany sales process and having trouble with returns. The INVOIC01 IDOC for the vendor posting (document type VC - Vendor Credit FI) is failing because text is required on the line item (field SGTXT on BSEG). So it appears that the IDOC doesn't have this text field mapped.
If I can identify a field in the existing IDOC to use for the text, is there a way that I can add that mapping? For example, let's say I want to populate the BSEG text with field BELNR on segment E1EDP01, is there a way to specify in the INVOIC01 idoc that this field should be plugged into BSEG-SGTXT? I don't have EDI experience, so this is all new to me!
Thanks
Allison

Hi Allison,
Since it's just for testing, just change the Text field on FI field status group become optional entry. It will solve your problem rather than modifying the standard IDOC
Regards,
Gumanti

I cannot get the "ARCKEY" value in my payload to be written to the Idoc

I am trying to write the interface filename to the ARCKEY field of an Idoc. I can see it in the Payload but the Idoc in the target system always has the GUID/MessageId in this field.
I've got "Apply Control Record Values from Payload" switched on in the communication channel.
Reading some other threads, is it because you actually can't over-ride this field?
Help!
Regards
Robert

Hello ,
Followin g control fields will be set by system and not allows to modify
SNDPOR
MANDT
DIRECT
CREDATE
CRETIME
TABNAME
STATUS
OUTMOD
DOCREL
ARCKEY
HTH
Rajesh

How to modify existing idoc

Hi all,
My requirement is all ready existing idoc is their add to the new segments.Where is see the existing idoc and how modified it.
requirement:
Invoice is created in R/3 the outbound idoc is created. The idoc details contain the PO Order Number, PO Line Number, Shipment Number, etc., along with serial number detail has to be added. For serial number detail additional segment has to be created and added to existing idoc.
Create the new segment for serial number and add to the existing idoc. u201CIDOC BasicType:INVOIC02 and IDOC Message Type: INVOIC u201C .
please help me.
sreddy.
Edited by: SReddy on Sep 8, 2008 7:06 AM

Hi,
Refer to the following link,
[How to extend an existing IDOC!;
Regards
Natasha Garg

Reg : change pointer mechanism for triggering the IDOC for delivery note

Hi ,
I am working on a change pointer mechanism for triggering the IDOC for delivery note and will be using this message class DESADV.
So SAP has suggested for assigning the message class DESADV with the function module in MASTERIDOC_CREATE_SMD_DESADV in BD60 transaction code.
So I was looking to create this MASTERIDOC_CREATE_SMD_DESADV function module in SAP and SAP suggesting that we should create this MASTERIDOC_CREATE_SMD_DESADV function module as same as the function module MASTERIDOC_CREATE_SMD_MATMAS.
So do anyone knows that is there any tool has been provided by SAP for creating this function module MASTERIDOC_CREATE_SMD_DESADV in SAP system for triggering the change pointer mechanism for outbound Delivery.
Thanks !
Regards,
Kiran

Hi,
When you are change pointer the system itself will take care of sending the changed master data to your partner system and the user will not have any intervention. If you really wanted to have that then you need to use the change pointers to read the master data which is modified in a custom program and then display that on the screen. Once the user selects that master data records then trigger an IDOC for creating the idoc for that master data and also flag that master data record as processed in the SAP BDCPS standard table, so that the same record will not be picked. If you wanted to know how the change pointers piece of code is written go through the program RBDMIDOC and you can understand how the change pointers logic is written.
Thanks,
Mahesh.

User eixt for modifying inbound idoc (delins) not working

hi all,
Inbound IDoc DELINS.DELFOR02 is sent from customer to vendor to create forecast delivery schedule lines (VA32). E1EDP16-WMENG has the delivery quantity and it is mapped to VBEP-WMENG.
I need modify E1EDP16-WMENG accordingly (based on some business rules) and this change should also be reflected to VBEP_WMENG.
I tried to modify the idoc_data in user exits: EXIT_SAPLVED4_002, userexit_zuordnen_idocs. During debug, I can see the idoc is modified, but the final forecast delivery is not updated (VA33).
Anyone can help?
Thanks!
Regards
Hui

Hi Sandip,
Inside userexit_zuordnen_idocs, i updated the table idoc_data_1 (I changed the delivery quantities of the schedule lines), but it dosen't work. In Va33, the delivery quantities are not changed.
Any other input?
Thanks!
Regards,
Hui

MM I need to inform in the idoc output when you cancel a document.

hi i need to know how to report on a idoc cancels out when the framework contract and a service entrance (ML81N, ME31K) is that when you cancel a document does not create logistical message. Thanks
I need to inform in the idoc output when you cancel a document OF ml81n migo or me31k, if you create or modify a documet of ml81n migo or me31k , logistical message is generated but not nullify. Is there any way to report a cancellation in the output idoc?
Edited by: juliansantelli on Apr 7, 2011 4:26 PM

Sorry, good network connection, happily downloaded for 15 minutes before this popup appeared... Staying with iOS 5.1.1 for now hoping Apple can sort it..oO

Regardig the extension of the Idoc

Hi Experts,
                We are using an Inbound Idoc.
              I extended the idoc COND_A, becoz we are having some custom fields in the IDOC.
         For this we have an Exit in the FM IDOC_INPUT_COND_A.
But the data coming to inbound would be of various tables which contains the custom fields.
      How do i update the data in the database tables.
For EX table A contains 4 custom fields that are to be updated,table b contains 2
custom fields that are to be updated.
       How do i do this??
Thanks and Regards
Rajesh.

Hii..
SAP provides the Function module exits to process the Extended idoc type.
Check this info...
ALE FUNCTION MODULE ENHANCEMENTS
Having extended the IDOC type to contain additional fields for an inbound or outbound application, you now want to enhance ALE function modules for populating the additional segment on the outbound or applying the additional segment data on the inbound application.
The core working code for ALE processes for a given application area is always encapsulated in ABAP/4 function modules. These function modules are associated with such control information as message types and process codes. So the ALE process checks this control information and derives the name of the function module to invoke for that particular IDOC processing from certain database tables. These function modules contain objects known as customer functions, which can be considered SAP Enhanced user exits. A function module is called at a particular point during the processing of the main program or function module, and it can be used to influence data processing at that point by adding code to the customer function. The customer function behaves like a normal function module and has import and export parameters, tables (internal tables) statement, and exception processing. Unlike a conventional user exit, customer functions give you the ability to modify only data available to you by the function moduleâs parameters and internal tables. While most ALE/EDI function modules are supported by customer functions, there are ALE/EDI processes that still use conventional user exits. There are a few ways to determine which function module to enhance for a given message type/process code:
For master data distribution, from SALE go to Extensions -> Master data distribution -> Setup additional data for message types. Search for message type DEBMAS in this example. You see an entry for DEBMAS associated with function module MASTERIDOC_CREATE_SMD_DEBMAS. This data is stored on table TBDME. The function module names for all master data message types follow this pattern: MASTERIDOC_CREATE_SMD_messagetype. This function module calls another function module of name MASTERIDOC_CREATE_DEBMAS or MASTERIDOC_CREATE_messagetype. Search for the words customer function, and you find several hits that can be used to add code to the function module.
From WEDI got to Control -> Inbound process codes -> Inbound with ALE service -> Processing by function module (transaction WE42), or from WEDI go to Control -> Outbound process codes -> Outbound with ALE service -> With function module (transaction WE41). There will be function modules associated with the process codes. For inbound, the function modules usually follow this pattern: IDOC_INPUT_messagetype: for example, IDOC_INPUT_CHRMAS for inbound characteristics master.
Use transaction WE57 or from WEDI go to Development -> Message/Application Object. The entries list the function module, Business Object, message type, and IDOC type that are used for inbound ALE/EDI interfaces.
Customer functions are not specific only to ALE and EDI but also to all programs/modules in SAP R/3. Customer function is a SAP enhancement component; the other two types are menu and screen enhancements.
All customer function exits are maintained in SAP enhancements and are found by using transaction SMOD. After executing transaction SMOD, pull down (F4) on the enhancement name field, and execute again. This provides you with a list of all SAP enhancements available. SAP enhancements are grouped by development class pertaining to an application area. Choose Application development R/3 SD master data distribution for development class VSV to lead to a screen that lists VSV00001 as an enhancement (see Figure 5). Press Component +/- to display its function exit components. There are four possible components listed, all of which are function exits (and are function modules) that are called from the ALE function modules in the form Call Customer Function Î001â. This is a special occurrence of the ABAP statement Call. Go to item Exit_SAPLVV01_ 001, which you need to enhance for the Customer Master outbound example of an IDOC extension. In the ALE-function module MASTERIDOC_CREATE_DEBMAS, the statement CALL Customer Function 001 is translated in the background to call component EXIT_SAPLVV01_001. Although this function exit can be edited using transaction SE37, you will use a simpler approach.
When you use SAP enhancements and their components, you manage them with an SAP object known as a project, which is like an envelope containing the selected enhancements and their components. A project can be used to control the execution of components and to transport them to other clients and instances in SAP. Basically, the process involves creating a project, including enhancements and components that are to be enhanced, editing the components, and then activating the project. The following process creates a project for our example Customer Master IDOC extension:
Execute transaction CMOD.
Enter name of project, say CSTMAST1.
Click on Create.
Enter a description of the project.
Save.
Click on SAP Enhancements.
Enter VSV00001 for Enhancement.
Save.
Once youâve created the project, edit the function exit components and activate the project. Remember that the code in the function exit enhancement will execute only if the project is activated. In fact, this is a convenient SAP enhancements feature, whereby the work in progress (developing code in the customer function) will not affect users of that application. When the code is completed, the project can be activated so the enhanced functionality takes effect. It can also be deactivated for maintenance.
As mentioned earlier, customer functions (function exits) are embedded in ALE function modules and can be used to influence the creation and modification of IDOC data on an outbound application or to post additional or modified IDOC data to an inbound R/3 application. Function exits are similar to regular function modules, with import/export parameters, tables (internal tables), and exceptions.
The two important factors to consider while developing the customer function are:
1. The point in the ALE function module where the function exit occurs
2. The data made available by the customer function that can be modified or posted to the R/3 application, based on the direction.
Because some function modules have several customer functions, it is critical to choose the function exit best suited for that particular enhancement. Do not attempt to perform activities that the function exit is not designed for. The importance of this point is illustrated by the following description of enhancing function modules for outbound and inbound ALE interfaces.
Outbound interfaces. In an outbound ALE interface you use function exits (customer functions) to populate additional segments created by an IDOC extension or to modify the existing IDOC data segments as per business requirements. Previously, you identified that enhancement VSV00001 has a component EXIT_SAPLVV01_001 (function exit), which can be used for populating the additional data segment Z1SADRX that you created in the IDOC extension ZDEBMASX (IDOC type ZDEBMASZ, based on Basic IDOC type DEBMAS02). You also learned that the ALE function module that calls this function exit is MASTERIDOC_CREATE_DEBMAS, which has a statement Call Customer Function 001.
Browse the function module MASTERIDOC_CREATE_DEBMAS using transaction SE37. You will find that this customer function is invoked for every segment of IDOC type DEBMAS02. In fact, the function exit is called soon after the creation of an existing segment has been populated with data and appended to the IDOC data table (internal table). Also, the function exit is exporting the message type, IDOC type, and the segment name and is importing the IDOC extension type. It is also passing the IDOC data internal table. This indicates that the ALE function module is allowing you to populate additional segments for every existing segment and modify the existing segmentâs data.
Letâs write ABAP/4 code to accomplish the task of populating IDOC segment Z1SADRX with a contact personâs business address:
From SE37, display function module MASTERIDOC_CREATE_ DEBMAS.
Find Customer Function 001.
Double-click on 001.
The function EXIT_SAPLVV01_001 will be displayed.
Double-click on INCLUDE ZXVSVU01.
You will be asked to create a new include object. Proceed as desired.
Enter code (as in Listing 1).
Be sure to perform a main program check (Function Module -> Check -> main program) and extended program check (Function module -> Check -> Extended check).
Now that you have extended the IDOC and enhanced the ALE function module based on the requirements for the contact personâs business address on the Customer Master, letâs test the interface. You should create a logical system and define a port for this interface. You should also configure the Customer Distribution Model to indicate that message type DEBMAS is being distributed to this logical system. The only difference in configuration between a regular outbound ALE interface and an enhanced one is the partner profile definition. While maintaining the outbound parameters of the partner profile, make sure the IDOC type is ZDEBMASZ. The fields for Basic IDOC type and extension type are automatically populated with DEBMAS02 and ZDEBMASX, respectively.
To maintain the contact personâs business address of a customer:
Use transaction BD12 or from BALE go to Master Data ->Customer -> Send and send that Customer Master record by executing the transaction after filling in the relevant fields such as customer number, message type, and logical system.
Use transaction WE02 or WE05 to verify the IDOC created. You should see the new segment Z1SADRX populated with the correct data.
With SAP releases below 4.5B, you cannot capture changes to business address through change pointers because a change document object is not available for capturing business address changes, and also earlier releases have not been configured to write change documents for a contact personâs business address. If you would like this functionality, you can either create change document objects, generate function modules to create change documents, and perform ALE configuration to tie it in, or make a cosmetic change to the contact person screen data while changing the contact personâs business address so that it gets captured as a change to the Customer Master. Subsequently, the ALE enhancement that you performed captures the contact personâs business address.
Inbound interfaces. The process for enhancing inbound ALE interfaces is similar for outbound, with a few exceptions; specifically in the coding of customer functions (function exits) for the ALE/EDI function modules.
The first step is to create an IDOC extension for the specific Basic IDOC type by adding new segments at the appropriate hierarchy level: that is, associated to the relevant existing segment. Populate the data fields on the new segments with application data by the translator or external system/program before importing them into the R/3 System. Then, find the ALE function module that is invoked by the inbound processing. By browsing through the code or reading the documentation on the function exit enhancements using the SMOD transaction, identify the function exit in which you should place your code. The technique used in the code to post the additional or modified IDOC data to the application can vary based on the application rules and requirements, the data available at that point in processing, and the application function modules available to update the application tables. It is important to search first for application modules that process the data and see if they can be called within the function exit. If the additional data in the extended segments in specific to a custom table or resides in nonkey fields of a single or small set of tables, you may be able to update it directly by SQL statements in the function exit. This approach should be carefully evaluated and is certainly not highly recommended.
Another option is to use Call Transaction from within the function exit to process the additional data. For example, in the case of message type WMMBXY for inbound goods movements from a warehouse management system, the standard interface creates batches for materials, but does not update its characteristics. In such a case, you can use Call Transaction MSC1 to create the batch and assign characteristic values to it from within the function exit provided.
reward if Helpful

Import of modified/extended Idoc into XI repository

Dear all,
we have to import a modified/extended Idoc from R/3 into XI repository.
When I do that in the normal way, I get only the original Idoc structure without our additional segments.
The Idoc is SDPICK.SDPIID01 where we added additional segments.
Any help is very much appreciated.
Thanks and best regards,
Philipp

Hi,
IDX1 & IDX2 is for metadata check these links
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/6bd6f69a-0701-0010-a88b-adbb6ee89b34
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/d19fe210-0d01-0010-4094-a6fba344e098
Thanks,
Prakash

User exit to modify the segment E1IDB02 data

Hi SAP Experts,
I have a requirement to change the data in the segment E1IDB02 field FIIKONTO before generating the IDOC.
I'm using the transaction code F110 for payment and the program in payment run transaction is RFF0EDI1, message type PAYEXT and the Basic Idoc type PEXR2002.
I have tried the user exit 'EXIT_SAPLIEDP_002' to modify the data, but it is not triggering that user exit I guess, even tried by putting 'BREAK-POINT' as well but still it is not stopping the control at that particular point.
This is for outbound idoc creation.
note : I have activated everything like project, function module etc.
Please kindly let me know whether I am using the correct user exit or not and if not please kindly provide me the correct user exit.
Thanks in advance.
kalikonda.

Hi Pawan,
Thanks for your prompt reply.
I tried all ways as you told but still it is not stopping.
Also implemented the sap note 937966 (RFFOEDI1: User exits EXIT_SAPLIEDP_002 and PEXR2002)
but still no result.
Is there any other way where I can modify the data in the segment E1IDB02?
Thanks,
kalikonda.

Change pointers to trigger the IDOC

HI
I am having a selection screen with fields to create a custom info record (transaction VD51/ VD52 )
Customer
material
salesorganisation
distribution channel
division
if we can use change pointers to determine when procedure is triggered.
Please provide the steps for that (including change document)or we need to check the CDHDR table using the following fields.
Plz suggest

Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
Reward if useful

Modified the idoc

Similar Messages

Maybe you are looking for