idocs_V2

i3S retail

TECNOLOGÍA ALE: INTERFAZ IDOC SAP R/3 4.6C

1 de 63 25/07/2005

i3S retail

1.- INTRODUCCIÓN A ALE ................................................................................................................................................................................................................3 1.1.- ALE ...........................................................................................................................................................................................................................................3 1.2.- EDI............................................................................................................................................................................................................................................3 1.3.- SISTEMA LÓGICO (LS) ...........................................................................................................................................................................................................4 1.4.- TIPO DE MENSAJE .................................................................................................................................................................................................................6 1.5.- TIPO DE IDOC Y IDOC............................................................................................................................................................................................................6 1.6.- MANTENIMIENTO DEL MODELO DE DISTRIBUCIÓN........................................................................................................................................................10 1.7.- PUERTAS...............................................................................................................................................................................................................................11 1.8.- CÓDIGOS DE OPERACIÓN..................................................................................................................................................................................................14 1.9.- PERFILES DE INTERLOCUTOR EDI....................................................................................................................................................................................15

2.- DISTRIBUCIÓN DE DATOS MAESTROS ...................................................................................................................................................................................16 2.1.- ENVÍAR DATOS DIRECTAMENTE: CASO PRÁCTICO, ENVIAR DATOS MAESTROS DE ARTÍCULOS .........................................................................20 2.2.- PUNTEROS DE MODIFICACIÓN: CASO PRÁCTICO, ENVIAR DATOS MAESTROS DE ARTÍCULOS............................................................................23

3.- DISTRIBUCIÓN DE DATOS TRANSACCIONALES ...................................................................................................................................................................26 3.1.- INTERFAZ DE SALIDA: CASO PRÁCTICO, ENVIAR UN PEDIDO DE COMPRAS ............................................................................................................26 3.2.- INTERFAZ DE ENTRADA: CASO PRÁCTICO, RECIBIR UNA ENTRADA DE MERCANCÍAS.........................................................................................35

4.- OPTIMIZACIÓN ALE: EXTENSIÓN Y REDUCCIÓN DE IDOCS...............................................................................................................................................42 4.1.- EXTENSIÓN DE IDOCS. CASO PRÁCTICO AÑADIR CAMPOS PARA LA DISTRIBUCIÓN DE CLIENTES.....................................................................42 4.2.- REDUCCIÓN DE IDOCS. CASO PRÁCTICO REDUCIR CAMPOS EN LA DISTRIBUCIÓN DE ACREEDORES ..............................................................52

5.- BAPIS ...........................................................................................................................................................................................................................................56 5.1.- INTRODUCCIÓN A LAS BAPIS.............................................................................................................................................................................................56 5.2.- EL BUSINESS OBJECT BROWSER (SWO2) .......................................................................................................................................................................57 5.3.- EL EXPLORADOR BAPI ........................................................................................................................................................................................................58 5.4.- INTRODUCCIÓN A LA DISTRIBUCIÓN MEDIANTE BAPIS ................................................................................................................................................59

5.4.1.- Filtrado de Datos y Determinación de los receptores......................................................................................................................................................62

2 de 63 25/07/2005

i3S retail

1.- INTRODUCCIÓN A ALE

1.1.- ALE • Application Link Enabling es la tecnología de SAP que permite la comunicación de datos entre dos o más sistemas SAP y/o entre SAP y/o entre un

sistema SAP y sistemas externos. • ALE facilita el desarrollo de las interfaces reduciendo su tiempo de implantación. • Los escenarios ALE se encuentran en tres categorías:

o Datos maestros o Datos transaccionales o Control de los datos distribuidos

• Las principales ventajas de la utilización de la tecnología ALE son: o Son independientes de versión o Posee potentes mecanismos de captura de cambios para los maestros de datos y transacciones o Reduce el tiempo de implementación o Necesita poco desarrollos ABAP.

1.2.- EDI • Electronic Data Interchange es una tecnología que permite el intercambio de documentos entre distintos interlocutores de una empresa como bancos,

clientes, acreedores. • Tienen un formato normalizado. • Algunas áreas de SAP tienen capacidad EDI, dentro de SAP, EDI y ALE, utilizan las mismas herramientas.

3 de 63 25/07/2005

i3S retail

1.3.- Sistema Lógico (LS) • Un sistema lógico (LS) es la representación de un sistema externo (ya sea SAP o no) para la distribución de datos • Cada mandante SAP también representa un sistema lógico. • La asignación Mandante vs Sistema Lógico debe ser unívoca: Un mandante únicamente debe estar asignado a un sistema lógico. Esto

también es válido para los sistemas preproductivos y productivos • En una interface ALE de entrada, el LS representa el remitente con respecto al LS original (receptor). • En una interface ALE de salida, el LS representa el receptor o el sistema externo.

• Mantenimiento de los sistemas lógicos

Dentro del menú de customazing SALE podemos encontrar todas las transacciones que necesitamos • Definir Sistema Lógico

Menú IMG – Base Application Link Enable Preparar sistemas receptores y de envío Preparar sistemas lógicos Nombrar sistema lógico

Código de Transacción BD54

Por ejemplo creamos el sistema lógico TEST1.

4 de 63 25/07/2005

i3S retail

• Asignar sistema lógico a un mandante

Tal y como hemos comentado con anterioridad, los mandantes deben estar asociados unívocamente a un sistema lógico. Esta parametrización no se puede transportar. Menú SALE Preparar sistemas lógicos Asignar sistema lógico a

