Servicio de Pago en Línea entre la Tesorería General
Anuncio
Servicio de Pago en Línea entre la Tesorería General de la República, las Instituciones Públicas y las IRAS suscritas al Servicio de Pago Electrónico 2011.11.18 Modelo General PPE_V42 1 1. Introducción 1.1. Antecedentes Generales El Supremo Gobierno ha resuelto convertir al sitio Web de la Tesorería General de la República (TGR) en el “Portal de Pagos del Estado”, de forma tal que los ciudadanos cuenten con un servicio ágil, eficiente, moderno y con empleo de tecnología interactiva, que les permita, a través de Internet por medio de una “ventanilla única”, efectuar pagos tanto de impuestos como de productos, servicios y/o derechos de otros Instituciones Públicas (IPs en adelante), y obtener los respectivos documentos de certificación de dichos pagos. Es así como Tesorería (TGR en adelante) ya ha efectuado los desarrollos e implantaciones para realizar, a través de su sitio, los pagos de productos y servicios de diversas IPs. El presente documento establece los requerimientos necesarios para que cualquier IP lleve a cabo la implementación del pago electrónico de los productos que entrega a sus usuarios a través de Internet, y por los cuales se requiera realizar un pago. 1.2. Alcances El sistema que a continuación se describirá, permitirá efectuar el pago electrónico de los productos y servicios solicitados por una persona en el sitio Web de la IP. En este sitio, al solicitar pagar electrónicamente, el cliente accederá en forma transparente para él a los medios de pago del portal Web de la TGR, para en ese lugar podrá escoger la Institución Recaudadora Autorizada (IRA) con la cual desea pagar el producto seleccionado en un principio. Se ha determinado que los pagos pueden ser de tres tipos: completamente de beneficio fiscal, completamente de beneficio de la IP, o mixtos, lo que quedará definido en el acuerdo que la IP y TGR firmen, y que definirá la forma de egresar los pagos. Los mensajes de pago que se generen electrónicamente en el portal Web de la IP, serán enviados a TGR utilizando Objetos a través de un Servicio Web con protocolo Soap o mediante la utilización de MQ Series, lo que será de responsabilidad de la IP. Los datos son recibidos y validados en TGR y se almacenarán en las bases de datos de la TGR. Una vez ingresados, estarán disponibles de inmediato para su pago en forma electrónica, como cualquiera de las otras obligaciones que existen en las bases de datos de la TGR. La IP deberá definir si la deuda puede o no ser vista por el deudor después de la fecha de vencimiento informada en el mensaje que informa la deuda (M1). El sistema está diseñado para que el solicitante realice los pagos en línea. En el caso que el solicitante realice efectivamente el pago en la IRA de su elección, y en cuanto la IRA informe a Tesorería de este evento, se generará un mensaje de Informe de Pago en línea (M2) hacia la IP, avisando esta situación. Modelo General PPE_V42 2 El sistema de mensajería funcionará 7x24x365 (con suspensión entre las 23:50 y las 00:10 hrs). Esto último es un acuerdo con las IRA’s para que no haya problema de cambio de día en los pagos, por las diferencias horarias que pudieran existir entre los relojes de los servidores de TGR y las IRAS. TGR y la IP establecerán un sistema de cuadraturas, tanto de mensajes como de montos en forma diaria, para asegurar la consistencia del sistema. El sistema de cuadraturas contempla el envío de un mensaje (MC) con todos los pagos recibidos por la IP a un servicio web que dispone la TGR, este servicio entrega por respuesta un “OK” si recibe bien la cuadratura o un “NOK” si no lo puede recibir bien (pueden existir time outs también). Una vez recibido este mensaje y en el mismo día o día hábil siguiente, se realizará un procesamiento de esa información en la TGR y el resultado de ese proceso (pareo de pagos informados por la IP con lo que tiene la TGR en sus bases, posteriormente a la cuadratura de las IRAs) generará un mensaje MR (con la misma estructura del MC) que será enviado por TGR a la IP a un servicio web que disponga para ello. Este servicio deberá entregar un “OK” si recibe bien el mensaje MR o un “NOK” si no lo puede recibir bien. Los valores que la IP informe a pagar, estarán dentro del mensaje. Internamente, TGR informará estos montos a la División de Finanzas Públicas, para que los totales recaudados se depositen en la cuenta corriente que la IP haya definido en el acuerdo marco, si corresponde (caso con ingresos propios). Lo importante de este sistema es que apunta a unificar en un solo lugar el pago de derechos, multas, productos y servicios que los ciudadanos realizan a favor del Estado. Por otra parte, se establece que la TGR, debido a su experiencia en el tema, es la institución que controlará la recaudación de los recursos por parte de las IRAS. 1.3. Objetivo del Proyecto Crear, a través de los Servicios Web de cada institución y/o la utilización de MQ Series, un sistema de interconexión entre la Institución Pública (IP), la Tesorería General de la Republica (TGR) y las IRAS incorporadas al sistema de pago electrónico, con el objeto de implementar el servicio de pago de los productos y servicios que la IP entrega electrónicamente a sus usuarios. 2. Requerimientos del Proyecto. 2.1. Requerimientos Funcionales del Proyecto. Implementar un proceso de pago ágil de modo que los usuarios desde el Sitio de la IP puedan, en una misma “sesión”, realizar todas las operaciones establecidas para la realización de un pago electrónico, sin que exista una discontinuidad en el proceso. Para ello se deberá utilizar como sistema de comunicaciones el sistema de mensajería MQ Series y/o Servicios Web (Basado en Protocolo Soap). Implementar servicios de pago en línea, de manera tal que los montos sean definidos en la IP y recaudados por TGR. Modelo General PPE_V42 3 Implementar los servicios de envío de Documentos Electrónicos de Pago, pago en línea con las Instituciones Recaudadoras Autorizadas (IRA’s), respuesta a la IP y Cuadraturas diarias, todo soportado en el esquema de mensajería vía Servicios Web o MQ Series. Implementar estos servicios de manera genérica a través de la definición de mensajes basados en clases u objetos. Los cuales serán soportados vía Servicios Web o Mq Series. 2.2. Requerimientos Técnicos del Proyecto. Utilización de Servicios Web y/o MQ Series para la transmisión de mensajes entre la IP, TGR y las Instituciones Recaudadoras Autorizadas (IRA). Realización de operaciones y recepción de respuestas de modo online en el Sistema, para los giros, pagos y cuadraturas. Definición de una estructura administrativa para soportar el sistema electrónico. 3. Interconexión y Flujo de las Comunicaciones. 3.1. Descripción del proceso de pago en línea: Caso 1: Cliente ingresa al sitio de la IP y allí ingresa la información del giro (1). El cliente, mediante un computador conectado a Internet, entra al Sitio Web de la IP, selecciona el (los) producto(s) que desea pagar, llena los datos que correspondan y da la instrucción de pago. (2). La IP informa el pago a la TGR (mediante Servicio Web o Mq Series), el browser (en forma paralela) del cliente es redireccionado hacia el sitio Web de la TGR. El giro ya registrado en las bases de la TGR es seleccionado y preparado para enviarlo a cualquiera de las Instituciones Recaudadoras Autorizadas (IRAs). Los datos del o los productos a pagar que envía la IP, incluyen un identificador único de la o las “deudas” a pagar, generado en el sitio de la IP. (Toda la acción de recepción, validación y registro de los datos enviados por la IP y recepcionados por la TGR, son transparentes para el cliente). Caso 2: Cliente ingresa al sitio de la TGR y allí ingresa la información del giro. Si el cliente desea pagar inmediatamente puede hacerlo, seleccionando el giro presionando el botón de pago en línea. Nota de aquí en adelante el proceso es común a ambos casos. (3). Una vez que se presenta la página de medios de pago de la TGR, el cliente tendrá la posibilidad de seleccionar cualquiera de las IRAs para realizar el pago. Hecho esto, los datos de la transacción son ingresados y enviados desde TGR a la IRA elegida. Modelo General PPE_V42 4 (4). En ese momento es la IRA la que toma el control del pago. Ésta consulta a la Tesorería por la o las “deudas” asociadas con un identificador único asignado al pago en proceso. El servidor de Tesorería toma la consulta, prepara los datos y devuelve en un mensaje la lista de la o las “deudas” seleccionadas para pago. El sitio Web de la IRA toma la respuesta a la consulta y presenta el detalle de las obligaciones a pagar. Estando en el sitio de la IRA, la persona se identifica como cliente de dicha institución y autoriza el cargo en su cuenta bancaria, de casa comercial o tarjeta de crédito, por el monto de la obligación identificada en un principio en el sitio de la IP. (5). Una vez que el cliente ha realizado el pago, la confirmación de éste es enviada desde la IRA a la TGR. Recibida dicha confirmación en la TGR, se realiza el cambio de estado de la deuda en las Bases de Datos de Tesorería, dejándola pagada. (6). Luego, la misma confirmación es enviada hacia la IP. Para ello, se tiene un programa residente en el servidor de la TGR, el que se encarga de enviar el correspondiente mensaje hacia la IP mediante el tipo de mensajería establecido entre las instituciones. (7). Mientras todo el proceso de mensajería ocurre oculto para el cliente, al finalizar el pago, la IRA lo devuelve a la página de resultados del sitio de Tesorería, en la cual podrá imprimir un comprobante de pago, si lo desea. Dicho comprobante tiene un número, necesario para obtener posteriormente el Certificado de Pago con timbre digital si lo requiere. (8). Finalmente, el cliente vuelve al sitio de la IP, donde también se le presenta el estado de su deuda como pagada, o se queda en la de TGR dónde también puede obtener un comprobante del pago en línea. Modelo General PPE_V42 5 Figura Nº1: Diagrama Modelo de Pago; flujo de Información y mensajes (ingresando desde la IP) (2) Envía datos con identificador único de la deuda. (1) www.ip.cl Selecciona obligaciones a pagar y da instrucción de pago. C O N T R I B U Y E N T E O C L I E N E T E (4.1) Consulta a TGR por datos de la Deuda a Pagar. (4.2) Envía datos con el Nº identificador único. I P (8) Presenta estado de deuda como “Pagada”. (6) Envía mensaje del pago de la deuda con identificador único. (5) Envía confirmación del pago a TGR. T G R (3.1) Presenta Medios de Pago al cliente. (3.2) Escoge Medio de Pago (la IRA). I R A (7) Presenta comprobante de pago con código de transacción. (9) Solicita Certificado de Pago con timbre digital. (4.3) Presenta detalle de la obligación a pagar. (4.4) Se autentifica como cliente del Banco y autoriza el cargo en su cuenta (paga). Modelo General PPE_V42 6 3.2. Definición de Mensajería INSTITUCION PUBLICA - TESORERIA PAGO EN LINEA SERVICIO WEB RECIBE INFORME DE DEUDA La Tesorería General de la República (TGR) pone a disposición un Servicio Web que permitirá almacenar la información de la deuda, información que será ocupada para el posterior pago de la misma. Los Servicios Públicos (Giradores) deberán disponer de un servicio web que les permita recibir las confirmaciones de pagos si corresponde. Requerimientos Técnicos La Tesorería General de la República (TGR) provee Servicios Web para la transmisión de objetos entre los Servicios Públicos (Giradores) y TGR, a través del puerto de seguridad https, utilizando autenticación WS-Security con token que contempla usuario y contraseña. Para acceder a los servicios que ofrece TGR, se debe utilizar WSDL (Web Services Definition Language). WSDL es un lenguaje descriptor, basado en XML, que permite conocer en forma abstracta, la gramática de los componentes de un Web Service (ubicación, formato, tipos de datos, servicios, funciones, parámetros de entrada, salida, etc.). Cuando el cliente conoce el WSDL del servicio, puede construir un Request en formato SOAP (Simple Object Access Protocolo), para luego enviarlo hacia el proveedor de servicio, previa Autenticación. Se utilizarán clases de objetos para la comunicación de las consultas de los Servicios Web. Definición del Objeto El Servicio Web recibirá los siguientes objetos para realizar el registro de la información de la deuda: MessageId Campo code msgDesc from ref datetime idExt Tipo Dato Alfanumérico Alfanumérico Alfanumérico Numérico Fecha Numérico Largo Máx. Obligatorio Descripción 6 Si Código de tipo de mensaje. Valor único: M1 20 Si Descripción del mensaje “Informa Deuda” 20 Si Sigla del girador 3 Si Identificador del girador 19 Fecha y hora de la transacción. Formato Si datetime YYYY-MM-DDThh:mm:ss 20 Identificador del mensaje. Largo único de 20 Si dígitos Modelo General PPE_V42 7 Deuda Campo idDeuda detalleDeuda Tipo Dato IdDeuda Item[] Obligatorio Descripción Si Objeto Identificador de la deuda Si Lista de items del detalle de la deuda idDeuda Campo rut dv formulario folio vencimiento moneda monto movimiento Tipo Dato Numérico Alfanumérico Numérico Numérico Fecha Alfanumérico Numérico Largo Máx. 10 1 3 10 8 3 15.4 1 Alfanumérico Obligatorio Si Si Si Si Si Si Si Si Descripción Rut del deudor Dígito verificador del rut Número identificador del formulario Folio de la transacción Fecha de vencimiento de la deuda: Formato YYYY-MM-DD Sigla de moneda o unidad asociada al monto de la deuda. “CLP”;”UF”, “UTM” Monto de la deuda. Largo máximo 15.4 Movimiento que representa la transacción. Valores Fijos: C para cargo del giro, D para descargo o anulación. Item Campo codigo contenido Tipo Dato Numérico Alfanumérico Largo Máx. 5 30 Obligatorio Descripción Si Código del ítem Si Contenido del ítem Como respuesta, el Servicio Web devolverá un String con el mensaje “OK” en el caso de transacción exitosa, y una excepción con el mensaje de error en el caso de algún problema. Notas: idExt : Identificación única de la deuda que se envía en la base de datos de la IP de la deuda que se envía. Su estructura es la siguiente: X(20)…….“GGGFFF12345678901234” En que los campos son los siguientes: X(03)…….”GGG”: Código del girador de la deuda (dado por Tesorería). X(03)…….”FFF”; Número del formulario requerido (dado por Tesorería). X(14)…….Correlativo generado por el girador (En producción comenzar con 00000000000001). M1 y M2 no deben contener acentos, eñes, comas o apóstrofes. Modelo General PPE_V42 8 Mensaje M2: Tesorería Confirma Pago en Línea (opcional) El mensaje M2 está definido como un string con estructura XML, de la siguiente manera: Etiqueta <Message> <MessageId> <Code> <MsgDesc> <Version> <FromAddress> <ToAddress> <RefAddress> <DateTime> <Number> <IdExt> <Status> </MessageId> <Confirmacion> <Pago> <IdOperacion> <IdTransaccion> <Rut> <Formulario> <Folio> <Vencimiento> <TotalPago> <Ira> <Codigo > <Nombre> </Ira> <FechaPago> <TipoPago> <Resultado> </Pago> </Confirmacion> </Message> Tipo Dato Largo Máximo Alfa Alfa Numérico Alfa Alfa Numérico Fecha 6 20 2 20 20 3 19 Numérico Numérico Alfa 10 20 3 Numérico Numérico Numérico Numérico Numérico Fecha Numérico 16 16 10 3 10 10 12 Numérico Alfa 3 30 Fecha Alfa Numérico 19 1 1 Descripción Inicio del mensaje Inicio de bloque "M2" "Confirma Pago" "1" (inicialmente) "TESORERIA" Destino del mensaje Origen del mensaje M1 "GGG" Código asignado a la institución Fecha de generación del mensaje. "dd-mmyyyy hh:mm:ss" Vacío "GGGFFF" + correlativo de 14 caracteres “OK” Fin bloque Inicio bloque Inicio bloque FFF: Número del formulario asignado “dd-mm-yyyy” Inicio de bloque Código Abif de la Institución Bancaria Nombre de Ia Institución Fin de bloque “dd-mm-yyyy hh:mm:ss” “E”: Electrónico; “M”: Manual “0”: Aprobado; “1”: Rechazado Inicio bloque Fin bloque Fin de mensaje Nota: Una vez transmitido el M2 (aviso de pago) la TGR espera de vuelta una respuesta tipo String que diga “OK”, en el caso que la IP reciba el mensaje y lo pueda registrar correctamente en sus sistemas (sin procesarlo aún). En el caso de haber algún problema con la respuesta hacia TGR (cualquier cosa distinta de OK, incluyendo TimeOut), se considera que el mensaje NO ha llegado correctamente a destino y éste se ingresa a un sistema de reenvíos automático, que repetirá 3 veces el envío con espacios de 1 hora. Puede ocurrir que la IP si haya registrado el M2, pero por algún motivo no pudo responder OK a la TGR, por tanto cuando la IP vuelva a recibir el M2 y comprobar que ya lo habían registrado, se debe ignorar este mensaje, y se debe responder “OK” para que la TGR se de por enterada de la recepción conforme del M2 y deje de reintentar el envío. Así los dos sistemas quedan seguros que el otro recibió una respuesta adecuada. Modelo General PPE_V42 9 4. Cuadraturas y Rendición de los dineros Recaudados. 4.1. Control de cuadraturas diarias. El propósito de las Cuadraturas Diarias es que las IPs informen electrónicamente todos los pagos que tienen registrados en sus bases de datos. El procedimiento consiste en lo siguiente: Al día siguiente de efectuados los pagos, a más partir a las 13:00 hrs y no más allá de las 15:00 hrs., la IP generará y enviará un Mensaje de Cuadratura (MC) a la TGR, utilizando el formato actualmente en uso para los pagos electrónicos, con todas las operaciones de pago efectivamente registradas durante el día anterior (día se entiende el que transcurre entre las 00:00:00 y las 23:59:59 hora chilena continental). La Tesorería tomará estos mensajes y comparará los pagos enviados y confirmados por la IRA y la IP, con los registrados en sus bases de datos. De haber inconsistencias, éstas se resolverán durante el día siguiendo el proceso administrativo acordado, hasta que se cuadre por completo la información de pagos realizados, tanto por parte de la Tesorería como por parte de la IRA y la IP. Es la TGR la que envía a la IP el último mensaje con el resultado final y acordado de la cuadratura (MR), cuestión que debe hacer antes de la 17:00 hrs. del día hábil siguiente al pago. Las cuadraturas correspondientes a pagos realizados en días viernes, sábado y/o domingo, se entregarán el día lunes siguiente, en el horario establecido, en mensajes separados (un archivo por cada día). Las cuadraturas correspondientes a pagos realizados en días feriados, se entregarán al día hábil siguiente, en el horario establecido. En caso de haber dos o más días feriados seguidos, las cuadraturas también se entregarán en mensajes separados (un archivo por cada día), el día hábil siguiente. El mensaje de cuadratura debe enviarse haya o no pagos diariamente, con el fin de eliminar incertidumbres de posible falla en las comunicaciones. 4.2. Control de Recaudación y Depósito de Remesas. Esta rendición consiste en un procedimiento entre las IRA y TGR, transparente para las IP, mediante el cual las IRAs certifican la cantidad y monto recaudados, y su posterior proceso de depósito en la Cuenta Única Fiscal de la TGR al tercer día hábil siguiente del pago, por concepto de Pagos de productos o servicios emitidos por la IP. Posteriormente, a más tardar al segundo día hábil siguiente de recibida la confirmación del depósito en CUF por parte de la IRA, Tesorería abonará los dineros recaudados en la Cuenta Corriente del Banco Estado que cada IP defina (en caso de ser dineros propios y no del fisco). Esto da un total de 5 días hábiles para el depósito en la cuenta de la IP. Modelo General PPE_V42 10 4.3 Mensaje MC: Cuadratura (es un string con estructura con xml) Ejemplo de mensaje MC, utilizado para cuadratura. El MR es equivalente en forma, cambiando sólo origen-destino. Etiqueta Tipo Dato Largo Máximo <Message> <MessageId> <Code> <MsgDesc> <Version> <FromAddress> <ToAddress> <RefAddress> Alfa Alfa Numérico Alfa Alfa Numérico 6 20 2 20 20 3 <DateTime> Fecha 19 Numérico Numérico Alfa 10 20 3 Numérico Numérico Numérico Numérico Numérico Fecha Numérico Fecha Numérico 16 16 14 3 10 10 12 19 3 Numérico Numérico 10 15 Numérico Numérico 10 15 Numérico Numérico 10 15 Numérico Numérico 10 15 <Number> <IdExt> <Status> </MessageId> <Cuadratura> <Lista> <Item nro=”1”> <IdOperacion> <IdDeuda> <RutRol> <Formulario> <Folio> <FechaVencimiento> <Monto> <FechaPago> <Resultado> </Item> </Lista> <Control> <Total> <Cantidad> <Monto> </Total> <Aceptados> <Cantidad> <Monto> </ Aceptados> <Rechazados> <Cantidad> <Monto> </Rechazados > <Anulados> <Cantidad> <Monto> </Anulados> </Control> <Cuadratura> </Message> Descripción Inicio del mensaje Inicio de bloque "MC" "Cuadratura TGR" "1" (inicialmente) Origen del mensaje "TESORERIA" "GGG" Código asignado a la institución Fecha de generación del mensaje. "dd-mmyyyy hh:mm:ss" Fecha de los pagos “aaaammdd” Vacío “OK” Fin de bloque Inicio de bloque Inicio de bloque Inicio de bloque, se repite “n” veces FFF: Número del formulario pagado “dd-mm-aaaa” “dd-mm-aaaa hh:mm:ss” “0”: Aprobado; “1”: Rechazado Fin de bloque Fin de bloque Inicio de bloque Inicio de bloque Cantidad total de pagos Monto total de pagos Fin de bloque Inicio de bloque Cantidad de pagos aceptados Monto de pagos aceptados Fin de bloque Inicio de bloque Cantidad de pagos rechazados Monto de pagos rechazados Fin de bloque Inicio de bloque Cantidad de pagos anulados Monto de pagos anulados Fin de bloque Fin de bloque Fin de bloque Fin del mensaje Modelo General PPE_V42 11 5. Depósito de la Recaudación en la Cuenta Corriente de la IP y Registro del Egreso en CUT. Recibida la certificación el depósito por parte de cada IRA, Sección Explotación de Sistemas informará al Departamento de Finanzas Públicas de la TGR el monto de los dineros recaudados y su depósito en la CUF por el concepto que haya dado origen al pago, para que dicho Departamento realice el traspaso electrónico correspondiente a la cuenta abierta por la IP (si corresponde) en el Banco Estado y acordada en el convenio firmado con TGR. El Departamento de Finanzas Públicas, una vez recibida la confirmación del depósito por parte de Explotación de Sistemas, realizará el traspaso de los fondos a la Cuenta Corriente de la IP; Asimismo, solicitará la generación del egreso automático al Sistema Automatizado de Egresos (SAE). Finalmente, la IP podrá tener acceso vía Internet en el sitio de TGR, por medio de una cuenta, a la información detallada del egreso efectuado: monto depositado, monto recaudado por cada IRA y fecha de la recaudación. Modelo General PPE_V42 12 Figura Nº 2: Diagrama de Flujo Cuadraturas, Rendición y Depósitos IRA Construye y envía Archivo de Cuadratura TGR Internet / Exp. De Sistemas TGR Dpto Finanzas Públicas IP Recibe Archivo y confirma Cuadratura Construye Archivo electrónico de depósito Deposita en CUF Envía Archivo electrónico Valida archivo electrónico de depósito Informa que Depósito se hizo Envía archivos con detalles de pagos por IRA Recibe confirmación del Depósito Realiza traspaso de fondos a IP Depósito en CTA CTE Construye Caja Electrónica Carga en CUT Genera Egreso automático SAE Modelo General PPE_V42 13 ANEXO 1 REDIRECCIÓN (En el caso de pago en línea inmediato) Para ingresar a la página de Medios de Pago de la TGR la IP debe hacer una redirección del navegador del cliente a la siguiente URL en TGR: Ambiente de Desarrollo: http://desa.tesoreria.cl/portal/portlets/pagos_externos/pagosExternosController.jpf?idext=p1&org=p 2 Ambiente de Test: http://test.tesoreria.cl/portal/portlets/pagos_externos/pagosExternosController.jpf?idext=p1&org=p2 Ambiente de Producción: http://www.tesoreria.cl/portal/portlets/pagos_externos/pagosExternosController.jpf?idext=p1&org=p 2 Esta redirección tiene dos parámetros que son: El parámetro p1 es el “Identificador único” dado por la IP (número a lo más de 20 caracteres). El parámetro p2 es el la sigla del servicio asignada por TGR, NO el código de Girador. SERVICIO WEB Para probar el servicio web que recibe los datos en TGR se debe utilizar la siguiente dirección URL dónde se encuentra el descriptor del servicio. Ambiente de Desarrollo: http://desa.tesoreria.cl/RecibeM1Web/RecibeM1WS.jws?WSDL Ambiente de Test: http://test.tesoreria.cl/RecibeM1Web/RecibeM1WS.jws?WSDL Ambiente de Producción: http://www.tesoreria.cl/RecibeM1Web/RecibeM1WS.jws?WSDL El método a usar (operation name) es: recibeM1 Modelo General PPE_V42 14 CUADRATURAS Para el envío de las cuadraturas (Mensaje MC), se debe utilizar los siguientes servicios web y métodos: Ambiente de Desarrollo: http://200.111.54.46/SoapListener/CuadraturaSOAP3_VB.WSDL Ambiente de Test: http://cuadra.tesoreria.cl/SoapListener/CuadraturaSOAP3_VB.WSDL Ambiente de Producción: http://cuadra.tesoreria.cl/SoapListener/CuadraturaSOAP3_VB.WSDL El nombre cuadra.tesoreria.cl está asociado a las siguientes IPs, para que las habiliten: - - 164.77.244.246 201.238.239.214 190.151.20.7 190.196.70.247 El método a usar es el mismo en desarrollo y producción (operation name): Escribir (p1, p2, p3) El parámetro p1 es el MC definido para informar los pagos en formato XML, y tiene que ser definido como string y no como objeto. El parámetro p2 debe ser la fecha de pago en formato “AAAAMMDD”. En que AAAA representa el año, MM el mes y DD el día, anteponer “cero” a los meses y los días de menos de 2 dígitos. El parámetro p3 debe ser el código asignado a la institución, y que debe ser el mismo de la etiqueta <RefAddress> de los mensajes. Este servicio web entrega un “OK” si recibe bien la información y la puede almacenar en la base de datos y un “NOK” si no la recibe bien o no la puede guardar. Si la falla de recepción persiste en reiterados intentos, usar email como método de contingencia hasta superar el problema (avisar a encargados de producción). La respuesta del servicio que recibe el MC NO es un XML, es una variable String que contiene “OK” o “NOK” solamente. En los servicios que reciben el MC y entregan el MR, las respuestas son funciones que entregan resultados de tipo String. No se entregan los resultados en las mismas variables por referencia, sino que por valor. Cualquier duda a este respecto es mejor aclararla durante el desarrollo del proyecto. NOTAS: En las etiquetas de los campos que contienen Fechas y Horas el formato debe ser estricto, los días y meses deben venir con 2 caracteres ejemplo: día 3 debe decir “03”, el mes 5 debe decir “05”. Los Modelo General PPE_V42 15 años deben venir con 4 caracteres. Las horas por ejemplo: 9 horas con 3 minutos y 5 segundos debe venir como “09:03:05”. Siempre hay que anteponer los ceros que se necesiten, para que no falle la lectura de los formatos. En el caso del M1 hay un formato estándar para el manejo de fechas y horas que se usa para los servicios web ejemplo: (yyyy-mm-ddTHH:mm:ss). El campo <Status> lo llena el Servicio Girador con un OK cuando envía cualquier mensaje (que lo contemple), TGR responderá OK o NOK en ese campo de acuerdo a la situación que corresponda. EL MR tiene la misma estructura, pero cambia el origen-destino, la fecha de generación (DateTime) y el Status permite decidir si el conjunto de los pagos están cuadrados o no y la etiqueta <Resultado> si el pago en particular está o no cuadrado (Resultado=0 aceptado, Resultado=1 rechazado). Modelo General PPE_V42 16 ANEXO 2 PASOS NECESARIOS PARA LA INTERCONEXION INICIAL Para realizar la interconexión con el Portal de Pagos del Estado, es necesario seguir o validar los siguientes pasos. 1.- Qué la IP pueda “ver” el archivo descriptor del servicio web que ingresará la deuda (M1) en la Tesorería General de la República (TGR). Esto debe ser hecho desde las máquinas de la IP que generarán el mensaje M1 con la deuda hacia el sitio de la TGR. En caso de ser un servicio especial y no disponer de la uri en particular para el caso, se puede probar verificando la siguiente uri de otros servicios web que dispone la TGR. Pruebas por ambiente: las direcciones para probar los servicios se encuentran en el anexo 1 Esta prueba se puede hacer mediante un navegador o mediante un telnet a la puerta 443, desde la máquina que generará el M1. 2.- Qué la TGR pueda “ver” el archivo descriptor del servicio web que recibirá el informe de pago (M2) pago de una deuda en el caso que una Institución Recaudadora Autorizada (IRA) la informe como pagada. La TGR necesita ingresar en su firewall la url a la cual se despachará el pago. 3.- La IP debe poder “ver” la uri del servicio descriptor de la TGR que recibe el informe con los pagos diarios (MC) denominados Cuadraturas (en Anexo 1) que tiene registrados en sus bases de datos. 4.- La TGR debe poder “ver” el archivo descriptor de la IP al cual debe despachar el MR con el resultado final de la Cuadratura. Modelo General PPE_V42 17 PASOS PARA CERTIFICAR FUNCIONAMIENTO DEL PORTAL DE PAGOS CON LA INSTITUCION PÚBLICA (IP) Para validar que todo el sistema de pagos del Portal de Pagos del Estado (PPE) que ofrece la Tesorería se han definido los siguientes pasos a seguir. Todos los pasos deben seguirse en cada uno de los tres ambientes con que cuenta la TGR (desarrollo, test y producción), con la salvedad que en producción se hace sólo un pago controlado para verificar que todos los procesos de egresos (que no se realizan en los otros ambientes estén bien). 1. IP valida conectividad con servidor de TGR que recibe el giro (M1) [desarrollo, test, producción] 2. TGR valida conectividad con servidor de IP que recibe el mensaje de pago (M2) 3. TGR valida recepción de M1 4. IP valida recepción de respuesta OK de TGR 5. TGR valida estructura de mensaje M1 6. IP realiza pago de deuda ingresada en banco de prueba de TGR 7. TGR valida realización de pago 8. IP valida la recepción de M2 9. IP realiza 4 o 5 pagos más para poder generar una cuadratura 10. IP prueba conectividad con servidor de TGR que recibe el mensaje de cuadratura (MC) 11. TGR valida recepción de MC 12. TGR revisa estructura de mensaje MC 13. TGR prueba conectividad con servidor de GIR que recibe MR 14. TGR realiza cuadratura 15. TGR envía mensaje de respuesta a la cuadratura (MR) 16. IP valida la recepción del mensaje MR 17. TGR realiza el proceso de generación de depósitos 18. TGR realiza depósito en cuenta informada por GIR en documento de cooperación 19. IP valida la recepción del depósito en su cuenta corriente Modelo General PPE_V42 18 PREGUNTAS FRECUENTES - - - - - - - - - - En el caso que el M2 no llegué inmediatamente en línea una vez realizado el pago, se sugiere que la IP disponga de un link en su sitio que permita al cliente revisar en forma posterior si el pago ha llegado, para poder obtener su producto, en el caso que éste no sea enviado en forma automática. Tanto para el M2 y el MC se espera un “OK” de vuelta. Este OK se debe devolver en el momento en que su sistema logre recibir el mensaje y lo pueda guardar a disco, base de datos, etc., de tal forma que ante alguna falla de un proceso interno puedan reintentar el proceso en forma completa sin que TGR deba enviar nuevamente el mensaje. Para los reenvíos de M2 por parte de TGR estos se harán una vez en línea y de no recibir “OK” se pondrá el mensaje en forma automática en un proceso que lo reenvía 1 vez más cada hora durante 3 horas. Si aún después de los reintentos no hay un OK, no se vuelve a enviar automáticamente, y sólo será reenviado si el girador lo requiere mediante un aviso a los encargados del proceso en el área de producción. Para el caso de los reintentos de MR, estos son manuales (por ahora) cada vez que se realizan, por tanto hay una persona que los está enviando y si no reciben un “OK” de vuelta lo reintentan y de seguir fallando se contactan con la contraparte en la IP para ver que sucede, puesto que eso debe quedar todo en línea antes de pasar a producción. En el caso de fallas del MC o MR en la transmisión en línea la IP debe disponer de una forma de genera el MC en un archivo y poder enviarlo por medio de correo electrónico. De la misma forma si falla el envío del MR la IP debe poder recibirlo como archivo por medio de correo electrónico e ingresarlo a sus sistemas para cerrar la cuadratura. Si la IP envía un M1 y la TGR no responde con un “OK” al servicio, significa que TGR no ha podido ingresar la deuda enviada a sus bases de datos correctamente por algún problema (datos incompletos, datos que no se aceptan al pasear, datos repetidos, etc.), en ese caso hay que revisar de acuerdo al tipo de excepción que se presenta la causa del problema, si no se puede determinar localmente, ponerse en contacto con área de desarrollo realizar otros análisis. En todas las redirecciones web en test y producción se puede usar https, en el área de desarrollo tenemos un certificado generado por nosotros que se puede usar, pero no es oficial y puede dar algún problema. Tanto en M1 como en M2 el tipo de moneda puede ser cualquiera de los válidos en TGR (Pesos, UF, UTM). No monedas extranjeras por el momento. Existe la posibilidad que un mismo cliente realice dos pagos por el mismo producto, si ocurre que en el momento de realizar el primer pago con alguno de los medios existentes, éste no logra confirmar el pago en línea y el cliente lo requiere apurado, sin darse cuenta que el cargo puede haber sido realizado en su cuenta, opta por realizar un segundo pago en otro medio, finalmente los dos pagos son confirmados por TGR y el dinero es depositado, la IP debe encargarse de devolver el dinero al cliente si corresponde. Existe la posibilidad que un cliente en el proceso de pago intente el pago con un medio y al no tener confirmación de él, utilice el retroceso del navegador y teniendo la misma deuda en la pantalla vaya a otro medio de pago y lo realice, finalmente los dos envían el mismo pago, el que llegue primero marcará el pago, pero el segundo aunque lo podemos rechazar el cliente ya no se entera, porque puede estar fuera de línea hace rato. De acuerdo a la experiencia que hemos tenido, cuando un SG se redirecciona hacia el sitio de la TGR, conviene más hacerlo dentro de una ventana emergente que dentro de un iframe, puesto Modelo General PPE_V42 19 que en este último hemos notado que se pierde el contexto de los datos, dando como resultado que al llegar al sitio de TGR, aparezca un mensaje relacionado a que la deuda no existe. Modelo General PPE_V42 20
