homologación prestadores edi - gs1 argentina · manual para la homologación de prestadores de...

Manual para la Homologación de Prestadores de Servicios EDI Diciembre 2012 - v2

Manual para la Homologación de Prestadores de Servicios EDI

2Diciembre 2012, v2 Copyright© GS1 Argentina 2012

Contenido

1. Manual para la Homologación de Prestadores de Servicios EDI .............................................................................................. 5

1. Introducción ...................................................................................................................................................................................................................................................... 5

2. Objetivo ................................................................................................................................................................................................................................................................. 5

3. Aspectos generales ...................................................................................................................................................................................................................................... 5

4. Proceso de validación .................................................................................................................................................................................................................................. 6

4.1.Asociación del Prestador de Servicios EDI a GS1 Argentina .................................................................................................................................... 7

4.2. Presentación de la Documentación requerida ............................................................................................................................................................. 7

4.3. Entrevista de Verifi cación ............................................................................................................................................................................................................ 8

4.4. Emisión de observaciones .......................................................................................................................................................................................................... 8

4.5. Feedback del proceso ................................................................................................................................................................................................................... 8

4.6. Publicación de los resultados .................................................................................................................................................................................................. 9

2. Anexo I ............................................................................................................................................................................................... 10

Requerimientos para la homologación.............................................................................................................................................................................................. 10

3. Anexo II .............................................................................................................................................................................................. 25

Diagrama de Secuencia y Reglas de Servicio ...................................................................................................................................................................................25

1. Introducción ................................................................................................................................................................................................................................................... 25

Contexto y objetivo ............................................................................................................................................................................................................................... 25

2. Diagrama de Secuencia .......................................................................................................................................................................................................................... 26

Modelo de Servicio EDI con un único Prestado de Servicio ........................................................................................................................................ 26

Modelo de Servicio EDI con dos Prestadores de Servicio ............................................................................................................................................. 27

Detalle del Diagrama de Secuencia ........................................................................................................................................................................................... 28

4. Anexo III ............................................................................................................................................................................................. 36

Estándares y documentos vigentes para homologar ............................................................................................................................................................... 36

5. Anexo IV ............................................................................................................................................................................................. 37

Información del prestador de Servicios EDI .................................................................................................................................................................................... 37

Carta de Adhesión ........................................................................................................................................................................................................................................... 38

6. AnexoV ............................................................................................................................................................................................... 39

Modelo de Informe Mensual ................................................................................................................................................................................................................... 39

7. AnexoVI .............................................................................................................................................................................................. 40

Modelo de Constancias .............................................................................................................................................................................................................................. 40



Grupo de Trabajo

Esta nueva versión del Manual para la Homologación de Prestadores de Servicio EDI de GS1 Argentina responde a las

necesidades planteadas por la comunidad en las reuniones del Grupo de Trabajo de EDI de Consumo Masivo. Esto es así

tanto en lo que respecta a los criterios a aplicar en el Proceso de Homologación, como también en lo que refi ere al rol

asignado a nuestra Organización como entidad encargada de defi nir y aplicar el mencionado proceso.

Nombre Empresa

Victor Luna Arcor

Karina Alice Carrefour

Diego Efron Cencosud

Leandro Japaz Cencosud

Valeria Rótolo Cencosud

Fernando Tilleiro Coca Cola FEMSA

Hugo Koval Coca Cola FEMSA

Adrian Gonzalez Cooperativa Obrera

Christian Abadia Cooperativa Obrera

Guillermo Volpintesta Cooperativa Obrera

Susana Linaza Cooperativa Obrera

Gabriela Rodriguez Cordiez

Hugo Suárez Cordiez

Guillermo Añaños Coto

María Paula Muñoz Coto

Silvina Saggese Coto

Claudio Farías Danone

Domingo Vivanco Grupo Bimbo

Marco Pineda Muñoz Grupo Bimbo

Esteban Sconoccini La Anónima

Víctor Gualdi La Anónima

Héctor Robles La Virginia

Juan Manuel Fera Maxiconsumo

Sergio Silva Maxiconsumo

José Levy Molinos Río de la Plata

Lorena D’Angelo Molinos Río de la Plata

Sabrina Raimondi Molinos Río de la Plata

Cristian Schmalzle Mondelez / Kraft Foods

Mariana Felchle Mondelez / Kraft Foods

Alejandro Luna Nestlé

Martín Massera Nestlé

Germán DiCarlo P&G

Juan Bibiloni P&G

Gustavo Sanjurjo Papelera del Plata

Mario Mercuri Papelera del Plata

Leandro Simari Quilmes

Martin Valseche Quilmes

Daniel Garrido Sancor



Nombre Empresa

Pablo Macagno Sancor

Javier Santolia SC Johnson

Cristian Jimenez Suc. de A. Williner

Osvaldo Wagner Suc. de A. Williner

Ana Cardone Unilever

Daniel Mendelberg Carvajal

Diego Gonzalez Carvajal

Diego Gonzalez Carvajal

Luis Sandoval Carvajal

Diana Salazar Edicom

Guillermo Corbi Edicom

Juan David Méndez Edicom

Adriana Bermudez Global Advant

Hernan Mendozzi Global Advant

Marcos del Molino Global Advant

Sergio Ramos Global Advant

Daniel de la Parte Ideas y Tecnología

Pablo Riveros Ideas y Tecnología

Rubén Sessa Ideas y Tecnología

Daniel Rigoni Planexware

Guido Pinto Planexware

Juan Carlos del Río Planexware

Luciana Gaspari Deloitte

Walter Riveros Deloitte

Rubén Calónico GS1 Argentina

Juan Pablo Mengide GS1 Argentina

Federico Sedano Acosta GS1 Argentina

Claudia Geniz GS1 Argentina

Anibal Serignese GS1 Argentina




1. Introducción

El Intercambio Electrónico de Documentos (EDI) se ha posicionado como una herramienta esencial en la operatoria

logística y comercial de sectores como Retail y Salud entre otros. Su uso permite:

■ Realizar negocios con mayor rapidez, facilidad y efi ciencia

■ Reducir costos de operación, niveles de inventario y errores administrativos

■ Aumentar la precisión y velocidad del intercambio de información

Para proceder a realizar intercambio de documentos y que el mismo sea efectuado con los niveles requeridos de calidad

y seguridad (autenticación de origen, privacidad, integridad del contenido y no repudio de origen o recepción), las em-

presas suelen recurrir a partners tecnológicos que gestionen el transporte de los datos. Estos partners serán denomina-

dos en adelante: Prestadores de Servicios EDI, o PS en forma abreviada.

2. Objetivo

El objetivo del presente Manual es fi jar las pautas y requerimientos de GS1 Argentina para con las empresas que deseen

ser homologadas como Prestadores de Servicios EDI, y los procedimientos aplicables a dicha homologación.

GS1 Argentina, con la meta de optimizar los procesos logísticos y comerciales en benefi cio de toda la cadena de abas-

tecimiento, procura garantizar a sus asociados por medio de la Homologación de Prestadores de Servicios EDI, que

quienes superen exitosamente el proceso son aptos para brindar el servicio y/o aplicaciones de Intercambio Electrónico

de Documentos (EDI) en las condiciones técnico-operativas adecuadas y alineadas con los requerimientos manifestados

por los usuarios.

En tal sentido GS1 Argentina pone foco en:

■ El Intercambio Electrónico de Documentos en los formatos estándar difundidos y administrados por GS1 a nivel global.

■ Los niveles de servicio requeridos por sus asociados.

■ El Modelo de Interoperabilidad entre Prestadores de Servicio EDI requerido por el Mercado.

■ Las recomendaciones de los expertos en seguridad informática que colaboraron con GS1 en la confección

de los Anexos.

Todo otro servicio y/o aplicación adicional brindados por los Prestadores de Servicios EDI, en función a su estrategia

