Estudio Resultado Pruebas Piloto PS v3.1

download Estudio Resultado Pruebas Piloto PS v3.1

of 53

Transcript of Estudio Resultado Pruebas Piloto PS v3.1

Estudio de Resultado Pruebas Piloto Payment Slip

Elaborado por: Giselle Rosario & Eduardo Nez AMECE - GS1 Mxico

NDICE1. Introduccin .......................................................................................................................................... 3 1.1 Payment Slip .............................................................................................................................. 3 1.2 Prueba Piloto ............................................................................................................................. 4 2. Alcance .................................................................................................................................................. 4 Emisores ................................................................................................................................................ 4 Receptores ............................................................................................................................................ 6 3. Antecedentes de la Prueba Piloto ....................................................................................................... 10 4. Metodologa ........................................................................................................................................ 10 5. Desarrollo ............................................................................................................................................ 11 5.1 Estndar Taln de Pagos ............................................................................................................... 11 5.2 Etapas de las Pruebas.................................................................................................................... 18 Etapa 1. Definicin del Layout del Cdigo & NPE ............................................................................... 18 Etapa 2. Generacin del Cdigo de Barras & NPE............................................................................... 24 Etapa 3. Decodificar y leer el Cdigo de Barras GS1 128 Captura del NPE ...................................... 25 Etapa 4. Desarrollar aplicacin ........................................................................................................... 26 Etapa 5. Generar reporte .................................................................................................................... 30 CONCLUSIONES ....................................................................................................................................... 31 ANEXO 1 .................................................................................................................................................. 33 ANEXO 2 .................................................................................................................................................. 35 ANEXO 3 .................................................................................................................................................. 43

1. IntroduccinEste documento tiene la intencin de dar a conocer el proceso llevado a cabo para el desarrollo de las pruebas piloto con relacin a la definicin del estndar Payment Slip para el mercado mexicano. Adems de proporcionar informacin acerca de los resultados de las pruebas, dando a conocer los ajustes y modificaciones que pueden surgir en una prueba piloto.

1.1

Payment Slip

Payment Slip es un estndar para el Pago de Servicios que utiliza el cdigo de barras GS1 128 y NPE (Nmero de Pago Electrnico), a travs del cual se puede obtener informacin contenida en el taln de pagos, como el proveedor del servicio, fecha de pago, importes, identificacin de usuario o cliente, entre otros. Este estndar va acompaado de transacciones electrnicas para el correcto intercambio electrnico de datos entre los socios comerciales, de tal manera que facilita el envo de informacin al emisor sobre el cobro de los servicios efectuados en las cadenas y sucursales. En este estndar se involucran las siguientes partes: proveedores de servicios (emisor), tales como empresas de electricidad, gas, agua, telefona, seguros, agencias gubernamentales, etc.; receptores de pago (banca tradicional y electrnica, tiendas de autoservicio, tiendas de conveniencia, departamentales, y farmacias); y usuario final (consumidor del servicio = cliente). Cabe destacar que los pagos de servicios ofrecen un proceso ms automatizado por parte de las empresas que suplen dichos servicios al usuario final. Esto debido al uso del cdigo de barras impreso en el taln de pagos. A travs de estos cdigos se puede eliminar errores y agilizar la captura de los datos. Aunado a esto, las empresas emisoras de facturas visualizaron el aprovechamiento de las tecnologas de lectores de cdigos de barras ya instaladas en las tiendas de autoservicio, tiendas de conveniencias, bancos, y departamentales, para agilizar el pago correspondiente por parte de sus clientes. La propuesta del estndar de Payment Slip para el mercado mexicano adems de considerar el uso del cdigo GS1 128, incluye tambin la captura manual de los datos del NPE (Nmero Electrnico de Pagos). De tal manera que una empresa receptora de pagos, puede realizar los cobros de los servicios sin la necesidad de utilizar la tecnologa de lectores de cdigos de barras. Inclusive, el conjunto de caracteres del NPE puede ser utilizado para realizar el pago del servicio correspondiente a travs de Internet, donde el usuario utiliza el banco del cual es cuenta habiente para completar la transaccin. El usuario final del servicio puede realizar el pago correspondiente a travs de los cajeros automticos que cuenten con lectores de cdigos de barras o hacer su pago con la captura manual de los caracteres que forman NPE. En julio de 2008 se realiz el Kick Off para desarrollar el estndar de Payment Slip al mercado mexicano. Este proyecto surgi en el comit de Identificacin de AMECE GS1 Mxico, a travs del cual se conform un grupo de trabajo para llevar a cabo el desarrollo e implementacin del estndar. Este proyecto contempla las siguientes fases: FASE I Definicin de la estructura del cdigo GS1 128 y del NPE, as como el procedimiento para cadenas, bancos y proveedores. FASE II Masificacin del proyecto y definicin de Transacciones Electrnicas (reglas y estructura de los mensajes, no implementndolo). FASE III Conciliacin entre socios comerciales. Al concluir la FASE I, el grupo de trabajo defini llevar a cabo la realizacin de una prueba piloto para demostrar la factibilidad del correcto funcionamiento propuesto para este estndar, tomando en cuenta para las pruebas slo la fase I.

1.2

Prueba Piloto

Una Prueba Piloto (Proof of Concept, POC) requiere un conjunto de experiencias que definen sus criterios de xito. Por lo general, los requisitos de prueba se acuerdan y documentan una vez completado el documento de alcance y antes de la definicin de la solucin. Los requisitos de prueba estn relacionados con los objetivos establecidos en el documento de alcance. Cada prueba incluye un requisito, un mtodo de prueba, criterios de aceptacin y medidas de xito. Requisitos de prueba Los requisitos de prueba se utilizan para dirigir el diseo de la solucin de la Prueba Piloto y para administrar el alcance del proyecto durante las fases posteriores. Sirve como referencia y como gua de la presentacin y documentacin de la prueba, y tambin se puede utilizar para registrar los resultados de cada prueba necesaria. Objetivos y alcance Los objetivos de la Prueba Piloto, el alcance general de la solucin se definen en el documento de alcance. El documento de requisitos de prueba define cmo la Prueba Piloto confirmar el alcance de la solucin. Los requisitos de prueba definen cmo se conseguir esto a un nivel determinado. El propsito de realizar la Prueba Piloto o validacin es demostrar que el producto y sus componentes cumplen con los requerimientos especificados y que el funcionamiento sea correcto en el ambiente propuesto. Las actividades de pruebas piloto pueden ser aplicadas en todos los aspectos del proceso en los ambientes deseados, como operacin, entrenamiento, desarrollo, mantenimiento y servicios de soporte. Los mtodos empleados para realizar la validacin deben estar acordes al modelo del estndar y flujo de operacin. El ambiente de pruebas debe representar el ambiente deseado del producto y sus componentes, as como representar el ambiente adecuado recomendado. Las prcticas especficas para este proceso son: 1. Seleccionar el estndar a validar permite la identificacin del estndar ser validado y los mtodos que se utilizarn para realizar la validacin. 2. Establecer el ambiente de pruebas especfico permite la determinacin del ambiente que se utilizar para llevar a cabo la validacin. 3. Establecer los procedimientos de validacin y los criterios permite el desarrollo de validacin de procedimientos y criterios que se encuentren alineados a las caractersticas del estndar seleccionado, restricciones del cliente, mtodos y ambiente de pruebas. 4. Realizar la validacin permite la realizacin de la validacin y pruebas de acuerdo a los mtodos, procedimientos y criterios.

2. AlcanceEmisores2.1 Descripcin del Alcance: Generacin de facturas de pago de servicios Seguros Monterrey generar un conjunto de facturas de pago que incluyan el cdigo de barras GS1 128 y el NPE de acuerdo a la definicin del layout descrita en el archivo: Generador Lneas de Captura SMNYL GS1 128 NPE-BARRA v15.xls.

El alcance en monedas de pago ser: Pesos, Dlares y UDIS Los casos para validaciones entre particulares incluirn: 00 = No hay validacin especial 01=Aceptar Fecha de Pago vencida 02=Aceptar Cantidad a Pagar de menos 03=Aceptar Fecha de Pago vencida y Cantidad a Pagar de menos Seguros Monterrey generar una matriz de pruebas que incluya el set de casos de prueba con las combinaciones posibles de Lneas de Captura de Barra/NPE. Este archivo incluir los campos de resultados y observaciones que sern llenados por los Retailers/Bancos participantes en el piloto. Recepcin y validacin archivo de pagos estandarizado Seguros Monterrey recibir el archivo de pagos estandarizado y validar que cumpla con la estructura definida y que contenga la informacin derivada del pago de las facturas. Verificacin resultados de matrices de pruebas Seguros Monterrey recibir las matrices de pruebas con los resultados observados por cada Retail/Banco y validar los resultados con el coordinador del piloto por parte de AMECE-GS1 Mxico. Seguros Monterrey y AMECE-GS1 Mxico entregarn un informe con los resultados observados de las pruebas por cada Retail/Banco participante. 2.2 Alcance Detallado:

Nota: El WBS incluye fechas definidas hasta el desarrollo de las facturas en PDF, quedando pendiente la validacin de pruebas de acuerdo a los tiempos que designen cada Retail/Banco participante en la prueba.

2.3 Entregables

No.

Descripcin (a)

Entendimiento (b)

Importancia

Criterios de aceptacin (d)

(A/M/B) (c) 1 Matriz de pruebas Es el documento que piloto incluye los casos de prueba Facturas de pago Documento que contiene una factura de pago asociada a un caso de prueba. de Documento que de contiene los de resultados observadosde las pruebas por cada retail/receptor participante.

Cumpla con lo definido en Generador Lneas de ACaptura SMNYL GS1 128 NPE-BARRA v15.xls

2

Asociada aun caso de la matriz de pruebas A Cumpla con lo definido en Generador Lneas de ACaptura SMNYL GS1 128 NPE-BARRA v15.xls

3

Informe verificacin resultados pruebas

2.4 Requerimientos Funcionales: No aplican para la etapa de pruebas piloto 2.5 Requerimientos NO Funcionales: No aplican para la etapa de pruebas piloto 2.6 Exclusiones: - No se generarn facturas en moneda Euros 2.7 Lmites del Proyecto: Fecha de inicio propuesto: Fecha de trmino propuesto: Viernes 17 de abril Actividad de inicio: 15 de Septiembre Actividad de fin: Generacin Facturas Conclusiones de pruebas

2.8 Estimacin de Recursos Financieros: No desarrollado para estos fines

Receptores2.1 Descripcin del Alcance: El alcance de esta prueba es poder lograr el diseo y la estructura adecuada del cdigo de barras, lnea de captura reducida y archivo de intercambio estandarizado que permita llevar cabo el cobro del proveedor de servicios (Seguros Monterrey) en un ciclo completo de recepcin, cobro y pago. Seguros Monterrey maneja una lnea de captura completa que requiere de pagos en pesos, dlares, UDIS y opciones flexibles en vigencias e importes de pago. La prueba piloto es en produccin en un ciclo de pago real. 2.2 Alcance Detallado: Para las pruebas iniciales se requieren: a) Definir el cdigo de barras estndar b) Definir el NPE, lnea de captura manual

