XML/EDI en el comercio electrónico

Enviado por xmlbyedi

Qué es
EDI
Componentes
EDI
Los estándares EDI
más utilizados en el mundo
Las transacciones EDI
utilizadas en el comercio
electrónico
Las tendencias de XML con
EDI
EDI por
Internet
XML-EDI en el
mundo
Bibliografía

INTRODUCCIÓN

El comercio electrónico en el mundo se basa en la
utilización de estándares internacionales para
poder tener
la
comunicación de sistema a sistema
sin importar la plataforma tecnológica que estén
utilizando las diferentes compañías.

Esto se traduce a que si una compañía que
hoy en día intercambia una orden de compra en forma
electrónica y utiliza un sistema ERP comercial
(SAP) y la otra
compañía recibe electrónicamente ese pedido
y tiene otro sistema de informática diferente se podrán
acoplar ambas compañías, considerando que se
realiza la automatización tanto del emisor como del
receptor.

El EDI tienes sus inicios desde hace más de 20
años en el mundo y es el único estándar a
nivel mundial que ha sobrevivido a pesar del surgimiento de otros
estándares que se han logrado imponer en ciertas regiones
o Países.

Muchas compañías y personas comentan que
EDI esta muriendo y lo remplaza la Internet y XML (Extensible
Markup Language), sin saber que EDI ha evolucionado y convive con
Internet y no difiere con XML.

QUE ES
EDI

Electrónic Data
Interchange por sus siglas en Inglés
es un estándar mundial de comercio electrónico que
nos indica los documentos o
transacciones electrónicas globales que podemos estar
intercambiando con nuestros clientes,
proveedores,
etc., que al entrar en un proyecto de EDI,
se convierten en socios de negocio.

Estos documentos o transacciones electrónica
fueron desarrollados hace más de 20 años por la
ONU. Actualmente
dentro de EDI existen dos grandes que son:

ANSI X-12 (Estados
unidos)
EDIFACT (Europa)

Ambos manejan muchas transacciones electrónica,
pedidos, avisos de pagos, facturas, reportes de ventas etc. El
propósito inicial de EDI es la reducción de
costos,
eliminación de errores, agilización de los procesos. La
comunicación electrónica de sistema
a sistema con la mínima intervención humana para
automatizar los procesos, sin importar las aplicaciones de cada
cliente, ya que
no será necesario que sean las mismas, es decir una empresa
podrá tener su sistema empresarial (ERP), como puede ser
SAP R/3, BAAN, BPCS, etc. y con EDI ellos se pueden estar
intercomunicando.

COMPONENTES
EDI

Hemos que existen los estándares de EDI ya sea
ANSI X-12 ó Edifact, que son los más usuales a
nivel mundial. Para implementar EDI, necesitamos tres componente
básicos:

1.- Software traductor
EDI

2.- Estándar EDI a utilizar

3.- Medios de
comunicación con nuestros socios
comerciales.

SOFTWARE TRADUCTOR

Su función es
la de interpretar los diferentes documentos electrónicos
que vamos a intercambiar con los diferentes estándares de
EDI que recibiremos o enviaremos, este software nos permite
integrar automatizada mente con cualquier sistema de
informática (ERP), no importando las
características de

ellos.

Se podrán comunicar ERP´s como SAP R/R3,
con sus IDOC´s con un AS/400, por ejemplo ó
cualquier otro sistema de informática, además
podremos tener una sola interfaz para recibir pedidos en
diferentes versiones de EDI o estándares X-12 ó
EDIFACT. Estos Software pueden instalarse en

ambientes de Windows,
Unix,
DOS. © Mario Pérez
Villeda e-mail:

Para realizar la comunicación de nuestros
sistemas de
informática con estos software se realiza lo que se llama
Mapeo. El mapeo se realiza en los SW. Para realizar un mapeo
tenemos que definir las características:

1.- Si es de entrada o salida

2.- La versión de EDI

3.- El estándar

Los campos que definiremos entre nuestros sistema de
informática y el documento electrónico.

Pongamos un ejemplo de lo que podemos hacer en
SW.