comercial y/o de los acuerdos realizados con sus clientes, y que no se vinculen con los estándares GS1 eCom, NO están

incluidos dentro del marco de la homologación.

3. Aspectos generales

■ La adhesión al proceso de homologación es voluntaria.

■ Solamente podrán acceder a la homologación, aquellas empresas asociadas a GS1 Argentina, y que tengan sus cuotas

sociales al día.

■ La homologación tendrá una validez de 1 año.

■ GS1 Argentina defi nirá las rutinas apropiadas para validar los conceptos defi nidos dentro de dicho proceso.



■ Cualquier irregularidad persistente respecto a lo oportunamente defi nido dentro del proceso de homologación, será

causal de pérdida de la misma.

■ La comunidad GS1 tendrá a disposición en nuestra página web la información correspondiente a los Prestadores de

Servicios EDI homologados, así como la lista de documentos electrónicos verifi cados, junto a su período de vigencia.

■ Los diferentes Anexos del presente Manual defi nen las condiciones particulares aplicables al proceso de homologa-

ción de PS.

■ En el Anexo I, se hace referencia al detalle de los requerimientos específi cos para homologar, los cuales están en línea

con lo manifestado por los usuarios.

■ Por su parte, el Anexo II describe la secuencia y reglas para la prestación del servicio EDI, en sintonía con la propuesta

realizada por los propios PS.

■ Los estándares vigentes para esta homologación son los indicados en el Anexo III. Estos deberán actualizarse en cada

cambio de versión que GS1 International publique y cuando GS1 Argentina considere necesaria dicha migración.

■ Independientemente de los documentos mencionados en el Anexo III, en la presente homologación se estarán ve-

rifi cando todos los documentos estándar que los Prestadores tengan en producción y que deseen que fi guren en el

acuerdo de homologación entre estos y GS1 Argentina.

■ Para dar comienzo formal a la homologación, los PS deberán completar el formulario del Anexo IV, el cual brinda los

datos generales del Prestador y manifi esta la intención de participar del proceso.

■ Mensualmente, los Prestadores de Servicios EDI que hayan sido homologados, deberán enviar a GS1 Argentina un

reporte notifi cando la cantidad de transacciones realizadas, discriminando por estándar y por mensaje. En el Anexo V

puede verse el modelo para la presentación de esos datos.

■ Finalmente, en el Anexo VI se muestran modelos de Constancias que GS1 emitirá como culminación del proceso.

■ Todo PS podrá durante la vigencia de su homologación, presentarse a verifi car nuevos documentos electrónicos

específi cos. En tal caso, y una vez superado exitosamente el proceso, GS1 Argentina emitirá la constancia corres-

pondiente, la cual tendrá como fecha de caducidad la misma que fi gure en la Constancia de Homologación como

Prestador de Servicio EDI.

■ Es condición para homologar, que un PS presente a verifi cación al menos un documento electrónico de Proceso de

Negocios (Orden, Aviso de Despacho, Factura, Devoluciones, etc.) y además los documentos electrónicos de control

mencionados en los pasos mandatorios de la secuencia descripta en el Anexo II.

Se realizará un nuevo proceso de Homologación siempre que:

■ El Prestador de Servicios EDI efectúe modifi caciones a la solución tecnológica que brinda a sus clientes.

■ GS1 Argentina libere nuevas versiones de estándar y/o transacciones.

■ Se haya vencido el plazo de validez de la homologación previa.

■ El Asociado o el Prestador lo soliciten.

4. Proceso de validación

El proceso de validación involucra lo siguiente:

■ Asociación del Prestador de Servicios EDI a GS1 Argentina

■ Presentación de la Documentación requerida

■ Entrevista de Verifi cación

■ Emisión de observaciones

■ Feedback del Proceso



Asociación a GS1 Argentina

Emisión de observaciones

Feedback del Proceso

Feedback Negativo

Publicación de los resultados

Entrevista de Verificación

Presentación de la Documentación

Proceso

¿Menores?

¿PS SubsanaObserv.?

¿Desvíos?

Sí

No

No

No

Sí

Sí

4.1. Asociación del Prestador de Servicios EDI a GS1 Argentina

Con el objetivo de alinear acciones para estandarizar el Comercio Electrónico en Argentina, así como para masifi car su

uso y difundir las mejores prácticas, se requiere establecer una “Alianza” entre Prestadores de tecnología y GS1 Argentina.

Toda empresa que desee participar en los Grupos de Trabajo y/o en las nuevas iniciativas a nivel de toma de decisiones

y desarrollo, debe estar inscripta en GS1, con las cuotas al corriente, y adherir a los estatutos bajo los que se rige y opera

GS1 Argentina.

4.2. Presentación de la Documentación requerida

A los fi nes de iniciar el proceso de homologación, la empresa solicitante deberá presentar la siguiente documentación:

■ Formulario de inscripción (si no está inscripto)

■ Estar al día con las cuotas

■ Presentar completas y fi rmadas ambas páginas del Anexo IV

■ Breve descripción de la solución implementada por el Prestador de Servicios EDI, incluyendo alcances, diagramas, etc.

■ Dos instancias reales (entorno de producción) de cada documento electrónico a verifi car.



Es importante aclarar que GS1 Argentina desarrollará sobre las instancias de documentos electrónicos que los PS

presenten a verificar, una serie de pruebas técnicas y operativas que apuntan a chequear el cumplimiento del es-

tándar correspondiente en lo referente a su estructura y formatos (conforme al estándar GS1 que correspondiese:

XML o EANCOM). No se hará validación, difusión o uso alguno de los contenidos, los cuales en todos los casos serán

considerados confidenciales.

La documentación descrita deberá enviarse vía correo electrónico a la dirección [email protected]. A través de esa

vía, y dentro de las 96 hs hábiles, el Prestador de Servicios EDI recibirá la confirmación de la fecha de la Entrevista

de Verificación.

4.3. Entrevista de Verifi cación

En fecha acordada entre el PS y GS1 Argentina, se realizará la Entrevista de Verifi cación, la cual tiene por objetivo repasar

conjuntamente un cuestionario o “check list” armado según los requerimientos detallados en este Manual.

■ La Entrevista de Verifi cación se desarrollará en ofi cinas del PS, debiendo éste planifi car los recursos físicos, técnicos y

humanos necesarios para que se efectivice durante una única jornada laboral.

■ GS1 podrá adelantar el cuestionario, en caso de considerarlo adecuado, para que el PS prepare las respuestas, las

fundamente y/o designe al interlocutor adecuado a participar del desarrollo de la Entrevista.

■ GS1 Argentina podrá, durante el desarrollo de la Entrevista de Verifi cación, solicitar las evidencias documentales y/o

realizar las inspecciones visuales que considere necesarias como complemento a la evaluación de los ítems que for-

men parte del cuestionario.

■ Las evidencias serán tratadas como información confi dencial y en ningún caso GS1 dispondrá de la misma fuera del

ámbito de la Entrevista de Verifi cación.

■ En caso de que el PS no pueda dar respuesta a algún ítem específi co, se asumirá que no cumple con el mismo.

4.4. Emisión de observaciones

En aquellos casos donde se evidencie un grado de concordancia importante entre lo relevado y lo requerido en el Ma-

nual, GS1 Argentina podrá decidir una instancia de ajuste previa al cierre del proceso.

■ En caso de detectarse desvíos menores durante el proceso de revisión, el Prestador de Servicios EDI, recibirá un reporte

para que proceda a efectuar los ajustes indicados o la presentación de un plan de remediación según corresponda.

■ De acuerdo a la magnitud de los desvíos hallados, así como de las demoras en proceder a los ajustes, GS1 Argentina

podrá incluir requisitos adicionales para lograr la Homologación o bien dar por cerrado el proceso en forma negativa.

4.5. Feedback del Proceso

GS1 Argentina comunicará al PS el resultado del Proceso de Homologación dentro de 10 días hábiles de ocurrido alguno

