Intercambio Electronico de Documentos

CAP. 1 PRESENTACIN .............................................................................................
4
1. Presentacin ....................................................................................................... 4
1.1 Antecedentes histricos ................................................................................... 5
1.2 Beneficios de la implementacin de EDI ........................................................ 7
1.3 Motivos por los que se adopta EDI ............................................................... 10
1.4 Cules son los primeros sectores en los que se ha implantado EDI? .......... 11
CAP. 2 ELEMENTOS ................................................................................................. 12
2. Elementos ........................................................................................................ 12
2.1 Centro de compensacin ................................................................................ 12
2.2 Comunicaciones. ........................................................................................... 22
2.3 Alternativas existentes del centro de compensacin ..................................... 25
2.4 Software de usuario. ...................................................................................... 29
2.5 Soporte. .......................................................................................................... 36
CAP. 3 Marco Legal ..................................................................................................... 38
3.1 Validez y eficacia jurdica de los documentos ............................................. 38
3.2 Responsabilidad de las partes en una transaccin va EDI ........................... 43
3.3 El acuerdo de intercambio ............................................................................ 48
3.4 Seguridad y validez legal .............................................................................. 55
3.5 Seguridad especfica de los sistemas EDI .................................................... 56
CAP. 4 EDI Y MUNDO EMPRESARIAL .................................................................. 59
4. Aplicaciones EDI en el mundo empresarial ................................................... 59
4.1 De la oferta al contrato ................................................................................. 60
4.2 Pedidos /instrucciones de suministro............................................................ 61
4.3 De la factura de pago .................................................................................... 62
4.4 Solicitud de transporte .................................................................................. 63
4.5 Despacho de aduanas .................................................................................... 64
4.6 MERCADO DE SERVICIOS EDI EN EUROPA Y EN ESPAA ............ 65
MENSAJES EDIFACT FINANCIEROS ............................................................... 71
GLOSARIO DE MENSAJES FINANCIEROS EDIFACT ................................... 72
CAP. 5 ESTNDARES ............................................................................................... 79
5. Estndares ....................................................................................................... 79
5. EDIFACT ....................................................................................................... 79
5.2 ANSI X.12 .................................................................................................... 89
5.3 Uso de EDIFACT en Europa ........................................................................ 92
5.4 Otros Estndares ........................................................................................... 92
5.5 OFTP ............................................................................................................ 93
5.6 Ejemplo UNIFACT: Manifiesto de importacin .......................................... 97
5.6 X.400 y X.435 .............................................................................................. 97
5.6 X.500 ............................................................................................................ 98
CAP. 6 SEGURIDAD ................................................................................................ 100
6. Seguridad ....................................................................................................... 100
6.1 Amenazas ................................................................................................... 100
6.2 Soluciones................................................................................................... 101
6.3 Terminologa bsica ................................................................................... 102
6.4 Servicios de seguridad ................................................................................ 102
6.5 Mecanismos de seguridad ........................................................................... 103
6.6 Alternativas de seguridad en entornos EDI ................................................ 107
6.7 PGP ............................................................................................................. 109
6.8 Estndares de seguridad EDIFACT ............................................................ 112
6.9 Conclusiones............................................................................................... 114
Intercambio Electrnico de Documentos
Pgina 1
CAP. 7 IMPLANTACIN ......................................................................................... 115

7. Pasos para la implantacin de EDI ............................................................... 115
7.1 Introduccin ................................................................................................ 115
7.2 Decidir la estrategia EDI ............................................................................ 116
7.3 Obtener apoyo de la alta direccin ............................................................. 117
7.4 Establecer el equipo de proyecto EDI ........................................................ 117
7.5 Elegir participantes de EDI......................................................................... 120
7.6 Disear con interlocutores comerciales ...................................................... 122
7.7 Acuerdo de intercambio ............................................................................. 122
7.8 Realizar prueba piloto................................................................................. 123
7.9 Revisar resultados de prueba piloto y modificar ........................................ 124
7.10 Ampliar uso .............................................................................................. 124
7.11 Hacer pblicos los esfuerzos .................................................................... 124
7.12 Resumen ................................................................................................... 125
CAP. 8 PERSONAL Y FORMACIN...................................................................... 126
8. Necesidades de personal y formacin para EDI ........................................... 126
8.2 Grupo de direccin EDI.............................................................................. 127
8.3 Grupo de operaciones ................................................................................. 128
8.4 Grupo tcnico ............................................................................................. 129
8.5 Grupo de enlace .......................................................................................... 130
8.6 Grupo de apoyo de personal ....................................................................... 131
8.7 Formacin EDI ........................................................................................... 132
8.8 Requisitos de conocimientos de visin general EDI .................................. 134
8.9 Necesidades de conocimientos de componentes de EDI ............................ 135
8.10 Necesidades de conocimiento de temas de implantacin ......................... 137
8.11 Resumen de necesidades de conocimiento de EDI .................................. 137
CAP. 9 OBSTCULOS ............................................................................................. 139
9. Superacin de los obstculos organizacionales a EDI.................................. 139
9.1 Introduccin ................................................................................................ 139
9.2 Nunca lo hemos hecho as. EDI cambiar mi trabajo................................. 139
9.3 EDI cambiar mi trabajo............................................................................. 140
9.4 EDI destruir mi relacin con los compradores y vendedores ................... 141
9.5 EDI es problema de otros, no concierne a mi departamento. ..................... 141
9.6 EDI es demasiado complejo para entenderlo ............................................. 142
9.7 Nuestros interlocutores comerciales recibirn todos los beneficios de EDI
.............................................................................................................................. 143
9.8 EDI cuesta demasiado ................................................................................ 143
9.9 EDI permitir el acceso de otros a nuestros datos propios ......................... 144
9.10 EDI crea todo tipo de problemas legales .................................................. 145
9.11 EDI elimina el registro de auditoria ......................................................... 146
9.12 Resumen ................................................................................................... 147
CAP. 10 COSTES - BENEFICIOS ............................................................................ 148
10. Anlisis de costes/Beneficios ..................................................................... 148
10.1 Introduccin .............................................................................................. 148
10.2 Razones para documentar costes beneficios ............................................. 148
10.3 Comportamiento de costes y beneficios de EDI....................................... 149
10.4 Categoras de costes de EDI ..................................................................... 150
10.5 Categoras de beneficios de EDI .............................................................. 152
10.6 Preparacin de un anlisis de costes/beneficios ....................................... 155
CAP. 11 SISTEMAS DE MENSAJERA .................................................................. 156
Pgina 2
11.1
11.2
11.4.
11.5.
11.6.
11.7.
11.8.
11.9.
Introduccin .............................................................................................. 156

Conceptos MHS (X.400) .......................................................................... 157
Nombres y direcciones ............................................................................ 170
Dominios de Gestin ............................................................................... 171
ISP ........................................................................................................... 173
Protocolos ................................................................................................ 174
Elementos ................................................................................................ 181
SMTP ....................................................................................................... 191
Pgina 3
CAP. 1
PRESENTACIN
1. Presentacin
EDI (Electronical Data Interchange) es el Intercambio Electrnico de
Documentos estandarizado a travs de sistemas de telecomunicacin, entre aplicaciones
informticas bajo un cierto protocolo. De este modo la informacin se puede tratar de
forma automtica sin intervencin humana.
Otras definiciones que podemos encontrar son:
Segn la ICC Intenational Chamber of Commerce) en el texto de la UNCID
(Uniform Rules of Conduct for Interchange of trade Data by Teletransmision) define
EDI como: La transferencia directa entre ordenadores, a travs de medios electrnicos,
de datos de negocios estructurados, esto es, la transferencia de documentacin propia
de negocio sin papeles.
En publicaciones oficiales de la Unin Europea se describe EDI como: El
intercambio de datos en un formato normalizado entre los sistemas informticos de
quienes participan en transacciones comerciales, con reduccin al mnimo de la
intervencin manual.
Richard Hill de la ITU indica que: Se define EDI como el intercambio de datos
relativos a transacciones comerciales entre ordenadores alejados, mediante el
establecimiento de acuerdos sobre formato y redes.
Yash P.Grupta, de la Universidad de Colorado, define EDI como El movimiento
de documentos administrativos de empresa, electrnicamente, dentro de o entre
distintas firmas, y en un formato estructurado recuperable por una mquina, que
permita la transmisin de datos sin necesidad de teclearlos, directamente desde una
aplicacin situada en un punto hasta otra situada en otro punto.
Con EDI se sustituye el papel, que constituye el soporte fsico de los
documentos mercantiles - Pedidos, rdenes de entrega, Albaranes, Factuas, etc.- por
transacciones electrnicas entre programas informticos. Primeramente los responsables
se deben poner de acuerdo en los protocolos a utilizar para cada tipo de documento a
tratar, de esta forma slo se debe transmitir el contenido y no el formato.
A partir de las definiciones podemos obtener las caractersticas ms importantes de
EDI:
EDI es un servicio telemtico de intercambio electrnico de datos entre
aplicaciones u ordenadores alejados, de forma automtica y con la mnima
intervencin humana.
Pgina 4
Los datos que se intercambian son transacciones comerciales, o de forma amplia

documentos - texto, imgenes, sonido -, relativo a cuestiones comerciales,
administrativas e industriales. De esta forma se elimina el soporte papel de los
documentos, y el trasiego de informacin se realiza bajo responsabilidad de las
aplicaciones informticas.
El intercambio de datos se hace mediante formatos normalizados, dando
soluciones a diferentes tipos de mensajes aplicables a todos los mensajes de la
industria.
Los usuarios EDI se deben organizar en torno a la definicin de un servicio
propio para todos ellos que resuelva acuerdos complementarios, cobre servicios
de red, interoperatividad con otro servicio, e integracin con aplicaciones
internas.
EDI se diferencia de la mensajera electrnica porque relaciona aplicaciones
entre dos empresas. Hace que las aplicaciones de mbito empresarial ms
habituales como la contabilidad, facturacin, control de almacn, gestin de
tesorera, etc., se integren en un todo. Esto supone un salto cualitativo de
trascendental importancia. Esta capacidad integradora de aplicaciones, hace que
EDI un fenmeno de sntesis y como los fenmenos de sntesis suponen un
motor para el sector y la empresa en que la implanta.
La simplificacin y la generalizacin de la informtica y de las comunicaciones ha
puesto EDI al alcance econmico y tecnolgico de todas las empresas, justo cuando la
competencia empresarial es mayor que nunca. La aparicin de estndares
internacionales propicia la difusin creciente de EDI como alternativa a los mtodos
tradicionales de realizar transacciones comerciales. Si ahora la utilizacin de EDI aporta
ventajas operativas y estratgicas para las empresas que lo adoptan, en un futuro
prximo su utilizacin ser una condicin necesaria para operar en un mercado cada vez
ms global.
Estas caractersticas se encuadran dentro de la teora de los 5 ceros: 0 stocks, 0
tiempo al mercado, 0 papel, 0 prdidas de tiempo y 0 defectos. Esta teora est
relacionada con los sistemas Just in Time.
1.1 Antecedentes histricos

En una primera instancia se pueden hablar de The American Hospital Supply
Corporation (AHSC) quien en los aos 60 integr un sistema EDI en sus
procedimientos administrativos, mediante un sistema automtico de adquisicin de
datos para unirles a los hospitales clientes. Este sistema permiti que los hospitales
satelites pudieran hacer los pedidos de forma automtica, reduciendo de esta forma los
niveles de stocks, los tiempos de espera y el uso del papel.
En 1968 se constituye la Transportation Data Coordinating Commitee (TDCC)
para contribuir a la estandarizacin de las tarifas de envos intercontinentales,
establecindose los procedimientos electrnicos para las transacciones.
Pgina 5
1982. Se crea el Guidelines for Trade Data Interchange (UNECE/GTDI)

desarrollado por las Naciones Unidas en la comisin Econmica para Europa.
1983. Se crea estndar X.12 por el Comit Coordinador del Transporte de Datos
(TDCC/EDIA) y el instituto Nacional Americano para la estandarizacin, el llamado
ANSI ASC X.12.
1985. Se crea el grupo UN/JEDI, entre la ONU y la CEE, con la intencin de
desarrollar un estndar EDI internacional.
1986. Se aprueba la normativa EDIFACT (Intercambio Electrnico de Datos
para la Administracin, Comercio y Transporte) por la Comisin Econmica para
Europa de las Naciones Unidas (UNCE), por trabajos del subgrupo WP.4.
1987. Se adopta la norma EDIFACT bajo el ttulo norma ISO 9735 por la UNCE
e ISO (International Standard Organization)
1988. La Comunidad Econmica Europea lanza el programa TEDIS para la
difusin y utilizacin de EDI en Europa. TEDIS se hace cargo de la secretara de
EDIFACT para Europa con el soporte de la EFTA (Asociacin Europea de Libre
Comercio), crendose las oficinas de difusin y apoyo de EDIFACT. Se crea el
EDIFACT Board en USA. La Cmara Internacional de Comercio promueve la
publicacin de un texto con orientacin semilegal sobre cuestiones de utilizacin de
EDIFACT, es el texto UNCID.
1989. La normativa EDIFACT queda muy avanzada, cubriendo la mayora de
los mensajes entre partes contratantes. Se incluyen pases del Pacfico.
1990. Aparece la norma espaola UNE 1145/90, de definicin de las reglas de
sintaxis, segn la Norma Europea EN 29735 adoptada por el Comit Europeo de
normalizacin (CEN) en 1989.
1991. Se inicia la segunda fase del proyecto TEDIS, para apoyo de los proyectos
EDI existentes, normalizacin por la junta EDIFACT de Europa, estudio de problemas
legislativo y telecomunicaciones, y el estudio de ayudas a las pymes.
1992. Se celebra la X Asamblea Plenaria del CITT (ITU),en las que se estudia
las normativas X.435 y F.435 y se perfila el correo electrnico como va de
comunicacin de EDI, basndose en el protocolo X.400.
1993. EDIFACT se consolida como norma internacional y fuerza a los dems
estndares a migrar hacia l. SEDAS, ODETTE, ANA TRADACOM emprenden
medidas para adaptarse a EDIFACT.
En la actualidad dentro de la junta EDIFACT existen 11 grupos de trabajo para
desarrollar diversos tipos de mensajes: MD1 (industria y comercio), MD4 (finanzas),
MD5 (construccin), MD6 (estadsticas), MD7 (seguros9, Md8 (turismo, viajes y ocio),
MD9 (sanidad), MD10 (trabajo y seguridad social) y MD11 (Administracin pblica).
Pgina 6
Actualmente EDI est polarizado entre la normativa X.12 y EDIFACT, aunque

hay un compromiso de inmigracin de X.12 a EDIFACT.
1.2 Beneficios de la implementacin de EDI

Est, claro que la implementacin de EDI reporta grandes beneficios a la
empresa. Estos beneficios los podemos estructurar en beneficios de carcter optativo y
de carcter estratgico.
Beneficios Operativos:
Reduccin de coste
Reduccin de papel y gastos de envo
Manipulacin: grabacin, verificacin, edicin
Mejora de la eficacia y de la productividad del personal
Reduccin de errores
Reduccin de los ciclos comerciales logsticos y administrativos
Reduccin de stocks: tcnicas just in time
Mejora de la disponibilidad de informacin
Mejor control de inventario
Implantacin de medidas de seguridad
Beneficios estratgicos:
Mejor imagen con respecto al entorno
Estrechas relaciones con los interlocutores comerciales
Mejor servicio al cliente
Permite utilizar la rapidez de respuesta como arma de negociacin
Permite ampliar el nmero de proveedores/clientes sin incrementar recursos
administrativos
Otras ventajas estn asociadas al tiempo. Entre ellas se puede hablar de las derivadas
de la disminucin de errores y la no necesidad de volver a teclear los datos y mayor
velocidad de intercambio de informacin entre las empresas, forma que permite utilizar
los mtodos JIT (Just In Time) y QRS (Quick Response). Tambin es muy importante la
reduccin del tiempo desde la consolidacin de un pedido hasta la recepcin del aviso
de expedicin de la mercanca, la que va desde que se entrega la mercanca hasta la
emisin de la factura, y la disponibilidad instantnea de informacin sobre pedidos y
entregas.
Ventajas asociadas al factor capital:
Disminucin del papel
Mejora del cash-flow
Disminucin de gastos de personal o rentabilizacin mayor de la plantilla
existente
Reduccin de las existencias y del espacio de almacenamiento
Pgina 7
Ventajas asociadas al factor estrategia:

En algunos casos se convierte en algo necesario para hacer negocios con una cierta
entidad, normalmente la administracin. Por otra parte estn todos aquellos que tienen
que ver con factores de tiempo y de capital: como mejor servicio al cliente, mejores
relaciones con los interlocutores comerciales, mejor capacidad competitiva y mejor
posicionamiento en el mercado. Capacidad de ofrecer ms y mejores servicios.
Se estima que el 70% de la informacin que generan los ordenadores en forma de
papel se vuelve a teclear y se introduce en otro ordenador. La eliminacin de estas
repeticiones no solo ahorra tiempo, sino tambin errores de mecanografa y por lo tanto
gastos.
La introduccin de informacin de forma manual en un ordenador, es siempre
origen potencial de errores. Aproximadamente el 50% de los documentos complejos de
una empresa presentan al menos un error. Esa cifra se eleva hasta un 80% de promedio
en documentos aduaneros. Las empresas que han adoptado EDI han eliminado dichas
tasas de errores.
El ciclo actual de los documentos comerciales intercambiados por medios
tradicionales es en general largo, lento e inseguro. Una gran cantidad de pasos
(extraccin de datos, mecanografiado, entrega, envos por correo, clasificaciones,
repartos, entregas, mecanografiado de nuevo, etc.) son necesarios para cubrir el ciclo
que va desde el ordenador del proveedor hasta el del cliente. Dichos pasos, ademn de
ser lentos y dilatar el tiempo transcurrido entre la emisin y la recepcin, generan
frecuentes problemas de extravos, repeticiones, prdidas, retrasos y errores en la
transcripcin.
En la figura adjunta se considera el intercambio del conjunto de documentos
mercantiles habitualmente presentes en cualquier operacin comercial entre un
fabricante y un suministrador.
Pgina 8
Cualquiera de esos documentos se someten a un proceso similar al siguiente: El

sistema informtico de gestin de almacn del fabricante detecta la necesidad de
renovar un determinado producto y produce la documentacin oportuna en listados o
impreso. Dicha documentacin se enva al Departamento de Compras que, a su vez,
enva las peticiones de oferta a los posibles suministradores.
Para ello, tradicionalmente, se escribe una carta o rellena un impreso de peticin
de oferta que se entrega al sistema de correo para su distribucin. Varios das ms tarde,
el sistema de correo entrega al suministrador el documento. ste a su vez, lo introduce
en un sistema informtico para su proceso posterior. Al poco tiempo, el suministrador
enva su oferta al fabricante siguiendo el mismo proceso.
El proceso se repite en uno y otro sentido para todos los documentos que se
intercambian lo interlocutores comerciales.
La gran ventaja de EDI es que los documentos se intercambian en los propios
ordenadores que los producen con el consiguiente ahorro de tiempo y errores.
Adems, la agilizacin de los procesos de pedidos, facturas, etc. no sirve
solamente para facilitar y disminuir los trmites y costes asociados a la elaboracin y
envo de dichos documentos, sino sobre todo para disminuir stocks mediante la
planificacin de entregas y la realizacin de pedidos con ciclos ms cortos: entregas y
pedidos semanales e incluso diarios, en vez de mensuales (tcnicas Just In Time).
Pgina 9
De hecho, a medio plazo EDI pasar a tener ms inters para la empresa desde el
punto de vista estratgico y des gestin que desde el puramente operativo, y ser un
elemento imprescindible para su competitividad.
En cualquier empresa, los ahorros de tiempo y recursos generados al automatizar
procesos son notables e inmediatos. Donde primero se notan los efectos de la
introduccin de EDI es en el mbito de la Administracin
Ninguna compaa desea dedicar personal valioso y de alto coste al manejo
rutinario de papeles, pudiendo tener a ese personal ocupado en una actividad ms
productiva, tal como una mejora en la atencin al cliente.
Otra de las ventajas de la introduccin de EDI es que al acortar el proceso de
elaboracin y envo de documentos, stos se pueden enviar con ms frecuencia. La
consecuencia inmediata es que el nivel de almacenamiento de un producto determinado
puede reducirse de forma substancial lo que se traduce en una mejora paralela del cashflow.
En definitiva, la utilizacin de EDI se traduce en una mejora de competitividad
de la empresa que lo adopta.
1.3 Motivos por los que se adopta EDI

Los motivos por los que las empresas llegan a adoptar EDI se pueden englobar en
razones internas y externas.
1.3.1
Razones internas
Las razones internas (Estratgicas, Operacionales y de Oportunidad) que llevan a la

adopcin del sistema EDI son las ya mencionadas anteriormente y en resumen seran las
siguientes.
El deseo de reducir el volumen de papel en diferentes departamentos.
La necesidad de incrementar el rendimiento del personal.
La necesidad de reducir las tasas de error.
La intencin de reducir el tiempo del ciclo comercial.
El deseo de simplificar la relacin con sus interlocutores comerciales.
La necesidad de capitalizacin, por oportunidad de ahorro de costes de
administracin y mejora del cash-flow que supone.
Precisar un servicio que permita la posterior implantacin de tcnicas just in
time o transferencia electrnica de fondos.
El deseo de trabajar ms estrechamente con proveedores o clientes
preestablecidos.
Razones externas
Cuando una empresa tiene un cliente importante y ste le exige utilizar EDI para
sus transacciones, la mayora de las veces no tiene ms solucin que adaptarse a los
requerimientos del cliente, so pena de perder dicho mercado. sta es, en la mayora de
las veces, la causa por la que las PYMES han de dar el salto a EDI.
Pgina 10
En otras ocasiones, debido al gran volumen de informacin que intercambian

dos empresas, se ve la necesidad de utilizar un mecanismo electrnico para sus
transacciones. Si una de estas empresas es muy grande, caso de la administracin lo ms
general es que arrastre a otras a seguir el mismo camino.
Por otra parte y de forma genrica, algunas razones externas que pueden llevar a la
adopcin del sistema EDI en una empresa son:
La presin del mercado para adoptar nuevas estrategias.
La necesidad de buscar nuevas ventajas competitivas.
La presin de proveedores o compradores con posicin dominante sobre el
mercado en el que actan.
No obstante suele ocurrir que las empresas que abrazan EDI tardan en ver los
beneficios mencionados en los puntos precedentes, ya que pueden ser empresas que se
han visto obligadas a introducir EDI por uno de sus grandes interlocutores. En esta
situacin, EDI puede verse como una cuestin de peso para seguir manteniendo la
relacin comercial, aunque rpidamente la empresa debe ver en esas circunstancias el
aspecto competitivo que la entrada de un servicio EDI le proporciona, ofrecindole
mecanismos favorables para el contacto con otros proveedores y clientes.
Es ms, con cada vez ms frecuencia se observa que en un futuro muy cercano, las
empresas vern en EDI un camino a la diversificacin y de encontrar nuevas
posibilidades de negocio. La tendencia de las prospecciones de mercado indica
claramente lo que hasta aqu se ha expuesto.
1.4 Cules son los primeros sectores en los que se ha implantado EDI?
Siguiendo las lneas de desarrollo habidas en otros pases, fundamentalmente en el
Reino Unido, los sectores que primero han adoptado EDI en nuestro pas o que estn en
una fase de implantacin avanzada son los siguientes:
Automocin.
Alimentacin y distribucin.
Electrnica, Informtica y Telecomunicaciones.
Sector qumico, farmacia y laboratorios.
Administracin pblica.
Sanidad.
Transporte y turismo.
Banca.
Sector Seguros.
Pgina 11
CAP. 2
ELEMENTOS
2. Elementos
Un sistema EDI est compuesto de diferentes elementos, hardware y software,
que perfectamente entrelazados, consiguen proporcionar el servicio que se le
encomienda.
Estos elementos bsicos son: El Centro de Compensacin, el Sistema de
Comunicaciones, Hardware y Software del usuario, y servicios de soporte.
2.1 Centro de compensacin

Los Centros de Compensacin (CC), conocidos tambin como Clearinghouse o
Redes de Valor Aadido (VAN) son centros informticos que funcionan como un
apartado de correos. Cada usuario dispone de un espacio en un sistema informtico,
referenciado con un nombre, nombre con que se guardan los mensajes emitidos y
recibidos hacia y desde otras empresas. El CC es el que se encarga de reenviar los
mensajes a los interlocutores apropiados. Este centro dispone de unos sistemas de
seguridad adecuados que hace fiables todas las transacciones.
2.1.1
Requisitos bsicos de un centro de compensacin
Un Centro de Compensacin (CC) debe proporcionar a sus clientes unas

garantas mnimas sobre disponibilidad y fiabilidad de servicios. Estos sern los puntos
esenciales a la hora de elegir entre los diversos CC.
Para poder proporcionar un cierto nivel de calidad de servicio un CC debe cumplir
los siguientes requisitos:
Mantener una alta de disponibilidad en el centro. Ello implica alcanzar el
mximo terico del 100% de disponibilidad, independientemente de los
desastres que puedan ocurrir. Instalacin de sistemas de Non Stop y Sistemas
Pgina 12
Tolerantes a Fallos. Es el principal factor para medir la calidad de servicio que

se proporciona. Esta disponibilidad no est dada solamente por los componentes
intrnsecos, sino que depende muy directamente de los elementos crticos fsicos
y lgicos de los que se compone.
Capacidad de soportar los servicios ofertados. Deben estar disponibles todos
los servicios que se ofrezcan siempre que el CC est disponible.
Incrementar la funcionalidad del Centro segn las necesidades del
mercado. Capacidad de migracin a nuevas tecnologas de comunicacin,
interfaces de usuario, adaptacin a nuevos protocolos EDI, etc.
Capacidad de ayudar al usuario. Poder ayudar a los clientes ante dificultades
para completar sus transacciones EDI ante situaciones de desastre, fallo de
sistemas, etc.
2.1.1.1
Elementos crticos lgicos.
Los elementos lgicos ms importantes de los que depende la calidad de servicio de un

CC son:
Servicio Posventa y stock mnimo. El CC debe garantizar el servicio posventa
disponiendo de un mnimo de componentes hardware y elementos software en
stock, normalmente los ms crticos, para proporcionar una respuesta inmediata
para que el cliente no se quede sin servicio.
Seguridad lgica de acceso. Las instalaciones del CC no deber ser accesibles a
personas ajenas al personal autorizado ni se debe poder acceder desde consolas
locales o remotas a la aplicacin del CC. Si no se cumplen estas sencillas
normas, cualquiera que consiga acceso a las instalaciones o a la aplicacin del
CC puede daar la integridad del sistema, con la merma de la Calidad de
Servicio.
Aparte de estas consideraciones la aplicacin del CC debe contar con medidas de
proteccin lgicas, con contraseas de seguridad, sistemas de cortafuegos y tiempo de
acceso limitado.
Sistema operativo y software fiables. El sistema operativo sobre el que se
ejecute la aplicacin del CC deber ser lo ms robusto y fiable posible, para
evitar la cada del sistema ante errores potenciales del propio sistema operativo.
En ese sentido los sistemas propietarios de las grandes firmas proporcionan
mayor nivel de seguridad, pero al mismo tiempo lleva asociado un costo
normalmente demasiado elevado que no justifica en muchas ocasiones la
seguridad proporcionada.
2.1.1.2
Elementos crticos
Los elementos lgicos sensibles del Centro de Compensacin deben estar

perfectamente identificados y contemplados en un plan de contingencias. La seguridad
de los elementos lgicos puede agruparse segn su tipo en:
Software
Pgina 13
Sistema de operacin: el sistema de operacin debe ser fiable en la medida de

lo posible, previniendo en lo posible los errores generados en operacin.
Aplicacin: todas las entradas de datos de la aplicacin de Centro de
Compensacin deben hacer una validacin de los datos introducidos.
Sistema Operativo: El sistema operativo debe ser tolerante a fallos y ser capaz
de recuperarse por s mismo de aquellos eventos software/hardware que puedan
llegar a perjudicar su funcionalidad.
Sistema de Backup robusto: el sistema de backup del sistema debe ser un
sistema especialmente robusto, fiable, completo y automtico, para garantizar la
calidad de las copias realizadas. El sistema de bakcup debe permitir la
realizacin de la copia de seguridad con los procesos en marcha, ya que el
Sistema no se puede parar para realizar esta tarea. Al mismo tiempo debe
garantizar una copia coherente del sitema, haciendo que se copien incluso
aquellos ficheros y programas bloqueados por el sistema para su uso o
bloqueados por uso temporal.
Elementos crticos fsicos.
Sistema de alimentacin ininterrumpido (SAI) y/o generador autnomo: la
finalidad es garantizar la continuidad de funcionamiento an con falta de energa
elctrica. Se debe disponer de un sistema que haga que entre en funcionamiento
el generador autnomo despus de un determinado espacio de tiempo de falta de
energa elctrica. Adems debe disponer de un sistema de control de forma que
la misma SAI mande una orden a todos los servidores del sistema para que se
auto apaguen cuando el nivel de carga de las bateras llegue a un mnimo
preestablecido.
Lneas de comunicaciones redundantes: es sumamente importante disponer de

rutas alternativas ante fallos de las lneas principales de comunicacin. Se
debern disponer de lneas X.25 y RDSI, Frame Relay, unas como backups de
las otras para poporcionar comunicacin segura 24/24.
Necesidades de elementos fsicos.
Los elementos fsicos sensibles delCC deben estar perfectamente identificados y
contemplados en un plan de recuperacin de emergencia. La seguridad de los elementos
fsicos puede agruparse segn su tipologa en:
Tolerancia a fallos.
El CC debe estar soportado por un Sistema Tolerante a fallos Hardware y Software.
Un sistema tolerante a fallos es aque que cumple al menos las caractersticas siguientes:
o
o
El sistema de almacenamiento de datos del sistema debe estar

fsicamente duplicado.
La memoria del sistema debe estar duplicada, para garantizar que no se
corrompan en memoria.
Pgina 14
El grupo de procesadores del sistema debe procesar la informacin por

duplicado o debe contar con un sistema fiable de lgica de polling entre
los resultados de los distintos procesadores.
o La energa elctrica del sistema debe estar garantizada por un periodo
dilatado de tiempo.
o El sistema debe contener un subsistema de autodiagnstico robusto, que
permita identificar en tiempo real los fallos crticos del sistema e
informar a las personas responsables en un tiempo mnimo.
Sistema de recuperacin en catstrofes.
La explotacin del CC debe incluir procedimientos de recuperacin en catstrofes.
Estos procedimientos de recuperacin incluyen las especificaciones por las que se pueda
restituir todo el servicio en caso de una catstrofe en el sistema.
Un sistema de recuperacin en catstrofes debe estar formado como mnimo por:
o
o
o
o
o
Un responsable, que coordinar toda la accin

Un procedimiento a seguir para cada proceso en la recuperacin
Otro sistema donde restituir el servicio.
Copias de seguridad del Sistema Operativo.
Copias de seguridad del da o del da anterior de la aplicacin del CC y
de los documentos intercambiados.
o Acceso, a ser posible, a las mismas lneas de comunicaciones del sistema
fuera de servicio.
Almacn de componentes hardware de reposicin.
La existencia de un almacn de repuestos hardware crticos es imprescindible para
poder sustituir en un tiempo mnimo aquellos componentes hardware que presenten
anomalas en su funcionamiento. El sistema deber ser lo suficiente robusto y modular
para permitir el cambio de componentes sin producir interferencia alguna en el Servicio.
Los elementos deben tener capacidad de insercin en caliente (Sistemas Non Stop y Hot
Swapping). Por otra parte, el sistema de autodiagnstico deber informar en tiempo real
de todos los componentes que generan errores o presenten una actividad anmala en su
funcionamiento.
Sistema de operacin fiable.
Una de las mayores fuentes de errores y estados anmalos en un sistema es la
intervencin manual. UN sistema es ms fiable cuantos mayores sistemas de control y
validacin existan en la interface de usuario. El sistema debe contemplar y prever todos
los errores que puedan generar los operadores, pudindose contemplar:
o
Errores fsicos de operacin: por ejemplo en el cambio de cintas de

copia de seguridad. El sistema debe controlar todas las posibles
incidencias al cambiar las cintas del sistema. Es muy comn, por ejemplo
introducir una cinta protegida contra escritura, lo que impedir que se
realice la copia.
Errores lgicos de operacin:
Errores de operacin al acceder al sistema operativo: siempre
que sea posible se debe limitar al operador el acceso a los
Pgina 15
2.1.1.3
comandos sensibles del sistema operativo, ya que por

desconocimiento o error, puede causar daos lgicos importantes
en el sistema.
Errores de operacin al acceder a la aplicacin del Centro de
Compensacin: la aplicacin debe contemplar todos aquellos
errores que se puedan cometer al introducir informacin en el
sistema y evitarlos.
Necesidades de Entorno.
Conjuntamente a las necesidades intrnsecas del sistema existen unas necesidades

bsicas del entorno que necesitan estar cubiertas para garantizar la integridad y la
capacidad de comunicacin con el exterior.
Generador de electricidad. Es imprescindible la existencia de un generador
autnomo que provea al sistema de la energa elctrica necesaria para el
funcionamiento normal. Este factor puede ser crtico en zonas dnde se
produzcan cadas de tensin o la irregularidad en el suministro elctrico. En las
zonas dnde el suministro elctrico no sufra problemas de cortes, tambin se
recomienda el uso de un generador, ya que nunca se pueden prever las
circunstancias del entorno ajenas al CC.
Redundancia del sistema de comunicaciones. Es imprescindible la existencia
de un encaminamiento alternativo para las comunicaciones. En teora, un nodo
X.25 nunca debe dejar de estar operativo, pero hay otras circunstancias que
pueden hacer que no se establezca la conexin entre el CC y el nodo ms
cercano. Por tanto, se recomienda que las conexiones con la red X.25 pblica se
hagan a travs de ms de un nodo, o incluso soportando un backup RDSI o
servicios similares.
2.1.2
Amplia opcin de servicios.
Un CC se caracteriza no solo por su capacidad de intercambiar documentos entre

sus clientes sino tambin en acercar al cliente un conjunto de servicios.
Estos servicios deben ser accesibles en todo momento a cualquier usuario que acceda al
CC, as que se deben disponer de todas las medidas necesarias para garantizar el acceso
de los usuarios a estos servicios sin ningn problema.
2.1.3
Recursos de defensa de integridad del Centro de Compensacin.
Todo CC debe contar con un conjunto de recursos que lo protejan de los

imprevistos que puedan surgir a lo largo de su vida y que garanticen el servicio que ste
presta, ya que un CC ha de ser, en la medida de lo posible, autosuficiente en cuanto a la
recuperacin en caso de desastre o incomunicacin.
La tabla adjunta indica todas aquellas amenazas, agrupadas por el entorno,
donde se producen los mecanismos que le dan solucin:
Pgina 16
Amenazas
Soluciones
Hardware:
Causas
externas
Cada de tensin o fallo
Generador y sistema de alimentacin ininterrumpida (SAI)
de alimentacin
Acceso al sistema de
Servicio de seguridad y control de acceso
personas no autorizadas
Destruccin del centro
Segundo equipo en otro edificio lo suficientemente alejado
por causas naturales o
del edificio que alberga al centro.
provocadas
Hardware:
Causas
internas
Fallo de uno de los
Stock de repuestos de componentes y sistema tolerante a
componentes
hardware
fallos, que contemple la restauracin automtica de discos.
del sistema
Las lneas X.25 y RDSI deben depender de distintos nodos
Fallo en la conexin a la
de la red, asegurando as encaminamientos alternativos.
red X.25 o RDSI, etc.
Lneas de backups. Redundancia.
Software: Software del
CC
Fallo por cada del
El sistema operativo debe ser tolerante a fallos
sistema operativo
Fallo por error del El software del CC debe ser tolerante a fallos, al menos,
software jdel Centro de disponer de las herramientas necesarias para volver a poner
Compensacin
en marcha el sistema sin que se produzcan inconsistencias
Operacin
Fallos por error de
El software del CC debe contemplar controles en la captura
introduccin manual de
de la informacin
datos
El software de operacin del CC debe ser lo suficientemente
Fallos por errores de
robusto para evitar estos erroes. Se debe impedir el acceso de
operacin en la aplicacin
operadores no autorizados a las partes sensibles del sistema.
Fallos por errores de
Se debe impedir el acceso de operadores no autorizados a las
operacin
sobre
el
partes sensibles del sistema.
sistema operativo
2.1.4
Descripcin de un Centro de Compensacin tipo.
El Centro Servidor o CC es el intermediario entre interlocutores. En l cada

empresa tiene asignado un buzn a travs del cual el usuario recibe y recupera la
informacin que sus interlocutores comerciales le envan. Los usuarios del Servicio se
conectan a l para emitir cualquier tipo de documento hacia cualquier interlocutor
debidamente autorizado y para recibir cualquier documento que le haya sido enviado, ya
que el Centro Servidor est habilitado para tratar tambin mensajes no EDI como
CAD/CAM, hojas de clculo, y en general cualquier fichero binario.
Pgina 17
De esta forma los usuarios del servicio solo necesitan una conexin fsica para
intercambiar documentos con toda la comunidad de usuarios, procedimiento que
realizan en el momento que elijan sin necesidad de permanecer conectados nada ms
que cuando deseen enviar o recibir mensajes.
Caractersticas tpicas de un CC podran ser:
o
o
o
2.1.5
Una plataforma hardware puede componerse de dos ordenadores

TAMDEM Inntegrity (1455 y 1300) con procesadores RISC, tolerantes a
fallos
y
redundantes.
Estos equipos TAMDEM garantizan la plena disponibilidad del servicio:
24 horas al da, 365 das al ao mediante la duplicacin y triplicacin de
sus elementos (CPU, memoria, controladora, etc.) que actan
paralelamente de forma que en caso de que uno falle el otro permanece
operativo.
Estos sistemas pueden detectar, aislar y recuperarse de los fallos de sus
componentes sin que el sistema operativo o las aplicaciones se vean
afectadas.
El centro servidor debera estar conectado a dos nodos distintos de la red
de comunicaciones con objeto de garantizar la mxima disponibilidad de
los enlaces.
El software ms indicado se compone de:
Sistema operativo non-stop UNIX SVR4 tolerante a fallos.
Software de aplicacin de Centro Servidor (ODEX/PLUS).
Los aspectos de seguridad tales como: control de acceso, suministro de
energa elctrica, etc., han de estar especialmente cuidados, con objeto de
garantizar a los usuarios del servicio la plena integridad y
confidencialidad de la informacin.
Debe tener capacidad para almacenar el logging de las transacciones
electrnicas que han tenido lugar, incluso registrar los documentos
electrnicos si se contempla en el acuerdo de intercambio, y en caso de
discrepancia o litigio entre las partes se puedan aportar pruebas para
clarificar la situacin.
Auditado por alguna empresa representativa en este campo (Auditora
externa).
Comunicacin con varias VAN'S.
Funcionalidades del centro de compensacin.

Las funcionalidades bsicas que suelen disponer de forma estndar los CC son:
o
Capacidad de buzoneo
Estndar: el centro recibe el documento, realiza las
comprobaciones y validaciones necesarias y lo deposita en el
buzn de destino.
Store and fordward: el propio centro, cuando recibe el
documento, genera una llamada saliente y lo retransmite a su
destinatario.
Call-out: es el llamado entrega rpida.
Pgina 18
o
o
o
Capacidad de intercambio internacional a travs de la red Infonet.

(Abanico para los usuarios para intercambio internacional)
Capacidad de conversin de protocolo OFTP <---> X.400
Medidas de seguridad bsicas:
Identificacin de los interlocutores: acceso restringido por
cdigo EDI y password, que permita evitar el acceso de usuarios
no reconocidos por el centro.
Validacin de intercambios de documentos: el centro servidor
guarda copias de seguridad durante unos das (10 por ejemplo) a
partir de una fecha de confirmacin de recepcin por parte del
destinatario, con el fin de solucionar posibles incidencias.
Disponibilidad 100%: el centro servidor debe permanecer
operativo 24 horas al da, 365 das al ao.
Mltiples modos de acceso que permitan la tolerancia a fallos.
Integridad de datos proporcionada por el protocolo: el
protocolo OFTP garantiza la no corrupcin de la informacin en
las comunicaciones.
Capacidad de autoridad de certificacin para soportar los servicios
de seguridad:
Autentificacin de origen de documentos: garantiza el origen
de los datos y da al receptor la prueba de que la fuente de los
datos recibidos es quien dice ser. Este servicio proporciona
tambin integridad del contenido del mensaje y puede ser
obtenido como subproducto del servicio de no repudio de origen.
No repudio de origen: protege al receptor de un mensaje de
cualquier intento por parte del origen de negar el envo de la
totalidad o parte del contenido del mismo. Para realizar este
servicio se usa la firma digital del mensaje. sta se obtiene
mediante un algoritmo asimtrico de cifrado, se cifra con la clave
privada del firmante y se verifica con su clave pblica. Esta clave
pblica puede ser firmada por una tercera parte para no evitar
fraudes. Esta tercera parte se conoce como Autoridad de
Certificacin y las firmas de las claves pblicas son los
certificados. El certificado de la clave pblica del firmante no
puede ser incluido junto con la firma.
No repudio de recepcin: protege al emisor de un mensaje de la
negacin por parte del receptor de la recepcin del mismo. Da
prueba al origen de que el mensaje ha sido recibido. Para obtener
este servicio se usa un mensaje de respuesta llamado AUTACK,
que se enva de destino a origen para confirmar la recepcin. En
esta respuesta el destino puede firmar el mensaje recibido y
enviar esta firma al origen en el mensaje AUTACK.
Confidencialidad: protege contra la lectura, copia o revelacin
no autorizada del contenido del mensaje. Este servicio suele
ofrecerse mediante mecanismos de cifrado simtrico (o de clave
secreta) por cuestiones de rendimiento. Para obtener este servicio
de seguridad se utiliza un nuevo tipo de mensaje, CIPHER, que
contiene el criptograma del mensaje.
capacidad de autoridad del registro
Pgina 19
Identificacin de los datos y verificacin de la integridad.

Seguridad fsica y lgica.
Depsito del documento en el buzn de destino.
Funcin de notario.
El centro de compensacin realiza una serie de procesos sobre cada documento
que acepta y que por orden cronolgico se describen a continuacin:
1. Identificacin de datos, es decir, detecta que los documentos que recibe son
documentos EDI, en un formato que es capaz de soportar y entender, a la vez que
verifica la integridad de los documentos. El centro aceptar en este momento el proceso
de cualquier documento con sintaxis normalizada. La integridad de los ficheros (y por
tanto la de los documentos que en ellos estn contenidos) la verifica de forma
automtica mediante la comprobacin de igualdad entre la longitud del fichero
preparado para enviar por el usuario y el recibido en el Centro.
2. Funciones de seguridad fsico-lgicas. El CC debe realizar una serie de
funciones tanto de ndole fsico como lgico. Entre ellas se puede hablar de realizar una
copia separada de la informacin en discos separados (mirroring), y verificacin, para
cada documento intercambiado, que est permitida la transaccin de origen a destino
para el tipo de documento de que se trate.
3. Depositar el documento en el buzn de destino, momento desde el cual el
documento es susceptible de ser recogido por el destinatario.
Como resultado de los procesos anteriores el CC devuelve al emisor una serie de
mensajes de control, a nivel del protocolo de comunicaciones utilizando OFTP (Odette
File Transfer Protocol), que le indican cual es el estado de los documentos emitidos.
En resumen se tiene que las funcionalidades descritas se centran en:
1. Asegura la integridad de los documentos: comprobacin fsica de los ficheros.
2. Realiza copias de seguridad de los documentos.
3. Comprueba a nivel de documento, que el intercambio definido por el perfil
Emisor-Receptor-tipo de documento, est permitido.
4. Deposita el documento en el buzn de destino.
5. Realiza estdsticas y registros de control en cada uno de los pasos anteriores.
4. Perfil de usuario Desde el punto de vista del usuario, es muy importante
sealar que el CC slo tratar documentos que los interlocutores hayan expersado su
voluntad de intercambiarlos a travs del servicio EDI. El conjunto de documentos a
intercambiar y las empresas con las que un usuario lo hace, es lo que se denomina el
"perfil de usuario".
En el momento de dar de alta a una empresa en el servicio, se abre un perfil que
define qu documentos se van a intercambiar y con qu empresas. Lgicamente, dicho
perfil ir creciendo en documentos y en empresas segn el usuario desee incorporar ms
Pgina 20
empresas con las que hacer EDI. Aunque siempre se hace referencia a documentos EDI
como CAD/CAM, hojas de clculo, etc., y en general cualquier fichero binario.
5. Funcin de notario. Esta funcin de notario electrnico que, si bien no puede
de momento equipararse a las que desarrolla a un fedatario pblico, s pueden ayudar,
sin duda, a aportar una mayor claridad a la resolucin del litigio.
Estas funciones de certificacin funcin de registro y el tipo de certificados que se
pueden emitir, son bsicamente de tres tipos:
Certificados de usuario: identifican al solicitante como usuario del sistema que
se conecta con un software debidamente homologado a partir de una fecha
determinada.
Certificados de intercambio de trfico: mediante estos certificados el CC
confirma la existencia de un determinado intercambio de un documento enviado
al Centro en una fecha y hora concreta e identifica al usuario que lo recupera,
aportando igualmente fecha y hora de la recuperacin.
Certificados de relaciones de intercambio: conteniendo las relaciones de
trfico de un usuario y de los interlocutores del mismo en un determinado
perodo.
Estos certificados no supondrn coste alguno al usuario cuando ste proporcione al
CC los datos necesarios para identificar los intercambios (fecha, nmero de intercambio
y nombre de fichero virtual). Tambin puede ofrecerse para los usuarios que lo
soliciten, la funcin de registro (backup) de los documentos intercambiados, que
permanecern en el CC por un perodo determinado (5 aos) a lo largo del cual el
usuario puede pedir su recuperacin.
Los servicios anteriormente reseados son servicios EDI estndar proporcionado por
cualquier CC. Adems pueden existir otras formas de servicio que normalmente slo se
proporciona mediante solicitud del usuario. Son los siguientes:
Opcin de envo automtico: mediante esta opcin, orientada a usuarios con
necesidad de un intercambio rpido de informacin, los documentos que se
depositan en un buzn determinado se retransmiten al destinatario, mediante
llamada saliente generada por el propio centro (Dial Out). Mediante esta
configuracin del CC proporciona mayor automatismo en los procedimientos de
las empresas al no tener que realizar la conexin al Centro Servidor.
Lgicamente el usuario debe disponer, para usar esta facilidad, de una estructura
de comunicaciones con capacidad para aceptar llamadas entrantes, por ejemplo
RTC o lnea X.25.
Opcin de recuperacin de documentos: permite, mediante solicitud del
usuario receptor, la puesta en su buzn de documentos que ya ha recuperado,
cubriendo la posibilidad de prdida de informacin en los procesos posteriores a
la recuperacin de documentos. Es importante indicar que, por razones de
seguridad y confidencialidad, los documentos slo se mantienen durante unos
das (10) en el CC una vez que ya se han recuperado, po lo que esta opcin no es
posible para documentos recuperados despus de este perodo de tiempo, a
menos que el usuario haya decidido establecer una modalidad de contratacin
del servicio configurando un perodo mayor de almacenamiento de documentos.
Pgina 21
Opcin de estadsticas especiales: proporcionan al usuario estadsticas ms

detalladas de los intercambios que realiza, volumen de informacin, tipos de
documentos, destinatario, perodos de tiempo o combinacin de las anteriores.
SPLIT: el usuario puede enviar al CC un solo fichero con mltiples
intercambios y el CC los enruta a sus destinatarios finales. El acuse de
recuperacin (EERP) para el emisor se enviar, bien al finalizar la transmisin
del fichero, o bien una vez que se hayan recuperado todos los intercambios por
los destinatarios.
Validacin sintctica: los intercambios EDI son validados a nivel de
coherencia UNB/UNZ, UNH/UNT, nmero de mensajes, de segmentos, etc. esto
garantiza que slo los mensajes sintcticamente correctos llegarn a las
aplicaciones del usuario o a sus interlocutores. El CC generar mensajes de
respuesta (GENERAL) para indicar al emisor si los mensajes enviados han sido
validados, y por tanto depositados en el buzn del destinatario, o si por el
contrario el CC los rechaza y la causa del error que lo produjo.
2.2 Comunicaciones.
La misin de las redes de comunicaciones es proporcionar un camino fsico que
permita el intercambio de informacin entre los equipos de usuario y el CC, y viceversa.
En primer lugar, se enumeran las redes utilizadas y posteriormente los
procedimientos de acceso utilizados para el intercambio de informacin.
2.2.1
Redes de acceso.
Las Redes de Acceso son el conjunto de medios fsicos por los que la
informacin viaja desde el usuario hasta el Centro Servidor y viceversa.
El acceso al Centro Servidor se puede realizar a travs de IBERPAC en las modalidades
de X.25, X.32, X.28 a travs de la Red Telefnica Bsica, y a travs de RDSI o ADSL.
Esta variedad de accesos facilita la llamada al centro desde cualquier punto geogrfico,
a la vez que permite, a travs de IBERPAC, acceder a tarifas de muy bajo coste e
independiente de la distancia.
2.2.1.1
IBERPAC
Es la red de datos de Telefnica. Su amplia difusin geogrfica permite accesos muy

baratos desde prcticamente cualquier punto, al disponer de nodos de acceso en casi
todas las provincias. Como procedimientos de acceso se pueden utilizar lneas X.25 o
lneas telefnicas convencionales. Los accesos X.28 o X.32, se diferencian en la
funcionalidad de acceso, sobre todo en cuanto a la velocidad de intercambio y coste
adicional.
2.2.1.2
Acceso X.28
Mediante este protocolo la estacin de usuario debe disponer de mdem V.22

Hayes compatible o V25bis, desde el que se llama a los EnsambladoresDesensambladores(PAD) de paquetes de la red Iberpac, a travs de la Red Telefnica
Conmutada, servicio 048, el cual selecciona automticamente el PAD disponible ms
cercano.
Pgina 22
Una vez conseguida la conexin fsica entre estacin de usuario y CC los datos se
intercambian utilizando protocolo asncrono por la Red Telefnica Conmutada en el
tramo Estacin de Usuarios- PAD y la red IBERPAC en el tramo desde el PAD-Centro
Servidor.
La velocidad de acceso mxima es de 9.600 bps, pudiendo transmitirse a velocidades
intermedias en funcin del mdem utilizado y la ocupacin de la lnea en el momento
de la conexin.
Ventajas X.28
Es el acceso ms econmico en cuanto a la inversin inicial, ya que solo necesita
un mdem, del que generalmente ya se dispone y que de no tenerlo no supone una
inversin significativa.
En cuanto a costes del acceso slo existe el de la llamada telefnica por red
Telefnica, que en la inmensa mayora de los casos es una llamada metropolitana a
travs del 048.
Inconvenientes X.28
A la vista del uso de esta modalidad de acceso al usuario se le presentan los
siguientes problemas:
La probabilidad de realizar la conexin fsica con el Centro en el primer intento
es inferior a 1. Lo cual quiere decir que con cierta frecuencia, dependiendo
fuertemente de la zona geogrfica, pueden existir problemas de acceso por
procedimiento X.28. Este problema se ha solucionado en gran medida con la
extensin por parte de Telefnica del acceso a travs del 048. No obstante el
modo de comunicaciones reintenta tres veces la conexin, lo que resulta
suficiente en el 99.9% de los casos.
La extensin en el primer tramo de comunicacin de un protocolo asncrono, por
lneas de voz provoca en algunos casos, no muy frecuentes, la aparicin de ruido que se
introduce en las tramas OFTP. No hay que ver esto como que los datos se puedan
corromper, ya que se corrige con la lgica especial que provee el OFTP, pero si puede,
en algunas ocasiones, reducir la velocidad efectiva de transmisin de datos.
2.2.1.3
Acceso X.25
Este procedimiento utiliza una lnea X.25 conectada a la Estacin de Usuario. En

este caso, se necesita instalar una placa adaptadora a la lnea en la estacin del usuario.
Con este tipo de procedimiento no se utiliza la Red Telefnica Conmutada como modo
de enlace sino que toda la transmisin se efecta a travs de IBERPAC.
Ventajas X.25
Aporta la mxima calidad tcnica en la conexin, disponibilidad del Centro (en
cuanto a conexin inmediata), y posibilidad de una mayor velocidad de intercambio.
Pgina 23
Inconvenientes X.25
Desde un punto de vista tcnico esta solucin no presenta ningn problema: la
conexin al centro servidor es inmediata y la velocidad de intercambio es la contratada
por el usuario con Telefnica hasta 64Kbps.
Desde un punto de vista econmico es tambin la solucin ms cara, debido a
que, si bien el trfico est incluido en las tarifas del Servicio EDI, existen cargos de alta
de la lnea y cuota mensuales. Tambin es necesaria la adquisicin de la placa X.25. Es
rentable para volmenes de trfico elevados; en caso contrario, no resulta rentable
dedicar una lnea X.25 exclusivamente para enviar y, recibir documentos EDI.
2.2.1.4 Acceso X.32
Este tipo de acceso trata de obtener las ventajas en cuanto a calidad tcnica de la
conexin del acceso X.25 pero manteniendo la economa de la X.28.
Bsicamente se trata de conseguir una conexin X.25 desde la Estacin de usuario al
Centro Servidor pero sin la necesidad de disponer de una lnea X.25, con el
consiguiente ahorro de costes. Del mismo modo que en X.28, en X.32 existen accesos
por red telefnica a travs del 042. La conexin entre Estacin de usuario y centro tiene
dos pasos:
Primero: La estacin de usuario llama, empleando el acceso 042, va modem V22bis
(2.400 bps) a un PAD X.32 y consigue un camino fsico hasta IBERPAC.
Segundo: Una vez conseguido el camino fsico la estacin de usuario realiza una
llamada X.25 al Centro Servidor como si se tratara de un terminal X.25 nativo y la
complicacin a partir de este momento se comporta como una lnea X.25 a 2.400 bps.
La velocidad mxima de intercambio es de 14.400 bps.
Ventajas X.32
Se consigue una conexin con las caractersticas en cuanto a calidad de la X.25.
Existen accesos X.32 en todas las provincias, por lo que la llamada de acceso ser
siempre metropolitana a travs del 042.
Inconvenientes X.32
El coste, aunque menor que en la solucin X.25, tambin es alto. Se evitan los
costes de abono a la red IBERPAC, aunque subsiste el coste de la placa y el de la
llamada metropolitana hasta el acceso X.32.
2.2.1.5
RTC
Se puede utilizar Red Telefnica Conmutada para accesos hasta el mismo Centro
de Servicios inicialmente como procedimiento de emergencia.
Pgina 24
2.2.1.6
Redes Pblicas
Aprovechando las interconexiones que existen tanto entre las redes de datos
como las de telefnica conmutada entre diferentes operadores de telecomunicacin de
las distintas administraciones, se puede acceder al Centro de Compensacin con la
misma funcionalidad desde cualquier parte del mundo que disponga de esta
interconexin.
2.2.1.7 RDSI
La Red Digital de Servicios Integrados permite a los usuarios del servicio EDI
que se conecten a travs de ella, transmitir a 64 Kbps y beneficiarse de su bajo coste y
alta seguridad ya que ofrece una combinacin idnea de ancho de banda, flexibilidad y
economa de uso. El usuario pude elegir entre un enlace bsico, que proporciona 2B+D,
esto es, dos canales de datos de 64Kb y uno de sealizacin, y un enlace primario con
32B+D. Normalmente se utiliza los enlaces bsicos.
2.2.1.8
Utilizacin de Internet
Debido a al gran auge de la red Internet de cada vez se utiliza esta red como
medio de transmisin para EDI. Aunque hay problemas de seguridad, con la
implantacin del protocolo SET, como fruto de la colaboracin entre VISA y
Mastercard, se han eliminado estos problemas para utilizar Internet como soporte de
comercio electrnico y EDI.
2.3 Alternativas existentes del centro de compensacin

2.3 Alternativas existentes del Centro de Compensacin
Existen bsicamente cuatro grandes modelos alternativos al Centro de
Compensacin, que proporcionan la misma calidad de servicio al usuario final.
2.3.1
Solucin de Centro de Compensacin Virtual
Para aquellas comunidades de interlocutores EDI, en las que no se justifique el

gasto de la infraestructura que requiere un CC, se puede optar por una solucin
denominada "Centro de Compensacin EDI Virtual". La solucin de Centro Virtual
proporciona todas las capacidades de control y gestin tpicos de una comunidad EDI,
pero con unos costes mnimos en infraestructura y explotacin. La solucin trata ole
sustituir toda la infraestructura hardware y de operacin del CC EDI por un acceso
remoto al mismo, permitiendo la misma funcionalidad pero sin inversin alguna en
material ni personal.
2.3.2
Solucin de Centro de Compensacin estndar.
Esta solucin es la ofrecida normalmente a los usuarios EDI, es la desarrollada en

las pginas anteriores. Est basado en un servicio EDI normal, con todos los atributos
reseados anteriormente. Las principales ventajas que presenta son:
Pgina 25
Resolver problemas de incompatibilidad entre diferentes sistemas de

comunicacin.
Prestacin de servicio 24h, 7 das a la semana, 365 das al ao.
Resolucin de problemas entre estndares de mensajes.
Disponer de una nica direccin de envo y recepcin de mensajes.
Capacidad de almacenamiento temporal de los mensajes y reenvo de stos.
Multidifusin de mensajes.
Baja inversin inicial.
Servicios complementarios a los usuarios.
2.3.3 Solucin de Centro de Compensacin Personalizado
Solucin adecuada a las necesidades del cliente bajo peticin. Permite el
mantenimiento de una comunidad EDI, a travs de una serie de servicios, entre los que
se incluyen:
Hot-line personalizado.
Facturacin personalizado.
Servicios y desarrollos individualizados.
2.3.4 Solucin de Centro de Composicin Propio
Solucin requerida por grandes comunidades EDI, con un gran volumen de
intercambio. Esta solucin se basa en:
o
o
o
o
o
o
o
Estudio de consultora sobre la comunidad EDI.

Definicin de documentos a intercambiar.
Equipamiento software y hardware del centro de compensacin.
Entrenamiento al equipo de operacin.
Entrenamiento al equipo de soporte tcnico.
Entrenamiento al equipo de ventas.
Entrenamiento al equipo de marketing.
Las tarifas de este servicio dependen de estudios de requisitos y necesidades de

la comunidad EDI sobre la que se va a implantar el servicio.
2.3.5
Centro de Compensacin versus conexin directa.
Una comunidad de usuarios EDI establecida podra plantearse dos

alternativas de interconexin, bien a travs de un CC o bien optar por una
conexin directa entre ellos, sin intervencin de figuras externas.
La eleccin entre las opciones no es inocua, va que de ella se derivarn una serie
de ventajas o inconvenientes que conviene tener en cuenta.
A continuacin se describe brevemente la estructura de las dos soluciones, para
pasar a relacionar los inconvenientes y ventajas de ambas.
Pgina 26
2.3.5.1
Centro de compensacin
La conexin de usuarios al CC,
descrito ampliamente en este apartado,
sigue una estructura centralizada.
2.3.5.2
Conexin Directa
La conexin directa entre usuarios

EDI implica la transmisin de ficheros
directamente entre usuarios finales. La
transmisin de los mensajes se realiza
en distintas sesiones de envo
ejecutadas nicamente durante un
horario
acordado.
2.3.5.3
Comparativa Centro de Compensacin versus Conexin Directa
En primer lugar, mientras que a travs de un CC una sola conexin

permite al usuario acceder a todos y cada uno del resto de usuarios del mismo,
as como a usuarios de otros CC interconectados con ste, la conexin directa
exige casi tantas conexiones como interlocutores, con lo que, en primer lugar,
dispara el coste de la inversin inicial, adems obliga a cada usuario a mantener
una infraestructura de comunicaciones adecuada que soporte el elevado nmero
de
conexiones.
Asimismo, la infraestructura ha de tener capacidad para hacer frente a la
concentracin de mensajes recibidos en un corto espacio de tiempo (picos de
trfico) o bien poder establecer procedimientos de polling, es decir asignar a
cada usuario una ventana de tiempo.
Pgina 27
En segundo lugar, otro aspecto diferenciador es el tiempo de conexin

requerido por una y otra alternativa.
Cuando una comunidad de usuarios EDI se
comunica a travs de un CC, cada usuario
se conecta exclusivamente para enviar o
recoger mensajes, en el momento que
considere ms oportuno; sin embargo, la
Conexin Directa obliga a sus usuarios a
tener siempre abiertas sus conexiones, tanto
para enviar mensajes como para estar accesible a sus interlocutores.
De manera que un CC (accesible 24 H/7das a la semana) permite a sus
usuarios elegir los perodos de conexin, pudiendo as optar por las franjas
horarias de menor tarifa para abaratar costes. Por otro lado, el uso del CC
implica un aumento en el plazo de tiempo asociada al ciclo de vida del mensaje,
ya que el receptor debe conectarse al CC para acceder a l.
Sin embargo existe una alternativa ofrecida por el CC que requiere disponer de
una infraestructura especfica (lnea X.25) (call out).
En tercer lugar, un CC ofrece una serie de funcionalidades y servicios que
no son accesibles pata usuarios de la Conexin Directa. Entre otros se
encuentran los siguientes:
o
Capacidad de reenvo de documentos: Si por cualquier motivo el

destinatario pierde el mensaje, puede solicitar su reenvo al CC, ya que
este guarda los mensajes durante el periodo de tiempo acordado por
ambas partes, en previsin de este tipo de situaciones.
No repudio (Acuse de recibo): El CC opera como intermediario y
puede confirmar si un usuario ha accedido a su buzn y retirado sus
mensajes. Adicionalmente generan automticamente acuses de recibo
bien de recepcin de mensaje, bien de procedimiento de aplicacin.
SPLIT o envo a listas de distribucin: Si un usuario tiene que enviar
un mismo documento a varios interlocutores, no es necesario que enve
un mensaje a cada uno, sino que el CC le permite enviar un nico
intercambio y el CC lo buzonea a cada destinatario de la lista de
distribucin del emisor. Un mismo documento con n receptores no tiene
que suponer n envos para el emisor, sino que es posible que el emisor
enve un solo mensaje al CC y este lo distribuya entre los n receptores.
Centro de atencin a usuarios: El uso de un CC supone un entorno de
intercambio seguro y atendido permanentemente de forma que cualquier
usuario conectado a l, se ver respaldado en todo tipo de incidencias por
un grupo de tcnicos profesionales altamente cualificados a travs de un
Centro de Atencin al Usuarios (CAU).
Direccionamiento y directorio: Los usuarios EDI se identifican por
medio de una cadena de caracteres que en la norma EDIFACT es de
longitud 35. Adems del nombre se encuentra la direccin lgica dentro
de la red. En la actualidad los proveedores EDI proporcionan a sus
usuarios estructuras de nombres jerrquicas facilitando enormemente las
labores de bsqueda. En las recomendaciones X.500 de la ITU se definen
los servicios de directorio electrnico para utilizar X.400 y FTAM.
Pgina 28
o
o
o
o
o
o
o
En el directorio X.500 se almacenan los objetos que representan a los

usuarios EDI, su nombre y sus atributos. Los atributos indican la
normativa y la versin que utiliza el usuario para el intercambio, as
como el identificador de sintaxis normalizado, tipo de versin y la
agencia de control.
Estndares y protocolos que soportan
Accesibilidad del servicio
Conectividad nacional e internacional
Coste y calidad del servicio
Relacin de auditorias informticas propias como evidencia en caso
de problema legal
Seguridad del enlace entre remitente y destinatario,
confidencialidad, Autentificacin y verificacin
Resolucin alternativa de disputas (arbitraje), segn un Acuerdo de
Intercambio.
En definitiva, un CC es una solucin dinmica que evoluciona tcnica y

cualitativamente, y oferta servicios en funcin de las necesidades del mercado
sin que suponga coste adicional alguno para el usuario. Mientras que toda
mejora en la conexin directa supondra incurrir en nuevos costes de
infraestructura.
En cuanto a los costes asociados a una y otra alternativa, un CC tarifica por el
trfico y el coste de los servicios de valor aadido, mientras que la Conexin
Directa tarifica nicamente el coste del trfico, si bien la inversin inicial
requerida por el primero es muy inferior a la exigida por el segundo.
La eleccin entre una comunicacin a travs de un CC o mediante Conexin
Directa se reduce a elegir acceder o no a una red de valor aadido a todos los
servicios que ello conlleva.
2.4 Software de usuario.

El software de usuario tiene corno misin actuar como puente entre el
actual sistema informtico de la empresa y los interlocutores EDI de la misma.
Est disponible en todas las plataformas actualmente operativas.
2.4.1
Caractersticas
Las caractersticas ms importantes de la estacin de usuarios EDI son las

siguientes:
Pgina 29
o
o
o
o
o
o
o
o
o
o
o
o
o
o
Integra programas de comunicaciones, extraccin, rastreo, identificacin,

traductor e interface de usuario en un solo producto.
Emplea el protocolo OFTP (Odette File Transfer Protocol), que garantiza
la no corrupcin de la informacin en las comunicaciones.
Mnimos requisitos de hardware para su funcionamiento y facilidad de
instalacin e incorporacin de nuevas versiones.
Diseada con objeto de facilitar el acceso a sus funciones mediante la
utilizacin de ventanas desplegables que ayuden y guan en todo
momento al usuario.
Confidencialidad de la informacin controlada a dos niveles:
Palabras claves de conexin.
Verificacin de autorizaciones Origen/Destino y tipo de
documento realizados en el CC.
Cumplimiento estricto de las normas actuales del estndar EDIFACT,
abierta a toda nueva incorporacin que se produzca en el mismo.
Capacidad de transmisin de informacin no estructurada (mensajes
Interpersonales, Ficheros binarios).
Control e informacin de las diferentes situaciones en que se encuentra
un documento (preparado, enviado, procesado y recibido).
Posibilidad de recibir llamadas entrantes.
Recuperacin y gestin automtica de errores/problemas de transmisin.
Generacin de estadsticas de los mensajes enviados y recibidos.
Posibilidad de generacin de distintos formatos de impresin en funcin
de origen, destino, tipo de documento y versiones.
Permite la comunicacin directa con interlocutores internacionales
empleando el estndar EDFACT.
Posibilita la integracin con las aplicaciones informticas del usuario.
Estacin de usuario para entorno Windows que facilita el acceso a sus
funciones mediante la utilizacin de una interface intuitiva para el
usuario.
Inclusin de software o hardware de cifrado DES y RSA para la
implantacin de medidas de seguridad EDIFACT.
Pgina 30
2.4.2
Funcionalidad
La estacin de usuario tiene como misin actuar como puente entre el actual
sistema informtico de la empresa y los interlocutores EDI de la misma.
Para ello, debe cubrir las siguientes funciones:

o
Rastreo
y
de
identificacin:
Identificacin de los elementos bsicos que se necesitan para componer
un mensaje EDI segn un estndar predeterminado, identificando donde
se
encuentran
los
datos
a
tratar.
Esta parte del software lo suele generar la misma empresa por el
conocimiento de ella que se precisa. La asignacin de datos se suele
realizar en el momento de la extraccin.
Extraccin: Es el proceso de recoger los datos previamente
identificados. Los datos se suelen tomar de una base de datos y se
convierten en un fichero plano. Esta estructura viene impuesta por el
software traductor. Este software no suele generarse por la empresa
usuaria de EDI, sino que nicamente ha de parametrizarla a travs de
mens sencillos de utilizar.
Traduccin: Es el software que genera propiamente el mensaje EDI a
partir del fichero plano obtenido por el software de extraccin.
Normalmente utiliza la estructura de una tabla y el diccionario de datos
del
estndar
a
utilizar
y
sus
reglas
de
sintaxis.
Despus de formar el mensaje bsico en conjuntos transaccionales se
disponen en grupos funcionales y se aade el sobre, para proceder a su
envo.
En los casos de envos al exterior, tiene como misin actuar sobre
los datos procedentes de la funcin de enlace descrita anteriormente,
convirtindose en mensajes estructurados segn la sintaxis elegida.
En los casos de recepcin del exterior, acta sobre los mensajes
estructurados procedentes del modulo de comunicaciones segn la
sintaxis elegida. Estos mensajes se convierten a un formato inteligible
para las aplicaciones informticas convencionales residentes en el equipo
del usuario.
El mdulo traductor tiene dos misiones segn acte sobre los
documentos salientes, es decir con destino a usuario o entrantes, es decir,
Pgina 31
que llegan desde el CC con destino al usuario que se ha conectado al

mismo.
Sobre los mensajes salientes, el traductor los convierte a mensajes
de contenido equivalente pero con sintaxis EDIFACT.
Comunicaciones: Efecta el enlace de la Estacin de usuario con

el mundo exterior, a travs de las redes pblicas de
telecomunicaciones.
Tiene como misin fundamental el Intercambio de informacin,
en forma de ficheros EDI entre la propia estacin de usuario de la
que este mdulo forma parte. Los mdulos de comunicaciones
deben tener en comn con el CC con el que intercambia
documentos al menos un protocolo de comunicacin. El
protocolo de comunicacin implementado en la estacin de
usuario EDI definir las capacidades de interconexin con
distintos CC y definir las capacidades de seguimiento de los
documentos enviados. Es absolutamente automtico, de forma
que el usuario no percibir que est realizando operacin alguna
sobre sus documentos. Sobre los documentos entrantes, realiza la
operacin inversa, recibiendo documentos con sintaxis EDIFACT
y los convierte a un formato susceptible de ser tratado por la
estacin. Este proceso tambin es automtico. El sentido de la
existencia de traductores en ambos extremos de un intercambio
EDI realizando operaciones inversas lo da la importancia que
tiene el realizar todos estos intercambios de una forma estndar y
aceptada Internacionalmente. Como valor aadido los traductores
se convierten en potentes filtros que eliminan la totalidad de los
errores debidos a falta de campos obligatorios dentro de los
documentos o a inconsistencias entre ellos.
Edicin de listados: Esta es una capacidad que, aunque apenas usada,
debe estar implementada en toda Estacin de Usuario EDI. Su cometido
bsico es la generacin de documentos en papel a partir de documentos
transmitidos en formato electrnico de datos recibidos del exterior que
no deban o no puedan ser traducidos de otra forma al Sistema
Informtico.
Esta funcin est cayendo cada vez ms en desuso, al tender a
integrar cada vez ms el EDI con las aplicaciones internas. Aun as, hay
momentos del ciclo de la informacin para algunos documentos que an
debe estar en formato papel para cumplir ciertos fines.
Entrada manual de datos (EMD): Permite la cumplimentacin manual

de cualquier documento EDIFACT de forma totalmente particularizando
a cada interlocutor segn el perfil: destino/tipo de documento/versin.
Una de las capacidades fundamentales de una Estacin de Usuario
EDI es posibilitar en cualquier momento la introduccin manual de algn
tipo de documento. Aunque se tiende a automatizar el ciclo completo de
los documentos, la existencia de esta opcin es fundamental para
Pgina 32
sustituir la captura de datos en las primeras fases de integracin del EDI

en la empresa.
La entrada manual de datos debe ser lo suficientemente flexible y
potente para facilitar la captura y gestin por consola de cualquier tipo de
documento EDI. Debe tambin cumplir con los criterios de seguridad en
mensajes salientes expuestos anteriormente.
Caractersticas principales de la EMD:
La EMD est diseada para empresas pequeas o que, al menos en una
primera fase, no deseen integrar EDI con sus aplicaciones. Con objeto de
minimizar errores, muy frecuentes en este tipo de procesos, se han previsto las
siguientes facilidades:
o
Relacin personalizada. La EMD permite definir, sobre cada

documento estndar un solo subconjunto de elementos de datos y
segmentos por cada interlocutor. De este modo solo se presentarn al
usuario para cumplimentar aquellos campos empleados por cada uno de
sus interlocutores.
Mxima flexibilidad. La EMD no slo facilita la cumplimentacin de
mensajes segn el perfil de cada fabricante sino que permite adems la
convivencia de varias versiones en la misma estacin.
Mnimo de errores. Basta con seleccionar un determinado fabricante
para que la EMD cumplimente automticamente todos los campos tales
como: Cdigo EDI origen, destino, tipo de mensaje, versin, etc.
Adems la EMD permite tener almacenados documentos pregrabados, es
decir, a falta de slo unos pocos campos que pueden ser cumplimentados
rpidamente en el ltimo momento antes de su envo. As se logra
minimizar el total de datos a introducir y por tanto el nmero de errores.
La EMD garantiza que los mensajes enviados desde la estacin de
usuario contienen no solo los elementos de datos establecidos como
mandatarios por el estndar EDIFACT, sino tambin aquellos que,
siendo condicionales en ste, se hayan definidos como obligatorios por
los interlocutores.
Sistema de Backup. La EMD permite almacenar en soporte magntico
los mensajes generados durante un cierto periodo de tiempo
Anlogamente ser posible cargar en la EMD los mensajes previamente
guardados.
Ergonoma. Con objeto de facilitar la cumplimentacin de cualquier
documento EDIFACT se debe prever un sistema de pantallas que, en
todo momento, indique el segmento en que se encuentra el usuario, el
nmero de repeticin, el Carcter del elemento de datos (AN, N y A) y
su longitud. Adems un sistema de ayudas que permita navegar
fcilmente por el diagrama en rbol del mensaje.
Funciones de Interface con el Sistema Informtico (ISI): La Estacin
de usuario permite la cumplimentacin de documentos en pantalla, pero
trabajando de esta forma es evidente que no se obtendrn excesivas
mejoras con respecto a los mtodos tradicionales, y es por esto por lo que
la estacin de usuarios EDI debe proporcionar una segunda forma
Pgina 33
automtica de extraccin/introduccin de documentos que es lo que se

describe a continuacin.
Caractersticas principales del ISI:
La entrada/salida automtica est diseada para organizaciones
que posean una estructura informtica donde residan las aplicaciones que
son las que realmente tratan los datos, que al final componen los
documentos comerciales a intercambiar.
Las principales caractersticas del ISI deben ser:
Permitir el tratamiento (envo y recepcin) de cualquier

documento EDIFACT.
En transmisin se podrn entregar al ISI para su tratamiento
mltiples ficheros de carga, cada uno de ellos con mltiples
intercambios.
En recepcin se podrn solicitar al ISI los documentos recibidos
segn origen y tipo de documentos.
Los ficheros entregados al ISI para su envo, se verifican respecto
a su integridad (relacin cabecera-cola), estructura (no falta
ningn elemento de datos mandatorio) y adems, se comprueba
que la relacin Origen/Destino/Versin ha sido autorizada en la
estacin de usuario EDI.
Los rechazos se realizaran a nivel de intercambio, no de fichero.
El ISI debe incorporar un registro de eventos en el que indican
los mensajes tratados y los rechazados, as como la causa del
error.
El ISI debe emplear el conjunto de caracteres definido en la
norma EDIFACT (ISO 9735) como Nivel A.
A travs del ISI debe ser posible el envo y recepcin no slo de
mensajes EDI sino de cualquier fichero binario.
Una vez que se preparan las aplicaciones de usuario para esta funcin
de generacin de ficheros, para el ISI y de aceptacin de los mismos,
(documentos salientes y documentos entrantes respectivamente), la
funcin del operador de la estacin se reduce a comprobacin y
supervisin de la introduccin del fichero con los documentos EDIFACT
en la estacin de usuario ISI, bien va transmisin local o bien va
soporte magntico compatible. Despus de realizar estas operaciones, los
documentos a transmitir quedan exactamente en la misma situacin que
si se hubieran introducido de forma manual, y se envan a la prxima
conexin.
Anlogamente, para los documentos provenientes de otros
interlocutores, el operador podr seleccionar segn origen y tipo de
documento los mensajes que posteriormente se cargarn en las
correspondientes aplicaciones.
Pgina 34
Funcin de impresin: Genera los formatos de impresin segn la

relacin: Interlocutor/Tipo de documento/Versin. Permite la generacin
de documentos en formatos individualizados para su posterior envo por
medios tradicionales a aquellos interlocutores comerciales que no
disponen de herramientas EDI para la gestin de documentos.
Funcin de seguridad: Controla la creacin de firmas electrnicas
segn la relacin interlocutor/tipo de documento/versin, permitiendo
tambin la comprobacin de las firmas recibidas. Realiza funciones de
cifrado de documentos y verificaciones, estando stas ocultas al usuario.
Funciones auxiliares: Soporta toda la administracin interna del
sistema, gestin de estadsticas de uso y capacidades de auditoria de la
estacin de usuario EDI. Entre otras opciones, se debern soportar las
siguientes:
Administracin del directorio de interlocutores. Altas, bajas y
modificaciones.
Borrado de la base de datos de documentos para un determinado
periodo de tiempo.
Cambio de cdigo local de CC para permitir la comunicacin con
otros interlocutores internacionales empleando el estndar
EDIFACT.
Configuracin de impresora segn se detalla en el apartado
dedicado al mdulo de impresin.
Control de acceso de usuarios.
Backup y recuperacin de documentos ya procesados.
Las funciones de informes permitirn las siguientes opciones:

o
2.4.3
Conocer el estado de los documentos enviados o recibidos segn tipo de

mensaje y durante un determinado periodo de tiempo. Este informe
podr ser visualizado.
Conocer el resultado de las ltimas conexiones con objeto de estudiar
posibles incidencias en las comunicaciones.
Software para PC
El usuario de acuerdo con su infraestructura ha de elegir la solucin EDI

que mejor se ajuste a sus necesidades, siempre existe una solucin idnea para
cada tipo de empresa. Este tipo de eleccin supone numerosas ventajas, tales
como: rapidez de implantacin, bajo coste, flexibilidad, altas prestaciones y
escasos requerimientos (solo es necesario un PC, un modem y una lnea
telefnica).
Este software acta como puente entre el sistema informtico
interno de la empresa y el mundo EDI, y lo denominamos estacin de
usuario.
La estacin de usuario EDI es la herramienta software que permite al
usuario la introduccin (manual o automtica), extraccin (por impresora
o en fichero estructurado), control e intercambio de los documentos a
travs del servicio EDI.
Pgina 35
2.4.4
Software para plataformas superiores
Existe una amplia gama de soluciones software disponible para implantar

en plataformas superiores: UNIX (IBM, HP9000,SUN...) Minis (IBM AS/400,
UNISYS, RS6000,...), Mainframs (IBM, AMDHAL).
Estas soluciones se desarrollan sobre dos mdulos: el de comunicaciones
y el de traduccin, de forma que integran con las aplicaciones internas de
usuario, evitando as la necesidad de reproduccin normal de los documentos.
2.5 Soporte.
La estructura de soporte a usuarios del Servicio EDI debe estar formada
por las personas y recursos destinados a hacer de la utilizacin del servicio un
medio sencillo y seguro para que los usuarios se incorporen a l. El soporte a
usuarios resuelve los problemas y dudas que se puedan plantear durante el uso
del Servicio. Es conveniente disponer de una lnea 900 de forma que las
llamadas sean gratuitas.
El soporte a clientes debe garantizar, como mnimo, que el 90% de las
incidencias en el uso del servicio se resuelvan en menos de 10 minutos y el
100% en menos de 2 horas.
El servicio de hot-line debe funcionar de manera continuada a plena
capacidad en las horas laborables del da, y a capacidad media o baja en el resto
de horas y das festivos respectivamente.
La figura siguiente recoge las situaciones en que el hot-line debe prestar
ayuda a las organizaciones que hayan decidido introducir EDI.
Soporte a usuarios
Antes
de
implantacin
la Introduccin
al
Anlisis del impacto de EDI en la organizacin
Durante
implantacin
Recomendacin de comunicaciones a adoptar

Suministro
e
instalacin
del
Software
la
Formacin
a
usuarios
del
servicio
Asesoramiento sobre el nivel de integracin Hardware
si fuera necesario
Despus
de
implantacin
la
Resolucin
de
todo
tipo
Cursos
y
seminarios
Mantenimiento de versiones
de
de
EDI
problemas
reciclaje
El servicio de hot-line que atiende las llamadas de los usuarios, realizar

funciones de Determinacin Resolucin y Seguimiento de los problemas
relacionados con la funcionalidad general del servicio, comunicaciones y
software de usuarios.
Pgina 36
Las funcionalidades bsicas que un sistema de soporte on-line debe

proporcionar son:
Recepcin de llamadas
o
o
o
Servicio 900 (llamada gratuita).

Va Fax.
Otros.
Recogida de informacin
o
o
o
Identificacin de usuario.
Determinacin del nivel de gravedad del problema.
Determinacin del tipo de problema: Hardware,
comunicaciones, otros...
software,
Primeras acciones:
o
o
o
o
Apertura de ticket y asignacin de nmero.

Asignacin de ticket a la organizacin encargada de resolverlo.
Coordinacin general y relacin con el usuario.
Integracin a la base de datos de problemas para identificar la posible
solucin ya detectada.
Otras medidas:
o
o
o
o
Observacin del mecanismo de escala ante problemas.

Tipificacin y documentacin de problemas.
Mantenimiento de estadsticas para confeccionar ndices de calidad.
El ticket se cierra cuando el usuario est de acuerdo.
Pgina 37
CAP. 3
Marco Legal
3.1
3.1.1
Validez y eficacia jurdica de los documentos

Consideraciones generales
Para abordar el anlisis de la validez jurdica de los documentos EDI, deberemos

estudiar la definicin formal de documento. A este respecto, el profesor Prieto Castro lo
considera como el objeto o materia en que consta, por escrito una declaracin de
voluntad, o de conocimiento o cualquier expresin del pensamiento. Llegaramos
entonces a la conclusin de que, nicamente sera, vlido el soporte papel como
plasmacin
de
una
voluntad
a
travs
de
la
escritura.
Sin embargo, la realidad de las relaciones sociales y econmicas nos demuestra, que el
documento se podr encontrar en cualquiera de los soportes fsicos de los que
normalmente se utilizan, y entre ellos el soporte magntico o cualquier otro de los
utilizados en informtica.
Por tanto no se debe identificar documento con un nico soporte. El documento
puede serlo tanto si se encuentra sobre papel o sobre cualquier otro soporte apto segn
su naturaleza.
La consecuencia inmediata de la utilizacin de documentos con formato
electrnico reemplazando el intercambio de documentos en papel se refiere a su
consideracin
legal
y
la
validez
probatoria
ante
un
tribunal.
Esto es debido, al valor que concede nuestra legislacin al soporte papel como prueba
fehaciente, principalmente en determinados documentos, tales como aquellos
instrumentos que otorgan derechos a su portador que tienen el carcter de negociables y
que requieren por su propia finalidad su materializacin en soporte papel. Por tanto, no
son las modificaciones legislativas necesarias el principal obstculo para la
generalizacin de la utilizacin del EDI en las relaciones comerciales habituales entre
las empresas, sino la propia naturaleza de los documentos. Este tipo de documento solo
adquirir fuerza legal con el desarrollo de una legislacin propia que contemple y regule
las diferentes necesidades impuestas por dicha naturaleza.
El resto de los documentos que admitan su traduccin electrnica, determinarn
por si mismos los controles de seguridad aplicables al entorno EDI que garanticen la
autenticidad de contenidos.
Este es por otro lado el objetivo principal del jurista, que deber conocer y
validar las tcnicas electrnicas que confieren seguridad a los documentos. El
instrumento bsico que determina la validez de documentos transmitidos va EDI, es el
Acuerdo de Intercambio, cuyo contenido es ratificado por las partes. Son, por tanto,
las partes las que admiten la validez de los mensajes intercambiados y los consiguientes
efectos legales de los mismos.
De forma general, puede decirse que las modificaciones legislativas requeridas
son necesarias slo en aquellos documentos que por su naturaleza requiera la definicin
Pgina 38
de procedimientos administrativos y tcnicos para que se le reconozcan las mismas

atribuciones que a un documento escrito.
Uno de los ejemplos ms evidentes de esta necesidad, por su enorme repercusin
en la relacin comercial, se encuentra en el mbito fiscal.
La legislacin aplicable en materia contable y fiscal persigue el objetivo de
asegurar la exactitud y veracidad de los asistentes y requisitos de negocio de las
empresas
que
mantienen
una
relacin
comercial.
Las leyes aplicables pueden exigir a las empresas el mantenimiento de registros y
documentacin sobre la actividad comercial de acuerdo a una determinada, forma
detallando requisitos concretos y restricciones sobre cierto tipo de documentacin. Estos
requisitos pueden llegar a constituir en la prctica, barreras en este terreno, sin embargo
las leyes fiscales han sido modificadas en numerosos pases con el fin de permitir las
nuevas tcnicas de procesamiento y almacenamiento de la informacin, entre otras
cosas, porque las propias autoridades administrativas emplean estas tcnicas, y obtienen
un considerable beneficio con la recepcin de datos de los sujetos pasivos en formas
fcilmente procesables por los sistemas informticos desarrollados.
A este respecto podemos citar:
Real Decreto 261/1996 de 16 de Febrero por el que se regula la utilizacin de
tcnicas electrnicas informticas y telemticas por la Administracin Gral. del Estado.
Circular 5/1995 de 14 de Diciembre del Departamento de Aduanas e Impuestos
Especiales de la Agencia Estatal de Administracin Tributaria por la que se aprueban
las instrucciones para la formalizacin del documento nico administrativo (DUA). Esta
iniciativa surge con el fin de mejorar la calidad de los servicios asociados al trfico de
mercancas a travs de la aduana. Contempla la conexin de los operadores a travs de
una red de valor aadido y su misin fundamental es regir el EDI empleados en:
La comunicacin de manifiestos entre consignatarios y puertos y entre stos y la
Administracin aduanera.
El despacho de aduanas establecido entre agentes de aduanas y la
Administracin.
Resolucin del 23 de Mayo de 1995 de la Direccin General de Tesorera General
de la Seguridad Social por la que se desarrolla la Orden 3 de Abril d 1995 sobre uso de
medios electrnicos, informticos y telemticos en relacin con la inscripcin de
empresas, afiliacin, altas y bajas de trabajadores, cotizacin y recaudacin en el mbito
de la Seguridad Social.
Merece especial consideracin el anlisis de la admisibilidad por la legislacin, la
factura intercambiada y materializada por medios electrnicos, por su especial
importancia en la relacin comercial entre las empresas y, al mismo tiempo por ser
elemento de evidente repercusin fiscal.
Pgina 39
3.1.2 LA FACTURA ELECTRNICA

Dado que la Hacienda Pblica establece las condiciones que deben cumplir las
facturas electrnicas, bajo la amenaza de importantes sanciones econmicas en el
supuesto de no cumplir con las formalidades exigidas, entendemos que es de
considerable importancia tratar aqu los requisitos fiscales exigidos por nuestra
legislacin que condicionan la completa validez de los documentos frente a la
Administracin Tributaria.
La ley 37/1992 del 28 de Diciembre del Impuesto sobre el Valor Aadido
(IVA), as como el Real Decreto 162/92 por el que se aprueba el reglamento del IVA,
suponen la apertura de la legislacin fiscal espaola, siguiendo la de otros pases de la
Unin Europea, a la administracin de la factura emitida y recogida en soporte distinto
al papel, en este caso la admisin de la factura electrnica.
De esta manera el artculo 88.2 de la Ley del IVA establece que:
La repercusin del impuesto deber efectuarse mediante factura o documento
anlogo, que podrn emitirse por va telemtica, en las condiciones y con los
requisitos que se determinen reglamentariamente.
La ley del impuesto se limita a abrir el camino de la adminisibilidad de la factura
electrnica, quedando entonces pendiente de desarrollo de otras normas de rango
inferior.
Nos encontramos as con el Reglamento del IVA y con las modificaciones
introducidas en el Real Decreto 2402/1985 de 18 de Diciembre, por el que se regula el
deber de expedir y entregar factura, que incumbe a empresarios y profesionales.
El nuevo Reglamento aade un artculo, el 9 bis, de gran importancia, cuyo texto
dice:
Las facturas transmitidas por va telemtica a que se refiere el artculo 88.2 de la
ley del Impuesto del Valor Aadido, tendrn la misma validez que las facturas
originales. La informacin contenida en la factura emitida y recibida deber ser
idntica. La administracin tributaria podr exigir en cualquier momento al
empresario o profesional emisor o receptor su transformacin en lenguaje legible,
as como su emisor en soporte de papel.
Este artculo establece los requisitos necesarios par asegurar la validez de las
facturas intercambiadas dentro de un Sistema de Facturacin Telemtica.
No obstante el apartado 5 del presente artculo establece lo siguiente:
Lo dispuesto en este artculo no ser de aplicacin hasta que el Ministerio de
Economa y Hacienda dicte las correspondientes normas de aplicacin.
En virtud de lo cual se dio la redaccin a la Orden Ministerial 7152 del 22 de
Marzo de 1996 por la que se reglamenta la aplicacin del Sistema de Facturacin por
Medios Telemticos (SIFMT).
Pgina 40
La orden comienza definiendo los elementos integrantes de un SIFMT, sus

obligaciones y todas las disposiciones y normas que han de cumplir para su
reconocimiento legal. Los elementos integrantes son los siguientes:
3.1.2.1
La factura electrnica.
La define como un conjunto de registros bsicamente almacenados en

soportes susceptibles de ser ledos por equipos electrnicos de procesamiento de
datos, que documenten las operaciones empresariales o profesionales. La factura
electrnica deber cumplir los mismos requisitos exigidos a las facturas en soporte
papel (Real Decreto 2402/1985) si bien, permiten la posibilidad de sustituir
descripciones de bienes o servicios por cdigos estables.
3.1.2.2
Sistema de Intercambio de Facturacin por Medios Telemticos (SIFMT).
El sistema de Intercambio de facturacin por medios telemticos (SIFMT) es un

sistema en el que intervienen un promotor, uno o ms centros servidores, los usuarios y
los prestadores de servicios informticos, si los hubiere, con el fin de intercambiar
facturas por medios electrnicos.
3.1.2.3
Promotor
El promotor de un Sistema de Intercambio de Facturas por Medios Telemticos

(SIFMT) es el titular de la autorizacin del mismo. Pueden acceder a la citada
titularidad empresarios, profesionales o sus agrupaciones. El promotor es una figura
interesada en promover la implantacin de un SIFMT y, como tal, adquiere una serie de
obligaciones especificadas en la presente Orden Ministerial, entre stas obligaciones se
encuentran entre otras cosas:
La de solicitar a la Agencia Estatal de Administracin Tributaria la autorizacin
de implantacin del SIFMT. La Agencia Estatal resolver sobre la solicitud en el
plazo de los seis meses siguientes a la recepcin. El cmputo de los plazos
quedar interrumpido en aquellos supuestos en los que la Agencia requiera del
interesado nuevos datos o informaciones necesarios para la resolucin del
expediente. Durante la tramitacin del expediente, el Departamento de
Inspeccin financiera y tributaria de la Agencia Estatal podr realizar los
controles que entienda oportunos en el establecimiento destinado al efecto por el
transmisor, el receptor o el prestador del servicio de teletransmisin.
El procedimiento descrito deber seguirse asimismo en aquellos casos en que se
desea modificar el sistema, con la nica salvedad de que en estos casos, si en el
plazo de seis meses la Agencia Estatal no ha resuelto el expediente, se entender
que la modificacin se encuentra autorizada.
Otra de las obligaciones del Promotor del SIFMT es la de adoptar los controles
suficientes para asegurar el cumplimiento de las condiciones y requisitos
establecidos y disponer en los Centros Servidores, de los debidos
procedimientos y controles que aseguren la conservacin del contenido original
.... de la informacin que est obligado a tener a disposicin de la
Administracin Tributaria durante el periodo de prescripcin.
Pgina 41
Facilitar el acceso y la documentacin que sea precisa por parte de la inspeccin

de Tributos, y en definitiva, actuar como representante y responsable del SIFMT
ante las autoridades tributarias.
3.1.2.4
Usuarios de SIFMT
Son todos aquellos empresarios, profesionales o sus agrupaciones que sean

autorizados a operar en cualquier SIFMT establecido. Dicha autorizacin se obtiene
previa solicitud dirigida a la Administracin Tributaria, con una anticipacin mnima de
30 das a su puesta en servicio.
El Centro Servidor, que ha de residir en territorio espaol, ser un centro
transparente, muy controlado, que actuar como intermediario del sistema.
Son extensibles, las obligaciones de la figura del Promotor, al Centro Servidor.
Excepto las relativas a las solicitudes de autorizaciones administrativas.
3.1.2.6
Prestador de Servicios Informticos
Son todos aquellos empresarios, profesionales o sus agrupaciones que

desarrollan o comercializan programas o equipos para cualquier SIFMT.
La presente Orden Ministerial les obliga a colaborar con la Inspeccin de
Tributos en la realizacin del control fiscal sobre los integrantes de SIFMT, aportando
para
ello
la
informacin
que
sea
necesaria.
Adems, los programas informticos que desarrollen debern adaptarse a las
especificaciones
del
Sistema.
Paralelamente, la Orden Ministerial establece una serie de mecanismos de control y
revisin del buen funcionamiento del SIFMT, que incluyen tanto medidas de control
administrativo, como un plan anual de actuaciones, que permiten efectuar un
seguimiento del buen funcionamiento de los sistemas de facturacin autorizados.
Por consiguiente, visto todo lo expuesto se puede deducir obviamente, la
aceptacin de la factura electrnica, siempre y cuando se renan todos los requisitos
mencionados que garanticen la autenticidad del documento en cuestin.
En cualquier caso, y al margen de la normativa anterior, se puede afirmar sobre la
validez y eficacia jurdica de una factura EDI, en base a lo siguiente:
En primer lugar, en base al Acuerdo de Intercambio que firman los
interlocutores de un Servicio EDI, se puede ratificar la validez y efecto jurdico
de los documentos que las partes acuerdan intercambiarse.
En segundo lugar, desde el punto de vista formal, no debemos confundir la
factura con su soporte. Los ordenamientos jurdicos actuales suelen exigir un
determinado soporte (generalmente papel) por motivos fiscales y de control
mercantil, pero los requisitos que establece la ley para la materializacin en
soporte papel de la factura se refieren a los datos que constituyen su contenido
Pgina 42
(NIF de emisor y receptor, fecha, nmero, concepto, precio, base imponible), no

a la materializacin bajo un determinado formato.
3.2
Responsabilidad de las partes en una transaccin va EDI
3.2.1
Consideraciones generales
En una transaccin va EDI intervienen, como regla general, tres partes:

Emisor del mensaje EDI
Receptor o destinatario del mensaje EDI
Proveedor del Servicio EDI
A cada uno de ellos le corresponde una serie de derechos, obligaciones y
responsabilidades, que se regulan en los siguientes contratos:
Acuerdo de Intercambio: Recoge el marco de referencia en el que se
encuadran los intercambios EDI de los usuarios.
Contrato de Servicio: Es un contrato que firman en proveedor del servicio con
los usuarios, y recoge las condiciones de adhesin a dicho servicio.
Es conveniente aclarar que las funciones y responsabilidades que se especifican a
continuacin son generales y la aparicin de sucesivas normativas y regularizacin en el
marco legal espaol referente al EDI, como es el caso de la Orden Ministerial del 22 de
Marzo de 1996, sobre la factura telemtica irn estableciendo las obligaciones y
responsabilidades legales para cada parte (usuarios, promotores, centros de
compensacin,...) y para cada tipo de documento EDI (factura).
Las principales obligaciones que afectan al Prestatario del Servicio se resumen en:
Transporte del mensaje siguiendo los formatos y protocolos correctores.
Proteccin para controlar la corrupcin del contenido de los mensajes.
Garanta de la transmisin del mensaje a su destinatario.
Preservar la confidencialidad de la informacin intercambiada por las partes.
La relacin contractual entre el proveedor del Servicio y las partes intervinientes en
la transaccin EDI puede materializarse de dos formas:
Si el proveedor del servicio ofrece idnticas prestaciones a emisor y receptor de
la informacin, ambos podrn firmar un nico contrato con el prestatario del
Servicio.
La forma ms comn, sin embargo, consiste en que cada uno de los
interlocutores firme un contrato de forma separada con el proveedor del
Servicio.
Pgina 43
El juego de responsabilidades vara considerablemente de unos contratos a otros,

pudiendo determinar la responsabilidad del prestatario del Servicio frente al emisor del
mensaje, frente al receptor o frente a ambos, e incluso eliminar o limitar su
responsabilidad.
Una de las posibles limitaciones a la responsabilidad puede encontrarse en el hecho
de que el proveedor del Servicio no siempre dispone de los medios necesarios para
asegurar la completa fiabilidad del medio utilizado como vehculo de las transacciones.
Con respecto a la responsabilidad del emisor del mensaje, se refiere al deber de
cumplir los compromisos establecidos con respecto a sus interlocutores - mediante un
Acuerdo de Intercambio - y respecto a la red utilizada como vehculo de transmisinmediante el Contrato de Servicio- adems de asegurar que la utilizacin del EDI no
afecta a la relacin comercial.
El emisor del mensaje tiene responsabilidades similares a las del proveedor del
servicio as como ciertas obligaciones adicionales como:
1. Transmisin de los mensajes siguiendo los formatos y protocolos correctos
(acordados por laspartes).
2. Evitar la corrupcin de los mensajes intercambiados.
3. Asegurar el envo de los mensajes al destinatario correcto.
4. Asegurar que el envo de los mensajes se realiza por las personas autorizadas a
tal efecto.
5. Asegurar que los mensajes concuerdan con los trminos de la transaccin
acordada por las partes.
6. Poseer licencias que fueran necesarias para la transmisin a determinada
informacinprotegida por Copyright.
7. Conservar un registro informtico de los intercambios.
El receptor del mensaje tiene responsabilidades similares a las del resto de
intervinientes, y dado que la relacin va EDI tiene una sentido bilateral, ha de cumplir
los mismo requisitos que se establecen para la transmisin de la informacin.
Como responsabilidades especficas de la recepcin de la informacin cabe citar
principalmente las siguientes:
Asegurarse de que el receptor es el destinatario a quien va dirigida la
informacin.
Reconocer y verificar el contenido de los mensajes recibidos.
Preservar la confidencialidad de los mensajes y garantizar su seguridad.
No siempre se establece la obligacin de reconocer y verificar el contenido de los
mensajes recibidos, sino que, en general, se limita a la confirmacin de la informacin
recibida con la generacin automtica de acuses de recibo por cada mensaje o para
determinados tipos de mensajes intercambiados.
A continuacin pasamos a analizar el Contrato de Servicio y el Acuerdo de
Intercambio que, como ya vimos, son la base sobre la que se asientan las relaciones de
intercambio va EDI.
Pgina 44
3.2.2
El contrato del Servicio EDI
Como ya vimos, el Contrato de Servicio EDI recoge las condiciones de adhesin

al servicio de los usuarios, las obligaciones y responsabilidades de las partes (usuarios y
prestador
de
servicio).
El prestador de servicios representa la figura del CC. Su funcin es equivalente a un
servicio de correos, al que los usuarios se conectan a travs de un determinado software,
disponiendo de buzones electrnicos mediante los cuales pueden transmitir y recibir
informacin en formato electrnico del colectivo de interlocutores adscritos al servicio
EDI.
Pero las prestaciones de los Centros Servidores abarcan otras posibles
actividades como: recuperar y mantenimiento de la informacin, controles de validacin
de la misma, variedad de modos de acceso al mismo, funciones de estadstica,
tratamiento especfico de determinado tipo de informacin, distribucin de mensajes a
varios interlocutores, e incluso, facilidad de conexin con dichas redes, funciones de
fedatarios o notario pblico ante posibles litigios entre partes.
Del estudio de los distintos contratos destacamos una serie de aspectos comunes
a todos ellos:
3.2.2.1
El servicio
El Contrato de Servicio ha de especificar qu tipo de protocolos y qu estndares

se van a utilizar adems de cuales son los mensajes que pueden ser transmitidos a travs
de la red contratada. Tambin debe contener disposiciones concretas respecto al tipo de
versin de los mensajes que se intercambian, a la transmisin de nuevos mensajes, y a
las facultades de uso de estos mensajes por el usuario del sistema.
Otro tipo de informacin relevante sobre el servicio que debe figurar en el contrato
es el aspecto econmico. Deber contemplar los costes asociados a las distintas
prestaciones, la forma de tarificacin del servicio, la forma de devengo del precio, las
condiciones
de
pago,
etc.
Por ltimo, otros aspectos definitorios del Servicio que deben tener cabida en un
contrato son:
Instrucciones peridicas concernientes a su utilizacin.
Soporte o asistencia tcnica.
Clusulas sobre posibles modificaciones, actualizaciones, etc.
3.2.2.2 &nbsa; Obligaciones de los usuarios
La mayora de los contratos firmados entre los usuarios y prestatarios del
Servicio plantean la responsabilidad de aquel respecto a la exactitud y correccin de la
informacin
transmitida
va
EDI
a
travs
de
la
red.
Algunas de estas responsabilidades pueden ser: utilizacin de claves para la
identificacin del usuario en el sistema y acceso al Servicio, definicin y modificacin
de perfiles de intercambio, utilizacin de un software y hardware especfico, etc.
3.2.2.3 &;nbsp; Acceso al sistema y propiedad de la informacin
Pgina 45
La disponibilidad temporal del Centro de Compensacin en cuanto a acceso al

mismo y capacidad de procesamiento de la informacin es uno de los aspectos ms
crticos que contemplan los contratos de Servicio, por el inters para los usuarios en
discernir si esta disponibilidad se adapta a las necesidades de intercambio de
informacin que tiene una determinada empresa u organizacin.
La disponibilidad del Centro de Compensacin debe contemplar dos conceptos:
Horario de servicio (Normalmente servicio de 24 horas al da, durante todo el
ao).
Capacidad de la red (Tiempo de procesamiento de la informacin durante las
horas de operacin del Servicio).
En cuanto a la propiedad de la informacin el principio general que se aplica entre
los contratos de Servicio, que muchas veces se contempla expresamente en alguna
clusula del contrato, especfica que el Centro no es en ningn momento propietario de
la informacin que procesa o archiva, no pudiendo ejercer ningn derecho sobre la
misma ni decidir sobre su retencin frente al emisor de la informacin que posee todos
los derechos sobre la misma.
3.2.2.4
Seguridad y confidencialidad
Uno de los aspectos ms crticos a la hora de valorar la utilizacin de un Servicio

EDI que implique la presencia de un intermediario en la transaccin de la informacin
entre el emisor y el receptor, se centra en la determinacin de los procesos de seguridad
que implementa el sistema para garantizar la inalterabilidad de la informacin
intercambiada, y la garanta de la confidencialidad de la misma.
La garanta de confidencialidad forma parte esencial de los contratos de
Servicio, especificndose en las clusulas que la regulan, su alcance y forma en la que
se materializa.
Una de las formas que tiene el usuario del Servicio de comprobar las garantas
de seguridad que ofrece el prestatario del Servicio EDI consiste en requerir de ste
algn tipo de certificado expedido por algn organismo oficial que evale la fiabilidad
del sistema.
3.2.2.5
Auditora
Resulta cada vez ms frecuente que los proveedores de servicios EDI se sometan
a procesos de auditora externos para garantizar a los usuarios el correcto
funcionamiento y fiabilidad de los sistemas que operan.
3.2.2.6
Interconexin de redes
La problemtica de la interconexin de redes, se identifica en un sistema EDI,

cuando los usuarios desean establecer comunicaciones con otros interlocutores que no
son usuarios del CC. La interconexin de CC (redes) evita los costes y complicaciones
funcionales que supondra para los usuarios la contratacin de los servicios de distintas
redes de valor aadido (VAN).
Pgina 46
El fenmeno de la interconexin de redes tiene repercusiones legales tanto en lo

que se refiere a las relaciones que establecen los CC entre s, como a la que mantienen
los usuarios de un determinado Centro con los Centros Intermediarios.
Los usuarios con necesidades de comunicacin con interlocutores adscritos a
otras redes de valor aadido, podran requerir a su proveedor de servicio una copia del
Acuerdo de Interconexin entre las redes como parte de la informacin del sistema
contratado para salvaguardar sus garantas.
3.2.2.7
Responsabilidad
La tendencia contractual que siguen la mayora de los Servicios de Valor

Aadido en todo el mundo, aboga por la exclusin o la limitacin mxima posible de la
responsabilidad
del
prestatario
de
un
servicio
EDI.
La mayora de los contratos de Servicio incluyen la indemnizacin por daos causados
directamente por el prestatario del Servicio, con un lmite mximo establecido en alguna
clusula del mismo.
En lo que se refiere a los elementos tcnicos del sistema:
Si los proporciona el proveedor del Servicio, este puede recoger en el contrato la
garanta del correcto funcionamiento de sus equipos durante un perodo de
tiempo determinado.
Si los adquiere el usuario en el mercado se minimiza el grado de responsabilidad
del proveedor de Servicio en este punto.
La responsabilidad del proveedor del Servicio EDI, en lo que respecta a la correcta
operacin del sistema contemplndose expresamente, en algunos contratos estudiados,
el deber de actuar con la debida diligencia que prevenga la prdida, alteracin o difusin
indebida de la informacin intercambiada por los usuarios, tambin ha de tener un
apartado en el Contrato EDI especificando las actuaciones preventivas de prdida,
alteraciones o difusin indebida de la informacin.
El tratamiento de posibles incumplimientos de alguna de las Funcionalidades del
Servicio tambin est contemplado en el Contrato de Servicio. De forma general, la
mayora de las redes reflejan expresamente su obligacin de corregir los fallos o
defectos en que puede incurrirse.
Por otra parte, las distintas clusulas que determinan la hipottica indemnizacin a
los usuarios tienen distinto alcance en cuanto a su extensin y cuanta en cada uno de
los contratos de servicio, pero se puede decir, con carcter general, que incluyen la
cobertura de los derechos de propiedad, protegiendo a ambas partes de los actos y
omisiones de la otra parte, dependiendo del grado de negligencia acontecida.
Las clusulas de limitacin de responsabilidad pueden tambin limitar el perodo de
tiempo dentro del cual el usuario puede entablar acciones legales contra el proveedor
del Servicio, a veces incluso con el deber de notificacin previa por parte del usuario
hacia el proveedor.
Pgina 47
3.2.2.8
Otras funciones (Fedatario Pblico)
Si as lo establecen las partes, El CC puede tener una funcin que no slo se

limite al procesamiento y gestin de la informacin dentro del sistema, sino que adems
se extienda a la consideracin del proveedor como fedatario de las transmisiones
realizadas por los usuarios a travs del sistema.
De este modo, en caso de disputa entre dos interlocutores, cualquiera de ellos
podra solicitar al proveedor del servicio ciertos registros informticos que constituyen
el medio de prueba en el proceso. Podra ser incluso requerido a que produjera algn
tipo de certificado de que el sistema funcionaba correctamente. Esta capacidad del
centro de Compensacin debera aparecer reflejada contractualmente en el Contrato de
Servicio.
Por otro lado, y tambin en caso d disputa, el usuario de un servicio EDI podra
ser compelido por el tribunal para que mostrase los elementos tcnicos de los que se
compone el servicio y su funcionamiento detallado. En consecuencia, el usuario deber
asegurarse el acceso a toda la documentacin existente al respecto de la que disponga el
proveedor del servicio.
3.3
El acuerdo de intercambio
La relacin que se establece entre las partes en una transaccin comercial realizada
va EDI exige que se determinen unas pautas para establecer un marco regulatorio con
los siguientes objetivos:
Dar un mnimo de certeza a la relacin comercial que se establece entre las
partes.
Establecer el valor legal, entre las partes, de los documentos transmitidos por
EDI.
Determinar el procedimiento o procedimientos dirigidos a la resolucin de un
hipottico litigio en caso de producirse desacuerdo entre las partes.
La va sin duda ms adecuada para el cumplimiento de estos requisitos consiste en
la celebracin de un Acuerdo de Intercambio (Intercahange Agreement o Trading
Partner Agreement de acuerdo con la terminologa britnica o americana).
La primera iniciativa llevada a cabo para acometer la tarea de alcanzar algn tipo de
compromiso en esta materia, surgi del Nordic Legal Comitte bajo los auspicios de
UN/ECE WP4.
El resultado de los trabajos de este comit se concret en un informe con el ttulo de
Proposal for Uniform Rules for Communication Agreements (UNCA) ECE
TRADE/WP.4/R.300, ICC DOCUMENTO N374/1.
La complejidad de crear un acuerdo de intercambio para todas las organizaciones
que utilizan EDI en su relacin comercial internacional debido a los numerosos y
diversos requisitos de las legislaciones nacionales, condujo a abandonar su idea de un
Acuerdo de Intercambio Internacional en favor de la elaboracin de un cdigo de
conducta
basado
en
normas
uniformes.
Pgina 48
El desarrollo de esta actividad se encomend a la International Chamber of Commerce

(ICC) por su experiencia contrastada en la elaboracin de este tipo de normas.
Los principios bsicos en los que se basara el Cdigo de conducta se referan a:
Facilitar el uso de intercambio electrnico de datos a travs de un cdigo de
conducta consensuado entre las partes.
El cdigo de conducta se referira al intercambio de informacin, no al
contenido de los mensajes transmitidos.
Incorporar la adopcin de estndares ISO y otros internacionalmente acordados
para evitar confusin.
Tratar los aspectos de seguridad, verificacin, confirmacin y Autentificacin
entre los interlocutores junto con las cuestiones de control y almacenamiento de
la informacin intercambiada.
Establecer un punto central para la interpretacin de los acuerdos para favorecer
un comportamiento armnico en el uso del Cdigo a nivel internacional.
Este conjunto de reglas, aunque no tienen el valor de un instrumento legal, pretenda
cubrir una etapa de transicin hasta que las legislaciones nacionales e internacionales
desarrollarn los principios necesarios para permitir su utilizacin.
Su importancia estriba en que fue el primer acuerdo adoptado internacionalmente
que pretenda cubrir los aceptos legales de EDI, de la misma forma que EDIFACT se
ocup de los aspectos tcnicos buscando la estandarizacin de las soluciones EDI.
Desde la elaboracin del Cdigo de Conducta UNCD se han producido
significativos avances dirigidos a encontrar soluciones prcticas con el objetivo de
regular la relacin jurdica que se establece entre dos interlocutores que utilizan EDI
para intercambiarse informacin.
Bajo el programa TEDIS, la Comisin Europea de las Comunidades Europeas ha
generado un modelo europeo de Acuerdo de Intercambio considerado como uno de los
mayores logros de este programa y en cuyo desarrollo han participado desde 1990 todos
los estados miembros de forma coordinada.
En Espaa se han desarrollado algunos modelos de acuerdo de intercambio para su
uso en un determinado sector.
El primero de ellos, propuesto por AECOC (Asociacin Espaola de Codificacin
Comercial) fue producido en 1990 para su utilizacin por los usuarios del Servicio
AECOM.
El servicio AECOM es un servicio EDI definido por AECOC para la comunicacin
entre proveedores y distribuidores de bienes de gran consumo espaoles, asociados a
este organismo, que agrupa hoy en da a ms de 10.000 empresas de nuestro pas.
Un nmero significativo de empresas utilizan este servicio desde su puesta en marcha
en 1990 pudiendo regular mediante este acuerdo las relaciones que inician con sus
interlocutores va EDI.
Pgina 49
Otro ejemplo, tambin incluido en el anexo, es el elaborado por Alcatel Standard

Elctrica SA para la conexin va EDI de esta empresa con sus proveedores, recogiendo
las recomendaciones UN/ECE y las recomendaciones EDIFICE que se refieren a su
utilizacin del EDI en el sector de la electrnica, informtica y telecomunicaciones.
3.3.1
Funciones del acuerdo de intercambio
Los acuerdos de intercambio firmado entre los interlocutores EDI estn diseados
de forma genrica para cubrir las siguientes funciones:
Ratificar la validez de las transacciones realizadas va EDI.
Reducir la posible confusin y falta de entendimiento entre las partes.
Definir la responsabilidad, riesgos y garantas de las partes.
3.3.2
3.3.2.1
Contenido del acuerdo de intercambio

Definicin y objetivo
Dado que el EDI supone una nueva forma de comercio basada en la

comunicacin electrnica entre las partes, es muy comn que en el Acuerdo se anteceda
una introduccin que defina los conceptos bsicos de EDI para una mejor comprensin
del mismo.
Algunos acuerdos definen explcitamente trminos como "firma" o "documento"
para satisfacer los requerimientos legales que implica la transmisin electrnica de
determinados documentos que poseen fuerza legal.
Con frecuencia algunos grupos de usuarios que se inician en la comunicacin va
EDI prevn una etapa de pruebas o piloto en la cual adems de su duracin, habr que
determinar la validez de los documentos intercambiados durante este perodo de tiempo,
y la necesidad de duplicar la informacin transmitida va papel.
3.3.2.2
Intercambio Electnico
El estatus legal de las comunicaciones se contempla en todos los modelos de

acuerdo
de
intercambio.
En algunos modelos, esta cuestin se trata en la parte introductoria, en el captulo de
definicin del sistema.
Por lo general se pueden distinguir tres formas de tratar esta cuestin:
Redefiniendo los trminos.
Acordando otorgar a los documentos transmitidos va EDI la misma validez que
aquellos que se emiten y reciben ensoporte papel.
Pgina 50
Acordando no recusar la validez de los mensajes transmitidos por EDI.

La adopcin de estos acuerdos ayuda en gran manera a determinar la validez legal
de los mensajes transmitidos va EDI en caso de litigio ante un tribunal.
En relacin a la formacin del contrato es necesario que las partes acuerden cundo
consideran
un
mensaje
recibido.
Este aspecto resulta especialmente importante cuando los mensajes intercambiados
suponen pagos o cobros en un determinado plazo de tiempo. Habr que distinguir si un
mensaje se considera recibido cuando ha sido depositado en el buzn electrnico del
receptor, o bien cuando el destinatario lo ha recuperado del mismo.
En relacin a la formacin de la relacin EDI, el acuerdo de intercambio incluir un
anexo con un listado de los tipos de documentos que se intercambiarn.
3.3.2.3
Responsabilidades
El contenido de las clusulas de responsabilidad de las partes depende

obviamente de la naturaleza del acuerdo de Intercambio que se trate. El modelo de
Acuerdo en la U.K. Association (SIA) que ha servido de pauta a la gran mayora de
modelos existentes no incluye una clusula de responsabilidad en extenso dado que
presupone que los daos y perjuicios que pudieran producirse entre las partes provienen
de la violacin del contrato subyacente o por la actuacin negligente de las partes, no
por el medio de comunicacin que se emplea para la transmisin de los mensajes.
El aspecto bsico de la responsabilidad inherente a la utilizacin de cualquier medio
de transmisin se refiere a la obligacin que tiene el emisor de transmitir los mensajes
ntegramente
y
con
total
exactitud.
Este aspecto debe ser, por lo tanto, recogido expresamente en el Acuerdo de
Intercambio.
Las nicas restricciones que figuran en el SIA que limitan la responsabilidad del emisor
se refieren a:
La generacin de un error causado por un fallo tcnico del emisor.
Cuando se hubiera producido un error en circunstancias "razonablemente
obvias" para el receptor.
Todos los Acuerdos analizados contemplan que en caso de producirse el envo y
consiguiente recepcin de un mensaje EDI incorrecto, el receptor debe comunicarlo al
emisor a la mayor brevedad posible, o de lo contrario el emisor podra actuar como si su
contenido fuera correcto.
En estos trminos parece adecuado afirmar que no resulta necesario que las
empresas usuarias de EDI contraten seguros para cubrir posibles riesgos.
Algunos Acuerdos de Intercambio incluyen una clusula relativa a la necesidad
de contratar un seguro como obligacin de las partes que utilizan el sistema EDI, si bien
esta clusula es poco frecuente.
Pgina 51
3.3.2.4 Seguridad y confidencialidad

Los procedimientos tcnicos que confieren seguridad a las transmisiones
realizadas va EDI constituyen un componente crtico dado que confieren al EDI el
grado necesario de fiabilidad y fomentan su difusin.
Por oro lado, la incorporacin al sistema de medidas de seguridad pueden ayudar
en gran medida a determinar la eficacia jurdica de los documentos transmitidos.
Resulta por lo tanto indispensable que las partes acuerden, implementen y mantengan
un cierto nivel de seguridad en sus transacciones.
El nivel de proteccin y seguridad requerido en cada caso depende obviamente
de la naturaleza de la informacin intercambiada.
Los mensajes que generan pagos o cualquier otro de contenido financiero
requieren en todos los pases en los que se utilizan, procedimientos de encriptacin. Sin
embargo para el intercambio de documentos comerciales como pedidos y facturas no se
suelen
adoptar
estos
sistemas
de
proteccin.
Si los procedimientos de seguridad no se recogieran expresamente en el Manual de
especificaciones tcnicas o si el emisor quisiera proveer a un mensaje determinado de
algn tipo de proteccin adicional, se podra establecer una clusula que determinase
que el nivel de seguridad, pudiera ser establecido por el emisor del mismo con la
obligacin por parte del receptor de mantener este nivel de seguridad para futuras
transacciones.
Tan importante como determinar los procedimientos de seguridad de los intercambios,
resulta el establecimiento de procedimientos que garanticen su continuidad a travs de
sistemas
de
auditoria
informtica.
La transmisin de mensajes como el "acuse de recibo" de un documento o la
confirmacin de su contenido puede ser acordada por las partes en aras de obtener una
mayor seguridad y certeza en los intercambios.
La generacin de acuses de recibo suele ser una facilidad automtica de la red o
Centro de Compensacin al que se encuentran conectados los usuarios EDI.
El mensaje de "confirmacin de contenido" supone la obligacin para el receptor
de leerlo dentro de un determinado perodo de tiempo y de confirmar al emisor sobre su
correccin. La implantacin de este tipo de mensajes lleva consigo un altsimo grado de
certeza y seguridad en los intercambios, pero, en contrapartida supone alguna forma de
intervencin manual lo que implica la prdida de alguno de los beneficios que supone la
transmisin electrnica va EDI.
La utilizacin de sistemas expertos que controlen la recepcin y entrada de datos
en la aplicacin informtica del destinatario podra ser en el futuro la solucin tcnica
que eliminase toda forma de inseguridad sin la necesidad de recurrir a procedimientos
manuales.
Sin embargo, conviene matizar que la implantacin tanto de acuses de recibo como de
mensajes de confirmacin del contenido no suponen para el receptor una aceptacin en
sentido contractual, a menos que as lo determinen las partes.
Pgina 52
La confidencialidad de la informacin intercambiada es otro de los aspectos

relevantes que debe contemplar el Acuerdo de Intercambio.
Este aspecto ha sido tratado en los acuerdos de tres diferentes categoras:
1. Inclusin de clusulas que determinan la confidencialidad de la informacin
intercambiada.
2. Inclusin de una clusula general de no confidencialidad.
3. Determinacin de la confidencialidad por el emisor de la informacin
En categoras 2 y 3, se presume que las partes han determinado con anterioridad a la
relacin que establecen va EDI, qu tipo de informacin ha de ser considerada como
confidencial; teniendo el emisor en la 3 categora la facultad de clasificar con la
mxima flexibilidad y mensaje la confidencialidad de los documentos que enva. En
algunas ocasiones, los manuales de usuarios establecen la confidencialidad de un
determinado mensaje distinguindolo con un cdigo especial.
Asimismo, en algunos Acuerdos de Intercambio, se incluye una obligacin adicional
para el receptor del mensaje consistente en comunicar al receptor si dicho mensaje ha
sido recibido por error.
3.3.2.5
Autentificacin
La Autentificacin es un aspecto particular que afecta a la seguridad de los

documentos intercambiados que permite al receptor poseer completa certeza respecto al
origen
del
mensaje.
Es un concepto estrechamente ligado al de la firma, entendida desde el punto de vista
legal, de tal forma que la satisfaccin de los requisitos implcitos en un proceso de
autenticacin debera suponer al mismo tiempo el cumplimiento de las funciones que
tiene
una
firma.
Este
concepto
ser
tratado
ms
adelante.
En la mayora de los acuerdos, la autenticacin se encuentra generalmente incluida
como parte de cualquier requerimiento de firma o dentro de las estipulaciones relativas
a la seguridad de los mensajes EDI y referencia en el manual de especificaciones
tcnicas.
Una vez ms, el proceso de autenticacin que se establezca, depender de un acuerdo
con el tipo de mensaje y el propsito para el cual es necesario su firma.
Por este motivo, las partes deberan acordar previamente a la puesta en marcha del
sistema EDI, la posibilidad de emplear procesos de autenticacin de distintos niveles, de
acuerdo con su aplicacin concreta.
3.3.2.6
Obligaciones de destinatartio
En algunos acuerdos de intercambio, las partes determinan las acciones que

deben seguir el destinatario de un mensaje, una vez que lo ha recibido.
En el modelo de Acuerdo de TEDIS se hace referencia directa al respecto,
indicndose que:
Las partes establecern algn tipo de procedimiento o se asegurarn de
alguna manera que sus sistemas informticos procesan los mensajes EDI dentro de
Pgina 53
un determinado perodo de tiempo que se especifique en el Anexo tcnico o en

cualquier otro lugar que las partes acuerden.
Es relativamente frecuente que, por ejemplo, las partes acuerden una cierta
disciplina horaria de conexin a sus buzones electrnicos y que los mensajes recibidos
en destino se procesen en un determinado plazo de tiempo "tan pronto como sea
posible".
Esta obligacin referida a la recepcin y procesamiento de los mensajes se ha de
establecer en relacin a la generacin de los mensajes de acuse de recibo o confirmacin
del
contenido
que
ya
han
sido
comentados
anteriormente.
Alternativamente, podra viajar en el documento a la vez de la forma de pago, la fecha
de pago y calculada en base a la fecha de emisin de la factura y coincide con la fecha
de
recepcin
de
la
misma
e
el
buzn
del
destinatario.
Adicionalmente a esta medida habra que establecer, en el acuerdo de intercambio,
como fecha de recepcin del documento la fecha en que ste fue depositado en el buzn
electrnico del receptor.
3.3.2.7
Almacenamiento y medio de prueba
El artculo 10 de las reglas UNCID determina que los usuarios EDI deben
mantener una "trade data log" como registro histrico de todos los mensajes emitidos y
recibidos.
La funcin primaria de este log es la de poder actuar como medio de prueba en caso de
litigio o con fines de auditoria de las transmisiones efectuadas.
Las partes deben acordar el contenido exacto de estos registros, dado que las
comunicaciones EDI cabe distinguir de forma general dos categoras de datos
intercambiados: los que se refieren a la transaccin comercial y aquellos relativos al
proceso
de
transmisin
y
procesamiento
de
la
informacin.
El almacenamiento de los mensajes podr hacerse en soporte informtico siempre y
cuando los formatos electrnicos sean susceptibles de ser transcritos a toros tipos de
formatos legibles, y por el perodo de tiempo que seale cada legislacin nacional, de
acuerdo al tipo de documento intercambiado, y a lo que las parte acuerden a este
respecto. (En Espaa, la Orden Ministerial de 22 de Marzo de 1996 que regula la
SIFMT, establece los procedimientos de almacenamiento para el documento factura).
Algunos Acuerdos de Intercambio tratan el almacenamiento de datos de forma
separada de su admisibilidad como medio de prueba para intentar evitar los rigurosos
requisitos de admisin como prueba de estos registros para algunas legislaciones,
incluyendo las clusulas del tipo propuesto por el modelo de TEDIS.
En caso de litigio, las partes no podrn en discusin la admisibilidad como medio
de prueba de los mensajes intercambiados y almacenados de acuerdo con las
estipulaciones de este Acuerdo.
Esta clusula, sin embargo, no puede prevenir cualquier tipo de objecin que
pudiera oponer una tercera parte (una autoridad administrativa por ejemplo) en caso de
litigio.
3.3.2.8
Terceras partes
Pgina 54
La mayora de los interlocutores EDI contratan los Servicios de un prestatario de

Servicios de Valor Aadido. Que hace la funcin de CC y/o de red la que se conectan
los
interlocutores
del
sistema.
El Acuerdo de Intercambio ha de indicar, por tanto, si se contempla o no esta figura e
identificar,
en
caso
positivo,
al
prestatario
del
servicio
EDI.
Igualmente, resulta necesario determinar las responsabilidades de los interlocutores con
el
prestatario
que
realiza
la
funcin
de
intermediario.
Dichas responsabilidades se encuentran en relacin directa con el contrato que las partes
firman con dicho intermediario y que constituye el contado de servicio con la de valor
aadido, siendo cada parte responsable de los costes de contratacin con dicha red.
El intermediario puede ser el nico para un determinado Servicio EDI o bien puede
haber distintas redes a las que el usuario pueda conectarse para intercambiar
documentos
EDI
con
sus
interlocutores.
En algunos casos la red puede venir impuesta por distintas circunstancias a alguna de
las partes. En este caso algunos Acuerdos con el SIA incluyen una clusula en la que se
determina que, en caso de producirse este hecho, la parte dominante ser responsable
frente a su interlocutor por las acciones del proveedor del Servicio.
3.3.2.9
Mediacin y arbitraje
La posibilidad de que se llegue a un litigio causado por algn tipo de desacuerdo

entre las partes suele estar recogida en la mayor parte de los Acuerdos de Intercambio.
Dado el coste que supone, en trminos de tiempo y dinero, para las partes
embarcarse en un procedimiento judicial para dirimir sus diferencias, la mayora de
Acuerdos prevn algn tipo de mecanismo de mediacin o arbitraje que evite la disputa
frente
a
un
tribunal.
Por otra parte, la escasez de jurisprudencia en lo que a EDI se refiere, hace
definitivamente recomendable la previsin de mecanismos alternativos al procedimiento
judicial usual.
3.4
Seguridad y validez legal
La seguridad de las transmisiones realizadas va EDI constituye uno de los

puntos a considerar a la hora de evaluar la validez y eficacia jurdica de los documentos
intercambiados entre los interlocutores del sistema.
La transmisin, proceso y archivo de informacin por medios electrnicos y
telemticos debe cumplir unos determinados niveles de seguridad que garanticen la
fiabilidad del sistema y en base a los cuales el estamento judicial pueda determinar la
certeza de las relaciones que unen a las partes.
Los niveles de seguridad fsicos y lgicos necesarios en una relacin establecida
va EDI abarcan desde el acceso a los sistemas por personal autorizado, a la definicin
de procedimientos de archivo de la informacin que eviten su manipulacin.
Dentro del concepto genrico de seguridad, se contemplan aspectos tales como
la fiabilidad de los mensajes e incide en la consideracin como medio de prueba de los
registros
informticos
transmitidos
por
las
partes.
Cuando hablamos de seguridad, en el fondo estamos hablando de las garantas que
Pgina 55
ofrece el sistema tanto a los usuarios como al estamento judicial y que condicionan su
validez
y
eficacia
a
todos
los
niveles.
De hecho, la aceptacin por las distintas autoridades nacionales para la utilizacin de
sistemas electrnicos en general y EDI en particular, pasan, en muchos casos, por la
certificacin de los equipos utilizados inherentes al sistema, al menos, la inspeccin de
los mismos para la comprobacin de que cumplen las condiciones mnimas que se
aseguran la fiabilidad de las transmisiones.
Igualmente, la prueba de la fiabilidad del sistema informtico que se ocupa de
las transmisiones electrnicas resulta esencial a la hora de dotar a los registros
informticos de la certeza jurdica suficiente a su admisin como prueba ante un
tribunal.
Por otra parte los niveles de seguridad de los sistemas EDI guardan una lgica
correspondencia con el tiempo de mensajes intercambiados, y de segn lo establecido
por las partes en el Acuerdo de Intercambio, deben acordarse los procedimientos de
seguridad y conservacin de los mensajes en relacin directa a la importancia de su
contenido.
3.5
Seguridad especfica de los sistemas EDI

Es posible analizar la seguridad de los sistemas EDI desde dos puntos de vista:
Los aspectos de seguridad vinculados a los mensajes.
Los aspectos de seguridad cubiertos por el Centro de Compensacin.
En el primer caso, su uso depender del contenido del acuerdo de intercambio,

mientras que en el segundo, son condiciones del centro, genricas, que se aplican a
todos los usuarios.
3.5.1
Mensajes
En los mensajes EDIFACT existe la posibilidad, como vimos en el apartado

anterior, de aadir informacin de seguridad. Adicionalmente, se han creado algunos
mensajes especficos destinados al uso de servicios de seguridad.
3.5.2
Centro de compensacin
El CC ofrece cobertura contra los riesgos ambientales en base a mecanismos de

seguridad fsica y planes de contingencia. De esta forma est cubierta la eventualidad de
catstrofe natural (terremotos, inundaciones, incendios) o el mal funcionamiento del
sistema.
Mediante
sistemas
y
lneas
de
respaldo.
Los archivos se salvaguardan con esquemas completos e incrementales seguros y las
distintas copias se custodian en cmaras blindadas ignfugas en lugares separados.
Los ordenadores utilizados son tolerantes a fallos y ofrecen un servicio continuo, sin
paradas
para
funciones
de
mantenimiento.
El dimensionamiento de rganos (lneas, CPUs, discos, etc. ) se calcula para que no se
produzcan situaciones de saturacin y la accesibilidad sea siempre del 100%.
De cara a los usuarios, se incorpora los siguientes mecanismos de control:
Pgina 56
Control de Acceso: Mediante uso de identificadores de usuario y palabras de

paso. De esta forma es posible autentificar usuarios, y proporcionar la prueba
que proporciona la Autentificacin de origen de los mensajes.
La custodia de los mensajes: Durante un tiempo es posible volver a recuperar
mensajes ya transmitidos de uno a otro extremo (lo que dota al centro de
caractersticas de auditabilidad). De esta manera se proporciona un nivel bsico
de Integridad de Contenido.
Acuse de recibo: El protocolo de comunicaciones utilizado incluye el envo de
un bloque de control por parte del centro de compensacin al remitente de un
mensaje, cuando el destinatario lo ha recogido de su buzn electrnico. Se trata
por tanto, de un mecanismo de control basado en la eficacia de los diferentes
controles de acceso al sistema.
Estos mecanismos confieren al sistema una seguridad bsica y mnima, pero las
crecientes amenazas hacen avanzar los mecanismos de seguridad, que actualmente
pasan por el uso de herramientas criptogrficas y ms concretamente, por la firma
digital (criptografa de clave pblica). De hecho, la firma digital es la nica forma de
trasladar alguno de los servicios de seguridad ms importantes del mundo del papel al
electrnico.
La implantacin y desarrollo de un servicio de seguridad basado en mecanismos del
tipo apuntado requiere la existencia de una entidad confiable que ejerza la funcin de
Autoridad de Certificacin.
La Autoridad de Certificacin (AC) es la entidad encargada de certificar las claves
pblicas de los usuarios en sistemas basados en criptografa de clave pblica, es decir,
de ligar de forma unvoca las credenciales de un usuario con su clave plica.
La funcionalidad de una AC contempla bsicamente los siguientes servicios:
1.
2.
3.
4.
Generacin de certificados.
Distribucin de certificados.
Peticin de renovacin de certificado.
Revocacin de certificado (mantenimiento de una Lista de Certificados
Revocados -LCR). Una LCR es una lista con todos los certificados que han sido
revocados por sospecha o certeza de que la clave pblica o privada ha sido
comprometida, es decir, revelada.
Estas son las funciones de una Autoridad de Registro, si bien podra considerarse la
posibilidad de incorporar la funcionalidad propia del Notario Electrnico, lo que
permitira elevar a pblicos contratos privados, sin ms que comunicar el documento
electrnico (que podra tener redaccin convencional o, preferiblemente, cumplir algn
tipo de normalizacin que haga identificables para un sistema electrnico al menos los
datos de lo sin intervinientes), as como las firmas electrnicas de las partes que
intervienen, dando fe de la validez de las firmas electrnicas a falta de faltas
manuscritas.
Por la especial relevancia de la firma electrnica describimos, a continuacin, lo que
sera el procedimiento estndar.
Pgina 57
3.5.3
Realizacin de la firma electrnica
De la misma forma que se realiza un otorgamiento de poderes ante notario,

puede especificarse que este otorgamiento podra ser efectivo a travs del empleo de
firma
electrnica.
En el mismo documento se especifican la clave pblica del apoderado, cifrada con la
privada del notario, as como la clave pblica del notario, que permitira la
comprobacin de las firmas con la simple presentacin del documento de otorgamiento.
De esta manera se cumplira con la finalidad del Notario electrnico, y vlido
ante todas las instancias que puedan requerir de la presentacin de poderes.
El notario dispondra de un dispositivo cifrador, que activara con su propia
tarjeta chip, y en la que introducira una tarjeta virgen, en la que se generan claves
nuevas y que se personaliza para el apoderado. En caso de que el apoderado ya posea
esa tarjeta, se certifica la clave ya existente.
En el mismo acto, el dispositivo enva la Clave Pblica Certificada a la
Autoridad de Certificacin de la red, vinculada a fedatario, por lo cual, desde ese
momento las claves pueden modificarse peridicamente de forma segura.
3.5.4
Validez probatoria
Los distintos sistemas de seguridad, tienen capacidad probatoria por s mismos

(cuando son fciles de entender por un juez o un jurado), o por la certificacin de un
perito.
Sin embargo, por razones prcticas, se reducen a unos pocos los medios de prueba
cuando
han
de
ser
utilizados
en
relaciones
comerciales.
El empleo de la firma manuscrita es, en estas circunstancias un recurso sencillo y
efectivo, aunque no excluyente, y con la utilizacin de la firma electrnica se pueden
probar dos externos fundamentales para la certeza de la relacin jurdica:
La auditora del mensaje.
La inalterabilidad de su contenido.
Consiguindose as una validez probatoria muy superior a la firma manuscrita con la
ventaja aadida de que la utilizacin de estos sistemas de seguridad admite el
tratamiento automatizado de documentos por ordenador y la supresin completa del
papel.
En conclusin, existen los medios tcnicos que garanticen la traslacin de los
mecanismos de seguridad de los documentos en formato papel a sus equivalentes
electrnicos, pero es preciso un esfuerzo por parte del estamento legislativo y judicial
para dotarles de un marco regulador que acepte y fomente la extensin de su uso.
Pgina 58
CAP. 4
EDI Y MUNDO EMPRESARIAL
4.
Aplicaciones EDI en el mundo empresarial
La sustitucin de los documentos en papel por los mensajes EDI supone ms una
aceleracin que una modificacin de las transacciones comerciales bsicas. Seguir
habiendo necesidad de enviar un pedido, de hacer una declaracin de aduanas, de
reservar espacio con un transportista, etc.
Presentamos a continuacin unos cuantos ejemplos sencillos para ilustrar la
manera e efectuar transacciones mediante mensajes EDI. Los mensajes que estos
intercambios estn siendo redactados por UN-EDIFACT, y se publican en forma de
recomendaciones de las Naciones Unidades. Algunos de los mensajes que figuran en los
ejemplos se encuentran ya en fase de explotacin o aprobacin definitiva entre ellos, los
correspondientes a facturas, pedidos, declaraciones de aduanas, solicitudes de
transporte,
etc.
Los mensajes que decidan aplicar las partes interesadas en la transaccin, dependern de
sus necesidades y acuerdos mutuos. No es necesario ni recomendable aplicar todos los
mensajes de inmediato, es preferible hacerlo gradualmente.
En el diagrama 1 aparecen los protagonistas principales que toman parte en el
comercio internacional. En los diagramas siguientes se presentan algunos ejemplos de
transacciones concretas: ofertas/contratos, y pedido/instrucciones de suministro.
En este diagrama, l comprador y el vendedor son los protagonistas principales
del intercambio.
Podran trazarse diagramas similares para reflejar los intercambios desde el
punto de vista del transportista, de las aduanas, de los bancos, etc.
Pgina 59
4.1
De la oferta al contrato
Cuando una entidad desea adquirir un producto o solicitar su fabricacin enva una
peticin de oferta a uno o ms proveedores/vendedores, aportando datos como los
siguientes:
Pgina 60
Entidades implicadas
Producto solicitado
Cantidad y fecha de entrega o serie de cantidades y fechas de entrega
Condiciones de entrega, si procede
Lugar de la entrega
Los vendedores/proveedores respondern con sus ofertas al comprador,

confirmando cantidades, fechas de entrega y condiciones de entrega o proponiendo
alternativas.
Basndose en las ofertas recibidas, o despus de nuevas peticiones y ofertas, el
comprador y vendedor acaban por llegar a un acuerdo o pedido redactado por el
vendedor o el comprador. Tras el contrato/pedido, el proveedor tendr que realizar la
entrega basndose en las instrucciones de suministro de los pedidos en firme.
4.2
Pedidos /instrucciones de suministro
El tipo de comunicacin que se establezca entre el comprador y el

vendedor/proveedor depender de los acuerdos comerciales a que hayan llegado. Un
comprador puede solicitar la entrega de la mercanca mediante un mensaje de
instruccin de suministro o directamente mediante pedido.
Los mensajes de instrucciones de suministro son caractersticos de la industria
de fabricacin; en la industria del automvil, por ejemplo, el fabricante presenta al
proveedor un panorama a largo plazo de sus necesidades para permitirle planificar su
produccin y el programa de entregas. Los mensajes de instruccin de suministro que se
intercambia a travs del EDI facilitan la sincronizacin de los calendarios y la
produccin entre el fabricante y su proveedor cuando se aplican tcnicas de fabricacin
"just in time".
Como respuesta, el proveedor/vendedor puede confirmar el pedido del
comprador o modificar alguno de sus parmetros; por ejemplo, la fecha de entrega.
Pgina 61
Anlogamente, el comprador puede tambin solicitar determinados cambios en un

pedido ya realizado.
Cuando las mercancas estn listas, el proveedor/vendedor enviar al comprador
un mensaje de aviso de expedicin informndole de que ya puede recoger la mercanca
o de que sta le ha sido enviada en funcin de lo acordado. En el mensaje de aviso de
expedicin figuran todos los datos referentes a productos, cantidades, embalajes y
transporte necesarios para facilitar al comprador la aceleracin de los trmites.
4.3
De la factura de pago
Una vez entregada la mercanca, el proveedor/vendedor enviar al comprador un

mensaje de factura en el que figurarn las cantidades, precios, condiciones de entrega y
de pago etc., de las mercancas suministradas y de los servicios prestados. Un mensaje
de factura puede referirse a una o mas entregas y solicitar el pago segn las condiciones
acordadas previamente.
Pgina 62
Puede ocurrir tambin que el proveedor/vendedor enve al comprador, adems

de los mensajes de factura, un estado de cuenta peridico en el figuren los pagos
pendientes.
Pueden tambin utilizarse mensajes de nota de abono y de nota de cargo para corregir
las facturas por causa de error en los precios o las cantidades, de devoluciones o
defectos en la mercanca, etc.
El comprador puede pagar al proveedor a travs de un mensaje de orden de
pago, enviado a su propio banco, en el que figuren los siguientes datos: banco
proveedor, facturas que van a pagarse e importes de las mismas. Al mismo tiempo, el
comprador puede enviar al vendedor un aviso de pago para informarle de que el pago
est en marcha. Cuando el banco del vendedor recibe los fondos, le informa de ello
mediante un mensaje de identificacin de abono en el que se detallan las facturas que se
han pagado.
4.4
Solicitud de transporte
En un momento determinado del ciclo comercial, el solicitante del transporte (la

parte que solicita el transporte de la mercanca sea el comprador o el
vendedor/proveedor), o su expedidor, solicitar una reserva provisional de los servicios
de transporte de un transportista o agente de transporte basndose en los datos iniciales
de una consignacin. A sa seguir una reserva en firme al conocerse con ms detalle
los datos de la configuracin, que llevar a la solicitud de reserva como culminacin del
acuerdo entre remitente/expedidor y transportista/agente de transporte. </P<
El transportista/agente de transporte podr confirmar la peticin de reserva en las
diferentes fases del acuerdo: provisional, en firme y contrato (solicitud).
Pgina 63
Adems, el transportista/agencia de transporte podr mantener informado al

solicitante del transporte acerca de la situacin del transporte de la mercanca y
recomendar posibles modificaciones en los planes previstos.
En consonancia con los acuerdos contractuales, el transportista o agente de
transporte podr evitar al solicitante del transporte/expedidor un mensaje de gastos en el
que se relacionen los servicios de transporte y fines prestados y se solicite el pago de los
mismos.
El mensaje de orden de pago del solicitante/expedidor a su banco por el que autoriza el
pago al transportista o su gente se efecta de manera anloga, segn se ve en el
diagrama 5.
4.5
Despacho de aduanas
Cuando una transaccin exija realizar una importacin o una exportacin, las
autoridades aduaneras respectivas recibirn notificacin de exportar, importador y
transportista, o de sus respectivos agentes, sobre el movimiento de mercancas a travs
de la frontera, tal como se indica en el diagrama. Estas declaraciones deben presentarse
antes de la llegada de la mercanca a la aduana.
El exportador y el importador, o sus agentes, remitirn su declaracin aduanera,
a travs de un mensaje EDI que contenga los datos correspondientes a las partes,
resumen de las mercancas por su grupo de artculos transporte y embalaje, derechos de
importacin o de otro tipo que deban abonarse, licencia de importacin, licencia de
exportacin , etc.
El transportista, o su agente, remitirn el mensaje de declaracin del transportista
para la consignacin, basndose en la hora de ruta y la relacin de mercancas.
Pgina 64
Con estos dos mensajes EDI de declaracin aduanera, las aduanas podrn
controlar el flujo de mercancas. La notificacin del despacho de una consignacin y de
cada uno de los envos de una consignacin y de cada uno de los envos de una
consignacin podr comunicarse mediante mensaje EDI al exportador, importador y
transportista, indicando el importe de los derechos que haya que abonar.
El importador, o su agente, pueden efectuar la liquidacin de los mencionados derechos
la aduana a travs de los procedimientos de pago anteriormente.
Si resulta necesario, las aduanas pueden solicitar al importador que les remita un
mensaje de declaracin detallada en el que figuren cada uno de los artculos para
permitir la inspeccin de la mercanca de un envo.
4.6
MERCADO DE SERVICIOS EDI EN EUROPA Y EN ESPAA
A principios de los aos 80 comienza a desarrollarse en Europa el EDI

principalmente
en
pases
como
el
Reino
Unido
y
Alemania.
Actualmente existen en Europa unos 50.000 usuarios, que se elevan a 125.000 si
hablamos de todo el mundo.
Los sectores en los que EDI se han desarrollado son: Automocin, Distribucin,
Electrnica, Farmacia, Sanidad, Turismo, Administracin Pblica, Financiero y
Transporte.
Las tendencias actuales son de un crecimiento del 20% anual. Con un volumen
de facturacin prevista en el 2001 de 961.619.367 millones de EUROS (160.000
Pgina 65
millones de Ptas.), frente a los volmenes obtenidos en el ao 1994 (281.273.665

millones de EUROS, unos 46.800 millones de Ptas.).
En cuanto a la evolucin de los usuarios la tendencia apunta hacia la creciente
incorporacin de las Pymes.
En Espaa el EDI se inicia a finales de la dcada de los 80 y actualmente existen
unos 2000 usuarios distribuidos en los sectores siguientes: Automocin, Distribucin,
Electrnica, Farmacia, Sanidad, Turismo, Administracin Pblica, Financiero y
Transporte.
Las redes proveedoras de Servicios EDI en Espaa y sus cuotas de mercado son:
TSAI
GEIS
IBM
BT
FTRS
65%
25%
8%
1%
1%
En Espaa, las tendencias actuales apuntan a la extensin del servicio a nuevos

sectores de actividad y a la interconexin de redes proveedores de servicios para
ampliar el N de interlocutores potenciales de los usuarios y conseguir un sistema lo
mas abierto posible.
Para el ao 2000 la previsin para el mercado EDI espaol es de 35 millones de
ECUS's(unos 5600 millones de pesetas).
4.6.1
Mercado espaol de servicios EDI
El primer proyecto que se desarroll en Espaa fue ODETTE en 1988, con un

retraso de 4 aos respecto a los pases europeos. Surge en el sector de Automocin par
el intercambio de informacin entre clientes y proveedores beneficindose con la
implantacin
de
tcnicas
"just
in
time"
y
"quick
response".
El nmero de usuarios en Espaa es de 500, cifra que se eleva a 6000 en Europa. Esta
cifra seguir creciendo hasta cubrir la totalidad de las empresas del sector.
AECOM, AECOC para el sector de distribucin, es otro de los sistemas EDI ms
extendidos. Se cre en 1991 y cuenta actualmente con unos 1000 usuarios, destacando
1994 como ao de expansin en el uso de EDI.
Posteriormente se han iniciado otros proyectos con grandes perspectivas de
crecimiento:
EDISTEL es el servicio EDI para las empresas de los sectores de Electrnica,
Informtica y Telecomunicaciones. Los documentos que se intercambias en la
actualidad en este entorno son los siguientes: Pedidos, Ofertas, Facturas y documentos
propietarios con formato EDIFACT.
EDI Farmacia, definido por Farmaindustria y Fedifar para el intercambio
electrnico entre laboratorios farmacuticos y mayoristas de Farmacia. En la actualidad,
Pgina 66
se encuentran conectados 16 usuarios en toda Espaa y los documentos intercambiados

son pedidos y facturas.
EDI Sanidad es el servicio dirigido a facilitar la comunicacin entre centros
hospitalarios, mdicos y sus proveedores. En la actualidad se encuentran conectados 20
usuarios den toda Espaa y los documentos intercambiados son : Catlogos de artculos,
Pedidos y Albaranes.
EdiLocal surge en 1993 por iniciativa de Telefnica y la Federacin Espaola
de Municipios y Provincias (FEMP) para la implantacin y desarrollo de redes y
servicios telemticos entre las corporaciones locales. En la actualidad se encuentran
conectados en Espaa a este servicio 512 usuarios, tanto de la administracin local
como de la central y los documentos intercambiados son: pedidos, facturas, documentos
financieros y el impuesto de actividades econmicas.
El EDI para el sector Transporte surgi en 1993 por iniciativa de la Agencia
Tributaria y Puertos del Estado con el fin de mejorar la calidad de los servicios
asociados al trfico de las mercancas a travs de la aduana. EDI transporte est dirigido
al intercambio de documentos entre Consignatarios, puertos, agentes de aduanas y la
aduana central.
Los documentos intercambiados son:
Manifiesto de carga y descarga
Declaraciones aduaneras de importacin y exportacin
Repuestas de aplicacin
Otras iniciativas que se han producido en Espaa son la adopcin de EDI en la
Seguridad Social, el sector editorial y las centrales de publicidad.
Existe una diferencia que clasifica a estos proyectos en 2 grupos diferenciados. Esta
distincin es la que clasifica los sectores como verticales u horizontales.
Es decir, proyectos como el de ODETTE en el sector de Automocin, AECOM en
el sector distribucin, EDISTEL en el sector electrnica, informtica y
telecomunicaciones, EDIFARMACIA en el sector farmacutico y EDISANIDAD en el
sector de la sanidad, son proyectos que se desarrollan verticalmente, es decir, que
pueden crecer dentro del propio sector (aumentar el N de usuarios y el N de
documentos intercambiados) pero que no tienen reaccin alguna con otros sectores. Son
servicios estancos y autocontenidos.
Llegados a este punto, no tena mucho sentido mantener estos proyectos
desarrollndose de forma autnoma e independiente. El siguiente paso lgico era aplicar
el intercambio electrnico de datos a sectores horizontales, es decir, sectores de
actividad que interaccionan con el resto, abriendo as las puertas al intercambio
electrnico de datos a las relaciones intersectoriales.
Bajo esta idea surgieron los Proyectos de EDI Financiero, EDI transporte y EDI en
la administracin pblica.
Pgina 67
4.6.1.1 EDI Local

El proyecto EDI-Local surgi a iniciativa de la Federacin Espaola de
Municipios y Provincias (FEMP) y Telefnica, con el apoyo del Fondeo Europeo de
Desarrollo Regional. El objetivo era poner en marcha un procedimiento de intercambio
electrnico de documentos y de dados a travs de redes de telecomunicacin.
El sistema EDI est teniendo una gran incidencia en el proceso de
modernizacin de las Administraciones Pblicas y, ms concretamente, en la mejora de
la gestin de las Corporaciones Locales, facilitando la modernizacin de las relaciones
con los ciudadanos y las empresas. Esta situacin viene avalada por diversas decisiones
de la Comisin Europea y por la nueva Ley de Rgimen Jurdico de las
Administraciones Pblicas y del Procedimiento Administrativo Comn que establecen
la posibilidad, cuando no la necesidad, de la utilizacin de este tipo de servicios
telemticos.
Hay que destacar la revitalizacin que EDI-Local ha supuesto, desde el punto de
vista de su nivel de desarrollo tecnolgico, no solamente a las Corporaciones Locales
participantes, sino tambin a las 391 PYMES incluidas en el proyecto de todos los
sectores de actividad empresarial. Han mejorado sus relaciones comerciales y
administrativas, en unos casos incrementando su grado de especializacin y en otros
creando nuevas reas de negocio. Todo ello las har ms competitivas en el entorno
comunitario y redundar, con toda seguridad, en la creacin de nuevos puestos de
trabajo.
El proyecto se inici en Abril de 1994, con la firma del acuerdo que regula la
participacin tcnica y financiera de le FEMP y de Telefnica en el desarrollo del
proyecto de implantacin del sistema EDI en la administracin local. Este proyecto
forma parte del programa de desarrollo del convenio Marco de Cooperacin firmado por
los Presidentes de ambas entidades el mes de Septiembre de 1993.
La FEMP ha coordinado la integracin de las corporaciones locales interesadas
en el proyecto y deleg en TACSA la relacin de tareas y aspectos ms tcnicos.
Telefnica, rgano gestor del proyecto ante el FEDER, ha delegado las tareas que le
corresponden en TSAI, empresa del Grupo Telefnica.
En definitiva, la fase piloto del proyecto EDI-Local ha permitido, por un lado,
abordar con solvencia tecnolgica un mejor aprovechamiento de las tecnologas de la
informacin al servicio de una renovacin de la gestin muy necesaria en momentos
como los actuales, marcados por las inevitables dificultades presupuestarias. Por otro
lado, se han sentado las bases que permiten plantearse desde este momento la extensin
del proyecto en dos niveles:
Territorial: Dando acceso a EDI-Local a todas aquellas corporaciones locales
interesadas y que, por estar ubicadas fuera de las zonas FEDER que sealaba el
proyecto, no tuvieron acceso al mismo. Tambin tendrn cabida aquellas CCLL que,
perteneciendo a zonas FEDER, no pudieron incorporarse por estar superando el nmero
mximo que el proyecto determina.
Pgina 68
Documental: Una vez han entrado en funcionamiento, los primeros documentos

son: pedidos, facturas recaudacin y afiliacin de la seguridad social. Y estn en
pruebas orden de pago simple, orden de pago, orden de cargo, aviso de abono.
Segn parece se pretende ampliar su nmero, integrando aquellos que, de
acuerdo con el grupo de trabajo de usuarios de CCLL y la Comisin de Informtica de
la FEMP, se han considerado como estratgicos para el buen fin del proyecto.
4.6.1.2
EDI transporte
El proyecto COMPAS surge en Abril de 1993 por iniciativa de la Agencia

Tributaria y Puertos del Estado con el fin de mejorar la calidad de sus servicios
asociados al trfico de las mercancas a travs de la aduana.
El sistema COMPAS (Comunicacin de Manifiestos a Puertos y Aduanas) contempla la
conexin de los operadores a travs de una red de valor aadido y su misin
fundamental es regir el intercambio electrnico de los documentos empleados en:
Comunicacin de manifiestos entre consignatarios y puertos y entre stos y la
Administracin Aduanera.
El despacho de Aduanas establecido entre Agentes de Aduanas y la
Administracin.
Caractersticas
COMPAS es un sistema nico, modular, gratuito, opcional, abierto y basado en
estndares.
nico: El sistema es nico para el trfico a travs de cualquier recinto del
territorio nacional.
Modular: La administracin aduanera recibe a travs de este sistema
informacin relativa a manifiestos, a declaraciones y otros documentos de
solicitud de operaciones y destinos aduaneros.
Gratuito: La administracin aduanera ofrece gratuitamente el servicio a los
interesados y Puertos de Estado recibe sus tarifas a las usuarios en los trminos
de la Orden del 13 de Abril de 1993.
Abierto: La administracin no exige requisito alguno de hardware o software,
bastando que el operador disponga de los medios para entregar y recibir los
mensajes en una de las redes de valor aadidos seleccionadas.
Basado en estndares: Entre las diversas opciones EDI se han elegido mensajes
estndares EDIFACT.
Colectivos involucrados
Los tipos de empresa que participan en las tareas logsticas se pueden sintetizar
de la siguiente forma:
o
Transitorios.
Operadores
logsticos
contratados
por
los
exportadores/importadores y que por medios propios o subcontratando
terceras empresas se encargan de transportar la mercanca desde el origen
al destino.
Pgina 69
Consignatarios. Es el responsable de disponer la mercanca en el puerto

en condiciones de embarque (empaquetada, paletizada o contenedorizada
y etiquetada).
Agentes de aduanas. Empresas que se encargan de realizar los trmites
administrativos, principalmente en lo que se refiere a liquidaciones de
impuestos y aduanas.
Entidades y organismos pblicos:
Autoridades portuarios y aeroportuarias
Aduanas
Consejera de Economa y Hacienda
Las relaciones se podrn esquematizar de la forma siguiente:

o
o
El importador/exportador contrata los servicios de una empresa

transitoria.
La empresa transitoria puede asumir a su vez el papel de agente de
aduanas y de consignatario o bien subcontratar estos servicios a terceras
personas.
El consignatario acordar con la naviera, armador o con la compaa
area el transporte de la mercanca y presentar la Declaracin Sumaria
de la Mercanca (manifiesto) a la Autoridad Portuaria.
El agente de aduanas tramita las declaraciones de impuestos (DUAS), a
la agencia Tributaria Central (a travs de la Aduana).
Documentos utilizados
IFCSUM o manifiesto. Definido por Puertos del Estado, actualmente est en
vigor el Manifiesto de Importacin (Declaracin Sumaria de Descarga) en su
versin EPPE21. El manifiesto de exportacin (Declaracin Sumaria de Carga)
tiene definida su correspondiente versin EDIFACT, aunque no ha alcanzado
todava un estado definitivo ni ha comenzado a utilizarse.
CUSDEC o DUA (Documento nico Administrativo) Definido por la Aduana
Espaola, actualmente su variante DUA EXPORT se encuentra en su versin 1.1
y estable. Utilizada en mayor grado que el manifiesto. El DUA IMPORT no se h
implantado todava. La Agencia Tributaria ha preparado ya una primera versin
aunque todava se encuentra en pruebas. La Agencia Tributaria piensa pasarlo a
produccin en 1997.
CUSCAR/CUSREP. Mensajes enviados por el puerto a la Aduana. Contienen
la misma informacin del mensaje IFCSUM, pero desglosa en dos mensajes
independientes.
CUSRES. Todos los mensajes anteriores reciben este mensaje de respuesta del
destinatario e indica el resultado de la validacin del mensaje original e
informacin adicional de respuesta.
Pgina 70
4.6.1.3
EDI FINANCIERO
Descripcin general
El concepto de EDI Financiero engloba dos acepciones distintas:
o
El intercambio electrnico de datos entre entidades financieras, para

comunicacin de efectos financieros truncados y en general para la
transmisin electrnica de fondos (denominado generalmente EFT,
Electronic Funds Transfer).
El intercambio electrnico de datos entre las entidades financieras y sus
clientes, para la realizacin de operaciones bancarias de forma remota, y
la comunicacin del estado de cuenta.
Estas acepciones, por otro lado, son dependientes entre s, ya que carecera
de sentido un intercambio electrnico de informacin entre las entidades
bancarias con sus clientes si no existiese previamente una va de comunicacin
de
las
entidades
bancarias
entre
s.
En realidad la distincin entre EDI y EFT, es muy difusa, ya que ambas
acepciones responden a la ida de la utilizacin del EDI para la transmisin
telemtica de informacin que implica transferencias monetarias y es por ello
por lo que nos referimos al EDI financiero en este sentido amplio.
La importancia del EDI financiero cobra cada vez un mayor peso especfico
por la doble funcin que cubre su utilizacin.
Por un lado, supone un instrumento idneo para el intercambio de
informacin de contenido econmico y obviamente de importancia crtica para
los
interlocutores
del
sistema.
Por otra parte, implica la finalizacin del denominado cierre comercial,
permitiendo a los usuarios de un servicio EDI agrupar en un nico canal todo
tipo de intercambios de informacin asociados a la operativa del negocio
(pedidos, facturas, albaranes, contratos..) incorporando al sistema el circuito de
cobros y pagos de la entidad o empresa utilizadora.
MENSAJES EDIFACT FINANCIEROS

Las familias de Mensajes Financieros contempladas en EDIFACT son las
siguientes:
o
o
o
o
o
o
o
o
o
o
Contabilidad
Informacin de balanza de pagos
Empresa a empresa
Banco a banco
Pagos
Adeudo directo
Informacin financiera
Crditos documentarios
Cobro documentario
Factoring
Pgina 71
Servicios y seguridad
A continuacin se presenta un glosario con los mensajes para EDI

financiero, as como el estatus en el que se encuentra cada mensaje.
GLOSARIO DE MENSAJES FINANCIEROS EDIFACT

AUTHOR
BANSTA
BOPBNK
BOPDIR
BOPINF
BOPSTA
COLADV
COLREQ
CREADV
CREEXT
CREMUL
DEBADV
DEBMUL
DIRDEB
DOCAMA
DOCAMD
DOCAMI
DOCAMR
DOCAPP
DOCARE
DOCINF
DOCISD
DOCTRD
FINCAN
PAYDUC
PAYEXT
PAYMUL
PAYORD
RECECO
REMADV
(1)
(1)
(1)
(1)
(1)
(0)
(0)
(0)
(2)
(2)
(1)
(2)
(1)
(1)
(1)
(0)
(1)
(1)
(1)
(1)
(1)
(0)
(0)
(1)
(2)
(2)
(1)
(2)
(1)
(2)
Authorisation Message
Banking Service Message
Reporting of de Balance of Payment Transaction
Direct Balance of Payment Declaration
Balance of Payment Information from Customer
Exchange of de Balance of Payment Statistics
Advice of documentary Collection
Request for Documentary Collection
Credit Advice Message
Extended Credit Advice Message
Multiple Devid Advice
Debit Advice Message
Multiple Debit Advice Message
Direct Debit Message
Advise of an Amendment of a Documentary Credit
Direct Amendment of a Documentary Credit
Documentary Credit Amendment of a Documentary
Request for an Amendment of a Documentary Credit
Documentary Credit Application
Response to an Amendment of a Documentary Credit
Documentay Credit Issuance Information
Direct Documentary Credit Issuance
Transfer of Documentary Credit
Financial Statement
Payroll Deduction Advice Message
Extended Payment Advice Message
Multiple Payment Order Message
Payment Order Message
Credit Risk Cover Message
Remittance Advice Message
Los mensajes mas utilizados son los referentes a pagos, concretamente los
siguientes:
Mensajes Edifact en PAGOS
Pgina 72
CREADV
CREEXT
DEBADV
PAYORD
PAYEXT
REMADV
PAYMUL
CREMUL
DEBMUL
4.6.1.4
(2) Aviso de abono

(2) Aviso de abono extendido
(2) Aviso de dbito
(2) Orden de pago
(2) Orden de pago extendida
(2) Liquidacin
(1) Orden de pago mltiple
(1) Aviso de abono mltiple
(1) Aviso de Dbito Mltiple
EDI FINANCIERO EN ESPAA
Aspectos histricos
El EDI financiero, en lo esencial de su concepto, lleva muchos aos
funcionando en Espaa si bien, los formatos utilizados en la definicin de los
mensajes no estaban basados en el estndar UN/EDIFACT.
En Espaa han sido los formatos definidos en los denominados
"Cuadernos del Consejo Superior Bancario" los que se han utilizado, primero
como registros de soporte magntico (cintas de pulgada de anchura, de 9
pistas y densidad de 1600 o de 6250 bits por pulgada) y mas recientemente con
sistema de transmisin conectados a la entidad financiera.
Teniendo en cuenta que los formatos EDIFACT han estado disponibles
con mucha posterioridad a la propia puesta en marcha del sistema de
compensacin, haba que resolver la necesidad cuando esta se produjo.
Inicialmente la puesta en marcha del EDI financiero se contempl como
una forma de reducir drsticamente la manipulacin de documentos que se
produca en las cmaras de compensacin.
Simplificadamente, la forma de funcionar de las cmaras de compensacin en la
poca en la que se viola necesidad de su automatizacin era siguiente:
22. El departamento de Cmara de cada banco (uno por cada plaza capital de
provincia en la que el banco tuviera presencia) reciba los documentos de
toda provincia (letras, cheques, pagars, ..) y los clasificaba manualmente
por tipo de documento, plaza, importe y entidad.
23. Los documentos se agrupaban en bloques, que se proceda a sumar por
duplicado.
24. Se disponan en cajas y se transportaban al edificio de la Cmara de la
Provincia, por un lado, y a los departamentos centrales del banco por
otro.
25. En la Cmara, se comprobaban los bloques, y se repartan a cada banco
los destinados a l, que fueran de la misma plaza (o provincia), y los que
Pgina 73
fueran destinados fuera de la provincia, se transportaban a Madrid, donde

se haca la reclasificacin por provincias.
En el retorno, se volvan a clasificar los documentos por sucursales para
envo a stas, que precisaban del efecto para su comunicacin al librador.
De este sistema de reparto surgi el esquema de comisiones que se aplica a
la negociacin de efectos por el banco:
o
o
o
o
De la misma entidad y de la misma plaza

De la misma entidad y de distinta plaza
De distinta entidad y de la misma plaza
De distinta entidad y de distinta plaza
Todo este trabajo conlleva la manipulacin de grandes cantidades de papel

durante todas las noches con una tasa de errores que, aunque baja debido al
nmero de controles, tena un alto nivel de incidencia debido a que cada uno de
los documentos manipulados representaba dinero.
Debido a esto, algunos bancos (inicialmente Hispano y Santander) se
plantearon un acuerdo de confianza mutua, en base al cual se comunicaran los
datos de los efectos a travs de soporte magntico (cinta de pulgada).
Considerando que eran grandes entidades con un elevado nmero de
documentos destinados de una a la otra, esto reducira la manipulacin de papel
a aquellas entidades no integradas en el acuerdo, lo cual redundara en ltima
instancia en una menor manipulacin de papel en conjunto.
El acuerdo limitaba el importe mximo de los documentados que se
procesaran por esa va 500.000 Ptas. (Posteriormente este lmite se ha ido
aumentando), dejando el resto de documentos para el circuito normal en el que
viaja el papel, de forma que el riesgo asumiendo, en caso incidencia, fuera
mnimo y menor que el coste del proceso manual que se sustitua.
En lugar del documento original, el banco destinatario generaba un
documento justificativo con los datos del original, y el depositario del
documento se hacia responsable de l, para el caso de que se detectara alguna
incidencia.
Debido a que se truncaba el trayecto de los documentos, a este sistema se le
denomina truncamiento y ha atravesado varios etapas hasta llegar al actual
Sistema Nacional de Compensacin Electrnica, pasando por momentos en los
que se intercambiaban cintas magnticas y otros en los que se llegaba a la
interconexin de ordenadores de determinadas entidades.
4.6.1.5
EVOLUCIN DEL EDI FINANCIERO
Respondiendo al inters de la comunidad bancaria espaola por el

desarrollo del EDI, a principios de 1990 se constituy una ponencia EDI en el
seno del Consejo Superior Bancario con el objeto de mantener informados a los
bancos sobre los distintos esfuerzos desarrollados internacionalmente.
Pgina 74
Por otro lado SWIFT (Society For Wordwide Interbank Financial

Telecomunication S.C.) inici a mediados de 1991 un proyecto piloto (que fue
ampliando paulatinamente) para utilizar mensajes EDIFACT con aquellas
entidades que lo solicitarn.
Desde entonces se fueron realizando avances informativos y de
seguimiento de los grupos financieros europeos que trabajan sobre EDIFACT,
poniendo nfasis en la normalizacin de crditos documentarios. Toda esta
informacin se pona a disposicin de los miembros del Consejo Superior
Bancario.
De entre los bancos espaoles, BBV fue el primero en implementar,
mediante desarrollos propios, una cierta funcionalidad EDI para sus usuarios de
Cash Management que accedieron a participar en las pruebas piloto.
En esta fase, los mensajes que se consideraron mas interesantes fueron
los de modalidad extendida (Extended Payment Order, y los correspondientes
Debid y Credit Advice). Con indicacin de los conceptos incluidos en el pago.
Una aportacin digna de mencin, es la posibilidad que se dio a los
usuarios de generar un documento en papel (que se denomin Abonar), para
permitir el pago a plazo y que, aunque en principio slo era negociable si se
presentaba en oficinas del BBV, se empez a presentar por la va de las Cmaras
de Compensacin, provocando un cierto desconcierto inicial.
Posiblemente, este avance se acabe incorporando oficialmente a la
relacin de documentos compensables por cmara e incluso por SNCE (de
forma semejante a los pagars). La gran ventaja que aporta es que permite que
los ordenanzas que ya trabajan mediante EDI puedan realizar pagos
independientemente de que los beneficiarios los gestionen tambin mediante
EDI, o a travs de documentos de papel. Esto dar un gran impulso al EDI
financiero.
Con cierta anticipacin, incluso a la iniciativa del BBV, la Caja de
Ahorros de la Inmaculada puso en marcha en Zaragoza en 1992 un servicio EDI,
en el que se baja el Cash Management que ofrece a sus clientes. Esta iniciativa,
impulsada por el gobierno autnomo aragons y acogida por compaas como
General Motors, fue desarrollada por la firma ISV con infraestructura de red de
IBM.
Durante 1993, un trabajo conjunto entre TSAI ( Telefnica Servicios
Avanzados de Informacin), AECOC (Asociacin Espaola de Codificacin
Comercial) y Banesto (Banco Espaol de Crdito) concluy en la primera
propuesta pblica de gua de implantacin de un mensaje EDIFACT financiero:
el PAYORD y un flujo de mensajes diseado para facilitar el pago aplazado y la
financiacin de los beneficiarios en base a este documento electrnico.
En diciembre de 1993 se constituy a iniciativa de la Confederacin
Espaola de Cajas de Ahorro un grupo de trabajo de entidades de Depsito, en el
que participaban Bancos y Cajas y que utiliz como documento inicial el
Pgina 75
PAYORD anterior. Este grupo se integr posteriormente, a principios de 1994

en la ponencia EDI del Consejo Superior Bancario.
Por estas fechas el Consejo Superior Bancario desapareci como tal y
pas a formar parte de la Asociacin Espaola de Banca, pero el grupo de
trabajo se mantuvo.
Entre los nuevos objetivos del grupo de trabajo estaban el de colaborar
con las asociaciones que ya estuvieran auspiciando iniciativas de EDI
(inicialmente ODETTE en el sector de la Automocin y AECOC en el sector de
la distribucin), y de unificar todos los esfuerzos de definicin de las guas de
implantacin de los mensajes de EDI financiero, de forma que sean los mismo
con independencia del sector o del prestatario del Servicio EDI contratado.
El grupo ha mantenido reuniones frecuentes y ha participado en las que
se celebran en ODETTE y en AECOC, a las que tambin se han incorporado
miembros de ASSET (Asociacin Espaola de Tesoreros), por lo que se puede
decir que la definicin de las gua de implantacin ha incorporado la mayor
parte de las aspiraciones de los usuarios.
El primer resultado del grupo de trabajo han sido las guas de
implantacin de los mensajes PAYORD, para pagos nacionales, a la vista ,
CREADV y DEBADV.
Tambin se est dando mucha prioridad a los mensajes FINSTA
(Financial Statement) para incluir una informacin de los movimientos de la
cuenta ms amplia que la que proporciona la norma 43 de CSB y DIRDEB para
facilitar los adeudos por domiciliaciones, tema en el Espaa est muy adelantada
respecto a otros pases.
Los trabajos tienen una amplia repercusin, ya que en algunos caso
simplifican la modificacin de mensajes interbancarios que viajan a travs del
SNCE, por lo que necesariamente su implantacin ser gradual.
4.6.1.6
EDI FARMACIA
Como ya adelantamos el servicio de EDI Farmacia es un proyecto por

Farmindustria y Feditar para el intercambio electrnico de documentos entre
laboratorios farmacuticos y mayoristas de farmacia.
El servicio est operado y explotado comercialmente por Telefnica
Servicios Avanzados de Informacin, 100% filial de Telefnica.
El contrato de explotacin del servicio fue firmado por las tres partes en
Julio de 1993, y durante el periodo de septiembre diciembre del mismo ao, se
acometieron las acciones de seleccin de herramientas (infraestructura, hardware
y software) y de definicin y estandarizacin de los documentos para la puesta
en marcha del Servicio.
Pgina 76
La fase de prueba piloto, indispensable en la implantacin de un servicio

como EDI, se extendi durante el periodo Enero-Mayo de 1994, y cont con la
participacin, adems de Farmaindustria , Feditar, de los siguientes laboratorios
y mayoristas:
Laboratorios: Boehringer Manheim, Bristol Myers, Ciba Geigy, Laboratorios
Almiral, Lilly, Cynamid Ibrica.
Mayoristas: Centro Farmacutico,
Farmacutica del Mediterrneo, SAFA.
Cofares,
Farmacen,
Hermandad
El lanzamiento comercial del servicio fue en Junio de 1994 y los documentos

que se incorporaron al servicio fueron la Factura y el Pedido.
4.6.1.7
EDI SANIDAD
El sector de la sanidad es especialmente indicado para la implantacin de un

servicio de intercambio electrnico de documentos, debido a la ingente cantidad de
documentos
que
intercambian
los
diferentes
agentes
del
sector.
Las estadsticas del sector sanitario de la Comunidad Europea describen un sector muy
desarrollado. Representa entre el 5% y el 10% del PIB de la Unin Europea, y e nmero
de hospitales asciende a 15.000, ms de 3 millones de camas hospitalarias y
aproximadamente 300.000 mdicos, en toda la Unin Europa.
En Francia, por ejemplo, se procesan alrededor de 840 billones de documentos
en papel por cerca de 200.000 ordenadores anualmente. Y anualmente se intercambian
cerca de 404 millones de documentos en forma de recetas, anlisis clnicos, etc..
En Estados Unidos, de acuerdo con un informe elaborado por Arthur D. Little, se ha
calculado una cifra de ahorro de 36.000 billones de dlares que resultara de la
aplicacin de soluciones tecnolgicas y telemticos en el sector sanitario.
En cuanto a las reas de utilizacin del servicio EDI en la sanidad, distinguimos:
o
o
Suministro hospitalario. Proveedores en general y Suministradores

clnicos y farmacuticos.
Aplicaciones Mdicas: Peticiones y resultados de anlisis clnicos entre
hospitales y laboratorios. Transmisin de recetas de los mdicos a las
farmacias, Solicitud y resultados de exploraciones clnicas (rayos X) y
transmisin de imgenes, historias clnicas, mensajes de frmacovigilancia.
Administrativa: Registro y alta de pacientes, Procesamientos de gestin
de listas de espera, reembolso y facturacin con administraciones
pblicas y entidades aseguradoras privadas.
EDI en la distribucin (AECOM)

AECOC es la asociacin espaola de codificacin que cuenta con mas de 10.000
asociados relacionados con el sector distribucin. Basndose en el estndar EDIFACT,
han definido un subestndar propietario, AECOM, para el intercambio de sus
Pgina 77
documentos. Actualmente se intercambias la factura y el

El servicio EDI se ha extendido a aproximadamente 1.000 de sus asociados.
pedido.
Pgina 78
CAP. 5
ESTNDARES
5.
Estndares
En el mundo del Intercambio Electrnico de Datos, y en el de las

comunicaciones en general, existen multitud de estndares y normativas relativas a
protocolos de comunicaciones, a implantacin y funcionamiento de servicios, estructura
y sintaxis de los documentos electrnicos, etc.
La necesidad de que existan unos marcos de referencia en cuanto a la normativa
viene impuesta por la globosidad y conectividad de los sistemas. Si se quiere tener una
infraestructura de telecomunicacin a nivel mundial, es imprescindible que todos y cada
uno de los elementos que la integran (ordenadores, servidores) hablen un mismo
lenguaje.
De las normativas que afectan al intercambio electrnico de datos, destacamos:
Normativas relativas a la sintaxis de los documentos: EDIFACT ANSI X.12
Normativas de comunicaciones: EDIFACT ANSI X.12
A continuacin, se describen estos estndares, prestando especial atencin al
estndar EDIFACT por su amplia difusin en el EDI.
5.
EDIFACT
EDIFACT surge en 1986 como iniciativa de las Naciones Unidas para agrupar
los dos principales estndares entonces existentes: ANSI X12 en Estados Unidos y
GDTI en Europa y establecer grupos de trabajo con objetivos comunes.
UN/EDIFACT se define como el conjunto de reglas de las Naciones Unidad
aplicables al Intercambio Electrnico de Datos en la Administracin, comercio y
Transporte. Este conjunto de reglas incluye:
Conjunto de caracteres: repertorio de caracteres (y su representacin
codificada) que pueden utilizarse en la informacin a intercambiar.
Estructura del intercambio: representa una estructura jerrquica que muestra
los componentes (segmentos de servicio y segmentos de datos de usuario), y la
relacin entre los mismos, de un intercambio.
Compresin de Datos: reglas que regulan la supresin de caracteres no
significativos.
Tcnicas de repeticin: reglas que controlan la repeticin de segmentos de
datos y elementos de datos en los mensajes.
Tcnicas de anidamiento: reglas que definen cmo expresar la dependencia
entre los segmentos de datos pertenecientes a los diferentes niveles jerrquicos
de un mensaje.
Representacin de los valores numricos de los elementos de datos.
Explicacin de las definiciones.
Pgina 79
Especificaciones de los segmentos de servicio.

Descripcin de los diagramas de mensajes
5.1.1
Visin histrica
La norma EDIFACT es el logro de normalizacin de un largo nmero de aos

trabajando sobre la idea de estandarizar EDI a nivel mundial.
Se comenz a trabajar en 1960 sobre manuales preparados a mano. Los primeros
trabajos informatizados datan de 1970, cuando las Naciones Unidas organiz el grupo
de trabajo 4 UN/ECE para trabajar sobre los procedimientos del comercio internacional.
Este grupo organiz dos comisiones para desarrollar los estndares. Suecia fue
responsable de definir la estructura y el contenido. Inglaterra desarroll la sintaxis.
Estos trabajos condujeron a la publicacin del Trade Data Element Directory (TDED) y
el Trade Data Interchange Directory (TDID) en 1981.
En 1985 las Naciones Unidas declararon estos directorios los estndares para el
comercio mundial. Esto provoc gran preocupacin debido a que no son compatibles
con el estndar X.12, ms desarrollado en ese momento. Seguidamente se form la
comisin Electronic. Data Interchange for Administration, Commerce and Transport
Commitee (EDIFACT).
La gua preliminar de diseo de mensajes se desarroll en 1987 y se remiti las
reglas sintcticas de EDIFACT a la ISO (International Standard Organitation).
Tambin en 1987 la UN/ECE reuni a expertos y representantes de Norte
Amrica, Europa Occidental y del Este. ISO aprob la sintaxis EDIFACT tambin en
1987 y se empez a utilizar el modelo de factura como prueba.
Al ao siguiente se introdujo el modelo de peticin de compra.
5.1.2
Sintaxis de EDIFACT
Se denomina sintaxis al conjunto sistemtico de reglas que gobiernan la

construccin de frmulas correctas en su sistema lgico.
En este mbito la sintaxis EDIFACT proporciona un conjunto de reglas
mediante las cuales el receptor de un mensaje es capaz de descodificar los datos que
contiene: nombres de segmentos y elementos de datos contenidos en el mensaje.
La conexin depende del mecanismo de comunicacin seleccionado para el
intercambio, y no forma parte de la norma. Una conexin puede contener uno o ms
intercambios.
Un intercambio consta de grupos funcionales de mensajes (grupos de mensajes
del mismo tipo) o de mensajes. El agrupamiento funcional puede utilizarse para dividir
el lote de mensajes en subconjuntos, cada uno de los cuales puede dirigirse a un
determinado departamento del sistema de informacin del destinatario. La utilizacin de
grupos funcionales es opcional. UNA, UNB y UNZ son segmentos de servicio que
proporcionan informacin adicional, externa a los mensajes, relativa al intercambio. Por
ejemplo, UNB es la cabecera del intercambio y contiene detalles esenciales, como las
Pgina 80
reglas de sintaxis y conjuntos de caracteres utilizados en el mensaje, identificacin del

emisor y destinatario previsto, y la referencia unvoca de intercambio asignada por el
emisor.
Un mensaje consta de datos particulares que cumplen funciones comerciales especficas
(rdenes de compra, acuses de recibo, instrucciones de embarque, facturas, etc.). UNH y
UNT son los segmentos de servicio que soportan el mensaje mediante un nmero de
referencia, un identificador de mensaje, etc. Cada mensaje contiene una secuencia de
segmentos de datos que cumplen un requisito funcional especifico (nombre y direccin,
medida, detalles del producto, fecha y hora, etc.).
Cada segmento de datos consta de elementos de datos compuestos y/o de

elementos de datos simples. Los elementos de datos identifican un tem o campo de
datos individual (cdigo postal, precio unitario, moneda, etc.). Los elementos de datos
compuestos estn formados por una combinacin de dos o ms elementos de datos
bsicos. Por ejemplo, un importe en moneda est compuesto de los elementos de datos
bsicos "cantidad" y "moneda" (divisa).
Una etiqueta de segmento contiene un cdigo de segmento (tal como aparece en
el directorio de segmentos -EDSD) y un valor de repeticin/anidamiento que expresa la
repeticin y la posicin del segmento dentro de una estructura jerrquica.
5.1.3
Mensajes y Directorios de Soporte UN/EDIFACT
El "UN/ECE - Directorio de Intercambios de Datos Comerciales de las Naciones

Unidas (UNTDID)" proporciona un amplio soporte para la interpretacin, comprensin
y utilizacin de los Mensajes Normalizados por las Naciones Unidas (UNSMS). La
Parte 5 del directorio UNTDID incluye todos los mensajes UNSMS modificados, no
Pgina 81
modificados y nuevos, as como sus directorios de soporte, aprobados por la Comisin

UN/ECE para uso pblico. Peridicamente, se vuelven a publicar nuevos nmeros de
todos los captulos de la Parte 5.
5.1.4
Mensajes
Los mensajes normalizados UN/EDIFACT son desarrollados y mantenidos por

la UN/ECE. Los mensajes UNSMS son publicados en un directorio especfico del
UNTDID (Parte 5, Captulo 2), denominado "Directorio UN/EDIFACT de UNSMS
(EDMD)". Los UNSMS se especifican de acuerdo con las "reglas de aplicacin de la
sintaxis - EDIFACT", y se refieren al contenido y estructura de la informacin
administrativa, comercial o de transporte a intercambiar entre organizaciones, tanto para
usos nacionales como internacionales. Un mensaje se identifica unvocamente por su
tipo, versin y nmero de publicacin. Los nmeros de publicacin de los directorios se
publican peridicamente.
Hasta 1992 (inclusive), un directorio se identificaba utilizando las dos ltimas cifras
del ao de su publicacin junto a un nmero adicional que era:
1, si contena tipos de mensajes de prueba.
2, si contena mensajes UNSMS;
Desde 1993, los directorios UN/EDIFACT se identifican de forma diferente. Por
ejemplo, D.93A es el directorio borrador y S.93A es el directorio normalizado (contiene
mensajes normalizados o de categora 2). La ltima letra (A en el primer caso) indica el
nmero de publicacin dentro del ao. Las letras que siguen (B, C,...) se utilizarn para
indicar las publicaciones siguientes.
5.1.5
Directorios de informacin
Un directorio de informacin EDIFACT (UNTDID: United Nations Trade Data

Directory) consiste en un conjunto de reglas que abarcan los siguientes aspectos:
Reglas sintcticas EDIFACT acordes a la normativa IS0 9735.
Guas de diseo de mensajes. Normas estndar a aplicar en diseo de cualquier
nuevo documento EDIFACT:
Directorio de elementos de Datos
Directorio de listas de cdigos
Directorio de Elementos de Datos Compuestos
Directorio de segmentos
Directorio de mensajes
Reglas uniformes de conducta en el intercambio de datos comerciales
Diverso material explicativo
Elementos de Datos Compuestos
Pgina 82
Los elementos de datos compuestos aparecen recogidos en otro directorio del

UNTDID (Parte 5, Capitulo 4) denominado "Directorio de Elementos de Datos
Compuestos UN/EDIFACT (EDCD)" .
Elementos de Datos
Los elementos de datos contenidos en los segmentos de servicio (series 0xxx) se
definen en ISO 9735 Anexo B; el directorio de referencia de todos los dems
elementos de datos es el "Directorio de Elementos de Datos UN/EDIFACT
(EDED)" del UNTDID (Parte 5, Captulo 5). El EDED es un subconjunto del
"Directorio de Elementos de Datos Comerciales de las Naciones Unidas
(UNTDID)". La parte del directorio UNTDED correspondiente a los elementos
de datos se ha convertido en la norma IS0 7372, adoptada posteriormente como
Norma Europea en 27372.
Lista de Cdigos
La UN/ECE mantiene una lista de todos los conjuntos de cdigos asociados a los
elementos de datos codificados en el "Directorio de Listas de Cdigos
UN/EDIFACT (EDCL)", que forma parte del directorio UNTDID (Parte 5,
Captulo 6).
Directrices de Diseo de Mensajes
Las "directrices de diseo de mensajes UN/EDIFACT" es la parte del directorio
UNTDID pensada para ayudar a los desarrolladores y diseadores de mensajes
EDIFACT. Tambin resulta til para comprender mejor la estructura de los
mensajes. Se recomienda que el contratista consulte este documento cuando
necesite ayuda o informacin adicional sobre los siguientes temas:
o
Para sugerir cambios en los mensajes normalizados, segmentos,

elementos de datos y cdigos ya existentes; o para presentar el borrador
de un mensaje para su registro como nuevo UNSM
Para disear un mensaje (no necesariamente para que llegue a ser un
mensaje UNSMS).
Las reas cubiertas por estas directrices son:

o
o
o
o
o
Visin de conjunto del Diseo de Mensajes - Directrices Generales;

Anlisis de los Elementos de Datos;
Estructura de los Segmentos;
Estructura de los Mensajes;
Equipos Consultivos y de Soporte.
Mantenimiento de Mensajes y Directorios de Soporte
La gran variedad de versiones/publicaciones de mensajes y el mantenimiento de
los directorios de soporte puede dar lugar a diferentes problemas de
interoperabilidad. UN/ECE ha publicado, con el nmero de referencia
TRADE/WP.4/R.601, un documento que establece reglas para la identificacin
Pgina 83
y control de mensajes UN/EDIFACT. Las enmiendas correspondientes al mismo

han sido publicadas en el documento TRADE/WP.4/R.720
Actualmente, mientras que los mensajes UNSMS estn definidos, validados y
registrados en el documento UN/ECE wp.4/ge.l, los subconjuntos de un UNSMS
y los mensajes EDI EDIFACT no estn respaldados por Autoridades de Registro
europeas o internacionales. Ello supone que estos mensajes EDI pueden soportar
contenidos y procedimientos locales.
En lo que se refiere a los cdigos, si bien se dispone de directorios especficos
para cada sector, no existe una estructura unificada de los mismos. Esta
situacin puede provocar problemas de interoperabilidad entre las diferentes
comunidades EDI.
5.1.6
Elaboracin de Subconjuntos de Mensajes
El documento directrices de implementacin de la sintaxis EDIFACT del directorio

UNTDID (Seccin 7.2) define y proporciona al usuario normas para la implementacin
de subconjuntos de un UNSMS. Para que puedan tener en cuenta los diferentes
requisitos comerciales, los mensajes y directorios de soporte EDIFACT se definen de
una forma totalmente general. Como consecuencia de ello, y con objeto de simplificar
las opciones permitidas en las normas, es necesario aplicar a los mensajes y directorios
un conjunto de restricciones. Bsicamente, las reas en las que hay que aplicar
restricciones se refieren a:
Grupos opcionales, segmentos y elementos de datos de los mensajes
normalizados;
Formatos alternativos permitidos para representar algunos datos.
No se ha identificado ningn perfil, por lo que la nica forma de tratar este problema
es mediante la utilizacin de convenios.
5.1.7
Reglas sintcticas EDIFACT
La normativa que define la estructura sintctica de los mensajes EDIFACT se

encuentra contenida en el estndar IS0 9735:
Conjunto de caracteres
Para codificar la informacin contenida dentro de los elementos de datos del
intercambio EDIFACT se pueden utilizar seis conjuntos de caracteres diferentes.
El repertorio de caracteres viene indicado en el segmento cabecera de
intercambio (UNB) incluido en el elemento de datos ldentificador de Sintaxis
s001. Los seis repertorios han sido seleccionados para aplicarse a los diferentes
requisitos de usuario en lo relativo a la representacin de datos:
o
UNOA (para el nivel bsico A) corresponde a ISO-9735 Nivel A,

alfabeto bsico del telex; incluye letras (slo maysculas), nmeros, y
algunos signos de puntuacin;
Pgina 84
UNOB (para el nivel B) corresponde a 150-9735 Nivel B; amplia UNOA

con letras minusculas y ms signos de puntuacin.
Los repertorios restantes se aplican en la codificacin de las lenguas nacionales:

o
UNOC para nivel C) corresponde a ISO 8859-1 alfabeto Latino N 1

(IS0-IR 100); soporta la mayora de las lenguas de Europa Occidental:
dans, ingls, finlands, francs, alemn, islands, irlands, italiano,
noruego, portugus, espaol, sueco, y el hablado en las Islas Faroes;
UNOD (para nivel D) corresponde a ISO 8859-2, alfabeto Latino N0 2
(ISO-IR 101); soporta el ingls y la mayora de los idiomas de Europa
Oriental: albans, checo, hngaro, polaco, rumano, serbo-croata,
eslovaco y esloveno;
UNGE (para nivel E) corresponde a ISO 8859-5, alfabeto Latino/Cirlico
(ISO-IR 144), soporta el ingls y los idiomas de Europa Oriental con
representacin cirlica: blgaro,bielorruso, macedonio, ruso, serbocroata, ucraniano.
UNOF (para nivel F) corresponde a 150 8859-7, alfabeto Latino/Griego
(150-IR 126); soporta el ingls y el griego.
En el caso de UNOA, se utilizan por defecto los siguientes separadores de

informacin:
Apstrofo
('):
terminador
de
segmento;
Signo ms (+): separador de etiqueta de segmento y elemento de datos;
Dos
puntos
(:):
separador
de
elemento
de
datos
bsico;
Interrogacin (?): carcter liberador.
Las sintaxis restantes utilizan como separadores de informacin los siguientes
caracteres de control no imprimibles:
o
o
o
IS 4: terminador de segmento
IS 3: etiqueta de segmento y separador de elementos de datos
IS 1: separador de elementos de datos bsicos
Los contratistas deben tener presentes los problemas que surgen de la utilizacin
de estos caracteres de control en determinados protocolos de comunicaciones.
En cualquier caso, EDIFACT no obliga a la utilizacin especfica de un juego de
caracteres, ya que ste puede ser acordado entre interlocutores mediante un
acuerdo de intercambio.
Separadores
Existe tambin un juego de caracteres especiales que determinan la separacin
entre los distintos componentes de un mensaje EDIFACT. Tambin este juego
de caracteres puede ser sustituido por otro a voluntad del usuario y explicitado
en el propio mensaje mediante un segmento particular (UNA). Estos caracteres
por defecto son:
Pgina 85
o
o
o
o
Apstrofe ('): Determina el final de un segmento.

Signo ms (+): Utilizado como separador de elementos de datos.
Dos puntos (:): Separador de subelementos de datos.
Interrogacin (?): Utilizado como carcter de escape. El carcter de
escape se emplea en aquellas circunstancias en que es necesario incluir
en el mensaje EDI un carcter de los anteriores. Por ejemplo, para incluir
la expresin 10 + 10 = 20 se usara el carcter de escape del modo
siguiente: 10?+ 10 = 20. La interrogacin se representa por ??.
Estructura de un intercambio EDIFACT

Una conexin EDIFACT consiste en el envo/recepcin de uno o varios
intercambios
entre
interlocutores.
Un intercambio se define como un conjunto de mensajes o grupo funcionales de
un
origen
para
un
destino.
En un intercambio puede incluirse cualquier nmero indeterminado de mensajes.
Si son de tipos distintos, es obligatorio agruparlos en grupos funcionales. La
misin de este agrupamiento es facilitar la labor del receptor del intercambio a la
hora de distribuir los mensajes EDI recibidos a las aplicaciones encargadas de
procesarlos.
Un grupo funcional sirve de sobre a uno o varios mensajes del mismo
tipo. Su utilizacin es escasa actualmente e, incluso se est planteando su
desaparicin ya que el modo ms habitual de trabajo es generar intercambios con
mensajes del mismo tipo no siendo necesaria la utilizacin de grupos.
Cada uno de los segmentos se cierra con un segmento de cola que
contiene la informacin de redundancia y control.
En una instancia, un intercambio EDIFACT consiste en un conjunto de
segmentos obtenidos de un directorio EDIFACT, cada uno con una funcin
determinada y que se subdividen en elementos de datos (simples o compuestos)
separadores conforme a las reglas explicativas anteriormente. El resultado es un
documento estructurado con cada tem de informacin perfectamente
identificable para las aplicaciones que lo procesen.
La normativa EDIFACT define para cada mensaje estndar los siguientes
factores:
Identificacin unvoca del mensaje. Un mensaje se identifica por los
siguientes campos:
Tipo
de
mensaje
(ORDERS,
INVOIC,...)
Versin
de
mensaje
('2',
'D'...)
Release
de
mensaje
('901',
'95B',...)
Agencia
controladora
('UN',
'AE',...)
Asociacin
responsable
del
mantenimiento
Descripcin del mbito de uso y partes a las que est dirigido.
Pgina 86
Conjunto de segmentos utilizados y orden de utilizacin de los mismos.

Conjunto de elementos de datos utilizados y valores tabulados de los mismos, de
existir.
El mensaje se estructura en niveles y la ordenacin de los segmentos en

el intercambio viene dada por el recorrido del rbol de izquierda a derecha y de
arriba abajo.
Es posible establecer otras ordenaciones, pero no son actualmente
utilizadas y precisan de un acuerdo entre interlocutores.
Segmentos EDIFACT
Pgina 87
Los segmentos de datos de usuario que pueden utilizarse en los mensajes

normalizados, aparecen recogidos en un directorio especfico del UNTDID
(Parte 5, Captulo 3) denominado "Directorio de Segmentos Normalizados".
A continuacin se describe un ejemplo de segmento EDIFACT obtenido de un
directorio estndar:
BGM
Beginning of Message
to indicate the type and function of a message
Function:
and to transmit the indentifying number
C002
Document/Message Name
C
1001
Document/message name, coded
C an..3
1131
Cod list qualifier
C an..3
3055
Code list responsible agency, coded
C an..3
1000
Document/tnessage name
C an..35
1004
Document/message Number
C an..35
1125
Message function, coded
C an..3
4343
Response type, coded
C an..3
5.1.8
Elementos de datos
Un segmento se divide en Elementos de Datos (denotados con maysculas) que a su

vez pueden contener subelementos. Para cada tem de informacin se indica lo
siguiente:
Etiqueta identificativa dentro del directorio.
Estado obligatorio/Condicional del elemento.
Tipo y Longitud.
5.1.9
Traduccin del mensaje
Un sistema de informacin EDI debe realizar una serie de tareas a la hora de

automatizar los procedimientos de Intercambio electrnico de Datos. Supongamos un
ejemplo de aplicacin que recibe mensajes estructurados va EDI. Deber realizar los
siguientes procesos:
Recepcin de uno o varios intercambios EDIFACT directamente de su
interlocutor o mediante un centro de compensacin.
Anlisis de la consistencia frente al estndar de los mensajes recibidos.
Si la validacin es correcta, extraccin de la informacin til recibida.
Cambio de formato de la informacin al utilizado por el sistema informtico
interno.
Validacin semntica de la informacin (consistencia).
Procesamiento.
Por otra parte, la estructura de mensaje EDIFACT est orientada a la transmisin
ya que comprime los datos intercambiados, pero es difcilmente procesable por
una aplicacin informtica.
Pgina 88
De todo lo anterior se pone de manifiesto la necesidad de un mecanismo que acte

de puente entre el mundo EDI y las aplicaciones internas de procesamiento y que realice
fundamentalmente dos tipos de labores:
Validacin.
Cambio de formato.
Este mecanismo lo proporciona el Traductor de Formatos. Su misin es analizar un
intercambio EDI, validarlo y generar un archivo en un formato definido por el usuario
denominado archivo plano.
La gran ventaja de un documento en formato plano es que los campos aparecen
siempre en posiciones fijas dentro del fichero, facilitando el acceso a la informacin por
parte del aplicativo del usuario.
Adicionalmente, el usuario filtra la informacin que necesita procesar y vuelca la
necesaria para sus aplicaciones.
5.2
ANSI X.12
Como hemos visto, un requisito indispensable para intercambiar documentos

electrnicamente es estructurar estos segn un estndar uniforme.
Si bien el estndar ms extendido en Europa es EDIFACT, en Estados Unidos y
Canad, el estndar ms empleado para el intercambio electrnico en los sectores
comercial e industrial es el ANSI X.12, desarrollado por el Instituto Nacional
Americano.
El estndar ANSI X.12 se dise para que fuera muy flexible y pudiera
acomodarse a los diferentes usos y necesidades de informacin. El estndar define una
estructura aplicable a diferentes sectores, con requerimientos y tamaos diferentes.
Su propsito es generar un formato para estructurar la informacin comercial que
vaya a ser enviada electrnicamente, y recoge los siguientes aspectos:
Qu documentos pueden ser enviados electrnicamente?
Qu informacin puede o debe incluirse en cada documento?
Qu secuencia debe seguir la informacin?
Qu tipo de informacin numrica, cdigos de identificacin, etc., es
aceptable?
El estndar X.12 se compone de cuatro partes Conjuntos de transaccin, Segmentos,
Elementos de datos y Control de transmisin.
Conjuntos de transaccin. Un conjunto de transaccin tiene una entidad parecida a
un documento comercial. Por ejemplo existe un conjunto de transaccin para la orden
de pedido, para el albarn, para la factura, etc. De forma que cada uno de los
documentos comerciales que estandarizado ANSI X.12 a dado lugar a un conjunto de
transaccin. Por ejemplo la factura se refiere como el conjunto 810, y la orden de
pedido como 850.
Pgina 89
Segmentos de datos. Cada conjunto de transaccin se compone de mltiples

segmentos de datos. Por ejemplo el conjunto de transaccin de la factura (819) tiene 50
segmentos. Cada segmento contiene informacin necesaria para poder realizar la
transaccin. Por ejemplo el N1 es el nombre de segmento y se usa para identificar la
organizacin que remite la factura.
Elementos de datos. Los segmentos de datos estn compuestos de elementos de
datos. Por ejemplo, para el segmento de datos N1 se tiene:
Segmento N1 NOMBRE
Elementos de datos Descripcin
98
Cdigo de identifciacin de la entidad
93
Nombre
66
Cualificador del cdigo de identificador
67
Cdigo de identificador
En el caso de desear utilizar un nuevo conjunto de transaccin, se comenzar

identificando los elementos de datos que se necesitan. Si existen, solo ser cuestin de
combinarlos para obtener un segmento de datos. En el caso de que no existieran se
deber hacer una peticin formal a la comisin ANSI X.l2 proponiendo los nuevos
elementos.
5.2.1
Estructura de control en ANSI X.12
Existen tres niveles de control, llamados normalmente "sobres":

Sobre de intercambio.
Sobre de grupo funcional.
Sobre de transaccin.
Hay que tener en cuenta que cada transaccin se compone de un sobre de
Transaccin y que varias transacciones forman un grupo funcional. Y vados grupos
funcionales forman un sobre de intercambio.
La estructura de control se compone de tres sobres, conteniendo cada uno de ellos
dos segmentos de datos, uno para identificar el principio del sobre y el otro para indicar
su final.
El Sobre de Intercambio comienza con el segmento de Cabecera de Control de
Intercambio (ISA) y termina con el segmento de Final de Control de Intercambio
(lEA). lEA contiene datos para saber si la transmisin es completa. ISA es un
segmento de longitud fija. Estos dos segmentos son obligatorios
El Sobre Funcional empieza y acaba con el segmento GE (Functional Group
Trail).
Pgina 90
El Sobre de Transaccin empieza con el segmento de cabecera de transaccin

(ST) y termina con segmento final de transaccin (SE).
El sobre ms externo es el ISA (Interchange Control Header). Contiene

elementos de datos que especfica cuantos conjuntos transacciones hay en el sobre,
quien es el origen y el destino del mensaje.
5.2.2
Comparacin entre EDIFACT y ANSI X.12
EDIFACT tuvo que combinar dos estndar al uso, ANSI X.12 y TDI (Trade
Data Interchance) del Reino Unido para conseguir un estndar mundial, y eso provoc
que el resultado no fuera compatible con X.12. Hay numerosas diferencian en como
tratan estos dos estndares las transacciones, los segmentos y los elementos de datos.
Un estudio llevado a cabo por TDCC/EDLX muestra que X.12 debera hacer ms de 30
modificaciones para que pudiera interoperar con EDIFACT.
Como ejemplo, Grupos funcionales que son obligatorios en X.12 son opcionales
en EDIFACT. X12 no permite mezclar conjuntos de transacciones distintos en un grupo
funcional, sin embargo, EDIFACT permite la integracin de varios tipos de
transacciones.
Pgina 91
Los nombres de segmentos son diferentes en EDIFACT y X.12, no comparten el

mismo diccionario de datos; tina referencia en un estndar significa algo completamente
distinto en el otro.
Hay un compromiso de migrar del estndar X.12 a EDIFACT, aunque hay que
reconocer que X.12 est mucho ms desarrollado que EDIFACT. Empresas americanas
y canadienses ven a EDIFACT como un ataque a su forma de hacer EDI. De cada vez
ms se encuentran productos software de EDI que admiten los dos tipos de estndar.
5.3
Uso de EDIFACT en Europa
Pases como Inglaterra y Estados Unidos, que cuentan con un nmero alto de
empresas que hacen EDI utilizan estndares como UNTDI y ANSI X.12 y disponen de
la infraestructura necesaria para el uso de estos estndares (redes de transporte de
mensajes,
sistemas
para
Centros
de
Compensacin
y
terminales).
En paralelo al trabajo de estandarizacin de UN/EDIFACT, han comenzado varios
proyectos en diferentes pases del mundo para introducir EDIFACT a nivel nacional.
Este es el caso de pases europeos como Blgica (ICOM), Alemania (SEDASS),
Finlandia (CCC), Francia Allegro), los pases Bajos (TRANSCOM) y Austria
(ECODEX) se han implementado el uso de estndares EDIFACT nacionales. La
mayora de estos sistemas no son sistemas abiertos.
La existencia de estos estndares ha venido propiciada por la unin de diversas
compaas en sectores especficos para realizar estndares propietarios, tal es el caso de
ODETTE (para la industria del automvil desde 1988), CEFIC (Industria Qumica),
EDIFICE (Informtica y Electrnica), RINFT (Sociedades de reaseguros).
5.4
Otros Estndares
El estndar de facto en Estados Unidos es el X.12, no obstante existe un

compromiso para migrar a la norma EDIFACT para 1997. Aunque se exige que para el
comercio internacional se use la norma EDIFACT.
La posicin oficial de Canad es de seguir la norma EDIFACT. No obstante
debido a la proximidad geogrfica y al gran volumen de transacciones entre Estados
Unidos y Canad, se utiliza frecuentemente la norma X.12
En Europa, aunque desde un principio, la Comunidad Econmica Europea, hoy
la Unin Europea, se adhiri a la norma EDIFACT, sin embargo existen otros entre
ellos se tiene TRADACOM (Trade Data Communications Standards) y ODETTE
(Organization for Data Exchange Trough Teletranstmission ni Europe). TRADACOM
se usa preferentemente en el Reino Unido y ODETTE en el sector automvil.
Rusia ha creado la agencia EDIFLOT y ha reconocido el estndar EDI. El
crecimiento EDI en este pas es espectacular debido al incremento comercial con sus
vecinos europeos. Se ha creado el Instituto para la Automatizacin de Sistemas en
Mosc, y el Centro Nacional para e1 Intercambio Automtico de Datos en Yugoslavia.
Pgina 92
En Japn, debido a su tradicin de utilizar intensamente protocolos propietarios

en el intercambio de datos, no est tan desarrolla la estandarizacin sobre EDIFACT o
X.12 como Europa o Estados Unidos. En 1989 se pretenda formar el grupo EDIFACT
de Nueva Zelanda y Japn. Sin embargo Japn no dese entrar en el grupo, intentando
formar otro grupo paralelo con Singapur. Pero en 1990 se unieron al grupo EDIFACT
del pacfico con Hong Kong y Corea.
Hong Kong ha formado el Shared Project for Electronic Data Interchange.
Segn un estudio reciente desarrollado por IDEA (International Data Exchange
Asociation) se ha visto que Australia es el pas que hace ms uso de EDI, en relacin
con su poblacin. Tambin Nueva Zelanda hace uso extensivo de EDI, sobre todo en el
campo aduanero, y siguiendo la normativa EDIFACT.
5.5
OFTP
OFTP es un protocolo de alto nivel. Trata sobre la forma en que se envan los
mensajes sin tener en cuenta las lneas de comunicacin fsicas sobre las que se envan
stos. Aunque estos tipos de conexiones estn tambin estandarizados se describen en
protocolos como X.25 o X.28 y queda fuera de este mbito.
OFTP usa conexiones X.25 y aparte de esto no se necesita tener ningn
conocimiento sobre el hardware o el software sobre el que se utiliza.
5.5.1
Historia de OFTP
El protocolo OFTP se utiliza de forma extensiva en toda Europa. ODETTE es la

asociacin de automocin de EDI en Europa, y se puede decir que es fruto de una idea
de Coln Anthony, director financiero de FORD para el Reino Unido. Esta idea cuajo en
una
iniciativa
coordinada
de
EDI
en
Europa.
ODETTE se organiz en diversos grupos, cada uno de ellos con responsabilidad sobre
un aspecto particular de EDI. Grupo 1 era el encargado sobre los elementos de datos,
grupo II sobre los mensajes, grupo III sobre la sintaxis de EDI, y grupo IV sobre las
comunicaciones.
El grupo IV tuvo como encargo definir el sistema de transferencia de ficheros
EDI que transportara los datos EDI definidos por los otros grupos. Los miembros este
grupo eran principalmente programadores de los grandes sistemas de IBM cuyo inters
se centraba en las comunicaciones dada su experiencias en sus respectivas
organizaciones.
Comenzaron los primeros trabajos en 1985 y pronto decidieron que aunque todos
disponan de redes SNA esa no era el ejemplo a seguir. Decisin basada no sobre la
naturaleza propietaria de SAN sobre las dificultades prcticas de intercomunicacin de
dominios
descentralizados
y
no
SAN.
FORD propuso una solucin propietaria de FORD que fue vetada por GM. General
Motor propuso una solucin propietaria de GM que a su vez fue vetada por FORD.
Philips propuso una solucin que vetada por todo el mundo. Con lo que se tema
constancia que no se poda utilizar una solucin propietaria.
Los nicos sistemas abiertos que se dejaron fueron X.400 y FTAM, y
probablemente el peor error cometido fue la decisin de separar las necesidades de
Pgina 93
comunicaciones entre Transferencia de ficheros (FTAM) y correo electrnico (X.400).

Esta separacin fue lo que no proporciono a EDI las necesidades de enrutamiento que
proporciona X.400 junto con la capacidad de transferencia de ficheros FTAM. No
estante en esta etapa de desarrollo FTAM no era un estndar y X.400 estaba sufriendo la
confusin que provoc el conflicto entre las versiones de 1984 y 1988, adems de tener
la idea errnea de que el sistema de mensajes X.400 solo podra manejar ficheros de
hasta 3 MB, que lo inutilizaba para manejar ficheros CAD/CAM.
Los miembros de las organizaciones de estandarizacin estaban compuestos
principalmente por profesores de universidades y representantes del mundo empresarial,
alejados entre s por grandes distancias, lo que hacia aumentar la confusin entre ellos,
falta de informacin, y diseminacin de informacin errnea.
5.5.1
El nacimiento de OFTP
Ante esta situacin pareca que no haba otra solucin para ODETTE que crear
su propio estndar, el OFTP, de forma que combinara la capacidad de enrutado de
X.400 y la transferencia de ficheros de FTAM, adems de hacerlo ms sencillo y ms
simple de implementar.
De esta forma, OFTP no es ms que una solucin pragmtica a un problema
simple comercial. La especificacin se hizo pblica en 1985 y fue ratificada por el
grupo IV el 20 de noviembre de 1986.
5.5.3
Caractersticas de OFTP
OFTP funciona sobre X.25 y es un protocolo simple de solamente 14 comandos.

Aunque X.25 es en s mismo un protocolo, sin embargo, no tiene capacidad para tratar
la transferencia de ficheros. Poniendo un ejemplo X.25 es como cuando se establece una
llamada telefnica y el OFTP es el dilogo que se hace sobre la conexin establecida.
Como se puede esperar, OFTP dispone de ordenes para controlar el inicio del
fichero, compresin de datos y seguridad. Desde el punto de vista del usuario su
potencia viene dada por su capacidad de enrutamiento de forma que OFTP puede hacer
y recibir mltiples llamadas simultneamente, incluso a travs de llamadas
internacionales.
Esta capacidad de enrutamiento permite al usuario dirigir un fichero a un
receptor remoto o a una entidad local dentro de la estructura organizativa del receptor
remoto. La comunicacin puede hacerse a travs de varias redes de valor aadido,
aunque sean internacionales.
Cuando un sistema OFTP conecta con otro sistema OFTP, el sistema operativo
remoto no est autorizado a indicar su presencia, de forma que no se necesita saber nada
del hardware remoto. De forma que es muy sencillo conseguir la conexin con sistemas
muy diversos.
Adems de usarse sobre X.25, OFTP se diseo para que se pudiera usar tambin
sobre las lneas de bajo precio X.28, usando la RTB y sin simple mdem asncrono.
Pgina 94
Primeros usuarios de OFTP: Los primeros pases que respaldaron este estndar
fueron Suecia, Francia y Alemania. Las empresas del automvil en Alemania, aunque
ya tenan un sistema propietario el VDA, enseguida adoptaron el OFTP.
El primer sistema OFTP fue desarrollado por Data Interchange, rama de Massey
Fergusson Corporation y el segundo fue desarrollado en Francia por una casa de
software patrocinada por Renault.
Los primeros usuarios de OFTP fueron Volvo y SAAB en Suecia. Y lo ms
interesante fue el consenso al que llegaron estas dos compaas para utilizar este
protocolo los sus suministradores. Decidieron que las tcnicas Just in Time (JIT) eran
los objetivos a alcanzar y que permitiran intermediarios entre ellos y sus proveedores,
de forma que rechazaron la utilizacin de redes de valor aadido.
SAAB y Volvo sostenan que con la utilizacin de redes de valor aadido se
retrasara la transferencia electrnica entre ellos y sus proveedores. Volvo quera utilizar
el mensaje AVIEXP (Despacht Advice) y tena proveedores que distaban 15 minutos en
automvil de la planta de produccin de Volvo, por lo que era necesario que el
proveedor generase un mensaje AVIEXP, enviarlo a Volvo, Volvo lo recibiera, Volvo
lo procesara y proporcionara la informacin al departamento de compras en menos de
15 minutos.
5.5.4
Redes de valor aadido y OFTP
Aunque los albores de OFTP son los que se indican anteriormente, el

crecimiento de OFTP es debido a tres individuos que pusieron su confianza en este
protocolo. Estos fueron Irvine Web de ISTEL, Steve Thompson de la British Telecom y
Peter Field de IBM. Los tres estaban relacionados con las redes de valor aadido y
queran que OFTP fuera el protocolo de estas redes.
De forma parecida al Reino Unido, fue la iniciativa de ISTEL con su rgimen de
franquicia EDICT lo que hizo que el protocolo se expandiera por Italia, Espaa y Suiza.
Hoy en da OFTP es el nico medio de acceso comn entre las principales redes
de valor aadido de Europa. Entre ellas estn IBM (IIE) AT&T (Easylink), BT
(EDI*NET), GEIS (EDI Express), INS (Tradenet), Swisscos, Seva, Memocom, ADB y
Telefnica.
Telefnica actualmente mantiene una red de valor aadido dedicado al servicio OFTP
para las empresas fabricantes y subsidiarias del automvil.
Un punto muy interesante de OFTP es la capacidad de poder comunicarse
directamente entre dos usuarios, sin necesidad de tener que contar con los servicios de
un Centro de Compensacin. Por lo que es sorprendente que la mayora de las VAN han
estado promoviendo este protocolo cuando X.400 proporciona tambin estas
caractersticas.
Disponer de un protocolo tan abierto como OFTP es realmente una gran ventaja
para las VAN porque simplifica los aspectos de interconexin de sus servicios y
permitiendo a usuarios de unas VAN utilizar otras VAN, con las que se hayan firmado
el acuerdo, sin necesidad de cambiar ni hardware ni software.
Pgina 95
Tambin es beneficioso para los usuarios, debido a su carcter abierto, que

pueden utilizar la VAN con la que tienen subscrito el acuerdo y otras interconectadas
con la primera.
5.5.5
Otros sectores
Aunque OFTP se desarrollo dentro del mundo del automvil, su diseo se hizo
de forma general y tan simple que se puede aplicar de forma directa a cualquier sector
comercial. Hoy en da OFTP se usa en la Industria textil, Venta al detalle,
Administracin, Transporte, Seguros, Banca, Sector Qumico y petroqumico.
5.5.6
Proyecto IDX
Los cinco mayores bancos del Reino Unido, Barclays, Midland, Natwest, Lloyds
y Royal Bank of Scotland, decidieron utilizar para sus transacciones EDI. Aunque ya
dispona del sistema BACS (Banker Automated Clearing Services) para compensacin
de sus transacciones, decidieron que era mejor realizarlas entre ellos directamente. Y el
mismo contexto que hizo que se creara OFTP, estos bancos decidieron usar este
protocolo para sus transacciones bancarias de EDI.
5.5.7
Futuro de OFTP
Los cinco mayores bancos del Reino Unido, Barclays, Midland, Natwest, Lloyds
De lo visto hasta este momento se podra sacar la consecuencia que de OFTP debera
desbancar a X.400. Sin embargo la fuerza que existe detrs de X.400 es muy importante
y cuando se generalicen los productos X.400 MTA EDI, a bajo precio y funcionado
sobre PC, sobre diversas plataformas hardware y software, entonces ser cuando puede
emerger claramente Pedi. Esta es la situacin que se est dando hay da.
De la misma forma que Bisync muri tambin se espera que OFTP sea superado
por Pedi, no obstante la sustitucin ser lenta y progresiva, de forma que OFTP todava
estar unos cuantos aos en el mercado. Una de las mayores ventajas de OFTP es que
funciona sobre X.25, de forma que puede convivir X.400,asi que permitir una
migracin cmoda a los usuarios a X.400.
5.5.8
Comandos OFTP
Para controlar las comunicaciones OFTP provee de un conjunto de comandos

que indican las distintas labores que se hacen en el tratamiento de los mensajes. Cada
uno de ellos sirve para una diferente y se necesita utilizar todos en una determinada
conexin, dependiendo de la naturaleza de la comunicacin.
SRM (Start Session Ready Message): Este el primer mensaje que se debe
enviar despus de hacer la conexin fsica. Indica que se est haciendo una
comunicacin con otro sistema va OFTP.
SFID (Start File Identification): Este comando es una peticin para permitir
enviar un fichero. Contiene informacin como el destino, cdigo del fichero, nombre
del fichero y su tamao.
Pgina 96
DATA
Este comando se utiliza para realmente enviar los datos al receptor.
EFID (End Of File Identifciation): Este comando se despus de haber
completado el vio de un fichero para indicar la seal de finalizacin del envo. Contiene
controles de seguridad para asegurar que se ha enviado la totalidad del fichero.
EERP (End lo End Response): Es un comando especial diseado orientado al
centro de compensacin. Se genera cuando un fichero alcanza el ltimo destino y se
enva al que origin el envo del fichero para indicarle que se ha recibido el fichero.
5.5.9
Otras consideraciones
Ficheros soportados por OFTP: OFTP soporta la transferencia de diferentes

tipos de ficheros. Incluye los de registro de longitud fija y variable, ficheros sin formato
y ficheros de texto.
Mtodo de acceso: OFTP soporta acceso directo a las redes X.25 y a travs de
la RTB con X.28. Provee deteccin de errores y procedimientos de recuperacin.
OFTP y la industria: OFTP lo usa principalmente las industrias fabricantes y
subsidiarias del automvil incluidas en la European Motor Manufacturers. Tambin lo
utiliza la industria farmacutica, industrias del textil y lo ha llegado a sectores como la
banca y el transporte.
5.6
Ejemplo UNIFACT: Manifiesto de importacin
5.6.1
Introduccin
5.6.2
Diagrama de bifurcacin
5.6.3
Estructura del mensaje
5.6.4
ndice de mensajes
5.6
X.400 y X.435
X.400 es un estndar de interconexin de sistemas abiertos para el Correo

Electrnico del ITU.
La normativa X.400 ofrece el medio para enviar y recibir mensajes
interpersonales, si bien existe tambin la posibilidad de realizar intercambios
mercantiles estructurados, usando un sistema de transferencia bsico para almacn y
envio de mensajes.
Es decir, existe una extensin del estndar X.400 que permite intercambiar
mensajes EDI a travs de correo electrnico, ste es el estndar X.435.
Este tipo de mensajes tendrn una estructura definida como la que se muestra en
el grfico:
Pgina 97
El mensaje podr contener partes de cuerpo estndar, pero slo una parte de
cuerno EDI puede estar incluida en el sobre. El mensaje EDI no puede extenderse sobre
partes de cuerno mltiples.
Los campos de cabecera estn armonizados con el estndar de cabecera
EDIFACT para hacer ms fcil la transmisin entre redes, pero se permitirn otras
sintaxis EDI para proporcionar la migracin a X.400 desde redes EDI ms antiguas.
En el apartado dedicado al Correo Electrnico se escribe detalladamente la
norma X.400.
5.6
X.500
Es un estndar de interconexin de sistemas abiertos para un Servicio de

Directorios. Este estndar ofrece los servicios de almacn y recuperacin de
informacin de un directorio, con control de accesos y duplicacin de servicios de datos
distribuidos.
Pgina 98
Los servicios de directorio X.500 proveen, a los usuarios de X.400 informacin

sobre direcciones de correo electrnico, incluyendo a los usuarios informacin acerca de
direccin de Redes de Valor Aadido. Algunos de los usos del servicio de directorio
son:
Mnemotcnicos o alias: Dado que las direcciones tanto en X.400 como en
Internet son complejas, es interesante la posibilidad de emplear alias o
mnemnicos para los emisores y receptores de los mensajes.
Listas de Distribucin. Podran agruparse varios destinatarios de mensajes
formando listas de distribucin. De manera que el remitente enviara el mensaje
a la Lista de Distribucin y automticamente se encaminan a todos los
integrantes de dicha lista.
Autentificacin Mutua: El funcionamiento intrnseco del servicio comprueba la
identidad de los interlocutores, de manera que se trata de un aspecto importante
en lo tocante a la seguridad.
Uso interactivo: El usuario EDI puede consultar directamente el servicio de
directorio para encontrar destinatarios y sus direcciones e igualmente obtener
informacin de su destinatario en cuanto a sus caractersticas, tipos de mensajes que
recibe,.. etc. Se trata, por tanto de una utilidad muy importante, sobre todo teniendo en
cuenta la escala mundial que ha adquirido el Comercio Electrnico.
Pgina 99
CAP. 6
SEGURIDAD
6. Seguridad
Las actuales redes de telecomunicacin han abierto mltiples posibilidades para
las empresas, en particular, en la forma de hacer negocios. El Intercambio Electrnico
de Datos vino a reemplazar los mtodos tradicionales de comunicacin de informacin
comercial o administrativa entre empresas y organismos estatales, por formatos
estndar, transferibles de ordenador a ordenador, y fcilmente integrable en las
aplicaciones informticas.
Parece claro que el uso de redes pblicas de transmisin de datos impone la
necesidad de proteger los documentos electrnicos de las posibles amenazas a las que
stas se ven sometidas, como por ejemplo: contra la integridad (modificacin, insercin
o supresin de contenido de un mensaje), Autentificacin (es el origen de un mensaje
quien dice ser?) y confidencialidad. Por otro lado, hay ciertos atributos de los
documentos en papel, que tiene que ver fundamentalmente con consideraciones de tipo
legal, tales como letras, rdenes de pago, contratos, etc. Que hacen necesario introducir
mecanismos electrnicos que los reemplacen, como puede ser la firma digital, as como
de los mecanismos necesarios para su gestin y auditoria (Terceras Partes Confiables).
En apartados siguientes, analizaremos en mayor profundidad los servicios de
seguridad que seran deseables para entornos EDI, apuntando qu infraestructura sera
necesaria para implementarlos.
6.1
Amenazas
Las amenazas a las que se pueden ver sometidos los documentos electrnicos no son
muy distintas de las que sufren en la actualidad los documentos en papel, aunque las
especiales caractersticas del soporte introducen nuevos matices. Bsicamente las
podemos resumir en las siguientes:
Prdida o demora
Repeticin
Manipulacin
Confidencialidad
Trazabilidad
Suplantacin
Repudio
Prdida o demora: Un mensaje puede perderse de forma accidental por la red
de comunicaciones por problemas de la misma o debido a la intervencin de
terceros. En otros casos, la simple demora en la entrega de un mensaje, por
motivos de congestin de la red por ejemplo, puede llegar al extremo de hacerlo
inservible o tener consecuencias negativas. Este es el caso de entornos donde se
emplean tcnicas de just in time.
Pgina 100
Repeticin: Un tercer interlocutor puede almacenar el mensaje, y obtener de l

tantas copias como desee, pudiendo transmitirlo de forma malintencionada.
Manipulacin: Se refiere ala interceptacin de un mensaje por una tercera parte,
y tiene que ver con la integridad del mismo. Se ha recibido el mensaje
completo y tal como fue enviado? Se ha alterado el mensaje, o una parte de l,
mientras estaba en trnsito? Es posible secuestrar un mensaje autntico y
modificar partes importantes del mismo antes de que llegue a su destino
correcto?
Confidencialidad: Hace referencia a la posible lectura no autorizada de un
mensaje en trnsito. Cundo un mensaje sea secreto, Cmo estar seguros de
que no ha sido ledo mientras transitaba? Es algo que tiene especial importancia
cuando se envan datos comerciales confidenciales o datos de tipo personal.
Trazabilidad: En determinados casos tambin resulta importante la
confidencialidad de los datos sobre trfico, ya que en ocasiones es posible
deducir informacin de utilidad de la simple observacin de dichos datos. Por
ejemplo, se puede calcular el nivel de actividad econmica de una empresa
contando el nmero de mensajes enviados y recibidos, an cuando se mantenga
en secreto el contenido de dichos mensajes.
Suplantacin: Tiene que ver con la autenticidad del origen del mensaje. Cmo
estar seguros de que un mensaje recibido procede realmente de la entidad o
persona que supone lo ha remito? .De no existir la posibilidad de comprobarlo,
un competidor podra obtener, por ejemplo, una lista de precios o informacin
confidencial relacionada con la planificacin de la produccin de la competencia
de forma errnea.
Repudio: Se refiere a la negacin del envo/recepcin de un mensaje o bien al
no reconocimiento de partes del mismo. Es evidente que para que d comercio
electrnico pueda reemplazar con garantas al comercio basado en mtodos
tradicionales, habr que poder dotar a los documentos electrnicos de elementos
aceptados comnmente como legales tales como las firmas manuscritas.
Es importante sealar que aunque las amenazas siempre van a estar ah. es decir, son
inevitables, las posibles vulnerabilidad desde los sistemas de informacin no lo son,
como veremos en los siguientes apartados.
6.2
Soluciones
Existe una gran variedad de tcnicas que permiten aportar seguridad a los
documentos electrnicos, conocidas como tcnicas criptogrficas. Estas tcnicas se
basan en la combinacin de algoritmos matemticos ms o menos complejos, junto con
una serie de procedimientos (protocolos) de uso. Al hablar de seguridad de la
informacin se suele distinguir entre servicios y mecanismos de seguridad, entendiendo
por servicios de seguridad aquellos atributos que los usuarios pueden aplicar a sus
documentos para protegerlos, mientras que por , mecanismos de seguridad nos
referimos tanto a los protocolos como a los mtodos criptogrficos necesarios para
garantizar los servicios de seguridad. En este apartado se dar un breve repaso a los
mecanismos de seguridad ms empleados en la actualidad, completado con un poco de
terminologa bsica.
Pgina 101
6.3
Terminologa bsica
La operacin de transformacin que el transmisor aplica al mensaje a proteger,

mensaje en claro o texto legible, recibe el nombre de cifrado. El proceso de cifrado
siempre est controlado por una clave secreta, que selecciona la transformacin
especfica a aplicar al mensaje en claro. El resultado de esta operacin es el texto
cifrado o criptograma. Para que el receptor pueda recuperar el mensaje original, deber
aplicar al texto cifrado la operacin de transformacin inversa, el descifrado, siempre
con el conocimiento de la clave.
Si la tarea del criptgrafo es la de buscar los mtodos para asegurar la
confidencialidad y / o autenticidad de un mensaje, la tarea del criptoanalista (pirata
informtico o hacker) es la de deshacerla tarea del primero, ya sea descubriendo tales
mtodos o falsificando mensajes, de forma que sean tomados como buenos.
A nivel terico se suele distinguir entre:
Sistemas incondicionalmente seguros: Sistemas seguros independientemente
del tiempo y de los recursos que disponga el enemigo criptoanalista para el
anlisis de los criptogramas.
Sistemas computacionalmente seguros: Sistemas en los que la complejidad de
este anlisis, excede la capacidad real tanto en tiempo como en medios con los
que cuenta el enemigo. Slo son de utilidad prctica estos ltimos.
Normalmente, la seguridad de un sistema de cifrado reside completamente en la
clave secreta, ya que el resto de detalles de implementacin, como algoritmo de cifrado,
formatos, etc. son pblicos.
6.4
Servicios de seguridad
Aunque del tipo de amenazas que hemos analizado pueden deducirse los servicios
de seguridad se detalla a continuacin se enunciado:
Integridad de la secuencia del mensaje: Previene la duplicacin, adicin,
borrado, prdida o repeticin del mensaje.
Integridad del contenido del mensaje: Garantiza la deteccin de la
modificacin no autorizada del mensaje. La integridad del mensaje puede
obtenerse como un subproducto del servicio de Autentificacin de origen del
mensaje o del no-repudio de origen (ver tabla).
Autentificacin del origen del mensaje: Garantiza el origen de los datos y da
al receptor la prueba de que la fuente de los datos recibidos es quien dice ser.
Este servicio proporciona tambin integridad del contenido del mensaje y puede
ser obtenido como subproducto del servicio de no-repudio de origen.
No repudio de Origen: Protege al receptor de un mensaje de cualquier intento
por parte del origen de negar su envo a la totalidad o a parte del contenido del
mismo. Para realizar este servicio se usa una firma digital del mensaje.
No-repudio de recepcin: Protege al origen de un mensaje de la negacin por
parte del receptor de la recepcin de mismo. Da prueba al origen de que el
mensaje ha sido recibido.
Pgina 102
Confidencialidad: Protege contra la lectura, copia o revelacin no autorizada

del contenido del mensaje.
Las relaciones entre los distintos servicios se recogen en la tabla siguiente:
Integridad
Contenido
Implica el uso de:

Integridad
contenido
de
Autenticacin
origen
de
de Autentificacin
origen
de
Si
Si
Si
No repudio de origen Si
Si
6.5
de No repudio
origen
Si
Mecanismos de seguridad
Existen dos grandes familias de sistemas criptogrficos: los sistemas de Clave

Secreta y los de clave Pblica.
6.5.1
Cifrador de clave secreta
En los sistemas criptogrficos de clave secreta, la seguridad no reside en el

algoritmo de cifrado, que puede hacerse pblico, si no en la clave, que debe mantenerse
en secreto, y que es utilizada tanto para cifrar como para descifrar (por lo que tambin
recibe el nombre de cifradores simtricos). Su principal ventaja es su rapidez. Su
principal inconvenientes es el de la distribucin de claves, que en cierta manera plantea
un problema circular: para poder comunicarse de forma segura sobre un canal inseguro,
los usuarios deben intercambiar primero informacin sobre sus claves privadas. Otro
problema relacionado es el nmero de claves que un usuario necesita para comunicarse,
ya que necesitar una clave distinta por cada interlocutor.
Los cifradores simtricos pueden proporcionar los servicios de integridad de

contenido y secuencia y el de Autentificacin de origen. no as la firma digital.
El cifrador simtrico ms conocido es seguramente el DES (Data Encryption
Standard). El tamao de la clave es de 56 bits, y hoy da se especula sobre su resistencia
a ataques de fuerza bruta. Existen otros cifradores simtricos en principio ms fuertes
(resistentes al ataque) que el DES. Por citar uno de ellos, mencionar el IDEA
Pgina 103
(Intemational Data Encription Algorithm), muy similar al DES, con sus mismo modos
de funcionamiento, aunque con una clave mucho mayor, 128 bits.
6.5.2
Cifradores de clave pblica
En un sistema de clave pblica, transmisor y receptor utilizan claves distintas

inversas (cifradores asimtricos), de las cuales una debe mantenerse en secreto, mientras
que la otra, as como los procedimientos de cifrado/descifrado. La separacin de las
funciones de cifrado y descifrado, hace posible que los usuarios de un sistema de este
estilo puedan listar sus claves pblicas a modo de directorio telefnico, junto con sus
nombre y direcciones. La desventaja, ms importante del cifrado asimtrico estriba en
su complejidad, que se traduce en bajas velocidades de cifrado, sobre todo comparadas
con las obtenidas por cifradores simtricos.
En la prctica suelen utilizarse sistemas hbridos, cifradores simtricos rpidos

para el cifrado masivo de datos y sistemas asimtricos par distribucin de claves y firma
digital.
Los cifradores de clave pblica pueden ofrecer todos los servicios de seguridad
detallados en los apartados anteriores. en especial el de la firma digital (no repudio de
origen/destino).
El sistema de clave pblica ms conocido es el RSA, nombre que deriva de las
iniciales de sus autores.
Como funciona RSA:
Encontrar dos nmeros primos lo suficientemente grandes. por ejemplo de 1024
bits, P y Q.
Elegir un nmero primo e impar E, tal que E y (P-l)(Q-l) sean primos entre s.
(P-l)(Q-l) no pueden ser primos porque es un nmero par.
Calcular D de tal forma que (DE-I) sea divisible por (P-l)(Q-l). Esto se suele
escribir DE = 1 mod (P- 1)(Q-l).
La funcin de encriptacin es C(I)=TE mod PQ .donde T es el texto sin cifrar.
La funcin de descifrado es D(c)= CED mod PQ. donde C es el texto cifrado.
La clave pblica viene dada por el par PQ,E. La clave privada es D. PQ es el
mdulo. E es el exponente pblico. y D es el exponente secreto.
Pgina 104
No hay problema en hacer pblico la clave pblica. porque no se conocen mtodos para
calcular D, P o Q, sabiendo nicamente P A y E.
6.5.3
Funciones resumen (hash)
Una funcin resumen o hash. H acepta un mensaje M de tamao variable como

entrada y como salida produce una representacin de M de tamao fijo H(M), conocida
con resumen de mensaje (Message Digest). En general. H(M) ser mucho menor que M,
usualmente entre 64 y 160 bits. El cambio de un solo bit en el mensaje hace que el hash
sea distinto. Su uso est relacionado con la firma digital. Su uso est relacionado con la
firma digital.
Para que una funcin Hash sea til desde el punto de vista de la Autentificacin,
debe cumplir al menos el siguiente requisito: debe ser computacionalmente imposible
encontrar un mensaje que produzca el mismo resumen que uno dado, es decir, que
aunque tericamente es posible encontrar dos mensajes con el mismo hash, la
probabilidad es la mnima.
Entre las funciones hash ms utilizadas hoy en da esta el MD5 (desarrollado por
Ron Rivest) y el SHA (Secure Hash Algoritm, desarrollado por el National Institute of
Standards and Technology), sin olvidar al MAC (modo de operacin del DES).
6.5.4
Firmas digitales
La firma digital es una analoga electrnica a la firma manuscrita. Las caractersticas

son tambin anlogas:
El receptor debe ser capaz de validar la firma del transmisor.
La firma no debe ser falsificable.
El transmisor de un mensaje firmado no debe poder repudiarlo posteriormente.
Una diferencia fundamental es que la Firma Digital no es constante, sino que es

funcin del documento que firma, de todo el documento.
Pgina 105
La implementacin de la Firma Digital mediante criptografa de clave pblica

proporciona importantes caractersticas:
1. Posibilidad de incorporar autentificacin simultneamente, siempre que el
sistema soporte ambos servicios.
2. Reutilizacin de la misma clave para generar firmas.
3. El no repudio es un servicio b' contenido en la firma.
El modo habitual de proceder para la generacin de una forma digital es el siguiente:
Calcular el hash o resumen del mensaje. Esto se hace por prestaciones, ya que
los cifradores asimtricos son muy lentos como para cifrar un mensaje completo.
Firmar el hash del mensaje con la clave privada
Para verificar la firma, cualquier usuario que tenga acceso a la clave pblica del
usuario que gener la firma proceder de la siguiente forma:
De la firma del mensaje recuperar el hash original, H.
En base al mensaje recibido, calcular el Hash H'.
Si H=H', la firma ser correcta, asegurando que el mensaje no fue modificado en
la transmisin, y que el usuario origen es quien dice ser.
6.5.5 Autoridades de Certificacin y Certificados de Clave Pblica.
Para la implantacin de servicios de seguridad basados en algoritmos de clave
pblica es necesario crear un entorno seguro, ya que las claves pblicas de los usuarios
aparecen listados en servicios pblicos de directorio. Por lo que deben protegerse contra
modificaciones no autorizadas. El mtodo habitual de proteger las claves pblicas de los
usuarios es mediante el uso de certificados, que deben ser generados por una Tercera
Parte Confiable, llamada Autoridad de Certificacin (AC). Bsicamente, un certificado
contiene informacin relativa al usuario (credencial), su clave pblica y el periodo de
validez del certificado. Esta informacin es firmada con la clave privada de la AC
ligando las credenciales del usuario con su clave pblica, permitiendo que cualquier
usuario, en posesin de la clave pblica de AC que emiti el certificado, pueda tener
total seguridad sobre la validez o no de las claves pblicas que obtiene del directorio.
6.5.6
Servicio de directorio X.500
El conjunto de protocolos de la serie X.500 propuesto por la ITU definen un

servicio de directorio global y distribuido, que posibilita la localizacin de recursos en
entornos abiertos. Por lo tanto este servicio es el candidato ideal para mantener los
certificados de clave pblica, en particular de la recomendacin estructura de
autentificacin del Servicio de Directorio X.509.
La recomendacin X.509 define la infraestructura necesaria para que los usuarios
(personas o aplicaciones) del directorio puedan acceder obtener de l informacin de
autentificacin de sus interlocutores, as como del formato de los certificados.,
establece:
Pgina 106
La forma en la que se almacena la informacin de Autentificacin en el

directorio.
Cmo puede obtenerse esta informacin.
El marco en el que se crea esta informacin.
Tres formas en las que las aplicaciones pueden hacer uso de esta informacin
para obtener servicios de autentificacin.
Se definen dos niveles de autentificacin:
1. Autentificacin simple: Basada en passwords para la verificacin de identidad,
que ofrece slo proteccin limitada contra accesos no autorizados.
2. Autentificacin fuerte: Basada en mtodos criptogrficos, en concreto de clave
pblica, ofrece el requisito mnimo para proporcionar servicios de seguridad.
Los certificados de clave pblica pueden mantenerse en el directorio como atributos,
pudiendo ser comunicados libremente y obtenidos del directorio de la misma forma que
el resto de la informacin del mismo. Los certificados se crean por procedimientos offline, y son puestos en el directorio por su creador. La generacin de los certificados de
usuario se realiza por una Autoridad de Certificacin off-line, es decir, completamente
separada de las DSAs (Director Service Agent) del Directorio.
6.5.7
Notara Electrnica: Terceras Partes Confiables
Un notario electrnico es una tercera parte en la que confan los usuarios de una
red pblica de datos. Debe ser capaz de demostrar que un mensaje fue enviado y
recibido, as como confirmar el contenido del mensaje. Es el equivalente del sistema
manual que se utiliza profusamente en la actualidad en el comercio internacional para
demostrar que la identidad del originador de un documento y el contenido de ste son
autnticos.
Son muchos los documentos que requieren una fecha otorgada por un organismo
independiente y confiable, como por ejemplo: notaras, documentos oficiales, etc. Este
es uno de los servicios que podra ofrecer una Tercera Parte Confiable (TPC), aadiendo
al mensaje un sello de tiempo, firmando mensaje y sello con su clave privada, casando
de esta forma la informacin del documento con la referencia temporal. Una Autoridad
de Certificacin es otro ejemplo de TPC.
6.6
Alternativas de seguridad en entornos EDI
Son muchas las iniciativas que en la actualidad se estn realizando en tomo ala
seguridad. No puede decidirse que sea fcil para un usuario decantarse por una de las
mltiples alternativas que ofrece el mercado, aunque es importante sealar que son ms
los puntos de coincidencia. En este apartado se analizan alguna de estas soluciones
haciendo hincapi en las iniciativas de EDIFACT.
Bsicamente, podemos distinguir las siguientes soluciones:
MHS-X400 del ITU
PEM (Privacy Enhanced Mail)
MOSS (MIME Object Security Services)
Pgina 107
Estndares sobre Seguridad en EDI de UN/EDIFACT.
6.6.1
MHS-X.400
Una serie de recomendaciones X.400 desarrollada., por ISO e ITU, establecen

los principios fundamentales de la infraestructura de un Sistema de Transferencia. de
Mensajes (MTS) capaz de transportar cualquier tipo de mensajes, tanto interpersonales
como binarios, como facilidades como las notificaciones de entrega. Utilizando el
mismo MTS del correo electrnico X.400 y el X.435 define un nuevo tipo de mensajes
cuya cabecera difiere ligeramente de la de los mensajes interpersonales (IPMS),
especfica para el transporte de mensajes EDI. Tanto el agente de usuario (UA) como el
almacenamiento intermedio de mensajes (Message Store, MS) si existen son especficos
de X.435, ya que deben ser capaces de entender la cabecera de mensaje especial del
X.435.
Los servicios de seguridad definidos en X.435 extiende aquellos definidos en la
recomendacin X.402 (genricos de X.400):
Prueba de Notificacin EDI: Permite al origen de un mensaje tener la
notificacin de que ste ha sido recibido, y la Responsabilidad EDIM (EDI Message) ha
sido aceptada, reenviada o denegada (puede proporcionarse mediante el servicio de
Integridad de Contenido).
Prueba de recuperacin: Permite al administrador de un MS tener la
notificacin de que un determinado mensaje ha sido recogido del EDI-MS por un EDIUA. La implementacin de este servicio es una cuestin local.
Prueba de Transferencia: Permite a un MTA o MD tener corroboracin de
que un mensaje ha sido transferido (reenviado) a otro MTA en otro dominio. La
implementacin de este servicio es un cuestin local.
No Repudio de Notificacin EDI: Proporciona al origen de un mensaje la
prueba irrefutable de que ste ha sido recibido y la responsabilidad EDIM ha sido
aceptada, reenviada o denegada.
No repudio de Transferencia: Proporciona aun MTA o MD tener la prueba
irrefutable de que un mensaje ha sido transferido (reenviado) a otro en otro dominio. La
implementacin de este servicio es una cuestin local.
No repudio de Contenido: Proporciona al usuario la prueba irrefutable de la
autenticidad e integridad del contenido del mensaje. Puede implementarse de dos
formas: por mecanismos de Notarizacin o bien uti1izando el servicio de seguridad de
No Repudio de Origen aplicado al contenido del mensaje ya la Notificacin EDI del
contenido del mismo.
6.6.2
PEM
Pgina 108
El protocolo PEM (privacy Enhanced Mail), recogido en la serie de

especificaciones RFCs 1421-1424 (del Internet Engineering Task Force's PEM Working
Group), fue diseado como un servicio extremo a extremo, para dotar de servicios de
seguridad a los agentes de un usuario de servicios de correo electrnico existentes,
aunque dirigido preferentemente a usuarios de la comunidad Internet.
Los servicios de seguridad extremo a extremo de PEM se relacionan con algunos de los
servicios de seguridad del MHS-X.400: Autentificacin del origen del mensaje,
confidencialidad del contenido (opcional), integridad del contenido, y no repudio del
origen. Para proporcionar estos servicios PEM contempla dos enfoques alternativos para
la Autentificacin y gestin de claves: uno basado en clave secreta y otro basado en
clave pblica. Sealar que en la actualidad PEM slo soporta mensajes de correo
electrnico basados en texto ASCII. Aunque PEM utiliza un subconjunto compatible de
servicios de seguridad del X.400, utilizando una infraestructura de certificacin de clave
pblica compatible. no pueden interoperar directamente. Existen iniciativas para
incorporar PEM como cuerpo en X.400, lo que permitir el uso de pasarelas que
conecten sistemas SMTP (protocolo de transporte de correo Internet) y X.400 para el
paso de mensajes PEM protegidos. PEM utiliza un esquema de codificacin de
caracteres que maximiza la probabilidad de que un mensaje PEM pueda transitar de
forma transparente por pasarelas de correo con otros sistemas de correo electrnico.
6.6.3
MOSS
El protocolo, de reciente definicin MOSS (MIME Object Security Services) es

muy similar al PEM y aplica servicios de cifrado y firma digital a objetos MIME
empleando tcnicas de clave pblica. Un usuario para hacer uso de l, para los servicios
de seguridad MOSS, necesita un par de claves pblica/privada. Los usuarios deben
intercambiar sus claves pblicas con aquellos usuarios con los que deseen intercambiar
correo electrnico MOSS. Este proceso puede hacerse manualmente mediante
mecanismos provistos por MOSS o va certificados X509.
6.7
6.7.1
PGP
Introduccin
PGP es un programa que utiliza el sistema de encriptacin de clave asimtrica,

que sirve para encriptar correo electrnico y ficheros. Permite intercambiar correo
seguro con personas con las que nunca se ha tenido contacto, utilizando el sistema de
clave pblica-privada, y de hecho se ha convertido en un estndar en Internet.
Se recomienda usar este tipo de encriptacin siempre que se utilicen redes no
seguras para enviar mensajes, tal y como Internet. Resulta relativamente sencillo atacar
los sistemas UNIX, o permanecer a la escucha para conocer e incluso adulterar el
contenido del correo electrnico.
Se han propuesto otras alternativas, pero PGP es gratuito y est disponible para
todo tipo de hardware y sistema operativo, adems puede conseguirse como una
aplicacin independiente o como un programa integrado de correo electrnico.Su autor
Phil Zimmermann ha tenido muchos problemas legales, sin embargo, en una reciente
sentencia, se ha visto libre de toda acusacin de vulnerar la ley americana sobre
criptografa.
Pgina 109
No obstante presenta ciertos problemas respecto a la distribucin de claves y no

presenta una interfaz agradable, los programas que hay bajo Windows tienen que
invocar un Shell MS/DOS para ejecutar en s PGP. La compaa ViaCrypt comercializa
una versin con completa funcionalidad en diversos entornos operativos.
6.7.2
Definiciones
Formato Radix-64: Formato alternativo a un fichero binario. Permite utilizar el

sistema de envo de correo en lneas de 7 bits, convirtiendo el fichero a caracteres
imprimibles ASCII.
Huella: es una secuencia de bytes en hexadecimal que se puede utilizar para
verificar una clave pblica utilizando el telfono o el papel.
Anillo de claves: Bases de datos o fichero donde se almacenan las claves en el
sistema PGP.
6.7.3
Ideas de diseo
Cuando Phil Zimmermann pens en el desarrollo de un programa para aportar

seguridad a la transmisin del correo electrnico, lo hizo pensado en lo siguiente:
Que estuviera disponible para todas las plataformas hardware y software, y de
forma gratuita.
Basarse en los algoritmos ms robustos de encriptacin (RSA., IDEA y MD5), y
an siguen sindolo.
Aplicabilidad para un amplio rango de aplicaciones.
Que no estuviera desarrollado por ninguna agencia gubernamental, ni asociacin
de ningn tipo.
Debido a estas consideraciones ha habido problemas para su implantacin a nivel
mundial debido a las leyes de exportacin de USA respecto a los productos
criptogrficos.
6.7.4
Servicios que proporciona
Autentificacin: PGP usa el sistema de encriptacin RSA, suficientemente probado

y fcil de implementar, y el sistema HASH MD5 tambin desarrollado por Ron Rivest
para formar la firma digital para asegurar al receptor la autenticacin del mensaje. La
secuencia es la siguiente:
El remitente crea el mensaje

Se usa MD5 para generar un cdigo HASH del mensaje de 128 bits.
El cdigo MD5 generado se encripta con la clave privada del remitente usando
RSA.
El receptor desencripta el mensaje con la clave pblica del remitente con RSA, y
recupera el cdigo HASH.
El receptor genera uno nuevo cdigo HASH y lo compara con lo desencriptado.
Si ambos coinciden indica que el mensaje es autntico.
Pgina 110
Se usa la combinacin de MD5 y RSA para conseguir ms efectividad. Debido a las

caractersticas de RSA el receptor se asegura que el poseedor de la clave privada puede
generar la firma. Por las caractersticas de MD5 el receptor se asegura que nadie, a parte
del remitente, puede haber generado un mensaje que de lugar al cdigo HASH recibido.
Confidencialidad: Este servicio se proporciona mediante la utilizacin del sistema
de encriptacin IDEA, considerado como ms robusto que DES. Adems, en el proceso
se utiliza una clave convencional una sola vez de 128 bits, una en cada sesin, generada
de forma aleatoria. Esta clave de sesin se liga al mensaje y se transmite con l de la
siguiente forma:
El remitente general el mensaje y una clave aleatoria de 128 bits para utilizarla
como clave de sesin. Q El mensaje se encripta con la clave de sesin usando
IDEA.
La clave de sesin se encripta con RSA usando la clave pblica del receptor, y
se aade al mensaje.
El receptor utiliza RSA con su clave privada para desencriptar el mensaje y
recuperar la clave de sesin.
Con la clave de sesin se desencripta el mensaje.
Se usa la combinacin IDEA-RSA porque IDEA es bastante ms rpido que RSA.

RSA resuelve el problema de la distribucin de la clave de sesin, ya que slo el
receptor es capaz de recuperar la clave que est ligada el mensaje. De forma que el
sistema es seguro en la misma medida que lo es el sistema RSA. PGP posibilita al
usuario usar claves de diversos tamaos:
Casual: con 384 bits. Se sabe que se puede romper pero con mucho esfuerzo.
Comercial: 512 bits. Con posibilidad de ser franqueada si se dispone de mucha
capacidad
de
clculo.
Militar: 1024 bits. Se considera que es infranqueable.
O sea, el remitente primeramente firma el mensaje con su clave privada. Encripta el
mensaje con la clave de sesin, y encripta la clave de sesin con la clave pblica del
receptor.
Integridad: La firma tiene la particularidad de que depende tanto de la clave
privada del remitente como del contenido del mensaje. De forma que se si altera el
mensaje la firma que se haba generado no sirve.
Compresin: Por defecto PGP comprime el mensaje despus de aadir la firma
pero antes de encriptar el mensaje utilizando el sistema PKZIP. De esta forma el
mensaje real a enviar es menor. Esto, adems, proporciona mayor robustez al sistema
criptogrfico, ya que el sistema comprimido tiene menos redundancia que el fichero sin
imprimir.
Compatibilidad: Hay sistema de correo electrnico que solo permiten el uso de
caracteres de 7 bits, aunque lo normal es utilizar 8bits. PGP utiliza el sistema de
conversin radix-64 para convertir mensajes de 8 bits a 7 bits. El sistema funciona
asignando cada grupo de 3 octetos de datos binarios en 4 caracteres ASCII. Esto hace
Pgina 111
que el mensaje se aun 33% mayor, pero el tamao real a enviar viene compensado por
el sistema de comprensin aplicado.
PGP se puede configurar para convertir a radix-64 solamente la firma aadida al
texto. De esta forma se posibilita al receptor la capacidad de leer el mensaje sin
necesidad de usar PGP, pero puede usarlo para comprobar la firma.
Gestin de Claves: Este servicio suele ser el taln de Aquiles de los sistemas
criptogrficos: tal y como indica Phil Zimmermann en el manual de PGP: El problema
de proteger las claves pblicas de suplantacin es lo ms complicado en un sistema real,
es el taln de Aquiles del sistema criptogrfico de clave pblica y gran cantidad de
software debe su existencia para intentar resolver este problema.
Para evitar tener un fichero de claves pblicas falsas, se puede pasar la informacin
buena en disquete, por correo normal, verificando la clave por telfono, o bien transferir
y confirmarlo a una tercera parte fiable.
Se puede utilizar otro sistema: Usar un servidor fiable y verificar la entrega de la
clave pblica monitorizando la huella PGP del emisor.
6.8
Estndares de seguridad EDIFACT
En abril de 1991 UN/EDIFACT establece el Grupo de Trabajo de Seguridad

(SJWG Security Joint Work Group) con el objetivo de crear los estndares para dar
seguridad (extremo a extremo) a los mensajes EDIFACT.
Previos a la creacin del SJWG, existan dos documentos UN/EDIFACT y otros dos
del ANSI ASC X.12:
Digital Signatura in EDIFACT, 29 de noviembre de 1990, creado bajo el

programa TEDIS de la Comisin de las Comunidades Europeas.
Security Framework for EDIFACT, 14 de marzo de 1991, preparado por el MD
EDIFACT Banking Security Group.
ANS X12.58 y XI2.42, que no pueden considerarse como una solucin completa
ya que no consideran la firma digital y el no repudio, solo integridad,
autentificacin y confidencialidad.
Los criterios bsicos seguidos por EDIFACT para implementar seguridad en EDI
han sido:
Permitir que los servicios de seguridad sean implementados por las propias
partes involucradas, extremo a extremo, por lo que la seguridad se aplicar en el
nivel de mensaje, no debiendo implicar cambios en los mensajes individuales,
sino que, la solucin de seguridad ser global y se aplicar de igual forma a todo
tipo de mensaje de cualquier aplicacin comercial EDI.
La seguridad debe ser Transparente al protocolo de comunicacin que se
utilicen, e independiente de los mecanismos de transporte, por lo que cualquier
protocolo de transferencia como OFTP, FTAM o X.400, no tiene por que saber
si el mensaje EDI lleva o no seguridad.
Pgina 112
La seguridad debe ser independiente de los algoritmos criptogrficos que se

empleen. En este sentido, lo usuarios EDI deben poder elegir de una lista de
algoritmos, segn convenga a sus actividades.
Los resultados obtenidos por el SJWG se presentan en los siguientes documentos:

Recomendations for UN/EDIFACT message Level security
EDIFACT Security Implementation Guidelines
Secure Functional Acknoledgment Message (FUNACK)
Edifact CIPHER Message
EDIFACT Security Interplementation Guidelines: CIPHER Message.
CERSVC por KEYMAN Message.
Los servicios de seguridad contemplados en la normativa EDIFACT son los
siguientes:
1.
2.
3.
4.
Integridad de la secuencia y/o del contenido del mensaje.

Autentificacin del origen del mensaje.
No-repudio de origen.
No repudio de recepcin. Para obtener este servicio se usa un mensaje de
respuesta, llamado AUTACK, que se enva de origen a destino para confirmar la
recepcin y evitar el no repudio de recepcin. En esta respuesta el destino puede
firmar el mensaje recibido y enviar esta firma al origen en el mensaje AUTACK
5. Confidencialidad. Este servicio suele ofrecerse mediante mecanismos de
cifrado simtrico (de clave secreta) por cuestiones de rendimiento. Para obtener
este servicio de seguridad se utiliza un nuevo tipo de mensaje, CIPHER. que
contiene el criptograma del mensaje.
Alternativas al aplicar seguridad a los mensajes EDI:
Integrados en el mensaje: se introducen grupos especficos de segmentos de
seguridad para proteger el nivel del mensaje: La cabecera y pie de seguridad. Se
pueden incluir en cualquier mensaje EDI y se colocan despus de la cabecera de
mensaje (UNH) y antes de pie de mensaje (UNT).
De forma separada mediante un mensaje especial, AUTACK, que permite
que se apliquen mecanismos de seguridad a mensajes ya enviados.
Mediante el mensaje CIPHER.
Estado actual de la normativa en seguridad EDIFACT, aunque parece que se estn
produciendo cambios:
El restado actual de las estructuras de seguridad (cabeceras y pies) y del mensaje
AUTACK es de for trial use.
El mensaje CIPHER no est ni siquiera en estado 0. El SJWG est considerando
dos soluciones: integrar la confidencialidad dentro de la sintaxis o continuar con
el CIPHER como mecanismo separado, siendo la primera de ellas la de mayores
posibilidades.
El mensaje KEYMAN ha sido desarrollado recientemente para el proyecto
TEDIS SAM, pero slo ha sido distribuido dentro del SJWG. El SJWG y el
UN/EDIFACT no han decidido an sobre el futuro de KEYMAN.
Pgina 113
6.9
Conclusiones
Aunque las soluciones criptogrficas se encuentran en un estado muy maduro,

no hay un nico estndar de seguridad para el correo electrnico, por lo que actualmente
son difciles soluciones abiertas, que pueden interoperar con los mltiples sistemas de
correo existentes. Sin embargo, hay ciertos aspectos que s son comnmente aceptados,
como es el caso del uso del estndar de servicio de directorio X500 como elemento
fundamental para una infraestructura de seguridad basada en certificados de clave
pblica.
Pgina 114
CAP. 7
IMPLANTACIN
7.
7.1
Pasos para la implantacin de EDI

Introduccin
La implantacin de EDI requiere dos planteamientos, uno enfocado hacia los

temas tcnicos y el otro hacia los temas de organizacin y culturales. Aunque
posiblemente la comprensin exacta de los detalles de funcionamiento de EDI pueda
llevar algn tiempo, desde el punto de vista tecnolgico EDI no es complejo. Adems,
la estructura de EDI en cuanto a normas, software y redes, est implantada y
funcionando. Es necesario que las firmas que utilizan EDI comprendan y planteen los
temas de la implantacin tecnolgica, sin embargo, estos temas no suelen plantear
dificultades importantes para las empresas, pues en la mayora de los casos se cuenta
con el asesoramiento del Proveedor de Servicios EDI.
Por otro lado, la resolucin de los temas de organizacin y culturales vinculada
con la implantacin de EDI es bastante ms difciles para la mayora de las empresas.
EDI cambia la forma en la que trabaja una empresa y relacin con otras organizaciones.
Es la envergadura de los cambios que exige el aprovechamiento eficaz de la tecnologa,
lo que hace difcil la implantacin de EDI. Puesto que EDI cambia las relaciones e
interacciones tanto dentro como fuera de la organizacin, la gestin del proceso de
cambio es difcil. Por su propia naturaleza, la integracin total de EDI dentro de una
compaa requiere la coordinacin del personal de compras, contabilidad, transporte,
sistemas, auditora, cuestiones jurdicas etc., adems, puesto que EDI es
intercorporativo, es necesario duplicar la coordinacin departamental en la organizacin
del interlocutor comercial. Por eso, el proceso de cambio de EDI requiere una
planificacin cuidadosa y una gestin minuciosa.
Este captulo tiene como objetivo presentar unas directrices para la implantacin
de EDI. Esta gua ofrece unas pautas a seguir a la hora de decidir la utilizacin de EDI,
de determinar el tipo de EDI, y de establecer el programa EDI. En la figura siguiente, se
describen los pasos bsicos cuya realizacin es necesaria para implantar con xito un
programa EDI. Aunque se demuestran y se discuten los pasos en orden secuencial, a
menudo se realizan actividades mltiples de forma concurrente.
Fases en la implantacin de EDI
Decidir la estrategia
Obtener apoyo de la Alta Direccin
Establecer el Equipo del Proyecto
Impartir/obtener Formacin
Realizar consultora de EDI
Desarrollar anlisis de Coste/Beneficios
Elegir participantes
Disear con interlocutores
Establecer contratos EDI
Pgina 115
Realizar piloto
Revisar piloto
Ampliar uso
Hacer publico
7.2
Decidir la estrategia EDI
La primera decisin que hay que tomar para la implantacin de EDI es la de

determinar el planteamiento o estrategia global para EDI, lo que consta de dos
componentes:
El grado de extensin del esfuerzo EDI
El grado de integracin de EDI con las aplicaciones internas.
El nivel de extensin se refiere a la amplitud o alcance que tendr EDI dentro de la
empresa. En un extremo, se puede implantar EDI solamente para una transaccin,
dentro de un departamento, para su uso con un solo interlocutor comercial. En el otro
extremo, se puede implantar EDI para poder incorporar transacciones mltiples, a todos
los niveles, con todos los interlocutores comerciales.
El nivel de integracin se refiere a la forma en la que se integra EDI con las
aplicaciones internas. En un extremo, se puede plantear un sistema puerta a puerta en el
que la transferencia de datos entre interlocutores sea electrnica, mientras que el enlace
con los programas de aplicaciones sea manual. En el otro extremo, existe la integracin
total en la que se realizan todas las transferencias de datos entre interlocutores de
aplicacin a aplicacin y se puenteen todos los programas de aplicaciones.
En la mayora de las organizaciones, la implantacin de EDI constituye un proceso
de evolucin, progresando a travs de varios niveles diferentes de extensin e
integracin. Se han identificado tres niveles de implantacin:
1. En una implantacin de nivel 1, se utiliza EDI por un solo departamento y para
un solo conjunto de transacciones. Solo unos cuentos interlocutores comerciales
utilizan EDI, siendo su utilizacin opcional por parte de los mismos. En muchos
casos, se utiliza una estructura puerta a puerta con PCs.
2. En una implantacin de nivel 2, departamentos mltiples de la organizacin
utilizan EDI. Se intercambia conjuntos de transacciones mltiples con un gran
nmero de interlocutores comerciales. Se fomenta mucho el uso de EDI y
posiblemente sea un requisito para los interlocutores comerciales. EDI est
integrado con las aplicaciones internas.
3. En una implantacin de nivel 3, EDI est totalmente integrado dentro de la
organizacin. El EDI en su conjunto est integrado con aplicaciones internas que
se habrn reestructurado y puenteado. La compaa lo considera una forma de
vida y se espera que todos los interlocutores comerciales lo usen.
La seleccin de una estrategia EDI depender de varios factores. Ante una cantidad
limitada de recursos, una falta de inters de los interlocutores comerciales o la
indiferencia de la alta direccin, la seleccin ms apropiada sera la de comenzar con el
nivel 1 (y no tener esperanzas de salir de all). Sin embargo, ante una situacin de crisis
(como con la que se ha enfrentado la industria del automvil), unos interlocutores
Pgina 116
comerciales exigentes o el entusiasmo de la alta direccin, sera mejor prever la

implantacin al nivel 2 o al nivel 3 desde el principio.
7.3
Obtener apoyo de la alta direccin

Por qu es necesario este apoyo?
Independientemente de la estrategia escogida, es necesario conseguir el respaldo

de la alta direccin, cuanto antes mejor. Es necesario el apoyo desde arriba para
cualquier cambio estructural importante, pero este apoyo es an ms importante para
EDI puesto que requiere una coordinacin interdepartamental y, adems, porque su
perodo de amortizacin puede ser largo.
7.3.1
Coordinacin interdepartamental
Para la implantacin de EDI, se requiere un esfuerzo que atraviesa fronteras. En

otras palabras, normalmente la implantacin de EDI afecta a varias reas funcionales
dentro de la organizacin. La versin aplicacin a aplicacin totalmente puenteada de
EDI afectar de modo significativo no slo a compras, contabilidad y transporte, sino
tambin a la gestin de sistemas y, en muchos casos a ventas o comercializacin.
Adems, en la mayora de las organizaciones, la plantilla jurdica y de auditoria tambin
est muy interesada en los cambios que se derivan de EDI. Asimismo, no solo
impactar EDI en todas estas reas funcionales, requiriendo as el apoyo de las mismas,
sino tambin tender a cambiar los flujos y procesos tradicionales, requiriendo dichos
cambios un apoyo slido desde arriba.
7.3.2
Periodo largo de amortizacin
En caso de una integracin total de EDI dentro de la organizacin, la inversin

inicial suele ser alta, mientras que los beneficios producidos por dicha inversin, al
menos al principio, pueden ser bajos. En general, los costes de EDI son altos durante las
primeras fases de la implantacin, y luego se van reduciendo de modo significativo.
Normalmente, hay pocos ahorros monetarios durante la implantacin inicial, y luego se
van incrementando de forma significativa conforme aumenta el volumen de EDI. Se
necesita el apoyo de la alta direccin para asegurar que el esfuerzo EDI no quede
anulado debido a prdidas iniciales.
Cmo se podr obtener este apoyo?
Existen varias formas de vender EDI a la alta direccin. Se puede presentar EDI
como:
Un programa para mejorar la productividad
Una maniobra estratgica y competitiva
Una necesidad para sobrevivir
7.4
Establecer el equipo de proyecto EDI
Pgina 117
No slo es crtico el apoyo de la alta direccin para que la implantacin sea un

xito EDI, sino tambin lo es conseguir una amplia base de apoyo dentro de la
organizacin. Puesto que la implantacin de EDI afecta a tantas organizaciones
funcionales y de personal dentro de la empresa, es necesario constituir un equipo EDI
con miembros procedentes de toda la organizacin para que sea un xito.
El equipo EDI, que deber asumir la responsabilidad total del plan de implantacin
de EDI, debera constar con representantes de cuatro reas principales:
reas funcionales tales como compras, contabilidad y administracin.
reas de personal tales como la jurdica y auditoria.
reas tcnicas tales como sistemas de informacin y proceso de datos.
reas de enlaces tales como ventas, servicios de asistencia al clientes o
comercializacin.
Es importante incluir en el equipo representantes de todos los departamentos que
utilizarn o que se vern afectados por EDI. Su participacin en el equipo seguramente
producir la impresin de propiedad de la idea de EDI, o sea, los usuarios se sentirn
como parte integral de la realizacin de EDI y se encontrarn ms dispuestos a trabajar
para que su uso sea aun xito.
7.4.1
Jefe de equipo
Es indispensable un jefe de equipo EDI competente y entusiasta para asegurar el

xito de la implantacin. En un estudio de los primeros usuarios de EDI, se percataba de
que el factor ms importante para lograr la implantacin haba sido la presencia de un
defensor franco y hbil dentro de la organizacin. Aunque a menudo se ve EDI desde la
perspectiva de la aplicacin de una nueva tecnologa informtica, la mayora de los
usuarios de EDI se han dado cuenta que el jefe de equipo necesita tener una amplia
perspectiva comercial. Es necesario tener una persona con una orientacin al negocio y
con conocimiento de las necesidades de la compaa. Adems, como EDI requiere un
esfuerzo de conversacin, tanto en el mbito interno, con las reas funcionales y con la
direccin, como en el mbito externo con los interlocutores comerciales, es importante
que el jefe de equipo sea un defensor persuasivo del esfuerzo EDI.
7.4.2
Impartir/obtener programas de formacin.
La formacin de los usuarios del sistema EDI es imprescindible para el xito de

la implantacin del mismo. La organizacin necesita tener una comprensin perfecta de
EDI y de como funciona. Se puede disponer enseguida de informacin y formacin
sobre EDI a travs de grupos de accin de la industria, de comits normativos y
proveedores de servicio EDI. Se debera aprovechar todas estas fuentes para educar a
los miembros de la organizacin, as como a los interlocutores comerciales, acerca del
sistema EDI.
7.4.3
Realizar una consultora EDI
Pgina 118
Para el xito de EDI, es necesario entender plenamente el funcionamiento del

sistema que EDI va a sustituir. Es necesario conocer tanto el flujo de informacin (en
forma de papel, verbal o electrnica) como la estructura de datos de las aplicaciones. Se
debera revisar los siguientes elementos antes de realizar la implantacin de EDI:
Cul es la informacin que se cambia con los interlocutores comerciales?
Debera incluir los documentos formales tales como pedidos de compra,
facturas, etc., as como los documentos informales tales como mensajes,
memorndum y llamadas telefnicas para comprobar la situacin.
Cmo y dnde se inicia la informacin Cuantas copias se producen, y
con qu formato? Quin recibe copias? Con qu propsito? Durante
cuanto tiempo se almacenan las copias, y en qu formato?
Cuales son las medidas de control y notificacin que se usan? Los
informes de estado? Los registros para la auditoria contable?
Cul es la informacin especfica que se necesita para las aplicaciones
informticas actuales? Qu formatos de datos? El flujo entre las
aplicaciones? Introduccin de datos?
De qu informacin se dispone en las aplicaciones? Qu resultados se
producen? Cul es el formato de las salidas?
Una vez resumido y comprendido el flujo de informacin actual, se deberan
identificar los cambios necesarios para la implantacin de EDI. Entre ellos se
encuentran las siguientes posibilidades:
El uso de la introduccin electrnica de datos en lugar de la manual
El desarrollo de una interface de datos entre aplicaciones y el mdulo EDI
La necesidad de realizar un puente entre aplicaciones si departamentos mltiples
utilizan la misma informacin.
Una vez resumidos los flujos de papel actuales as como los flujos de EDI, se deber
iniciar el desarrollo del software. Para usar un paquete de traduccin EDI, primero es
necesario extraer los datos de los programas de aplicacin, colocndolo en el fichero
plano de campos fijos. Para llevar a cabo este esfuerzo de programacin, es
indispensable conocer de antemano los datos que se necesitan para EDI y determinar
donde residen los datos y con qu formato.
7.4.4
Desarrollar anlisis preliminar de constes/beneficios
Aunque en muchas compaas se implantan sistemas EDI por razones

estratgicas y no para reducir coste, sigue siendo til un anlisis de costes/beneficios y a
menudo es necesario para conseguir el apoyo de la compaa al programa EDI. Entre
los puntos que se deben considerar en un anlisis de costes/beneficios, se debern
incluir los siguientes:
Costes
Costes de arranque
Hardware
Software de usuarios
Formacin
Pgina 119
Costes contnuos
Costes de comunicaciones
Costes de mantenimiento de software
Formacin
Beneficios
Directos
Reduccin del teclado
Ahorros de personal
Inventario reducido debido a una informacin ms rpida
Indirectos
Mejor aprovechamiento del personal
Mejor acceso y uso de informacin
Ventaja estratgica conseguida por el uso de EDI
7.5
Elegir participantes de EDI
Una vez desarrollado el apoyo del concepto EDI y constituido un equipo, habr que
tomar decisiones operacionales relativas a la implantacin, entre ellas las siguientes:
Se utilizar una red de terceros? En caso afirmativo Cuales?
Se desarrollar o se comprar el software? Si se compra Quin ser el
proveedor?
Cuales sern los conjuntos de transaccin implantados?
Cuales sern los departamentos de la compaa implicados?
Cuales sern los interlocutores comerciales implicados?
7.5.1
Intercambios
Aunque muchas organizaciones piensan usar EDI para todos los conjuntos de
transaccin apropiados normalmente se selecciona solo uno o dos documentos para la
comprobacin y operacin iniciales de EDI. Para la seleccin de los conjuntos de
transaccin especficos que se desea implantar, se debera tomar en consideracin los
siguientes factores:
Una solicitud de un interlocutor comercial importante
Rentabilidad prevista en funcin de la reduccin en el papeleo
Disponibilidad de normas
Utilizacin por otros en la industria
7.5.2
Secciones o departamentos de la compaa
Pgina 120
Para la seleccin de los primeros departamentos o secciones que van a usar EDI, se
deberan examinar varios factores.
1. La seccin debera tener personal que est interesado en EDI
2. La seccin debera tener un gran volumen del tipo de transacciones que se est
considerando para el proyecto EDI
3. La seccin debera tener los recursos y capacidad necesarios para la
implantacin de EDI
Finalmente, en caso de considerar para EDI varias secciones geogrficamente
dispersas, la seleccin de la seccin ms cercana a la sede social contribuye a
promocionar una coordinacin ms estrecha y un mayor nivel de apoyo.
7.5.3
Interlocutores comerciales
Para la seleccin de los interlocutores comerciales con los que iniciar un sistema
EDI, lo normal es buscar interlocutores comerciales con las siguientes caractersticas:
Representan un alto volumen de las transacciones, con un bajo valor monetario
por transaccin
Estn realizando EDI en la actualidad
Existe una buena relacin con ellos
A la hora de identificar los interlocutores comerciales potenciales, en primer lugar,
la organizacin debera identificar sus interlocutores claves en funcin del volumen de
importancia. Mediante un anlisis cuidadoso de los interlocutores comerciales, se
debera poder identificar el 20% de ellos a los que corresponden el 80% de las
transacciones. Son estos interlocutores comerciales los que seguramente producirn la
mayor rentabilidad por lo que se refiere a una reduccin del papeleo y una mayor
precisin.
Tambin es de utilidad encontrar un interlocutor comercial que est usando EDI con
otros. La implantacin de EDI se vuelve bastante ms fcil cada vez que se incorpora al
sistema un interlocutor comercial nuevo. Por lo tanto si se puede identificar a un
interlocutor clave que se est ya comunicando de forma electrnica con otra empresa, la
implantacin en la organizacin ser mucho ms fcil. De esta forma, se pueden
aprovechar los conocimientos previos de EDI del interlocutor comercial. Si en la
actualidad ninguno de los interlocutores comerciales est utilizando EDI, es importante
identificar a un interlocutor que est muy interesado en EDI. Aunque clientes o
proveedores importantes podran imponer EDI a sus interlocutores comerciales, la
implantacin resulta mucho ms fcil cuando existe entusiasmado con el proyecto por
las dos partes.
EDI requiere cooperacin y coordinacin entre los interlocutores comerciales. El
esfuerzo exige que las partes compartan informacin, que acuerden un gran nmero de
pequeos detalles y que trabajen juntas en estrecha colaboracin. Existe una mayor
posibilidad de xito con EDI cuando hay un alto nivel de confianza en la relacin con el
interlocutor antes de la implantacin de EDI.
Pgina 121
Se debera destacar un punto ms referente a la seleccin de los interlocutores

comerciales. Aunque resulta totalmente lgico implantar EDI con el interlocutor de
mayor volumen y de ms confianza, quizs se debera considerar iniciar EDI con otro
cliente que no sea el mejor. Igual que con cualquier otro sistema nuevo, durante la
primera realizacin con EDI se producirn algunos errores que habr que resolver. Es
mejor empezar EDI, en caso de ser posible, con un buen interlocutor comercial que ya
ha realizado EDI con otros, en lugar de empezar con su mejor cliente. De esta forma, no
se corre el riesgo de perjudicar a su mejor cliente durante el proceso de aprendizaje de
EDI.
7.6
Disear con interlocutores comerciales
Aunque en las normas EDIFACT se establece la estructura bsica de los

mensajes EDI, las normas no son suficientes por s solas para establecer de forma exacta
lo que se desea comunicar entre interlocutores comerciales. Por ejemplo, las normas
permiten la identificacin d un producto a travs del uso de un cdigo de identificacin
de producto, sin embargo, no especifican el tipo de cdigo (nmero de catlogo del
vendedor, nmero de pieza del comprador, etc.) que se debera usar. Estas decisiones se
dejan al juicio de los interlocutores comerciales.
Una vez establecida una relacin electrnica entre interlocutores comerciales, los
mismos debern determinar los siguientes aspectos, entre otros:
Cuales son los conjuntos de transaccin que se van a enviar?
Cuales son los elementos y segmentos de datos opcionales que se van a
utilizar?
Cuales son los tipos de identificacin que se utilizarn para: Productos,
Compaas, Puntos de envo?
Cuales son los protocolos de comunicacin que se utilizarn (s es directo)?
Esta parte de EDI requiere mucho tiempo pero es indispensable. El proceso de
diseo establece las reglas bsicas para el proyecto EDI con cada interlocutor comercial.
7.7
Acuerdo de intercambio
En algunos casos, los temas planteados anteriormente se exponen en contratos

EDI. Como el uso de EDI cambia tanto el formato de la informacin como el flujo de la
misma, muchas compaas preparan acuerdos de intercambio EDI para su uso con
interlocutores comerciales.
Estos acuerdos definen los siguientes aspectos:
Transacciones que se enviarn por medios electrnicos
Uso de una red de terceros
Reparto de los costes de transmisin entre los interlocutores comerciales
Los trminos y condiciones que se aplican a las transmisiones electrnicas
Identificacin de un director de proyecto o punto de contacto en cada ubicacin
Condiciones que regirn en los intercambios realizados por EDI
Pgina 122
Aunque no todos los usuarios de EDI realizan contratos con los interlocutores,
parece que el uso de contratos va en aumento. Los acuerdos de intercambio con los
interlocutores son especialmente tiles cuando se transmiten de forma electrnica los
pedidos de compras y las facturas. En un pedido de compras tradicional de papel, los
trminos y condiciones aparecen por escrito al dorso del formato del mismo, lo que por
supuesto no ocurre en el caso de un pedido de compras electrnico. Por lo tanto, a
menudo se exponen y se acuerdan los trminos y condiciones que se aplican a pedidos
de compras electrnicos en un contrato con el interlocutor comercial. De hecho, algunos
de los trminos de los pedidos de compras electrnicas son diferentes que los de los
pedidos de papel, en particular en lo que se refiere a las condiciones de pago. El uso de
EDI, especialmente cuando va asociado con pagos electrnicos, cambia a menudo los
plazos de los pagos, en cuyo caso puede resultar necesario volver a negociar las
condiciones de pago.
7.7.1
Otros contratos.
Los usuarios de EDI tambin tienen contratos con proveedores de servicios EDI
y con vendedores de software. En un contrato de terceros, normalmente se explican las
obligaciones y responsabilidades del tercero. En los contratos de software, se explican
las obligaciones, responsabilidades y costes, e indican las restricciones sobre el uso del
software (Por ejemplo, las restricciones sobre el nmero de emplazamientos en los que
se puede utilizar el software). En general, los contratos con redes de terceros y con
vendedores de software suelen ser contratos estndares facilitados por vendedores,
mientras que los contratos con los interlocutores comerciales son nicos para cada
situacin y son negociados entre ellos.
7.8
Realizar prueba piloto
Una vez diseado el sistema EDI, seleccionados los proveedores y establecidos los
interlocutores comerciales y las transacciones, se debera realizar una prueba piloto del
sistema. Normalmente, se realiza la prueba piloto en tres etapas:
Transmisin de datos ficticios.
Prueba en paralelo de la retransmisin electrnica y en papel.
Transmisin electrnica sin un backup de papel.
Si es posible, una organizacin debera ejecutar su prueba piloto con un nmero
limitado de interlocutores comerciales que tienen experiencia de EDI con otros
interlocutores comerciales.
La prueba piloto se efectuar en tres fases:
Transacciones ficticias
La primera fase de la prueba piloto debera ser la transmisin de datos ficticios,
para poder garantizar que se hayan hecho correctamente todos los enlaces, que
est funcionando el software y que se pueda enviar y recibir mensajes.
Pgina 123
Prueba en paralelo
La prxima etapa del piloto es una prueba de la transmisin de documentos de
compras reales, sin embargo, esta parte de la prueba debera ejecutarse en
paralelo con la transmisin de documentos de papel. En otras palabras, se enva
el mismo proceso (por ejemplo, un pedido de compras) tanto electrnicamente a
travs del sistema EDI como manualmente. Esta prueba en paralelo permite una
comparacin entre EDI y el sistema manual y, adems, permite a los usuarios
acostumbrarse al sistema antes de abandonar el sistema de papel. Asimismo, es
un modo til para identificar cualquier flujo de papel que se dej pasar durante
la consultara de EDI.
Prueba electrnica
La siguiente etapa de la prueba piloto consiste en usar el sistema EDI para un
nmero limitado de transacciones sin el sistema paralelo de papel. Es el paso
final en la comprobacin del sistema EDI antes de una implantacin ms
difundida.
7.9
Revisar resultados de prueba piloto y modificar
Normalmente, se ejecuta la prueba piloto hasta que todos los interlocutores

comerciales participantes se sientan cmodos con el sistema EDI. Este periodo de
tiempo variar de una organizacin a otra. Adems, en muchos casos, algunos
interlocutores estarn preparados a pasar del piloto a la fase de implantacin antes que
otros. En general, la duracin de la etapa piloto puede variar desde unas cuantas
semanas hasta varios meses. Tras la terminacin de la prueba piloto, se deber realizar
una revisin del conjunto del esfuerzo EDI para poder determinar si es necesario hacer
alguna modificacin antes de ampliar el sistema.
7.10
Ampliar uso
Cuando la compaa est preparada para ampliar el sistema EDI tras la fase piloto,
se debera fijar un programa de implantacin. En la mayora de las compaas se ha
comprobado que lo mejor es un programa de ampliacin incremental. Con este sistema
incremental, se incorporan nuevos interlocutores comerciales o se incorporan nuevas
transacciones, pero no al mismo tiempo, o sea, se realiza la ampliacin de una de las dos
maneras indicadas a continuacin:
Intercambio de las transacciones pilotos con nuevos interlocutores.
Intercambio de nuevas transacciones con los interlocutores comerciales
utilizando en el piloto.
7.11
Hacer pblicos los esfuerzos
Un paso final que resulta muy importante para el xito del proyecto EDI, es
hacer pblicas las actividades. Adems, cuan mayor es el nmero de interlocutores EDI,
mayores los beneficios. Por lo tanto, una vez puesto en operacin el proyecto EDI,
anncielo al mundo.
Pgina 124
La publicidad debera empezar dentro de la organizacin. El envo de

informacin a los directores funcionales y el personal de sistemas permitir fomentar el
uso de EDI por toda la compaa. Resaltando los beneficios que se consiguen con el uso
de EDI, se podr estimular su crecimiento dentro de la compaa.
Tambin es importante la publicidad de cara al exterior. Las conferencias sobre
EDI y las ferias comerciales brindan una oportunidad de intercambiar ideas y problemas
con otros usuarios de EDI. Tambin se puede aprovechar la asistencia a estas reuniones
para buscar nuevos interlocutores comerciales que estn interesados en intercambiar
documentos. Tambin es til la participacin en otras compaas que posiblemente usen
aplicaciones y mtodos similares. En estos foros, existe una oportunidad excelente para
enterarse de cmo se han resuelto problemas similares en otras organizaciones.
Asimismo, las actividades de los comits de normas y los grupos de accin de la
industria tambin son importantes. La participacin en estas actividades permite
mantenerse al da en cuanto a los cambios en el entorno EDI. Y quiz an ms
importante, la participacin en estos grupos permite dar a conocer las preocupaciones e
influir en el futuro de EDI.
No se puede lograr el proyecto EDI sin cooperacin entre compaas. La mayor
parte de los usuarios de EDI se dan cuenta de que se beneficia toda una industria cuando
sus miembros cooperan y participan juntos desarrollando normas para EDI, celebrando
conferencias y compartiendo experiencias. Su participacin en estas actividades no solo
aumentar los beneficios para su organizacin sino para toda la industria.
7.12
Resumen
Es este captulo se han expuesto los casos para la implantacin de EDI.

Obviamente, ninguna lista de pasos a seguir puede encajarse con todas las situaciones,
sin embargo, los pasos que se resumen aqu deberan formar una buena base para la
planificacin y ejecucin de la implantacin de EDI. En el siguiente captulo, se
describen los requisitos especficos de personal y formacin necesarios para lograr la
implantacin EDI.
Pgina 125
CAP. 8
PERSONAL Y FORMACIN
8.
Necesidades de personal y formacin para EDI
8.1
Introduccin
La implantacin de EDI requiere la coordinacin y cooperacin del personal de

numerosas reas tanto dentro como fuera de la organizacin. Por lo tanto, en el trabajo
de implantacin, se necesitan conocimientos procedentes de varias reas diferentes. En
este captulo, se describen las tareas que son necesarias realizar para la implantacin de
EDI. A efectos del presente captulo, se supondr que EDI se integrar en las
operaciones actuales a travs de lneas funcionales. De todas formas incluso en un
entorno autnomo de EDI, habr que realizar la mayora de las tareas indicadas a
continuacin.
En este captulo, se presentan las necesidades de personal como papeles o
funciones que habr que realizar. Aunque habr que llevar a cabo todas las funciones
descritas a continuacin para lograr con xito la implantacin de EDI, no es necesario
que se realice cada uno de los papeles o funciones por una persona diferente. En las
organizaciones de varios usuarios actuales de EDI, solo hay una o dos personas
responsables para la totalidad del esfuerzo EDI,mientras que en otras organizaciones
hay hasta 20 personas participando directamente en ello. El nmero de personas
vinculadas a EDI depender del tamao de la compaa, del tipo de sistema EDI que se
est utilizando, del volumen, de transacciones que se estn transmitiendo y de la
prioridad segn la organizacin impuesta a EDI.
Independientemente del tamao y constitucin del equipo EDI, el equipo deber
tener una visibilidad de empresa bien marcada, o sea deber tener miembros designados
y un jefe de equipo o grupo designado, y deber depender de la alta direccin. En la
figura adjunta, se indican los papeles, clasificados por grupos de personal, que habrn
que desempear para lograr la implantacin de EDI.
Pgina 126
8.2
Grupo de direccin EDI
El grupo de direccin de EDI es responsable de la direccin, de la planificacin

del proyecto global de EDI. Las actividades de direccin comprenden tres funciones:
Director jefe EDI, Director de proyectos EDI y Coordinador EDI. A continuacin, se
indican las tareas especficas realizadas por el grupo de direccin.
Actividades del grupo de direccin
Realizar la direccin y supervisin global
Determinar alcance y diseo
Comunicar con la alta direccin
Obtener recursos
8.2.1
Director Jefe
El director jefe de la implantacin y operacin de EDI es responsable de la gestin

global del proyecto EDI. Las responsabilidades de esta funcin son:
Obtener los fondos necesarios
Coordinar los recursos de la empresa necesarios
Desempear la funcin de enlace con la alta direccin
Actuar de defensor de EDI
Quizs la funcin ms importante del equipo de direccin EDI es la de defensor de
EDI. El proyecto EDI requiere marketing tanto interno como externo. El director jefe de
EDI debera estar entusiasmado con EDI y comunicar dicho entusiasmo a los dems.
Pgina 127
8.2.2
Director de proyecto EDI
El director de apoyo EDI respalda y ayuda al director jefe EDI, siendo responsable
del funcionamiento diario del esfuerzo de implantacin de EDI. Sus tareas incluyen las
siguientes:
Desarrollo de programas de implantacin
Aprobacin de la seleccin de proveedores de EDI
Supervisin de los miembros del equipo.
8.2.3
Coordinador EDI
Tanto el director jefe como el director de proyecto EDI realizan principalmente

actividades de gestin. Como respaldo a estas actividades de gestin, el grupo de
direccin de EDI necesita tener un experto interno en temas de EDI. Este papel de
experto interno lo desempea el coordinador EDI. En su capacidad de experto residente,
el coordinador EDI tiene que conocer bien todos los aspectos de la implantacin de
EDI. Entre los temas especficos que debera entender el coordinador EDI, se
encuentran los siguientes:
Temas tcnicos, tales como normas, configuraciones de software y hardware y
las opciones de redes de terceros.
Temas de gestin, tales como asuntos jurdicos y de auditoria y el impacto en la
organizacin.
Temas de la industria, tales como actividades de grupos comerciales y
directrices industriales referente a normas.
El coordinador EDI deber participar de forma activa en todas las decisiones
referentes a EDI. El coordinador deber desempear un papel de asesor para determinar
el alcance y objetivo del proyecto de implantacin de EDI. Adems, el coordinador
deber contribuir de manera significativa al plan y el programa de implantacin de EDI,
incluyendo la prioridad de transacciones y los interlocutores comerciales que se van a
incorporar en el esfuerzo EDI.
En muchas organizaciones, el coordinador EDI tambin desempea la funcin de
coordinador de normas. Como tal, el coordinador asiste a reuniones normativas y acta
de portavoz de la organizacin en el proceso de desarrollo de las normas. El
coordinador EDI tambin interviene de manera diaria en la propia implantacin de EDI,
debiendo participar en la realizacin de la prueba piloto del trabajo EDI y de las
modificaciones necesarias antes de la implantacin total.
8.3
Grupo de operaciones
Adems del grupo de direccin, el grupo EDI deber incluir un grupo constituido
por directores funcionales como los de compras, contabilidades o administracin, que
son los usuarios de EDI. A travs de su participacin en el proceso de planificacin de
EDI, se sentirn ms propietarios del esfuerzo EDI, disminuyendo as la oposicin a su
uso. Los grupos de operaciones constan de directores de reas funcionales y de
coordinadores de reas funcionales, realizando las tareas indicadas a continuacin.
Pgina 128
Actividades del grupo de operaciones

Identificar las aplicaciones de EDI a las reas funcionales
Fijar las prioridades de las aplicaciones EDI
Disear los nuevos flujos y procesos funcionales
8.3.1
Directores de reas funcionales
El papel de los directores funcionales es el de identificar la forma en la que se

puede utilizar EDI dentro de cada rea funcional especfica y de actuar en calidad de
defensor de EDI ante todos los dems en el rea funcional. Adems, el director
funcional es responsable de fijar las prioridades de las opciones alternativas de EDI
dentro del rea funcional especfica. Al director de rea funcional le respalda un
coordinador de rea funcional.
8.3.2
Coordinador del rea funcional
El papel del coordinador de reas funcionales acta de experto de rea funcional en

el equipo EDI. Entre sus tareas, se encuentran las siguientes:
Identificar las transacciones e interlocutores comerciales potenciales.
Determinar los flujos de informacin actuales dentro del rea funcional
Identificar los cambios necesarios en el rea funcional como consecuencia de
EDI
Ayudar en la realizacin del anlisis coste/beneficios.
8.4
Grupo tcnico
Puesto que la implantacin de EDI implica la introduccin de una nueva

tecnologa informtica en una organizacin, el equipo de implantacin EDI deber
contar con representantes procedentes de las reas informticas y de comunicaciones de
la organizacin. El papel del grupo tcnico es el de asesorar sobre los sistemas actuales
de la empresa y de ayudar con la integracin del sistema EDI dentro del sistema actual
de la organizacin. Al grupo tcnico le corresponden tres funciones: Especialista en
comunicaciones, especialista en informtica y coordinador tcnico.
8.4.1
Especialista en comunicaciones
El papel del especialista en comunicaciones es familiarizarse con la capacidad

actual de comunicaciones de la empresa y establecer los mtodos de comunicacin de
EDI. Entre los temas que caen bajo la responsabilidad del especialista en
comunicaciones, se encuentran los protocolos de comunicaciones y velocidad,
disponibilidad temporal de la red y la capacidad de volumen de la red.
8.4.2
Especialistas en informtica
Pgina 129
El papel del especialista en informtica es familiarizarse con las distintas

aplicaciones actualmente en uso en la organizacin. Es responsabilidad del especialista
en aplicaciones programar cualquier cambio necesario en las bases de datos o software
actuales, as como desarrollar o adquirir los paquetes de conversin necesarios para
realizar la interfaz del sistema EDI con los sistemas de aplicacin internos.
8.4.3
Coordinador tcnico
El coordinador tcnico desempea el papel de experto en sistemas desde el

punto de vista tanto de comunicaciones como de aplicaciones. En base a la informacin
facilitada por los especialistas en comunicaciones y aplicaciones, el coordinador tcnico
es responsable de la seleccin de opciones especficas de comunicaciones y software,
as como de la instalacin del sistema. El coordinador tcnico tambin puede dar
asesoramiento tcnico a los interlocutores comerciales.
8.5
Grupo de enlace
El papel del grupo de enlace es el de comunicar los esfuerzos EDI tanto a nivel
interno como entre la empresa y los interlocutores comerciales. Adems, el grupo de
enlace acta en calidad de defensor de EDI para ayudar a venderlo tanto a nivel interno
como externo. A continuacin, se sealan las obligaciones principales del grupo de
enlace desempeadas por dos funciones: Comercial y Coordinador de interlocutores
comerciales.
8.5.1
Comercial de EDI
La funcin principal del comercial de EDI es la dar a conocer y fomentar la

participacin en EDI tanto dentro como fuera de la organizacin. Con la ayuda del
grupo funcional y del coordinador de interlocutores comerciales, el comercial debera
animar a los interlocutores comerciales para que participen en el esfuerzo, lo que se
puede hacer a travs de jornadas de formacin, visitas personales, etc. Adems de
trabajar directamente con los interlocutores, el Comercial de EDI debera asistir a ferias
comerciales, reuniones normativas, conferencias. De esta forma, el vendedor de EDI
puede anunciar al mundo que su organizacin est usando EDI y que busca
interlocutores. Una vez que un interlocutor comercial expresa un inters en EDI, l
mismo pasa a ser responsabilidad del coordinador de interlocutores comerciales.
8.5.2
Coordinador de interlocutores comerciales
El coordinador de interlocutores comerciales es responsable de la identificacin

y mantenimiento de los interlocutores comerciales de EDI. En base a la informacin
facilitada por el grupo funcional y el comercial, el coordinador tiene la responsabilidad
de fijar prioridades en cuanto a interlocutores potenciales y de seleccionar los
interlocutores para poder su buena voluntad y disponibilidad para participar. Asimismo,
en este punto, el interlocutor comercial puede plantear los asuntos mutuos, por ejemplo
las normas a usar, los cdigos de identificacin especiales que se necesitan, los
protocolos de comunicacin y los programas de transmisin.
Actividades del grupo de enlace
Pgina 130
Vender EDI a nivel interno y externo

Seleccionar interlocutores comerciales para prueba piloto
Mantener el estado de los interlocutores comerciales
Tambin el coordinador de interlocutores comerciales tiene la responsabilidad de
identificar la formacin que necesitan los interlocutores comerciales y disponer dicha
formacin con el coordinador de formacin.
El coordinador de formacin. El coordinador trabaja estrechamente con los dems
integrantes del equipo EDI de la empresa para programar las pruebas de transmisin,
realizar un seguimiento del progreso y discutir las modificaciones necesarias.
Adems este coordinador es responsable de mantener la informacin de estado referente
a los interlocutores. Por ejemplo, se debera mantener informacin sobre la aprobacin o
no de un interlocutor, si ha comprado equipos, si ha instalado software, si est en la fase
piloto o si ha terminado la prueba piloto. Adems, normalmente el coordinador debera
hacer un seguimiento del interlocutor comercial para averiguar si est usando una red de
terceros (y en caso afirmativo averiguar la red) y las normas, incluyendo el nmero de
versin, que est usando. La informacin de estado de los interlocutores se facilitar a
los grupos funcionales y de direccin, as como a la red de terceros de la organizacin.
8.6
Grupo de apoyo de personal
Adems de los grupos tcnicos y funcionales necesarios para el xito de la

implantacin de EDI, tambin deberan participar en la implantacin representantes de
las funciones de personal dentro de la organizacin. Unos representantes del personal de
auditoria y jurdico, deberan participar en el proceso de planificacin de EDI, y
tambin deberan formar parte del equipo un administrador de contratos y un
coordinador de formacin. Sus tareas estn indicadas a continuacin.
8.6.1
Revisadores jurdicos y de auditoria contable
Puesto que con EDI se cambian los flujos de papel y datos, los representantes de
las funciones jurdicas y de auditoria de la organizacin deberan formar parte del
equipo EDI. Aunque el uso d EDI, no mermar la capacidad de una organizacin de
realizar una auditoria de las transacciones, s cambiar el mtodo con lo que se suele
realizar la auditoria. El papel del representante de auditoria es llamar la atencin del
equipo EDI para poder considerar estos asuntos durante el diseo del sistema. Lo
mismo se aplica a la parte jurdica.
8.6.2
Actividades del grupo del grupo de apoyo de personal
Las actividades que realiza este grupo son:

Revisar el proceso EDI eficacia jurdica y de auditoria
Desarrollar /obtener formacin
El papel del representante jurdico en el equipo EDI es el de plantear cualquier
preocupacin que pueda tener la funcin jurdica referente al uso de documentos
electrnicos en lugar de documentos de papel. Las cuestiones de firmas electrnicas,
seguridad de datos y control funcional pueden acogerse en el diseo del sistema EDI. Al
Pgina 131
plantear estos temas durante las etapas de planificacin e implantacin de EDI, se

garantiza que los flujos nuevos de papel y datos producidos por el sistema EDI sean
aceptables a las funciones de auditoria y jurdica.
8.6.3
Administrador de contratos EDI
En muchas organizaciones, se usan contratos para asegurar que todas las partes
entiendan y acepten sus responsabilidades individuales en el esfuerzo EDI. La funcin
del administrador de contratos es la de preparar y/o supervisar los distintos contratos de
EDI.
Los contratos de EDI se pueden concertar entre la organizacin y sus
interlocutores, su red de terceros y su proveedor de software. Aunque puede haber
empresas que no formalicen contratos EDI, la mayora creen firmemente en este tipo de
contratos por pensar que permiten una relacin comercial ms estrecha y mejor. Por otro
lado algunas empresas no creen que los contratos sean necesarios, especialmente con los
interlocutores comerciales con los que han mantenido una buena relacin comercial
duradera, aunque de forma genrica se aconseja llegar a un Acuerdo de Intercambio por
los problemas legales que puedan surgir en el futuro, por muy buenas relaciones que se
tengan.
8.6.4
Coordinador de formacin
La funcin final que habr que realizar para lograr la implantacin de EDI es la
de coordinador de formacin, mediante la que se determinarn las necesidades de
formacin. Las necesidades de formacin en una organizacin pueden variar desde una
formacin tcnica detallada sobre normativa hasta una descripcin general de EDI.
Asimismo, este coordinador, que llevara el control de la coordinacin de la formacin,
puede averiguar si un interlocutor comercial requiere formacin antes de ponerse en
lnea con la empresa. El coordinador de formacin ser responsable de desarrollar o
adquirir la formacin necesaria y de programar la misma de acuerdo con el programa de
implantacin de EDI.
A menudo, se pasa por alto el grupo de apoyo de personal durante la
implantacin de EDI. De hecho en algunas organizaciones, se dan casos de maniobras
deliberadas de excluir al personal jurdico y de auditoria de la planificacin de EDI. En
ciertos ambientes empresariales sienten la necesidad de mantener a los abogados
alejados del proceso EDI. Segn estas personas, se puede llegar rpidamente a un
acuerdo entre interlocutores comerciales sobre los trminos y condiciones de las
transacciones de EDI, siempre que no estn involucrados los abogados. Se dice que
comentaba un director de proyecto EDI: "Nuestros peores problemas han sido con
nuestras organizaciones jurdicas o como consecuencia de participacin de las
organizaciones jurdicas de nuestros interlocutores comerciales". En muchos casos,
puede no resultar fcil conseguir que el personal jurdico (o de auditoria) comprenda y
acepte los cambios producidos por EDI, sin embargo es importante tener su apoyo. Su
participacin en el proceso de planificacin puede retrasar la implantacin al principio,
sin embargo seguramente evitar la aparicin de problemas importantes ms adelante.
8.7
Formacin EDI
Pgina 132
Segn lo visto anteriormente la implantacin de EDI requiere la cooperacin y el

trabajo de personal en reas funcionales, tcnicas y de personal. Tambin requiere el
respaldo de la alta direccin. No se puede realizar este esfuerzo si el personal no tiene
conocimientos de EDI.
Sin embargo, en numerosos estudios, se ha demostrado que existe todava una
falta de comprensin importante acerca de lo que es y como funciona. En un estudio
realizado los usuarios de EDI, a menudo se citaba la falta de conocimientos de EDI
como razn de retraso en la implantacin. En respuesta a la pregunta- Ha aplazado su
empresa la implantacin de cualquier componente funcional de EDI por alguna de las
siguientes razones? El 41% respondan que los factores relacionados con la formacin
eran importantes, y el 42% muy importantes. Entre los factores relacionados con la
formacin, se encontraban la falta de conocimientos, la falta de conciencia por parte de
la alta direccin y las dificultades a la hora de educar a los clientes o proveedores.
Por lo tanto, la formacin y educacin son muy importantes para conseguir la
aceptacin de EDI para comprender y lograr su implantacin. En esta seccin, se
describen las necesidades de formacin para las distintas partes de la organizacin y
para los distintos grupos que constituyen el equipo. Adems se exponen las fuentes de
esta formacin.
8.7.1
Necesidades de formacin
Puesto que EDI afecta a muchas funciones diferentes dentro de una

organizacin, y puesto que el impacto se siente a todos los niveles de direccin, las
necesidades de formacin de EDI son numerosas y diversas. Por supuesto, la formacin
necesaria para la alta direccin ser muy distinta de la formacin que requiere un
usuario funcional del sistema. Incluso dentro del equipo de implantacin de EDI,
variarn las necesidades de formacin. Por ejemplo, la formacin que requiere el
coordinador de EDI ser mucho ms intensiva y detallada que el vendedor.
8.7.2 Matriz de formacin
El cuadro que se muestra a continuacin es una representacin de una matiz de
formacin compuesta de dos componentes: Necesidades de Conocimientos de EDI y
Funciones Organizacionales. Los primeros identifican los conocimientos y habilidades
bsicas de EDI, y las segundas los distintos grupos dentro de la organizacin que
requieren formacin de alguna forma u otra. En estas ltimas se incluyen los grupos del
equipo EDI, junto con la alta direccin y lo usuarios. El propsito de la matriz es
proporcionar una directriz para la formacin mediante la identificacin de los
conocimientos y habilidades que son necesarios y cuales corresponden a los grupos
participantes en el esfuerzo de implantacin. A continuacin se da un resumen de la
informacin que compone cada una de las necesidades de conocimiento.
Los conceptos de conocimientos y habilidades de EDI se clasifican en tres
categoras generales: Visin general de EDI, Componentes de EDI y Temas de
implantacin de EDI. Cada categora se subdivide en reas de conocimientos ms
detallados. A continuacin se exponen los tipos de conceptos e ideas que deberan
incorporarse en la formacin para cada una e las necesidades de conocimientos y
habilidades.
Pgina 133
R=Requerido
D=Deseable
N=No necesario
Grupos
organizacionales
Conocimientos y
Alta Direccin
Habilidades
Usuario Equipo EDI

Director Operaciones tcnico enlace Personal
Descripcin
General
Conceptos
Bsicos
Uso estratgico
Ejemplos
Costes/beneficios R
Normas
Papel/funcin
Diseo
Documentos
Papel/Funcin
Opciones
Operaciones
Opciones
Operaciones
Interfaz
Software
Configuracin
del Sistema
Temas
de
implantacin
Tareas
Impacto
proceso
en
Temas
Seguridad
de
8.8
8.8.1
Requisitos de conocimientos de visin general EDI

Temas bsicos
Pgina 134
La categora de visin general de EDI comprende las necesidades de

conocimientos de una introduccin bsica a EDI, la estrategia de EDI, ejemplos del uso
de EDI y los costes y beneficios de EDI. La formacin en los temas bsicos de EDI
debera incluir una explicacin de lo que es EDI y como funciona, as como una
discusin de como difiere EDI de otras tecnologas actuales como Correo Electrnico y
transmisin por fax. Se debera hacer una introduccin y explicacin de los
componentes bsicos de EDI, incluyendo normas, software, configuraciones de
hardware y redes de terceros. Adems, en una descripcin general conviene dar una
explicacin breve de los sistemas de implantacin.
8.8.2
Uso estratgico
La seccin sobre el uso estratgico de EDI debera referirse a los beneficios

corporativos que se pueden obtener del uso del EDI. Esta necesidad de conocimientos
abarca temas que van ms all de los ahorros de productividad, incluyendo una
explicacin del uso de EDI para conseguir una ventaja competitiva gracias a una mayor
asistencia al cliente, una mayor calidad y disponibilidad de la informacin de la
integracin de EDI en los sistemas internos.
8.8.3
Ejemplos de EDI
Unos ejemplos del uso de EDI tambin deberan formar parte de la formacin
general, incluyendo una discusin de las organizaciones en la misma industria que han
tenido xito con EDI. En los ejemplos se debera exponer la forma en que se implant
EDI, quin estaba involucrado, los costes y beneficios correspondientes y las lecciones
aprendidas durante el proceso de implantacin.
Tambin es conveniente incluir ejemplos de EDI en otras industrias para demostrar la
amplia diversidad de organizaciones que lo usan.
8.8.4
Costes y beneficios
El tema final del resumen general de EDI debera ser una discusin de los costes
y beneficios de un sistema EDI, debiendo mantener esta discusin a un nivel bastante
general con una presentacin de los varios tipos de costes que se producirn durante la
implantacin y la identificacin de los beneficios previstos. Esta discusin debera
incluir informes de grupos de accin de la industria que han estimado los costes y
beneficios para las aplicaciones especficas.
8.9
Necesidades de conocimientos de componentes de EDI
Esta seccin de la formacin estar orientada a los elementos o componentes

bsicos necesarios para el funcionamiento de EDI, incluyendo una introduccin a las
normas EDIFACT, el software y el diseo de los sistemas de EDI.
8.9.1
Normas EDIFACT
Pgina 135
Uno de los componentes principales de EDI lo constituyen las normas, sin

embargo parece ser el concepto poco comprendido, quiz porque suele ser difcil para
los directores funcionales imaginar un documento estndar que puede ser eficaz en
todas las situaciones tan diferentes planteadas en una organizacin. Por lo tanto, la
formacin en las normas de EDI es crtica para lograr la implantacin. La formacin
debera tratar los temas de funcionamiento, los documentos respaldados por las normas
y la forma en que se transforma un documento de papel en un documento electrnico
EDIFACT.
En la discusin del funcionamiento de las normas EDIFACT, se debera explicar
lo que son las normas y como hacen posible EDI, as como una breve historia del
desarrollo de las normas y de la situacin de los diferentes grupos y comits de
desarrollo. Tambin debera haber una discusin del alcance de las normas en lo que se
refiere a los requisitos de formateado y comunicaciones. Esta seccin tiene como
objetivo dar a conocer que una norma permite coger informacin no estructurada y
ponerla en un formato estructurado, pero no es objetivo explicar como se hace.
Otro tema que debera formar parte de esta formacin es una discusin de los
documentos que se encuentran respaldados por EDIFACT. Incluyendo una presentacin
de aquellos documentos que tienen normas aprobadas y aquellos que se encuentran en
fase de revisin por el comit de normativa.
La tercera necesidad de conocimiento indispensable para una comprensin total
de las normas es la de la transformacin, siendo el objetivo de esta parte de la formacin
impartir a los tcnicos unos conocimientos detallados del proceso de transformacin o
traduccin de un documento de papel en un documento electrnico. Esta formacin
debera incluir unos ejercicios prcticos de repaso de documentacin normativa y
elaboracin de un documento en el lenguaje estndar de EDIFACT.
8.9.2
Software de usuario
El segundo componente importante de EDI que habr que tratar en la formacin

es el del software de EDI. Entre los temas que se deberan tratar en la formacin, se
encuentran la funcin y la operacin del software y los criterios para decidir la compra
de ste.
Una parte de esta formacin debera ser una descripcin general del software
EDI, explicando el uso del software y la funcin de traduccin que realiza. Esta
presentacin no debera ser tcnica para que la puedan entender personas sin
conocimientos informticos o de sistemas.
Adems de la descripcin general de la funcin del software, se debera impartir
formacin adicional sobre su uso y operacin, incluyendo ejercicios prcticos con el
programa de software para formatear y realizar transmisiones electrnicas. De nuevo,
esta formacin estar a un nivel no tcnico.
Una tercer necesidad de conocimientos de software indispensable para implantar
EDI es la de facilitar informacin sobre las diferentes opciones de software, incluyendo
una comparacin de los numerosos paquetes de software disponibles, as como una
Pgina 136
comparacin de los costes de compra. Esta formacin se impartir a un nivel bastante

tcnico, dirigida principalmente al personal de informtica.
8.9.3
Diseo de sistemas
Tambin es importante la formacin en el diseo EDI. Es necesario entender las

diferentes opciones para establecer un enlace con los interlocutores comerciales para
que puedan comprender el funcionamiento de EDI. Esta formacin debera incluir una
discusin de las ventajas y desventajas de un diseo PC comparado con uno de
mainframe, y de una versin manual comparada con una de aplicacin a aplicacin.
Esta discusin debera tratar el papel del Centro de Compensacin y las funciones que
puede realizar. Est destinada principalmente a un pblico no tcnico y est diseada
para presentar un resumen general de la misin del Centro de Compensacin.
8.10
Necesidades de conocimiento de temas de implantacin
La ltima categora de conocimiento que habr que tratar en la formacin en

EDI es la de la implantacin. Es necesario saber como se va a implantar EDI y su
impacto en la organizacin para conseguir un proceso de implantacin sin problemas.
Concretamente, dicha formacin debera referirse a las tareas de implantacin, cambios
en procedimientos o procesos y temas de seguridad.
8.10.1
Tareas de implantacin
Esta formacin debera iniciarse con un resumen bsico de las tareas necesarias
para la implantacin de EDI, incluyendo una temporizacin para la terminacin de las
tareas y una discusin de la designacin de tareas entre diferentes miembros del equipo
de implantacin. Por supuesto, esta formacin est orientada a dicho equipo, pero
tambin resulta til para otros que se vern afectados por EDI.
8.10.1.1
Impacto sobre procedimientos.
Esta formacin tambin debera tratar los cambios que se producirn en los
procedimientos y procesos como consecuencia de EDI. El uso de EDI cambiar los
flujos tradicionales de papel y los de datos dentro de una organizacin. Es crtico para la
aceptacin del sistema EDI entender como cambiarn estos flujos y su impacto en dicha
organizacin.
8.10.1.2
Seguridad de sistemas
Asimismo, la formacin en la implantacin debera incluir una discusin de los

temas de seguridad. Normalmente, el personal funcional, jurdico y de auditoria estar
muy preocupado de la manera en que EDI afectar a la capacidad de la organizacin de
controlar y seguir los documentos y transacciones. Una formacin sobre posibles
registros de auditora y las diferentes medidas de seguridad que se pueden incorporar en
el diseo de un sistema EDI suele debilitar la oposicin a ello. Aunque resulta
conveniente una discusin de como otras organizaciones en la industria se han
planteado este problema.
8.11
Resumen de necesidades de conocimiento de EDI
Pgina 137
Todos los temas arriba mencionados deberan formar parte de la formacin, sin
embargo no es necesario presentar todos los temas a todo el personal. El propsito de la
matriz de formacin no solo es de sugerir temas para la formacin, sino tambin sealar
que temas deberan presentarse a cada grupo.
Existen dos formas bsicas de realizar la formacin: se puede desarrollar
internamente o se puede adquirir de fuentes externas.
Desarrollo interno.
Como parte integral de esfuerzo de implantacin de EDI, la organizacin puede
desarrollar su propia formacin. Para ello, se puede aprovechar informacin disponible
de varias fuentes externas, incluyendo redes de terceros, comits normativos, ferias
comerciales y materiales publicados. La ventaja principal de la propia formacin es que
se puede adaptar la formacin a las necesidades especficas. Se puede disear la
formacin para ajustarla de forma ptima al programa de implantacin y a las
necesidades concretas de conocimientos del equipo EDI. De la alta direccin y de los
usuarios. Un inconveniente importante es que los instructores no son expertos en la
materia. Adems, la capacidad de formacin interna a menudo se encuentra limitada, de
manera que estas acciones pueden interferir con otras necesidades de formacin.
Fuentes externas.
Se puede disponer de formacin externa de muchas fuentes, entre ellas las redes
de terceros, asesores, proveedores de software y organizaciones de formacin de EDI.
Su ventaja principal es que normalmente la imparten unos expertos en este campo. Un
inconveniente importante es que a veces es genrica por naturaleza y no trata las
necesidades de problemas especficos que pueden ser nicos en una organizacin. Sin
embargo, existen muchas organizaciones pedaggicas que adaptarn las sesiones de
formacin para satisfacer las necesidades particulares
La decisin entre el desarrollo de formacin propia o de contratacin externa
debera basarse en una evaluacin de las necesidades especficas, teniendo en cuenta los
recursos disponibles, el programa de implantacin y el nivel actual de conocimientos de
EDI dentro de la organizacin. Segn un porcentaje alto de usuarios de EDI, la
formacin es el rea donde haya ms necesidad de ayuda externa. N un estudio llevado
a cabo por EDI Research, con un total de 1094 entrevistas, result que un 39,4% de las
compaas que estn usando o piensan usar EDI sealaban la formacin como el rea en
que ms necesitaban ayuda externa.
Pgina 138
CAP. 9
OBSTCULOS
9.
9.1
Superacin de los obstculos organizacionales a EDI

Introduccin
Todo est listo para el crecimiento de EDI. EDI da beneficios; las industrias ms
importantes promocionan su uso; los componentes de EDI se consiguen fcilmente.
Entonces Por qu la dificultad a la hora de implantar EDI? La implantacin es difcil
porque a EDI es mucho ms que una herramienta tcnica, es un cambio cultural.
Para la mayor parte de las personas en el mundo de negocios, el papel es una
manta de seguridad. Nos gusta el papel; lo usamos y lo guardamos. EDI nos amenaza
con quitarnos esa manta de seguridad. Adems, EDI amenaza traer consigo otros
cambios en la forma de nuevas obligaciones y procedimientos diferentes en nuestros
trabajos. Estos cambios afectan a la gente.
En otras palabras, la implantacin de EDI no solo tendr un impacto importante
en la tecnologa y en los procesos tanto dentro como fuera de la organizacin, sino
tambin tendr un impacto en la gente y en la filosofa de direccin. Por eso, para que
EDI sea un xito, habr que reconocer y superar los obstculos organizacionales y
personales para lograr la implantacin de EDI.
En este captulo, se exponen varios obstculos comunes que se imputan a
menudo a EDI, ofreciendo sugerencias para superarlos. Los siguientes comentarios
reflejan los obstculos y preocupaciones con qu se han enfrentado la mayora de las
organizaciones que han implantado EDI.
9.2
Nunca lo hemos hecho as. EDI cambiar mi trabajo.
Uno de los principales obstculos a la implantacin EDI es la oposicin al

cambio o la inercia corporativa. Muchas organizaciones tardan mucho en cambiar,
debido en gran parte a la oposicin de los empleados a las nuevas tecnologas, procesos
o gestin. Como no se puede prever siempre el impacto especfico del cambio, la
introduccin de estos dentro de una organizacin suele encontrarse con una fuerte
oposicin.
Los primeros usuarios de EDI identificaron la oposicin al cambio por parte de
directores funcionales, por ejemplo los de compras y contabilidad, como el principal
obstculo a su implantacin. Estas organizaciones sealaban que los directores veran en
EDI una amenaza a su posicin, su poder y posiblemente a su puesto. Por ejemplo, un
director indicaba que estaba previsto que EDI redujera el nmero de personas, sin
embargo su salario en parte estaba vinculaba a este nmero. Obviamente, este director
consideraba EDI una amenaza a su posicin. La oposicin natural al cambio, junto con
el miedo de EDI y de lo que permite hacer, crean un obstculo considerable Cmo se
puede superar este obstculo?
Pgina 139
9.2.1
Solucin
Existen tres medidas importantes parra minimizar la oposicin de la empresa al

cambio:
El firme respaldo de la alta direccin
La participacin de usuarios desde el principio
Formacin a todos los niveles de la organizacin
Es mucho ms probable que se acepte un cambio en la organizacin si goza del
respaldo formal e incondicional de la alta direccin. El apoyo a alto nivel convierte
inmediatamente el cambio en un asunto de importancia para toda la organizacin,
ayudando as a debilitar la resistencia.
Adems del respaldo de la alta direccin, el esfuerzo EDI debera tener todo el
apoyo posible de los directores de las reas funcionales ms afectadas por el cambio, o
sea los usuarios eventuales deberan participar activamente en la planificacin e
implantacin. La involucrar a los usuarios en el esfuerzo EDI en lugar de dejar toda la
planificacin e implantacin en manos del departamento de informtica o de consultores
externos, los directores funcionales se sentirn ms vinculados a EDI. De esta forma es
menos probable que estn en contra del proyecto y lo ms probable es que se conviertan
en defensores del mismo.
Por ltimo, la existencia desde el principio de un programa de formacin que resalte
los beneficios de EDI y explique cmo se integrar con los sistemas existentes ayudar
a superar el miedo a lo desconocido. Al exponer claramente los objetivos del programa,
las organizaciones pueden minimizar la mala informacin que suele acompaar
cualquier cambio, lo que permitir evitar comentarios como los de "EDI nos dejar sin
trabajo" o "EDI nos convertir en tcnicos".
9.3
EDI cambiar mi trabajo
Claramente, el uso de EDI impacta en papeles y funciones tanto dentro como

fuera de las organizaciones, A menudo, existen obstculos en su implantacin por las
preocupaciones sobre como afectar exactamente a las funciones y relaciones entre
reas.
Una fuerte preocupacin de los directores funcionales se refiere a la forma en que EDI
impactar en sus funciones dentro de la organizacin. El personal de compras a menudo
teme que EDI convertir a los compradores en poco ms que contables informticos.
Los vendedores preguntarn si EDI llegar a eliminar sus puestos de trabajo, pues no
habr que recoger los pedidos. Los directores funcionales en todas las reas temen que
EDI permitir reducir el nmero de personas en sus departamentos, y a veces sus
salarios se basan en parte, en dicho nmero.
9.3.1
Solucin
Aunque estas preocupaciones no son siembre vlidas ni corroboradas por la

experiencia de los usuarios, es necesario tenerlas en cuenta, pues si no se resuelven estas
preocupaciones formarn una barrera importante en la correcta implantacin de EDI. De
nuevo, son necesarias la formacin y e respaldo de la alta direccin.
Pgina 140
Se ha comprobado que el uso de EDI puede cambiar los papeles del personal funcional,
sin embargo los cambios son positivos. El personal de compras descubre que EDI les
libera de las tareas administrativas, dejndoles ms tiempo para las actividades
profesionales de compras. Igualmente los vendedores se dan cuenta que con EDI,
pueden pasar ms tiempo vendiendo pues pierden menos tiempo con el papeleo. Educar
a la gente sobre los impactos reales de EDI permitir eliminar sus preocupaciones.
Tambin se necesita el respaldo de la alta direccin. EDI cambiar el papel de muchos
directores funcionales, y los directores superiores necesitan saberlo y estar dispuestos a
ajustar las medidas de rendimiento, si es necesario, para reflejar un entorno EDI en
lugar de papel. Para eliminar las preocupaciones por prdida de salario o posicin
debido a EDI, se podra recompensar una mayor productividad en lugar de nmero de
personas.
9.4
EDI destruir mi relacin con los compradores y vendedores
Otra preocupacin de los directores funcionales es que EDI puede afectar

negativamente la relacin entre interlocutores comerciales, en particular entre
compradores y vendedores. Algunos ven en EDI, a menos hasta cierto punto, una
intervencin en las relaciones de intercambio en curso. Los compradores expresan su
preocupacin en el sentido de que existir menos contacto ente compradores y
vendedores, haciendo as la relacin menos personal. Los vendedores tambin temen
que EDI debilitar los vnculos entre compradores y vendedores. De nuevo, aunque
estas preocupaciones son vlidas, la experiencia ha demostrado que EDI permite
reforzar estas relaciones.
9.4.1
Solucin
En un estudio de usuarios de EDI, el 87% de las organizaciones afirmaban que

en realidad, EDI permita mejorar las relaciones entre interlocutores comerciales, siendo
las razones principales la cooperacin y coordinacin necesarias para implantar EDI y
una mayor confianza conseguida al compartir informacin. De hecho, algunas
organizaciones han implantado EDI para mejorar las relaciones. Pues bien, con EDI, se
cambian las relaciones entre interlocutores comerciales, sin embargo estos cambios
suelen reflejar una sustitucin de relaciones adversas por unas ms estrechas de
cooperacin. Para superar este obstculo, la mejor forma es ensear a los directores
funcionales las experiencias de otros usuarios.
9.5
EDI es problema de otros, no concierne a mi departamento.
Existe un obstculo importante en la implantacin de EDI que no se produce con

otros cambios de organizacin, por ejemplo, la incorporacin de un sistema informtico
en el departamento de compras. El obstculo que se encuentra en la mayora e las
organizaciones es el efecto que EDI puede introducir en la estructura bsica de la
organizacin. El uso de EDI traspasa las fronteras departamentales tradicionales, o sea
para una implantacin completa, es necesaria la cooperacin del personal de compras,
contabilidad, tesorera, marketing, informtica y ventas, as como el apoyo del personal
jurdico y de auditoria. Adems, no solo es necesario duplicar esta cooperacin entre
departamentos en la organizacin del interlocutor comercial, sino tambin habr que
eliminar las fronteras tradicionales entre organizaciones. En otras palabras, es necesario
Pgina 141
un cierto nivel de confianza y respaldo tanto dentro como fuera de las organizaciones
para la realizacin de todos los beneficios potenciales de EDI.
9.5.1
Solucin
Por supuesto, las compaas que han implantado EDI no han tirado sus
organigramas ni han eliminado las barreras tradicionales entre funciones. Sin embargo,
estas organizaciones se han esforzado en conseguir la cooperacin a travs de las lneas
funcionales. La constitucin de equipos de implantacin interfuncionales, junto con el
firme respaldo de la direccin, permitir fomentar la participacin y cooperacin entre
departamentos. Tambin, para intentar derrumbar las barreras entre organizaciones, la
alta direccin puede fomentar la idea de ver los interlocutores comerciales no como
adversarios sino como una extensin de la propia compaa. Adems, si una compaa
empieza al nivel 1 de implantacin, existirn menos barreras organizacionales pues
normalmente solo un departamento se encuentra afectado. Cuando resulta ser un xito
en ese departamento, probablemente habr menos oposicin a EDI en otros
departamentos.
9.6
EDI es demasiado complejo para entenderlo
En muchos casos, todos los obstculos arriba mencionados proceden de un

problema fundamental: una falta de conocimientos. Varios estudios han confirmado que
la mayora de los usuarios potenciales de EDI no saben o estn mal informados en lo
referente
a
sus
beneficios
y
costes
potenciales.
En un estudio de usuarios de EDI, se identific la falta de conocimientos como una
razn importante por haber aplazado la implantacin de EDI en una o varias reas
funcionales. El 41% de los encuestados sealaban los factores de falta de
conocimientos, falta de conciencia por parte de la alta direccin, necesidades de
formacin interna y dificultad de educar a los interlocutores comerciales, como razones
importantes para aplazar la implantacin de EDI, y en el 42% los sealaban como muy
importantes. En el mismo estudio, se demostr que solo un 30% de las empresas
pensaban que existan conocimientos slidos de las normas EDIFACT, un 28% del
software y un 36% de los recursos de comunicacin de EDI.
Esta falta de conocimientos solo sirve para reforzar la oposicin al uso de EDI.
Muchas organizaciones sobre valoran los costes y subestiman los beneficios. Adems,
al no entender como funciona EDI, existen mayores preocupaciones con su supuesta
complejidad tecnolgica, as como con los temas de control y de seguridad de los datos.
Como consecuencia, muchas firmas se muestran reacias a iniciar un proyecto,
esperando verse obligadas a ello por un interlocutor comercial.
9.6.1
Solucin
La manera de derrumbar esta barrera es simplemente educacin. Aunque su

implantacin no es fcil, EDI no resulta tecnolgicamente complejo. Adems, se puede
disponer de asistencia de los proveedores, grupos comerciales e interlocutores
comerciales. Para iniciar la educacin o ayudar a los interlocutores, se pueden
considerar las siguientes medidas:
Discusiones con proveedores de software y de red
Pgina 142
Asistencia a cursillos de formacin

Participacin en conferencias y ferias comerciales sobre EDI
Participacin en el proceso normativo
Reuniones con interlocutores comerciales que ya usen EDI
9.7
Nuestros interlocutores comerciales recibirn todos los beneficios
de EDI
Un aspecto especfico de la falta de conocimientos general que obstaculiza el
crecimiento de EDI es el de no comprender los beneficios potenciales de EDI. Estos
beneficios pueden ser substanciales, tanto desde la perspectiva de productividad como
de las ventajas estratgicas. Sin embargo, muchas organizaciones no son conscientes de
estos beneficios.
Adems, en muchos casos, los usuarios eventuales de EDI creen que los
beneficios de EDI estn mal repartidos entre los interlocutores comerciales y, an ms
significativo, que la mayor parte de los beneficios corresponden a los interlocutores en
lugar de a sus propias organizaciones. En un estudio del Sector de la Distribucin en
que participaban tantos distribuidores como fabricantes, casi todas las compaas
indicaban que sus interlocutores se beneficiaran ms de EDI que ellos mismos.
Mientras que las organizaciones piensen que los beneficios son limitados, seguramente
el crecimiento de EDI ser lento. Adems de la preocupacin con los beneficios
limitados, muchas organizaciones se preocupan por los costes eventuales.
9.8
EDI cuesta demasiado
Muchas organizaciones piensan que los costes de EDI sern substanciales y que
no sern compensados por los beneficios. En varias encuestas diferentes, el obstculo a
la implantacin que se cita ms a menudo es el de los coste de arranque. Adems, las
organizaciones que citan los costes como obstculo importante declaran que los costes
de hardware representan l inversin ms importante, seguidos por los de desarrollo de
software.
Esta idea sobre los costes de hardware manifiesta una falta de conocimiento. En la
mayora de los casos, las organizaciones poseen ya casi todo el hardware necesario para
ejecutar EDI. En los pocos casos en los que no existe la capacidad informtica, se puede
comprar un microordenador y mdem por poco dinero. Aunque los costes del software
pueden ser substanciales si EDI est completamente integrado en las operaciones
internas, se pueden comprar paquetes de software para la mayora de las aplicaciones de
EDI, requiriendo solo un mnimo de desarrollo propio. La implantacin de EDI requiere
una inversin financiera, sin embargo los costes reales no suelen alcanzar los costes
previstos.
9.8.1
Solucin
Se pueden aprovechar varios mtodos para superar las equivocaciones referentes

a costes y beneficios.
En primer lugar tenemos la formacin. Al compartir las experiencias de los
usuarios actuales, se puede mitigar el miedo de inversin substancial sin rentabilidad.
Adems, muchos grupos industriales han publicado estimaciones de los ahorros
Pgina 143
conseguidos con el uso de EDI, pudiendo aprovechar estas cifras para demostrar sus
beneficios potenciales.
En segundo lugar, se puede realizar un anlisis de costes/beneficios. Muchas
organizaciones han comprobado que pueden justificar EDI en base a los ahorros
directos.
En tercer lugar, se puede iniciar una prueba piloto de EDI con un PC autnomo
conectado a una red de terceros, lo que permitir demostrar los beneficios de EDI con
unos bajos costes iniciales de implantacin.
En cuarto lugar, los que desean usar EDI deberan recomendar a los que se
muestran reacios que tengan paciencia. Los costes de EDI suelen ser ms altos durante
la primera fase de la implantacin, mientras que los beneficios son mayores mucho ms
adelante. Por lo tanto, los usuarios no deberan esperar un beneficio econmico
inmediato. Los beneficios a largo plazo pueden ser importantes, pero suelen producirse
despus de un perodo de costes iniciales.
En quinto lugar, los defensores de EDI deberan evitar a justificacin de EDI
exclusivamente en trminos econmicos. Mientras que se puede justificar EDI en base a
los costes/beneficios, existen beneficios ms importantes que no son monetarios, como
son la mayor calidad de las relaciones y las operaciones y las ventajas estratgicas.
9.9
EDI permitir el acceso de otros a nuestros datos propios
Los directores funcionales tambin se muestran indecisos con EDI por el miedo
a perder la seguridad de los datos. Tradicionalmente las relaciones entre interlocutores
comerciales han sido algo adversas. Normalmente, la mayora de las empresas se
muestran reacias a compartir informacin fuera de la compaa. Esta tendencia parece
an ms marcada en las reas de compras y contabilidad, que tradicionalmente han
controlado estrechamente el acceso a la informacin. A menudo se ve en EDI una
amenaza a este control de la informacin.
Muchos directores se preocupan de que el enlace de los ordenadores con EDI
permita a una organizacin externa acceder de alguna forma al ordenador de su
compaa y obtener informacin confidencial o sensible. La inquietud manifestada ms
a menudo por los directores de compras es el posible acceso electrnico de proveedores
o competidores a los ficheros de compras.
9.9.1
Solucin
El miedo al acceso ilimitado a ficheros de ordenador a travs de EDI es

infundado, sin embargo habr que resolver este miedo antes de que muchos directores
funcionales acepten EDI. Existen varias maneras de resolver el tema de la seguridad de
datos. En primer lugar, EDI no proporciona el acceso directo a ficheros internos. Al usar
una red de terceros, toda compaa dispone el envo de todos los mensajes a su buzn.
Adems, la compaa puede disponer la salida por marcacin para recuperar los
mensajes en lugar de permitir a la red de terceros que entre por marcacin en el
ordenador de la empresa. De esta forma, no existe el acceso, ni directo ni indirecto,
desde el exterior al ordenador de la compaa. Adems, en el caso de permitir la
Pgina 144
introduccin por marcacin a la red de terceros o a los interlocutores comerciales, se

pueden limitar las actividades que pueden realizar la parte ajena mediante el uso de
cdigos de autorizacin y claves de acceso.
9.10
EDI crea todo tipo de problemas legales
Las preocupaciones del personal jurdico tambin representan un obstculo.

Segn se ha mencionado anteriormente, muchos usuarios de EDI piensan que la
participacin del personal jurdico en el esfuerzo garantizar su fracaso, pues muchas
veces los abogados creen que EDI plantea problemas jurdicos insuperables. Sin
embargo, es imprescindible tener en cuenta los asuntos jurdicos durante la primera fase
de planificacin. Los abogados corporativos han expresado varias preocupaciones con
EDI. Los dos temas jurdicos ms importantes parecen ser la prdida de controles de
autorizacin y la legalidad de los documentos electrnicos.
9.10.1
Controles de autorizacin
En la mayora de las organizaciones, se establecen controles internos para

garantizar que solo el personal autorizado pueda realizar ciertas funciones. Por ejemplo,
normalmente se exige una firma en compras para obligar fondos, y a menudo la persona
que est autorizada a firmar variar en funcin del valor monetario del pedido de
compras. Con un pedido de compras electrnico, parece que no hay firma y por lo tanto
no hay control.
9.10.1.1
Solucin
Mediante el uso de cdigos de autorizacin y claves de acceso, se puede

configurar el sistema EDI para que solo el personal autorizado tenga acceso al sistema.
De esta forma, se puede validar la autoridad de la persona para transmitir un pedido de
compras concreto. Igual que con papel se puede disear un sistema EDI con unos
controles incorporados para garantizar que la misma persona no pueda requisar una
partida, autorizar su compra, documentar la recepcin y autorizar el pago. Se puede
establecer el mismo nivel de control en el campo electrnico mediante el uso de cdigos
de autorizacin que limitan el acceso al sistema y de firmas digitales o electrnicas que
identifican positivamente a la parte que las origina.
9.10.2
Legalidad de documentos
Los abogados tambin se preocupan por la legalidad de los documentos

electrnicos. Por regla general, los pedidos de compras de papel llevan incorporada una
seccin de trminos y condiciones estndares, normalmente escritas al dorso del pedido
y por lo tanto formando parte de cada uno de los pedidos. En un pedido de compras
electrnico, no existen estas condiciones estndares. Por lo tanto Cuales son los
trminos y condiciones que rigen el pedido? Adems existe la preocupacin sobre la
falta de un documento escrito y una firma escrita.
9.10.2.1
Solucin
La mayor parte de los usuarios de EDI resuelven este tema con el uso de
contratos de intercambio con los interlocutores comerciales. Normalmente, en estos
Pgina 145
contratos, se incorporan los trminos y condiciones bsicas que regirn todas las
transmisiones electrnicas. Otros usuarios incluyen una referencia a los trminos y
condiciones estndares en el segmento de datos de notas. Estos mtodos permitan la
inclusin de trminos y condiciones en los pedidos de EDI.
9.11
EDI elimina el registro de auditoria
Muchas compaas tambin se enfrentan con la oposicin de los auditores. La

preocupacin ms acusada de los auditores parece ser la de la eliminacin del registro
de auditora con la transmisin electrnica de documentos. Aunque EDI puede cambiar
la apariencia del registro de auditora, no lo elimina, De hecho, a menudo es el mejor
que en el entorno de papel.
9.11.1
Solucin
En EDI, todas las transacciones estn selladas con tiempo y fecha

automticamente. Normalmente el software EDI permite guardar un registro de todas
las transacciones. Estos mecanismos permiten un registro de auditoria que como
mnimo es tan fiable como la de papel, y en muchos casos mejor.
Adems, el centro de compensacin acta como notario electrnico: da fe de que un
documento ha sido enviado y recibido, y en que fecha.
9.11.2
Las comunicaciones con EDI no son seguras
Los auditores tambin se muestras preocupados con la integridad de la

informacin electrnica. En otras palabras, con una transmisin de papel, es bastante
fcil averiguar si alguien ha interceptado la transmisin y ha revisado o modificado la
informacin. Con las transmisiones electrnicas, piensan que se podra interceptar un
mensaje y revelar la informacin que contiene a un tercero, sin que se den cuenta ni el
remitente ni el destinatario. Existen dos mtodos de seguridad de datos para resolver
este problema de auditoria: la encriptacin y la autenticacin de datos.
9.11.2.1
Solucin
Con la encriptacin de datos se garantiza la confidencialidad de las

transmisiones electrnicas enviando un mensaje electrnico en formato codificado. El
remitente traduce el mensaje EDI a un mensaje codificado usando una clave a la que
tiene acceso solo el remitente y el destinatario. A la recepcin del mensaje codificado, el
destinatario utiliza la clave para traducir el mensaje. De eta forma, se garantiza la
confidencialidad del mismo.
La autenticacin de datos garantiza que el mensaje enviado es realmente el
mismo que el mensaje recibido. Aqu, lo importante no es mantener la confidencialidad
de los datos, sino garantizar que no se ha alterado el mensaje durante la transmisin.
Para la autenticacin de datos, se codifica un mensaje EDI utilizando una clave de
encriptacin, transmitiendo tanto el mensaje codificado como el no codificado al
interlocutor comercial. A la recepcin de los mensajes, el interlocutor utiliza la clave de
encriptacin para descodificar el mensaje codificado, comparndolo al mensaje original
no codificado. Si coinciden los dos mensajes, el destinatario puede estar seguro que no
se
alter
el
mensaje
durante
la
transmisin.
Pgina 146
Estos mtodos permiten garantizar la integridad de las transmisiones de EDI, sin

embargo su uso no est muy difundido porque la mayora de los mensaje enviados a
travs de EDI no requieren un control tan riguroso, puesto que tanto el software de
usuario como el centro de compensacin cuentan con medidas de seguridad suficientes.
9.11.3
Ninguno de nuestros interlocutores comerciales tiene EDI.
EDI es parecido al telfono, en que se requieren dos partes para su

funcionamiento. Obviamente, una organizacin no puede enviar un mensaje electrnico
si no hay otra parte para recibirlo. Un obstculo al crecimiento de EDI es la falta de
interlocutores comerciales que estn interesados, dispuestos y capaces a implantarlo.
Incluso se plantea este problema en las empresas en las que existen programas en curso.
El hecho de que no se pueda implantar EDI de forma unilateral representa otro tipo de
obstculo. Muchas organizaciones se dan cuenta de que con el tiempo, tendrn que
utilizar EDI. Si embargo, en muchos casos, estn esperando una peticin de un
interlocutor comercial antes de implantarlo, o sea, a menudo los dan estn esperando
que actu el otro primero.
9.11.3.1
Solucin
Se puede superar este problema de varias formas. Primero, se pueden averiguar

las compaas que estn dispuestas a iniciar un proyecto EDI, a travs del Proveedor de
Servicios
EDI.
En segundo lugar, se puede dar formacin y soporte a los interlocutores que no han
expresado un inters. Varias organizaciones crean jornadas de formacin, folletos
publicitarios y videos para su distribucin a interlocutores. Esta informacin est
diseada para sealar los beneficios de EDI y fomentar la participacin de los
interlocutores. Adems, se puede proporcionar a los interlocutores el hardware y el
software necesarios para realizar EDI. Para la pequea inversin inicial necesaria para
establecer un sistema de microordenador autnomo para los interlocutores, muchas
organizaciones han comprobado que reciben unos beneficios incrementales importantes.
9.12
Resumen
Existen varios obstculos a la implantacin de EDI, sin embargo la mayora son

figurados. En otras palabras, a menudo los usuarios potenciales estn mal informados
acerca de EDI. La formacin y el respaldo de al alta direccin permitirn eliminar
muchas de las ideas errneas.
Sin embargo, existe un obstculo ms serio y ms difcil de superar, que es la
conviccin de que EDI es una tecnologa que se puede superponer a la estructura actual
de la organizacin. Para que EDI sea un xito tanto dentro como entre organizaciones,
habr que derrumbar las fronteras tradicionales y replantear las operaciones, procesos y
relaciones de las empresas.
Pgina 147
CAP. 10
COSTES - BENEFICIOS
10.
10.1
Anlisis de costes/Beneficios
Introduccin
Aunque a menudo se piensa que la tecnologa de EDI tiene como objetivo lograr
un ahorro de costes, las ltimas encuestas de los usuarios de EDI indica que la razn
principal de la implantacin de EDI no es la de reducir costes. Un alto porcentaje de
usuarios manifiestan que el beneficio ms importante haba sido la mejora en la gestin
de la informacin y en los servicios de asistencia a los clientes, dejando la mejora de
costes
en
segundo
lugar.
Los pioneros en el campo de EDI y sus defensores tampoco recomiendan tratar EDI
como un modo de reducir costes. Segn se mencion anteriormente cualquier
organizacin que implanta EDI solo para ahorrar dinero no llegar a aprovechar todas
sus
posibilidades.
Entre los primeros usuarios de EDI, queda patente el reconocimiento de los beneficios
importantes que obtiene EDI adems de la reduccin de costes. En un estudio de
pioneros en las industrias del automvil, distribucin y otras, solo un 13% de las
empresas haban realizado una cuantificacin especfica de los costes de EDI, y solo un
27% la haban realizado de los beneficios, antes de la implantacin. Entre los
comentarios ms comunes para justificar la no realizacin de un anlisis detallado de
costes/beneficios, se encuentran los siguientes:
EDI llega al corazn de nuestro negocio. Los beneficios son tan obvios que no
merezca la pena gastar recursos para elaborar una documentacin de costes/beneficios.
No se consideran los costes importes y los beneficios son obvios. La decisin
intuitiva de seguir EDI preceda desde arriba.
10.2
10.2.1
Razones para documentar costes beneficios

Para intentar vender EDI a nivel interno
Muchos de los primeros usuarios de EDI basaron su decisin no en la reduccin

de costes sino en la reduccin del tiempo correspondiente al ciclo comercial y en otros
beneficios estratgicos como la mejora en las relaciones comerciales. Aunque parece
que los primeros pioneros y defensores incondicionales de EDI pensaban que no era
necesaria una cuantificacin de costes/beneficios, existen varias razones para realizarla.
En primer lugar, independientemente de lo importante que resulta EDI para la
supervivencia de la empresa, la mayora de las organizaciones exigen algn tipo de
justificacin econmica. Se puede justificar EDI econmicamente en base a ahorros
tangibles, por lo tanto parece lgico realizar el anlisis y aprovechar los resultados para
vender EDI por toda la compaa.
Pgina 148
10.2.2
Para permitir presupuestar las actividades de EDI
En segundo lugar, incluso en aquellas empresas en las que no se exige una

justificacin econmica (p.e. la alta direccin est convencida que lo necesitan para
sobrevivir), sigue resultando til una cuantificacin. Un anlisis de costes/beneficios no
solo indicar el nivel de recursos que habr que presupuestar para la implantacin, sino
tambin indicar los cambios financieros que se deberan prever conforme EDI va
integrndose en la compaa.
10.2.3 Para ayudar a definir la estrategia de EDI
La tercera razn para un anlisis de costes/beneficios se refiere a la seleccin de
una estrategia de implantacin. Los costes de implantacin de EDI y los beneficios
resultantes pueden variar mucho en funcin del nivel del sistema EDI que se
implementa. Dicho anlisis de las distintas opciones de EDI, junto con una revisin de
los recursos disponibles, permitirn determinar el tipo de sistema que se desea
implantar. En el caso de haber pocos recursos en el primer ao de operacin, una
compaa puede decidirse por la implantacin de un microordenador como front-end de
un mainframe, consiguiendo as unos costes iniciales bajos pero con la opcin de
ampliar el sistema ms adelante.
10.3
Comportamiento de costes y beneficios de EDI
Al realizar un anlisis de costes/beneficios, habr que tener en cuenta dos

caractersticas muy importantes de EDI, especialmente si la justificacin se basar en
aspectos econmicos. Estas caractersticas son las siguientes:
Los costes son los primeros; los ahorros se producen despus
Resulta fcil determinar los costes, pero los beneficios no.
10.3.1
Realizacin de costes/beneficios en el tiempo
Para la implantacin de EDI, pueden resultar necesarios muchos recursos

iniciales, incluso con el uso de un sistema de microordenador sencillo. Las actividades
de formacin, adquisicin o desarrollo de software, adquisicin del hardware necesario
(p.e. ordenadores, y mdem), ingreso en asociaciones y grupos normativos ocasionarn
costes antes de poder iniciar operaciones con EDI. La mayor parte de los costes de EDI
suelen
ser
fijos
y
al
principio.
Por otro lado, los beneficios tienden a variar en funcin del volumen de EDI, o sea van
incrementado conforme va aumentando el volumen de uso. En la mayor parte de los
proyectos de implantacin, se empieza con el intercambio de unos pocos documentos
con un nmero limitado de interlocutores comerciales, por lo tanto habr menos
beneficios
justo
cuando
los
costes
suelen
ser
mayores.
Es importante entender cuando se producirn los costes y beneficios, pues en las
primeras fases de EDI es muy probable que se pierda dinero. Durante este perodo de
tiempo cuando los costes superen los beneficios, la compaa debera mantener su
compromiso con el proyecto EDI. Normalmente, es durante este perodo cuando son
necesarios los mayores esfuerzos de marketing interno.
Pgina 149
10.3.2
Determinacin de costes beneficios
El segundo punto a tomar en cuenta en un anlisis de costes/beneficios es que

normalmente, es mucho ms fcil estimar los costes que los beneficios. Los costes
suelen ser cifras concretas, permitiendo un examen directo. Se puede determinar de
forma exacta los costes de formacin, software o servicios de terceros de EDI, pues
existe una factura por parte del proveedor. Tambin es fcil hacer un seguimiento del
tiempo y esfuerzo dedicado por el personal interno a la realizacin de desarrollos
propios o modificaciones de los programas existentes.
Al contrario, a menudo los beneficios no son claros, resultando subjetivas las
estimaciones de ahorros de inventario, la reduccin del papeleo y el impacto de la
mayor precisin de informacin. Adems, no se suele disponer de los datos necesarios
para
realizar
una
estimacin
completa,
ni
suelen
ser
exactos.
Es importante hacer esta distincin, pues puede afectar a la manera en que las otras
personas opinan sobre un anlisis de coste/beneficios. En muchos casos, no es probable
que se dude de los costes estimados, mientras que se pondr en tela de juicio los
beneficios. El equipo EDI tendr que darse cuenta de estas diferencias y estar preparado
para defender el anlisis y los beneficios estimados.
10.4
10.4.1
Categoras de costes de EDI

Costes de Hardware
Entre los costes de hardware de EDI, se encuentran los de la compra y

mantenimiento de los equipos de ordenador necesarios para realizar EDI. Muchas
organizaciones tendrn ya los equipos necesarios, pero algunas se enfrentarn con la
necesidad de comprar un ordenador y/o un mdem de comunicacin.
10.4.2
Costes de software
Existen dos categoras generales de costes de software: compra inicial de

software, desarrollos de interface de mantenimiento permanente. Hay dos factores que
determinan el nivel de estos costes. El primero es la configuracin del sistema EDI. Si
se usa un sistema de ordenador personal, los costes sern bajos, mientras que los costes
de
software
para
un
mainframe,
sern
superiores.
El mantenimiento permanente del software es necesario para garantizar que se podr
ejecutar las versiones actualizadas de las normas. Los costes anuales de mantenimiento
tambin
varan
en
funcin
del
tipo
de
sistema.
El otro factor que incidir en los costes de software es el grado de implantacin de EDI
en las aplicaciones internas. En caso de implantar EDI como funcin autnoma, solo
ser necesario el software de traduccin, sin embargo si se integra el sistema EDI en los
sistemas de aplicacin internos ser necesario un desarrollo de software adicional.
10.4.3
Costes de comunicaciones
En la utilizacin de una red de terceros se incurrirn en costes nicos y

progresivos. En la mayora de las redes de terceros, se cobra un precio inicial de
arranque y luego una cuota mensual.
Pgina 150
10.4.4
Costes de formacin
En todo el proyecto de implantacin de EDI, ser necesario un cierto grado de

formacin para el personal de la compaa y el del interlocutor comercial. Los costes de
formacin engloban tanto la que se imparte a nivel interno como la que imparta el
proveedor. Normalmente, la mayor parte de la formacin se imparte al principio, siendo
necesario despus un nivel limitado de formacin permanentemente para mantener al
personal al da de los cambios y tecnologa.
10.4.5
Costes de personal
Para la implantacin de EDI, se necesita el respaldo del personal de informtica

y participacin del equipo EDI. Mientras que en muchas compaas se asignan recursos
informticos al esfuerzo EDI y se carga el tiempo al proyecto EDI para calcular los
costes del proyecto, no suelen cargar el tiempo de otros miembros del equipo EDI ( p.e.
directores funcionales) al proyecto. Sin embargo, se suele cobrar al proyecto el nuevo
personal contratado para ello.
10.4.6
Costes de soporte externo
A menudo, las compaas contratarn servicios de consultara para ayudar en el

desarrollo de estrategia EDI. Normalmente esto tiene un coste fijo y nico que se
produce al principio del proyecto EDI.
10.4.7
Costes de ingreso en asociaciones
Normalmente, las compaas que tienen programas activos de EDI participan e

ingresan en asociaciones de EDI. Estas asociaciones suelen cobrar una cuota nica de
ingreso o una cuota de interlocutor anual.
10.4.8
Costes por valor temporal
Otro coste en que se puede incurrir con EDI es la prdida de tiempo de flotacin,
que se produce al hacer los pagos antes a los proveedores. Este coste en funcin del
porcentaje de los pagos que se realizan de modo electrnico, el volumen del cash flow y
el coste del dinero dentro de la organizacin.
10.4.9
Resumen de costes EDI
La figura siguiente es una hora de trabajo para el resumen de costes, en que se

resumen las varias categoras d costes. As cifras exactas variarn de una organizacin a
otra en funcin de la estructura de costes de la empresa y estrategia especfica de EDI
seleccionada.
Pgina 151
10.5
Categoras de beneficios de EDI
Segn se ha mencionado anteriormente, es mucho ms fcil estimar los costes de

EDI que los beneficios que proporciona. Mientras que algunos beneficios son obvios y
medibles, por ejemplo una reduccin en los gastos de correo, hay otros que son mucho
ms difciles de calcular, por ejemplo la mayor productividad del personal. A
continuacin se describen varios tipos de costes que se pueden ahorrar con la
implantacin de EDI.
Es de destacar que muchas empresas que han documentado ahorros con EDI
basan sus cifras en los costes ahorradas por documento. Sin embargo, los ahorros de
costes documentados representan reducciones en varias reas, por ejemplo personal,
Pgina 152
equipos, correos, material de oficina, etc., por lo que a continuacin se describen estas
categoras.
10.5.1
Ahorros en costes de personal
Con la implantacin de EDI, se eliminan varias actividades administrativas que se

suelen realizar en un sistema basado en papel. Por lo tanto, se pueden ahorrar en los
costes de la realizacin de estas actividades, entre las que se encuentran las siguientes:
Nuevos tecleados de operaciones de datos.
Costes de procesamiento de correo (llenando sobres, poniendo direcciones).
Costes de los trabajos de archivo.
Conformacin de varios documentos.
Seguimiento de documentos incorrectos, perdidos o atrasados.
Los ahorros reales que se pueden conseguir en los costes de personal irn en funcin
de varios factores.
Primero, los ahorros son variables en base al porcentaje del volumen de EDI.
Cuando ms grande sea el volumen, mayores sern los ahorros.
En segundo lugar, el valor monetario de los ahorros variar considerablemente
en base a las personas que realizan las anteriores actividades en la actualidad.
Por ejemplo, en algunas organizaciones el seguimiento lo realiza el personal
administrativo, mientras que en otras lo realizan los compradores.
Un tercer factor que incidir en el importe real de los ahorros conseguidos se
refiere a lo que se dedicar el tiempo ahorrado con la eliminacin de dichas
actividades. Algunas organizaciones han conseguido reducir el nmero de
personal con EDI, mientras que otras no han reducido personal, pero les ha
permitido asignar el personal actual a otras actividades. En este ltimo caso, se
estiman los ahorros en base al nmero de personal que se hubiera tenido que
contratar si no se hubiera podido hacer nuevas asignaciones del personal
existente.
10.5.2
Ahorros de papel
Como con EDI se sustituyen los documentos de papel por los electrnicos, como
consecuencia se reducen los costes de papel. Entre estos costes, se encuentran los de los
formatos de papel, de almacenamiento y de correo, siendo variables en base al nivel de
aprovechamiento de EDI.
10.5.3
Ahorros de inventario
EDI permite a menudo la reduccin de los niveles de inventario, debido a una

reduccin del tiempo del ciclo de pedidos, as como una menor incertidumbre respecto a
dicho tiempo. Los ahorros de inventario van en funcin del nmero de das que se quita
al inventario y el coste que supone la existencia de dicho inventario. Adems, una
reduccin del inventario supone generalmente una reduccin de los costes de
almacenamiento.
Pgina 153
10.5.4
Beneficios de valor temporal
En caso de usar EDI para cobrar, lo ms probable es que se disponga antes del
dinero. El beneficio monetario de adelantar el cobro variar en base al nmero de
cobros que se reciben antes. El importe del ahorro va en funcin del tiempo adicional en
que se encuentra disponible el dinero y del coste de dinero de la organizacin.
10.5.5
Ahorros de costes de informacin
EDI permite unos ahorros adicionales gracias a la disponibilidad de una informacin

puntual y exacta. Unos ejemplos de estos ahorros son:
Reduccin de las situaciones de existencias agotadas y prdida de ventas
Reduccin de las paradas de lacas cadenas de produccin.
10.5.6
Otros beneficios
En la mayora de las organizaciones, se pueden cuantificar los beneficios arriba

mencionados. Adems existen otros beneficios que no se prestan a una cuantificacin
fcil, pero a menudo forman parte de la decisin de implantar EDI. Los factores de la
mejora de las operaciones internas, unas relaciones ms estrechas con los proveedores,
el mantenimiento de la base de clientes y el mayor volumen de ventas debido a la mayor
productividad del personal tiene valor para una compaa, debiendo considerarlos a la
hora de tomar su decisin.
En la figura se da un resumen de los beneficios cuantificables que resultan de
EDI en que se describe cada tipo de beneficio y se ofrecen sugerencias para calcular
estos beneficios.
10.5.7
Anlisis de beneficios
Los beneficios de EDI suelen ser variable en funcin del volumen de EDI. Para
calcular los ahorros, muchas organizaciones los estiman en base a una conversin del
Pgina 154
100% desde papel a EDI, ajustando despus los ahorros para reflejar el nivel real del
volumen de EDI.
10.6
Preparacin de un anlisis de costes/beneficios
La figura siguiente es una hoja de trabajo para combinar los costes y beneficios
de EDI para poder mostrar el resultado monetario neto de su implantacin. A la hora de
calcular el impacto econmico total de EDI, habr que tener en cuenta varios puntos.
En primer lugar, se debera realizar el clculo para un periodo de tiempo de
varios aos. Los costes de EDI suelen ser a corto plazo, mientras que los beneficios son
a largo plazo, por lo tanto no se debera realizar el anlisis en base a un ao, sino en
base a un periodo superior.
En segundo lugar, el anlisis debera tener en cuenta el ndice de crecimiento del
proyecto EDI. La mayor parte de los beneficios son variables en base al volumen de
EDI, mientras que la mayor parte de los costes suelen ser fijos. En el anlisis, se debera
realizar una estimacin del volumen de transacciones que sern convertidas cada ao
desde papel al medio electrnico.
10.6.1
Resultado neto de la implantacin de EDI
Arranque
Costes iniciales totales + Ahorros iniciales (normalmente 0)
Perdidas / Ganancias netas de arranque
Ao uno
Total
de
costes
fijos
anuales
Total de costes anuales variables * Factor de conversin + Beneficios variables totales
X Factor de conversin
Perdidas /ganancias netas del ao uno
Ao dos
Total
de
costes
fijos
anuales
Total de costes anuales variables X Factor de conversin + Beneficios variables totales
X factor de conversin
Perdidas /ganancias netas del ao dos
Ao tres
Igual que el ao dos, ajustado para el factor de conversin.
Pgina 155
CAP. 11
SISTEMAS DE MENSAJERA
11.1
Introduccin
Un sistema de mensajera electrnica (MHS) es una solucin para el intercambio

de informacin, tanto dentro de una organizacin como con el exterior, que proporciona
una gran flexibilidad a un coste razonable. Se conoce ms vulgarmente como Correo
Electrnico y en sentido mplio hay que hablar de Mensajera Interpersonal (IPM) y
mensajera EDI (EDIMP)
Los sistemas de mensajeria electrnica, diseados para crear, unir y extender la
comunicacin entre los usuarios dentro de un concepto global de negocio, pretende:
Dar comunicacin interna entre usuarios pertenecientes a la misma empresa o

con usuarios externos a la misma.
Proporcionar soluciones a las compaas que carecen de mensajera electrnica o
completar la mensajera de la que disponen.
Dar solucin a la comunicacin entre usuarios, entre usuarios y terceros que
dispongan de terminales informticos.
Reducir el coste de las comunicaciones de empresa.
Tratar la informacin en funcin de las necesidades de cada usuario.
El estndar de correo electrnico es el X.400. Esta normativa X.400 es un conjunto

de recomendaciones del ITU, que define cmo se direcciona un mensaje entre distintas
mensajeras electrnicas, permitiendo el intercambio de mensajes entre usuarios de
distintos correos electrnicos que cumplan dicha normativa.
La ventaja ms clara que el X.400 ofrece al mundo del correo electrnico, es que la
existencia de direccionamientos estandarizados hace que el contactar con los usuarios
de otros sistemas de correo electrnico sea algo casi tan fcil como llamar al compaero
de al lado.
Los mensajes se envan utilizando una direccin completa, que identifica un buzn
de manera nica en la red mundial. Esta direccin recibe el nombre de Nombre de
Organizador/Receptor
(O/R).
Una direccin O/R se compone de una larga serie de atributos muchos de ellos
opcionales, que identifican unvocamente al usuario.
Atributo
Generation Qualifier
Clave Descripcin
Q
MR.Junior, etc.
Surname
Apellido del usuario
Given Name
Nombre del usuario
Unidad de Organizacin OU
Nombre de la Unidad dentro de la Organizacin (1..4)
Organizacin
Nombre de la organizacin
Pgina 156
PRMD
Dominio de gestin de privado
ADMD
Dominio de Gestin de la Administracin
Country
Cdigo de Pas
La columna clave se utiliza para describir de forma abreviada una direccin

X.400. Por ejemplo:
G=Esteban; S=Garca; O=UDC; OU1=SIX; OU2=CPD; ADMD=400NET; C=ES
11.2
11.2.1.
Conceptos MHS (X.400)

Sistemas de mensajera interpersonal
El modelo de un servicio de mensajera interpersonal (IPM) o correo electrnico,

es el mismo que el del sistema postal convencional, en el que los usuarios remiten
mensajes en un sobre cuyo contenido es tratado confidencialmente por el sistema que se
encarga de su entrega.
La norma X.400, introduce una serie de servicios, entidades y protocolos que
normalizan los sistemas abiertos de Gestin de Mensajes, formando parte de las
recomendaciones OSI. Los documentos ms importantes involucrados en la normativa
X.400 son:
X.400 Introduccin general del sistema y servicios
X.402 Arquitectura general
X.403 Pruebas de conformidad
X.407 Definicin de servicios abstractos y convenciones
X.408 Reglas de conversin de tipos de informacin codificado.
X.411 Sistema de Transferencia de Mensajes. Definicin de servicios (P1).
X.413 Almacn de mensajes. Definicin de servicios (P7).
X.419 Especificaciones del protocolo de acceso de mensajes (P3).
X.420 Agente de usuario de mensajera interpersonal (P2).
X.435 Especificaciones de X.400 y EDI.
El CCITT ha utilizado ciclos de 4 aos para la renovacin y actualizacin de
normativas X.400. La primera se hizo en 1984, despus en 1988.
La normativa de 1984 se la conoce como el Libro Rojo y la del 1988 Libro Azul,
por ser se el color externo de las publicaciones.
En los Estados Unidos, el National Institute of Standard and Technology (NIST) ha
publicado un documento llamado "Stable Implementation Agreement for Open Systems
Internconection Protocols". Este documento proporciona perfiles funcionales para las
recomendaciones X.400. El gobierno de los Estados Unidos ha ratificado estos
documentos y ahora forman la base de las especificaciones OSI para la adquisicin de
bienes por el gobierno de Estados Unidos; son las normas conocidas como US GOSIP.
En Europa grupos patrocinados por la Comisin Europea de Normalizacin (CEN),
la Comisin Europea de Normalizacin Electrotcnica (CENELEC) y la Conferencia
Pgina 157
Europea de Correos y Telecomunicaciones (CEPT) tambin han publicado perfiles

funcionales para la implementacin de X.400. Son las normas ENV 41 201 y ENV 41
202. En el Reino Unido el gobierno tambin ha generado sus propios perfiles (UK
GOSIP).
11.2.2.
Modelo de un sistema de gestin de mensajes
El trmino Sistema de Gestin de Mensajes (MHS) se refiere a una serie de

sistemas diseadas para ofrecer un servicio de Mensajera Interpersonal (IPM) o correo
electrnico o soporte para remitir EDI.
Tpicamente, un sistema de mensajera proporciona al usuario los mecanismos
necesarios para transferir pequeos volmenes de informacin (mensajes) a uno o ms
interlocutores (destinatarios) situados en ubicaciones locales o remotas. Los
destinatarios no tienen que estar conectados a la red en el mismo instante en que el
mensaje es enviado sino que pueden recibirlo con posterioridad. El componente emisor
de un sistema de mensajera puede conectarse directamente al componente destinatario
o a travs de componentes intermedios. En este ltimo caso, el sistema de mensajera
utiliza la tcnica de comunicaciones conocida con el nombre de almacenamiento y
reenvo.
Los Servicios de Tratamiento de Mensajes, en adelante conocidos con el nombre
de MHS , estn definidos en un conjunto formal de normas OSI. Se hace distincin
entre
el
MHS
y
los
sistemas
de
mensajera.
El
MHS
no
normaliza cada una de las funciones asociadas a un sistema de mensajera (las citadas
anteriormente). Ms bien, la meta del MHS es asegurar la interoperabilidad entre las
diferentes partes de un sistema de mensajera, cada una de las cuales puede estar
localizada en sistemas de comunicaciones informticos diferentes.
Pgina 158
11.2.3.
Funcionalidades que ofrece el MHS
El MHS proporciona al usuario capacidad para construir un sistema de

mensajera a partir de los componentes que puede comprar a diferentes suministradores.
Tambin proporciona la capacidad necesaria para que el sistema de mensajera pueda
interoperar con los sistemas de mensajera de otros usuarios localizados en cualquier
parte del mundo.
Las normas MHS no abarcan la interfaz hombre/mquina. Es en esta rea donde
los suministradores pueden incluir funcionalidades que proporcionen a sus productos un
valor aadido y caractersticas diferenciadoras.
La disponibilidad de las funciones citadas al principio puede estar limitada por la
conectividad de los sistemas de mensajera asociados. Tambin se ha de tener en cuenta
que la comunicacin entre usuarios depende, adems de las capacidades del MHS, de
las caractersticas tanto de las estaciones de trabajo como de la interfaz suministrada a
los usuarios, por ejemplo, pueden tener capacidad para procesar el tipo de informacin
que se recibe o capacidad para hacer frente a mensajes de un tamao dado.
Un sistema de mensajera puede incluir las siguientes funciones:
Preparacin del mensaje
Recepcin y visualizacin del mensaje
Envo del mensaje a uno o ms destinatarios
Gestin del sistema de mensajera
Administracin de los usuarios del sistema de mensajera
Seguridad en la mensajera
Archivo, clasificacin y recuperacin de mensajes
Acceso telemtico (por ejemplo, desde telefax)
Entrega sobre papel
Acceso a informacin de direccionamiento
Los servicios de mensajera interpersonal ponen a disposicin del usuario una serie
de herramientas para poder intercambiar todo tipo de informacin con los interlocutores
conectados al servicio.
Generalmente, los sistemas de oficina actuales ofrecen las siguientes funciones:
La preparacin de mensajes y la presentacin visual (se realiza en una estacin
de trabajo).
El envo del mensaje a un buzn y su archivo (se realiza en un servidor
dedicado).
La transferencia del mensaje y el encaminamiento a travs de diferentes
servidores y estaciones de trabajo (se realiza a travs de una aplicacin que
puede ejecutarse en un servidor dedicado, o integrarse en la estacin de trabajo,
o bien en el servidor de buzn de mensajes).
Estos componentes diversos pueden interactuar a travs de redes de comunicaciones
privadas y pblicas, con el fin de enviar, archivar y recuperar mensajes.
Pgina 159
Las funciones de administracin pueden realizarse mediante un centro de

administracin sobre un servidor dedicado, o bien incorporarse a los anteriores. Cada
una de ellas est sometida a funciones de seguridad.
A continuacin se estudia de forma pormenorizada cada uno de los servicios que
proporciona el MHS.
Preparacin del mensaje
El elemento de informacin que va a enviarse puede existir previamente, o bien
puede crearse en el momento de preparacin del mensaje. La preparacin del
mensaje puede ser dirigida por un usuario humano, o bien ser automatizada.
La preparacin del mensaje consiste en indicar al sistema de mensajera cundo,
cmo y a dnde debe enviarse el mensaje y qu contenido transporta ste.
La informacin transportada por el mensaje puede contener, desde el punto de
vista de MHS, cualquier tipo de informacin (texto, grficos, voz, archivos
binarios,
etc.).
Debido a que la informacin que se desea enviar puede haberse elaborado
mediante aplicaciones informticas de cualquier tipo, lo que incluye
procesadores de texto, paquetes de contabilidad, paquetes EDI, etc., la interfaz
entre dichas aplicaciones y el sistema de mensajera es una cuestin importante.
Si el mensaje es preparado por un usuario humano, la estacin de trabajo debe
ofrecer una interfaz adecuada para realizar el dilogo. Cuando se prepara el
mensaje, no es necesario que ste se enve inmediatamente. Puede almacenarse y
enviarse posteriormente, ya sea previa solicitud del usuario humano o mediante
un activador automatizado, basado, por ejemplo en criterios de fecha y hora.
La preparacin de mensajes puede ofrecer una amplia gama de posibilidades al
usuario, o bien ser muy directa, en funcin de los requisitos de servicio y del
nivel del producto.
Recepcin y visualizacin de mensajes
Anlogamente, el destinatario del mensaje puede ser una aplicacin o un usuario
humano. El objetivo ltimo del usuario humano es visualizar el mensaje. Ello
puede realizarse presentando el mensaje en pantalla o imprimindolo en papel.
Antes de ser presentado, el mensaje se almacena en un buzn, que consiste en
cierta cantidad de memoria dedicada al destinatario del mensaje. Generalmente,
los usuarios pueden gestionar el contenido del buzn, generando una lista con un
resumen de su contenido, recuperando mensajes concretos aplicando ciertos
criterios, guardando copias de los mensajes y eliminando mensajes. Asimismo,
pueden proporcionarse diversas funciones para mejorar la interfaz del usuario
tanto del remitente como del destinatario de los mensajes: tan pronto como se
deposita un mensaje urgente en el buzn, pude presentarse un aviso destinado al
usuario propietario de dicho buzn, mediante un efecto visual o acstico en la
estacin de trabajo, etc.
Pgina 160
Envo del mensaje

Una vez preparado el mensaje, se puede enviar a uno o ms destinatarios. Para
ejecutar la funcin de envo el sistema de mensajera tiene que identificar la
ubicacin de los buzones de cada uno de los destinatarios. Estos buzones pueden
encontrarse en el mismo sistema o estar distribuidos por diferentes sistemas
remotos interconectados entre s. Si uno o ms buzones destinatarios se
encuentran ubicados remotamente, se hace necesaria la transferencia electrnica
del mensaje a travs de conexiones externas.
Gestin de sistema de mensajera
La utilizacin de un sistema de mensajera no consiste nicamente en realizar el
intercambio de mensajes, sino que incluye el seguimiento del comportamiento
del sistema de mensajera: el administrador del sistema de mensajera debe ser
capaz de examinar el comportamiento interno del sistema (encaminamientos
seguidos por los mensajes, retrasos en las transferencias, congestin, etc.)
configurar el sistema con arreglo a los requisitos de servicio, recibir aviso de los
problemas mediante alarmas y reaccionar a dichos problemas utilizando
herramientas para finalidades especficas.
Administracin de usuario de sistemas de mensajera
La administracin de usuarios consiste en el registro de usuarios, la
identificacin de los mismos, la administracin de las listas de distribucin, etc.
Esta tarea puede ser realizada utilizando guas que describan a los usuarios,
indicando su nombre, direccin, emplazamiento, caractersticas del negocio,
caractersticas de mensajera (como los tipos de terminales que utilizan para
acceder al sistema, la longitud mxima de los mensajes que pueden recibir, los
tipos de informacin que pueden incorporar los mensajes recibidos, etc.) y los
derechos de acceso del sistema de mensajera.
Seguridad de los mensajes
En funcin de los requisitos de los usuarios que participan en el intercambio de
mensajes, pueden ofrecerse o no caractersticas de seguridad, a travs de
funciones
de
seguridad.
Puede ser importante verificar que el mensaje realmente ha sido enviado por la
persona que afirma haberlo hecho, que dicho mensaje es recibido por la persona
adecuada y que ello puede demostrarse, que el mensaje no pueda ser ledo por
personas o sistemas que no deben conocer su contenido, que el mensaje no
puede modificarse durante su transferencia, etc.
Algunos entornos de usuario necesitan de forma muy acusada dichas
caractersticas, que se implementan, por ejemplo, a travs del encriptado de
mensajes o la incorporacin de firmas digitales. A nivel bsico, es necesario el
control de acceso a los servicios (o la base de los derechos de acceso, etc.)
Pgina 161
La unidad de transferencia es el mensaje, por lo que los protocolos de

comunicaciones garantizan la integridad de dicha unidad de transferencia ante
posibles incidencias del servicio.
Archivo, registro y recuperacin de mensajes
Es muy conveniente disponer de la capacidad de archivar y recuperar los
mensajes que se han enviado o recibido. Ello puede realizarse mediante un
sistema de archivo o de almacenamiento/recuperacin que sea especfico y que
sea ofrecido por el sistema de mensajera, o bien a travs de un sistema
independiente,
integrado
en
el
sistema
de
mensajera.
Si algn nodo de la red se encuentra fuera de servicio los mensajes destinados a
l quedan almacenados hasta que la conexin se restablezca.
Control de accesos
Todos los usuarios deben estar dados de alta en el servicio y se identifican por
una larga serie de atributos, muchos de ellos opcionales, que identifican
unvocamente al usuario y una contrasea de acceso.
Es posible incorporar pasarelas entre el sistema de mensajera y servicios
telemticos. Las funciones de interconexin ms importantes son, por ejemplo,
las que se realizan con fax y tlex.
Interconectividad
El centro servidor mantiene conexin con otros ADMD nacionales e
internacionales para garantizar que cualquier mensaje transmitido llegue a su
destino.
Envo multidestino
El centro servidor permite enviar el mismo mensaje a uno o varios destinatarios
con lo cual se evita enviar varias veces el mismo mensaje.
Notificacin de entrega
A peticin del usuario, el centro puede informar al remitente del mensaje que
dicho mensaje ha sido entregado al buzn del destinatario al que iba dirigido.
Envo urgente
El centro servidor asegura un trato prioritario a aquellos mensajes que se han
enviado mediante esta modalidad frente a los que son enviados en modalidad
normal.
Estadsticas
A peticin del usuario se puede generar estadsticas sobre los mensajes
enviados, destino, tamao, etc.
Pgina 162
Listas de distribucin
Permite la gestin y mantenimiento de listas de distribucin para el envo de un
mensaje y mediante una nica conexin a todos los usuarios de la lista
seleccionada.
Capacidad de grupo cerrado de usuarios
La facilidad de grupo cerrado de usuarios permite limitar el intercambio de
mensajes a un nmero limitado de usuarios. Esta capacidad permite establecer
de antemano el origen de los mensajes que se reciben.
Envos multicuerpos
Un mismo mensaje puede tener cuerpos, cada uno de ellos con un tipo de
informacin distinta (ficheros de texto, binarios, fax, imagen, etc.).
Con el fin de controlar la evolucin de un sistema de mensajera y
resolver los problemas que plantea, en trminos de mejora funcional, as como
en trminos de capacidad, contener los costes de transmisin, y con capacidad de
apertura hacia otros sistemas de mensajeras pertenecientes a otras
organizaciones, es conveniente distribuir las diversas funciones de los sistemas
de mensajera entre los diferentes equipos conectados entre s.
11.2.4. Cundo usar el MHS
El MHS es la solucin adecuada para el intercambio corporativo de informacin
con sistemas remotos cuando los requisitos de la mensajera no exijan la transferencia
de mensajes en tiempo real. Si se requiere transferencia en tiempo real, deben
considerarse soluciones basadas en ftam y/o tp. Los tipos de informacin normalmente
transferidos son ficheros de texto y de datos, notas, mensajes e informacin de formato
indefinido. Si la informacin tiene un tamao superior a los 2 megabytes, los perfiles no
garantizan su correcto tratamiento, por lo que, en general, deber optarse por soluciones
basadas en ftam.
El destinatario y el remitente pueden estar:
En la misma o en diferentes organizaciones
En la misma o en diferentes localidades o incluso en diferentes pases
El MHS ofrece los siguientes:
Beneficios:
Dado que el mensaje se enva y se almacena de forma electrnica, un nico
mensaje puede ser enviado a diferentes destinatarios sin que sea necesaria su
reintroduccin
Ahorra tiempo, puesto que el destinatario no tiene que estar disponible para la
comunicacin directa
Pgina 163
Reduce el tiempo de entrega y ahorra costes respecto a la transmisin va

facsmil o correo fsico
Incrementa la flexibilidad en lo que se refiere a localizacin y ubicacin fsica
de las tareas
Reduce los tiempos de espera en la ejecucin de las tareas, en especial si las
mismas son tareas distribuidas
Puede ser utilizado como base de un servicio de comunicaciones fiable
(notificacin de entrega, caractersticas de seguridad, etc.)
Ventajas:
Bajo coste
Ahorro de dinero al tratar volmenes altos de informacin sin necesidad de
inversin en equipos de gama alta optimizando el uso de los actuales recursos
informticos de la empresa.
Expansin-Crecimiento en funcin de las necesidades del usuario
Solucin a medida y Disponibilidad inmediata.
Acceso en toda Espaa.
Cobertura nacional e internacional sin que el usuario tenga que hacerse cargo de
las comunicaciones con cada destino.
Disponibilidad 24 horas del da.
Requisitos:
Ordenador personal
Mdem V22, V22 Bis, V32. V32Bis, V34
Lnea telefnica
Software de usuario.
11.3.
Trminos y Conceptos Bsicos de MHS
Por analoga con el servicio postal tradicional, un mensaje consta de un sobre y

un contenido. La principal funcin de la informacin contenida dentro del sobre es
permitir la entrega del mensaje a los destinatarios adecuados (el sobre puede incluir uno
o varios destinatarios). Tambin identifica el formato del contenido para permitir en
recepcin el procesamiento adecuado del mensaje. Adicionalmente, la informacin del
sobre permite que se efecte la retransmisin del mensaje.
Dado que un MHS puede utilizarse para diferentes propsitos, existen diferentes
formatos de contenido de mensaje. Hasta la fecha, ha sido normalizado un contenido
copia del correo tradicional (Mensaje Interpersonal: ipm), y otro relativo a EDI
(Mensaje EDI: edim).
El usuario final puede ser un usuario humano o un proceso de aplicacin. El
MHS puede soportar diferentes estilos de intercambio de informacin. Hasta ahora han
sido normalizados dos estilos relacionados con los dos tipos de contenido identificados
en lneas anteriores: Mensajera Interpersonal (IPM) y Mensajera EDI (EDImg).
La siguiente descripcin de la terminologa utilizada en MHS se ilustra en la
figura anterior, la cual debe interpretarse como una representacin lgica. El usuario
Pgina 164
final puede acceder al MHS de diferentes formas. Un usuario final humano puede
disponer de una interfaz soportada por un equipo que puede ser o no co-residente con un
UA. De forma similar, un proceso de aplicacin puede estar ubicado en un equipo que
puede ser o no co-residente con un UA. En la actualidad existen dos tipos de UA : ipm
UA y edim UA. Sin embargo, en las descripciones siguientes se utilizar l termino
genrico UA sin calificativo alguno.
Adicionalmente un usuario final puede acceder al MHS a travs de otro servicio
que se conecta, en este caso, a travs de una Unidad de Acceso (AU). De esta forma, el
usuario final humano puede recibir mensajes en soporte papel. El sistema que contiene
los dispositivos de impresin se conecta a la Unidad de Acceso a la entrega fsica
(PDAU).
11.3.1.
MTA
MTA (Message Tranfer Agent). Es el nodo de intercambio de mensajes dentro

del sistema. Son los encargados de proporcionar el servicio bsico de transferencia que
permite la emisin y entrega de los mensajes. Varios MTA conectados forman el
sistema de transferencia de mensajes. Si lo comparamos con el servicio postal los MTA
trabajan con la informacin del sobre. Las direcciones que manejan son los nombres del
Originador/Receptor.
La responsabilidad de la entrega de un mensaje se va trasladando de un MTA a otro a
media que el mensaje progresa por la red.
MTA realiza las siguientes funciones:
Acepta el mensaje remitidos por el UA del remitente dirigidos a un UA receptor
o a otro MTA.
Acepta mensajes recibidos por otra MTA para que los reciba un UA, otro MTA
o un AU.
Analiza la lista de receptores en el mensaje y realiza el enrutado.
Si la direccin de un mensaje corresponde a un UA servido por l, pasa el
mensaje al UA y si es necesario genera una notificacin de entrega.
Si la direccin indica que un mensaje nececesita que se pase a otro MTA, pasa
el mensaje al prximo MTA.
Si no puede resolver la direccin, genera una notificacin de no entrega para esa
direccin.
El remitente del mensaje provoca que su UA pase un mensaje a su MTA local. Este
MTA analiza la direccin del mensaje y transfiere el mensaje al MTA adecuado. Este
MTA vuelve a analizar la direccin y o bien pasa el mensaje al UA o al MTA
apropiado. Esta forma de proceder continua hasta que un MTA recibe un mensaje
dirigido a uno de sus UA y se lo pasa, entonces genera una notificacin de entrega, que
se dirige a quien envi el mensaje. El MTA funciona de forma similar para reenviar esta
notificacin
a
travs
de
la
red.
Los MTA pueden tener ms funcionalidades como por ejemplo, si un mensaje va
dirigido a varios receptores, uno o ms MTA puede crear copias del mensaje y cada
copia entregarla a su correspondiente receptor.
Pgina 165
Ya se ha indicado que varios MTA forman un MTS . Dado que tanto usuarios como
proveedores solicitan diferentes grados de funcionalidad y de prestaciones, todos los
MTA no son idnticos. El problema se presenta cuando se deben conectar estos
diferentes MTA. El problema se resuelve de la forma siguiente:
Cuando los MTA se intercambias mensajes, primeramente se codifican los mensajes y
las notificaciones utilizando el formato P1, en segundo lugar intercambian mensajes
utilizando un conjunto de protocolos referenciados como RTS (1984) o Protocolo de
Transferencia de MTA (1988).
11.3.2.
MS
El MS (Message Store) es el buzn electrnico del usuario dentro del sistema

donde se almacenan los mensajes remitidos por sus interlocutores. Define formalmente
el buzn, su estructura y las operaciones que se pueden realizar sobre l.
EL MS se aadi a las recomendaciones de 1988 para eliminar algunos problemas
relativos a la disponibilidad de conexin del PC y proporcionar al MTS un interface
para que se parezca ms a un servicio de correos. Una instancia particular de un MS es
un objeto que se coloca entre el UA y el MTA, sirve a un nico UA y proporciona los
siguientes servicios:
Cuando un MTA tiene un mensaje que entregar a un UA servido por un MS,
entrega el mensaje al MS en lugar de al UA. Recupera el mensaje de un MS
segn convenga. Desde el punto de vista del MTS, el mensaje se entrega cuando
se transfiere al MS y el MTA genera una notificacin de entrega.
Cuando el usuario de un UA servido por un MS enva un mensaje, el UA del
usuario enva el mensaje al MS en vez de al MTA. El MS, a su vez, enva el
mensaje al MTA. Es lo que se conoce como remisin indirecta.
El MS proporciona funciones adicionales tales como la capacidad de listar o
borrar mensajes retenidos por el MS en nombre del UA al que sirve.
El UA que accede al MTS va un MS tiene que acceder no solo a todos los
elementos de servicio disponibles al UA, que accedes el MTS directamente (usando el
protocolo P3), sino que tambin a los elementos de servicio proporcionados por el MS,
tal y como la capacidad de listar resmenes de los mensajes retenidos por el MS o la
capacidad
de
solicitar
mensajes
especficos.
Las recomendaciones X.400 especifican tanto formatos y protocolos entre el MS y el
UA como los servicios proporcionados por el MS al UA. El interface entre un UA y su
MS se refieren como el protocolo P7. Estos servicios y formatos se les conoce como
X.431, a los protocolos se les conoce como recomendacin X.419 Protocolos de acceso
MS.
11.3.3.
UA
UA (User Agent) Es la interfaz entre el usuario y el sistema X.400 a travs del

MTS. Son las entidades que permiten al usuario el acceso al servicio de Mensajera
Interpersonal (IPM). Un UA debe tener las siguientes funcionalidades:
Cuando el usuario genera un mensaje, ste se codifica en un formato que el UA
receptor puede entender. (protocolo P2).
Pgina 166
Pasa el mensaje P2 con la informacin adicional necesaria para transferir al

MTA.
Un UA receptor interactua con el MTA y recibe los mensajes del l, junto con la
informacin de transmisin relativa al mensaje, dirigida al usuario que sirve.
El UA decodifica los mensajes que recibe del MTA y se los presenta al receptor
en un formato fcil de tratar. Adems, despus de decodificar el mensaje, el UA
puede realizar alguna accin o notificar al usuario acerca de los elementos
relativos al mensajes, tales como la solicitud del remitente de que se espera que
se conteste al mensaje.
El UA proporciona un conjunto de servicios que permiten la preparacin de
mensajes. Permite al usuario final construir el sobre del mensaje, incluyendo en el
mismo informacin relativa a:
Direccionamiento
Peticin de informe de recepcin
Prioridad del mensaje (normal, urgente, etc.)
Informacin necesaria para la distribucin del
destinatarios de copia oculta, etc.
Marcas de da/fecha
Tratamiento especial (entrega registrada, registro, etc.)
mensaje: direcciones,
Junto a estas funcionalidades bsicas, un sistema completo UA pude proporcionar al

usuario servicios extra. Algunos de estos se proporcionan con la ayuda de X.400. Por
ejemplo un UA puede marcar mensajes que han quedado obsoletos en su sistema de
almacenamiento debido a la recepcin de mensajes ms recientes, haciendo uso del
servicio
"indicacin
de
obsolescencia".
Esos servicios se definen en el sistema X.400. Otros servicios se pueden proporcionar
como pare del interface de usuario del UA. X.400 no define ningn tipo de interface de
usuario. De forma que el usuario se puede encontrar con un interface primitivo como
una lnea de comandos o bien con un completo interface grfico.
Al UA le sirve el MTA con el que est registrado. Siempre enva sus mensajes al
mismo MTA, y los mensajes dirigidos a un determinado UA siempre se entregan a un
UA por el mismo MTA.
Debido a que el UA es el interface entre el usuario y el Sistema de Gestin de
Mensajes (MHS), esto hace que se pueda aumentar la funcionalidad si se ajustan los
mensajes que trata para proporcionar la mxima funcionalidad al usuario. Como los
usuarios finales de un MHS son personas, la denominacin elemental que recibe es IPM
(Interpersonal
Messaging).
El UA que soporta IPM recibe el nombre de IPM-UA. Existen otros tipos de UA para
tratar con otros tipos de mensajes, por ejemplo existe el EDI-UA para transferir
mensajes
EDI.
De esta forma se asegura siempre que existe una coordinacin entre el MTA y el UA.
Solo pueden intercambiar mensajes UA del mismo tipo, esto hace que por ejemplo
un IPM-UA no se pueda comunicar con un EDI-UA. Esto es til debido a que IPM y
EDI tiene requerimientos muy diferentes, pero tampoco limita al sistema ya que existe
la posibilidad de implementar una UA que acte tanto como IPM-UA como EDI-UA.
Pgina 167
Cuando se concibi el UA por primera vez, se idearon dos tipos, uno remoto y otro
local. El UA local es el que est implementado en el mismo ordenador que el MTA con
el que se comunica. Un UA remoto est ubicado en un ordenador diferente a donde est
su MTA. En el caso de un UA local el interface UA - MTA se utiliza una
implementacin sencilla mientras que en UA remoto se debe hacer un diseo ms
cuidadoso debido a que las comunicaciones UA - MTA estn sujetas a errores. El
protocolo P3 de X.411 se desarroll para resolver estos problemas.
Cuando se dise el sistema X.400 se pensaba en que un MTA sirviendo un PC,
actuando como un UA remoto, debera establecer conexin con el PC y depositar el
mensaje dirigido a este UA; sin embargo, esta idea nunca lleg a materializarse, ya que
los PC estn conectados de forma discontinua y la mayor parte del tiempo no estn
disponibles para recibir mensajes. Esto hace que se puedan producir una tasa muy alta
de fallos y de desconexiones por exceso de temporizacin. De esta forma los PCs
actuando como UA y comunicndose con un MTA pueden caer en las siguientes dos
categoras:
El PC actuando como un UA est conectado a una LAN que contiene un
servidor actuando como un MTA. En estos casos no es necesario implementar el
protocolo de acceso P3 o MTS entre el UA y el MTA debido a que se
proporciona de base en el protocolo de transferencia de ficheros de la LAN.
El PC se usa como terminal inteligente y se conecta al sistema de correo
proporcionando funcionalidad de UA, de hecho usando un UA local.
El CCITT al ver estos problemas del UA remoto se crearon los MS y el protocolo
P7. Los UA s no pueden comunicarse con otros UA s sin enviar mensajes a travs del
Agente de Trasferencia de Mensajes (MTA).
Vuelta al ndice
11.3.4.
RUA
RUA (Remote User Agent). Es un agente de usuario externo y conecta con el

MTA a travs del almacn de mensajes (MS).
Vuelta al ndice
11.3.5.
AU
AU (Access Unit). Interface para sistemas anteriores a X.400. Se habla de

unidades de acceso cuando se definen las conexiones con otros servicios de gestin de
mensajes (Fax, Telex, Servicio Postal).
El sistema X.400 y recomendaciones posteriores describen un sistema de mensajera
autocontenido y completo. Sin embargo, existen otros sistemas de correo mpliamente
utilizados, de forma que la aceptacin del estndar X.400 depende en gran medida de
cmo se puede comunicar con otros MHS. Esto es esencial debido a:
Los usuarios potenciales de X.400 han podido haber hecho inversiones
importantes en sistemas no X.400 de forma han de amortizar la inversin.
Pgina 168
Al principio, al disponer de una base instalada pequea, es necesario tener la

capacidad para comunicarse con otros tipos de mensajera.
AU define como pueden comunicarse los usuarios X.400 con otros usuarios no
X.400, tal y como el telex, teletexto e incluso servicios de entrega postal. Un AU es un
dispositivo que se comunica con el MTA por un lado y con servicio no X.400 por otro.
Se encarga de convertir los formatos, servir los elementos y los protocolos. Un AU
puede proporcionar servicios bidireccionales de flujo de mensajes no X.400.
En la normativa de 1984 se defina solo un AU para teletex. En 1988 no se define
ningn AU, se pasan a las recomendaciones de la serie F.400, que son descripciones de
servicio nacidas para completar las recomendaciones X.400., el telex, teletex, y entrega
postal,
sin
embargo,
no
se
define
el
servicio
de
FAX.
Debido a esto, que nicamente son recomendaciones tipo F no existen definiciones
tcnicas al respecto.
El interface entre sistemas X.400 y sistemas anteriores a X.400 es uno de los puntos
esenciales a la hora de proceder a la implantacin de un sistema de mensajera X.400.
El suministrador de equipos MHS o el proveedor de servicios MHS puede
incrementar la funcionalidad bsica del UA suministrando una interfaz eficiente y
amigable, en el caso de usuarios humanos, o una API de facto en el caso de un proceso
de aplicacin. Esta funcionalidad adicional estar, en general, relacionada con las
acciones ejecutadas para el envo, recepcin o clasificacin del mensaje, y ser valida
siempre que se respete la semntica de los campos de mensajes normalizados por el
MHS.
11.3.6.
MHE
El Message Handling Environment representa a todo el conjunto de

componentes MHS y usuarios.
Usando la analoga con la oficina postal, el UA ejecutara las acciones
equivalentes a las que se realizan dentro de una compaa que utiliza el servicio postal.
Las operaciones de un MTA son equivalentes a las acciones llevadas a cabo dentro de
una oficina postal: la oficina postal ( MTA ) que gestiona el mensaje, tiene que leer el
sobre (sin abrir el mensaje), analizar la direccin y el tipo de servicio requerido
(urgencia del mismo, peticin de acuse de recibo, etc.) y encaminar el mensaje hacia su
destino dentro del Sistema de Transferencia de Mensajes ( MTS ). La direccin
identifica la siguiente oficina postal a la que debe enviarse el mensaje y, si se trata de la
ltima de ellas, identifica el UA al que debe entregarse. Destacar que la direccin no es
el nico lugar del MHS que contiene este tipo de informacin.
En otras palabras, el MTA transfiere y encamina el mensaje. Los UA s y el
MTA pueden residir en el mismo equipo. Alternativamente, el MTA puede residir en
un servidor dedicado.
El MHS define el protocolo de transferencia entre MTA s y entre un UA y un
MTA. Tambin obliga al MTA a gestionar el protocolo de forma correcta, por ejemplo,
Pgina 169
manteniendo en el sobre la lista de los MTA s que han gestionado el mensaje a lo largo
de su recorrido.
Al conjunto de todos los MTA s se le denomina Sistema de Transferencia de
Mensajes (MTS). El MTS puede entenderse, si lo comparamos con el servicio postal
tradicional, como el servicio postal en su conjunto.
Dado que no es necesario que el emisor y el destinatario final estn conectados
al mismo tiempo al MTS, es necesario un mecanismo capaz de gestionar los mensajes
entrantes que no puedan ser entregados inmediatamente y que, por tanto, tendrn que
ser entregados con posterioridad. El MHS proporciona una facilidad, llamada Almacn
de Mensajes (MS), que gestiona los mensajes. En la actualidad existen dos tipos de MS
: ipm MS y edim MS, sin embargo, en las descripciones siguientes se utilizar el
trmino genrico MS sin calificativo alguno. No debe confundirse el MS con el
concepto buzn ("mail-box"). Mientras que un buzn almacena los mensajes
pertenecientes a un nico usuario, el MS proporciona una capacidad mucho ms general
para el almacenamiento de mensajes pertenecientes a diversos usuarios. Al MS se puede
acceder de formas muy diferentes, por ejemplo, para recuperar un conjunto de mensajes
que tienen las mismas caractersticas.
El MS puede recibir mensajes del MTS, almacenarlos, y ofrecer a los UA s un
servicio de recuperacin de mensajes. Este servicio de recuperacin puede entregar
mensajes almacenados en el MS de acuerdo a criterios expresados por el usuario, por
ejemplo, recuperar todos los mensajes de un tipo concreto.
Un MS no almacena los mensajes que remite el usuario al MHS, ms bien acta
como un repetidor entre el UA y el MTS .
El MHS especifica los aspectos de comunicaciones involucrados en la relacin
entre el MS y el UA, y entre el MS y el MTA.
11.4.
Nombres y direcciones
En los sistemas de comunicaciones un nombre es una designacin nica para un

objeto. En el contexto de un MHS, deben asignarse nombres fundamentalmente a sus
usuarios (en otras palabras, a sus correspondientes UA).
Atributo
Clave Descripcin
Generation Qualifier
Mr. Junior, etc.
Surname
Apellido del usuario
Given Name
Nombre del usuario
Unidad de Organizacin OU
Nombre de la Unidad dentro de la Organizacin (1..4)
Organizacin
Nombre de la organizacin
PRMD
Dominio de gestin de privado
ADMD
Dominio de Gestin de la Administracin
Country
Cdigo de Pas
Pgina 170
Una direccin tambin identifica un objeto, si bien en relacin con un sistema de

coordenadas dado. Una direccin denota el emplazamiento en el que puede encontrarse
el objeto. A partir de estas definiciones, deducimos que una direccin es tambin un
nombre, pero no a la inversa. Asimismo, un objeto puede tener varios nombres, pero
nicamente una direccin (respecto al mismo sistema de coordenadas).
Para el concepto de una direccin, X.400 utiliza de forma confusa el trmino
nombre (O/R). Los nombres O/R son conjuntos de atributos, es decir, pares de la forma
(tipo de atributo, valor de atributo), donde los tipos de atributo que deben utilizarse no
se especifican de forma concluyente en las recomendaciones. Los tipos de atributos se
seleccionan de modo que un nombre O/R pueda utilizarse para determinar el
emplazamiento
en
el
que
un
UA
se
conecta
al
MTS.
De esta forma, los nombres O/R hacen referencia a la arquitectura del MHS y son en
realidad direcciones. Contiene al menos, el nombre del ADMD y, generalmente,
contiene tambin un nombre de PRMD y el nombre del UA dentro del PRMD. Los
nombres O/R definidos de este modo no son fciles de utilizar, ya que contienen
elementos de la arquitectura MHS y, por consiguiente, son difciles de recordar, y deben
modificarse cuando cambia la estructura de la empresa (o cuando cambia el
emplazamiento del usuario). Para documentar la funcin de los nombres O/R, con
arreglo a la norma X.400 (88) utilizaremos la terminologa direcciones O/R.
X.400
(84)
especifica
varias
formas
de
direcciones
O/R:
Una primera forma de direccin, denominada forma 1, variante 1, define direcciones de
UA que estn conectadas a un sistema X.400. Ello representa el caso normal.
11.5.
Dominios de Gestin
La gestin de un MHS mundial es una tarea que nicamente puede realizarse con
xito si el sistema de gran tamao se descompone en partes menores. Con esta finalidad
X.400 proporciona los denominados dominios de gestin (MD). Se trata de dominios
dentro de los cuales una Autoridad de gestin es responsable de la operacin del
sistema. Se dispone de los siguientes dominios:
Dominios de Gestin de Administracin (ADMD). Estos dominios estn
reservados para la administracin adjunta al CCITT (por ejemplo,
organizaciones pblicas como los Organismos de Correos y Comunicaciones
PTT nacionales).
Dominios de Gestin Privadas (PRMD). Una organizacin, como una
Universidad o una gran empresa, puede, por ejemplo, crear su propio PRMD.
Pgina 171
Segn las recomendaciones de la norma X.400, los PRMD estn subordinados a

los ADMD, en el sentido de que los PRMD no pueden asumir funciones de
conmutacin entre ADMD. Diversas administraciones postales europeas operan o
tienen previsto operar ADMD a las que pueden conectarse PRMD y que, parcialmente,
ofrecen asimismo servicios de usuario final (buzones de correo electrnico) y pasarelas
a los servicios telemticos actuales (tlex, teletexto, videotexto).
Las recomendaciones proporcionan ciertos consejos, tanto explcitos como
implcitos, sobre las estructuras y las asociaciones que se permiten o que deben evitarse.
Por ejemplo, una interpretacin estricta del texto de las recomendaciones puede
llevarnos a concluir que no se permite un PRMD que abarque una o ms fronteras
nacionales. No obstante, un caso de tales caractersticas es muy probable que se d, ya
que corresponde a una organizacin multinacional que opere su propio MHS. Se hace
notar expresamente que los mensajes que se intercambian entre diferentes ADMD
nunca deben conmutarse a travs de un PRMD.
En general, la forma de operar un PRMD y su integracin depende de la
legislacin en materia de telecomunicaciones de cada pas y, por consiguiente, no est
gobernada por las recomendaciones de la norma X.400.
Pgina 172
No es necesario (si bien, en ocasiones, es razonable) intercambiar mensajes entre

PRMD que pertenecen a diferentes empresas a travs de un ADMD. Un intercambio de
mensajes a travs de ADMD es, sin duda, ventajoso si el volumen de trfico es reducido
y si no est justificado el coste de mantener una conexin directa. Por consiguiente, los
ADMD pueden servir como mediadores fiables entre PRMD y permitir la conectividad
del rea amplia inmediata, mediante una nica conexin a un MHS internacional.
Cuando se conecta un PRMD a un ADMD, es de esperar que se entre en el
mbito de tcnicas y de operacin debido a que, segn las recomendaciones de la norma
X.400, un ADMD es responsable de los PRMD conectados al mismo, debemos
garantizar que, por ejemplo, un PRMD genera formatos de mensaje correctos y que
entrega los mensajes que recibe con la fiabilidad requerida. Ello implica un
procedimiento de Autorizacin oficial para los PRMD que deben conectarse al MHS
pblico. El fundamento tcnico de ello ser producido por definicin de secuencias de
ensayo que un sistema debe ejecutar con xito y la definicin de los sistemas de ensayo
correspondientes.
Un grupo de MTA y UA s puede ser propiedad de una organizacin, en cuyo
caso se les conoce con el nombre de Dominio de Gestin. Un Dominio de Gestin que
proporciona servicios de transmisin y encaminamiento a otros dominios de gestin
recibe el nombre de Dominio de Administracin Pblica (ADMD). Un dominio de
gestin que no proporciona tales facilidades recibe el nombre de Dominio de
Administracin Privada (PRMD). Dentro de un pas, un ADMD es normalmente
operado por una organizacin PTT, pero existen ejemplos de ADMD operados por otras
organizaciones diferentes. Sin embargo, en el caso de una contratacin para una
organizacin del sector pblico, es poco probable que el ADMD sea operado por una
organizacin diferente a un PTT.
Un PRMD est normalmente asociado con un nico ADMD. Para que el
funcionamiento de un MHS global sea satisfactorio, todos los ADMDS deben
conectarse de tal manera que permitan al mensaje ser encaminado entre cualquier par de
ADMDS. Esta conectividad ha sido alcanzada en Europa, pero todava no se ha
alcanzado a nivel mundial.
Un PRMD que no est asociado con ningn ADMD forma parte de un sistema
cerrado cuyos usuarios finales pueden nicamente enviarse mensajes entre s. Sin
embargo, un PRMD puede conectarse a otro PRMD, especialmente en aquellos lugares
donde exista un volumen de trfico elevado. En este caso, algunas de las funciones de
gestin del MHS, normalmente ejecutadas por un ADMD, son necesarias en el PRMD,
tales como el mantenimiento de la informacin de encaminamiento.
11.6.
ISP
Existen dos versiones de las normas MHS , MHS 84 y MHS 88, publicadas,
respectivamente, en 1984 y 1988. El MHS 88, desarrollado sobre la base del MHS 84,
ampla sustancialmente la funcionalidad del MHS 84. Las normas MHS han estado
sujetas a un ejercicio de perfiles que ha dado por resultado un nmero determinado de
ISPs. Los perfiles estn clasificados como perfiles de aplicacin (perfiles-A) y son
identificados con el prefijo AMH.
Pgina 173
Algunos usuarios pueden definir/especificar requisitos relativos a la seguridad de

sus sistemas de tratamiento de mensajes. Las normas proporcionan facilidades de
seguridad clasificadas como S0, S1 y S2. As, S0 ofrece Autentificacin del origen del
mensaje, prueba de entrega e integridad del contenido. Opcionalmente, S0 ofrece
confidencialidad del contenido, integridad de la secuencia de mensajes, no-repudio del
origen, no-repudio de la entrega y etiquetado de seguridad.
Las normas de MHS han desarrollado en una serie de documentos llamados
perfiles (International Specification Profile ISP) que han dado lugar a un nmero
determinado de ISP.
Existen tres conjuntos de ISPs en desarrollo, cada uno de los cuales se encuentra
en diferentes etapas de ratificacin. La serie AMH 1x est siendo votada para pasar a
DISPs. La serie AMH 2x se encuentra en revisin para pasar a pDISP.
Por su parte, la serie AMH 3x se encuentra cerca de ser consensuada entre los
diferentes comits regionales y, prximamente, ser ratificada para poder entrar en el
proceso de revisin como pDISP. Los ISPs correspondientes al MHS sern totalmente
ratificados y pasarn al CEN para su transposicin a Normas Europeas (ENs).
11.7.
Protocolos
Cada uno de los componentes especificados utiliza un protocolo especfico para

sus intercomunicaciones. Estos protocolos son los siguientes:
P1. Conocido como protocolo de transferencia entre MTA s, describe el modo
en que se interconectan dos MTA s.
P2. Define la estructura de un mensaje.Tenemos que distinguir entre el sobre y
el contenido. El mensaje viaja dentro del sobre P1 y el contenido P2 se estructura en:
Cabecera: Contiene la informacin suplementaria que es similar a la que se incluye en
los servicios tradicionales de correo, las direcciones del remitente y los receptores, el
tema
y
todos
los
servicios
ofrecidos
por
P2.
Cuerpo: Ese el cuerpo del mensaje puede ser una serie de secciones (partes del cuerpo)
con diferentes formatos. Esto permite la integracin de una amplia gama de servicios de
tratamiento de mensajes. Los formatos reconocidos son: Texto ASCII, telex, Teletexto,
Videotex, Fax, otros mensajes X.400, Binario indefinido, fichero de datos, voz,
P3 Regula la comunicacin entre un Agente de usuario (UA) y un Agente de
Transferencia de Mensajes (MTA) y con el Almacn de Mensajes (MS).
P7 Regula la comunicacin entre un Agente de Usuario (UA) y un Almacn de
Mensajes (MS)
11.7.1.
P1 Protocolo (X.419 [1988]/X.410 [1988])
Pgina 174
El protocolo P1 es el formato de intercambio de mensajes del MTA . El MTA lo

utiliza para proporcionar las funciones de transferencia de mensajes en EL sistema de
enrutamiento del X.400. el MTA utiliza el sobre de P1 para controlar el intercambio de
mensajes. Se utiliza para enrutar y
monitorizar el camino seguido por
el mensaje, tener constancia del
contenido del mensaje, indicar
cuando se debe entregar el
mensaje o cuando deshacerse de
l, e indicar todo lo concerniente a
como fue entregado o como
convertirlo de un formato a otro.
El
MTA
intercambia
mensajes P1 utilizando los
elementos
de
servicio
de
aplicacin llamados Message
Tranfer Service Element ( MTS
E). El MTS E proporciona esta
servicio usando la Reliable
Transfer Service Element (RTSE)
para enviar los datos a travs de
los enlace entre MTA y el Access
Controls
Service
Elements
(ACSE) para establecer y romper
estos enlaces.
Los mensajes P1 tienen dos
partes: El Sobre de Transferencia
de mensajes y el contenido o
mensaje P2.
El Sobre P1
El P1 contiene campos de
enrutamiento y control para
intercambio de mensajes en los
MHS X.400. Estos campos son:
Identificador del mensaje MTSI
Tipo de contenido
Identificador del contenido
Tipo de entrega diferido
Direccin del receptor X.400. Esta es la direccin X.400 que utiliza el MTA
para encontrar la direccin de red en el directorio X.500. Puede ser que haya uno
o varios destinatarios.
Indicadores de mensajes (si existen o no varios destinatarios que deban pasarse a
todas las UA en tiempo de entrega, si se permiten receptores alternativos, si en
caso de fallo el mensaje indicador de error debe contener el mensaje enviado.
Pgina 175
Informacin Bilateral de Dominio. Informacin que indica qu codificacin se

ha empleado.
Corelator de contenido. Si no se puede entregar el mensaje se devuelve una parte
al remitente. Definido en la recomendacin de 1988.
Hora lmite de entrega, si se alcanza esta hora el mensaje se descarta informndo
al remitente.
Permiso de conversin con prdida de contenido. Si no se dispone de este
servicio puede darse el caso que cuando se comunican aplicaciones con todos los
servicios implementados y otros que los tienen en parte, se puedan perder
algunos elementos del mensaje.
Direccin de retorno del remitente.
Campo de prioridad. Cuanta mas prioridad se entregar ms rpida.
Parmetros de seguridad (Un certificado asegurando que el remitente es quien
dice quien es, algoritmo de confidencialidad y comprobacin del remitente del
mensaje).
Prohibicin de receptores alternativos.
Por receptor:
o Nombre OR.
o Indicacin de entrega no solicitada (no supresin de entrega positiva, no
devolucin de entrega negativa).
o Ejecucin de conversin
o Receptor indicado originalmente
o Direccin X.400 del remitente para notificacin segn entrega.
o Campo de monitorizacin de camino seguido.
o Mtodo de entrega (se puede indicar un mtodo diferente de entrega para
cada uno de los destinatario.
o Receptor alternativo
o Seguridad (token del mensaje, prueba de entrega, integridad de contenido
o Parmetros de entrega fsica
o Historia de redireccin
11.7.2.
P2/P22 Protocolo de mensaje interpersonal
El mensaje P2 o Mensaje Interpersonal es el equivalente a la carta cuando se usa

el correo normal. Tiene una cabecera al principio con la direccin e informacin que no
se usa en el enrutamiento, pero que es parte en si mismo del mensaje. Despus viene el
cuerpo del mensaje, que son realmente los datos a enviar. La revisin del X.400 (1988)
se le renombre como estndar P22.
Cabecera
Es el equivalente a la direccin que se colocara al principio de la carta, de forma
que realmente no es necesario excepto el identificador del mensaje (esto es debido a que
se utiliza como un identificador entre UA).
Una parte opcional proporcionando la descripcin del que origina el mensaje (la
direccin X.400, sobrenombre, nombre, nmero de telfono)
Un indicador opcional describiendo el destinatario.
Un identificador del mensaje (no opcional).
Otros elementos y referencias cruzadas a otros mensajes
Pgina 176
Cuerpo
Cada cuerpo est compuesto de una o ms partes, llamadas tambin cuerpos,
cada una de ellas puede tener informacin en formatos diferentes. Las partes del cuerpo
se etiquetan para mostrar qu tipos de datos lleva. As el sobre P1 debe tener alguna
indicacin del tipo del mensaje de cmo un MTA debe saber qu tipo de informacin
puede manipular y coger la UA en cuestin.
En algunos casos, como con informacin binaria o donde puede existir
ambigedad, existe la convencin de poner una cadena descriptora ia5 antes del
mensaje. Esto significa que un dato binario llevando una hoja de calculo no necesita
estar mezclado con un dato binario que no sea una hoja de calculo.
Tipos de datos incluidos
Texto ia5 ( El ms utilizado, la mayor parte de las veces caracteres ASCII)
Telex
Voz
G3FAX
G4 Clase 1
Teletex
Videotex
Datos encriptados
Datos definidos de forma bilateral. Normalmente usados por ficheros binarios,
descirbiendolos con una cadena ia5.
11.7.3.
P3 ASEs y protocolo P3
El Message Submission Service Element (MSSE) permite al elemento de

usuario enviar mensajes a una entidad con la que est conectada, un MTA o un MS .
Esto se realiza bajo el protocolo P3.
El Message Delivery Service Agent (MDSE) permite al MTA entregar el
mensaje al UA. Esto tambin se realiza bajo el protocolo P3.
El Message Administration Service Element (MASE) ayuda al UA de las
labores administrativas del mensaje.
Pgina 177
El protocolo P3 se utiliza en la comunicacin entre el UA y el MTA . No est

demasiado extendido dado que el UA no est siempre disponible.
P3 sirve para interconectar los UA y los MTA directamente, su uso no es muy
corriente debido a que los UA no estn siempre disponibles, y representa el elemento
ms bajo de la pila para comunicarse con el MTA usando los elementos de Aplicacin
de Servicio. Con el protocolo P3 se obliga al UA a entregar mensajes sin examinarlos
de forma no selectiva. Esto quiere decir que mensajes no deseados tambin se procesan
siendo una perdida de tiempo.
El Elemento de Servicio de Envo del mensaje (MSSE) en P3 proporciona:
Remisin de mensajes, pueden ser diferidos o de diferentes prioridades.
Se realiza con el comando: Submit Some Arguments indicando:
o Nombre O/R de remitente
o Nombre O/R del destinatario
o Contenido del mensaje
o Tipo del contenido
o Tipo de informacin codificada
o Prioridad
o Tiempo de retraso de entrega
o Solicitud de conversiones
o Devuelve el identificador del UA
Prueba de reenvo, mira si el mensaje puede progresar:
o Nombre O/R de remitente
o Nombre O/R del destinatario
o Contenido del mensaje
o Tipo del contenido
o Tipo de informacin codificada
o Solicitud de conversiones
Control de reenvo de entrega diferida
o Entrega o reenvo permitido
o Mensajes ms grande que una cierta longitud que no se transfieran
o Mensajes con menor prioridad de una dada que no se transfiera
Pgina 178
o
o
Que solamente se transfiera cierta informacin codificada.

Solo pruebas y notificaciones
Elemento de Servicio de entrega de Mensaje

Entrega de Mensaje (Entrega el identificador del mensaje dado)
Entrega de prueba
Control de entrega (notifica una entrega no exitosa)
Elemento de Servicio de Administracin de Mensajes
Este elemento proporciona:
o Registro (registra un UA en un MTA)
o Cambio de credenciales. Cambia como ve el MTA al UA.
11.7.4.
Protocolo P7 ASEs y P7
El protocolo P7 lo utilizan los siguientes elementos de servicio:

El Message Submission Service Element (MSSE). Elemento de Servicio de
Envo de Mensajes permite al UA enviar mensajes a una entidad conectada con
l (un MTA o un MS); para ello se utiliza el puerto de envo indirecto.
El Message Retrieval Service Agent (MRSA). Agente de Servicio de
Recuperacin de Mensajes permite al UA obtener o buscar un mensaje en el
MS; para ello se utiliza el puerto de recuperacin.
El Message Administraction Service Element (MASE). Elemento de Servicio
de Administracin de Mensajes, ayuda al UA en las labores administrativa, para
ello utiliza el puerto de administracin
El protocolo P7 es el que une directamente el UA con el MS . Con este protocolo el
UA puede examinar y recibir mensajes de una forma selectiva. No hace falta que el UA
est siempre disponible y el MS puede entregar o eliminar mensajes de acuerdo con el
criterio establecido con el UA. Esto significa que se pueden encontrar mensajes no
deseados y borrarlos posteriormente o recuperar el mensaje que interese sin prdida de
tiempo.
Este elemento de servicio proporciona envo de mensaje con los parmetros:
Nombre O/R de remitente
Nombre O/R del destinatario
Contenido del mensaje
Tipo del contenido
Tipo de informacin codificada
Prioridad
Tiempo de retraso de entrega
Solicitud de conversiones
Envo de prueba. La prueba es un mensaje abreviado y utiliza los siguientes
parmetros que devuelve el identificador del UA.
Nombre O/R de remitente
Nombre O/R del destinatario
Contenido del mensaje
Pgina 179
Tipo del contenido

Tipo de informacin codificada
Solicitud de conversiones
Control de reenvo de entrega diferida

Entrega o reenvo permitido
Mensajes ms grande que una cierta longitud que no se transfieran
Mensajes con menor prioridad de una dada que no se transfiera
Que solamente se transfiera cierta informacin codificada.
Solo pruebas y notificaciones
Elemento de Servicio de Recuperacin de documentos
Resumen. Proporciona un resumen segn los criterios impuestos. Cuenta las
entradas segn lo preestablecido; por defecto son los mensajes almacenados que
establece el MS.
Lista de Registro de cualquier concepto: prioridad, Nombre O/R, etc.
Bsqueda, busca los atributos seleccionados en la base de datos de informacin.
Borrar. Borra la informacin seleccionada de la base de datos. No se puede
borrar nada si tiene el atributo de NUEVO. Se puede borrar segn filtros
establecidos o una lista de nmeros, etc.
El MS puede registrar:
Acciones automticas (acciones que realizar el MS de forma Automtica)
Tipos de atributos por defecto
Para listas y avisos: Etiquetas de seguridad nuevas, Credenciales nuevas.
Pgina 180
11.8.
Elementos
Los servicios de mensajera interpersonal ponen a disposicin del usuario una

serie de herramientas para poder intercambiar todo tipo de informacin con los
interlocutores conectados al servicio.
Generalmente, los sistemas de oficina actuales ofrecen las siguientes funciones:
La preparacin de mensajes y la preparacin visual se realiza en una estacin de
trabajo.
El envo del mensaje a un buzn y su archivo se realiza en un servidor dedicado.
La transferencia del mensaje y el encaminamiento a travs de diferentes
servidores y estaciones de trabajo se realiza a travs de una aplicacin que puede
ejecutarse en un servidor dedicado, o integrarse en la estacin de trabajo, o bien
en el servidor de buzn de mensajes.
Estos componentes diversos pueden interactuar a travs de redes de comunicaciones
privadas y pblicas, con el fin de enviar, archivar y recuperar mensajes.
Las funciones de administracin pueden realizarse mediante un centro de
administracin sobre un servidor dedicado, o bien incorporarse a los anteriores. Cada
una de ellas est sometida a funciones de seguridad.
11.8.1.
El centro servidor
El centro servidor de correo nos ofrece la interconexin a la red mundial de

X.400,
proporcionando
el
servicio
de
mensajera
interpersonal.
La funcin principal del centro servidor es la de la transferencia de mensajes (MTA)
pero puede contener otros elementos del servicio para proporcionar capacidades de
almacenamiento de mensajes y unidades de acceso para conexin con otras redes (fax,
telex, Internet, correo propietario). Se puede manejar la idea de un nico centro servidor
pblico donde se almacenan los buzones de todos los usuarios o se puede contemplar la
posibilidad de varios centros servidores privados (PRMD) conectados a uno o varios
centros servidores pblicos.
La posibilidad de adoptar un modelo de centro u otro viene determinada por las
necesidades de organizacin, costes, etc., y por el tipo de servicio que se desee ofrecer
al usuario.
Las principales funciones que desempea el centro servidor de mensajera
electrnica son las siguientes:
11.8.2.
Productos y servicios
Una organizacin que desee establecer un sistema de mensajera cuenta con diversas
posibilidades. Puede comprar un producto o suscribirse a un servicio pblico, o bien
utilizar ambas opciones. En el mercado estn disponibles diferentes tipos de productos:
Productos de mensajera integrados en paquetes de automatizacin de oficinas.
Productos de mensajera independientes.
Pgina 181
Productos de pasarela, que permiten la interoperacin entre productos de

mensajera heterogneos.
Productos de mensajera portables.
Productos dedicados a una de las funciones especficas de mensajera
enumeradas anteriormente.
La estrategia del usuario del producto puede ser adaptada a su entorno especfico,
con el fin de conseguir que se adecue a sus propios requisitos. Ello puede llevar al
desarrollo de software especfico, que se integra en el producto. Por consiguiente,
algunos productos ofrecen interfaces de programacin de aplicaciones.
Un servicio puede ofrecer a una organizacin diferentes tipos de servicios, dichos
servicios pueden cubrir los siguientes aspectos:
Mantenimientos de buzones
Transferencia y encaminamiento de mensajes entre sistemas de mensajera de
titularidad privada.
Suministro de pasarelas entre servicios telemticos.
11.8.3.
Gestin de comunicaciones
Como se ha indicando anteriormente el servicio de mensajera interpersonal se

extiende sobre una gran red de dominios comunicados todos ellos entre s y con los
usuarios. Esta estructura real, con muchas entidades independientes todas ellas
interconectadas, podemos verla como un nico centro virtual donde todo estara
concentrado. Para el usuario, toda esta estructura es transparente, siendo el servicio y
sus modos de acceso lo nico que le atae directamente.
Las redes de acceso ms usuales son las siguientes:
Red
telefnica
bsica
(RTB)
Este acceso permite enviar mensajes mediante una lnea telefnica convencional.
Este tipo de acceso proporciona una gran universalizacin del servicio pues
permite el acceso desde cualquier ubicacin geogrfica y con muy pocos
recursos tcnicos.
IBERPAC
Este acceso ofrece mayores velocidades de transmisin y est especialmente
indicado para usuarios con grandes volmenes de informacin y con una
infraestructura tcnica importante.
RDSI
Acceso de altas prestaciones para transferencia masiva de mensajes.
RED
de
rea
local
El acceso mediante red de rea local est indicado para aquellos usuarios que
tengan un dominio privado conectado a la red local.
Lneas
de
accesos
especiales
Indicada para los usuarios que por manejar grandes cantidades de mensajes o por
requerimientos del servicio puede conectarse al centro servidor mediante lneas
dedicadas para optimizar al mximo los recursos.
Pgina 182
11.8.4.
Puesto de usuario
La instalacin del puesto de usuario es variable en funcin de las capacidades

que se necesiten. El puesto de usuario mnimo est formado por un ordenador personal,
el software de gestin de correo, un mdem y una lnea telefnica normal para acceder a
un buzn de un dominio pblico o privado.
En entornos en los que implanta un servicio de correo electrnico como correo
corporativo se necesita adems de la infraestructura bsica para acceder al servicio, un
dominio privado (PRMD) que gestione el correo internamente. Dicho PRMD estara
conectado con uno o varios dominios pblicos (ADMD) para cursar el correo con el
exterior.
El software de Agente de Usuario Remoto (RUA) existe para varios sistemas
operativos y su misin es la siguiente:
Gestin de mensajes. Control de los mensajes enviados, reenvos, informacin
de acuses de recibo, etc.
Almacenamiento de mensajes. El usuario va generando mensajes y se van
acumulando para transmitirlos todos de una vez cuando se conecta al servidor de
correo.
Comunicaciones. Gestiona las comunicaciones con el centro servidor de correo
electrnico para enviar todos los mensajes acumulados en el puesto de usuario y
para recoger todos los mensajes existentes en el buzn.
Interface con la aplicacin externa. Parte de la gestin de corro que es comn a
la aplicacin del usuario o que comparte datos con ella. Este mdulo sera el
encargado de extraer e inyectar datos a la aplicacin usuario.
Generacin de mensajes. Mdulo encargado de general mensajes que pueden
estar formados por texto o bien por ficheros en diversos formatos (texto,
binarios, grficos, etc.)
El proceso de generacin de mensajes sera el siguiente:
El usuario genera manualmente un mensaje o bien lo importa desde su sistema
informtico.
El software de gestin del correo proporciona al mensaje las cabeceras
necesarias para su transmisin y lo almacena.
Cuando el usuario decide transmitir todos los mensajes almacenados el software
de gestin de correo activa las conexiones y enva todos los mensajes al centro
servidor de correo y, en esta misma conexin, recoge todos los mensajes
recibidos en el buzn del usuario.
El centro servidor encamina los mensajes y los lleva hasta los buzones de
destino.
Si alguno de los mensajes llevaba Notificacin de Entrega, el centro servidor
devuelve este acuse de recibo cuando los mensajes son depositados en el buzn
destinatario. Este acuse se recibe como un mensaje ms que ser recogido del
buzn del usuario emisor cuando ste se conecte al centro servidor.
Pgina 183
11.8.5.
Soporte a usuarios
El soporte al usuario debe ser permanente desde que ste decide instalar el
software necesario para acceder al centro servidor de correo electrnico.
El usuario necesita soporte para disear la interface entre el software de gestin del
correo electrnico y su propia aplicacin. Este soporte puede darse proporcionando al
usuario las herramientas necesarias para realizar dicho interface o incluso desarrollando
una interface con sus aplicaciones a medida. El soporte en el proceso de explotacin del
servicio permite al usuario resolver las incidencias que se puedan detectar.
11.8.6.
Seguridad
Siempre que se transmite informacin, los participantes en la comunicacin

esperan que la informacin transmitida llegue sin sufrir alteraciones. Las funciones de
seguridad son prerrequisitos importantes para un sistema de manipulacin de mensajes
previsto para transmitir contratos, documentos e incluso, transferencias bancarias
electrnicas. Tales funciones de seguridad incorporan la integridad garantizada de los
mensajes transmitidos, verificacin del originador, verificacin del envo y recepcin, y
asimismo, la confidencialidad de los mensajes transmitidos y la proteccin frente a
prdida o duplicacin de mensajes. Incluso la transmisin de notas breves o de saludos
requiere cierto nivel mnimo de seguridad. Una nota breve que durante la transmisin es
desviada por un hacker a otro destino puede generar confusin. En resumen, un sistema
de manipulacin de mensajes totalmente inseguro nicamente tiene una utilidad
limitada.
Conseguir seguridad supone defender un sistema frente amenazas. A
continuacin se describen posibles amenazas contra un sistema electrnico de
manipulacin de mensajes, los elementos que proporciona la norma X.400 (88) y por
ltimo, algunos ejemplos para describir la utilizacin de elementos de seguridad contra
amenazas potenciales.
11.8.6.1.
Posibles amenazas contra un MHS X.400
Con el fin de hacer un sistema seguro es necesario, en primer lugar, analizar las
posibles amenazas. Existen numerosas razones por las que las personas pueden intentar
atacar a un sistema electrnico de gestin de mensajes y utilizarlo indebidamente en su
propio provecho. Las razones van desde la simple curiosidad hasta la produccin de
daos en comunicaciones internas de empresas o la modificacin de instrucciones de
transmisin electrnica, pasando por el espionaje. Incluso los usuarios habituales del
sistema pueden incurrir en comportamientos ilegtimos, negando haber enviado o
recibido un mensaje, con el fin de evitar consecuencias jurdicas o sociales de dicho
mensaje.
Los ataques pueden estar dirigidos contra cualesquier componente del sistema de
manipulacin de mensajes, tanto contra los sistemas informticos y los programas de
aplicacin que se ejecutan en los mismo, como contra las conexiones entre los
ordenadores. El hecho de que el atacante cuente con acceso Autorizado al sistema y a
las lneas de conexin (por ejemplo, como administrador), o si ha obtenido el acceso
ilegalmente utilizando un punto dbil del sistema en cuestin (por ejemplo, un hacker)
Pgina 184
es irrelevante. La figura siguiente muestra posibles puntos en los que puede ser atacado
un sistema de mensajera.
Los ataques contra una conexin incluyen la lectura o modificacin de paquetes

de datos en el enlace y la interrupcin del mismo. Los ataques contra un sistema
generalmente suponen la lectura o la modificacin de mensajes almacenados o de
informacin de gestin. Un posible atraque que est entre esas dos categoras es la
suplantacin. En este caso, un atacante puede, por ejemplo intentar establecer una
conexin desde su sistema al MTA de la empresa Alfa, anuncindose en dicha conexin
como MTA Meta, con el fin de sustraer informacin o introducir mensajes. Incluso los
usuarios finales pueden intentar invitar o recibir mensajes bajo nombres falsos.
Una vez que un atacante ha penetrado en un sistema o en una conexin, existen
diferentes mtodos de ataque a su disposicin. Por ejemplo, puede:
Restringir o detener totalmente el funcionamiento causando daos en los
sistemas y en las conexiones individuales.
Enviar mensajes ilcitamente.
Leer mensajes.
Modifcar o eliminar mensajes, o bien introducir sus propios mensajes. Las
modificaciones de un mensaje no se limitan al contenido, sino que pueden
afectar a la informacin de control.
Borrar, Duplicar o Modifcar la secuencia de los mensajes.
Enviar mensajes marcados para envo diferido, antes de tiempo (preplay).
En el pasado, numerosos ejemplos han mostrado que dichas amenazas existen y que
han de tomarse en consideracin.
11.8.6.2.
Elementos de seguridad en el X.400 (88)
X.400 proporciona numerosos mecanismos (elementos de servicio de seguridad)

para la defensa contra las diferentes amenazas mencionadas. Fundamentalmente, existen
dos clases de elementos de seguridad: aquellos que protegen las conexiones entre
Pgina 185
sistemas y los que protegen los mensajes individuales. La proteccin del sistema
propiamente dicho es puramente una cuestin de los operadores del sistema, y en dicha
rea no podemos entrar en mayor detalle.
Las normas utilizan diversos trminos para las funciones de seguridad, con arreglo
al nivel de abstraccin con el que analice el sistema.
Elementos del Servicio de Seguridad son los servicios proporcionados por el
MHS relacionados con la seguridad.
Servicios de Seguridad es un trmino que procede la norma "Modelo de
referencia OSI: Estructura de seguridad (OSI Reference Model: Security
Framework)" (ISO 7498-2). Entre otras cosas, dicha norma especfica un
conjunto de servicios de seguridad mediante los cuales puede hacerse seguro un
sistema de comunicacin estructurado con arreglo a la norma OSI. Debido a que
X.400 cumple dicha estructura, los servicios de seguridad citados deben ser
identificables.
Elementos de Seguridad son las funciones de seguridad proporcionadas por las
diversas operaciones. Los elementos de seguridad se materializan utilizando los
argumentos de seguridad correspondiente.
Argumentos de Seguridad son los campos especficos de seguridad
suministrados en los argumentos y resultados de las diversas operaciones.
Funcin de Seguridad hace referencia a cualquier funcin especfica
relacionada con la seguridad, sin referencia a ninguno de los niveles de
abstraccin anteriores.
El usuario final est interesado fundamentalmente en los elementos de seguridad de
los servicios que ofrece X.400 (88) al nivel de mensaje individual.
11.8.6.3.
Elementos de seguridad para proteger las conexiones
Autentificacin de entidades de igual nivel

Finalidad. Que los participantes en una conexin puedan declarar la
autenticidad de los participantes con los que se comunican.
Realizacin. Cuando se abre la conexin, y a intervalos regulares despus de
dicha apertura, ambos comunicantes intercambian elementos de datos especiales
que permiten a ambos suscriptores verificar la Autenticidad de su comunicante.
Autentificacin fuerte. Este elemento incorpora un procedimiento bidireccional
X.509 que utiliza un procedimiento de codificado asimtrico. En este caso, se
intercambian y verifican elementos de datos con firma electrnica (marcas,
tokens) que contienen la direccin del comunicante, un sello de tiempo y un
nmero aleatorio.
Contexto de seguridad
Finalidad. En sistemas informticos en los que los datos estn estructuralmente
separados con arreglo a su clasificacin o sensibilidad, puedan disponer de un
contexto seguro como si estuvieran los datos en una sola mquina.
Pgina 186
Realizacin. Para cada posible conexin entre sistemas, se especifica la

sensibilidad de los mensajes que deben transmitirse a travs de dicha conexin.
Con el fin de evitar la posible confusin de mensajes de diferentes sensibilidades
(y, por consiguiente, la clasificacin errnea de un mensaje sensible en una
categora equivocada), en caso de problemas, todos los mensajes transportados
en cada conexin abierta tienen la misma sensibilidad. La transmisin de datos
secretos de forma abierta a travs de una lnea insegura puede evitarse
autorizando nicamente conexiones no clasificadas para dicha lnea. Siempre
que se abre una conexin, el que la ha iniciado especifica el nivel de
clasificacin de los mensajes que se van a trasmitir.
Elementos de seguridad para proteger mensajes individuales
Los campos de datos de mensajes necesarios para los elementos de seguridad se
suministran mediante el mecanismo EXTENSIN. Utilizando el mecanismo de
criticidad asociado, es posible garantizar que se rechazan los mensajes
procedentes de un sistema que no soportan el elemento de seguridad en cuestin,
si bien es posible garantizar, por otra parte, que los MTA intermediarios vuelvan
a transportar el mensaje, independientemente de si proporcionan o no ellos
mismas los elementos de seguridad. Los argumentos de seguridad por mensaje
son los siguientes:
o
o
o
o
o
o
o
o
o
Certificado del originador

Identificador del algoritmo de confidencialidad del contenido
Verificacin de autentificacin de origen del mensaje
Etiqueta de seguridad del mensaje
Solicitud de prueba de envo
Receptor por mensaje
Token del mensaje
Verificacin de integridad del contenido
Solicitud de prueba de entrega
La mayor parte de estos campos cuenta con una estructura sencilla. nicamente
el campo token de mensaje, requiere una explicacin introductoria, debido a que
puede proporcionar numerosos elementos de seguridad y una estructura
igualmente compleja. Fundamentalmente, contiene la siguiente informacin (los
nombres corresponden a la definicin ASN.1)
o
o
o
Nombre del destinatario

Hora
Campo de datos token no encriptado, que contiene:
Identificador del algoritmo de confidencialidad del contenido
Solicitud de prueba de entrega
Nmero de secuencia de mensaje
Campo de datos token encriptado, que contiene:
Clave de confidencialidad del contenido
Pgina 187
Clave de integridad del contenido

Nmero de secuencia de mensaje
La informacin contenida en el token est protegida contra manipulacin

utilizando la firma del remitente. Los dos campos de datos token pueden
contener nicamente una seleccin de los campos dados, y es posible omitir
campos si estn vacos. Algunos elementos se producen tanto en los campos de
datos token encriptados cono no encriptados. En dicho caso, es posible elegir
entre los dos campos de datos token segn requiera confidencialidad o no para el
elemento.
La definicin exacta del token ASN.1 es muy complicada y utiliza, asimismo, un
tipo de mecanismo de extensin. El nico tipo de token definido en la actualidad
es el token asimtrico (basado en los sistemas de codificacin asimtricos). No
obstante, el contenido de los dos campos de grupo (tipo TokenDAta en ASN.1)
vara con arreglo a la utilizacin del token. Adems del token de mensaje que se
acaba de describir, exista un token de unin para la autentificacin de entidad de
igual nivel, tal y como se ha descrito anteriormente.
Autentificacin del origen del mensaje
Finalidad. Que el destinatario de un mensaje pueda verificar el origen del
mismo.
Realizacin. Esta funcin se realiza mediante la firma electrnica del mensaje.
A nivel de elementos de seguridad, distinguimos entre dos grupos de elementos
que pueden proporcionar esta funcionalidad: autentificacin en origen y
verificacin de integridad.
Los elementos de ambos grupos son muy similares entre s y pueden utilizarse
para garantizar la integridad de un mensaje, as como el origen del mismo. No
obstante, ambos grupos de elementos de seguridad se diferencian
considerablemente entre s en el momento en que los mensajes se ecnriptan para
garantizar la confidencialidad. Los servicios del grupo de autentificacin de
origen operan en el contenido del mensaje codificado y permiten a todos los
componentes que participan en la transmisin del mensaje (incluyendo los
MTA) determinar el origen del mismo. Por otra parte los elementos de
seguridad del grupo de verificacin de integridad nicamente operan en texto no
cifrado y, por consiguiente, nicamente pueden utilizarse de extremo a extremo
(nicamente cuando el mensaje se produce en texto no cifrado). Ambos grupos
difieren asimismo a nivel semntico: la autentificacin de origen demuestra
nicamente que el remitente ha enviado el mensaje encriptado, si bien no conoce
su contenido. Por otra parte, la integridad de contenido puede demostrar que el
remitente conoce el contenido del mensaje.
La autentificacin de origen de mensaje utiliza el campo EXTENSIN
verificacin de Autentificacin de origen del mensaje que, bsicamente, es
una firma sobre el contenido del mensaje, el identificador de contenido del
mensaje y la etiqueta de seguridad del mensaje.
Pgina 188
Opcionalmente, la integridad de contenido del mensaje puede utilizar los

campos verificacin de integridad de contenido o token. Estos dos campos
son de tipo EXTENSIN que pueden producirse una vez por destinatario de
mensaje. El campo verificacin de integridad de contenido contiene una firma
que cubre el contenido del mensaje, tanto como una EXTENSIN, como dentro
del token. Dentro del token, el campo puede asimismo ir encriptado con el fin de
protegerlo contra ataques. Debido a que el propio token est protegido contra
manipulacin mediante una firma, basta con utilizar un algoritmo de suma de
comprobacin en este punto (sin utilizar la clave privada del remitente).
Es posible utilizar otros mtodos (como la proteccin de los mensajes mediante
algoritmo de suma de comprobacin) que requieren una clave secreta. El token
proporciona incluso un campo clave correspondiente (encriptado). Asimismo, la
integridad del mensaje puede garantizarse codificando el contenido del mismo
utilizando un procedimiento adecuado y una clave acordada bilateralmente de
antemano, siempre que el propio mensaje contenga suficiente redundancia para
verificar la integridad (que, de nuevo, es perjudicial para el secreto).
Integridad del contenido
Finalidad. Que el destinatario del mensaje sea capaz de comprobar si el mensaje
ha sido alterado durante la transmisin.
Realizacin. Esta funcin se realiza mediante firma electrnica, como se ha
explicado anteriormente para la Autentificacin del origen del mensaje.
Confidencialidad del contenido
Finalidad. Que nicamente el destinatario legtimo del mensaje tenga capacidad
para leer el contenido del mismo.
Realizacin. Esta funcin se realiza, por ejemplo, mediante el encriptado del
contenido del mensaje, utilizando la clave pblica del destinatario. Debido a que
este encriptado consumira gran cantidad de tiempo, se utiliza una combinacin
de encriptado asimtrico y simtrico. El mensaje propiamente dicho se encripta
utilizando una clave de mensaje aleatoria y un procedimiento de codificacin
simtrica. Asimismo, la clave propiamente dicha se suministra de modo
encriptado asimtrico en el campo de datos encriptados del token.
Alternativamente, el mensaje puede codificarse utilizando un procedimiento
acordado bilateralmente y una clave. El algoritmo utilizado y las referencias a la
clave utilizada se suministran en el campo EXTENSION "Identificador del
algoritmo de confidencialidad del contenido".
Etiquetado de seguridad de mensajes
Finalidad. Esta funcin hace posible la entrega de mensajes con una
clasificacin legible por una mquina. Ello es importante para sistema en los que
esta clasificacin se utiliza para controlar los derechos de acceso y la separacin
de datos en clases de seguridad.
Pgina 189
Realizacin. Esta funcin se realiza fijando el valor del campo EXTENSIN de

"etiqueta de seguridad de mensaje" o del campo correspondiente en el token.
Asimismo, en el token es posible proteger la etiqueta de seguridad contra la
lectura (ilegal) mediante la implantacin de una parte encriptada, con el fin de
que la clasificacin del mensaje no se muestre al exterior. Advertencia: fuera del
token, el campo nicamente est protegido contra manipulacin si est activado
al mismo tiempo el elemento de seguridad "prueba de origen" (pero no el
elemento "integridad del mensaje", que no tiene en cuenta el campo "etiqueta de
seguridad del mensaje").
Integridad de la secuencia de los mensajes
Finalidad. Esta funcin garantiza que la secuencia en la que se envan los
mensajes se conserva en la recepcin y que no se pierden ni se duplican los
mensajes.
Realizacin. Supone la introduccin en el token de mensaje de un nmero de
secuencia de mensaje y el mantenimiento por el UA de un registro de secuencias
de mensajes por remitente y por destinatario. El token protege el nmero de
secuencia de los mensajes contra manipulacin ilegal. Asimismo, es posible
encriptar el nmero de secuencia de los mensajes, con el fin de mantenerlos
secreto.
Prueba de entrega
Finalidad. Proporciona una confirmacin electrnica que garantiza el hecho de
que el destinatario ha recibido el mensaje de modo legible.
Realizacin. El UA destinatario firma el mensaje (desencriptado)
electrnicamente y enva la firma al remitente. En el informe de entrega se
proporciona un campo EXTENSION (prueba de entrega) con esta finalidad. La
prueba de entrega se solicita utilizando el campo EXTENSION "solicitud de
prueba de entrega" del mensaje.
Prueba de envo
Finalidad. Esta funcin proporciona una confirmacin electrnica que garantiza
el hecho de que el mensaje se ha enviado realmente (transmitido a un MTA).
Realizacin. El MTA adyacente al UA firma el mensaje electrnicamente y
enva la firma al remitente cuando lo solicita, utilizando el campo EXTENSION
solicitud de prueba de envo del mensaje. El remitente recibe la firma en el
campo pruebas de envo en el resultando de la operacin de envo del mensaje.
No rechazo de origen
Finalidad. Esta es una forma ms fuerte de prueba de entrega. El remitente
puede, asimismo, demostrar a terceros que este mensaje se ha recibido
correctamente.
Pgina 190
Realizacin. Se realiza mediante firma electrnica del mensaje (desencriptado)

por el destinatario utilizando un sistema de encriptado asimtrico adecuado.
No rechazo de envo
Finalidad. Esta es una forma ms fuerte de prueba de envo que, de nuevo,
supone la capacidad de demostracin a terceros.
Realizacin. Se realiza mediante firma electrnica del mensaje por el MTA
adyacente al UA, utilizando un sistema de cifrado asimtrico adecuado.
Confidencialidad volumen de trfico
Finalidad. Incluso si se envan mensajes cifrados, una persona no involucrada
en la comunicacin podra extraer conclusiones acerca de las posibles
actividades llevadas a cabo en una o ms organizaciones, basndose en el
nmero y el tamao de los mensajes enviados (anlisis estadstico de trfico).
Pueden adoptarse medidas adicionales para distorsionar los resultados de dicho
anlisis, de modo que no resulte significativo.
11.9.
SMTP
No se puede imaginar Internet sin el correo electrnico. Este servicio es el ms utilizado

desde los albores de la Red, utilizndose un
programa sendmail y un protocolo SMTP, que
ha
creado
toda
una
cultura.
El propsito del Simple Mail Transfer Protocol,
es gestionar la transferencia de correo
electrnico de un ordenador a otro. No acepta
correo de un usuario local ni distribuye correo a
los destinatarios. Esto lo realiza el sistema de
correo local. La normativa de este protocolo
viene recogida en el RFC-822.
De esta forma SMTP no ve el correo realizado
de
forma
local
en
una
mquina.
Slo entra en accin cuando se enva o se recibe
correo de otra mquina.Normalmente existe una
cola E/S en el interface entre el sistema de
correo local (Local Mail System) y las puertas
Cliente/Servidor. El cliente se preocupa de
enviar correo a otros sistemas y el clientes de
recibirlo.
El sistema local dispone de unos buzones para cada usuario del sistema. El nombre con
que se referencia al usuario se compone de dos partes:
Puerto local: Es sencillamente el nombre del usuario y debe ser nico en sistema
local. (esteban)
Puerto Global: Es el nombre de la mquina y debe ser nica en Internet. (udc.es)
Pgina 191
Ambos estn unidos por una @.

11.9.1.
Formato del correo
En este sistema un mensaje de correo electrnico se compone de dos partes:

cabecera y cuerpo.
Cabecera
La cabecera se compone a su vez de campos obligatorios y opcionales.
Obligatorios
TO: Para indicar el destino
FROM: Para indicar el remitente.
Opcionales
REPLAY TO: Nombre que indica la respuesta a un mensaje
CC: Destinatario a quien se le enva una copia
BC: Destinatario a quien se enva una copia sin que se entere los destinatarios de
CC
SUBJECT: Tema del correo.
DATE: Fecha del correo.
ENCRYPTED: Puntero de cifrado.
RECEIVED FROM: seala las mquinas por las que ha ido pasando el correo.
El cuerpo
El cuerpo consta de un texto de caracteres ASCII, como mximo de 64 Kb, separado de
la cabecera por una lnea en blanco y acabando con un lnea que contenga nicamente
un punto y un retorno de carro.
Pgina 192
11.9.2.
Transferencia de correo
Una vez que se ha creado el correo electrnico a enviar, el sistema local

determina si debe colocar el correo en la cola de salida del SMTP en funcin del
nombre del destinatario. Si el destinatario es local se encarga el sistema local de correo.
Si el destinatario no est en la mquina que origin el correo, el cliente SMTP busca la
direccin IP del destinatario utilizando el Domain Name Server (DNS). Se establece
una conexin a travs del puerto 25 con un servidor SMTP en la mquina de destino, y
le pasa el correo. Esta transferencia se realiza a travs de unos comandos (PDU del
SMTP.) sobre la conexin establecida TCP. Cada comando es una cadena de caracteres
ASCII.
La sesin empieza establecindose una conexin TCP a travs del puerto 25
entre el cliente y servidor SMTP. Una vez que se ha establecido la conexin el servidor
responde con un PDU 220(ready for mail). El cliente enva HELLO al servidor
indicndole su nombre, el Servidor responde indicndole el suyo.
El cliente enva MAIL FROM: remitente. El cliente responde con PDU 250 (Ok). El
Pgina 193
cliente responde con RCPT TO destinatario. El servidor puede responder con PDU 250
indicando que el nombre es de su dominio, o con PDU 550 indicando que no.
Si se ha recibido 250 el cliente enva DATA. El servidor responde con PDU 345
(Ready for Mail), indicando que est dispuesto a recibir el cuerpo del correo. El cliente
entonces enva el cuerpo del correo, acabando con una lnea con solo punto y un retorno
de carro. El servidor responde con PDU 250(OK) indicando que ha detectado el fin del
cuerpo del correo. El cliente responde con QUIT y el servidor responde con PDU 221
(Destination closing). Posteriormente se interrumpe la conexin TCP.
Adems de estas acciones bsicas tambin se pueden dar otros tipos de
transacciones como:
Si el receptor no tiene un buzn en la mquina de destino, se puede remitir una
redireccin para reencaminar el mensaje.
Despus de que se haya enviado el correo, el cliente puede invitar al servidor a
que enve correo en direccin contraria si tiene algo.
11.9.3.
RFC-822
El RFC-822 es el documento donde se establece la normativa para el correo

electrnico a travs de Internet (SMTP). En esencia, el correo se ve como un sobre y un
contenido. En el sobre se coloca la informacin para que el correo pueda llegar a su
destino, y el contenido es el mensaje en s mismo.
Esto hace que el sistema contemple Campos de Sistema y Campos de Usuario.
Campos de sistema
Camino de retorno (Return Path). El sistema de transporte final que entrega el
mensaje aade esta informacin al receptor. Contiene informacin completa de
las direcciones y de las rutas por la que ha pasado el correo.
Recibido (Received). Cada servicio de transporte por el que pasa el mensaje
aade este campo. Es til para tracear la ruta que el mensaje ha seguido y
solventar problemas tcnicos.
Fecha (Date) Indica simplemente la hora y la fecha en la que se cre el mensaje.
Identificador del mensaje (Message-ID). Contiene un identificador nico que se
hace referencia a la versin de este mensaje. La mquina que lee el mensaje
tiene que garantizar la unicidad del identificador.
Respuesta a (Replay-to). Este campo indica cualquier buzn al que se le debe
enviar una rplica.
DE (FROM) Este campo contiene la identificacin del remitente. Si este campo
no existe debe existir entonces el campo Sender.
Remitente (Sender) Este campo tiene la identidad del agente (persona, sistema
o proceso) que enva el mensaje. Generalmente se usa cuando el remitente del
mensaje no es el Autor del mensaje. Se puede omitir si es redundante con
FROM.
Pgina 194
Campos de usuario
TO
CC
Subject
11.9.4. Comparacin X.400 y SMTP
X.400 es un estndar definido por el CCITT e ISO, y aunque tericamente estn
sustentados por organizaciones internacionales sin ningn inters, la realidad es que
detrs de estas comisiones de estandarizacin estn los operadores telefnicos y grandes
compaas de hardware de comunicaciones que pretenden imponer SU ESTNDAR.
Hay demasiada gente involucrada, la mayor parte de ellos interesados en hacer
dinero con la estandarizacin en lugar de llegar a un buen estndar. De esta manera se
llega a estndares que despus la industria no lo quiere implementar. Se ha hecho
demasiada nfasis en definir estndares que son cargadas con excesivos servicios en
lugar de definir servicios econmicos y con la suficiente calidad para que las empresas
quieran implementarlos y la gente utilizarlos.
Ventajas de X.400
Las ventajas mas importantes que presenta son la generalidad y su
extensibilidad. Se ha diseado pensando que sobreviva a los cambios que puedan
introducir los avances tecnolgicos, como ha pasado con la cultura de los PC y la
multimedia. Por otra parte no ha habido ningn problema en ampliarlo con la normativa
X.435 para soportar EDI. Una de las ventajas de X.400 que incluye de forma nativa
soporte para mensajes multimedia, no ha habido que proceder a realizar ninguna
extensin.
Desventajas del X.400
Excesiva influencia de los operadores telefnicos con intencin de aumentar sus
ganancias. Tambin se nota que la legibilidad, la organizacin, la notacin y el lenguaje
empleado estn muy pobremente utilizados. Se desarrolla software que despus no
resulta compatible con el estndar porque no se ha comprendido complemente el
estndar o bien el estndar no est completamente definido. Por otra parte, otras
entidades de estandarizacin, puede ser el Internet Engineering Task Force (IETF),
generan documentos que son muchos ms legibles y comprensibles que los anteriores,
aunque en presentacin dejan mucho que desear.
Un ejemplo claro ha pasado con el protocolo OSI de comunicaciones. Est muy
bien estructurado, muy soportado por organismos internacionales, pero prcticamente
nadie lo ha implantado. La cuestin es que muy ineficiente y muy complicado el
implementarlo. Sin embargo, si se mira desde el punto de OSI esto es debido para poder
proporcionar seguridad y disponibilidad.
Adems, tiene un sistema de direccionamiento realmente complejo. El sistema
de direccionamiento SNTP es realmente sencillo. Adems, el X.400 requiere cambiar la
Pgina 195
direccin de usuario si este cambio de ubicacin o si la empresa reestructura sus

secciones.
Ventajas Correo de Internet
Una de mayores ventajas que tiene este tipo de correo es que se ha convertido en
el estndar de facto de Internet. Esto elimina el problema de no encontrar software para
utilizarlo, adems de proporcionar pasarelas a otros entornos. Estos productos son muy
fiables e incluso gratis. A travs de las redes acadmicas, se ha convertido en el primer
servicio de la era de las comunicaciones, ha traspasado estas fronteras y se ha
implantado en el mundo empresarial.
Desventajas Correo de Internet
El principal problema es que no se penso en hacerlo funcionar con otros
sistemas, lo que ha provocado tener que aadir muchos mdulos.
No se penso en hacerlo extensible ni genrico, esto ha creado graves problemas a la
hora de tener que aadir nuevas funcionalidades. Este problema se ha visto con las
extensiones MIME. Y quiz el mayor problema que tiene es el de la seguridad. Se ha
dicho en muchas ocasiones que el programa sendmail es el programa ms peligroso de
la historia de la Informtica. Constantemente se estn encontrando agujeros de
seguridad y tener que reparchear constantemente el programa. Este problema es que ha
provocado que la Banca, Entidades de Seguros, la Administracin, o sea, los pesos
pesados
de
la
informtica
se
hayan
negado
a
utilizarlo.
Tambin para este tipo de problemas se han encontrado soluciones, como emplear
versiones reducidas de sendmail o utilizar PGP de forma extensiva.
Comparacin
Esta claro que cada uno intenta resolver un problema diferente. El correo de
Internet pretende resolver problemas que existen en la actualidad y que se implementes
rpidamente. Sin embargo, el CCITT (ITU) est ms interesado en definir estndres que
duren un largo periodo de tiempo.
El resultado es que el IEFT proporciona soluciones sencillas para resolver
problemas especficos, y provoca generar software que incluso es gratis en la red, sin
embargo, ITU consigue soluciones muy complejas, despus de aos de estudios, muy
caras, de cuyos productos nicamente se puede conseguir soporte del proveedor del
software.
Para la mayora de los usuarios, que solamente envan mensajes de texto, el sistema
X.400 es muy ineficaz, cara y complicada. Pero para los usuarios que utilizan el correo
de forma completa, enviando tipos de datos variados, que pretende disponer de alto
nivel de seguridad y disponibilidad la solucin es X.400.
11.9.5.
MIME
Mime (Multipurpose Internet Mail Extensions), se construye sobre el estndar de

correo Internet de 1982 con la intencin aadir campos extras para poder transmitir
ficheros binarios.
Pgina 196
El estndar original de 1982 de Correo Internet solo permita transmitir ficheros de

textos con las siguientes restricciones:
Uso nicamente de caracteres ASCII
Cada lnea no puede ser mayor de 1000 caracteres
La mxima longitud del mensaje es de 64 K.
El estndar MIME permite:
Objetos mltiples en un solo mensaje
Cada lnea del mensaje no tiene lmite
Longitud total del mensaje sin lmite.
Posibilidad de utilizar caracteres no ASCII
Los mensajes pueden estar compuestos de mltiples fuentes: ficheros binarios,
imgenes, sonido, video etc.
Permite que el usuario defina sus propios tipos de datos
Campos de cabecera
MIME define una serie de nuevos tipos de cabecera, sin embargo, la mayora solo
se preocupan de los campos segn el tipo de contenido.
Versin: Este campo se utiliza para colocar el nmero de la versin de MIME.
Tipo de contenido: dispone de varios campos de este tipo, cada uno de ellos
indica el tipo de contenido seguido de un valor que indica el tipo de data del
cuerpo del mensaje. Los tipos pueden ser:
Texto. Se usa para indicar que se enva informacin tipo texto con un cierto
nmero del conjunto de caracteres y lenguaje de descripcin de texto formateado
de forma estndar.
Multiparte. Este tipo se puede usar para combinar varios cuerpos de mensaje en
un solo mensaje. Cada uno de estos cuerpos puede ser de un tipo distinto.
Aplicacin. Datos de una aplicacin o datos binarios.
Mensaje. Se usa para encapsular un mensaje de correo.
Imagen. Para indicar que es una imagen esttica
Audio. Para indica que se enva un fichero con datos de voz.
Vdeo. Para indicar que se enva imgenes en movimiento, quiz con parte de
audio.
Codificacin de contenido. Este campo especifica que se transmiten datos
codificados para permitir su paso a travs de los enrutadores de correo que
podran poner limitaciones a este tipo de datos o caracteres.
Identificacin y descripcin de contenido. Estos dos campos de cabecera para
identificar y describir mejor el cuerpo del mensaje. Es una parte que se deja
abierta para futuras actualizaciones.
Pgina 197

Intercambio Electronico de Documentos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Intercambio Electronico de Documentos

Загружено:

Авторское право:

Доступные форматы

CAP. 1 PRESENTACIN .............................................................................................

CAP. 7 IMPLANTACIN ......................................................................................... 115

Introduccin .............................................................................................. 156

Intercambio Electrnico de Documentos

Intercambio Electrnico de Documentos

Los datos que se intercambian son transacciones comerciales, o de forma amplia

1.1 Antecedentes histricos

Intercambio Electrnico de Documentos

1982. Se crea el Guidelines for Trade Data Interchange (UNECE/GTDI)

Actualmente EDI est polarizado entre la normativa X.12 y EDIFACT, aunque

1.2 Beneficios de la implementacin de EDI

Intercambio Electrnico de Documentos

Ventajas asociadas al factor estrategia:

Intercambio Electrnico de Documentos

Cualquiera de esos documentos se someten a un proceso similar al siguiente: El

Intercambio Electrnico de Documentos

1.3 Motivos por los que se adopta EDI

Las razones internas (Estratgicas, Operacionales y de Oportunidad) que llevan a la

En otras ocasiones, debido al gran volumen de informacin que intercambian

Intercambio Electrnico de Documentos

2.1 Centro de compensacin

Requisitos bsicos de un centro de compensacin

Un Centro de Compensacin (CC) debe proporcionar a sus clientes unas

Tolerantes a Fallos. Es el principal factor para medir la calidad de servicio que

Elementos crticos lgicos.

Los elementos lgicos ms importantes de los que depende la calidad de servicio de un

Los elementos lgicos sensibles del Centro de Compensacin deben estar

Intercambio Electrnico de Documentos

Sistema de operacin: el sistema de operacin debe ser fiable en la medida de

Lneas de comunicaciones redundantes: es sumamente importante disponer de

El sistema de almacenamiento de datos del sistema debe estar

Intercambio Electrnico de Documentos

El grupo de procesadores del sistema debe procesar la informacin por

Un responsable, que coordinar toda la accin

Errores fsicos de operacin: por ejemplo en el cambio de cintas de

Intercambio Electrnico de Documentos

comandos sensibles del sistema operativo, ya que por

Conjuntamente a las necesidades intrnsecas del sistema existen unas necesidades

Amplia opcin de servicios.

Un CC se caracteriza no solo por su capacidad de intercambiar documentos entre

Recursos de defensa de integridad del Centro de Compensacin.

Todo CC debe contar con un conjunto de recursos que lo protejan de los

Intercambio Electrnico de Documentos

Descripcin de un Centro de Compensacin tipo.

El Centro Servidor o CC es el intermediario entre interlocutores. En l cada

Una plataforma hardware puede componerse de dos ordenadores

Funcionalidades del centro de compensacin.

Intercambio Electrnico de Documentos

Capacidad de intercambio internacional a travs de la red Infonet.

Intercambio Electrnico de Documentos

Identificacin de los datos y verificacin de la integridad.

Opcin de estadsticas especiales: proporcionan al usuario estadsticas ms

Es la red de datos de Telefnica. Su amplia difusin geogrfica permite accesos muy

Mediante este protocolo la estacin de usuario debe disponer de mdem V.22

Este procedimiento utiliza una lnea X.25 conectada a la Estacin de Usuario. En

Intercambio Electrnico de Documentos

Intercambio Electrnico de Documentos

2.3 Alternativas existentes del centro de compensacin

Solucin de Centro de Compensacin Virtual

Para aquellas comunidades de interlocutores EDI, en las que no se justifique el

Solucin de Centro de Compensacin estndar.

Esta solucin es la ofrecida normalmente a los usuarios EDI, es la desarrollada en

Intercambio Electrnico de Documentos

Resolver problemas de incompatibilidad entre diferentes sistemas de