EDI. Monitorización de los Idocs

Seguimos hablando de temas EDI. En este post vamos a ver como podemos monitorizar todo el flujo de IDOCs que tengamos en SAP.

La interfase idoc  ofrece dos maneras diferentes de realizar el seguimiento de los datos cargados en el sistema y su evolución:

• Informes para la monitorización.
• Workflow para la monitorización.

Ambos métodos se basan en el concepto de transiciones de status. Un idoc cambia de status de un valor dado a otro.

Para acceder a la monitorización de los idocs entramos a través del menú de ámbito ‘WEDI’ a la transacción WE02 – Visualizar idoc

Esta transacción muestra todos los datos del registro de control del idoc para su selección.

La presentación de la información se distribuye en carpetas de ‘Idocs Salientes’ y ‘Idocs Entrantes’, y dentro de ellas, por clase de mensaje.

Para acceder a los datos de los idocs basta con realizar doble click sobre la línea deseada. Los datos se presentan en carpetas, para los tres tipos de registros existentes: 

• Registro de control.
• Registro de datos.
• Registro de status. 

Otra transacción a tener en cuenta es WE07 – Estadística Idoc  Con esta transacción se seleccionan los idocs que se encuentran en error, con las condiciones de selección introducidas, mostrando los datos en carpetas de ‘Idocs salientes’ y ‘Idocs entrantes’. 

En próximos post seguiremos viendo otras transacciones que pueden ayudarnos a monitorizar todo el flujo de Idocs.

EDI. Creación de los acuerdos de interlocutor

Continuamos con los post dedicados a EDI. En este caso vamos a explicar que son y como se crean los acuerdos de interlocutor en SAP.

El acuerdo de interlocutor especifica varias de las características de los datos que se intercambian incluyendo el modo de operación y la organización o persona responsable por el manejo de los errores. Cuando los datos son intercambiados entre interlocutores, es importante que el emisor y el receptor estén de acuerdo en la sintaxis y semántica 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 cómo los contenidos deben ser interpretados.

La 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 intercambiarán los idocs para el tipo de idoc y mensaje. 
• Puerto por el cual el emisor y el receptor se comunicarán. 
• En el interlocutor se definen datos específicos de cada mensaje a transmitir en los parámetros de salida o entrada según corresponda. 

Mediante la transacción WE20 se crea el acuerdo de interlocutor con el sistema lógico.

El siguiente es un ejemplo de un acuerdo de interlocutor para un tipo de mensaje de salida de SAP R/3 a un proveedor EDI, el tipo de mensaje de facturas (INVOIC). En la tabla “parámetros de salida” de la parte derecha de la pantalla se deberá crear una entrada pulsando el botón ‘+’.

EDI. Definición de puerta y sistemas lógicos

En este post vamos a seguir avanzando con EDI. Ya hemos visto anteriormente los que es un IDOC. Ahora vamos a continuar viendo como definir la puerta y los sistemas lógicos para poder trabajar con EDI desde SAP.

Los idocs pueden ser enviados y recibidos a través de diferentes medios. Con el objetivo de no acoplar la definición de las características del medio con la aplicación que lo está utilizando, el medio es accedido vía puertas. En otras palabras, una puerta es un nombre lógico para un dispositivo de entrada/salida. Los programas se comunican con una puerta a través de una interfaz estándar.

En vez de definir el medio de comunicación directamente en el Acuerdo de Interlocutor (Partner Profile), se asigna un número de puerta, y es esta puerta la que designa realmente al medio. Esto permite definir las características de las puertas individualmente y usar una puerta en múltiples Acuerdos de Interlocutores. Los cambios en una puerta se reflejarán automáticamente en todos los acuerdos que lo estén utilizando.

Al menos debe existir una puerta para cada sistema externo. Los tipos de puertas más comunes son los siguientes (desde la transacción WE21):

• Ficheros (File Interface). Permite intercambiar idocs a través de archivos del sistema operativo. El sistema que envía el idoc crea un archivo en el file system. Luego notifica al sistema receptor vía RFC sincrónico 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 estáticos, dado que el archivo es sobrescrito cada vez que el idoc se envía. Se recomienda usar el módulo de funciones EDI_PATH_CREATE_CLIENT_DOCNUM, el cual genera el nombre del archivo a partir del mandante y número de idoc.
  
• RFC Transaccional. Se usa para escenarios de distribución ALE. El nombre del puerto se puede definir a mano o dejar que SAP lo elija. Además del puerto, hay que definir el destino RFC.
  