de los siguientes hechos:

a) Culminación de la Entrevista de Revisión sin Emisión de Observaciones.

b) Recepción del Plan de Remediación en respuesta a las observaciones realizadas por GS1.

c) Manifestación de la conformidad de GS1 con los ajustes que el PS hubiese realizado para corregir los desvíos menores

detectados en el proceso de revisión.

En la mencionada comunicación, GS1 confi rmará si el resultado ha sido positivo y por ende se pasará al paso siguiente de

publicación de los resultados, o por el contrario, si el PS no ha tenido éxito en su intención de homologarse, GS1 explicará

las causas que motiven este hecho.



4.6. Publicación de los Resultados

Una vez culminado el proceso de revisión, y siempre que haya sido satisfactorio, GS1 Argentina publicará las correspon-

dientes Constancias de Homologación y de Verifi cación de Documento EDI en su sitio web: www.gs1.org.ar. En dicho

sitio se incluirá además el logo del Prestador de Servicios EDI, los datos básicos de contacto y un hipervínculo a su co-

rrespondiente sitio web.

En caso de que el PS presentase posteriormente nuevos documentos electrónicos a verifi car, sus correspondientes Cons-

tancias se agregarán a las previas.



Anexo I

Requerimientos para la homologación

Se describen a continuación los requerimientos para homologar que serán evaluados, clasifi cados por grupos de reque-

rimientos y con la indicación acerca de si se los considera mandatorio u opcional.

Por razones de comodidad en la página de GS1 Argentina se pondrá a disposición un documento Excel con el mismo

contenido.

Código Requerimientos para homologación Mandatorio Opcional

1 Reglas de negocio

1.1 Defi nición de reglas de negocio

Los proveedores de servicio deberán cumplir con el esquema de interope-

rabilidad defi nido en el Anexo I.

1.1.1 ANEXO I “Diagrama de secuencia y reglas de negocio” ✓

1.2 Estándares de Mensajes

1.2.1 Todos los documentos, mensajes y notifi caciones intercambiados median-

te EDI deberán cumplir con los estándares publicados y homologados por

GS1

✓

1.3 Niveles de servicio

Los proveedores de servicio deberán cumplir con los siguientes niveles

acordados durante el intercambio de documentos electrónicos

1.3.1 Disponibilidad del servicio 7x24x365 ✓

1.3.2 Soporte 7x24x365 ✓

1.3.3 Tiempo máximo de respuesta del soporte de 15 minutos ✓

1.3.4 Tiempo máximo de resolución de incidentes de 4 horas ✓

1.3.5 Modelo de intercambio con un único Prestador de Servicios

El Prestador de Servicios deberá cumplir con los siguientes niveles de ser-

vicio para EDI

✓

1.3.5.1 Cumplimiento anual del 99,5% de las transacciones de mensajes en un

tiempo inferior a 2,30 horas✓

1.3.5.2 Tiempo máximo de notifi cación al Emisor indicando la aceptación o recha-

zo del documento: 30 minutos ✓

1.3.5.3 Tiempo máximo de notifi cación al Receptor indicando que tiene disponi-

ble el documento: 30 minutos a partir del envío de la notifi cación enviada

al Emisor indicando la aceptación del documento

✓

1.3.5.4 Tiempo máximo de notifi cación el Emisor indicando que el Receptor tiene

disponible el documento: 2 horas y media, desde el momento en que no-

tifi có al Emisor la aceptación del mismo

✓




1 Reglas de negocio

1.3.6 Modelo de intercambio con dos Prestadores de Servicios

Los Prestadores de Servicio deberán cumplir con los siguientes niveles de

servicio para EDI

✓

1.3.6.1 Cumplimiento anual del 99,5% de las transacciones de mensajes entre

Proveedores de Servicio en un tiempo inferior a 2 horas✓

1.3.6.2 Tiempo máximo de notifi cación al Emisor a través del envío de un mensaje

homologado indicando la aceptación o rechazo del documento por parte

de PS1: 30 minutos

✓

1.3.6.3 Tiempo máximo de envío del documento a PS2 una vez que PS1 lo aceptó:

30 minutos✓

1.3.6.4 Tiempo máximo de envío de MDN por parte de PS2 hacia PS1, luego de la

transmisión del documento: 30 minutos✓

1.3.6.5 Tiempo máximo de envío de un mensaje por parte de PS2 a PS1, luego

del envío del MDN, donde se indique la aceptación o el rechazo del docu-

mento: 30 minutos

✓

1.3.6.6 Tiempo máximo de análisis del rechazo y comienzo de la retransmisión de

un documento (en caso de aplicar) desde PS1 a PS2 en aquellos casos don-

de el mensaje enviado desde PS2 a PS1 indique un rechazo: 30 minutos

✓

1.3.6.7 Tiempo máximo de notifi cación desde PS2 a PS1 indicando que el Recep-

tor tiene disponible el documento: 2 horas, desde el momento en que PS1

notifi có al Emisor la aceptación del mismo

✓

1.3.6.8 Tiempo máximo de notifi cación desde PS2 a PS1 indicando que el Recep-

tor tiene disponible el documento: 1 hora desde el momento en que PS2

notifi có a PS1 la aceptación del documento mediante un mensaje homo-

logado

✓

1.3.6.9 Tiempo máximo de notifi cación desde PS1 al Emisor indicando que el Re-

ceptor tiene disponible el documento: 2.30 horas, desde el momento en

que PS1 notifi có al Emisor de la aceptación del mensaje

✓




2 Requerimientos funcionales

2.1 Funcionalidad provista por los proveedores de servicio

La aplicación provista por los proveedores de servicio para el intercambio

de documentos electrónicos deberá proveer las siguientes funcionalida-

des para los Emisores/ Receptores

2.1.1 Soporte el idioma español si la aplicación es de uso regional/internacional ✓

2.1.2 Interfaz gráfi ca intuitiva y amigable ✓

2.1.3 Capacidad de efectuar la integración con sistemas del Emisor y/o Receptor

para el intercambio de documentos en forma automática✓

2.1.4 Las siguientes facilidades serán provistas para que el Emisor efectúe la ges-

tión de documentos:✓

2.1.4.1 Consulta a través de la aplicación de documentos enviados por el Emisor ✓

2.1.4.2 Cancelación con un mensaje homologado de documentos que han sido

enviados con anterioridad✓

2.1.4.3 Detección de documentos duplicados, es decir, que poseen el mismo

identifi cador, tipo y contenido del mensaje.✓

2.1.4.4 Capacidad de retransmisión de documentos ✓

2.1.4.5 Retención de documentos enviados ✓

2.1.4.6Administración de fl ujos de autorización de documentos, ante los casos en

un usuario carga los documentos y otro usuario los libera✓

2.1.5 Emisión de un reporte con el histórico de transacciones realizadas con do-

cumentos sobre un período de tiempo a defi nir✓




2 Requerimientos funcionales

2.2 Monitoreo de transacciones

La aplicación provista por los proveedores de servicio para el intercambio

de documentos electrónicos deberá permitir registrar y resguardar en for-

ma automática los eventos del sistema

2.2.1 Identifi cación de los eventos provenientes del sistema, incluídos pero no

limitados a: ✓

2.2.1.1 Transacciones de documentos exitosas y fallidas ✓

2.2.1.2 Retransmisión de documentos realizados ✓

2.2.1.3 Eventos/Incidencias repetitivas ✓

2.2.1.4 Time-outs ✓

2.2.1.5 Fallos en el enlace ✓

2.2.1.6 Caída del servicio y necesidad de iniciar contingencia ✓

2.2.1.7 Accesos a los registros de auditoría ✓

2.2.1.8 Inicialización de los registros de auditoría ✓

2.2.1.9 Creación y eliminación de objetos (usuarios, documentos, transacciones,

mensajes, incidentes)✓