c) Preparar ambiente de laboratorio d) Desarrollo del sistema en punto de venta para poder recibir el pago de servicio estndar GS1128 e) Crear la tabla para colocar la informacin de configuracin y negociacin para cada proveedor de servicio que esta adherido al estndar f) Agregar el formato de barra estndar con el decodificador de datos para el nuevo formato de barras definido g) Agregar la lgica necesaria al sistema para que exista un solo punto de entrada en la operacin del punto de venta que pueda ramificar a varios proveedores de servicio Para las pruebas finales se requieren: a) Documentos impresos con cdigo para pruebas b) Pruebas con terceros, ajustes c) Pruebas en laboratorio de ciclo completo d) Liberacin de prueba piloto en produccin 2.3 Entregables: No. Descripcin (a) 1 Resultados de Lectura de cdigos de barras Lay out con el cobro de las facturas recibidas Pliza de pago

Entendimiento (b) Retroalimentar avances para ajustes Que la informacin llegue correctamente, para todos los casos recibidos. Esta pliza genera el pago y debe cuadrar con el detalle lay out. Informacin sobre la prueba pilotos, registros, importes, fechas de transferencias.

Importancia (A/M/B) (c) ALTA

Criterios de aceptacin (d) El Resultado sea similar par a los Comercios El emisor reciba informacin que requiere Con el importe de pago exacto de las facturas recibidas Operacin satisfactoria

2

ALTA

3

ALTA

3

Resumen resultado de las pruebas

ALTA

2.4 Requerimientos Funcionales: La implementacin del cdigo estandarizado permitir realizar la funcin de cobro de servicios con absoluta seguridad y eficacia evitando problemas de aplicacin. Esto representa una importancia Media debido al tiempo requerido para integrar a todos los participantes en el proceso. No. 1 Descripcin * (a) Entendimiento (b) Importancia (A/M/B) ALTA Criterios de Aceptacin (d) Solicitante

Cdigo de barras Necesario para la legible y buena automatizacin y lectura evitar captura Datos La informacin necesarios: mnima para Identificacin de realizar un cobro

Lecturas exitosas de Cadenas / varios casos en BANORTE escneres promedio. Que la definicin de Cadenas / datos cumpla con la BANORTE mayora de datos

2

ALTA

No.

Descripcin * Entendimiento (a) (b) proveedor, sin captura de identificacin de datos adicionales. cliente, importe, fecha de vigencia, banderas Lnea de captura para casos donde la barra no pueda ser leda. Con datos mnimos y digito verificador Que se puedan permitir pagos en distintas monedas: Pesos, Dlares y UDIS Que se pueda flexibilizar la captura de importes y vigencias Que se registre contablemente y en un enlace a detalle las operaciones En caso de que la barra este deteriorada o el escner falle es necesario poder permitir por excepcin una captura manual Seguros Monterrey mantiene varios productos en planes especiales

Importancia (A/M/B)

Criterios de Aceptacin (d) requeridos por los emisores actuales

Solicitante

3

ALTA

Que la definicin de Cadenas / datos cumpla con la BANORTE mayora de datos requeridos por los emisores actuales

4

ALTA

Que se puedan Seguros recibir pagos en Monterrey distintas monedas con la conversin de tipo de cambio adecuada Que el sistema Seguros permita una captura Monterrey de importe abierta de acuerdo al tipo de producto. Que mediante un archivo estndar se detallen toda la informacin requerida de barras, datos y negociacin al proveedor de servicio. Seguros Monterrey / Cadenas / BANORTE

5

Seguros Monterrey requiere de un producto donde el cliente paga el importe que pueda. Los pagos de los clientes especficos tienen que informarse a Seguros Monterrey

ALTA

6

ALTA

7

Que se realice el pago consolidado al proveedor del servicio del importe recibido.

Debe existir una pliza contable que genera el pago de los pagos recibidos.

ALTA

La pliza contable Cadenas / es interna del BANORTE receptor y debe cuadrar conforme al detalle enviado y conforme a las comisiones negociadas. La transferencia Comercial debe ser por el Mexicana importe completo. Seguros Monterrey

8

Que se realice la El pago es de transferencia forma electrnica. electrnica de fondos

ALTA

No. 9

Descripcin * (a) Que se realice el pago de comisin por recepcin de pagos

Entendimiento (b) El proveer el servicio de captacin conlleva gastos que tienen que ser recuperadores.

Importancia (A/M/B) ALTA

Criterios de Aceptacin (d)

Solicitante

Que exista una Comercial transferencia Mexicana electrnica con el pago de comisin por la factura presentada.

2.5 Requerimientos NO Funcionales: De acuerdo con la plataforma que actualmente opera la empresa tanto en servidores como en perifricos no se contempla inversin en hardware o software especial. No. Descripcin * (a) Recurso econmicos Entendimiento (b) Evaluar la necesidad de desarrollos y adecuaciones La necesidad de requerir personal de apoyo adicional para: Programacin. Pruebas Importancia (A/M/B) (c) media Criterios de aceptacin (d) En funcin de algn posible costo Disponibilidad del rea de punto de venta y de transferencia electrnica de fondos para realizar el desarrollo,

1

2

Recursos humanos

media

3

Laboratorio de Pruebas

Se requiere un punto de venta de prueba y hardware como escneres para realizar y probar el desarrollo antes de salir a produccin,

media

Disponibilidad del laboratorio.

2.6 Exclusiones: -Ningn cambio en el procedimiento actual, se aceptan como siempre. -En esta prueba piloto no se contemplan todas las sucursales, solamente entrarn las sucursales de prueba. -La prueba piloto es en un archivo adicional paralelo a la produccin. 2.7 Lmites del Proyecto: Fecha de inicio propuesto: Fecha de trmino propuesto: Viernes 17 de abril Actividad de inicio: 15 de Septiembre Actividad de fin: Comentarios de lecturas Conclusiones de pruebas

2.8 Estimacin de Recursos Financieros: Para la cadena/banco el desarrollo se hace con personal interno y en nomina, con el siguiente personal: Desarrollo Punto de Venta Transferencia Electrnica de Fondos.

Control de calidad Punto de Venta. Tesorera. El personal de operacin de la(s) sucursal piloto. No se requieren fondos adicionales, sola la disponibilidad del personal.

3. Antecedentes de la Prueba PilotoEn Junio del 2008 se present a la Vicepresidencia de Identificacin el proyecto de Payment Slip, con la finalidad de iniciar el desarrollo de este estndar en el mercado mexicano. Este proyecto fue aprobado, y se form un grupo de trabajo para dichos fines. Este grupo de trabajo inici sus sesiones en Julio del 2008, en el cual han participado diversas empresas de diferentes sectores, como del sector telefnico, de seguros, de gobierno, de educacin, bancario, cadenas, entre otros. Desde las primeras sesiones de este grupo de trabajo, se iniciaron las definiciones del estndar de taln de pagos para el mercado mexicano. Para esto, AMECE GS1 Mxico colabor con la presentacin del estndar en el uso de los identificadores de aplicacin (campos contenidos en el cdigo) que pueden ser utilizados para pagos de servicios. Para finales del 2008 AMECE GS1 Mxico en conjunto con las empresas entreg la propuesta inicial de la estructura del cdigo GS1 128 con los identificadores de aplicacin definidos. En Enero del 2009 se defini en este grupo de trabajo iniciar las pruebas piloto de acuerdo a la propuesta inicial de definicin de layout para el cdigo de barras. Este grupo de trabado tom la decisin de formar un sub grupo de trabajo especfico para pruebas piloto. Las empresas que aceptaron inicialmente participar en las pruebas piloto son: Seguros Monterrey como emisor del taln de pagos, Comercial Mexicana, CHEDRAUI, Soriana, Wal Mart, y Banorte como receptores de los talones de pagos. Se estableci como fecha lmite para realizar el desarrollo interno por los receptores de pagos, el 31 de Agosto del 2009. En vista de esta limitante, las empresas que concluyeron las pruebas correspondientes Seguros Monterrey, Comercial Mexicana y Wal Mart en sus roles respectivos. El desarrollo de las pruebas piloto fue divido en distintas etapas, en las que las empresas participantes en las pruebas definieron iniciar la primera etapa en el mes de febrero de 2009 con la definicin del layout del cdigo de barras y el NPE.

4. MetodologaEl desarrollo de las pruebas piloto para el estndar de Payment Slip necesita llevar a cabo una serie de pasos, y procesos que involucran al menos un par de empresas con el objetivo de demostrar el funcionamiento del estndar ya establecido con la intencin de controlar todas las variables. Es importante mencionar que para el desarrollo de un piloto se debe de identificar las reas de oportunidad y mejoras, para poder corregirlas y subsecuentemente masificarlas. Se requiere poner atencin en la funcionalidad del proceso. En una prueba piloto se define el flujo del origen al fin de las pruebas, mostrando lo que ocurrir, en cuanto a procesos, tiempos, entregables, documentacin, etc. A continuacin se presenta un diagrama con las pruebas a realizar durante toda la prueba piloto del estndar Payment Slip:

Definir el layout del cdigo y NPE

Generar cdigo y NPE Decodificar y leer

Leer cdigo y NPE Configurar escaner Desarrollar aplicacin Leer cdigos demos Generar reporte Enviar reporte al emisor Conciliar

Emisor/Receptor

Emisor

Receptor

Receptor

Receptor

Receptor

Receptor

Emisor/Receptor

Para el piloto hay que documentar el flujo de pruebas, los participantes, el cronograma, los recursos, y entregables. La documentacin debe venir detallada a nivel de actividad. Se debe de buscar un acuerdo en cuanto a las fechas para cada uno de los pasos liberados.

5. Desarrollo5.1 Estndar Taln de Pagos5.1.1 CONCEPTOS BSICOSEl cdigo de barras es un grupo de barras y espacios rectangulares paralelos, estructurados segn unas reglas de codificacin o simbologa estndar, que representan informacin alfabtica y/o numrica. Existen diferentes simbologas para diferentes aplicaciones, cada una de ellas con diferentes caractersticas, tales como EAN/UPC, cdigo 39, CODABAR, I 2/5, cdigo 93, cdigo EAN/UCC 128. Esta ltima es la simbologa a emplear para los talones de pagos.

5.1.2 CDIGO DE BARRASLos cdigos de barras cumplen con dos funciones especficas: identificar un servicio o producto, y permitir la captura automtica de la informacin. El cdigo est compuesto de dos partes: el cdigo y el smbolo. El smbolo es la representacin del cdigo en barras oscuras y espacios claros, que permite la captura automtica de la informacin. El cdigo es la parte que identifica el servicio, producto o localizacin por medio de caracteres humanamente legibles.

5.1.3 ESTRUCTURA DEL SMBOLOLa simbologa EAN/UCC 128 es una simbologa que pertenece a la clase de las simbologas de una sola lnea, continua y de longitud variable. La estructura general de un smbolo de cdigo de barras bajo la simbologa estndar EAN/UCC-128 es la siguiente: a) rea o zona de silencio izquierda b) Carcter de inicio c) Uno o ms caracteres representando los datos (identificadores de aplicacin y datos) y caracteres especiales. d) Carcter de control e) Carcter de parada f) rea o zona de silencio derecha

a) ZONA DE SILENCIOrea libre de interferencias alrededor de un smbolo de cdigo de barras; en particular, al principio y al final de

un smbolo de cdigo de barras. Esta rea es necesaria para la correcta lectura del smbolo.