un mandante

Código de Transacción SCC4

Aquí podemos ver que nuestro mandante (500) está asociado al sistema lógico 500T01

5 de 63 25/07/2005

i3S retail

1.4.- Tipo de Mensaje • Un tipo de mensaje, representa el mensaje que se intercambiado entre SAP y otro sistema externo (ya sea SAP o no) • Por lo general los tipos de mensajes están asignados de forma unívoca a tipos de documentos SAP. En lo posible sus nombres corresponden a los del

estándar UN/EDIFACT. Los escenarios ALE, sin embargo, a menudo no corresponden a EDIFACT, por ejemplo, cuando se transmiten datos maestros. • El tipo de mensaje determina la estructura de los datos • Por ejemplo el tipo de mensaje MATMAS es el tipo de mensaje utilizado para el maestro de artículos, INVOIC para las facturas…

1.5.- Tipo de IDOC y IDOC • Un tipo de IDOC (Intermediate DOCument) o tipo base representa la estructura de datos asociada a un tipo de mensaje ( por ejemplo el tipo base

MATMAS03 para el mensaje MATMAS, WMMBID01 para el tipo de mensaje WMMBXY –movimiento de mercancías…) • Un IDOC es un container de datos con “inteligencia” que contiene uno y solo un objeto empresarial. Por ejemplo, el pedido de compras 4711 fue enviado

al proveedor con el IDOC 0815, el IDOC 0815 tiene el formato del tipo base ORDERS01. El pedido de compra, se corresponde con el tipo de mensaje ORDERS.

• Un IDOC consiste en tres tipo de registros: o Registro de control (EDI_DC) o Registros de datos (EDI_DD) o Registros de status (EDI_DS)

6 de 63 25/07/2005

i3S retail

• El registro de control o EDI_DC contiene información sobre el IDOC, como el tipo base, el tipo de mensaje, el receptor, el emisor, dirección (1 de salida, 2

de entrada). El registro EDI_DC se guarda en la tabla EDIDC • El registro de datos o EDI_DD contiene los datos de la aplicación, cada registro tiene una serie de campos clave que definen el contenido del registro y un

campo SDATA que contiene los datos de la aplicación con en la estructura que indica el campo SEGNAM. Los registros EDI_DD se guardan en la tabla EDID4

• El registro de status o EDI_DS contiene información del estado del IDOC en las distintas etapas del proceso, mantiene el histórico del proceso. Los registros EDI_DS se guardan en la tabla EDIDS. Los posibles status de los IDOCs se encuentran en la tabla TEDS1. Los valores de status de los IDOCs de salida se encuentran entre el ‘01’ y el ‘49’ mientras que los de entrada están entre el ‘50’ y el ‘99’.

• Existen varias transacciones para obtener documentación sobre los IDOCS:

o Para los campos de los tipos de registro Menú WEDI Documentación Clases de registros IDOC

Código de Transacción WE61

7 de 63 25/07/2005

i3S retail

• Para los tipos de IDOC

Menú WEDI Documentación Tipos de IDOC


Ejemplo tipo base MATMAS03

8 de 63 25/07/2005

i3S retail

• Para los segmentos de los IDOCS

Menú WEDI Documentación Segmentos IDOC


Ejemplo visualización del segmento E1MARM

9 de 63 25/07/2005

i3S retail

1.6.- Mantenimiento del Modelo de distribución • El Modelo de Distribución es una herramienta que almacena información sobre el flujo de mensajes entre varios sistemas • Es posible especificar filtros de la información que se va a enviar

Menú SALE Modelar e implementar procesos empresariales Actualizar modelo de distribución y distribuir vistas


1. Pulsar Vista Modelo e introducir la siguiente información

2. Aceptar y grabar la información

10 de 63 25/07/2005

i3S retail

1.7.- Puertas • Las puertas son el canal para la comunicación usadas por SAP • En SAP existen varios tipos de puertas, la selección del tipo de puerta depende de la configuración técnica del sistema externo • En la mayoría de casos, los IDOCs se transfieren como ficheros secuenciales y se utiliza el tipo de puerta Fichero • Se debe asignar al menos un puerto para cada sistema lógico La siguiente imagen muestra como los IDOCs son enviados a dos sistemas lógicos a través de tres puertas.

Port type Application area

File Interface Link to most EDI subsystems

Transactional RFC

ALE distribution scenarios

CPI-C Link to R/2 System: Direct communication with an R/2 System (from version 5.0F onwards) is only possible via this port type.

Internet Sending to e-mail addresses

Programming Interface (PI)

The IDoc is not exchanged with an external system but rather with a function module you have written. This means that any dispatch type can be used.

XML E-commerce

11 de 63 25/07/2005

http://help.sap.com/saphelp_46c/helpdata/es/88/baec64163711d2a5660060087832f8/frameset.htm

http://help.sap.com/saphelp_46c/helpdata/es/dc/6b7f6343d711d1893e0000e8323c4f/content.htm



http://help.sap.com/saphelp_46c/helpdata/es/dc/6b7fb143d711d1893e0000e8323c4f/content.htm

http://help.sap.com/saphelp_46c/helpdata/es/dc/6b7ff243d711d1893e0000e8323c4f/content.htm

http://help.sap.com/saphelp_46c/helpdata/es/d5/edf163dcdc11d1890c0000e8216438/content.htm