2.2.2 Para cada uno de los eventos almacenados se registrará la siguiente infor-

mación:✓

2.2.2.1 Usuario ✓

2.2.2.2 Tipo de evento ✓

2.2.2.3 Fecha y hora ✓

2.2.2.4 Resultado (exitoso o fallido), ✓

2.2.2.5 Origen del evento, ✓

2.2.2.6 Datos o componentes afectados ✓

2.2.2.7 Motivo del error ✓

2.2.3 Los logs y registros de auditoría de la infraestrucutura que soporta EDI de-

berán retenerse durante un año✓

2.2.4 La aplicación provista deberá tener la capacidad de alertar los incidentes

del sistema✓

2.2.5 La aplicación provista deberá brindar la posibilidad de parametrizar las

alertas y tomar acciones en base a rangos fl exibles✓

2.2.6 La aplicación provista deberá tener la capacidad de defi nir acciones auto-

máticas, envío de correos, envío de sms, interacción con sistemas de repor-

te ante alertas emitidas

✓

2.2.7

La aplicación provista deberá contar con un motor de mecanismo de es-

calamiento de alertas y reportes según parámetros defi nidos en la herra-

mienta (roles, criticidad y urgencia).

✓




2.3 Reportes

Los proveedores de servicio deberán facilitar reportes a fi nes de proveer

trazabilidad de los documentos enviados y facilitar la gestión durante el

proceso de intercambio

2.3.1 Reportes online/batch parametrizables para los Emisores (por usuario, do-

cumento, estándar, receptor, proveedor de servicio, fecha, tipo de docu-

mento):

✓

2.3.1.1 Tiempos de respuesta ✓

2.3.1.2 Cantidad de transacciones (exitosas, fallidas, reversas) ✓

2.3.1.3 Incidencias/eventos mencionados en la sección de monitoreo ✓

2.3.1.4 Tipos de transacciones ✓

2.3.1.5 Acceso a reportes a través de interfaz web, según niveles de autorización

defi nidos en el módulo de administración de usuarios y roles.

✓

2.3.2 Reportes online/batch parametrizables para GS1 (por estándar, fecha y

tipo de documento):

✓

2.3.2.1 Cantidad de transacciones (exitosas, fallidas, reversas) ✓

2.3.3 Envío de reportes en diferentes tipos de medio (HTML, PDF, XLS) ✓

2.3.4 Capacidad de almacenar datos históricos que posibiliten generar

estadísticas

✓

2.4 Documentación

Los proveedores de servicio deberán poseer la siguiente documentación

actualizada y revisada por el personal correspondiente

2.4.1 Manual de Operación ✓

2.4.2 Manual de Usuarios ✓

2.4.3 Manual de Administración ✓




3 Requerimientos técnicos

3.1 Contingencia

3.1.1 Los proveedores de servicio deberán tener defi nida y documentada una

estrategia de contingencia donde se defi na el plan de acción a seguir para

disponibilizar el servicio en el menor tiempo posible tolerable (incluyendo

la provisión del servicio por otro PS)

✓

3.2 Escalabilidad, parametrización y mantenimiento

3.2.1 La aplicación que soporta el intercambio electrónico de datos debe estar

completamente diseñada y segmentada por módulos

✓

3.2.2 La arquitectura de la solución EDI debe ser multicapa: Separación de capas

de base de datos, reglas de negocio e interfaz de usuario en capas inde-

pendientes que interactuen entre sí

✓

3.3 Alta disponibilidad y tolerancia a fallos

3.3.1 Las plataformas de hardware que darán soporte al sistema deben disponer

de un esquema de alta disponibilidad de procesamiento y una arquitectu-

ra tolerante a fallos, con balanceo de carga.

✓

3.4 Arquitectura de la solución

3.4.1 Segmentación en capas ✓

3.4.2 Utilización del protocolo AS2 para la comunicación entre proveedores de

servicio

✓

3.4.3 Utilización de mecanismos de cifrado robustos y protocolos de seguridad

(por ejemplo, SSL/TLS, IPSEC, SSH, etc.) para proteger los documentos du-

rante la transmisión por redes públicas abiertas.

Ejemplos de redes públicas abiertas incluyen, pero no se limitan a:

- Internet

- Tecnologías inalámbricas

- Sistema global para comunicaciones móviles (GSM)

- Servicio de radio paquete general (GPRS)

✓

3.4.5 Aplicación web en una DMZ ✓

3.4.6 Capa de datos en la red interna ✓

3.4.7 Existencia de un fi rewall en cada conexión a Internet y entre cualquier

zona desmilitarizada (DMZ) y la zona de la red interna

✓

3.4.8 Utilización de sistemas de detección y/o prevención de intrusiones para

supervisar el tráfi co y alertar al personal ante la sospecha de riesgos

✓

3.4.9 Infraestructura EDI segmentada física o lógicamente del resto de la red ✓




4 Requerimientos de operación

4.1 Procesos y procedimientos

Los proveedores de servicio deberán defi nir e implementar normas y pro-

cedimientos de seguridad, que abarquen los aspectos defi nidos en los

puntos siguientes

4.1.1 Procedimiento de Gestión de incidentes ✓

4.1.1.1 Deberán estar defi nidos los roles y responsabilidades respecto de la ges-

tión de incidentes con respecto al proceso de EDI

✓

4.1.1.2 Todos los incidentes generados deberán ser registrados y tipifi cados en

forma inicial identifi cando: usuario, emisor, receptor, PS1, PS2, fecha de de-

tección, responsable.

✓

4.1.1.3 Los incidentes reportados deberán ser resueltos en un período no mayor a

4 horas y deberán escalarse en caso de ser necesario

✓

4.1.1.4 Los incidentes deberán cerrarse con la aprobación de todas las partes in-

volucradas

✓

4.1.1.5 El responsable del incidente deberá resguardar y registrar la documenta-

ción correspondiente al caso

✓

4.1.2 Proceso de gestión de vulnerabilidades sobre la infraestructura de la so-

lución EDI

✓

4.1.2.1 Pruebas de ethical hacking internas en forma semestral o ante cambios en

la infraestructura

✓

4.1.2.2 Pruebas de ethical hacking externas en forma semestral o ante cambios

en la infraestructura

✓

4.1.2.3 Pruebas de ethical hacking sobre app web en forma anual o ante cambios

en las aplicaciones

✓

4.1.2.4 Aplicación de últimos parches de seguridad publicados y homologados

por los proveedores sobre la infraestructura que soporta EDI

✓

4.1.3 Procedimiento de gestión de claves criptográfi cas y certifi cados digitales ✓

4.1.3.1 Almacenamiento de claves criptográfi cas en forma segura (por ejemplo,

en medios portátiles protegidos adecuadamente con controles sólidos de

acceso).

✓

4.1.3.2 Acceso a claves restringido a la menor cantidad de custodios necesaria ✓

4.1.3.3 Conocimiento dividido y control dual de claves generadas manualmente ✓

4.1.3.4 Defi nición de proceso de cambio y rotación de claves ante divulgación o

compromiso de las mismas

✓

4.1.3.5 Utilización de un CA reconocido para la generación de certifi cados digi-

tales

✓

4.1.3.6 Defi nición de un procedimiento de intercambio seguro de certifi cados

con otros proveedores de servicio

✓

4.1.3.7 Defi nición de proceso para la revocación y renovación de certifi cados

digitales

✓





4.1.4 Procedimientos básicos de operaciones de seguridad ✓

4.1.4.1 Administración de reglas de fi rewall ✓

4.1.4.1.1 Defi nición de roles y responsabilidades para la administración del fi rewall ✓

4.1.4.1.2 Procedimiento que establezca la aprobación formal para efectuar el alta,

baja y modifi cación de reglas de fi rewall

✓

4.1.4.1.3 Revisión semestral de reglas de fi rewall para determinar la corresponden-

cia de las mismas y tomar las acciones pertinentes

