# Canales de transmisión EDI: ¿cuál encaja con su socio? Los canales de transmisión EDI habituales son AS2, OFTP2, SFTP, interfaces HTTPS (API), el correo electrónico y, en algunos sectores, todavía X.400 a través de una VAN. Cuál usa usted rara vez lo decide solo: normalmente el cliente o el proveedor fija el canal en su guía EDI. Esta página muestra en qué se diferencian los protocolos de comunicación EDI y en qué debe fijarse al ponerlos en marcha. ## Formato y canal de transmisión son dos preguntas distintas Una conexión EDI tiene dos niveles que a menudo se confunden: - El formato determina cómo se estructura el contenido: EDIFACT, VDA, XML o CSV. Más información en [EDIFACT explicado](https://edi-service.eu/es/guia/edifact/). - El canal de transmisión determina cómo llega el fichero de un ordenador a otro: AS2, OFTP2, SFTP, etc. Los niveles son independientes. Una factura EDIFACT puede viajar por AS2, por OFTP2 o por SFTP. Un programa de entregas VDA suele llegar por OFTP2, aunque técnicamente podría hacerlo de otra forma. Cuando su cliente le pide «EDI», necesita por tanto las dos respuestas: qué formato y qué canal. ## Los canales de transmisión EDI de un vistazo ### AS2 AS2 envía ficheros por HTTP directamente al socio, firmados, cifrados y con un acuse de recibo, la MDN. Se basa en el RFC 4130. AS2 no está ligado a ningún sector. Detalles: [AS2 explicado](https://edi-service.eu/es/guia/as2/). ### OFTP2 OFTP2 es el protocolo de la industria del automóvil, mantenido por Odette y descrito en el RFC 5024. Funciona con una conexión TCP propia (puerto 6619 con TLS), usa certificados y confirma cada fichero con un EERP. Detalles: [OFTP2 explicado](https://edi-service.eu/es/guia/oftp2/). ### SFTP SFTP transmite ficheros a través de una conexión SSH (Secure Shell, RFC 4251; puerto estándar 22). Normalmente una parte pone a disposición un directorio y la otra deposita o recoge allí los ficheros. La conexión está cifrada, pero no hay acuse de recibo a nivel de fichero. Si un fichero se ha procesado solo lo sabrá por un mensaje de respuesta o por un acuerdo, por ejemplo «el fichero se borra una vez recogido». ### Interfaz HTTPS (API) Una conexión por API significa que el socio ofrece una dirección web a la que su sistema envía datos o de la que los recoge, normalmente en JSON o XML. La conexión está cifrada con TLS (RFC 8446) y la autenticación se hace con claves o tokens. Cada API tiene su propia estructura, de modo que cada una necesita su propia conexión. ### Correo electrónico El correo electrónico es el canal más sencillo: el fichero EDI va adjunto a un mensaje. El RFC 1767 describe cómo se empaquetan datos EDI en mensajes MIME; AS1 (RFC 3335) añadió firma y acuse de recibo. En la práctica, un correo simple no va firmado ni confirmado. Aun así se usa para volúmenes pequeños o como solución transitoria. ### X.400 y VAN Con X.400, la UIT-T describe una serie de normas para sistemas de mensajería; recoge versiones desde 1988 y la vigente es la de 1999. Una VAN (Value Added Network, red de valor añadido) es la red de un proveedor con buzones a través de la cual los socios intercambian datos sin conectarse directamente. En la distribución todavía se encuentra X.400: proveedores de servicios EDI alemanes como cctop y EDI Fuchs lo incluyen en sus listas de precios, EDI Fuchs por ejemplo como recargo desde 10 € al mes por tipo de mensaje y socio. ## Tabla comparativa | Canal | Dónde es habitual | Seguridad | Acuse de recibo | Esfuerzo para usted | |---|---|---|---|---| | AS2 | en todos los sectores | firma y cifrado por fichero, TLS opcional | sí, MDN (puede ir firmada) | medio: software, certificado, dirección accesible | | OFTP2 | industria del automóvil | TLS, certificados, firma y cifrado de fichero posibles | sí, EERP (puede ir firmado) | medio a alto: software, Odette-ID, certificado, puerto 6619 | | SFTP | en todos los sectores | conexión cifrada con SSH | no, solo por acuerdo o mensaje de respuesta | bajo: acceso y clave | | HTTPS/API | donde el socio ofrece una API | TLS, autenticación con token o clave | según la API (código de respuesta, estado) | una conexión propia por API | | Correo electrónico | volúmenes pequeños, soluciones transitorias | correo simple sin protección, cifrado solo con complementos | no (con AS1, sí) | bajo, pero propenso a errores | | X.400/VAN | partes de la distribución | dentro de la red del proveedor | según la red | contrato con un proveedor de VAN, cuotas periódicas | La columna «Dónde es habitual» es una clasificación aproximada. Lo que cuenta es lo que exige su socio en su guía EDI. ## En qué fijarse al elegir Si puede elegir, ayudan tres preguntas: 1. ¿Necesita una prueba de que el fichero ha llegado? Con avisos de expedición y facturas suele ser así. En ese caso AS2 y OFTP2 tienen ventaja, porque el acuse de recibo forma parte del procedimiento. 2. ¿Quién establece la conexión? Con AS2 y OFTP2 es frecuente que el socio le envíe los datos activamente. Para ello su servidor necesita una dirección fija y un puerto de entrada abierto. Con SFTP o una API también puede recoger usted los datos, sin abrir ningún puerto en su cortafuegos. 3. ¿Cuántos socios usan el mismo canal? Cada canal adicional es un componente más que hay que operar, supervisar y mantener con certificados. En cuanto a la seguridad: para muchos datos basta un canal con conexión cifrada. Los ficheros firmados y los acuses de recibo compensan cuando más adelante pueda haber discrepancias sobre la recepción o el contenido. ## Costes de la transmisión Las especificaciones de AS2, OFTP2, SFTP y HTTPS se pueden consultar libremente como RFC. Los costes proceden del software, los certificados, en OFTP2 del Odette-ID, y de la operación. Con X.400 y VAN se suman las cuotas periódicas del operador de la red. Cómo sale la cuenta en conjunto lo muestra [¿Cuánto cuesta una conexión EDI?](https://edi-service.eu/es/guia/cuanto-cuesta-edi/). ## Canales de transmisión en edi-service.eu edi-service.eu admite OFTP2, AS2, SFTP, HTTPS y correo electrónico, de entrada y de salida. No incluye X.400 ni buzones VAN. Si un socio solo es accesible por esa vía, hace falta un canal adicional (por ejemplo, un proveedor de servicios EDI solo para ese socio) o que el socio cambie a AS2 u OFTP2. Nuestro componente OFTP2 no ha sido probado por Odette; lo aclaramos de antemano si su cliente exige software probado. Lo que cubre el precio figura en [Precio](https://edi-service.eu/es/#preis). ## Preguntas frecuentes ### ¿Cuál es el mejor canal de transmisión EDI? No hay un único canal mejor; normalmente decide su socio. En la industria del automóvil está extendido OFTP2; otros sectores usan AS2, SFTP o una API según el socio. SFTP es fácil de configurar, pero no ofrece acuse de recibo. ### ¿Basta el correo electrónico para el EDI? Para volúmenes pequeños y como solución transitoria puede bastar, si su socio lo acepta. Pero un correo simple no va firmado ni confirmado, y los buzones a veces filtran los adjuntos. Para avisos de expedición y facturas, un canal con acuse de recibo es la opción más segura. ### ¿Qué es una VAN y la necesito? Una VAN es la red de un proveedor en la que cada participante tiene un buzón. Solo la necesita si un socio es accesible exclusivamente por esa vía, por ejemplo por X.400. Para conexiones directas por AS2, OFTP2 o SFTP no hace falta ninguna VAN. ### ¿Mi servidor tiene que ser accesible desde internet? Con AS2 y OFTP2, casi siempre: cuando el socio le envía los datos activamente. En ese caso necesita una dirección fija y un puerto abierto. Con SFTP o una API en las que usted mismo recoge los datos, basta una conexión saliente. ¿Quiere comprobar si los canales de transmisión de sus socios encajan con edi-service.eu? [Enviar una solicitud](https://edi-service.eu/es/solicitud/) ## Fuentes - RFC Editor: «RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)», (consultado el 16/10/2026) - RFC Editor: «RFC 5024: ODETTE File Transfer Protocol 2», (consultado el 16/10/2026) - Odette International: «OFTP2», (consultado el 16/10/2026) - RFC Editor: «RFC 4251: The Secure Shell (SSH) Protocol Architecture», (consultado el 16/10/2026) - RFC Editor: «RFC 4253: The Secure Shell (SSH) Transport Layer Protocol» (puerto 22), (consultado el 16/10/2026) - RFC Editor: «RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3», (consultado el 16/10/2026) - RFC Editor: «RFC 1767: MIME Encapsulation of EDI Objects», (consultado el 16/10/2026) - RFC Editor: «RFC 3335: MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet», (consultado el 16/10/2026) - UIT-T: «F.400/X.400: Message handling system and service overview», (consultado el 16/10/2026) - stratEDI (cctop): lista de precios de clearing y WebEDI (PDF), (consultado el 16/10/2026) - Fuchs ITC (EDI Fuchs): precios, (consultado el 16/10/2026)