http://help.sap.com/saphelp_46c/helpdata/es/d5/edf163dcdc11d1890c0000e8216438/content.htm

http://help.sap.com/saphelp_46c/helpdata/es/3f/faa285bb7911d2897f0000e8216438/content.htm

i3S retail

Menú Herramientas _ Business Comunication Base IDOC

IDOC Descripción puerta


Por ejemplo creamos la puerta PUERTACURS de tipo Fichero

El módulo de fucnciones EDI_PATH_CREATE_CLIENT_DOCNUM se utiliza para crear los nombres de los ficheros

12 de 63 25/07/2005

i3S retail

Ejemplo de puerta tipo XML

13 de 63 25/07/2005

i3S retail

1.8.- Códigos de operación

• El código de operación se utiliza para identificar el proceso específico, por ejemplo el módulo de funciones o la tarea workflow que utilizan los IDOCs para

ser enviados o recibidos. • Hay dos tipos de códigos de operación:

o Códigos de operación de salida. Si se utiliza la determinación de mensajes para la generación de IDOCs, el código de operación contiene el módulo de funciones que genera el fichero

o Código de operación de entrada. Contiene la tarea workflow o el módulo de funciones que lee el IDOC y lo transfiere al sistema para crear el documento

• Para obtener información sobre los códigos de operación:

Menú WEDI Documentación Código de Operación


Ejemplo del código de operación M 10 para el tipo de mensaje ORDE ERS

14 de 63 25/07/2005

i3S retail

1.9.- Perfiles de Interlocutor EDI

• Un perfil de interlocutor EDI es un identificador para un sistema usado en la comunicación de mensajes, se debe mantener la información de tipo de mensaje, puerta y código de proceso utilizados.

• Los principales tipos de interlocutores EDI son : o B para bancos o KU para clientes/deudores o LI para proveedores/acreedores o LS para sistemas lógicos

15 de 63 25/07/2005

i3S retail

2.- DISTRIBUCIÓN DE DATOS MAESTROS • Este capítulo trata de la distribución de datos maestros mediante ALE • Podemos distribuir abarcan un rango de datos como materiales, clientes, proveedores, clases, condiciones, centros de coste…Se puede encontrar una

lista de los mensajes que se pueden distribuir en: http://help.sap.com/saphelp_46c/helpdata/es/07/acdfab6829d3119b440060b0671acc/frameset.htm • Hay tres opciones para distribuir datos maestros desde SAP:

o Enviar datos maestros directamente, a través de una serie de programas ALE o Capturar todos los cambios ocurridos en los datos maestros, luego esos cambios se conviertan en IDOC y se transmiten. Es lo que se conoce

como punteros de modificación o “ir a buscar” los datos maestros desde otro sistema R/3, esta opción es posible para unos cuantos tipos de mensajes.

Vamos a construir un ejemplo para distribuir datos maestros de material usando el tipo de mensaje MATMAS entre el sistema lógico de nuestro mandante 500T01 y el sistema lógico que creamos TEST1.

1. Mantener el Modelo de Distribución Menú SALE Modelar e Implementar procesos empresariales

Actualizar modelo de distribución y distribuir vistas


• Nos posicionamos sobre el modelo que creamos en el capítulo anterior (MODISTRCUR) y pulsamos Insertar tipo mensaje. Introduciremos la

siguiente información:

16 de 63 25/07/2005

http://help.sap.com/saphelp_46c/helpdata/es/07/acdfab6829d3119b440060b0671acc/frameset.htm

i3S retail

• Grabamos

17 de 63 25/07/2005

i3S retail

2. Definir y mantener Acuerdos entre Interlocutores EDI

• Definir Tipo de Interlocutor EDI

Menú SALE Modelar e Implementar procesos empresariales Configurar acuerdo entre interlocutores y fecha Actualizar a mano acuerdos entre interlocutores EDI WEDI IDOC Acuerdo entre interlocutores EDI


Elegimos Tipo de interlocutor EDI LS y pulsamos crear.Introducimos la siguiente información y pulsamos grabar:

18 de 63 25/07/2005

i3S retail

• Crear los parámetros de salida, pulsamos dentro de los parámetros de salida e introducimos la siguiente información:

19 de 63 25/07/2005

i3S retail

2.1.- Envíar datos directamente: Caso práctico, enviar datos maestros de artículos SAP proporciona una serie de programas para enviar datos maestros completos. En el siguiente ejemplo, vamos a enviar seis materiales:

Menú Herramientas ALE Distribución de datos maestros

Multiaplicaciones Material Enviar


El sistema nos informa que se han generado los IDOCs.

20 de 63 25/07/2005

i3S retail

Para generar los ficheros

Menú BALE Monitoring Monitor status para mensajes ALE


Introducimos los criterios de selección pertinentes y procesamos los IDOCS, generados

Para ver los ficheros generados, desde el log de cualquiera de los IDOCs procesados :

21 de 63 25/07/2005

i3S retail

Para visualizar el fichero, podemos utilizar la transacción AL11

22 de 63 25/07/2005

i3S retail

2.2.- Punteros de modificación: Caso práctico, enviar datos maestros de artículos • Los cambios en los datos maestros se guardan en las tablas CDHDR y CDPOS. • Una vez activados los punteros de modificación, el sistema genera registros en las tablas BDCP y BDCPS. • Un programa ALE procesa selecciona todos los registros de las tablas no tratados y los convierte en IDOCs. • Se pueden establecer filtros.