✓

4.1.4.2 Revisión de confi guración de plataformas ✓

4.1.4.2.1 Defi nición de roles y responsabilidades para revisar la confi guración de se-

guridad de las plataformas

✓

4.1.4.2.2 Proceso formal de revisión semestral de los equipos que forman parte de la

infraestructura EDI a fi nes de verifi car que se encuentren implementados

los estándares de seguridad defi nidos en la sección “Hardenning”

✓

4.1.4.3 Gestión de usuarios ✓

4.1.4.3.1 Procedimiento que establezca la aprobación formal para efectuar el alta,

baja y modifi cación de usuarios en los sistemas y donde se asegure que

los usuarios poseen asignados únicamente los privilegios necesarios para

efectuar sus tareas diarias

✓

4.1.4.3.2 Procedimiento formal semestral de certifi cación de accesos, donde el due-

ño de los sistemas verifi que si es correcta la relación entre los usuarios que

poseen acceso y los privilegios que tienen asignados

✓

4.1.4.3.3 Procedimiento formal semanal para bloquear los usuarios que no ingresan

al sistema por un período mayor a 90 días

✓

4.1.4.3.4 Procedimiento de administración de usuarios de máximos privilegios, a

fi nes de resguardar en forma segura las contraseñas y evitar su utilización

✓

4.1.4.4 Antivirus y antispam ✓

4.1.4.4.1 Implementación de software antivirus en todos los sistemas que confor-

man la infraestructura EDI (en especial, computadoras personales y ser-

vidores)

✓

4.1.4.4.2 Actualización diaria de las fi rmas de antivirus ✓

4.1.4.4.3 Ejecución automática de software antivirus y realización de escaneos pe-

riódicos

✓

4.1.4.4.4 Implementación de antispam y antispyware para detectar amenazas y vi-

rus provenientes del correo e internet

✓





4.1.4.5 Copias de seguridad ✓

4.1.4.5.1 Procedimiento formal para la gestión de copias de seguridad que contem-

ple la identifi cación del soporte e información que contiene

✓

4.1.4.5.2 Almacenamiento de las copias de seguridad en ambientes controlados y

seguros (Ver sección “Seguridad física”)

✓

4.1.4.5.3 Autorización para la entrada y salida de la ubicación principal y registro de

movimientos de copias de seguridad

✓

4.1.4.5.4 Implementación de mecanismos de destrucción segura de la información

en desuso o de medios obsoletos

✓

4.1.4.6 Control de cambios en los sistemas ✓

4.1.4.6.1 Existencia de segregación física de ambientes de desarrollo, prueba y pro-

ducción relacionada con la infraestructura EDI

✓

4.1.4.6.2 Segregación lógica de accesos entre los usuarios desarrolladores y los

usuarios que acceden a ambientes de prueba y producción

✓

4.1.4.6.3 Ofuscación de datos productivos en ambientes bajos, tales como prueba

y/o desarrollo

✓

4.1.4.6.4 Proceso formal establecido para que los cambios a los códigos de las apli-

caciones sean revisados por individuos distintos al autor que originó el có-

digo y por individuos con conocimiento en técnicas de revisión de código

y prácticas de codifi cación segura

✓

4.1.4.6.5 Revisión y aprobación por un responsable de los resultados de la revisión

de código antes de la implementación en producción

✓

4.1.4.6.6 Desarrollo de aplicaciones web siguiendo los lineamientos de las mejores

prácticas de seguridad, por ejemplo OWASP.

✓

4.1.4.7 Revisión de eventos de seguridad ✓

4.1.4.7.1 Defi nición de roles y responsabilidades con respecto a la revisión de los

logs y registros de eventos de seguridad

✓

4.1.4.7.2 Resguardo de logs de auditoría en repositorio con acceso restringido para

evitar su eliminación y /o modifi cación

✓

4.1.4.7.3 Proceso formal de revisión periódica de eventos de seguridad ✓

4.2 Soporte y atención

Los proveedores de servicio deberán proveer de un esquema para

brindar soporte y atención a otros proveedores de servicio, emiso-

res y/o receptores

✓

4.2.1 Soporte de mesa de ayuda 7x24x365 ✓

4.2.2 Mecanismo de soporte defi nido y publicado, ya sea mediante tickets, te-

lefónico u on site

✓

4.2.3 Cobertura regional del soporte e idiomas de atención adecuados ✓





4.3 Cumplimiento contractual y regulatorio

4.3.1 Non-disclosure agreement entre Proveedores de Servicio ✓

4.3.2 Autorización formal para operar entre Emisores y Proveedores de Servicio

2 (PS2)

✓

4.3.3 Homologación formal anual de proveedores de servicio por GS1 ✓

4.3.3.1 Listado de proveedores homologados disponibles para la consulta a través

de la página web de GS1

✓

4.3.3.2 Ante incumplimientos, los PS deberán confeccionar un plan de remedia-

ción y validarlo con GS1 para continuar operando

✓




5 Seguridad

5.1 Administración segura

La aplicación que soporta el proceso de intercambio de documentos elec-

trónicos deberá poseer un esquema de administración segura

5.1.1 Identifi cación de usuarios ✓

5.1.1.1 No permite identifi cadores de usuario repetidos dentro de la misma com-

pañía

✓

5.1.1.2 Valida que el identifi cador de usuario no esté asociado a información pú-

blica de la compañía o del propio usuario

✓

5.1.1.3 No se utilizan usuarios genéricos o compartidos dentro de la compañía ✓

5.1.2 Autenticación ✓

5.1.2.1 Enmascara datos confi denciales visualizados en pantalla, por ejemplo,

contraseñas

✓

5.1.2.2 Los mensajes de error generados en forma posterior a la autenticación, son

genéricos para no permitir enumeración de cuentas

✓

5.1.2.3 Todos los formularios públicos que permiten el envío de datos requieren

el ingreso de un Captcha

✓

5.1.2.4 Los gráfi cos asignados a los caracteres del Captcha son aleatorios ✓

5.1.3 Política de contraseñas y bloqueo de cuentas ✓

5.1.3.1 Permite defi nir una longitud mímina a la contraseña ✓

5.1.3.2 Permite defi nir complejidad en la composición de la contraseña ✓

5.1.3.3 Permite defi nir el bloqueo de la cuenta ante intentos de accesos fallidos ✓

5.1.3.4 Permite defi nir un historial de contraseñas utilizadas ✓

5.1.3.5 Permite defi nir el tiempo máximo de uso de una contraseña luego del cual

se fuerza el cambio de la misma

✓

5.1.3.6 Permite defi nir el tiempo mínimo de uso de una contraseña antes del cual

no se permite el cambio de la misma

✓

5.1.3.7 Permite defi nir el mecanismo de desbloqueo de una cuenta (automático

- manual)

✓




5 Seguridad

5.1.4 Cambio de contraseña ✓

5.1.4.1 Valida en forma previa la contraseña anterior y luego ingresa la nueva con-

traseña

✓

5.1.5 Reestablecimiento de contraseña ✓

5.1.5.1 Debe validar que el identifi cador de usuario sea válido ✓

5.1.5.2 Debe validar la nueva contraseña de un único uso al email registrado por

el usuario

✓

5.1.6 Almacenamiento, transmisión y encripción de datos sensibles ✓

5.1.6.1 Los identifi cadores de usuario y las contraseñas no son transferidas en tex-

to plano entre los diferentes componentes de la aplicación

✓

5.1.6.2 Las contraseñas no son almacenadas en texto plano ✓

5.1.6.3 Las contraseñas no son manipuladas en el código de la aplicación ✓

5.1.6.4 Las contraseñas no son enviadas al usuario en ningún momento ✓

5.1.6.5 Los documentos no son almacenados en la aplicación en texto plano ✓

5.1.6.6 La transmisión de datos mediante el protocolo AS2 debe implementarse

