Programa para listar el contenido de un IDOC

Con el siguiente reporte vamos a poder mostrar el contenido de un IDOC y luego guardarlo en un fichero. Simplemente corremos el programa con el nmero de IDOC y luego que se liste el contenido, podemos grabar un fichero desde el men Lista > Grabar/Enviar > Fichero

REPORT Z_DISPLAY_IDOC LINE-SIZE 275. DATA: IDOC_CONTROL LIKE EDIDC, NUMBER_OF_DATA_RECORDS LIKE SY-DBCNT, NUMBER_OF_STATUS_RECORDS LIKE SY-DBCNT, INT_EDIDS LIKE EDIDS OCCURS 0 WITH HEADER LINE, INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE. TYPE-POOLS : LEDID. DATA: STRUCT_TYPE TYPE LEDID_STRUCT_TYPE , IDOC_STRUCT TYPE LEDID_T_IDOC_STRUCT, SEGMENTS TYPE LEDID_T_SEGMENT, SEGMENT_STRUCT TYPE LEDID_T_SEGMENT_STRUCT, EXCEL_TAB(2000) OCCURS 0 WITH HEADER LINE. PARAMETER: DOCNUM LIKE EDIDC-DOCNUM OBLIGATORY, Idoc Number SAP_REL LIKE SY-SAPRL DEFAULT SY-SAPRL OBLIGATORY, PI_VER LIKE EDI_VERREC-VERSION DEFAULT 3 OBLIGATORY. START-OF-SELECTION. PERFORM READ_IDOC. PERFORM PROCESS_IDOC. END-OF-SELECTION. *&* *& * Form read_idoc text *&* *-* FORM READ_IDOC. CALL FUNCTION IDOC_READ_COMPLETELY EXPORTING DOCUMENT_NUMBER IMPORTING IDOC_CONTROL = IDOC_CONTROL NUMBER_OF_DATA_RECORDS = NUMBER_OF_DATA_RECORDS = DOCNUM

NUMBER_OF_STATUS_RECORDS = NUMBER_OF_STATUS_RECORDS TABLES INT_EDIDS INT_EDIDD EXCEPTIONS DOCUMENT_NOT_EXIST OTHERS IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. ENDFORM. read_idoc = 3. =1 DOCUMENT_NUMBER_INVALID = 2 = INT_EDIDS = INT_EDIDD

*&* *& * Form process_idoc text *&* *-* FORM PROCESS_IDOC. PERFORM READ_IDOC_STRUCTURE. PERFORM DISPLAY_DATA_RECORDS. ENDFORM. process_idoc

*&* *& * Form display_data_records text *&* *-* FORM DISPLAY_DATA_RECORDS. DATA: PE_SEG_HEADER LIKE EDI_SAPI01, SEGNAME LIKE EDI_IAPI12-SEGMENTTYP, PREV_SEGNAME LIKE EDI_IAPI12-SEGMENTTYP VALUE , PT_FIELDS2 LIKE EDI_IAPI12 OCCURS 0 WITH HEADER LINE, PT_FVALUES2 LIKE EDI_IAPI14 OCCURS 0 WITH HEADER LINE, BYTE_FIRST TYPE I, BYTE_LAST TYPE I, FIELD_VAL(50), TMP_STR(15), TMP_STR3(15), SEG_REPEATS TYPE I VALUE 0, TMP_STR2(15), TAB_CR(2) TYPE C VALUE 09, TOT_CTR TYPE I VALUE 0, CTR TYPE I VALUE 0, MSG(40) TYPE C. DATA: IDOC_STRUCT_WA TYPE LEDID_IDOC_STRUCT. SORT INT_EDIDD BY SEGNUM. DESCRIBE TABLE INT_EDIDD LINES TOT_CTR. LOOP AT INT_EDIDD. MOVE INT_EDIDD-SEGNAM TO SEGNAME. CLEAR MSG.