1. Activar Punteros de Modificación

• Activación general de punteros de modificación Menú SALE Modelar e Implementar procesos empresariales

Configurar reproducción de datos modificados Activación general de puntero de modificación


Introducimos la siguiente información: • Activar puntero de modificación por tipo de mensaje

23 de 63 25/07/2005

i3S retail

Menú SALE Modelar e Implementar procesos empresariales

Configurar reproducción de datos modificados Activar puntero de modificación por tipo de mensaje


Marcar el Tipo de Mensaje MATMAS

1. Convertir punteros de modificación en IDOCs

• Ahora, al crear (MM01), modificar (MM02) o marcar para borrado (MM06) se debe enviar un IDOC. En nuestro ejemplo, modificamos la descripción del material 100113. Observamos que en la tabla BDCPV aparece la entrada :

• El campo PROCESS, indica que todavía no se ha generado un IDOC para esa e El campo CDCHGID informa de si la entrada se refiere a una modificación, si

ntrada • es un

registro nuevo o si se ha borrado

24 de 63 25/07/2005

i3S retail

Para generar el IDOC, procederemos de la siguiente manera

Menú BALE Servicios Puntero de modificación Evaluar

Código de Transacción BD21 Introducimos el mensaje MATMAS y ejecutamos, el sistema nos informa de los IDOCs que se han creado

2. Visualizar los IDOCs generedos. • Existen varias transacciones para visualizar los IDOCs. Vamos a ver la siguiente:



Establecemos los criterios de selección pertinentes y ejecutamos la transacción:

El status 30, indica que el IDOC ha sido creado pero no enviado, para hacerlo, ejecutamos la selección. Pulsamos Procesar Ahora aparece la siguiente pantalla:

Si navegamos por la pantalla, doble clic en la selección y nuevamente doble clic en el número de IDOC, podemos ver la estructura del IDOC y donde se ha grabado la información

25 de 63 25/07/2005

i3S retail

3.- DISTRIBUCIÓN DE DATOS TRANSACCIONALES La principal diferencia entre la distribución de datos maestros y la distribución de datos transaccionales, es la manera de generar los IDOCs. Mientras que para la distribución de datos maestros, utilizamos mecanismos como los punteros de modificación o programas que envían los datos cuando y como nosotros queramos, la distribución de datos transaccionales, en la mayoría de casos, se realiza mediante la determinación de mensajes.

3.1.- Interfaz de Salida: Caso Práctico, enviar un pedido de compras En este capítulo, vamos a enviar un pedido de compras, lo haremos mediante el tipo de mensaje ORDERS y con el tipo base ORDERS05. Seguiremos los siguientes pasos:

1. Configurar el modelo de distribución Menú SALE Modelar e Implementar procesos empresariales

Actualizar modelo de distribución y distribuir vistas


Nos posicionamos en el modelo deseado, marcamos Insertar Tipo de Mensaje e introducimos la siguiente información:

Pulsamos continuar y grabamos

26 de 63 25/07/2005

i3S retail

2. Determinación de salida.

Está basado en la determinación de mensajes, tal y como configuramos por ejemplo que se genere un determinado formulario o para los precios de compra o de venta. Deben estar creadas las tablas de condiciones y las secuencias de acceso para dichas tablas

• Crear/Visualizar tablas de condiciones de pedido Menú SPRO Gestión de materiales Compras Mensajes

Control de salida Tablas de condiciones Fijar tablas de condiciones para pedido Mensajes: visualizar tabla de condiciones de pedido.

Código de Transacción M/61

En esta transacción podemos ver las distintas posibilidades que tenemos para crear mensajes. Podemos crear nuevas tablas de condiciones si es preciso. Para nuestro ejemplo elegimos la tabla 026 por Clase de documento.

• Crear visualizar secuencias de acceso Para acceder a las tablas de condiciones, necesitamos las secuencias de acceso.

Menú SPRO Gestión de materiales Compras Mensajes Control de salida Secuencias de acceso Control de salida

Secuencias de acceso Fijar secuencia de acceso para pedido

Vemos que la secuencia de acceso estándar 001, contiene la tabla 026

27 de 63 25/07/2005

i3S retail

3. Configurar el tipo de salida Debemos configurar el tipo de mensaje que deseamos que se cree al generar un pedido.

Menú SPRO Gestión de materiales Compras Mensajes Control de salida Clases de mensajes Fijar clases de mensajes para pedido Actualizar clases de mensajes para pedido

Código de Transacción M/34

• Creamos un tipo de mensaje como copia de NEU • Introducimos una descripción y la Secuencia de acceso 0001 • Dentro de los valores de propuesta elegimos • Dentro de Rutinas de proceso, nos aseguraremos que existe la entrada :

• Dentro de Funciones de interlocutor que para el medio Distribución ALE, existe la entrada PR Proveedor.

28 de 63 25/07/2005

i3S retail

• En la siguiente actividad, indicamos para que operaciones vamos a crear los mensajes.

Menú SPRO Gestión de materiales Compras Mensajes Control de salida Clases de mensajes Fijar clases de mensajes para pedido Control detallado del pedido

Para indicar que queremos generar mensajes ZNEU cuando se creen o modifiquen pedidos: • Tenemos que enlazar el tipo de mensaje ZNEU con el esquema de mensajes