con HTTPS y con la utilización de fi rma digital (integridad y no repudio)

✓

5.1.7 Administración de usuarios del portal ✓

5.1.7.1 El esquema de autorización utilizado se encuentra basado en un sistema

de control de acceso basado en roles (RBAC, role based access control)

✓

5.1.7.2 El esquema de autorización permite defi nir privilegios hasta el nivel de ac-

ción que administre el sistema (por ejemplo: formulario, reporte, punto de

menú, código de acción)

✓

5.1.7.3 El sistema de control de acceso basado en roles soporta roles predefi nidos ✓




5 Seguridad

5.2 Arquitectura de seguridad

5.2.1 Autenticación ✓

5.2.1.1 Los controles de autenticación son realizados en el servidor y no en el

cliente

✓

5.2.1.2 Todos los controles de autorización y autenticación son implementados

de manera centralizada, es decir, existe un único módulo de autenticación

dentro de la aplicación

✓

5.2.1.3 La aplicación falla de manera segura: ante la ocurrencia de errores o excep-

ciones no contempladas por la aplicación, la misma cierra todas la sesiones

del usuario, muestra errores controlados, fi naliza transacciones en curso de

manera controlada y requiere re-autenticación para continuar la operación

✓

5.2.1.4 El portal web no permite el acceso concurrente de una cuenta de usuario ✓

5.2.2 Modelo de capas ✓

5.2.2.1 Es posible segmentar la arquitectura del portal como mínimo en tres ca-

pas: presentación, lógica de negocio y base de datos

✓

5.2.2.2 No es posible la comunicación directa entre la capa de presentación y la

capa de base de datos

✓

5.2.2.3 Las consultas a la base de datos están encapsuladas a través de store pro-

cedures defi nidos por el DBA

✓

5.2.3 Manejo de errores ✓

5.2.3.1 Los mensajes de error o traces no brindan información de los componen-

tes de la arquitectura ni datos del usuario

✓

5.2.3.2 Los mensajes de error son gestionados del lado del servidor ✓

5.2.3.3 Ante el acceso al contenido del servidor por dirección IP, la aplicación en-

via un mensaje de error

✓

5.2.3.4 El código de la aplicación no permite que la página web esté incrustada

dentro de un frame

✓




5 Seguridad

5.3 Protección de datos

5.3.1 Controles para documentos procesados ✓

5.3.1.1 El código fuente de todas las páginas web que contienen campos de con-

traseñas no poseen habilitada la función de “Autocomplete”

✓

5.3.1.2 La aplicación no almacena en la caché datos sensibles, como nombres de

usuario y contraseñas

✓

5.3.1.3 Los archivos temporales enviados al cliente por la aplicación, no pueden

ser accedidos de forma pública y son eliminados luego de su utilización

✓

5.3.1.4 La aplicación no muestra información sensitiva dentro del código fuente ✓

5.3.1.5 Todas las “Operaciones” privadas o que formen parte de un flujo de

operación, son accedidas únicamente por usuarios que se encuentran

autenticados

✓

5.3.2 Validación de datos de entrada ✓

5.3.2.1 El código fuente de la aplicación restringe el tipo de archivos que pueden

ser cargados en el sitio

✓

5.3.2.2 El código fuente de la aplicación no permite la reescritura de archivos que

han sido cargados desde el sitio web

✓

5.3.2.3 La validación de los datos de entrada es realizada por el servidor

de aplicación

✓

5.3.2.4 La aplicación no es susceptible a buff er overfl ows ✓

5.3.2.5 El servidor debe efectuar la validación de los parámetros recibidos por los

formularios de la aplicación

✓

5.3.2.6 La aplicación verifi ca todos los datos ingresados por parte del usuario, va-

lidando su tipo y verifi cando que se reciban las longitudes / cantidades de

caracteres esperados

✓

5.3.2.7 La aplicación verifi ca las credenciales del usuario, antes de permitir la carga

o descarga de archivos

✓




5 Seguridad

5.4 Hardenning

5.4.1 Defi nición de estándares de confi guración sistemas operativos, bases de

datos y equipos de comunicaciones de la arquitectura EDI basados en me-

jores prácticas, que involucren como mínimo:

✓

5.4.1.1 Política de contraseñas y bloqueo de cuentas ✓

5.4.1.2 Política de auditoría ✓

5.4.1.3 Asignación de permisos basada en el principio del “menor privilegio” ✓

5.4.1.4 Bloqueo de sesiones por tiempo de inactividad ✓

5.4.1.5 Cambio de contraseñas por defecto ✓

5.4.1.6 Utilización de usuarios personalizados, no genéricos ✓

5.4.1.7 Utilización de servicios seguros ✓

5.4.1.8 Utilización de software antivirus ✓

5.4.1.9 Implementación de actualizaciones de seguridad ✓

5.4.2 Implementación de los estándares sobre la arquitectura EDI ✓

5.5 Seguridad física

La infraestructura que soporta el intercambio de documentos electróni-

cos deberá estar en un lugar protegido contra el acceso no autorizado y

con controles ambientales adecuados para asegurar la disponibilidad del

servicio

5.5.1 Control de acceso físico ✓

5.5.1.1 Autorización formal y logs de acceso al Centro de procesamiento de datos

(CPD)

✓

5.5.1.2 Mecanismo de control de acceso implementado (llave, tarjeta, pin, dispo-

sitivo biométrico)

✓

5.5.1.3 Control de acceso a terceros ✓

5.5.1.4 Cámaras de video para monitoreo ✓

5.5.1.5 Puertas y ventanas blindadas ✓

5.5.2 Monitoreo ambiental ✓

5.5.2.1 Sensores de humedad ✓

5.5.2.2 Sensores de humo ✓

5.5.2.3 Termómetro ✓

5.5.2.4 Aire acondicionado ✓

5.5.2.5 Sistema de extinción de incendios ✓

5.5.3 Suministro eléctrico ✓

5.5.3.1 Grupo electrógeno ✓

5.5.3.2 UPS ✓

5.5.4 Red ✓

5.5.4.1 Los puntos de acceso de la red se encuentran inhabilitados o se efectúa

validación antes de permitir acceso (por ej, por MAC)

✓



Anexo II

Diagrama de Secuencia y Reglas de Servicio

Se describe a continuación el Diagrama de Secuencia y las Reglas de Servicio a cumplir por los Prestadores de Servicio

EDI. En este caso también se pondrá a disposición un archivo con el mismo contenido en la página de GS1 Argentina.

1. Introducción

Contexto y objetivo

El presente Anexo tiene por objetivo defi nir el diagrama de secuencia del proceso de intercambio de documentos elec-

trónicos bajo los siguientes modelos:

■ Intercambio de documentos electrónicos donde interviene un único Prestador de Servicios.

■ Interoperabilidad, donde intervienen dos Prestadores de Servicios para el intercambio de documentos electrónicos.

Para efectuar esta tarea se han tomado como punto de partida los requerimientos globales del Sector de Consumo Ma-

sivo, consolidados en la propuesta presentada oportunamente por los propios Prestadores de Servicio EDI a GS1.

Las premisas consideradas para defi nir el proceso de interoperabilidad se detallan a continuación:

1. Todos los proveedores de servicio homologados por GS1 deben interconectarse con aquellas contrapartes que,

estando también homologadas por GS1, dispongan de un proyecto concreto de intercambio de documentos

electrónicos.

2. Todos los documentos intercambiados deben encontrarse homologados en el estándar de GS1.

3. El proceso debe garantizar seguridad y privacidad.

4. La transmisión de documentos entre partes deberá cumplir con el nivel de servicio defi nido.

5. La trazabilidad de los documentos deberá asegurarse durante todo el circuito de intercambio.

6. Para todos los mensajes que sean entregados, se deberá recibir un mensaje de confi rmación de recepción.

7. Todo intercambio de mensajes no deberá superar los tiempos máximos defi nidos.