b) CARCTER DE INICIOCarcter que determina el tipo o conjunto de caracteres que se representan, y en la simbologa EAN/UCC-128 puede ser: Inicio A, Inicio B, o Inicio C. Inicio A. Carcter que permite que se simbolicen caracteres alfanumricos ASCII en maysculas y caracteres de puntuacin. Inicio B. Carcter que permite que se simbolicen caracteres alfanumricos ASCII en maysculas y minsculas, y caracteres de puntuacin. Inicio C. Carcter que permite simbolizar nica y exclusivamente caracteres numricos, en pares de 00 a 99. El inicio C permite codificar la informacin numrica de manera que dos dgitos de informacin se representen con slo un carcter de smbolo; es decir, permite un juego de simbologa de doble densidad. El beneficio de tener un cdigo numrico simbolizado en inicio C es que la longitud del smbolo se reduce. Dado que la simbologa EAN/UCC-128 define que cuando se trata de un cdigo numrico se debe emplear siempre el juego de simbologa C, el estndar de recaudo debe estar simbolizado teniendo en cuenta esta simbologa. Funcin 1. Carcter que junto con el de inicio define la simbologa estndar EAN/UCC-128. Tambin se usa como separador entre campos, cuando en un smbolo se concatenan varios campos de longitud variable. Datos. Los datos simbolizados corresponden a la informacin relacionada con el recaudo, tales como identificacin de empresa, referencia del recaudo, fecha mxima de pago, valor a recaudar, etc. Estos datos tambin se representan en el cdigo; es decir, en los caracteres humanamente legibles, de acuerdo con una estructura especfica.

c) CARCTER DE CONTROL (CC)Carcter de chequeo calculado a partir de los otros caracteres del smbolo de acuerdo con un algoritmo definido. Su uso es obligatorio y se emplea para verificar que el cdigo de barras ha sido correctamente compuesto y ledo.

d) CARCTER DE PARADA (CP)Carcter auxiliar que indica el final de un smbolo de cdigo de barras y se ubica en extremo derecho del smbolo. De acuerdo con lo anterior, la estructura general de un smbolo del estndar de recaudo estar dada por: Es importante sealar que el carcter de inicio C, Funcin 1 y de parada son codificados e impresos automticamente por el software de generacin de cdigos de barras, previa seleccin de la simbologa EAN/UCC 128. Estos caracteres van simbolizados, mas no codificados; es decir van en las barras pero no en los caracteres humanamente legibles.

5.1.4 ESTRUCTURA DEL CDIGOPara la identificacin y simbolizacin de la informacin fija (identificacin de empresa, monto a pagar, fecha de vencimiento) y variable (referencia de pagos.), la simbologa establece que el cdigo se compone de una cadena de identificadores de aplicacin (IA) y los datos mismos, as:

Los identificadores de aplicacin (IA) son prefijos empleados para identificar el significado, el tipo de caracteres y la longitud de la cadena de datos que se codifica a continuacin. Un IA es un nmero estndar de 2, 3 o 4 dgitos,

que provee informacin exacta sobre: el significado de los datos. Dependiendo del IA empleado se puede identificar el tipo de datos codificados a continuacin del IA (fecha, referencia, valor, etc.) el tipo de caracteres: numrico o alfanumrico. la longitud de los datos: variable o fija.

El estndar recomienda que el IA se codifique entre parntesis en el cdigo, pero que estos no sean simbolizados; es decir, que los parntesis vayan en el cdigo, mas no en el smbolo. Por otra parte, los datos representan la informacin propiamente dicha, la cual va relacionada con el tipo de IA empleado.

ESTRUCTURA DEL CDIGO Y SIMBOLO (CODIGO DE BARRAS) PARA LOS RECAUDOSA continuacin se presentan los posibles identificadores de aplicacin que pueden ser utilizados para los recaudos. Sin embargo, no todos los identificadores mencionados son los utilizados para el estndar.

IA415

DATONumero de Localizacin EAN-13

LONGITUD REQUISITOFijo n3+n13 Obligatorio

DESCRIPCIONCdigo numrico asignado por GS1 Mxico. Identifica Entidad emisora, servicio facturado.

COMENTARIOS

390n Cantidad a 391n Pagar

Fijo Opcional 390: n4+n..15 391: n4+n3+n..15

12

Fecha mxima de pago

Fijo n2+n6

Opcional

Es utilizado por la agencia de recepcin de pagos como referencia de las caractersticas del contrato efectuado con la parte que factura, tales como: Se puede aceptar el pago Detalles del contrato de la parte que factura Accin a seguir en el caso de que la fecha de vencimiento expire Acuerdos de transferencia de fondos al banco de la parte que factura Para facturas en moneda se emplea un AI (390n) = cantidad a Pagar rea monetaria nica IA 390n 391n. Este separa 8 enteres y 2 AI (391n) = cantidad a Pagar con cdigo de moneda de tres dgitos ISO decimales Ej. 12345678.12 Si la cantidad a pagar est codificada en barras, se recomienda utilizar AI (391n), ya que esto asegura que la moneda del pago puede ser procesada y verificada de manera automtica por el sistema. Sin embargo, si la moneda est implcita de manera no ambigua por el sistema, se puede utilizar el AI (390n). Para evitar la ambigedad, se puede utilizar un AI codificando la cantidad a pagar y la cantidad deber ser claramente indicada de forma tal que pueda ser leda por el ser humano. Los sistemas de escaneo deberan ofrecer la posibilidad de cambiar la cantidad a pagar. Se requiere esta funcionalidad si el que recibe la factura desea realizar un pago mnimo requerido, que sera inferior a la suma total adeudada. La suma que se debe es una informacin de atributo, y cuando se la utiliza, debe ser procesada con el Nmero Mundial de Localizacin (GLN) de la parte que factura. Slo un elemento de la cantidad a pagar de la cadena de elemento se podr aplicar en un taln de pago. El formato debe ser AAMMDD. Ej. Mientras que la fecha de vencimiento codificada en barras debe ser representada YYMMDD, es 080129 posible presentar los datos ledos por el ser humano de cualquier manera adecuada. La fecha de vencimiento indica la fecha lmite en la cual la factura deber ser abonada (por el invoicee, la parte a quien se le factura). Es una informacin de atributo y cuando se la utiliza, debe ser procesada con el Nmero Mundial de Localizacin (GLN) de la parte que factura.

8020 Referencia del recibo de pago

Variable n4+an..25

Obligatorio

Caracteres alfanumricos asignados por la entidad que factura para identificar al usuario, servicio etc. Que identifique lo que le estn pagando. Este solo puede ser colocado en posiciones pares 2, 4, 6, hasta un mximo de 24.

El IA (8020) identifica nicamente, al taln de pago cuando se lo utiliza junto con el Nmero Mundial de Localizacin (GLN) de la parte que factura. Se utiliza para comunicar detalles de pagos entre todos los socios involucrados: parte que factura, parte que recibe la factura, agencia de recepcin de pagos y banco(s). Tambin puede ser utilizado como una clave para acceder a la informacin recolectada localmente.

8007 Nm. Internacional de Cuenta Bancaria (IBAN)

Variable n4+an..30

Opcional

90

Aplicaciones Variable internas n2+an..30 (acuerdo de clientes y proveedores).

Opcional

9199

Informacin Interna de la Compaa

Variable n2+an..30

Opcional

El identificador de la cuenta bancaria de la parte que factura se define en ISO 13616. Se utiliza para identificar a dnde enviar el pago y, en el pas que recibe el pago, para identificar qu banco es el banco que posee la cuenta, para el pago bancario internacional. El IA 90 est asignado para empleos internos y/o aplicaciones mutuamente acordadas entre las empresas que participan en la transaccin comercial. Las empresas pueden idear a su propia discrecin, estructuras de cdigos internos y simbolizarlos junto con este IA. Ejemplo: (90)BM001006 Puede contener cualquier informacin Nota: Puede contener tiempos de re-emisin, un uso libre, indicacin de impuesto, dgito interna de la compaa. El campo es verificador. alfanumrico y puede contener todos los caracteres contenidos en la GENSPECS

8018 Nmero Mundial de Relacin de Servicios

Fijo n4+n18

Opcional

Proporciona un medio para que el proveedor del servicio almacene la informacin relevante en relacin al o a los servicio (s) proporcionado (s) al receptor. Incluye nombre y direccin y el detalle de los servicios suministrados.

Puede tener hasta 18 dgitos y deben ser asignados de manera secuencial y que no contengan elementos de clasificacin

Resumiendo el cdigo de barras puede manejar varias estructuras segn la necesidad del cliente y el convenio que tengan con la sucursal bancaria, farmacia o la tienda de autoservicio o departamental.

POSICIN DE LOS DATOSEl identificador de Aplicacin (IA) 415, cuyo dato es el N de Localizacin EAN 13, debe de representarse en el inicio del smbolo. El identificador de Aplicacin (IA) 8020 y su dato Referencia de Pago debe de posicionarse como ultimo dato a representar en el smbolo. Los identificadores de Aplicacin (IA) 390n y 12 pueden intercambiar posiciones, pero nunca posicionarlos al inicio o el final del smbolo. CREACIN DE NPE NPE es un cdigo generado desde el mismo cdigo de barra manejando as la misma informacin. Este utiliza un digito verificador que es calculado a travs de una rutina conocida como Mdulo 10. Como se relacionan los segmentos del cdigo de barra GS1 - 128c y NPE EAN/UCC 128 415 90 96 3902 8020 Identificador Referencia Identificador Cantidad a Pagar 13 caracteres 4 caracteres 4 caracteres 4 a 12 caracteres 4 a 20 caracteres NA NA

NPE 8 caracteres 3 caracteres 4 Caracteres 4 a 12 caracteres 4 a 20 caracteres 1 1

EAN/UCC 128 Identificador Fecha de Pago Dgito Verificador NA

NPE 1

NA

2