Menú SPRO Gestión de materiales Compras Mensajes Control de salida Esquemas para mensajes Especificar esquemas de mensajes para pedido Actualizar esquema para mensajes: pedido

Código de Transacción

Añadimos la entrada ZNEU en el esquema estándar RMBEF1:

29 de 63 25/07/2005

i3S retail

• Nos aseguramos que la orden de compra está asignada al esquema RMBEF1.

Menú SPRO Gestión de materiales Compras Mensajes Control de salida Esquemas para mensajes Especificar esquemas de mensajes para pedido Asignar esquema a pedido

Código de Transacción

• El último paso es crear los registros de condición para las tablas de condiciones

Menú Logística Gestión de materiales Compras Pedido Datos maestros Mensajes Pedido Crear

Código de Transacción MN04

Elegimos la clase de mensaje ZNEU y para la secuencia de acceso Clase de documento

30 de 63 25/07/2005

i3S retail

4. Mantener los perfiles de Interlocutor

Menú WEDI IDOC Acuerdo entre interlocutores comerciales EDI


Creamos un nuevo parámetro de salida con las siguientes características: La entrada sin el indicador de mensajes es para la creación de pedidos, mientras que la otra es para la modificación de pedidos.

31 de 63 25/07/2005

i3S retail

5. Creación del IDOC Para crear el IDOC, ahora sólo tenemos que crear o modificar un pedido de tipo NB, comprobamos que se crea un mensaje de tipo ZNEU.

Por ejemplo hemos creado el pedido de compras 4500000283, vamos a visualizarlo mediante la transacción ME23N y en Pasar a Mensajes podemos ver que efectivamente se ha creado el tipo de mensaje. En el log de proceso, nos informa del IDOC que se ha generado

32 de 63 25/07/2005

i3S retail

6. Visualización del IDOC.

En el capítulo anterior vimos la transacción BD87, ahora veremos otra transacción para monitorizar los IDOCs: Menú WEDI IDOC Visualizar IDOC

Transacción WE02

In

troducimos los parámetros de selección correspondientes:

33 de 63 25/07/2005

i3S retail

Haciendo doble clic sobre el número de IDOC:

34 de 63 25/07/2005

i3S retail

3.2.- Interfaz de entrada: Caso Práctico, recibir una entrada de mercancías

En esta sección vamos a procesar un IDOC de entrada, concretamente, vamos a recibir una entrada de mercancías para un pedido, simulando que nos lo envían de un almacén que no maneja SAP. El tipo de mensaje, será el WMMBXY con el tipo base de IDOC WMMBID02. WMMBXY es un potente mensaje que permite hacer muchos tipo de movimientos de mercancía: entradas con referencia a pedido, con referencia a órdenes de producción, cambio de status del stock…. 1. Mantenimiento el Sistema Lógico y el modelo de distribución

• Vamos a crear un sistema lógico llamado ALMACÉN, que será el emisor de nuestro mensaje. Menú IMG – Base Application Link Enable Preparar sistemas

receptores y de envío Preparar sistemas lógicos Nombrar sistema lógico


Mantenemos creamos un modelo de distribución llamado MODELOALM con el sitema lógico emisor ALMACEN y con el sistema receptor nuestro mandante 500T01. Incluimos el mensaje WMMBXY

35 de 63 25/07/2005

i3S retail

2. Actualización de los interlocutores EDI Creamos

el interlocutor EDI, ALMACEN de tipo LS y le incluimos el parámetro de entrada WMMBXY:

36 de 63 25/07/2005

i3S retail

3. Generar el IDOC Esta es la parte más laboriosa, porque tenemos que fabricar un fichero con la estructura del IDOC. ExIDOCs, pero es muy posible que queramos construir desde el propio SAP un IDOC para simular el

isten softwares externos que mapean ficheros en proceso de recepción de un IDOC.

Podemos hacer un sencillo progra demás de las estructuras correspondientes a cada segmento. Con tipos de IDOC que son tanto de entrada como de salida podemos utilizar la transaLa opción más recomendada es utilizar la transacción de test que SAP proporciona para crear, modificar I • En esta parte y con ayuda de la documentación del IDOC (WE60, WE62) vamo

Mediante esta transacción podemos genera IDOCs a partir de otro, podemos mTambién como en nuestro caso podemos crear un tipo de IDOC.

Ponemos tipo base WMMBID02 y ejecutamos:

ma en ABAP, utilizando las estructuras EDI_DC (para generar la cabecera) y EDI_DS (para generar el detalle), a

cción WE12 DOCs.

s construyendo un IDOC.

odificarlo y ejecutarlos.

Menú WEDI Test Herramientas de test


37 de 63 25/07/2005

i3S retail

• Lo primero que rellenamos es la estructura del registro de control: EDIDC. Hacemos clic sobre EDIDC e introducimos la siguiente información

ar según las

• Ahora rellenamos el segmento E1MBXYH que corresponde a la cabecera del documento (obviamente esta información puede variparametrizaciones del sistema) en nuestro caso introducimos lo siguiente:

38 de 63 25/07/2005

i3S retail

• Rellenamos el segmento E1MBXYI que corresponde a la posición del documento de entrada de mercancías para el pedido 4500000284:

39 de 63 25/07/2005

i3S retail

• Creamos otro segmento de posición como copia del anterior. Nos posicionamos sobre el segmento E1MBXYI botón derecho copiar.el icono de pegar y elegimos al mismo nivel

Clic sobre