CONCATENATE Reading segment SEGNAME INTO MSG SEPARATED BY SPACE. IF TOT_CTR <> 0. CTR = ( 100 * SY-TABIX ) / TOT_CTR. ENDIF. CALL FUNCTION SAPGUI_PROGRESS_INDICATOR EXPORTING PERCENTAGE = CTR TEXT = MSG. ADD 1 TO SEG_REPEATS. CLEAR TMP_STR2. IF INT_EDIDD-SEGNAM <> PREV_SEGNAME. SEG_REPEATS = 1. CLEAR: PE_SEG_HEADER, PT_FIELDS2, PT_FVALUES2. REFRESH: PT_FIELDS2, PT_FVALUES2. CALL FUNCTION SEGMENT_READ_COMPLETE EXPORTING PI_SEGTYP PI_RELEASE PI_VERSION IMPORTING PE_HEADER TABLES PT_FIELDS PT_FVALUES EXCEPTIONS SEGMENT_UNKNOWN OTHERS IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE I NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. PREV_SEGNAME = INT_EDIDD-SEGNAM. ENDIF. READ TABLE IDOC_STRUCT INTO IDOC_STRUCT_WA WITH KEY SEGMENT_TYPE = INT_EDIDD-SEGNAM. IF SY-SUBRC = 0. IF IDOC_STRUCT_WA-SYNTAX_ATTRIB-MUSTFL = X. TMP_STR = Mandatory. ELSE. TMP_STR = Optional. ENDIF. IF IDOC_STRUCT_WA-SEGMENT_TYPE_ATTRIB-QUALIFIER = X. TMP_STR3 = Qualified. ELSE. TMP_STR3 = Non-Qualified. ENDIF. SHIFT IDOC_STRUCT_WA-SYNTAX_ATTRIB-OCCMAX LEFT DELETING LEADING 0. MOVE SEG_REPEATS TO TMP_STR2. CONDENSE: IDOC_STRUCT_WA-SYNTAX_ATTRIB-OCCMAX, TMP_STR2. CONCATENATE TMP_STR2 of IDOC_STRUCT_WA-SYNTAX_ATTRIB-OCCMAX INTO TMP_STR2 SEPARATED BY SPACE. Optional Mandatory = 3. =1 SEGMENT_STRUCTURE_UNKNOWN = 2 = PT_FIELDS2 = PT_FVALUES2 = PE_SEG_HEADER = SEGNAME = SAP_REL = PI_VER

WRITE :/ IDOC_STRUCT_WA-SEGMENT_TYPE, TMP_STR, TMP_STR3, TMP_STR2, IDOC_STRUCT_WA-SYNTAX_ATTRIB-HLEVEL, IDOC_STRUCT_WA-SEGMENT_TYPE_ATTRIB-PLAST, IDOC_STRUCT_WA-SEGMENT_TYPE_ATTRIB-DESCRP. ENDIF. SORT PT_FIELDS2 BY FIELD_POS. BYTE_FIRST = 0. LOOP AT PT_FIELDS2. CLEAR: FIELD_VAL. BYTE_LAST = PT_FIELDS2-EXTLEN. WRITE INT_EDIDD-SDATA+BYTE_FIRST(BYTE_LAST) TO FIELD_VAL LEFT-JUSTIFIED. SHIFT PT_FIELDS2-EXTLEN LEFT DELETING LEADING 0. SHIFT PT_FIELDS2-BYTE_FIRST LEFT DELETING LEADING 0. SHIFT PT_FIELDS2-BYTE_LAST LEFT DELETING LEADING 0. WRITE:/ , PT_FIELDS2-FIELDNAME, PT_FIELDS2-DATATYPE, PT_FIELDS2-EXTLEN, PT_FIELDS2-BYTE_FIRST , PT_FIELDS2-BYTE_LAST, PT_FIELDS2-DESCRP, FIELD_VAL. READ TABLE PT_FVALUES2 WITH KEY FIELDNAME = PT_FIELDS2-FIELDNAME FLDVALUE_L = FIELD_VAL. ADD BYTE_LAST TO BYTE_FIRST. IF SY-SUBRC = 0. WRITE : PT_FVALUES2-DESCRP. ELSE. CLEAR PT_FVALUES2-DESCRP. ENDIF. ENDLOOP. ENDLOOP. ENDFORM. display_data_records

*&* *& * Form read_idoc_structure text *&* *-* FORM READ_IDOC_STRUCTURE. DATA: IDOCTYPE TYPE LEDID_IDOCTYPE. IF NOT IDOC_CONTROL-CIMTYP IS INITIAL. STRUCT_TYPE = E. Extended IDOCTYPE = IDOC_CONTROL-CIMTYP. ELSE. STRUCT_TYPE = B. Basic IDOCTYPE = IDOC_CONTROL-IDOCTP. ENDIF. CALL FUNCTION IDOC_TYPE_COMPLETE_READ EXPORTING RELEASE = SAP_REL

STRUCT_TYPE IDOCTYPE VERSION * * IMPORTING IDOC_TYPE TABLES IDOC_STRUCT SEGMENTS SEGMENT_STRUCT EXCEPTIONS

= STRUCT_TYPE = IDOCTYPE = PI_VER = idoctype = IDOC_STRUCT = SEGMENTS = SEGMENT_STRUCT =1

IDOCTYPE_UNKNOWN