5.2 Etapas de las Pruebas Etapa 1. Definicin del Layout del Cdigo & NPEPara la definicin final del layout del Cdigo de Barras GS1 128 se desarrollaron varias sesiones de trabajo en conjunto con las cadenas, bancos y proveedores de servicios. En un inicio slo las cadenas y proveedores de servicios trabajaron en la definicin de la estructura del cdigo de barras. La definicin del layout para el cdigo de barras GS1 128 a ser utilizado en los talones de pagos de servicios consiste en establecer los identificadores de aplicacin que sern utilizados en el cdigo GS1 128 los cuales contienen la informacin que requieren los emisores y receptores para establecer la informacin necesaria en sus sistemas y su relacin comercial. Esta definicin tiene la intencin de revisar los campos mandatarios u opcionales, de longitud variable o fija, y que el tipo de datos contenidos sean alfanumricos o numricos, para que posteriormente se pueda generar el cdigo de barras a travs de un software que trabaje bajo los estndar del GS1 128. Definicin 1 del Cdigo de Barras GS1 128 La primera propuesta de layout para el cdigo de barras que se decidi utilizar consta de la siguiente estructura: Utilizar un nico Identificador de Aplicacin (IA) 91 = informacin interna de la compaa. Utilizar varios sub-campos los cuales sern separados guiones medios, definidos a continuacin: 1. GLN con 6 dgitos como mnimo y 11 como mximo. Este sub campo ser de tipo numrico. 2. Cantidad a Pagar con 3 dgitos como mnimo y 7 como mximo. Este sub campo ser de tipo numrico. 3. Fecha de Pago con 6 dgitos de longitud fija. No habr mnimos ni mximos, deber llenarse ao y mes obligatoriamente, y el da se rellenar con 2 ceros. Irn en el siguiente orden: Ao, Mes, Da. Este sub campo ser de tipo numrico. 4. Referencia con 4 dgitos como mnimo y 14 como mximo. Este sub campo ser de tipo alfanumrico. 5. Banderas con 2 dgitos de longitud fija. Este sub campo ser de tipo alfanumrico. Utilizar un dgito verificador. Soriana hizo la observacin de validar la factibilidad de utilizar el subcampo Bandera de tipo alfanumrico. Adems todos los participantes recomendaron buscar una rutina de validacin para el clculo del dgito verificador en esta primer propuesta. En esta primer propuesta, AMECE GS1 Mxico verific con GS1 Global el tamao definido para el GLN, donde originalmente la idea plateada por este subgrupo de trabajo era validar si se podra utilizar un GLN de 6 dgitos. GS1 Global realiz una recomendacin del GLN de 13 dgitos para el mercado mexicano en base al estndar global, donde viendo esta posibilidad GS1 Global en conjunto con AMECE GS1 Mxico redefinieron el primer layout para contemplar otro Identificador de Aplicacin el cual sera el GLN (415) y eliminarlo del Identificador de Aplicacin 91 como subcampo. En relacin a la rutina de validacin para calcular el dgito verificador, se consult con GS1 Global e hicieron la observacin de no utilizar el mdulo 10 ya que este slo aplica en campos de tipo numrico, adems de comentar que GS1 Global no posee rutinas de validacin para cuando se utilizan campos de tipo alfanumrico. Al mismo tiempo Seguros Monterrey hizo la recomendacin de ampliar la longitud de los subcampos de Referencia, Cantidad a Pagar, y Banderas, y reducir la longitud del subcampo Fecha de Pago. Definicin 2 del Cdigo de Barras GS1 128 En base a todo lo anterior, se elabor la segunda propuesta de layout, la cual se detalla a continuacin:

Utilizar el IA 415 (GLN de la compaa emisora de servicio) como primer IA. Utilizar el IA 91 (informacin interna de la compaa) como segundo IA. En este segundo IA, se encuentran los siguientes subcampos: 1. Referencia con 1 dgito como mnimo y 19 como mximo. Este sub campo ser de tipo alfanumrico. 2. Cantidad a Pagar con 0 dgitos como mnimo y 8 como mximo. Este sub campo ser de tipo numrico. 3. Fecha de Pago con 0 dgitos como mnimo y 4 como mximo. Ser una fecha juliana, donde el primer dgito indica el ao y los siguientes 3 dgitos indican los das transcurridos en el ao. Este sub campo ser de tipo numrico. 4. Banderas con 3 dgitos de longitud fija. Este sub campo se divide en 2: banderas de validacin (importe o vencimiento), y banderas de moneda. Ser de tipo numrico. Utilizar un dgito verificador. Soriana acept utilizar cualquier definicin con respecto a la estructura del cdigo, ya que se adaptarn al lay out definido, para posteriormente hacer las pruebas. En esta segunda definicin de layout, WAL Mart hizo la recomendacin de revisar el monto mximo permitido para realizar un pago de servicio en los POS (puntos de ventas de los receptores participantes) y de esta manera definir la longitud mxima del subcampo Cantidad a Pagar. Seguros Monterrey adems recomend emplear algn carcter delimitador para los subcampos, como por ejemplo guiones medios, de tal manera que facilitara la lectura e identificacin de los mismos, y esto pueda reducir la cantidad de caracteres contenidos en el cdigo de barras. AMECE GS1 Mxico hizo la revisin del estndar global para el manejo de caracteres alfanumricos. En el ltimo layout definido el sub campo de referencia utiliza caracteres alfanumricos, que corresponde al conjunto A o B de caracteres, y estos no permiten codificaciones mayores a 48 caracteres. Por lo anterior AMECE GS1 Mxico recomend utilizar el conjunto C de caracteres, el cual utiliza dgitos numricos, y codifica dgitos en grupos de 2. Considerando el diseo del ltimo layout, los emisores que deseen utilizar caracteres alfanumricos en su referencia, deben de hacerlo con un mnimo de 48 caracteres. Con el objetivo de eliminar dgitos en el sub campo banderas, se propuso por Comercial Mexicana que el sub campo Banderas fuera opcional, que se invirtiera el orden de acuerdo a la ltima definicin para que el primer dgito validara la moneda y el segundo dgito validara el importe y la fecha. En base a esta propuesta, el grupo de trabajo acord un estndar para el uso de banderas de acuerdo a como se describe a continuacin: Para la bandera moneda, la catalogacin sera: 0 moneda pesos mexicanos, 1 dlares, 2 euros, 3 UDIS, del 4 al 9 sera uso libre para otras monedas. Para la bandera importe y fecha sera: 0 cantidad exacta, 1 menos de la cantidad a pagar, 2 aceptar ms de la cantidad a pagar, 3 aceptar la cantidad que sea, 4 fecha lmite (mxima) de pago, 5 aceptar la fecha abierta, 6 fecha mxima con importe mximo, 7 fecha mxima con importe variable, 8 fecha mxima sin validacin de importe, 9 de uso libre de acuerdo a lo que se defina en cada relacin comercial. HSBC puntualiz que en el sector bancario la longitud de referencia de los cdigos de barras es de 40 posiciones, y que no existen caracteres variables y especiales, por lo que solicit revisar el uso de guiones medios que se utilizan en el IA 91. Adems puntualiz que de acuerdo a la utilizacin de caracteres numricos, la tecnologa actual permite la utilizacin de medios alternos como celulares y cajeros automticos los cuales se inclinan por la no utilizacin de caracteres alfanumricos.

Debido a las observaciones anteriores, AMECE GS1 Mxico propuso considerar que se utilizara el modelo de GS1 El Salvador descrito a continuacin: IA 415 (GLN de la compaa emisora de servicio) como primer IA. Campo obligatorio fijo de 13 posiciones. IA 3902 (cantidad a pagar) como segundo IA. Campo opcional fijo de 8 posiciones. IA 12 (fecha lmite de pago) como tercer IA. Campo opcional fijo de 6 posiciones. IA 8020 (referencia del pago) como cuarto IA. Campo obligatorio variable de 2 a 20 posiciones. Creacin de un cdigo NPE estndar para captura manual de la informacin. Este cdigo vendra impreso junto con el cdigo de barras, y sera un cdigo reducido a partir de los datos colocados en los IAs, sin contemplar los dgitos que representan cada IA colocados dentro de los parntesis. Notas: 1. El uso del NPE soluciona la propuesta de no rebasar los 40 caracteres de acuerdo a la longitud mxima que es permitida en el sector bancario. 2. El modelo de GS1 El Salvador utiliza un conjunto de datos C, lo cual quiere decir que son caracteres numricos. Aquellos emisores que deseen utilizar este tipo de caracteres C deberan de utilizar un catlogo interno para intercambiar este tipo de dgitos a numricos, y esto conllevara a la correcta utilizacin del estndar definido por GS1 El Salvador. El grupo de trabajo estableci una regla para la definicin del NPE, el la que se manejarn mltiplos de 4. En caso de que una empresa no desee utilizar algn campo, estos se deben de justificar con ceros a la izquierda; por lo que AMECE GS1 Mxico propuso utilizar el IA 3902 (cantidad a pagar) para el cdigo de barra y el NPE. El grupo de trabajo decidi cambiar el IA 12 (fecha lmite de pago) por el IA 96 (informacin interna de la empresa) para poder utilizar una fecha juliana de 4 dgitos tanto en el cdigo de barras como el NPE con el propsito de ahorrar espacios en los dgitos. Esto para poder ahorrar espacios en los dgitos. Seguros Monterrey propuso utilizar el IA 91 para identificar el cdigo de moneda del importe a pagar y una bandera para negociaciones. Para el cdigo de barra se utilizar un dgito que identifique la moneda, 2 dgitos que identifique la bandera y al final un dgito verificador. Para el NPE se propuso utilizar 2 dgitos para identificar la moneda, 2 dgitos para identificar la bandera, 1 dgito para identificar la fecha de pago, 1 dgito para identificar la cantidad a pagar, 1 dgito para identificar la referencia y al final un dgito verificador (DV). Se propuso que el IA 91 fuera obligatorio y de longitud fija para el cdigo de barra. Definicin 3 del Cdigo de Barras GS1 128 En base a todo lo anterior, el grupo de trabajo elabor la tercera propuesta de layout la cual servir como base para realizar pruebas de concepto de manera interna por cada participante. La misma se detalla a continuacin: Utilizar el IA 415 (GLN de la compaa emisora de servicio) como primer IA. Campo obligatorio fijo de 13 posiciones. Utilizar el IA 3902 (cantidad a pagar) como segundo IA. Campo opcional variable de 4, 6 8 posiciones. No se rellena con ceros a la izquierda. Utilizar el IA 96 (fecha lmite de pago) como tercer IA. Campo opcional fijo de 4 posiciones. Utilizar fecha juliana, donde el 1er dgito es el ao y los siguientes son los das transcurridos en el ao. Utilizar el IA 8020 (referencia de pago) como cuarto IA. Campo obligatorio variable de 2 a 20 posiciones. No se rellena con ceros a la izquierda. Utilizar el IA 91 (informacin interna de la compaa) como quinto IA. Campo obligatorio fijo de 4 posiciones, el cual incluye un dgito verificador; de acuerdo a como lo propuso Seguros Monterrey mencionado anteriormente. El grupo de trabajo estableci imprimir el cdigo NPE estndar para la captura manual de la informacin junto con el cdigo de barras. Cabe destacar que el NPE se genera a partir de los campos definidos en el cdigo de

