El EDI las VAN
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 Oxaion, 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.
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.
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.
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.
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.
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.
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.
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.:
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">
<documento>
<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.
!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 2007, 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.