odificamo ción de

4. Procesar el IDOC. Desde la misma transacción podemos procesar el IDOC, podemos elegir procesarlo:

o De forma estándar (lo que esté parametrizado en el mantenimiento de los acuerdos de inte ón) o Mediante un módulo de funciones. El sistema nos deja elegir si hay más de una funci demos

ejecutarlo en fondo o visible…y podemos utilizar el debugg. o A partir de un fichero.

Elegimos Entrada estándar , el primer mensaje que aparece, el sistema comprueba que la cabecera es correcta, (existe los acuerdos deintrerlocutores, las puertas…). Aceptamos el mensaje. Aparece lo siguiente:

Se crea un nuevo segmento de posición, ahora m s los datos pertinentes como posi l pedido, cantidad…

rlocutor, a través del código de operación asociada a ese mensaje. Además po

40 de 63 25/07/2005

i3S retail

I

5. Visualizar el IDOC.

ntroducimos el número de IDOC 202042


C

Si vemos el pedido 4500000284 (ME23N)

ódigo de Transacción BD87

41 de 63 25/07/2005

i3S retail

4.- P CIÓN ALE: EXTENSIÓN Y

dar no or completo los requerimientos que tenemos, en muchos casos es posible añadir funcionalidad a los IDOCs. Por ejemplo, podemos “extender” el IDOC para crear nuevos campos y modificar la función ALE que lo procesa para dar contenido a esos campos

ños los ficheros y mejorando por tanto

En este capítulo trabaj s con el MATMAS.

En nue n el segmento E1KNVKM envía el nombre de la persona de contacto pero no la dirección del mismo (es posib s el deudor 241 en la sociedad ARAN. En la pestañ

O TIMIZA REDUCCIÓN DE IDOCS

Es posible que los IDOCs están cumplan p• • También podemos “reducir” el tipo de IDOC para eliminar campos que no necesitamos, haciendo más peque

los procesos de comunicación.

aremos la “extensión” de los IDOCs con el DEBMAS, mientras que la reducción la trabajaremo

4.1.- Extensión de IDOCs. Caso práctico Añadir campos para la distribución de clientes

stro ejemplo, el tipo de IDOC DEBMAS05 ele que otros IDOCs si la envíen). Si vamos al maestro del cliente: Transacción XD03 e introducimo

a de Persona de contacto si pulsamos el botón Direc. Personal

42 de 63 25/07/2005

i3S retail

Sabem que los datos de dirección se encuentran en la tabla ADRC (se accede a ella a través de la tabla KNVK, a partir del campo ADRNP_2). Los pasos que deberemos seguir son:

to E1KNVKM • Se deberá crear un tipo de extensión ZDEBMASX

1. Crea

• Introducimos el nombre del segmento a crear Z1ADRC y clic sobre Crear

os

• Crearemos un nuevo segmento Z1ADRC asociado al segmen

• Crearemos un nuevo tipo de IDOC ZDEBMASX asociado al tipo de mensaje DEBMAS • Finalmente chequearemos los datos.

r el segmento Z1ADRC

Menú WEDI Desarrollo Segmentos IDOCs


• Insertamos la siguiente información:

43 de 63 25/07/2005

i3S retail

á una pantalla de carácter informativo: • Pulsamos grabar. Aparecer

. Crea un tipo de extensión y un

• ón •

2 ción de nuevo segmento

Me WE Desarrollo Tipos de IDOCnú DI

Có

En nombre, introducimos ZDEBMASX y marcamos el radio-button de AmpliaciClic en Crear, introducimos la siguiente información:

digo de Transacción WE30

44 de 63 25/07/2005

i3S retail

• No nsaje informándonos que el nuevo segmento se aplica como hijo de E1KNVKM.

s posicionamos sobre E1KNVKM y clic sobre Crear, nos aparece un meIntroducimos la siguiente información y grabamos:

45 de 63 25/07/2005

i3S retail

3. Crear un nuevo tipo de IDOC

Debemos asociar nuestra ampliación a un tipo de mensaje

• •

Ahora asociamos la ampliación ZDEBMASX al tipo base ZDEBMASZ. Desde la pantalla principal de WE30 (Objeto ZDEBMASX y el check de Ampliación: Utilidades Ampliación Asignar Tipo Base)

Introducimos ZDEBMASZ como nombre de Objeto Marcamos el radio-buton de Tipo Base y clic sobre Crear

Menú WEDI Desarrollo Tipos de IDOC


46 de 63 25/07/2005

i3S retail

4. Asociar el Tipo de IDOC al Tipo de Mensaje

• Marcamos Modificar y Entradas

5. • n ZDEBMASX desde la transacción WE30.

Menú WEDI Desarrollo Tipos IDOC/Mensaje

Código de Transacción WE82 Nuevas :

Grabamos la información introducida

Verificar el Tipo de IDOC Primero debemos liberar el Tipo Base ZDEBMASZ y la ampliació

47 de 63 25/07/2005

i3S retail

• ve pliación como para el Tipo Base

6. P

os el código en la función EXIT_SAPLVV01_001

Ahora desde la misma transacción WE30, pulsamos rificar, tanto para la am

rogramar la user-exist

Creamos un proyecto, (CMOD) y le asignamos la componente VSV00001, introducim

48 de 63 25/07/2005

i3S retail

7.

Actualizar los acuerdos de Interlocutor

Menú WEDI IDOC Acuerdo entre interlocutores comerciales EDI