barras estndar. El NPE no considera utilizar los dgitos de cada IA, que son los que estn colocados dentro de los parntesis. La longitud del NPE tendr un tamao de 40 caracteres numricos de acuerdo a la recomendacin del sector bancario mexicano. Definicin 1 del NPE En base a todo lo anterior, se elabor la primera propuesta de layout para el NPE, la cual se detalla a continuacin: Un extracto del GLN de solo 4 dgitos Cantidad a Pagar de 4 8 posiciones incluyendo 2 decimales. Cuando se utilicen 4 posiciones se rellena con ceros a la izquierda. Un fecha de pago juliana de 4 posiciones Una referencia de pagos de 4, 8, 12 16 posiciones como mximo. Cuando se utilicen menos de las 16 posiciones se rellena con ceros a la izquierda. Informacin interna de la compaa de 8 posiciones fijas incluyendo el DV. Incluye el cdigo de moneda, una bandera para negociaciones internas entre proveedor y receptor, un dgito para identificar la fecha de pago, un dgito para identificar la cantidad a pagar, un dgito para identificar la referencia y al final un dgito verificador. Nota: El modelo propuesto utiliza un conjunto de datos C, lo que quiere decir que todos los datos utilizados son caracteres numricos. En esta definicin se acord validar el nmero de dgitos utilizados en el GLN (4 dgitos como identificadores nicos para una empresa). Despus de revisar este punto, AMECE GS1 Mxico estableci utilizar 750 00001 donde los tres primeros dgitos representan el prefijo de pas, y los ltimos cinco el nmero correspondiente a la empresa proveedora de servicios, a travs del cual se puede identificar cien mil empresas. Definicin 4 del Cdigo de Barras GS1 128 Al incorporarse nuevos Bancos a este grupo de trabajo surge la necesidad de revisar el layout definido. Se propuso cambiar el IA 3902 (cantidad a pagar) a 10 posiciones y no de 8 como estaba definido anteriormente, esto debido a que existen pagos que rebasan al milln de pesos. La lectura del cdigo de barras tiene 2 enfoques: 1) los imprimibles (los que son humanamente legibles); y 2) los no imprimibles (los que no son humanamente legibles). Se revisaron los catlogos de las banderas, de lo cual se acord que en las banderas de negociacin debe existir un ltimo cdigo que identifique fechas vencidas y cantidad a pagar de menos, de manera combinada. El cdigo para esta descripcin ser 03. Con relacin al cambio del IA Cantidad a Pagar (3902), el cual tendr 10 posiciones, se seal que se debe de considerar que el NPE se lee de derecha a izquierda, en mltiplos de 4 dgitos y los identificadores incluidos son obligatorios. Por esta razn, esta cantidad de dgitos lleva a que el NPE no termine en mltiplos de 4, por lo que se decidi llevar el mismo a una longitud de 12 dgitos (10 para nmeros enteros y 2 para decimales). De acuerdo a todo lo anterior se defini hacer un anlisis de la referencia (ver anexo 1) que utiliza cada banco, es decir analizar la forma bajo la cual trabajan los bancos en cuanto a referencias, longitudes y mdulos para los algoritmos, y qu porcentaje de sus proveedores de servicios utilizan caracteres alfanumricos y numricos. Esto para medir el impacto y obtener la definicin 4 del Cdigo de Barras GS1 128 y por ende la definicin 2 del NPE. Con los resultados presentados en el anexo 1 donde se analiza las referencias utilizadas por los bancos, qued definido el layout 4 mismo que se detalla a continuacin: Utilizar el IA 415 (GLN de la compaa emisora de servicio) como primer IA. Campo obligatorio fijo de 13 posiciones + 3 posiciones del 415.

Utilizar el IA 90 (moneda + bandera) como segundo IA. Campo obligatorio fijo de 3 posiciones, 1 para la moneda y 2 para las banderas. La moneda es la que est asociada a la cantidad a pagar, para efectos de convertirla en caso de que se pague con otra moneda. Se realiz un catlogo, el cual qued establecido como sigue a continuacin: 00=Si no hay cantidad a pagar se pondr 1=Pesos 2=Dlares 3=UDIS 4=Euros Para la conversin de Dlares y UDIS se sugiere el tipo de cambio publicado por el Banco de Mxico en el Diario Oficial de la Federacin. El catlogo para las banderas para validaciones particulares se detalla continuacin: 00=Si no hay validacin especial es 01=Aceptar Fecha de Pago vencida 02=Aceptar Cantidad a Pagar de menos 03=Aceptar Fecha de Pago vencida y Cantidad a Pagar de menos Utilizar el IA 96 (fecha lmite de pago) como tercer IA. Campo opcional fijo de 4 posiciones. Utilizar fecha juliana, donde el 1er dgito es el ao y los siguientes son los das transcurridos en el ao. Si no hay Fecha de Pago, sta se omitir. Utilizar el 3902 (cantidad a pagar) como segundo IA. Campo opcional variable de 4, 6, 8, 10 12 posiciones. Si no hay Cantidad a Pagar, sta se omitir. Utilizar el IA 8020 (referencia de pago) como cuarto IA. Campo obligatorio variable de 4 a 20 posiciones. Este slo puede ser par (4, 6, 8, 10, 12, 14, 16, 18 20). Definicin 2 del NPE En base a lo anterior, se elabor la segunda propuesta de layout para el NPE, la cual se detalla a continuacin: Un extracto del GLN de solo 4 dgitos fijos (obligatorio). Moneda + Bandera. Obligatorio fijo de 3 posiciones, 1 para la moneda y 2 para las banderas. La moneda es la que est asociada a la cantidad a pagar, para efectos de convertirla en caso de que se pague con otra moneda. Se realiz un catlogo, el cual qued establecido como sigue a continuacin: 00=Si no hay cantidad a pagar se pondr 1=Pesos 2=Dlares 3=UDIS 4=Euros Para la conversin de Dlares y UDIS se sugiere el tipo de cambio publicado por el Banco de Mxico en el Diario Oficial de la Federacin. El catlogo para las banderas para validaciones particulares se detalla continuacin: 00=Si no hay validacin especial es 01=Aceptar Fecha de Pago vencida 02=Aceptar Cantidad a Pagar de menos 03=Aceptar Fecha de Pago vencida y Cantidad a Pagar de menos Un fecha de pago juliana de 4 posiciones. Opcional fijo de 4 posiciones. El 1er dgito es el ao y los siguientes son los das transcurridos en el ao. Si no hay Fecha de Pago, sta se omitir. Cantidad a Pagar opcional variable de 4 a 12 posiciones incluyendo 2 decimales. Este slo puede ser en mltiples de 4 (4, 8 o 12). Si no hay Cantidad a Pagar, sta se omitir. Una referencia de pagos obligatoria variable de 4, 8, 12, 16 20 posiciones como mximo.

Validaciones de 3 dgitos fijos, donde el primero es para la referencia, el segundo para la cantidad a pagar y el tercero para la fecha, detallado como sigue a continuacin: 1. Referencia: 0=Omisin 1=4 Dgitos 2=8 Dgitos 3=12 Dgitos 4=16 Dgitos 5=20 Dgitos 2. Cantidad a Pagar: 0=Omisin 1=4 Dgitos 2=8 Dgitos 3=12 Dgitos 3. Fecha de Pago: 0=Omisin 1=Fecha de Pago Doble digito verificador. Obligatorio fijo de 2 posiciones. Nota: Cabe destacar que en esta definicin 2 del NPE no se tiene contemplado un algoritmo para el clculo del doble dgito verificador. Despus de estas dos ltimas definiciones (definicin 4 para el cdigo de barras y definicin 2 para el NPE), en sesin de trabajo por el grupo se realizaron algunos cambios, lo que conllev a tener 2 nuevas definiciones, mismas que se detallan a continuacin. Definicin 5 del Cdigo de Barras GS1 128 Esta nueva definicin conserva la misma estructura de la definicin 4, donde se decidi utilizar el formato de fecha juliana por el de fecha condensada; adems de considerar utilizar como fecha ancla para el IA de fecha de pago el 1ro de Enero del 2009. Definicin 3 del NPE Esta nueva definicin conserva la misma estructura de la definicin 2, excepto con los siguientes cambios: Un extracto del GLN de solo 8 dgitos fijos obligatorio en vez de 4. Los tres primeros dgitos el pas de origen (prefijo de pas) y los cinco restantes identifican la empresa proveedora de servicios. Utilizar el mdulo 97 para la validacin del algoritmo a utilizar en el doble dgito verificador. Utilizar como fecha ancla para el IA de fecha de pago el 1ro de Enero del 2009. Utilizar tipo de fecha condensada en vez de juliana. Definicin 6 del Cdigo de Barras GS1 128 Como consecuencia de la prueba E de este piloto, los participantes del grupo de trabajo definieron incluir nuevas banderas para las validaciones particulares entre cliente-proveedor. Las mismas se detallan a continuacin siguiendo la numeracin del catlogo establecido en la definicin anterior: 04=Aceptar Cantidad a Pagar mayor 05=Aceptar Cantidad a Pagar de ms y fecha de pago vencida 06=Aceptar Cantidad a Pagar mayor o menor al importe de la factura 07=Aceptar fecha de pago vencida y cantidad a pagar mayor o menos al importe de la factura La vicepresidencia de Identificacin de AMECE GS1 Mxico solicit se hiciera un anlisis de las ventajas y desventajas al utilizar fecha condensada y juliana, debido a la que la fecha condensada seleccionada en la

definicin anterior tiene la limitante de renumeracin de aos cuando termina la vigencia del perodo de la fecha ancla (diez mil das). Despus de realizar el anlisis, se decidi una fecha condensada truncada la cual permite que la misma sea infinita y no se deba de renumerar. Esta definicin fue aprobada por el grupo de trabajo y comit. Definicin 4 del NPE Esta nueva definicin se considera los mismos cambios comentados anteriormente en la definicin 6 del cdigo.

Etapa 2. Generacin del Cdigo de Barras & NPEPrueba A: Seguros Monterrey como empresa proveedora de servicios en conjunto con AMECE GS1 Mxico 1 solicitaron a GS1 El Salvador el software para la generacin del cdigo de barras GS1 128 . Para la generacin del cdigo de barras Seguros Monterrey realiz algunos casos de pruebas con la finalidad de que los receptores de pagos participantes hicieran las lecturas. Estos casos de pruebas fueron generados a travs del software facilitado por GS1 El Salvador. De acuerdo a la especificacin del clculo del dgito verificador para la simbologa del GS1 128, la cual utiliza el mdulo 103 para dichos fines, Seguros Monterrey hizo la recomendacin de que para el cdigo de barras la cantidad total de dgitos a utilizar debe de ser un nmero par y el NPE un nmero impar debido a que este ltimo utiliza un dgito verificador. Esto con la finalidad de cumplir con el requerimiento del sector bancario para el NPE. Adems se estara utilizando el mdulo 10 para el algoritmo del NPE. Los casos de pruebas generados ayudaron a demostrar que los cdigos de barras utilizados no pudieron ser ledos de manera correcta por la longitud que presentaban los mismos. Para esto AMECE GS1 Mxico estara consultando a algn receptor de pagos de GS1 El Salvador con la finalidad de poder verificar cmo pudieron leer el cdigo, o en su defecto contactar al proveedor de tecnologa que desarrollo el software en este mercado. AMECE GS1 Mxico consult a GS1 El Salvador el cual sirvi como intermediario para solucionar este punto con HSBC El Salvador, el cual especific no haber tenido problema alguno en la deteccin correcta del cdigo. Prueba B: I. Para la generacin de los cdigos de barras, AMECE GS1 Mxico tom varios casos de pruebas del software de GS1 El Salvador, los cuales seran probados por el SECODAT. II. Despus de la recomendacin que hiciera el proveedor de tecnologa Traceback, Seguros Monterrey en conjunto con AMECE - GS1 Mxico investigaron y analizaron el software de codificacin y decodificacin de cdigos de barras con dos proveedores de tecnologa (ID Automation e Indigo). Ambos ofrecen en sus portales un software tipo demo con licencia de 30 das. Al trabajar con el software de ID Automation, Seguros Monterrey y AMECE - GS1 Mxico detectaron que el mismo software generaba el cdigo de barras con los FUNC1 y con el tamao de acuerdo al estndar. A su vez se utiliz el software de Indigo para la validacin de la generacin de los cdigos ingresando las imgenes de los cdigos que fueron generados por el software de ID Automation. Utilizando este software Seguros Monterrey y AMECE - GS1 Mxico decidieron delimitar los casos de prueba a tres cdigos de barras para que los receptores validaran la lectura correspondiente en sus laboratorios. Prueba C: Seguros Monterrey propuso elaborar una matriz con veinte casos de pruebas (tratando de cubrir el mayor uso posible de identificadores de aplicacin y sus respectivos valores, y escenarios para el mercado

1

Fuente del software: ID Automation

mexicano). Cada unos de estos casos de pruebas gener una factura tipo DEMO, las cuales se enviaron a las cadenas participantes en las pruebas. Los casos de pruebas vinieron acompados de su respectiva matriz2. Prueba D: De acuerdo a la definicin 4 del cdigo de barras y definicin 2 del NPE, se gener un nuevo set de pruebas por parte de Seguros Monterrey en las que se consideran los ltimos cambios incluidos en estas definiciones. Al mismo tiempo surge la propuesta de elaborar un estudio donde se pudiera validar los tipos de escneres que puedan leer el cdigo de barras GS1 128 especificado por marca y modelo del fabricante. Ver Anexo 2. En este estudio se presenta la validacin de los escneres por parte del fabricante de los mismos as como de los usuarios de estos. Los resultados de este estudio arrojaron que los escneres no presentan problemas para la lectura, excepto el escner PSC Datalogic Modelo VS1000. Prueba E: Seguros Monterrey gener el nuevo set de pruebas para las facturas demos con las ltimas definiciones establecidas (definicin 5 cdigos de barras y definicin 3 NPE). Prueba F: Seguros Monterrey nuevamente gener un set de pruebas en el cual se pudieran comprobar el uso de las nuevas banderas (definicin 6 cdigos de barras y definicin 4 NPE). Prueba G: De acuerdo a los resultados obtenidos por la cadena en la prueba F de decodificacin, Seguros Monterrey realizar un set de pruebas que considere utilizar el mximo de caracteres en cada IA y al mismo tiempo irn eliminando los mismos de 4 en 4 para respetar la regla del NPE.