IDOCSTRUCT_UNKNOWN = 2 SEGMENT_DATA_MISSING = 3 ILLEGAL_STRUCT_TYPE = 4 OTHERS IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. ENDFORM. read_idoc_structure = 5.

Creacin de IDOCs de Orden de Compra

El siguiente documento explica como generar IDOCs de Orden de Compra(Purchase order) con Punteros de Modificacin (Changer Pointers). Con las siguientes configuraciones una vez creada una orden de compra desde la transaccin ME21N se generar un archivo de salida (OUTBOUND) de formato XML con el contenido de la orden de compra (IDOC). Primero un poco de teora para entender qu es un IDOC y para qu se utilizan: Los IDocs permiten intercambiar informacin entre distintos sistemas. Se lo puede ver como un archivo de texto plano, con registros. Un Idoc es por ejemplo los datos de un proveedor, o una oferta. Contiene una cabecera y posiciones, pero todos los datos pertenecen a la misma entidad. O sea, para transmitir datos de ms de un proveedor, hara falta ms de un Idoc. Los IDocs se crean y luego se envan. Este envo se realiza en un segundo paso; o sea que podra haber IDocs que todava no se hayan enviado. Un IDoc est formado por tres bloques:

Un registro de Control.

Una tabla con los datos del IDoc. Varios registros de Estado El registro de control contiene toda la informacin administrativa del IDoc, como el origen y el destinatario, y qu tipo de IDoc es. Sera algo as como el sobre que acompaa a cualquier carta. Este registro es muy importante ya que es necesario para saber, entre otras cosas, cul ser el destinatario del IDoc. La tabla SAP donde se guardan es la EDIDC. Los registros de datos se guardan en la tabla EDID4 en un campo de 1000 caracteres. Para saber interpretar esa cadena, el registro cuenta con un campo que informa cul es la estructura con la que se deben interpretar los datos. Generalmente, varios registros de estado se adjuntan a un IDoc. El sistema automticamente asigna registros de estado durante todo el proceso, a medida que el IDoc va alcanzando diversos puntos de control. Contienen informacin de estado, tal como cdigo de estado, fecha y hora en que el punto de control es alcanzado. Estos registros de estado existen solamente en SAP y no son almacenados en el archivo de salida. La estructura de los registros de estado est definida por la estructura del DDIC EDI_DS40. La tabla es EDIDS. Desde la transaccin WE30 se puede ver el formato de los Idocs.

IDOCs para rdenes de compra:

Tipo Base de IDoc:
El primer paso es verificar que contemos en el sistema con el Tipo Base de IdocORDERS05.

Transaccin: WE30

Ingresamos el tipo base ORDERS05 y clickeamos en visualizar.

Debemos obtener algo as.

Tipo de Mensaje en SAP:

En este paso verificamos que tengamos creado el Tipo de Mensaje ORDERS.

Transaccin: WE81
Tenemos que encontrar esto.

Relacin entre un tipo de Mensaje y un Tipo de IDoc:

Ahora tenemos que controlar que exista la relacin entre el tipo de base Idoc y la clase de mensaje.

Transaccin: WE82
Controlamos que figure la siguiente lnea:

Definicin de puerta:
Los Idocs pueden ser enviados y recibidos a travs de diferentes medios. Con el objetivo de no acoplar la definicin de las caractersticas del medio con la aplicacin que lo est utilizando, el medio es accedido va puertos. En otras palabras, un puerto es un nombre lgico para un dispositivo de entrada/salida. Los programas se comunican con un puerto a travs de una interfaz estndar. En vez de definir el medio de comunicacin directamente en el Acuerdo de Interlocutor (Partner Profile), se asigna un nmero de puerto, y es este puerto el que designa realmente al medio. Esto permite definir las caractersticas de los puertos individualmente y usar un puerto en mltiples Acuerdos de Interlocutores. Los cambios en un puerto se reflejarn automticamente en todos los acuerdos que lo estn utilizando. Al menos un puerto debe existir para cada sistema externo. Los tipos de puertos ms comunes son los siguientes: Ficheros (File Interface) Permite intercambiar Idocs a travs de archivos del sistema operativo. El sistema que enva el IDoc crea un archivo en el file system. Luego notifica al sistema receptor va RFC sincrnico que el archivo ha sido transferido, que est localizado en un determinado directorio, y que tiene un determinado nombre. SAP recomienda no usar nombres de archivos estticos, dado que el archivo es sobre escrito cada vez que el Idoc se enva. Se recomienda usar el mdulo de funciones EDI_PATH_CREATE_CLIENT_DOCNUM, el cual genera el nombre del archivo a partir del mandante y nro. de Idoc.