• Archivo XML. Envía documentos en formato XML. Para utilizar este tipo de puerta, es necesario definir el nombre de la puerta, 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 función EDI_PATH_CREATE_CLIENT_DOCNUM para que genere los nombres del archivo en forma dinámica.
  
• XML-HTTP. En vez de definir el nombre del archivo XML, se especifica un destino RFC. 

Además de definir la puerta deberemos definir los sistemas lógicos utilizando la transacción BD54 y asignar estos sistemas lógicos al mandante que corresponda con la transacción SCC4.

IDOCs en SAP

En este post vamos a seguir hablando de un tema que introducimos hace algún tiempo, EDI. Y mas en concreto vamos a ver que es un IDOC.

Los idoc permiten intercambiar información entre distintos sistemas. Se puede ver como un archivo de texto plano, con registros. Un idoc es por ejemplo los datos de un cliente, o un pedido de venta.

Contiene una cabecera y posiciones, pero todos los datos pertenecen a la misma entidad. O sea, para transmitir datos de más de un cliente, haría falta más de un idoc.

Los idocs se crean y luego se envían. Este envío se realiza en un segundo paso; o sea que podría haber idocs que todavía no se hayan enviado.

Un idoc, como se mencionó más arriba, está formato por dos bloques:

• Un registro de control.
• Una tabla con los datos del idoc.

El registro de control contiene toda la información administrativa del idoc, como el origen y el destinatario, y qué tipo de idoc es. Sería algo así como el sobre que acompaña a cualquier carta. Este registro es muy importante ya que es necesario para saber, entre otras cosas, cuál 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 cuál es la estructura con la que se deben interpretar los datos. El nombre de dicha estructura existe en SAP y se puede ver desde la transacción SE11.

Desde la transacción WE30 se puede ver el formato de los idocs. Por ejemplo, para el idoc ORDERS05, el formato es el siguiente:

Generalmente, varios registros de estado se adjuntan a un idoc. El sistema automáticamente asigna registros de estado durante todo el proceso, a medida que el idoc va alcanzando diversos puntos de control. 

Contienen información de estado, tal como código 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.

EDI en SAP. Introducción

En este post vamos a hacer una introducción al mundo EDI desde SAP.

Introducción

Un sistema EDI se utiliza para transmitir electrónicamente documentos comerciales y administrativos entre aplicaciones informáticas, en un formato normalizado, de esta forma la información entre las empresas puede ser procesada sin intervención manual.    

A la hora de integrar un sistema EDI deberemos analizar:

a  El volumen de documentos comerciales/administrativos intercambiados.

a  El actual porcentaje de error en el tratamiento de documentos sobre Papel.

a  El coste del tratamiento y mantenimiento de documentos sobre papel.

a  El factor tiempo (si es crítico o no).

a  El valor estratégico asignado al EDI en términos de beneficios a largo plazo.

Entre los principales beneficios que nos aporta trabajar con un sistema EDI, cabe destacar:

§  Agilización de procesos comerciales .

§  Importante disminución de errores en los documentos .

§  Ahorro de costos de administración.

§  Mejora de la competitividad de la empresa que lo adopta.

SAP – EDI

La aplicación SAP R/3 no genera ni recibe documentos estándar EDI. SAP R/3 trabaja con un formato propietario llamado IDOC (Intermediate Document)  para la transferencia de datos entre aplicaciones.

Para la integración de SAP R/3 en un entorno EDI es necesario la utilización de un subsistema externo que realice la conversión de los formatos IDOC a formatos estándar EDI.

 

Estructura de los IDOC:

 

 

Las estructuras IDOC se componen de 3 tipos de registros:

 

• Registro de Control

Existe un único registro de control, entre la información que almacena cabe destacar, el Idoc ID  un nº de 16 dígitos, asignado automáticamente por el sistema y que sirve como identificador único de un Idoc en un sistema SAP R/3.

En el registro de control también se almacena información referente a los interlocutores comerciales así como al tipo de Idoc.

 

• Registros de datos de aplicación

Existen múltiples registros de datos, esto vendrá definido según la estructura del tipo de Idoc.

Cada registro de datos se compone de una parte de control donde se almacena el nombre del segmento. Y una parte de datos donde se almacenan cada uno de los campos de datos de este segmento.

 

• Registros de Status.

Pueden existir múltiples registros de status para un idoc  que nos van reflejando cada uno de los pasos de proceso en el que se ve involucrado el idoc.

 

Es un tema que da para mucho. Seguiremos hablando de el en próximos post.