Etapa 3. Decodificar y leer el Cdigo de Barras GS1 128 Captura del NPEPrueba A: Seguros Monterrey realiz las primeras lecturas de los casos de pruebas generados utilizando un escner marca SYMBOL y modelo LS1203. Los primeros resultados indicaron que no identificaban los caracteres separadores (FUNC1) entre un Identificador de Aplicacin y otro. AMECE GS1 Mxico tambin realiz pruebas de lectura con los mismos casos generados por Seguros Monterrey utilizando un escner marca A219. Los resultados indicaron que debido al tamao de los cdigos muchos de estos no podan ser ledos, salvo 7 de estos casos. En dos de ellos la lectura mostr que el cdigo ledo no coincida con el cdigo impreso. En las lecturas realizadas por el escner de AMECE GS1 Mxico se identificaba que los cdigos de barras correspondan al estndar GS1 128. El Centro de Validacin de Cdigos de Barras de AMECE GS1 Mxico (SECODAT) establece una calificacin de la calidad de lectura de los cdigos 3 de barras. Para las pruebas realizadas, seis obtuvieron calificacin C, y una obtuvo calificacin D . AMECE - GS1 Mxico recomend realizar las lecturas de los casos de pruebas con el proveedor de tecnologa Traceback, debido a que ellos cuentan con escneres que permiten la lectura de cdigos de barras ms extensos. Cabe destacar que los escneres utilizados en el SECODAT fueron proporcionados por este proveedor, donde se utilizan escneres tipo HAND HELD. Es por esta razn que Traceback realiz las pruebas. Los resultados de la lectura mostraron un intercambio de los Identificadores de Aplicacin respecto al orden de impresin en los cdigos de barras. Por lo que el proveedor de tecnologa recomend revisar la generacin e impresin del cdigo de barras. Adems recomend realizar otras pruebas con cdigos de barras generados por GS1 El Salvador, de tal manera que se pudiera comprobar que el resultado de la decodificacin muestre el orden correcto de los Identificadores de Aplicacin. Prueba B: I. El SECODAT realiz las pruebas de los casos de GS1 El Salvador, donde en alguno de los cdigos se obtuvo el resultado de no lectura debido a que el tamao de los mismos era muy extenso.2

Esta matriz es un archivo en Excel que contiene la descripcin de los casos de pruebas para que los receptores de pagos participantes en las pruebas realicen los resultados de lectura de cdigo de barras y su NPE. 3 Las referencias de las calificaciones de lectura de los cdigos de barras van de acuerdo al documento de validacin de cdigos segn las 7 normas de calidad de ISO

II. De los tres casos de pruebas generados por Seguros Monterrey (prueba B etapa 2), el primer receptor en realizar la validacin de la lectura fue Comercial Mexicana. El resultado de las lecturas de estos cdigos mostr que el escner marca NCR modelo 7875 no identificaba los FUNC1. Comercial Mexicana decidi revisar el manual tcnico de este escner con la finalidad de verificar si el mismo tena la capacidad de lectura del cdigo de barras GS1 128. El manual arroj que esta marca y modelo de escner si tiene la capacidad de lectura para este tipo de cdigo. En vista de esto, Comercial Mexicana formul la hiptesis de que el escner no tiene la correcta configuracin para la lectura del cdigo de barras GS1 128, por lo que realizaron la correcta configuracin del mismo de acuerdo a la especificacin del manual y volvieron a realizar la lectura de los casos de pruebas. Los nuevos resultados mostraron la correcta identificacin de los FUNC1 y orden de los Identificadores de Aplicacin en base al orden impreso en el cdigo GS1 128. Prueba C: Chedraui indic que no pudo leer los cdigos en su laboratorio. De acuerdo al primer set de pruebas, Wal Mart realiz las lecturas del cdigo de barras y slo un cdigo result sin xito. Prueba D: Al momento de iniciar estas pruebas, Comercial Mexicana not que era necesario realizar la configuracin de sus escneres debido a que en las lecturas obtenidas de los cdigos de barras no se mostraba la separacin de un campo con otro. Por esta razn, se consult el manual tcnico del fabricante para la correcta configuracin del escner, pudiendo obtener una lectura correcta del cdigo GS1 128 con la separacin de los campos. Comercial Mexicana inform sobre la necesidad de configurar el escner de acuerdo a las especificaciones del manual tcnico para una correcta lectura del GS1 128. Prueba E: Comercial Mexicana realiz las pruebas de lectura de estas ltimas facturas demo y notific que no se estaban considerando algunas banderas para las validaciones particulares. Esto conllev a una nueva definicin para el cdigo de barras y NPE. Prueba F: Comercial Mexicana present los resultados obtenidos en el ltimo set de pruebas en donde se identifica que todos los casos fueron satisfactorios, con excepcin de la prueba 15 en donde no se pudo leer el cdigo de barras debido a la extensin de esta (esta prueba considera la cantidad mxima de dgitos para todos los campos contemplados en el layout). Por lo anterior, la cadena pidi realizar un caso de pruebas de cdigo de barras con el IA de cantidad a pagar a 8 dgitos y por el mximo de dgitos para los dems campos. El resultado de las pruebas obtenidas por Comercial Mexicana se incluye en el Anexo 3.

Etapa 4. Desarrollar aplicacinSeguros Monterrey Emisor Seguros Monterrey integr un equipo con un analista, 1 desarrollador y un lder de proyecto, quienes trabajaron bajo la metodologa CMMI (Capability Maturity Model Integration, modelo para la mejora y evaluacin de procesos para el desarrollo, mantenimiento y operacin de sistemas de software). El proyecto cubri 5 etapas: 1. 2. 3. 4. 5. Arranque Planeacin Ejecucin y control Pruebas Cierre

Arranque y Planeacin

Anlisis del sistema. El equipo realiz una exploracin en sitio sobre los usuarios que se veran afectados o que estn involucrados en el proceso de emisin de facturas para los seguros de vida individual y vida colectiva, as como la distribucin de las facturas y el Call Center. Seguros Monterrey tiene un sistema CRM (Customer Relationship Management, administracin basada en la relacin con los clientes) el cual tiene interfaces para que el cliente que se pone en contacto, proporcione los datos de su pliza y se le genere una lnea de captura manual, va telefnica o a travs del IVR (Internet Voice Responding). A su vez, el alcance del proyecto consider 2 fases: 1. Las facturas que se entregan a los clientes y que incluyen el cdigo de barras, es el grueso de la emisin donde entre el 25% y 30% de la cobranza se realiza en bancos y otros receptores. El objetivo es cubrir el 90% de la cobranza en esta primera fase. 2. Las facturas de condiciones especiales. En la emisin de las facturas, se utiliza el estndar GS1-128 del taln de pagos en los siguientes campos: GLN y GLN abreviado para la lnea de captura corta Moneda: pesos, dlares y UDIS Banderas: 00 aceptar la forma de pago que trae el cliente Fecha de pago: obligatoria para las referencias temporales que son las del seguro de vida tradicional, con un recibo de pago, debe cubrirse en determinado tiempo, y las permanentes son las de seguros de vida universal variable, aquellos donde el cliente tiene una parte de inversin y puede depositar la cantidad que desee cuando lo requiera Cantidad a pagar: variable y puede ser de 0 para las facturas permanentes (abierto) y de 4 a 8 dgitos en promedio para las facturas de cantidad fija temporales Referencia: del recibo de pago, asociado a los productos de Seguros Monterrey, con 8 posiciones para las facturas temporales y 12 para las universales Diseo. Est basado en casos de uso, es una tcnica que permite a su vez estimar el costo del desarrollo, el asunto es pago de lneas de captura en bancos, para ventanillas de centro de pago tanto para referencias temporales y permanentes. Los 2 casos de uso que realizar SMNYL son bsicamente: 1. 2. Generar Facturas, y Aplicar Pagos

Para la elaboracin del diseo, se consideraron las siguientes reglas: 1. 2. 3. 4. Reglas de negocio Reglas del estndar Reglas de emisin, es decir todos los datos asociados a la referencia (el segmento que identifica el producto en la lnea de captura) y su registro con el producto. Esta se asocia al cdigo de barras. Reglas de aplicacin, validar la lnea de captura completa y la identificacin de la referencia para aplicar el pago al producto correcto. En estas reglas vienen muchas variantes. Pueden haber veces que se excedan los importes o que realice un pago de menos del importe.

Las reas internas de Seguros Monterrey involucradas para el diseo del sistema fueron el rea Comercial y Financiera, quienes revisan las negociaciones con las distintas empresas receptoras de pagos y Emisin de Productos.