49 de 63 25/07/2005

i3S retail

8. Testear la aplicación.

hora, por fin, verificamos que el proceso funciona correctamente.

A

Menú Herramientas ALE Distribución de Datos Maestros Multiaplicaciones Cliente Enviar


50 de 63 25/07/2005

i3S retail

Visualizamos el IDOC que acabamos de generar, por ejemplo con la BD87.

51 de 63 25/07/2005

i3S retail

4.2.- Reducción de IDOCs. Caso práctico Reducir campos en la distribución de acreedores • eños • No se pueden desactivar los segmentos o campos obligatorios • No todos los mensajes se pueden reducir, en el customazing encontramos una guía con los IDOC que se pueden reducir:

En nuestro ejemplo reduciremos el tipo de IDOC CREMAS Procederemos de la siguiente manera:

1. Crear el IDOC reducido

• Introducimos ZCREM y clicamos el botón de crear, le indicamos que el modelo es CREMAS

La reducción de IDOCs optimiza el proceso de comunicación ya que se generan ficheros más pequ

s

Menú SALE Modelar e implementar procesos empresariales Configurar distribución de datos maestros Especificar alcade los datos que se deben distribuir Reducir mensajes Crear tipo de mensaje reducido

nce

Código de Transacción Clicar sobre la ayuda

Menú SALE Modelar e implementar procesos empresariales Configurar distribución de datos maestros Especificar alcance de los datos que se deben distribuir Reducir mensajes Crear tipo de mensaje reducido


52 de 63 25/07/2005

i3S retail

Entramos una descripción y aceptamos Seleccionamos los campos que queremos añadir, primero debemos marcar el segmento y luego seleccionar los campos, en nuestro caso vamos a

a or.

el segmento no está seleccionado

• ndica que el segmento está seleccionado

Los campos en verde son obligatorios y no se pueden quitar

• Clic sobre Seleccionar

rabamos

••

ñadir a los campos obligatorios, la fecha de creación del registro y autor en la vista de sociedad del acreed

• G

• El signo (-) indica que

El signo (+) i

•

53 de 63 25/07/2005

i3S retail

2. Testear la aplicación

• Incluimos en nuestro modelo de distribución el mensaje ZCREM (BD64)

• Actualizamos los acuerdos de interlocutor (WE20)

54 de 63 25/07/2005

i3S retail

• enviamos el IDOC con la transacción BD14

• Visualizamos el IDOC

55 de 63 25/07/2005

i3S retail

5.-

• Las• Las• Gra• El siguiente gráfico m

BAPIS

5.1.- Introducción a las BAPIs

BAPIs (Business Application Programming Interfaces) son el estándar de las interfaces de SAP BAPIs permiten la conexión entre un sistema SAP y otro sistema ya sea SAP o no. cias a su componente RFC, pueden ser llamadas desde programas desarrollados en Visual Basic o Java.

uestra las posibles utilidades de las BAPIs

56 de 63 25/07/2005

i3S retail

5.2.- El Business Object Browser (SWO2) • bu cumentos) • El Busine P. • Se accede m