RFC Transaccional Se usa para escenarios de distribucin ALE. El nombre del puerto se puede definir a mano o dejar que SAP lo elija. Adems del puerto, hay que definir el destino RFC. Archivo XML Enva documentos en formato XML. Para utilizar este tipo de puerto, es necesario definir el nombre del puerto, el formato del XML, y el nombre del archivo a generar. Al igual que con el tipo de puerto Fichero, se puede invocar a la funcinEDI_PATH_CREATE_CLIENT_DOCNUM para que genere los nombres del archivo en forma dinmica. XML-HTTP En vez de definir el nombre del archivo XML, se especifica un destino RFC. Para nuestro ejemplo vamos a elegir como salida un Archivo XML. Por lo cual invocaremos a la funcin EDI_PATH_CREATE_CLIENT_DOCNUM para que genere los nombres del archivo en forma dinmica.

Transaccin: WE21
Dentro de la carpeta Fichero XML debemos crear y configurar nuestra Puerta de salida de la siguiente manera.

El Directorio fsico lo podemos elegir a nuestro gusto, tiene que ser un directorio del servidor. Los directorios disponibles los podemos visualizar desde la

transaccin AL11.

Definicin de sistemas lgicos:

Transaccin: BD54

Creamos un Sistema Lgico con el nombre y la descripcin que queramos.

Creacin de los acuerdos de interlocutores:

Un interlocutor ALE es un sistema SAP remoto o un sistema legacy con el que se intercambian datos. El acuerdo de interlocutor especifica varias de las caractersticas de los datos que se intercambian incluyendo el modo de operacin y la organizacin o persona responsable por el manejo de los errores. Cuando los datos son intercambiados entre interlocutores, es importante que el emisor y el receptor estn de acuerdo en la sintaxis y semntica de los datos intercambiados. Este acuerdo es lo que se llama Acuerdo de Interlocutor, y es lo que le informa al receptor de la estructura de los datos enviados y cmo los contenidos deben ser interpretados. Los datos definidos en un acuerdo de interlocutor son: - Tipo de Idoc y Tipo de mensaje, los cuales son el identificador clave del acuerdo de interlocutor.

- Nombre del Emisor y Receptor que intercambiarn los Idocs para el tipo de Idoc y mensaje. - Puerto por el cual el emisor y el receptor se comunicarn. En el interlocutor se definen datos especficos de cada mensaje a transmitir en los parmetros de salida o entrada segn corresponda. Mediante la transaccin WE20 se crea el acuerdo de interlocutor con el sistema lgico.

Transaccin: WE20
Dentro de la carpeta Tp.interlocutor EDI Proveedor/Acreedor creamos lo siguiente:

El N interl.EDI debe llevar el mismo nombre del Sistema Lgico que creamos en el paso anterior. El Tp.int.EDI tiene que ser LI (Proveedor/Acreedor). Luego en la tabla Parmetros salida agregamos en Tipo mensaje: ORDERS. A continuacin hacemos doble click sobre ORDERS y llenamos como muestra esta imagen:

En la solapa Opciones salida, ponemos la Puerta destino que definimos anteriormente y completamos los campos marcados con lnea roja. En la solapa Control de mensajes completamos como se muestra en la imagen:

En Aplicacin ponemos EF (Pedido de compras) Clase mensaje: NEU Cdigo de operacin: ME10 Hacemos doble click sobre ME10 y chequeamos:

El mdulo de funcin IDOC_OUTPUT_ORDERS es la funcin que se va a encargar de recolectar los datos y formar nuestro IDOC.

Activacin de punteros de modificacin en forma global:

Transaccin: BD61
Activamos nuestro puntero de modificacin:

Activacin de punteros de modificacin por Tipo de Mensaje:

Transaccin: BD50
Agregamos una entrada para el mensaje deseado, y la marcamos como activa.

Creacin de una orden de compra:

Transaccin: ME21N
Creamos un Pedido estndar (NB) y luego clickeamos en Mensajes Generamos una clase de mensaje como esta:

Clase de mensaje: NEU Medio: EDI Funcin: PV Interlocutor: ORDERIDOC (nombre del interlocutor que creamos en la definicin de sistemas lgicos) Chequeamos que en Datos adicionales tengamos esto:

Apretamos en el botn GUARDAR y nos saldr el mensaje:

Con todo esto, nuestro IDOC ya tiene que estar creado!!!. Para verificar vamos a la

Transaccin: WE02
Al apretar el botn ejecutar nos listar nuestro IDOC:

La cantidad de registros de datos puede variar segn la orden que hayamos creado. Slo nos resta ir a buscar nuestro IDOC en formato XML en el directorio fsico que hayamos definido en la parte de Definicin de puerta