8. El servicio estará disponible en un esquema 24x7x365.

9. Los niveles de servicio serán aplicables tanto cuando interactúen dos prestadores de servicio o uno solo.

10. El tiempo de respuesta por parte del Receptor, una vez que el mensaje ha sido entregado, dependerá del Acuerdo que

se encuentre establecido entre el Receptor y el Emisor.

11. Los proveedores de servicio serán homologados técnicamente por GS1.



2. Diagrama de Secuencia

Modelo de servicio EDI con un único Prestador de Servicio

A continuación se presenta el diagrama de secuencia propuesto para el intercambio de documentos electrónicos donde

interactúa un único Prestador de Servicios.

En este diagrama se encuentra el detalle de los mensajes intercambiados entre las partes y los tiempos de respuesta

máximos propuestos para la entrega y confi rmación de los mismos.

Documento

Documento

CONTRL

CONTRL

CONTRL

CONTRL

CONTRL

Notificación

disponibilidad del

mensaje

(e-mail, portal,

interface directa)

Mensajes optativos

(Puesta a disposición del

Receptor)

(Documento formado por

Receptor)

(Aceptación o Rechazo)

EMISORRECEPTOR PRESTADOR 1

30´

30´

2.30 hs.

30´

30´

30´

Referencias



Modelo de servicio EDI con dos Prestadores de Servicio

A continuación se puede visualizar el esquema general de interoperabilidad entre Prestadores de Servicio y los tiempos

de respuesta máximos propuestos para la entrega y confi rmación de mensajes.

Documento

CONTRL

Notificación

disponibilidad

del mensaje

(e-mail, portal,

interface

directa)

EMISORRECEPTOR PRESTADOR 1PRESTADOR 2

2 hs. 2.30 hs.

30´

30´

30´

30´

1 h

30´

30´

30´

30´

Mensajes optativos

Referencias

APERAK (Aceptación o Rechazo)

CONTRL (Notificación disponibilidad)

CONTRL (Msj tomado por Receptor)

CONTRL (Aceptación o Rechazo)

AS2 MDN

Documento

Documento

CONTRL

CONTRL

CONTRL

CONTRL

30´

30´



Detalle del Diagrama de Secuencia

A continuación se procederán a describir en forma detallada las actividades y los tiempos de respuesta máximos durante

todo el circuito de intercambio de mensajes donde intervienen dos Prestadores de Servicio, tomando como referencia el

Diagrama de Secuencia presentado en la sección anterior.

Paso 1

El Emisor transmite un mensaje, denominado en este esquema “documento”, al Prestador de Servicios 1 (en adelante, PS1)

El documento deberá respetar los estándares homologados por GS1.

Documento

EMISORPRESTADOR 1

CONTRL

EMISORPRESTADOR 1

Paso 2

PS1 recibe el documento y valida el formato y contenido del mismo.

Luego de dicha validación, PS1 envía al Emisor un mensaje “CONTRL”, indicando la aceptación o rechazo del documento.

Si el documento fuera rechazado, PS1 deberá indicar en el mensaje “CONTRL” el motivo del error.

PS1 deberá enviar el mensaje “CONTRL” al Emisor dentro de los 30 minutos de recibido el documento.



EMISORPRESTADOR 1PRESTADOR 2

CONTRL

Documento

Emitiralarma

SI

>30´

CONTRL

EMISORPRESTADOR 1

Documento

SI

Emitiralarma

Emitiralarma

>30´

Paso 3

El Emisor recibe el mensaje “CONTRL” desde el PS1 y evalúa si el mensaje fue aceptado o no.

Si el mensaje “CONTRL” estuviera rechazado, el Emisor podrá retransmitir el documento de acuerdo a los motivos de error

informados y se iniciará el intercambio de mensajes desde el Paso 1.

El emisor deberá controlar que no transcurran más de 30 minutos desde que ha enviado el documento hasta que PS1

responde con el mensaje “CONTRL”. Si transcurrieran más de 30 minutos, el Emisor deberá emitir una alarma.

Paso 4

PS1 envía el documento al Prestador de Servicios 2 (en adelante, PS2), utilizando el protocolo AS2.

Esta transmisión deberá efectuarse antes de transcurridos 30 minutos desde el momento en que PS1 envió el mensaje

“CONTRL” al Emisor indicando la aceptación.



AS2 MDN

APERAK

PRESTADOR 2 PRESTADOR 1

Documento

SI

Emitiralarma

Emitiralarma

>30´

AS2 MDN


Documento

SI

Emitiralarma

Emitiralarma

>30´

Paso 5

PS2 recibe el documento enviado por PS1. Al recibirlo, si bien PS2 no realiza validaciones de reglas de negocio, valida la

integridad del mensaje, que esté fi rmado digitalmente por PS1 y que el destino del documento sea un Receptor con el

cual opera.

PS2 envía un “Message Delivery Notifi cation” (en adelante, MDN) a PS1 notifi cando la recepción del documento. PS2 debe

enviar el “MDN” antes de transcurridos los 30 minutos desde que recibió el documento por parte de PS1.

Ante el caso que no se cumpla el tiempo previsto PS1 emitirá una alarma.

Paso 6

Luego del envío del “MDN”, PS2 envía un mensaje “APERAK”, indicando la aceptación o el rechazo del documento.

Este mensaje debe ser enviado por PS2 en un tiempo máximo de 30 minutos desde el envío del mensaje “MDN”, caso

contrario PS1 podrá emitir una alarma.



PRESTADOR 1PRESTADOR 2RECEPTOR

APERAK

Emitiralarma

SI

Notificación

disponibilidad

del mensaje

(e-mail, portal,

interface

directa)

>30´

AS2 MDN

APERAK


Documento

SI

Rechazo?

Retransmisión -Paso 4

Paso 7

PS1 recibe el mensaje “APERAK” por parte de PS2 y analiza si el documento fue aceptado o rechazado.

Si el documento fuese rechazado debido a la ocurrencia de errores durante la transmisión o bien, porque el destinatario

del mismo no era PS2 o un Receptor con el cuál éste interactúe; PS1 deberá retransmitir el documento en un período

máximo de 30 minutos desde que recibe el mensaje “APERAK”, retornando al Paso 4.

Paso 8

Una vez que PS2 ha recibido el documento, debe notifi car al Receptor la disponibilidad del mismo a través de los me-

canismos establecidos previamente entre ambos, los cuales podrán ser: envío de mails, notifi cación en el portal de PS2,

ERP del Receptor, entre otros.

PS2 no deberá demorar más de 30 minutos desde que envió el mensaje “APERAK” de aceptación del documento PS1

hasta que notifi ca al Receptor la disponibilidad del mismo.




Notificación

disponibilidad

del mensaje

(e-mail, portal,

interface

directa)

APERAK

CONTRL

AS2 MDN

Documento

Emitiralarma

OR

>2 hs

>1 h

Paso 9

Una vez notifi cado el Receptor, PS2 le envía a PS1 un mensaje “CONTRL”, indicando que el documento se puso a disposi-

ción del Receptor.

PS1 deberá recibir este mensaje en un lapso de no más de 2 horas a partir del momento en que efectuó la transmisión

del documento hacia PS2 (Paso 4), o de no más de 1 hora a partir del momento en que PS1 recibió el mensaje “APERAK”

de PS2 indicando la aceptación del documento (Paso 6). En caso de que alguna de las condiciones no se cumplan, PS1

deberá emitir una alarma.




<30´

Notificación

Documento

CONTRL

Mensajes optativos

Referencias

PRESTADOR 1PRESTADOR 2 EMISOR

<30´CONTRL

CONTRL

Paso 11

Una vez que PS1 recibe el mensaje “CONTRL” por parte de PS2 indicando que el Receptor levantó el documento, PS1

debería notifi car al Emisor.