Los siness objects types son la representación de entidades de negocio (datos maestros, doss Ojecct Browser (BOR) muestra una visión en clave de Orientación a Objetos del sistema SA

ediente la transacción SWO2:

57 de 63 25/07/2005

i3S retail

5.3.- El Explorador BAPI rador BAPI (Transacción BAPI) permite buscar las BAPIS existentes en el sistema, bien por jerarquía de negocio bien por orden alfabético:

• El explo

58 de 63 25/07/2005

i3S retail

5.4.- Introducción a la distribución mediante BAPIs

obtener una lista de clientes. Antes de la destino RFC

ra la lectura de datos externos. Por ejemplo, si generamos un documento FI a destino, pero la red cae mientras la BAPI está siendo

umento podría ser creado nuevamente, con lo cuál, el documento estaría

car datos en uno o más sistemas lógicos, por ejemplo, para distribuir datos PIs, se debe haber generado una interfaz ALE IDOC que controla la

Deb stas

o Cambios en la base de datos. Se producen actualizaciones en la base do Conexión débil (loose coupling). Con una interfaz síncrona entre

conexión, el cliente podría no ser capaz de trabajar correctamente. o Rendimiento. La interfaz tiene un gran volumen de datos, o el servidor deb

la interfaz síncrona no puede ser utilizada porque su rendimiento puede Si mediante las BAPIs estándar podemos modelar nuestro proceso ALE, entonces, simplem

o Filtrado de datos o Determinación de los Receptores

En cambio, si necesitamos desarrollar nuevas BAPIs o modificar las existentes, deberemo Implementar una nueva BAPI o Mantener la interfaz BAPI-ALE o Determinación de los receptores

ALE soporta dos tipos de llamadas: o Llamadas síncronas.

a la lectura de datos en un sistema remoto, por ejemplo paraNormalmente son utilizadas parllamada a la BAPI se debe determinar elLas llamadas asíncronas deberían ser utilizadas únicamente pamediante una llamada síncrona, el documento se genera correctamente en el sistemejecutada, la aplicación devolvería un mensaje de error y el docduplicado.

o Llamadas asíncronas. Las llamadas asíncronas se utilizan normalmente para para replimaestros. Para implementar una interfaz asíncrona mediante BAcomunicación entre los sistemas

eríamos implementar un modelo asíncrono si se cumple al menos una de e condiciones: e datos de ambos sistemas

el cliente y el servidor es demasiado estrecha. Si se interrumpe la

e llevar a cabo una gran cantidad de operaciones. En este caso ser muy pequeño.

ente necesitaremos seguir los siguientes pasos:

os seguir los siguientes pasos:

59 de 63 25/07/2005

i3S retail

asíncrona, en el sistema receptor, el sistema llama a la interfaz ALE del IDOC en lugar de a la BAPI. Se realizan los

siguientes

o o

El siguiente gráfico, muestra el proceso de distribución de datos mediante BAPIs

El proceso se divide en los siguientes subprocesos: 1. Proceso de salida:

• Determinación del receptor • Llamada al modulo de función de salida generado • Conversión BAPI <->IDOC • Filtrado de datos • Envío del IDOC

2. Envío del IDOC: Los IDOCs son envíados a la capa de comunicación, mediante

tRFC o mediante ficheros. 3. Proceso de entrada:

• Filtrado de datos • Conversión de los campos • Control de la transferencia (decide a que BAPI llamar) • Conversión IDOC <-> BAPI • Determinación del status del IDOC • Manejo de errores

Cuando utilizamos las BAPIs de forma procesos:

o Crear un IDOC desde los datos del BAPI Enviar el IDOC al sistema destino Recibir el IDOC en el sistema destino y llamada a la BAPI.

60 de 63 25/07/2005

i3S retail

Se puede utilizar la transacción BDBG para crear los objetos necesarios para el proceso, esto es, el IDOC y los módulos de funciones.

Por ejemplo par método CANCEL (BAPI_GOODSMVT_CANCEL)

Menú Herramientas ALE Desarrollo ALE BAPI Actualizar interfase ALE

a los movimientos de mercancía (objeto BUS2017) existe el

Códi d BDBGgo e Transacción

61 de 63 25/07/2005

i3S retail

5

Para las lla d de filtrado de datos: • Reducc . No se basa en condiciones Filtrado d

.4.1.- Filtrado de Datos y Determinación de los receptores

ma as asíncronas a BAPIs, existen dos tiposión de la Interfaz. Puede ser mediante campos o completamente

e parámetros. Basado en condiciones. •

Function module Features

ALE_BAPI_GET_FILTEROBJECTS Determining Filter Objects of BAPIa

ALE_ASYNC_BAPI_GET_RECEIVER Determining Receivers of Asy rnch onous BAPIs

ALE_SYNCH_BAPI_GET_RECEIVER Determining Receivers of Synchronous BAPIs

ALE_BAPI_GET_UNIQUE_RECEIVER Determining Unique Receivers s of Synchronous BAPI

El proceso de generación del IDOC depende de la aplicación, el siguiente ejemplo es apli , en el cual, un módulo de funciones es el responsable de la generación del IDOC. • El módulo de funciones es llamado por la transacción • El módulo de funciones, genera un IDOC, que es transferido a la función MASTER_IDO• MASTER_IDOC_DISTRIBUTE chequea el IDOC y llama a la función COMUNICATION es decir, elimina los datos que no

son necesarios para la comunicación)

cable a un escenario ALE

C_DISTRIBUTE _IDOC_CREATE (filtra el IDOC,

62 de 63 25/07/2005

i3S retail

Ejempl ograma con llamada asíncr on llamada síncrona o de pr ona: Ejemplo de programa c

data declaration

data: fifilterobj_types like bdi_fobjtype occurs 0,

exceptionsrror_in_filterobjects = 1 rror_in_ale_customizing = 2.

* call generated ALE interface function module

if sy-subrc <> 0. if not bapi_logsys[] is initial.call function ‘ALE_DEBITOR_CREDITACC_REPLICATESTATUS’tablesreceivers = bapi_logsys...commit work.endif.endif.

* data declaration

data: filterobj_values like bdi_fobj occu 0,

...endif. endif.

lterobj_values like bdi_fobj occurs 0,

bapi_logsys like bdi_logsys occurs 0.filterobj_types like bdi_fobjtype occurs 0bapi_server like bdibapidest occurs 0.

rs,

filterobj_values-objtype = ‘KKBER’.filterobj_values-objvalue = ‘0002’.append filterobj_values.

* get receiver from ALE distribution model

call function ‘ALE_ASYNC_BAPI_GET_RECEIVER’exportingobject = ‘BUS1010’method = ‘REPLICATESTATUS’tablesreceivers = bapi_logsysfilterobject_values = filterobj_values

* fill filterobject values into table

filterobj_values-objtype = ‘KKBER’.filterobj_values-objvalue = ‘0002’.append filterobj_values.

* get receiver from ALE distribution model

call function ‘ALE_SYNC_BAPI_GET_RECEIVER’exportingobject = ‘BUS1010’method = ‘GETSTATUS’tablesreceivers = bapi_serverfilterobjects_values = filterobj_valuesexceptionserror_in_filterobjects = 1 error_in_ale_customizing = 2.

* call synchronous BAPI locally/remotely

if sy-subrc <> 0. if not bapi_server[] is initial.loop at bapi_server.call function‘BAPI_DEBITOR_CREDITACC_GETSTATUS’destination bapi_server-rfc_dest...endloop. else.call function‘BAPI_DEBITOR_CREDITACC_GETSTATUS’

ee

63 de 63 25/07/2005

idocs_V2

Documents

Transcript of idocs_V2