Tenemos nuestro sistema de informática SAP R/3,
dentro del modulo de pedidos tendremos que generar las ordenes de
compra a nuestros proveedores, como en SAP existe el modulo de
EDI, este nos generara nuestras ordenes de compra con las
características de SAP, que se llaman IDOC´s, nos
genera un archivo de salida
con la definición de un IDOC. Sus características
no podrán ser interpretadas por todos nuestros socios
comerciales, solo los que tengan SAP. Como esto es imposible
tendremos que utilizar un software traductor de EDI, en este SW.
Lo que definiremos será:

1.- El estándar de EDI (ANSI X-12, ó
EDIFACT)

2.- La versión 96-A, etc.

3.- Buscar el documento que se utiliza para las ordenes
de

compra (ORDERS)

4.- Definir la información de nuestro IDOC, que vamos a
enviar:

(Número de pedido, fechas del pedido
[cancelación, generación, envío,
etc.)

5.- Las características de cada campo
(numérico, alfanumérico, etc.)

6.- Generar nuestra guía de
implantación.

7.- Comenzar a realizar nuestro mapeo dentro del
SW.

Una vez realizado lo anterior tendremos que de salida
nos genera un documento de EDI, llamado orders 96-a con los
segmentos equivalentes a nuestra información de SAP, para
que nuestro socios comerciales puedan interpretar la
información y generar su mapeo de entrada con sus sistema
de informática tendremos que enviarle nuestra guía
de implementación., y de esta manera todos podrán
interpretar nuestras ordenes de compra particularizadas apara
cada socio comercial. Además de que estos procesos se
hacen de forma automatizada.

Es la forma en que trabaja un sw. Traductor, donde se
definen nuestro mapeo, se da de alta a nuestro socios
comerciales, con su user id y su calificador, y se realiza la
configuración de los procesos automatizados.
© Mario Pérez Villeda
e-mail:

ESTÁNDAR EDI A UTILIZAR

La definición del estándar a utilizar
depende en gran parte de si somos el receptor o el emisor,
normalmente cuando somos los receptores de un documento EDI
tendremos que adecuarnos a la guía que nos
proporciones.

El estándar EDI nos dice la información de
los campos que son enviados ó recibidos y poder
implementar nuestro mapeo para la integración con nuestras
aplicaciones.

Pongamos un ejemplo siguiendo el anterior de SAP
R/3

Supongamos que vamos a seguir generando las ordenes de
compra para nuestros proveedores.

Para definir el estándar, tenemos que ver
cuál es el estándar global que es más
utilizado, en este caso el que se está manejando es
EDIFACT, ya que tenemos definido el estándar
EDI.

Tendremos que ver el nombre del documento EDI referente
a las ordenes de compra. Buscando el estándar EDI
encontraremos que para pedidos el documento asignado es
ORDERS.

Como Sabemos que existen varias versiones de EDIFACT
96-A, -96-B, etc. Tendremos que ver dentro del nuestro
país o industria
cuál es el que utilizaremos. Por ejemplo en México se
utiliza 96-a, subset EANCOM. Vemos que de momento ya tenemos
definido:

Estándar EDI
Documento EDI
Versión

Lo que tendremos que definir es el origen de nuestros
datos que
genera nuestro sistema y revisar la guía EDIFACT que
utilizaremos para encontrar los segmentos elementos y
calificadores que equivalen a la información generada de
nuestro sistema. Para que pueda generar un documento
EDI.

MEDIOS DE COMUNICACIÓN

Bien de momento tenemos que utilizaremos un sw.
Traductor EDI, el estándar EDI pero faltaría la
comunicación con nuestro socios comerciales. La forma
tradicional de enviar y recibir intercambios con EDI se utiliza
la VAN (VALUE ADDED NETWORK) red de valor
agregado.

La VAN es el medio más seguro y
confiable para la transmisión y recepción de
documentos EDI.

¿Pero cuál es la función de esta
VAN. Y como podemos acceder a este servicio.?

Las VAN´s nos permiten intercambiar documentos EDI
con nuestros socios comerciales, la comunicación con ellas
es mediante una línea telefónica tradicional UN
MODEM y tener
contratado un buzón dentro de la VAN. © Mario Pérez Villeda e-mail:

Cuando se realiza la contratación de este
servicio se les asigna lo que es un USER ID y Calificador, con
estos datos podremos tener comunicación con nuestros
socios comerciales de manera regional ó mundial ya que las
VAN´s pueden intercambiar documentos EDI en cualquier parte
del mundo.

Las VAN´s son mainfraines conectados por
diferentes protocolos de
comunicación, OFTP, X-25, FTP, TCP/IP, etc.;
Normalmente las VAN´s o nodos están en Estado Unidos,
la India y en
México ya se tiene un nodo local.

La forma de transmitir los datos pueden ser de forma
sincronía y asíncrona, la forma sincronía
nos permite enviar o recibir la información en
ráfagas mientras que la asíncrona se transmite por
bloques.

Las VAN´s funciona las 24 horas del día los
365 días del año, y existen personas que dan el
soporte y servicio de ellas de forma directa. Los buzones
privados están activos todo el
tiempo y
permite almacenas la información de cualquier documento
EDI.

Lo interesante de las VAN´s es que podemos enviar
todas nuestra información de una sola llamada y que
será depositada en nuestro buzón y de ahí
podemos dejar toda la información de todos nuestro
proveedores y clientes sin importar el lugar físico donde
se encuentren, ya que les llegará a cada uno de ellos en
el mismo momento en que los generemos.

Los servicios de
VAN los pueden ofrecer IBM, General Electric, Sterling Commerse,
AT&T, etc. El cobro del servicio es diferente en cada una de
ellas y tienen costos por los caracteres enviados ó
recibidos.

¿Pero que pasa si estoy en la VAN de IBM y mi
socio esta en otra VAN diferente, tendré que contratar un
buzón con ese proveedor? "NO".

Para que podamos intercambiar información con
ellos solo le tendremos que solicitar a nuestro proveedor que
realice una interconexión con esa VAN, y lo que
pasará es que al momento de enviar el socio comercial su
información automáticamente será recibida en
nuestro buzón, ya que existirá una referencia
lógica.
Y con ello no importa donde estemos nosotros o nuestro socio
comercial ya que puede estar a la vuelta de la esquina de nuestra
empresa
ó en Japón,
y para nosotros solo será una llamada local donde podemos
recibir cualquier documento electrónico estándar
regulado a nivel mundial.

¿ Las interconexiones tienen costo?

Eso depende en gran parte del proveedor que nos de el
servicio, en algunos casos no tiene costo.

La comunicación con las VAN es punto a punto
mediante una línea telefónica que permite
intercambiar información de forma segura confiable y
confidencial. © Mario
Pérez Villeda e-mail:

EDI & INTERNET

Tenemos que comprender el concepto de
Internet. Como sabemos Internet es la comunicación entre
múltiples servidores que
nos permite intercambiar información, la
comunicación es igual con una línea
telefónica y un MODEM, pero la comunicación no es
directa como el esquema de una VAN, Internet son diferentes
protocolos de comunicación, http, FTP,
SMTP/POP3, TCP/IP, etc. Y
puede en gran parte reducir los costos por la transmisión
de documentos electrónicos. Por lo que ese tema se toca en
la siguiente página sobre protocolos de
comunicación AS1, AS2, ANX, SMTP………… más
información en EDI por Internet en esta

LOS
ESTÁNDARES EDI MÁS UTILIZADOS EN EL
MUNDO

Los estándares EDI a nivel mundial son: ANSI X-12
y EDIFACT, cada uno de ellos maneja transacciones
electrónicas aplicadas a cualquier industria Comercial,
Puertos, Aduanas,
etc.

ANSI X-12 es creado en Estados Unidos

EDIFACT es desarrollado en Europa

Ambos estándares manejan transacciones
electrónicas, su diferencia se encuentra en el formato de
cada uno de ellos. Por ejemplo en ANSI X-12 las transacciones se
reconocen por números la 850 Purchase Order, y en EDIFACT
tienen nombres como es el caso del ORDERS, que es la misma
transacción.

ANSI X-12

Publica un release ó versión por
año y se identifican por números, por ejemplo:
3020, 3040, 3060. 4010, etc.

EDIFACT

Pública sus release dos veces por año,
versión "A" y "B", y se identifican con el año
96-A, 96-B, etc.

En la ONU existe un grupo que
regula los estándares de EDI y sus tendencias, por lo que
ahora en el último consenso mundial se ha decidió
solo utilizar un solo estándar y este es EDIFACT. ANSI
esta de acuerdo con la ONU y han comenzado a migrar a EDIFACT,
por lo que será común encontrar a diferentes
industrias en
diferentes partes del mundo utilizando ambos
estándares. © Mario
Pérez Villeda e-mail: xmlbyedi[arroba]yahoo.com.mx

Para conocer un poco más de ANSI X-12 y EDIFACT,
describiré sus características.

ANSI X-12

Maneja SEGMENTOS, ELEMENTOS DE DATOS, ELEMENTOS
COMPUESTOS DE DATOS, y su estructura
es:

UN SEGMENTO que contiene un elemento de datos y puede
tener un elemento compuesto que califica al elemento de datos.
Esto se parece mucho a los conjuntos, un
conjunto a que contiene dentro un conjunto b y puede tener un
conjunto C, el saber leer un diccionario de
datos ANSI X-12 es sencillo, solo tienes que aprender los
números de transacciones, y los directorios de segmentos
de datos. Trataré de explicar lo más sencillo un
documento EDI.

Dentro de las transacciones EDI, se identifican por
número, existe una breve explicación de su uso. Y
de ahí se derivan las tablas, cada tabla indica si es un
encabezado ó un detalle, dentro de ellos contiene los
segmentos a utilizar, su ID, y su nombre, además de
sí es requerido ó no, es decir que tiene que ir el
segmento y cada cuando lo podemos utilizar. Además de los
calificadores que podemos utilizar.

Las transacciones de EDI en ANSI X-12, son: desde la 104
hasta llegar a la 997, y cada número

Tipo Símbolo

Numérico Nn

Número decima l R

identificador ID

String AN

Día DT ( CCYYMMDD)

Hora TM ( hhmmssd…d)

Binario B

Fixed Length String FS

M Mandatorio

O Opcional

P Paridad múltiple

R Requerido

E Excluyente

C Condicional

L Lista condicional

Los elementos compuestos siempre califican al elemento y
mucho de ellos pueden tener diferentes condiciones, todo depende
de la transacción en X-12. Para darnos una idea de un
mensaje EDI X-12. © Mario
Pérez Villeda e-mail: xmlbyedi[arroba]yahoo.com.mx

Ejemplo de ANSI X-12:

BG*MXUR003*MAEU*MXUR003*MAEU*010727*1343*GS*SO*MXUR003*MAEU*010727

*1343*
143*X*003030ST*322*00044267*GLDU*0534054*26676*G*11023******

CN*N/A****A*L
*4*HP***4500*M7*A5231533***W2*GLDU*0534054**CN*L*****

BG Es un elemento

* Es un separador de elemento de datos

~ Es un delimitador de terminación de
segmento.

Es más fácil de interpretar ya que no
maneja muchas condiciones como ANSI X-12, pero si encontramos en
los segmentos y elementos de datos con sus opciones de
Mandatorio, opcional, condicional, etc.

Ejemplo de EDIFACT:

UNB+UNOA:1+ENSENADAINTERNATIONALTERMINAL+TRANSPORTACION+010717

:0755+258+++UNH+2572+BAPLIE:1:911:UN:SMDG15BGM++2572+9'TDT+20+003WB+

+:103::TMMSINALOA++MLL:172:20'LOC+61+MXZLO'DTM+178:0107170755:201DTM+

133:0107170755:201

LAS
TRANSACCIONES EDI UTILIZADAS EN EL COMERCIO
ELECTRÓNICO

Existen diversos tipos de documentos EDI y/o
transacciones electrónicas que podemos utilizar y mucho
dependerá del sector y de la industria que lo utilicemos.
Muestra de
ello son los documentos ANSI X-12, que son muy utilizados en la
industria automotriz, y en EDIFACT tenemos muchos que se utilizan
en sectores del Retail, Puertos, Bancos,
etc.

No obstante la industria automotriz esta también
utilizando EDIFACT. Para diferencia cada uno de ellos, en esta
página presentare algunas transacciones y las industrias
que lo utilizan, si requieren más información de
las transacciones sigue el link que requieras:

SECTOR AUTOMOTRIZ

Transacción

830 Release ANSI X-12

856 ASN ANSI X-12

810 Invoice ANSI X-12

820 Aviso de pagos ANSI X-12

DELFOR Programación de entregas EDIFACT

999 Confirmación de recepción-envío
ANSI X-12

SECTOR TEXTIL Y RETAIL

Sector Retail y Textil: (Wal-Mart, Sears, ….), los
documentos más comunes son:

En el caso de las tiendas de Textil, están
enviando en la transacción EDI, el formato y tipo de
etiqueta que requieren, cuando sus proveedores les entreguen la
mercancía ya etiquetada.

Transacción Descripción Estándar

Orders Orden de compra EDIFACT

Remadv Aviso de pagos EDIFACT

850 Orden de compra ANSI X-12

SLSRPT Reporte de Ventas EDIFACT

DESADV Aviso anticipado de embarque EDIFACT

SECTOR BANCARIO (BANCOMER, BITAL, …), los
documentos más comunes son:

PAYMUL Orden de pago originador EDIFACT

CREMUL Aviso de pago del banco receptor
EDIFACT

SECTOR ADUANAS

CUSDEC Declaración electrónica de aduanas
EDIFACT

CUSRES Mensaje de respuesta EDIFACT

Existen más sectores y diferentes tipos de
mensajes que se pueden integrar así como el sentido de los
mismos, para concluir solo realizare un ejemplo de un operador
logístico, es decir algo que existe en Europa y que se
utiliza para manejar las mercancías de un fabricante y
poder llegar a todos los puntos de entrega en el menor tiempo y
reduciendo los costos por almacenaje, distribución, entregas, etc.:

LAS TENDENCIAS DE
XML CON EDI

Para poder determinar si realmente XML sustituye a EDI
tendremos que realizar una comparación

El XML (eXtensible Markup Languaje), es el lenguaje de
marcas creado
por Charles F. Goldfarb auxiliado por Ed Mosher y Ray Lorie a
finales de los 70´, su objetivo fue
que la gestión
y edición
de documentos pudieran ser entendidos por la diferentes
aplicaciones y plataformas tecnologías.

El diseñar documentos electrónicos en XML
es sencillo y fácil de manejar. Al igual que todo lenguaje tiene
sus peculiaridades. Que se conocen como DTD´s, Schemas,
etc.

Actualmente XML esta de moda en el mundo
del EDI, y los que no conocen muy bien el tema han llegado a
opinar que lo sustituye. Lo cuál no comparto con ellos en
este momento, ya que si comparamos a EDI, tenemos que enfocarnos
en dos cosas:

1.- Las comunicaciones

2.- Los estándares EDI (EDIFACT, ANSI X-12,
ODETTE, etc.)

Para comparar XML v.s. EDI, tendremos que enfocarnos en
ambos y obtener los beneficios de uno y de otro

EDI

Maneja los estándares de comercio
electrónico, si nos enfocamos a EDIFACT, tendremos que la
versión 2002-A, maneja 194 transacciones
electrónicas que pueden ser utilizadas a nivel global en
las diferentes industrias Retail, Automotriz, Puertos, Aduanas,
Bancos,

Las transacciones electrónicas nos dicen como
podemos utilizar los documentos, es decir si mi orden de compra
en papel que le envío a mis proveedores la quisiera
trasladar a un Estándar EDI, primero tendría que
realizar un selección:

1.- El estándar a utilizar ANSI X-12 o
EDIFACT

2.- La transacción equivalente a la orden de
compra

3.- La versión de EDI que
utilizaré.

Una vez que tenemos seleccionado lo anterior, tendremos
que buscar los segmentos EDI, que serian los equivalentes en mi
orden de compra, por ejemplo:

En las ordenes de compra manejamos diferentes fechas,
fecha de envío, fecha de entrega, cancelación,
etc., su equivalente en EDI versión EDIFACT es DTM, por lo
que donde encontremos un segmentos DTM, nos indicará que
son fechas.

Ahora bien como no todas la fechas son las mismas
tendremos que diferenciarlas mediante calificadores, mismos que
están en las guías EDI.

El número 137 es la fecha en que se creo la orden
de compra, y el número 2 corresponde a la fecha de
cancelación por ende, nuestro documento en papel ya
trasladado a EDI nos dará los segmentos y calificadores
necesarios para convertirlo a un estándar que podrá
ser interpretado por cualquier socio comercial, sea nacional,
extranjero y de cualquier parte del mundo,

DTM+137 = Fecha de la orden de compra

DTM+2 = Fecha de cancelación

En conclusión:

EDI es un estándar global que nos dice como
convertir los documentos en papel a transacciones
electrónicas que podrán ser interpretados por los
diferentes socios comerciales que conozcan los estándares
EDI (regulados a nivel mundial por la ONU, EAN Internacional,
EANCOM)

XML

Para crear un documento en papel a un documento
electrónico utilizando XML, es algo sencillo y
fácil de lograr.

XML maneja lo que son las etiquetas, y ellas se crean
con corchetes de inicio y de fin, la etiqueta final se antepone
una barra.

<?xml version="1.0">

<pedido>Orden de compra</pedido>

<orden_de_compra>Orden de
Compra</orden_de_compra>

<numero_pedido>1234556</numero_pedido>

</documento>

Por lo que podemos crear nuestro documento en XML mucho
más sencillo y práctico que con EDI, ya que
nosotros elegimos el formato de la etiqueta y de su
significado.

Otro punto importante antes de terminar nuestro
documento en XML es considerar las DTD´s,
(definición del tipo de Documento) que nos dicen la
definición del tipo de etiqueta, si es numérica,
alfanumérica, etc.

Existen DTD´S o Schemas, internas y externas, las
internas están en nuestro documento XML, y las externas
hacen referencia a una liga url, en Internet.

Para saber si nuestro documento en XML esta bien formado
existen los parsel, que nos indican que valores
están mal estructurados.

En conclusión:

Crear documentos en XML es muy sencillo y fácil
de realizar, pero tenemos el problema de la
estandarización de las etiquetas, es decir yo podré
utilizar la etiqueta <pedido> para mi orden de compra,
alguien más utilizará <PEDIDO>, otros
<PURCHASE>, etc., y lo que obtendremos al final será
un documento XML propio donde nuestros socios comerciales
tendrán que estar constantemente en comunicación
con nosotros para conocer los datos que viajan
electrónicamente.

Actualmente existen iniciativas a nivel global que
están trabajando en la estandarización de las
etiquetas en XML lo que podrá ayudar a crear documentos
electrónicos globales y exista compatibilidad con
EDI.

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

Al realizar ejemplo de transmisión de datos en
XML, vemos que un documento formado en XML, ocupa más
espacio que una transacción en EDI no puede ser
transportado por la redes privadas (VAN), y el
tiempo de envío y recepción es un poco más
que el de una transacción en EDI. (dependiendo del tipo de
comunicación, dial up, LAN,
etc.)

Si está pensando en migrar sus soluciones de
EDI a XML, antes considere realizar un breve análisis de sus situación actual de
lo que ha logrado con EDI y de los beneficios que tendrá
al utilizar XML, considero que aún no es tiempo de migrar
las transacciones a XML ya que no existe un estándar
global.

* AS1, AS2, http, https, tcp/ip, ftp, etc.

** PGP, certificados y firmas digitales, SSL,
etc.

——————————————————————-

Sitios de interés:

www.w3c.org

www.globalcommerceinitiative.org

www.xml.org

EDI POR
INTERNET

!Quien no conoce la historia esta condenado a
repetirla!!, es por eso importante realizar un breve
análisis de EDI antes de enfocarnos a EDI por
Internet.

El objetivo principal de EDI es la transmisión
electrónica de transacciones de sistema a sistema con la
mínima intervención humana agilizando los procesos
y eliminando los errores.

Los estándares de EDI, nos dicen como estructurar
documentos electrónicos, tales como pedidos pagos, avisos
de embarque, etc, donde los más utilizados son ANSI X-12
(USA) y EDIFACT (Europa), se escucha algo de XML, pero esto
aún no ha madurado con respecto a EDI.

Si nos remontamos 15 años atrás
encontraremos que no existía la Internet como uso
comercial, teníamos comunicaciones
propietarias sobre MS-DOS, con
módems internos o externos cuyas velocidades poderosas
eran de 1200 bps.

Por lo que para transmitir nuestras transacciones EDI se
basaban en comunicaciones seguras punto a punto y donde la VAN
(red de valor agregado), era y es el medio de almacenamiento,
validación, certificación y transporte de
transacciones EDI.

Ahora en el año 2003, encontramos la Internet, y
el hablar de Internet involucra muchas cosas, por lo que solo nos
avocaremos a plantear la parte de algunos protocolos de
comunicación, que son los que actualmente algunas empresas en
Europa, América
están utilizando para hacer EDI seguro por Internet (ya
que de esta manera realizar más transacciones
electrónicas que generan valor agregado y/o bien que
están utilizando para realizar ECR. o para reducir los
costos por tráfico de VAN.)

AS1/AS2 (Applicability Statement)

En USA algunas empresas están comenzando a utilizar
AS2, que no es más que una comunicación HTTPS, SSL,
con encriptación, smime y firma digital, lo que les
representa una gran inversión en nivel de comunicaciones,
seguridad,
soporte y que en el mediano plazo les permitirá recuperar
su inversión y eliminar algunos costos por tráfico.
El inconveniente de utilizar AS2, es que no esta enfocado para
las PYMES quienes
representan el 80-20 (Ley del pareto),
los cuáles tienen que recurrir a terceros para poder
realizar una emulación de AS2 a AS1, y viceversa.

AS1, es otro esquema de comunicación que utiliza la
Internet como medio de comunicación y que se basa en una
comunicación SMTP/POP3, que hoy en día la mayor
parte de las empresas utiliza en los correos
electrónicos.

Para garantizar la seguridad se emplean encriptación de
la información con certificados digitales y/o PGP. En
Costa Rica se
esta utilizando mucho este medio de comunicación y que es
más barato y da la misma seguridad que un protocolo AS2.
que permite integrar y reducir costos por tráfico de
VAN.

ANX / ENX / JNX

En la industria automotriz, encontramos a las principales
plantas armadoras
que tienen diferentes protocolos de comunicación de
acuerdo a sus necesidades, entre ellos encontramos ANX (American
Network Exchange) , que es el que se utiliza en América,
ENX, es la identificación de Europa y JNX, se utiliza para
Asía.

Incorporando tecnología de
última generación, los protocolos y
estándares más comunes (TCP/IP), y la máxima
seguridad (autoridades de certificación, firma
electrónica, IPSec, encritpado y cifrado,…)

Este protocolo de comunicación es más robusto y
no solo esta planteado para EDI, ya que tiene muchas ventajas y
permite realizar transmisiones de datos, video, voz, por
lo que es algo más caro que un servicio de EDI por
VAN.

Aunado a ellos las plantas armadoras han incorporado
iniciativas de EDI por Internet utilizando el protocolo de
comunicación HTTPS, y otras peculiaridades para sus
proveedores que no pueden utilizar ANX, caso concreto la
iniciativa de Daimler Chrysler conocido con Ebmx.

ebXML (electronic business Extensible Markup
Language)

Es una iniciativa de comunicaciones de datos por Internet por
la ONU, la CEFACT/OASIS, y estructura los procesos de transmitir
datos seguros como
pueden ser transacciones EDI y/o XML.

Utilizando un repositorio de datos con comunicación con
múltiples formas de transmitir (http, smtp, corba, etc), y
nos permite tener cualquier tipo de seguridad smime, pgp, etc.
Además de la estructuración de los documentos
enviados y recibidos, lo que permite realizar los esquemas de
seguridad que dan ahora las VAN, (autentificación, no
repudiación, etc).

VPN (Red Virtual Privada)

Las Redes Privadas Virtuales o VPN, constituyen
una tecnología de redes relativamente reciente, que le
permite acceder a una red remota en Internet o
a una red que está conectada a Internet por medio de una
conexión cifrada segura.

Una red privada virtual consiste en dos máquinas
(una en cada "extremo" de la conexión) y una ruta o
"túnel" que se crea dinámicamente en una red
pública o privada. Para asegurar la privacidad de esta
conexión los datos transmitidos entre ambos ordenadores
son encriptados por el Point-to-Point protocol (PPP), un
protocolo de acceso remoto, y posteriormente enrutados o
encaminados sobre una conexión previa (también
remota, LAN o WAN) por un dispositivo PPTP.

Otras alternativas de encriptado son PTPT (Tunneling
protocol), LTP2 o IPSec (en sus distintos niveles de seguridad
incluido 3DES) que garantizan la confidencialidad de las
comunicaciones a través de una red no propietaria.

Las principales ventajas que ofrece una VPN
son:

Confidencialidad: previene que los datos que viajan por
la red sean leídos correctamente.

Integridad: asegura que los datos de origen correspondan
a los de destino.

Autentificación: asegura que quien solicita la
información exista.

Control de acceso: restringe el acceso a usuarios no
autorizados que quieran infiltrarse en la red.

Secure Shell

Algunas empresas en México están
comenzando a utilizar Secure Shell, lo que les permite eliminar
los costos por tráfico de VAN.

Secure Shell y OpenSSH permiten realizar la
comunicación y transferencia de información de
forma cifrada proporcionando fuerte autenticación sobre el
medio inseguro. Este tipo de conexión se muestra en
la
ilustración siguiente:

Ssh provee fuerte autenticación y
comunicación segura sobre un canal inseguro y nace como un
reemplazo a los comandos telnet, ftp,
rlogin, rsh, y rcp, los cuales proporcionan gran flexibilidad en
la
administración de una red, pero sin embargo, presenta
grandes riesgos en la
seguridad de un sistema. Adicionalmente, ssh provee seguridad
para conexiones de servicios X Windows y envío seguro de
conexiones

Conclusiones:

Podría exponer más soluciones de EDI
seguro por Internet y de las diferentes adaptaciones que algunas
industrias en México, Europa, Costa Rica y USA,
están utilizando para hacer intercambio electrónico
de documentos en XML/EDI, y que buscan eliminar los gastos de VAN
para integrar a la comunidad de
negocios y
hacer un B2B.

Al igual que XML/EDI aún existen dudas en que
utilizar para hacer B2B, estamos en la misma posición con
el medio y el protocolo de transmitir la
información.

Lo importante es identificar una solución de
Software B2B, que nos permita utilizar de forma simultanea
EDIFACT, ANSI X-12, XML, que soporte cualquier tipo de protocolo
de comunicación (VAN, Internet), y que solo represente una
sola interfaz para integrarlo con nuestros sistema
ERP.

En México existen este tipo de soluciones que
hacen que el B2B sea algo sencillo de realizar y se integran a
nuestro negocio.

XML-EDI EN EL
MUNDO

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

Bibliografía

Mario Pérez Villeda

http://mx.geocities.com/xmlbyedi

Tel 04455-1473-4779

Tel. 5395-9217 Ext. 103

e-mail: mvilleda[arroba]buzonabc.com

xmlbyedi[arroba]yahoo.com.mx

Mario Pérez Villeda

mvilleda[arroba]buzonabc.com

xmlbyedi[arroba]yahoo.com.mx

SOBRE EL AUTOR:

Mario Pérez Villeda nació en la ciudad de
Mexico D.F. y a publicado y escrito numerosos artículos de
EDI y XML para varios países como Costa Rica, Argentina,
España,
México, Guatemala.

Su acercamiento con EDI se realiza en el año de
1998 donde realizo el proyecto de integración B2B con
Clientes y Proveedores de la Compañía Casa Autrey
en la Cd. de
México donde destacan la integración con Grupo
Cifra Wal-Mart, Costco, Comercial Mexicana, Soriana y proveedores
como Procter & Gamble, Colgate, Pfzier, Roche Syntex,
etc.

Integrando transacciones como Ordenes de compra, avisos
de embarque, etc, utilizando los estándares ANSI X-12 y
EDIFACT,

Además a formado parte del comité de
usuarios de EDI en AMECE desde 1998, y participo en la
integración de XML con la iniciativa EBXML desde el
año 1999.

A impartido cursos, seminarios y conferencias en
empresas publicas, privadas y asociaciones civiles.