El equipo para este proyecto utiliz una herramienta de modelado basado en los requerimientos del negocio (BPM, Business Process Management, Gestin de Procesos de Negocio). Esta herramienta permite la rastreabilidad bidireccional, del requerimiento al componente del producto y viceversa. Adems para la arquitectura de la solucin se consideraron los requerimientos funcionales, como tal del usuario as como los no funcionales, es decir los que no son necesarios para el correcto funcionamiento del sistema, ejemplo, disponibilidad, escalabilidad, mantenimiento y seguridad. La generacin de la lnea de captura se realiza con procedimientos almacenados en la Base de Datos, es decir objetos que viven en la Base de Datos. Y la explotacin (invocacin de los objetos por los sistemas emisores) desde la misma plataforma de Oracle, la plataforma para los productos de vida individual se explota con Forms de Oracle y para los seguros de vida individual colectivo, la generacin es a travs de un Web Service genrico, solo para la lnea de captura. El cdigo de barras, debe cumplir con las especificaciones tcnicas del estndar de identificacin GS1-128. Para la generacin del mismo, se accesan procedimientos almacenados en la Base de Datos. La imagen del cdigo de barras se hizo con un software de C# de Microsoft, lo que se crea es el estndar donde va la tilde junto con la cadena de elementos del cdigo. La programacin est orientada a objetos y se est resolviendo la situacin con los fonts para su conversin a 72 puntos para arriba, con la finalidad de garantizar la lectura del cdigo de barras, ya que hacia abajo le cuesta a la lectora. Se utiliza un freeware para tomar el font del cdigo de barras GS1-128, ADVC128C. Para incrustar la imagen en las facturas de Seguros Monterrey se contemplan 2 escenarios. El primero es grabar la imagen como objeto en la Base de Datos o en un repositorio de imgenes y el segundo se refiere a tener un font para convertir la cadena en cdigo al momento de emitir, ambos cumpliendo con la calidad y especificaciones del estndar. A continuacin se enumera la secuencia para la generacin de la lnea de captura: 1. Partir de la lnea de captura de Excel, del demo y ver las reglas 2. Convertir todos los elementos de Excel a lenguaje PL/ SQL 3. Flujo para generar los elementos: a. Generar la lnea de captura NPE, con varios pasos i. Dividir la cadena para obtener los elementos que la forma ii. Generar dgito verificador iii. Formatear la lnea de captura a grupos de 4 , el tamao no debe tener sobrantes de caracteres b. Generar el cdigo de barras como tal, con los mismos datos de la lnea pero cambiando los formatos y tambin en grupos pares con el mismo procedimiento, se hace un proceso de condensacin para el cdigo de barras c. Aplicar el algoritmo para obtener la numeracin del cdigo de barras 128 los IA en encriptado a un Font (la cadena de elementos) La programacin es genrica para ser re-utilizable en C# y ser consumida por otras aplicaciones propuestas como Web Service. Internamente, como datos de entrada se tiene la pliza o recibo, la fecha de cobro, el importe, la referencia de control interno y otros datos que son utilizados para la generacin del cdigo de barras. Se genera un nmero de registro de control interno, que sirve para asociar la pliza a pagar con la referencia de pago. Comercial Mexicana Receptor

En su participacin en las pruebas piloto ejecut una serie de actividades con la finalidad de implementar y utilizar el estndar de Taln de Pagos (cdigo de barras GS1 128 y NPE) dentro de sus sistemas de Punto de Venta (POS). A continuacin se detallan las actividades para poder recibir un cdigo de barras GS1 128: 1. Registrar en la base de datos todos los GLNs de los proveedores de servicios con los cuales se tiene un acuerdo comercial. Configurar en la tabla (software de Microsoft Access) a travs del cual se agregan 2 columnas: la del GLN y la de Moneda Aceptada. 2. Registrar o ingresar la moneda aceptada (pesos, dlares, euros, udis). 3. Configurar el escner conforme al manual del proveedor. Seguir la secuencia de los pasos del manual. 4. Leer el cdigo de barras desde el escner en la terminal del POS para identificar si la barra es un GS1 128. Esto se logra a travs de la identificacin de los caracteres especiales de inicio ]C1. 5. Al momento de escner el cdigo, la informacin obtenida se enva a la base de datos y valida si existe el GLN del proveedor de servicio. Se valida que sea un GLN correcto. El GLN se obtiene para ver a qu emisor (nombre de la empresa) corresponde el pago de servicio. Cabe sealar que esta programacin se agreg a la aplicacin que tiene la cadena para el manejo de la terminal del POS. 6. El programa descomprime todos los datos del cdigo de barras siguiendo todas las reglas que se definieron de acuerdo al layout, como por ejemplo las banderas, cantidades a pagar con la longitud especificada. Todos los campos son guardados en variables individuales (por separado). 7. Iniciar con las validaciones definidas en el layout para los campos que as lo requieran, donde se empezara por la validacin del campo de fecha de acuerdo a la bandera de validacin siempre y cuando aplique. La siguiente validacin que se hace es al monto o moneda. Al validar el campo de monto, el programa despliega una segunda pantalla donde se pueda capturar el monto a pagar. Si el cliente quiere pagar de ms o menos presenta esa pantalla para que se ingrese el monto si aplica. 8. Solicita de la base de datos el tipo de moneda para el pago (revisando los valores previamente registrados en la actividad nmero 2). Para cada emisor tiene los tipos de moneda en una tabla donde se especifica la moneda que se puede recibir por cada uno de ellos. 9. El programa pasa a la pantalla de cobro en el punto de venta, primero se presenta el emisor donde se va a dar el pago de servicios, la referencia o cuenta, el importe a pagar, el tipo de cambio, y el total a pagar. Con todo esto ya se puede realizar el cobro. El programa siempre solicitar el monto a pagar en moneda nacional. 10. El programa valida la forma de pago. No se puede pagar con vales, ni con TC, etc. Se escanea el cdigo y con los caracteres especiales de inicio se determina que es un GS1 128 porque ningn otro cdigo tiene esos caracteres Determinar que el GS1 128 es de AMECE, siguiendo NPE 1. 2. 3. 4. 5. Registrar en la base de datos todos los GLNs de los proveedores de Servicios con los cuales se tiene un acuerdo comercial. Registrar o ingresar la moneda aceptada (pesos, dlares, euros, udis). El sistema siempre te va a dar el tipo de moneda en pesos al final Identificar si es un pago de servicio o un producto a travs de dar de alta en el sistema un comando desde el teclado identificado como PS (Pago de Servicio) en la aplicacin. Programar el clculo del DV de acuerdo a las reglas establecidas en el simulador. Identificar el NPE con la longitud mnima y mxima, dgito verificador valido para AMECE GS1 Mxico.

Notas a considerar:

El escner no lee el cdigo de barras si no fue generado correctamente El algoritmo del GS1 128 no necesita configuracin en el programa interno de la empresa ya que el propio escner valida si est bien generado el cdigo de barras o no. Distinguir entre un proveedor de servicios que trabaja bajo el uso de los estndares de AMECE GS1 Mxico y otro que no lo utilice. Esto a travs de la identificacin del estndar con los caracteres especiales de inicio. En cuanto a complicaciones que se obtuvieron fue configurar el escner tipo bscula y el de Hand held, donde solo se configuraron 2 marcas y se tardaron 2 das. Documentaron la configuracin del escner para futuras configuraciones.

Etapa 5. Generar reporteDurante la operacin de recepcin de pagos en Comercial Mexicana todas las transacciones se van acumulando en una tabla central. Cada noche el sistema de la cadena en forma automatizada extrae todos los pagos por proveedor de servicios en particular, y va generando un archivo plano (texto) con las columnas definidas por el proveedor y separadas por comas. Para el caso de Seguros Monterrey todas las columnas quedan definidas de la siguiente forma: 1. 2. 3. 4. 5. Fecha de pago Referencia Importe Tipo de Pago Lugar de pago

CONCLUSIONESEl desarrollar las pruebas piloto para un estndar permite identificar las mejoras o adaptaciones de acuerdo a la situacin y experiencia de las empresas involucradas. Estas pruebas facilitan que la adopcin del estndar sea ms comprensible para los sectores a quienes va dirigido. Para estas pruebas se estableci una metodologa la cual ayud a establecer la secuencia de pasos a seguir en el desarrollo de las pruebas; iniciando con la etapa de definicin en donde las distintas aportaciones de las empresas del grupo de trabajo impulsaron varias definiciones para el uso del cdigo de barras GS1 128 y el NPE que estaran impresos en los talones de pagos de servicios. Cada nueva definicin integraba necesidades del mercado para una correcta implementacin y uso del mismo ya en productivo. Las definiciones ayudarn a las empresas a anticiparse a posibles fallas o situaciones que pudieran presentarse una vez estn listas para los desarrollos a realizar. Cabe destacar que AMECE GS1 Mxico supervis que las definiciones realizadas estuvieran apegadas al estndar del sistema GS1. En la etapa de generacin del cdigo y NPE se tuvo que recurrir al conocimiento y prctica de proveedores de tecnologa especializados en el tema de cdigo de barras para la correcta generacin del cdigo GS1 128 utilizando un software tcnico dirigido para este propsito, as como recurrir al apoyo de GS1 en otros pases de acuerdo a su experiencia de implementacin del estndar de su regin, misma que llevara a una correcta emisin del cdigo. En base a la etapa de maduracin de este proyecto en otros pases, el grupo de trabajo obtuvo la informacin para identificar el software correcto y adecuado para la generacin del cdigo GS1 128. En cuanto a la generacin del NPE, la participacin de todos los sectores (proveedores de servicios, bancos, cadenas, tiendas de conveniencia, etc.) fue importante para acordar y establecer las caractersticas en la definicin del mismo, as como para la generacin y uso correcto del algoritmo a utilizar en esta lnea de captura estandarizada. En la etapa de lectura del cdigo y captura manual de NPE, se identific la importancia de la configuracin tcnica de los escneres para la correcta identificacin del cdigo GS1 128 debido a que en las primeras pruebas de escaneo no se reconocan los caracteres especiales de este cdigo. Con relacin a la captura del NPE y la obtencin de una correcta lectura del cdigo, se detect la necesidad de realizar un desarrollo interno en los sistemas de las empresas receptoras de pagos de servicios, ya que sin este desarrollo no sera posible obtener un buen resultado. En esta etapa AMECE GS1 Mxico contribuy en la verificacin de los cdigos generados a travs del apoyo del Servicio de Comprobacin de Datos (SECODAT). Para tener una visin ms amplia de los escneres que puede leer un cdigo GS1 128 se elabor un estudio para validar la aceptacin de tres pruebas de cdigos de barras en distintas marcas y modelos de fabricantes. Estas pruebas fueron aprobadas tanto por los usuarios de los escneres como por los fabricantes. En la etapa de desarrollo de aplicacin de sistemas, se cont con la cadena Comercial Mexicana como receptores, quienes ya contaban con una aplicacin para su terminal del Punto de Venta, por lo cual se simplific el trabajo de programacin para separar los campos contenidos en el cdigo de

barras GS1 128, y considerar las banderas de moneda y forma de pago, as como el reconocimiento del GLN para identificar el proveedor de servicio. Por el lado del emisor, Seguros Monterrey utiliz su plataforma de programacin orientada a objetos y base de datos Oracle para el desarrollo de su aplicacin de emisin de plizas de vida integrando el cdigo de barras GS1 128. En la etapa de generacin de reporte el grupo de trabajo acord utilizar los campos definidos para el cdigo de barras GS1 128 y NPE, los cuales fueron necesarios para el reporte. Este estudio de pruebas piloto sirvi para realizar ciertas definiciones que ayudan al despliegue del proyecto a futuro una vez que todos los participantes desarrollen los ajustes en los sistemas para la emisin o recepcin de los talones de pagos con el cdigo GS1 128 y el NPE estandarizado. Para llevar a cabo la masificacin de este proyecto, es necesario considerar los siguientes puntos: El mercado que se desea atacar, donde estn considerados los sectores para la emisin de los talones de pagos, tales como: telefona, entretenimiento, educacin, utilities, banca, aseguradoras, automotriz, gobierno, entre otros. Adems estn considerados los sectores para la recepcin de talones de pagos, tales como: banca, supermercados, farmacias, departamentales, tiendas de conveniencia, entre otros. Que las empresas a involucrarse entiendan que es un proyecto factible para implementarse con el fundamento de los resultados de las pruebas, as como el retorno de la inversin que el mismo representa. Las empresas receptoras que por primera vez deseen ofrecer este servicio a sus clientes, este documento les proporciona la referencia para que puedan conocer el tipo de escner que se estara utilizando para la recepcin de los talones de pago bajo estndar. Este documento sirve como un marco de referencia a las empresas interesadas en la implementacin del proyecto taln de pagos, al detallar las distintas etapas que debern seguirse en un piloto. Este documento brinda ideas de mejoras en los procesos actuales desarrollados por los participantes que ya estn implementando este proyecto.