A fi nes de notifi car al Emisor, PS1 le envía un nuevo mensaje “CONTRL”. No deberán transcurrir más de 30 minutos desde

que PS1 recibió el mensaje de “CONTRL” por parte de PS2 hasta que PS1 notifi ca al Emisor que el documento fue levan-

tado por el Receptor.

A partir del Paso 10 los mensajes serán intercambiados de forma optativa, según lo establezcan el acuerdo entre

Emisores, Receptores y Prestadores de Servicio.

Paso 10

En el momento en que PS2 detecta que el Receptor levantó el documento, PS2 podrá enviar un mensaje “CONTROL” a

PS1 notifi cando esta situación.

No deberían transcurrir más de 30 minutos entre que el Receptor levanta el documento, y PS2 notifi ca a PS1 de esta situación.



PRESTADOR 2RECEPTOR

Notificación

Documento

CONTRL

Mensajes optativos

Referencias


<30´CONTRL

CONTRL

Paso 12

Una vez que recibe el documento, el Receptor deberá tener la posibilidad de enviar un mensaje “CONTRL” a PS2 para

indicar la recepción del mismo.

El plazo que posee el Receptor para enviar este mensaje deberá responder a los tiempos acordados con el Emisor.

Paso 13

PS2, luego de recibir el mensaje “CONTRL” con la confi rmación de recepción del documento por parte del Receptor, de-

berá enviarlo a PS1 en un tiempo máximo de 30 minutos.



PRESTADOR 1PRESTADOR 2 EMISOR

<30´SLACONTRL

CONTRL

Paso 14

Finalmente, una vez que PS1 recibe el mensaje “CONTRL” desde PS2, debería reenviarlo al Emisor notifi cándole la confi r-

mación de recepción del documento por parte del Receptor.

PS1 debería transmitir el documento al Emisor en un lapso inferior a 30 minutos.

El Emisor posteriormente evaluará si el tiempo de respuesta por parte del Receptor cumple con el nivel de servicio acor-

dado previamente entre ellos.



Anexo III

Estándares y documentos vigentes para homologar

APERAK - Application error and acknowledgement message / EANCOM® 2002 S4 - Edition 2010

App Rec Ack - Application Receipt Acknowledgement / GS1 XML 2.6.0

CONTRL - Syntax and service report message / EANCOM® 2002 S4 - Edition 2010

DESADV - Despatch advice message / EANCOM® 2002 S4 - Edition 2010

Despatch Advice / GS1 XML 2.5.0

INVOIC - Invoice message / EANCOM® 2002 S4 - Edition 2008

Invoice / GS1 XML 2.6.0

ORDERS - Purchase order message / EANCOM® 2002 S4 - Edition 2008

Order / GS1 XML 2.5.0

ORDRSP - Purchase order response message / EANCOM® 2002 S4 - Edition 2008

Order Response / GS1 XML 2.5.0

RECADV - Receiving Advice message / EANCOM® 2002 S4 - Edition 2008

Receiving Advice / GS1 XML 2.5.0

REMADV - Remittance advice message / EANCOM® 2002 S4 - Edition 2010

Settlement / GS1 XML 2.3.0

RETANN - Announcement for returns message / EANCOM® 2002 S4 - Edition 2008

(La versión XML de RETANN se implementó localmente con Despatch Advice)

Los Prestadores de Servicios EDI, podrán sin embargo homologar otros documentos aquí no contempla-dos, así como nuevas versiones de los mencionados.



Anexo V

Información del Prestador de Servicios EDI

1. Favor de completar:

Denominación Social: .................................................... ...........................................................................................................................

CUIT: ......................................................................................................................................................................................................................

GLN: . .....................................................................................................................................................................................................................

Domicilio legal: . .............................................................................................................................................................................................

Localidad: ..........................................................................................................................................................................................................

Provincia: . ..........................................................................................................................................................................................................

País: . ......................................................................................................................................................................................................................

Código Postal: .................................................................................................................................................................................................

Teléfonos: ..........................................................................................................................................................................................................

Fax: ........................................................................................................................................................................................................................

E-mail: . .................................................................................................................................................................................................................

Web: . .....................................................................................................................................................................................................................

Presidente: ........................................................................................................................................................................................................

e-mail: ..................................................................................................................................................................................................................

Director o Gerente General: ...................................................................................................................................................................

e-mail: ..................................................................................................................................................................................................................

Apoderado: ......................................................................................................................................................................................................

e-mail: ..................................................................................................................................................................................................................

Resp. / Gerente Comercial: .....................................................................................................................................................................

e-mail: ..................................................................................................................................................................................................................

Resp. / Gerente de Sistemas: .................................................................................................................................................................

e-mail: ..................................................................................................................................................................................................................

Otros:

(Nombre y cargo): ........................................................................................................................................................................................

e-mail: ..................................................................................................................................................................................................................

(Nombre y cargo): ........................................................................................................................................................................................

e-mail: ..................................................................................................................................................................................................................



Carta de Adhesión

Por la presente nos dirigimos a GS1 Argentina para manifestarle nuestro deseo de participar del vigente

proceso de Homologación de Prestadores de Servicio EDI, prestando conformidad con todo lo expresa-

do en el correspondiente Manual.

Solicitamos efectuar en lo posible la Entrevista de Verifi cación en fecha específi ca a confi rmar, durante la

semana del .......... al .......... de ........................... del año ................

Fecha: .............................................................................................................................................

Empresa: .......................................................................................................................................

Firma: ..............................................................................................................................................

Aclaración: ...................................................................................................................................

DNI: ..................................................................................................................................................

Cargo: .............................................................................................................................................



Anexo V

Modelo de Informe Mensual

Prestador Homologado

VOLUMEN DE DOCUMENTOS EMITIDOS - AÑO 2012

Tipo

documento

ENERO FEBRERO MARZO ABRIL MAYO JUNIO JULIO AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE

ORDERS

ORDRSP

DESADV

RECADV

INVOICE

REMADV



Anexo VI

Modelos de Constancias

VERIFIC ACIÓN DE DOCUMENTO EDI

Por el presente avalamos que el Prestador de Servicio EDI:

....................................................................................................................................................

Ciudad Autónoma de Buenos Aires, Argentina

ha cumplido exitosamente el Proceso de Verifi cación

para el documento electrónico

Despatch Advice

correspondiente al estándar

GS1 EANCOM® 2002 – Syntax Version 4 – Edition 2008

Constancia Nº: xxx20120320001

(válida sólo si está vigente paralelamente la Homologación como Prestador de Servicio)

Fecha de Homologación: 20 de Marzo de 2012

Fecha de Caducidad: 19 de Marzo de 2013

Emitido por:

Este documento está sujeto a los términos y condiciones indicadas en el Manual para la Homologación de Prestadores de Servicios EDI

La Homologación está condicionada a que se mantengan los cumplimientos evaluados en el Proceso respectivo.



CONSTANCIA DE HOMOLOGACION

Por el presente avalamos que el Prestador de Servicio EDI:

....................................................................................................................................................

Ciudad Autónoma de Buenos Aires, Argentina

ha cumplido exitosamente el Proceso de Verifi cación

como

Prestador de Servicio EDI

correspondiente a los requerimientos del

Manual de Homologación de Prestadores de Servicio EDI

Constancia Nº: xxx20120320001

Fecha de Homologación: 20 de Marzo de 2012

Fecha de Caducidad: 19 de Marzo de 2013

Emitido por:

Este documento está sujeto a los términos y condiciones indicadas en el Manual para la Homologación de Prestadores de Servicios EDI

La Homologación está condicionada a que se mantengan los cumplimientos evaluados en el Proceso respectivo.



Fraga 1326C1427BUB, Ciudad de Buenos AiresArgentinaT (54-11) 4556 4700F (54-11) 4556 4740E [email protected]

www.gs1.org.ar

homologación prestadores edi - gs1 argentina · manual para la homologación de prestadores de...

Documents