ANEXO 1Anlisis realizado de la referencia bancaria por los nuevos bancos participantes en el grupo de trabajo de Taln de Pagos: Scotiabank: 3 rutinas de validacin de dgitos verificadores de uso ms comn. 2 de las rutinas son alfanumricas y se crean precisamente por la limitacin de la validacin en modulo o base 10, que es totalmente limitada a nmeros y emite un solo digito verificador. La mayor parte de sus clientes utilizan la validacin 97 (en el argot bancario) 7 para Scotiabank y que esta en los documentos que te envo, esta rutina es alfanumrica de una longitud de 30 posiciones, excluyendo la condensacin de la fecha, importe, constante y dejando nicamente los campos mnimos para la referencia se requiere 22 y 2 ms para los dgitos verificadores. Propuesta: Algoritmo: De mayor seguridad, diferente a modulo 10 Tipo: Alfanumrica Campos para el importe: 15 La definicin de la longitud minima (a consenso de todo el grupo). Bancomer: Servicio CIE (cobranza inmediata empresarial): % de Convenios con referencia numrica de 1 a 20 posiciones 68% % de Volumen de operacin de estos convenios 73% % de Montos operados por estos convenios 72% % de Convenios con referencia alfanumrica de 1 a 20 posiciones 32% % de Volumen de operacin de estos convenios 27% % de Montos operados por estos convenios 28% En la muestra de los convenios analizados, no se identific ninguno que utilice dentro de la referencias los datos de fecha e importe del pago Propuesta: Referencia alfanumrica de hasta 20 posiciones para no afectar la operativa de sus clientes actuales con la implementacin del cdigo GS1 128. Indispensable se identifique claramente la clave, convenio o cuenta con la que los bancos identifican al cliente beneficiario del depsito en los talones de pago. HSBC:

TIPO DE REFERENCIA

26%

74%

Referencia Alfanumrica Referencia Numrica

LONGITUD DE REFERENCIA

9% 22%

Hasta 16 posiciones Hasta 30 posiciones Hasta 40 posiciones 69%

MDULOS DE VALIDACIN

16% 11%

9%

6% 58%

Sin Validacin Validacin 2 DV Otros Mdulos

Validacin 1 DV Validacin Fecha e Importe

ANEXO 2Receptor Comercial Mexicana Marca NCR Modelo 7875 Especificaciones UPC/EAN/JAN Cdigo 3 de 9 (39) Cdigo 128 IL 2 de 5 Cdigos que se aaden peridicamente Modo de lectura de etiquetas mltiples Cdigo de cupones prolongados UPC/EAN/IAN Codigo 3 de 9 (39) Cdigo 128 IL 2 de 5 Capacidad de aadir cdigos Proveedor Lectura GS1-128, Marca Lectura GS1-128 Cadena/Banco

Farmacias Benavides

NCR

7892

Farmacias Benavides

Symbol

LS9100

Code 39 Code 128/EAN-128 UPC/EAN Interleaved 2 of 5 Codabar Discrete 2 of 5, IATA Code 93 Code 11 Code 49 MSI/Plessey Bookland, Trioptic Code 39, Coupon, NW7 UPC-A, UPC-E, UPCE1, EAN 8/13, JAN 8/13, UPC/EAN con suplementos, Cdigo 39, Cdigo 39 ASCII completo, Entrelazado 2 de 5, Discreto 2 de 5, Cdigo 128, UCC/EAN 128, ISBT 128, Codabar/NW7, Cdigo 93, Cdigo 11, Variantes de RSS UPC/EAN y con suplementos, cdigo 39, cdigo 39 ASCII completo, variantes RSS, UCC/EAN 128, cdigo 128, cdigo 128 ASCII completo, cdigo 93, Codabar (NW1),

OXXO

Symbol

LS7808

OXXO

Symbol

LS4278

OXXO

PSC / Datalogic

VS1000

entrelazado 2 de 5, discreto 2 de 5, MSI, Codell, IATA, Bookland EAN, cdigo 32. UPCA,E/EAN8,13/JAN8, 13 Con Edge (VS1 200 solamente) Con aditamentos P2 / P5 (Standard en VS1000, opcional en VS1200) Cdigos industriales: Cdigos 128 Cdigos 39 con stitching (VS1000 solamente) ITF (intercalado 2 de 5) MSI / Plessey (VS1000 solamente) Versiones UPC A & E UPC Supplementals (Bookland y Cdigo de cupn) UPC Add-ons (subtema 2, subapartado 5 & C128) EAN 8, 13 JAN 8, 13 EAN / JAN dos etiqueta UCC / EAN 128 Cdigo 39 (con ASCII completo) Cdigo 128

Solo tiene capacidad de leer 32 dgitos.

No s ley

OXXO

PSC / Datalogic

Magellan 8405

Chedraui

PSC / Datalogic

Magellan SL

Cdigo 93 Interleaved 2 de 5 Italiano Pharmacode Codabar/NW7 MSI / Plessey GS1 DataBar (RSS) Con software Edge: UPC/EAN/JAN: UPC-A / UPC-E EAN-8 / EAN-13 JAN-8 / JAN-13 UCC 128, P2 / P5 adicionales

Cdigos industriales: Cdigos 128 Cdigos 39 ITF (intercalado 2 de 5)Corvi Unitech PA600 UPC-A/E EAN-8/13 Codabar Code 39 Code 39 full ASCI Code 93 Code 32 Interleaved & Std. 2 of 5 EAN 128 Code 11 Delta MSI/Plessey Code 128 Toshiba

No ley el ltimo cdigo

Corvi

PSC / Datalogic

Magellan 8104

UCC / EAN 128

WalMart

Symbol Motorola

LS4208

UPC/EAN y con suplementos, cdigo 39, cdigo 39 ASCII completo, variantes RSS, UCC/EAN 128, cdigo 128, cdigo 128 ASCII completo, cdigo 93, Codabar (NW1), entrelazado 2 de 5, discreto 2 de 5, MSI, Codell, IATA, Bookland EAN, cdigo 32. UPC/EAN y con suplementos, cdigo 39, cdigo 39 ASCII completo, variantes RSS, UCC/EAN 128, cdigo 128, cdigo 128 ASCII completo, cdigo 93, Codabar (NW1), entrelazado 2 de 5, discreto 2 de 5, MSI, Codell, IATA, Bookland

WalMart

Symbol Motorola

LS4278

EAN, cdigo 32. Casa Ley PSC / Datalogic Magellan SL Con software Edge: UPC/EAN/JAN: UPC-A / UPC-E EAN-8 / EAN-13 JAN-8 / JAN-13 UCC 128, P2 / P5 adicionales

Cdigos industriales: Cdigos 128 Cdigos 39 ITF (intercalado 2 de 5)Casa Ley PSC / Datalogic Magellan 8100 UCC / EAN 128

Casa Ley

PSC / Datalogic

Magellan 8400

UCC / EAN 128

Casa Ley

PSC / Datalogic

Magellan 8500

UCC / EAN 128

Banorte

Welch Allyn

T3800, 3800PDF12

EAN-8, EAN-13, UPC-A, Code 93, UPC-E, Code 128, CODABAR, Interleaved 2 of 5, PDF417, Code 11, RSS, Code 3 of 9, Matrix 2 of 5, Chinese Postal

Scotiabank

No tiene

No tiene

GS1 Japn

Denso Wave

HC56

UCC/EAN-128

GS1 El Salvador GS1 Colombia

No tienen informacin No tienen informacin

ANEXO 3Nota: Se indican en color verde las pruebas que cumplen con la Descripcion del Caso ingresando los Datos de Entrada descritos. Se indican en color rojo las pruebas que no cumplen con la Descripcion del Caso ingresando los Datos de Entrada descritos. CASOS DE PRUEBA Retail/Banco Fecha de ejecucin ID del Caso

Descripcin del caso

Datos de entrada

Valores (NPE/Barra)

Resultado Obtenido

LCB

NPE

Comentarios

1

LC (lnea de captura: Barra/NPE) que 1) LC (factura 1) permite pagar con pesos cualquier importe 2) Pago con cheque en cualquier fecha. 500 pesos

7500 0400 0001 2349 6123 4563 0084 (415)7504001004003(90)0000(8020)123496123456

Se cobra correctamente el pago de servicio por un monto de 500 pesos con ambos valores de entrada NPE/Barra. Se cobra correctamente el pago de servicio por un monto de 100 dolares con ambos valores de entrada NPE/Barra.

2

1) LC (factura 1) LC que permite pagar con dlares cualquier 2) Pago con efectivo importe en cualquier fecha. 100 dlares

7500 0400 0001 2349 6123 4563 0084 (415)7504001004003(90)0000(8020)123496123456

3

1) LC (factura 2) LC que permite pagar con pesos cualquier 7500 0400 0001 2349 6123 4883 0012 2) Pago con efectivo importe en cualquier fecha (415)7504001004003(90)0000(8020)123496123456 1500.25 pesos

Se cobra correctamente el pago de servicio por un monto de 1500.25 pesos con el valor de entrada Barra.

No se puede cobrar correctamente el pago de servicio por un monto de 1500.25 pesos con el valor de entrada NPE, debido a que el digito verificador "12" es incorrecto, debiendo ser "94".

Nota:

Se indican en color verde las pruebas que cumplen con la Descripcion del Caso ingresando los Datos de Entrada descritos. Se indican en color rojo las pruebas que no cumplen con la Descripcion del Caso ingresando los Datos de Entrada descritos. CASOS DE PRUEBA Retail/Banco Fecha de ejecucin

ID del Caso

Descripcin del caso

Datos de entrada

Valores (NPE/Barra)

Resultado Obtenido

LCB

NPE

Comentarios

4

LC en pesos a pagar con pesos un mnimo 1) LC (factura 3) de 1,000.00 pesos, vlida hasta el 2) Pago con efectivo 30/09/2009 1,000.00 pesos

7500 0400 1000 2770 0100 0009 6123 4562 2192 (415)7504001004003(90)0100(96)0277(3902)100000(8020)9612 3456

Se cobra correctamente el pago de servicio por un monto exacto de 1000 pesos con ambos valores de entrada NPE/Barra.

5

LC en pesos a pagar con pesos un mnimo 1) LC (factura 4) 7500 0400 1000 0910 0100 0009 6123 4562 2147 de 1,000.00 pesos, vlida hasta el 2) Pago con efectivo (415)7504001004003(90)0100(96)0091(3902)100000(8020)9612 30/03/2009 1,000.00 pesos 3456