REPÚBLICA DOMINICANA

Este modelo estándar xx Xxxxxx de Condiciones Específicas para la contratación de Servicios, ha sido elaborado por la Dirección General de Contrataciones Públicas, para ser utilizado en los Procedimientos de Licitaciones regidos por la Xxx Xx. 000-00, de fecha dieciocho (18) xx xxxxxx del dos mil seis (2006), sobre Compras y Contrataciones de Bienes, Servicios, Obras y Concesiones, su modificatoria contenida en la Xxx Xx. 000-00, de fecha seis (06) de diciembre del dos mil seis (2006), y su Reglamento de Aplicación emitido mediante el Xxxxxxx Xx. 000-00 de fecha seis (6) de septiembre de dos mil doce (2012).

A continuación se incluye una breve descripción de su contenido.

PARTE 1 – PROCEDIMIENTOS DE LICITACIÓN

Sección I. Instrucciones a los Oferentes (IAO)

Esta sección proporciona información para asistir a los Oferentes en la preparación de sus Ofertas. También proporciona información sobre la presentación, apertura y evaluación de las ofertas y la adjudicación de los contratos. Las disposiciones de la Sección I son de uso estándar y obligatorio en todos los procedimientos de Licitación para la contratación de servicios regidos por la Xxx Xx. 000-00 sobre Compras y Contrataciones con modificaciones de Xxx Xx. 000-00 y su Reglamento de aplicación aprobado mediante Decreto No. 543-12.

Sección II. Datos de la Licitación (DDL)

Esta sección contiene disposiciones específicas para la Contratación del Servicios, y complementa la Sección I, Instrucciones a los Oferentes.

Sección III. Apertura y Validación de Ofertas

Esta sección incluye el procedimiento de apertura y validación de Ofertas, Técnicas y Económicas e incluye los criterios de evaluación y el procedimiento de Estudio de Precios.

Sección IV. Adjudicación

Esta sección incluye los Criterios de Adjudicación y el Procedimiento para Adjudicaciones Posteriores.

PARTE 2 - CONTRATO

Sección V. Disposiciones sobre los Contratos

Esta sección incluye el Contrato, el cual, una vez perfeccionado no deberá ser modificado, salvo los aspectos a incluir de las correcciones o modificaciones que se hubiesen hecho a la oferta seleccionada y que están permitidas bajo las Instrucciones a los Oferentes y las Condiciones Generales del Contrato.

Incluye las cláusulas generales y específicas que deberán incluirse en todos los contratos.

PARTE 3 – OBLIGACIONES Y RESPONSABILIDADES

Sección VI. Obligaciones y Responsabilidades del Proveedor

Esta sección incluye las responsabilidades y obligaciones con las que deberá cumplir el Proveedor.

Sección VII. Formularios

Esta sección contiene los formularios de información sobre el oferente, presentación de oferta y garantías que el oferente deberá presentar conjuntamente con la oferta.

1.1 Antecedentes ‌‌‌‌

PARTE I PROCEDIMIENTOS DE LA LICITACIÓN

Sección I Instrucciones a los Oferentes (IAO)

En el 2006 se promulgó la Xxx Xx. 000-00, que confiere todas las competencias administrativas y de control de todas las operaciones de los juegos xx xxxx al Ministerio de Hacienda.

En el 2011 se promulgó la Ley 139-11 que rige los aspectos impositivos relacionados con los establecimientos de juegos xx xxxx.

El Ministerio de Hacienda necesita poner en funcionamiento herramientas tecnológicas que le permitan implementar la gestión de las leyes anteriores, ya que se requieren de mecanismos que posibiliten la obtención de las informaciones generadas por los diferentes establecimientos de juegos xx xxxx.

En ese sentido, el Ministerio de Hacienda a través de la Dirección de Casinos y Juegos xx Xxxx ha dado inicio al Proyecto de Fortalecimiento del Sistema de Control y Supervisión de Operaciones de Bancas y Casinos y se ha requerido la participación del Programa de Administración Financiera Integrada (PAFI), para apoyar en el diseño e implementación del referido proyecto.

Por estos motivos, se busca adquirir una solución de software que permita al Ministerio de Hacienda disponer de un mejor control, supervisión, monitoreo y fiscalización de las operaciones de las bancas de lotería, con miras a obtener un mecanismo regulador más eficiente.

1.2 Objetivos y Alcance

El objetivo del presente documento es establecer el conjunto de cláusulas jurídicas, económicas, técnicas y administrativas, de naturaleza reglamentaria, por el que se fijan los requisitos, exigencias, facultades, derechos y obligaciones de las personas naturales o jurídicas, nacionales o extranjeras, que deseen participar en la Licitación para la contratación de SOLUCIÓN DE SOFTWARE PARA EL CONTROL, SUPERVISIÓN, MONITOREO Y AUTENTICACIÓN DE LAS OPERACIONES PARA BANCAS DE

LOTERÍA, llevada a cabo por Ministerio de Hacienda (Referencia: MINISTERIO HACIENDA-CCC-LPN- 2018-00031).

Este documento constituye la base para la preparación de las Ofertas. Si el Oferente/Proponente omite suministrar alguna parte de la información requerida en el presente Pliego de Condiciones Específicas o presenta una información que no se ajuste sustancialmente en todos sus aspectos al mismo, el riesgo estará a su cargo y el resultado podrá ser el rechazo de su Propuesta.

1 La referencia corresponde al nombre de la institución-Comité de Compras y Contrataciones-Licitación Pública Nacional, Licitación Pública Internacional o Licitación Restringida- Año-número secuencial de procedimientos llevados a cabo.

1.3 Definiciones e Interpretaciones

A los efectos de este Pliego de Condiciones Específicas, las palabras y expresiones que se inician con letra mayúscula y que se citan a continuación tienen el siguiente significado:

Adjudicatario: Oferente/Proponente a quien se le adjudica el Contrato u Orden de Servicio.

Caso Fortuito: Acontecimiento que no ha podido preverse, o que previsto no ha podido evitarse, por ser extraño a la voluntad de las personas.

Circular: Aclaración que el Comité de Compras y Contrataciones emite de oficio o para dar respuesta a las consultas planteadas por los Oferentes/Proponentes con relación al contenido xxx Xxxxxx de Condiciones, formularios, otra Circular o anexos, y que se hace de conocimiento de todos los Oferentes/Proponentes.

Comité de Compras y Contrataciones: Órgano Administrativo de carácter permanente responsable de la designación de los peritos que elaborarán las especificaciones técnicas del bien a adquirir y del servicio u obra a contratar, la aprobación de los Pliegos de Condiciones Específicas, del Procedimiento de Selección y el dictamen emitido por los peritos designados para evaluar ofertas.

Compromiso de Confidencialidad: Documento suscrito por el Oferente/Proponente para recibir información de la Licitación.

Consorcio: Uniones temporales de empresas que sin constituir una nueva persona jurídica se organizan para participar en un procedimiento de contratación.

Consulta: Comunicación escrita, remitida por un Oferente/Proponente conforme al procedimiento establecido y recibida por el Comité de Compras y Contrataciones, solicitando aclaración, interpretación o modificación sobre aspectos relacionados exclusivamente con el Pliego de Condiciones Específica.

Contrato: Documento suscrito entre la institución y el Adjudicatario elaborado de conformidad con los requerimientos establecidos en el Pliego de Condiciones Específicas y en la Ley

Credenciales: Documentos que demuestran las calificaciones profesionales y técnicas de un Oferente/Proponente, presentados como parte de la Oferta Técnica y en la forma establecida en el Pliego de Condiciones Específica, para ser evaluados y calificados por los peritos, lo que posteriormente pasa a la aprobación del Comité de Compras y Contrataciones de la entidad contratante, con el fin de seleccionar los Proponentes Habilitados, para la apertura de su Oferta Económica Sobre B.

Cronograma de Actividades: Cronología del Proceso de Licitación.

Enmienda: Comunicación escrita, emitida por el Comité de Compras y Contrataciones, con el fin de modificar el contenido xxx Xxxxxx de Condiciones Específicas, formularios, anexos u otra Enmienda y que se hace de conocimiento de todos los Oferentes/Proponentes.

Entidad Contratante: El organismo, órgano o dependencia del sector público, del ámbito de aplicación de la Xxx Xx. 000-00, que ha llevado a cabo un proceso contractual y celebra un Contrato.

Estado: Estado Dominicano.

Experiencia Profesional: Número de años acreditado por el certificado de estudios en el que consta el derecho al título universitario.

Experiencia Específica: número de años o fracción de 6 meses (equivalente a ½ año) en que el Proponente desempeñó actividades similares o equivalentes a la de su propuesta.

Fuerza Mayor: Cualquier evento o situación que escapen al control de la Entidad Contratante, imprevisible e inevitable, y sin que esté envuelta su negligencia o falta, como son, a manera enunciativa pero no limitativa, actos, epidemias, guerras, actos de terroristas, huelgas, fuegos, explosiones, temblores de tierra, catástrofes, inundaciones y otras perturbaciones ambientales mayores, condiciones severas e inusuales del tiempo.

Interesado: Cualquier persona natural o jurídica que tenga interés en cualquier procedimiento de compras que se esté llevando a cabo.

Licitación Pública: Es el procedimiento administrativo mediante el cual las entidades del Estado realizan un llamado público y abierto, convocando a los interesados para que formulen propuestas, de entre las cuales seleccionará la más conveniente conforme a los Pliegos de Condiciones correspondientes. Las licitaciones públicas podrán ser internacionales o nacionales. La licitación pública nacional va dirigida a los Proveedores nacionales o extranjeros domiciliados legalmente en el país.

Licitación Restringida: Es la invitación a participar a un número limitado de proveedores que pueden atender el requerimiento, debido a la especialidad de los servicios a prestarse, razón por la cual sólo puede obtenerse un número limitado de participantes, de los cuales se invitará un mínimo de cinco (5) Oferentes cuando el registro sea mayor. No obstante ser una licitación restringida se hará de conocimiento público por los medios previstos.

Líder del Consorcio: Persona natural o jurídica del Consorcio que ha sido designada como tal.

Máxima Autoridad Ejecutiva: El titular o el representante legal de la Entidad Contratante o quien tenga la autorización para celebrar Contrato.

Notificación de la Adjudicación: Notificación escrita al Adjudicatario y a los demás participantes sobre los resultados finales del Procedimiento de Licitación, dentro de un plazo de cinco (05) días hábiles contados a partir del Acto de Adjudicación.

Oferta Económica: Precio fijado por el Oferente en su Propuesta.

Oferta Técnica: Especificaciones de carácter técnico-legal de los servicios a ser adquiridos.

Oferente/Proponente: Persona natural o jurídica legalmente capacitada para participar en el proceso de licitación.

Oferente/Proponente Habilitado: Aquel que participa en el proceso de Licitación y resulta Conforme en la fase de Evaluación Técnica del Proceso.

PAFI: Es el Programa de Administración Financiera Integrada del Ministerio de Hacienda, el cual está en proceso interno de pasar a Dirección de Área con una nueva denominación de Dirección de Administración Financiera Integrada (DAFI).

Peritos: Funcionarios expertos en la materia del proceso llevado a cabo, de la Entidad Contratante, de otra entidad pública o contratados para el efecto y que colaborarán asesorando, analizando y evaluando propuestas, confeccionando los informes que contengan los resultados y sirvan de sustento para las decisiones que deba adoptar el Comité de Compras y Contrataciones.

Prácticas de Colusión: Es un acuerdo entre dos o más partes, diseñado para obtener un propósito impropio, incluyendo el influenciar inapropiadamente la actuación de otra parte.

Prácticas Coercitivas: Es dañar o perjudicar, o amenazar con dañar o perjudicar directa o indirectamente a cualquier parte, o a sus propiedades para influenciar inapropiadamente la actuación de una parte.

Prácticas Obstructivas: Es destruir, falsificar, alterar u ocultar en forma deliberada pruebas importantes respecto de su participación en un proceso de compra o incidir en la investigación o formular declaraciones farsas a los investigadores con la intensión de impedir sustancialmente una investigación de la Entidad Contratante referente a acusaciones sobre prácticas corruptas, fraudulentas, coercitivas, o colusorias y/o amenazar, acosar o intimidar a una parte con el propósito de impedir que dicha parte revele lo que sabe acerca de asuntos pertinentes a la investigación, o que lleve adelante la investigación, o la ejecución de un contrato.

Pliego de Condiciones Específicas: Documento que contiene todas las condiciones por las que habrán de regirse las partes en la presente Licitación.

Representante Legal: Persona física o natural acreditada como tal por el Oferente/ Proponente.

Reporte de Lugares Ocupados: Formulario que contiene los precios ofertados en el procedimiento, organizados de menor a mayor.

Resolución de la Adjudicación: Acto Administrativo mediante el cual el Comité de Compras y Contrataciones procede a la Adjudicación al/los oferente(s) del o los Contratos objeto del procedimiento de compra o contratación

Servicios: Conjunto de actividades realizadas para el buen funcionamiento del Estado.

Sobre: Paquete que contiene las credenciales del Oferente/Proponente y las Propuestas Técnicas o Económicas.

Términos de Referencias: Condiciones técnicas a ser cumplidas para alcanzar los objetivos con la calidad exigida.

Unidad Operativa de Compras y Contrataciones (UOCC): Unidad encargada de la parte operativa de los procedimientos de Compras y Contrataciones.

Para la interpretación del presente Pliego de Condiciones Específicas:

 Las palabras o designaciones en singular deben entenderse igualmente al plural y viceversa, cuando la interpretación de los textos escritos lo requiera.

 El término “por escrito” significa una comunicación escrita con prueba de recepción.

 Toda indicación a capítulo, numeral, inciso, Circular, Enmienda, formulario o anexo se entiende referida a la expresión correspondiente de este Pliego de Condiciones Específicas, salvo indicación expresa en contrario. Los títulos de capítulos, formularios y anexos son utilizados exclusivamente a efectos indicativos y no afectarán su interpretación.

 Las palabras que se inician en mayúscula y que no se encuentran definidas en este documento se interpretarán de acuerdo a las normas legales dominicanas.

 Toda cláusula imprecisa, ambigua, contradictoria u oscura a criterio de la Entidad Contratante, se interpretará en el sentido más favorable a ésta.

 Las referencias a plazos se entenderán como días calendario, salvo que expresamente se utilice la expresión de “días hábiles”, en cuyo caso serán días hábiles de acuerdo con la legislación dominicana.

1.4 Idioma

El idioma oficial de la presente Licitación es el español, por tanto, toda la correspondencia y documentos generados durante el procedimiento que intercambien el Oferente/Proponente y el Comité de Compras y Contrataciones deberán ser presentados en este idioma o, de encontrarse en idioma distinto, deberán contar con la traducción al español realizada por un intérprete judicial debidamente autorizado.

1.5 Precio de la Oferta

Los precios cotizados por el Oferente en el Formulario de Presentación de Oferta Económica deberán ajustarse a los requerimientos que se indican a continuación.

Todos los lotes y/o artículos deberán enumerarse y cotizarse por separado en el Formulario de Presentación de Oferta Económica. Si un formulario de Oferta Económica detalla artículos pero no los cotiza, se asumirá que está incluido en la Oferta. Asimismo, cuando algún lote o artículo no aparezca en el formulario de Oferta Económica se asumirá de igual manera, que está incluido en la Oferta.

El desglose de los componentes de los precios se requiere con el único propósito de facilitar a la Entidad Contratante la comparación de las Ofertas.

El precio cotizado en el formulario de Presentación de la Oferta Económica deberá ser el precio total de la oferta, excluyendo cualquier descuento que se ofrezca.

Los precios cotizados por el Oferente serán fijos durante la ejecución del Contrato y no estarán sujetos a ninguna variación por ningún motivo, salvo lo establecido en los Datos de la Licitación (DDL).

1.6 Moneda de la Oferta

El precio en la Oferta deberá estar expresado en moneda nacional, (Pesos Dominicanos, RD$), a excepción de los Contratos de suministros desde el exterior, en los que podrá expresarse en la moneda del país de origen de los mismos.

De ser así, el importe de la oferta se calculará sobre la base del tipo de cambio vendedor del BANCO CENTRAL DE LA REPÚBLICA DOMINICANA vigente al cierre del día anterior a la fecha de recepción de ofertas.

1.7 Normativa Aplicable

El proceso de Licitación, el Contrato y su posterior ejecución se regirán por la Constitución de la República Dominicana, Xxx Xx. 000-00 sobre Compras y Contrataciones de Bienes, Servicios, Obras y Concesiones, de fecha dieciocho (18) xx xxxxxx del 2006, su modificatoria contenida en la Xxx Xx. 000-00 de fecha seis (06) de diciembre del 2006; y su Reglamento de Aplicación emitido mediante el Decreto No. 543-12, de fecha seis (06) de septiembre del 2012, por las normas que se dicten en el marco de la misma, así como por el presente Xxxxxx xx Xxxxxxxxxxx y por el Contrato a intervenir.

Todos los documentos que integran el Contrato serán considerados como recíprocamente explicativos.

Para la aplicación de la norma, su interpretación o resolución de conflictos o controversias, se aplicará el siguiente orden de prelación:

1) La Constitución de la República Dominicana;

2) La Xxx Xx. 000-00, sobre Compras y Contrataciones de Bienes, Servicios, Obras y Concesiones, de fecha 18 xx xxxxxx del 2006 y su modificatoria contenida en la Xxx Xx. 000-00 de fecha seis

(06) de diciembre del 2006;

3) El Reglamento de Aplicación de la Xxx Xx. 000-00, emitido mediante el Decreto No. 543-12, de fecha 06 de septiembre del 2012;

4) El Pliego de Condiciones Específicas;

5) La Oferta;

6) La Adjudicación;

7) El Contrato;

8) La Orden de Compra.

1.8 Competencia Judicial

Todo litigio, controversia o reclamación resultante de este documento y/o el o los Contratos a intervenir, sus incumplimientos, interpretaciones, resoluciones o nulidades serán sometidos al Tribunal Superior Administrativo conforme al procedimiento establecido en la Ley que instituye el Tribunal Superior Administrativo.

1.9 Proceso Arbitral

De común acuerdo entre las partes, podrán acogerse al procedimiento de Arbitraje Comercial de la República Dominicana, de conformidad con las disposiciones de la Xxx Xx. 000-00, de fecha treinta (30) de diciembre del dos mil ocho (2008).

1.10 De la Publicidad

La convocatoria a presentar Ofertas en las Licitaciones Públicas deberá efectuarse mediante la publicación, al menos en dos (02) diarios de circulación nacional por el término de dos (2) días consecutivos, con un mínimo de treinta (30) días hábiles de anticipación a la fecha fijada para la apertura, computados a partir del día siguiente a la última publicación.

La comprobación de que en un llamado a Licitación se hubieran omitido los requisitos de publicidad, dará lugar a la cancelación inmediata del procedimiento por parte de la autoridad de aplicación en cualquier estado de trámite en que se encuentre.

1.11 Etapas de la Licitación

Las Licitaciones podrán ser de Etapa Única o de Etapas Múltiples.

Etapa Única:

Cuando la comparación de las ofertas y de la calidad de los oferentes se realiza en un mismo acto.

Etapa Múltiple:

Cuando la Ofertas Técnicas y las Ofertas Económicas se evalúan en etapas separadas:

Etapa I: Se inicia con el proceso de entrega de los “Sobres A”, contentivos de las Ofertas Técnicas, en acto público y en presencia xx xxxxxxx. Concluye con la valoración de las Ofertas Técnicas y la Resolución emitida por el Comité de Compras y Contrataciones sobre los resultados del Proceso de Homologación.

Etapa II: Se inicia con la apertura y lectura en acto público y en presencia xx Xxxxxxx de las Ofertas Económicas “Sobre B”, que se mantenían en custodia y que resultaron habilitados en la primera etapa del procedimiento, y concluye con la Resolución de Adjudicación a los Oferentes/Proponentes.

1.12 Órgano de Contratación

El órgano administrativo competente para la contratación de los servicios a ser contratados es la Entidad Contratante en la persona de la Máxima Autoridad Ejecutiva de la institución.

1.13 Atribuciones

Son atribuciones de la Entidad Contratante, sin carácter limitativo, las siguientes:

a) Definir la Unidad Administrativa que tendrá la responsabilidad técnica de la gestión.

b) Nombrar a los Peritos.

c) Determinar funciones y responsabilidades por unidad partícipe y por funcionario vinculado al proceso.

d) Xxxxxxxx, declarar desierta o nula, total o parcialmente la Licitación, por las causas que considere pertinentes. En consecuencia, podrá efectuar otras Licitaciones en los términos y condiciones que determine.

1.14 Órgano Responsable del Proceso

El Órgano responsable del proceso de Licitación es El Comité de Compras y Contrataciones. El Comité de Compras y Contrataciones está integrado por cinco (05) miembros:

 El funcionario de mayor jerarquía de la institución, o quien este designe, quien lo presidirá;

 El Director Administrativo Financiero de la entidad, o su delegado;

 El Consultor Jurídico de la entidad, quien actuará en calidad de Asesor Legal;

 El Responsable del Área de Planificación y Desarrollo o su equivalente;

 El Responsable de la Oficina de Libre Acceso a la Información.

1.15 Exención de Responsabilidades

El Comité de Compras y Contrataciones no estará obligado a declarar habilitado y/o Adjudicatario a ningún Oferente/Proponente que haya presentado sus Credenciales y/u Ofertas, si las mismas no demuestran que cumplen con los requisitos establecidos en el presente Pliego de Condiciones Específicas.

1.16 Prácticas Corruptas o Fraudulentas

Las prácticas corruptas o fraudulentas comprendidas en el Código Penal o en la Convención Interamericana contra la Corrupción, o cualquier acuerdo entre proponentes o con terceros, que establecieren prácticas restrictivas a la libre competencia, serán causales determinantes del rechazo de la propuesta en cualquier estado del procedimiento de selección, o de la rescisión del Contrato, si éste ya se hubiere celebrado. A los efectos anteriores se entenderá por:

a) “Práctica Corrupta”, al ofrecimiento, suministro, aceptación o solicitud de cualquier cosa de valor con el fin de influir en la actuación de un funcionario público u obtener una ventaja indebida con respecto al proceso de contratación o a la ejecución del Contrato, y,

b) “Práctica Fraudulenta”, es cualquier acto u omisión incluyendo una tergiversación de los hechos con el fin de influir en un proceso de contratación o en la ejecución de un Contrato de obra pública en perjuicio del contratante; la expresión comprende las prácticas colusorias entre los licitantes (con anterioridad o posterioridad a la presentación de las ofertas) con el fin de establecer precios de oferta a niveles artificiales y no competitivos y privar al contratante de las ventajas de la competencia libre y abierta, coercitivas y obstructiva.

1.17 De los Oferentes/Proponentes Hábiles e Inhábiles

Toda persona natural o jurídica, nacional o extranjera que haya adquirido el Pliego de Condiciones, tendrá derecho a participar en la presente Licitación, siempre y cuando reúna las condiciones exigidas y no se encuentre afectada por el régimen de prohibiciones establecido en el presente Pliego de Condiciones.

1.18 Prohibición de Contratar

No podrán participar como Oferentes/Proponentes, en forma directa o indirecta, las personas físicas o sociedades comerciales que se relacionan a continuación:

1) El Presidente y Vicepresidente de la República; los Secretarios y Subsecretarios de Estado; los Senadores y Diputados del Congreso de la República; los Magistrados de la Suprema Corte de Justicia, de los demás tribunales del orden judicial, de la Xxxxxx xx Xxxxxxx y de la Junta Central Electoral; los Síndicos y Regidores de los Ayuntamientos de los Municipios y del Distrito Nacional; el Contralor General de la República y el Sub-contralor; el Director de Presupuesto y Subdirector; el Director Nacional de Planificación y el Subdirector; el Procurador General de la República y los demás miembros del Ministerio Público; el Tesorero Nacional y el Subtesorero y demás funcionarios de primer y segundo nivel de jerarquía de las instituciones incluidas bajo el ámbito de aplicación de la Xxx Xx. 000-00;

2) Los jefes y subjefes de Estado Mayor de las Fuerzas Armadas, así como el jefe y subjefes de la Policía Nacional;

3) Los funcionarios públicos con injerencia o poder de decisión en cualquier etapa del procedimiento de contratación administrativa;

4) Todo personal de la entidad contratante;

5) Los parientes por consanguinidad hasta el tercer grado o por afinidad hasta el segundo grado, inclusive, de los funcionarios relacionados con la contratación cubiertos por la prohibición, así como los cónyuges, las parejas en unión libre, las personas vinculadas con análoga relación de convivencia afectiva o con las que hayan procreado hijos, y descendientes de estas personas;

6) Las personas jurídicas en las cuales las personas naturales a las que se refieren los Numerales 1 al 4 tengan una participación superior al diez por ciento (10%) del capital social, dentro de los seis meses anteriores a la fecha de la convocatoria;

7) Las personas físicas o jurídicas que hayan intervenido como asesoras en cualquier etapa del procedimiento de contratación o hayan participado en la elaboración de las especificaciones técnicas o los diseños respectivos, salvo en el caso de los contratos de supervisión;

8) Las personas físicas o jurídicas que hayan sido condenadas mediante sentencia que haya adquirido la autoridad de la cosa irrevocablemente juzgada por delitos de falsedad o contra la propiedad, o por delitos de cohecho, malversación de fondos públicos, tráfico de influencia, prevaricación, revelación de secretos, uso de información privilegiada o delitos contra las finanzas públicas, hasta que haya transcurrido un lapso igual al doble de la condena. Si la condena fuera por delito contra la administración pública, la prohibición para contratar con el Estado será perpetua;

9) Las empresas cuyos directivos hayan sido condenados por delitos contra la administración pública, delitos contra la fe pública o delitos comprendidos en las convenciones internacionales de las que el país sea signatario;

10) Las personas físicas o jurídicas que se encontraren inhabilitadas en virtud de cualquier ordenamiento jurídico;

11) Las personas que suministraren informaciones falsas o que participen en actividades ilegales o fraudulentas relacionadas con la contratación;

12) Las personas naturales o jurídicas que se encuentren sancionadas administrativamente con inhabilitación temporal o permanente para contratar con entidades del sector público, de acuerdo a lo dispuesto por la presente ley y sus reglamentos;

13) Las personas naturales o jurídicas que no estén al día en el cumplimiento de sus obligaciones tributarias o de la seguridad social, de acuerdo con lo que establezcan las normativas vigentes;

PARRAFO I: Para los funcionarios contemplados en los Numerales 1 y 2, la prohibición se extenderá hasta seis (6) meses después de la salida del cargo.

PARRAFO II: Para las personas incluidas en los Numerales 5 y 6 relacionadas con el personal referido en el Numeral 3, la prohibición será de aplicación en el ámbito de la institución en que estos últimos prestan servicios.

En adición a las disposiciones del Artículo 14 de la Xxx Xx. 000-00 con sus modificaciones NO podrán contratar con el Estado dominicano los proveedores que no hayan actualizado sus datos en el Registro de Proveedores del Estado.

1.19 Demostración de Capacidad para Contratar

Los Oferentes/Proponentes deben demostrar que:

1) Poseen las calificaciones profesionales y técnicas que aseguren su competencia, los recursos financieros, el equipo y demás medios físicos, la fiabilidad, la experiencia y el personal necesario para ejecutar el contrato.

2) No están embargados, en estado de quiebra o en proceso de liquidación; sus negocios no han sido puestos bajo administración judicial, y sus actividades comerciales no han sido suspendidas ni se ha iniciado procedimiento judicial en su contra por cualquiera de los motivos precedentes;

3) Han cumplido con sus obligaciones tributarias y de seguridad social;

4) Han cumplido con las demás condiciones de participación, establecidas de antemano en los avisos y el presente Pliego de Condiciones;

5) Se encuentran legalmente domiciliados y establecidos en el país, cuando se trate de licitaciones nacionales;

6) Que los fines sociales sean compatibles con el objeto contractual;

1.20 Representante Legal

Todos los documentos que presente el Oferente/Proponente dentro de la presente Licitación deberán estar firmados por él, o su Representante Legal, debidamente facultado al efecto.

1.21 Subsanaciones

A los fines de la presente Licitación se considera que una Oferta se ajusta sustancialmente a los Pliegos de Condiciones, cuando concuerda con todos los términos y especificaciones de dichos documentos, sin desviaciones, reservas, omisiones o errores significativos. La ausencia de requisitos relativos a las credenciales de los oferentes es siempre subsanable.

La determinación de la Entidad Contratante de que una Oferta se ajusta sustancialmente a los documentos de la Licitación se basará en el contenido de la propia Oferta, sin que tenga que recurrir a pruebas externas.

Siempre que se trate de errores u omisiones de naturaleza subsanable entendiendo por éstos, generalmente, aquellas cuestiones que no afecten el principio de que las Ofertas deben ajustarse sustancialmente a los Pliegos de Condiciones, la Entidad Contratante podrá solicitar que, en un plazo breve, El Oferente/Proponente suministre la información faltante.

Cuando proceda la posibilidad de subsanar errores u omisiones se interpretará en todos los casos bajo el entendido de que la Entidad Contratante tenga la posibilidad de contar con la mayor cantidad de ofertas validas posibles y de evitar que, por cuestiones formales intrascendentes, se vea privada de optar por ofertas serias y convenientes desde el punto de vista del precio y la calidad.

No se podrá considerar error u omisión subsanable, cualquier corrección que altere la sustancia de una oferta para que se la mejore.

La Entidad Contratante rechazará toda Oferta que no se ajuste sustancialmente al Pliego de Condiciones Específica. No se admitirán correcciones posteriores que permitan que cualquier Oferta, que inicialmente no se ajustaba a dicho Pliego, posteriormente se ajuste al mismo.

1.22 Rectificaciones Aritméticas

Para fines de subsanaciones, los errores aritméticos serán corregidos de la siguiente manera:

 Si existiere una discrepancia entre una cantidad parcial y la cantidad total obtenida multiplicando las cantidades parciales, prevalecerá la cantidad parcial y el total será corregido.

 Si la discrepancia resulta de un error de suma o resta, se procederá de igual manera; esto es, prevaleciendo las cantidades parciales y corrigiendo los totales.

 Si existiere una discrepancia entre palabras y cifras, prevalecerá el monto expresado en palabras.

 Si el Oferente no acepta la corrección de los errores, su Oferta será rechazada.

1.23 Garantías

Los importes correspondientes a las garantías deberán hacerse en la misma moneda utilizada para la presentación de la Oferta. Cualquier garantía presentada en una moneda diferente a la presentada en la Oferta será descalificada sin más trámite.

Los Oferentes/Proponentes deberán presentar las siguientes garantías:

1.23.1 Garantía de la Seriedad de la Oferta

Correspondiente al uno por ciento (1%) del monto total de la Oferta.

PÁRRAFO I. La Garantía de Seriedad de la Oferta será de cumplimiento obligatorio y vendrá incluida dentro de la Oferta Económica. La omisión en la presentación de la Oferta de la Garantía de Seriedad de Oferta o cuando la misma fuera insuficiente, conllevará la desestimación de la Oferta sin más trámite.

1.23.2 Garantía de Fiel Cumplimiento de Contrato

Los Adjudicatarios cuyos Contratos excedan el equivalente en Pesos Dominicanos xx Xxxx Mil Dólares de los Estados Unidos de Norteamérica con 00/100 (US$10.000,00), están obligados a constituir una Garantía Bancaria o Pólizas de Fianzas de compañías aseguradoras de reconocida solvencia en la República Dominicana, con las condiciones de ser incondicionales, irrevocables y renovables, en el plazo de Cinco (5) días hábiles, contados a partir de la Notificación de la Adjudicación, por el importe del CUATRO POR CIENTO (4%) del monto total del Contrato a intervenir, a disposición de la Entidad Contratante, cualquiera que haya sido el procedimiento y la forma de Adjudicación del Contrato. En el caso de que el adjudicatario sea una Micro, Pequeña y Mediana empresa (MIPYME) el importe de la garantía será de un UNO POR CIENTO (1%). La Garantía de Fiel Cumplimiento de Contrato debe ser emitida por una entidad bancaria de reconocida solvencia en la República Dominicana.

La no comparecencia del Oferente Adjudicatario a constituir la Garantía de Fiel Cumplimiento de Contrato, se entenderá que renuncia a la Adjudicación y se procederá a la ejecución de la Garantía de Seriedad de la Oferta.

Cuando hubiese negativa a constituir la Garantía de Fiel Cumplimiento de Contrato, la Entidad Contratante, como Órgano de Ejecución del Contrato, notificará la Adjudicación de los renglones

correspondientes al Oferente que hubiera obtenido la siguiente posición en el proceso de Adjudicación, conforme al Reporte de Lugares Ocupados. El nuevo Oferente Adjudicatario depositará la Garantía y suscribirá el Contrato de acuerdo al plazo que le será otorgado por la Entidad Contratante, mediante comunicación formal.

1.24 Devolución de las Garantías

a) Garantía de la Seriedad de la Oferta: Tanto al Adjudicatario como a los demás oferentes participantes una vez integrada la garantía de fiel cumplimiento de contrato.

b) Garantía de Fiel Cumplimiento de Contrato: Una vez cumplido el contrato a satisfacción de la Entidad Contratante, cuando no quede pendiente la aplicación de multa o penalidad alguna.

1.25 Consultas

Los interesados podrán solicitar a la Entidad Contratante aclaraciones acerca xxx Xxxxxx de Condiciones Específicas, hasta la fecha que coincida con el CINCUENTA POR CIENTO (50%) del plazo para la presentación de las Ofertas. Las consultas las formularán los Oferentes por escrito, sus representantes legales, o quien éstos identifiquen para el efecto. La Unidad Operativa de Compras y Contrataciones, dentro del plazo previsto, se encargará de obtener las respuestas conforme a la naturaleza de la misma.

Las Consultas se remitirán al Comité de Compras y Contrataciones, dirigidas a:

COMITÉ DE COMPRAS Y CONTRATACIONES.

Ministerio de Hacienda

Referencia: MINISTERIO HACIENDA-CCC-LPN-2018-00032

Dirección: Xxx. Xxxxxx Xx. 00, Gazcue

Teléfonos: 809-687-5131 ext. 2436

Correo electrónico: xxxxxxxxxxx@xxxxxxxx.xxx.xx

1.26 Circulares

El Comité de Compras y Contrataciones podrá emitir Circulares de oficio o para dar respuesta a las Consultas planteadas por los Oferentes/Proponentes con relación al contenido del presente Pliego de Condiciones, formularios, otras Circulares o anexos. Las Circulares se harán de conocimiento de todos los Oferentes/Proponentes. Dichas circulares deberán ser emitidas solo con las preguntas y las respuestas, sin identificar quien consultó, en un plazo no más allá de la fecha que signifique el SETENTA Y CINCO POR CIENTO (75%) del plazo previsto para la presentación de las Ofertas y deberán ser notificadas a todos los Oferentes que hayan adquirido el Pliego de Condiciones Específicas y publicadas en el portal institucional y en el administrado por el Órgano Rector.

2 La referencia corresponde al nombre de la institución-Comité de Compras y Contrataciones-Licitación Pública Nacional, Licitación Pública Internacional o Licitación Restringida- Año-número secuencial de procedimientos llevados a cabo.

1.27 Enmiendas

De considerarlo necesario, por iniciativa propia o como consecuencia de una Consulta, el Comité de Compras y Contrataciones podrá modificar, mediante Enmiendas, el Pliego de Condiciones Específicas, formularios, otras Enmiendas o anexos. Las Enmiendas se harán de conocimiento de todos los Oferentes/Proponentes y se publicarán en el portal institucional y en el administrado por el Órgano Rector.

Tanto las Enmiendas como las Circulares emitidas por el Comité de Compras y Contrataciones pasarán a constituir parte integral xxx Xxxxxx de Condiciones y en consecuencia, serán de cumplimiento obligatorio para todos los Oferentes/Proponentes.

1.28 Reclamos, Impugnaciones y Controversias

En los casos en que los Oferentes/Proponentes no estén conformes con la Resolución de Adjudicación, tendrán derecho a recurrir dicha Adjudicación. El recurso contra el acto de Adjudicación deberá formalizarse por escrito y seguirá los siguientes pasos:

1. El recurrente presentará la impugnación ante la Entidad Contratante en un plazo no mayor xx Xxxx

(10) días a partir de la fecha del hecho impugnado o de la fecha en que razonablemente el recurrente debió haber conocido el hecho. La Entidad pondrá a disposición del recurrente los documentos relevantes correspondientes a la actuación en cuestión, con la excepción de aquellas informaciones declaradas como confidenciales por otros Oferentes o Adjudicatarios, salvo que medie su consentimiento.

2. En los casos de impugnación de Adjudicaciones, para fundamentar el recurso, el mismo se regirá por las reglas de la impugnación establecidas en los Pliegos de Condiciones Específicas.

3. Cada una de las partes deberá acompañar sus escritos de los documentos que hará valer en apoyo de sus pretensiones. Toda entidad que conozca de un recurso deberá analizar toda la documentación depositada o producida por la Entidad Contratante.

4. La entidad notificará la interposición del recurso a los terceros involucrados, dentro de un plazo de

Dos (02) días hábiles.

5. Los terceros estarán obligados a contestar sobre el recurso dentro de Cinco (5) días calendario, a partir de la recepción de notificación del recurso, de lo contrario quedarán excluidos de los debates.

6. La entidad estará obligada a resolver el conflicto, mediante resolución motivada, en un plazo no mayor de Quince (15) días calendario, a partir de la contestación del recurso o del vencimiento del plazo para hacerlo.

7. El Órgano Rector podrá tomar medidas precautorias oportunas, mientras se encuentre pendiente la resolución de una impugnación para preservar la oportunidad de corregir un incumplimiento potencial de esta ley y sus reglamentos, incluyendo la suspensión de la adjudicación o la ejecución de un Contrato que ya ha sido Adjudicado.

8. Las resoluciones que dicten las Entidades Contratantes podrán ser apeladas, cumpliendo el mismo procedimiento y con los mismos plazos, ante el Órgano Rector, dando por concluida la vía administrativa.

Xxxxxxx X.- En caso de que un Oferente/Proponente iniciare un procedimiento de apelación, la Entidad Contratante deberá poner a disposición del Órgano Rector copia fiel del expediente completo.

Xxxxxxx XX.- La presentación de una impugnación de parte de un Oferente o Proveedor, no perjudicará la participación de éste en Licitaciones en curso o futuras, siempre que la misma no esté basada en hechos falsos.

Las controversias no resueltas por los procedimientos indicados en el artículo anterior serán sometidas al Tribunal Superior Administrativo, o por decisión de las partes, a arbitraje.

La información suministrada al Organismo Contratante en el proceso de Licitación, o en el proceso de impugnación de la Resolución Administrativa, que sea declarada como confidencial por el Oferente, no podrá ser divulgada si dicha información pudiese perjudicar los intereses comerciales legítimos de quien la aporte o pudiese perjudicar la competencia xxxx entre los Proveedores.

1.29 Comisión de Veeduría

Las Veedurías son el mecanismo de control social, que de manera más concreta, acerca a la comunidad al ejercicio y desempeño de la gestión pública y la función administrativa.

Sección II

Datos de la Licitación (DDL)

2.1 Objeto de la Licitación

Constituye el objeto de la presente convocatoria la SOLUCIÓN DE SOFTWARE PARA EL CONTROL, SUPERVISIÓN, MONITOREO Y AUTENTICACIÓN DE LAS OPERACIONES PARA BANCAS DE

LOTERÍA, de acuerdo con las condiciones fijadas en el presente Pliego de Condiciones Específicas.

2.2 Procedimiento de Selección

El Procedimiento de Selección es de Etapas Múltiples

2.3 Fuente de Recursos

El Ministerio de Hacienda, de conformidad con el Artículo 32 del Reglamento No. 543-12 sobre Compras y Contrataciones Públicas de Bienes, Servicios y Obras, ha tomado las medidas previsoras necesarias a los fines de garantizar la apropiación de fondos correspondiente, dentro del Presupuesto de los años 2018 y 2019, que sustentará el pago de todos los servicios contratados mediante la presente Licitación. Las partidas de fondos para liquidar las entregas programadas serán debidamente especializadas para tales

fines, a efecto de que las condiciones contractuales no sufran ningún tipo de variación durante el tiempo de ejecución del mismo.

2.4 Condiciones de Pago

La Entidad Contratante establece la modalidad de pago, bajo el siguiente esquema: Correspondiente a la implementación del proyecto será desglosado de la siguiente manera:

(i) Anticipo: El veinte por ciento (20%) del precio del Contrato, se pagará dentro de los treinta (30) días siguientes a la entrega de la garantía de buen del anticipo; *

(ii) Instalación de aplicación en su última versión en uso sin subsanaciones: El veinte por ciento (20%) del precio del Contrato, se pagará dentro de los treinta (30) días siguientes de que el proveedor concluya de forma exitosa la "instalación de la aplicación".

(iii) Al concluir de forma exitosa la subsanación de las funcionalidades complementarias, capacitación, pruebas de calidad y desempeño": El veinte por ciento (20%) del precio del Contrato, se pagará dentro de los treinta (30) días siguientes de:

- Subsanación de las funcionalidades complementarias que no se encuentran nativas y están incluidas en la oferta.

- Capacitación técnica para la operación, desarrollo, mantenimiento, administración, auditoría y configuración de la solución.

(iv) Al concluir de forma exitosa las pruebas de calidad y desempeño": El veinte por ciento (20%) del precio del Contrato, se pagará dentro de los treinta (30) días siguientes de:

- Pruebas de calidad, depuración y corrección de errores, desempeño y certificación final de la solución. Se considerará completada la entrega cuando la solución esté libre de errores de funcionamiento.

(v) Al concluir de forma exitosa la documentación. El diez por ciento (10%) del precio del Contrato, se pagará dentro de los treinta (30) días siguientes de la entrega:

- Manuales de usuario

- Manuales de operaciones, soporte técnico, desarrollo y mantenimiento

(vi) Al concluir el acompañamiento post-implementación y entrega del informe de cierre de proyecto. El diez por ciento (10%) del precio del Contrato, se pagará dentro de los treinta (30) días siguientes de la entrega:

- Acompañamiento post-implementación

- Informe de cierre de proyecto

*La garantía de buen uso de anticipo deberá ser constituida por el equivalente al monto que reciba el adjudicatario, conforme a lo establecido en el artículo 112 del Decreto No. 543-12, de fecha 6 de septiembre de 2012, Reglamento de Aplicación de la Xxx Xx. 000-00 y sus modificaciones.

2.5 Cronograma de la Licitación3

ACTIVIDADES

PERÍODO DE EJECUCIÓN

1. Publicación llamado a participar en la licitación

Dos días consecutivos/ dos diarios de circulación nacional.

Viernes 25 xx xxxx del año 2018

2. Visita Explicativa obligatoria al Ministerio de Hacienda.

Martes 05 xx Xxxxx del año 2018

Desde las 3:00PM hasta las 6:00PM en el Salón Xxxxxx Xxxxx.

3. Período para realizar consultas por parte de los

interesados

50% del plazo para presentar Ofertas

Martes 19 xx Xxxxx del año 2018

4. Plazo para emitir respuesta por parte del Comité de Compras y Contrataciones

No más allá de la fecha que signifique el 75% del plazo para presentar Ofertas.

Viernes 29 xx Xxxxx del año 2018

5. Recepción de Propuestas: “Sobre A” y “Sobre B” y apertura de “Sobre A” Propuestas Técnicas.

30 días hábiles contados a partir de la última publicación.

Miércoles 11 de Julio del año 2018

Desde las 8:00AM hasta las 10:00AM en la Dirección Jurídica.

Apertura: 02:00PM en el Salón Xxxxxx Xxxxx Xxxxx

6. Verificación, Validación y Evaluación contenido de las Propuestas Técnicas “Sobre A”

Hasta el Viernes 20 de Julio del año 2018

Plazo razonable conforme al objeto de la contratación

7. Verificación de prueba de conceptos

Días 00-00-00-00 de Julio del año 2018

8. Notificación de errores u omisiones de naturaleza subsanables.

Plazo razonable conforme al objeto de la contratación

Martes 24 de Julio del año 2018

9. Periodo de subsanación de ofertas

Plazo razonable conforme al objeto de la Contratación

Viernes 27 de Julio del año 2018

10. Período de Ponderación de Subsanaciones

Plazo razonable conforme al objeto de la contratación

Martes 31 de Julio del año 2018

11. Notificación Resultados del Proceso de Subsanación y Oferentes Habilitados para la presentación de Propuestas Económicas “Sobre B”

Plazo razonable conforme al objeto de la contratación

Miércoles 01 de Julio del año 2018

12. Apertura y lectura de Propuestas Económicas “Sobre B”

Plazo razonable conforme al objeto de la contratación

Jueves 02 xx Xxxxxx del año 2018.

Apertura: 02:00PM en el Salón Xxxxxx Xxxxx Xxxxx

13. Evaluación Ofertas Económicas “Sobre B”

Plazo razonable conforme al objeto de la contratación

Lunes 06 xx Xxxxxx del Año 2018

3 Nota: Incluir en el cronograma una actividad de reunión técnica o aclaratoria, si procede.

14. Adjudicación

Concluido el proceso de evaluación

Martes 07 xx Xxxxxx del año 2018

15. Notificación y Publicación de Adjudicación

5 días hábiles a partir del Acto Administrativo de Adjudicación

Martes 14 xx Xxxxxx del año 2018

16. Plazo para la constitución de la Garantía Bancaria de Fiel Cumplimiento de Contrato

Dentro de los siguientes 05 días hábiles, contados a partir de la Notificación de Adjudicación

Martes 21 xx Xxxxxx del año 2018

17. Suscripción del Contrato

No mayor a 20 días hábiles contados a partir de la Notificación de Adjudicación

Martes 11 de Septiembre del año 2018

18. Publicación de los Contratos en el portal institución y en el portal administrado por el Órgano Rector.

Inmediatamente después de suscritos por las partes

2.6 Disponibilidad y Adquisición xxx Xxxxxx de Condiciones

El Pliego de Condiciones estará disponible para quien lo solicite, en la sede central del MINISTERIO DE HACIENDA, ubicada en la Av., México, No. 45, Gazcue en el horario de 9:00 a.m. / 3:00 p.m., de lunes a viernes, en la fecha indicada en el Cronograma de la Licitación y en la página Web de la institución xxx.xxxxxxxx.xxx.xx y en el portal administrado por el Órgano Rector, xxx.xxxxxxxxxxxxxxxxx.xxx.xx

, para todos los interesados.

El Oferente que adquiera el Pliego de Condiciones a través de la página Web de la institución, xxx.xxxxxxxx.xxx.xx o del portal administrado por el Órgano Rector, xxx.xxxxxxxxxxxxxxxxx.xxx.xx , deberá enviar un correo electrónico a xxxxxxxxxxx@xxxxxxxx.xxx.xx, o en su defecto, notificar al Comité de Compras y Contrataciones del Ministerio de Hacienda sobre la adquisición del mismo, a los fines de que la Entidad Contratante tome conocimiento de su interés en participar y de esa manera convocar a reunión explicativa.

2.7 Conocimiento y Aceptación xxx Xxxxxx de Condiciones

El sólo hecho de un Oferente/Proponente participar en la Licitación implica pleno conocimiento, aceptación y sometimiento por él, por sus miembros, ejecutivos, y su Representante Legal, a los procedimientos, condiciones, estipulaciones y normativas, sin excepción alguna, establecidos en el presente Pliego de Condiciones, el cual tienen carácter jurídicamente obligatorio y vinculante.

2.8 Descripción del Servicio

Para el logro del objetivo propuesto en la presente contratación, el Proponente deberá realizar las actividades que se indican a continuación en el tiempo programado y entregar los informes parciales y el informe final de conformidad con los objetivos, alcances y contenido.

2.8.1 REQUERIMIENTOS FUNCIONALES (SECCION A)

Adquisición de una solución de software para el control, supervisión, monitoreo y autenticación de las operaciones en los establecimientos de juegos xx xxxx autorizados para BANCAS DE LOTERÍA.

*********************** INICIO DE REQUERIMIENTOS FUNCIONALES (SECCION A) ************************* 1.1 ESQUEMA DE OPERACIÓN

Se requiere que la solución propuesta por el oferente actúe como un sistema central controlado por el Ministerio de Hacienda, que interactúe con cada uno de los establecimientos controlados, a través de sus respectivas unidades centrales de procesamiento. Es decir, se requiere que el sistema central interactúe no con cada local o terminal de cada banca, sino con los centros de datos de cada uno de ellos.

En el caso de que dichos establecimientos trabajen bajo un modelo tercerizado con un proveedor externo de dichos servicios, se requiere que el sistema central interactúe con dichas unidades centrales, quienes actuarán como integradores entre sus establecimientos clientes y el Ministerio de Hacienda.

En el gráfico mostramos el esquema general de la solución que se requiere implementar.

2. REQUERIMIENTOS FUNCIONALES

Se requiere que el sistema incluya cada uno de los módulos listados a continuación, así como cada uno de los escenarios descritos en cada uno:

1. Registro de establecimientos y su estructura

2. Registro de juegos xx xxxx y sorteos

3. Registro de operaciones

4. Gestión de fuera de línea (offline)

5. Procesos de cierre y conciliación

6. Cálculo impositivo

7. Portal de consulta de jugadas y premios

8. Monitoreo de premios no reclamados

9. Reportes y “dashboards”

10. Interfaces con sistemas específicos

En el diagrama de componentes anexo se señalan todos los componentes necesarios para la solución de software que actuará como Sistema Central del Ministerio de Hacienda.

2.1 REGISTRO DE ESTABLECIMIENTOS Y SU ESTRUCTURA

2.1.1 REGISTRO GENERAL

Se requiere que el sistema ofrezca la funcionalidad de registro y mantenimiento de todos los establecimientos con licencias autorizadas y empresas que ofrezcan servicios de operaciones tecnológicas, o conexos, a las mismas.

2.1.2 ESTRUCTURA JERÁRQUICA

2.1.2.1 Niveles de la estructura

Se requiere que el sistema ofrezca la funcionalidad de establecer una estructura jerárquica de al menos 3 niveles, con los códigos de identificación únicos que se emplearán en los mensajes transaccionales, así como el nivel de detalle requerido para el correcto registro de todos sus detalles.

 [IDES] Identificador único del establecimiento regulado (consorcio)

 [IDLF] Identificador único del local físico (banca)

 [IDTR] Identificador único de la terminal (punto de venta)

2.1.2.2 Establecimiento (consorcio)

Se requiere que el sistema ofrezca la funcionalidad de registro de la información necesaria de los establecimientos (consorcios) para su adecuada fiscalización y control, que deberá incluir:

 [IDES] IDENTIFICADOR ÚNICO DEL ESTABLECIMIENTO

 Nombre del establecimiento

 [TPES] TIPO DE ESTABLECIMIENTO

o De acuerdo con la Ley y/o normativa vigente (ej. banca de lotería, banca deportiva…) y que, por tanto, pueda ser configurable.

 Propietario y/o accionistas

 RNC y/o cédulas de identidad

 Administración responsable * En casos de Casinos

 Números de teléfono

 Dirección de correo electrónico

 Número y fecha de licencia o permiso

 Sede central de operaciones

 [1-n] Puntos de venta autorizados, con jerarquía para poder identificar sus terminales (punto de venta, banca, zona, consorcio…) – direcciones, teléfonos de contacto, imágenes de los locales, geolocalización…

 [1-n] Catálogo de juegos xx xxxx comercializados autorizados al establecimiento – según los identificadores de juego registrados [IDJA] en el sistema

 Estado (activo, inactivo, en proceso de autorización…)

2.1.2.3 Locales físicos (bancas)

Se requiere que el sistema ofrezca la funcionalidad de registrar y controlar cada uno de los locales físicos (bancas) autorizados para dicho establecimiento, identificando para cada uno los detalles relacionados a su dirección, datos de contacto, imágenes de los locales, geolocalización… y código de identificación único para el mismo.

2.1.2.4 Terminales

Se requiere que el sistema ofrezca la funcionalidad de registrar y controlar las TERMINALES desde las que se ejecutan las operaciones dentro de los locales físicos (bancas) de forma única, de forma que cada operación controlada pueda vincularse con una terminal específica.

 [IDES] Identificador único del establecimiento regulado (consorcio)

 [IDLF] Identificador único del local físico (banca)

 [IDTR] Identificador único de la terminal (punto de venta o equipo físico desde el que se emiten los recibos)

2.1.3 CREDENCIALES Y ACCESOS

2.1.3.1 Gestión de credenciales y accesos

Se requiere que el sistema ofrezca la funcionalidad de definir, mantener y gestionar las credenciales y accesos que se les deberán otorgar a los establecimientos supervisados para que puedan realizar la integración con él y poder recibir los mensajes transaccionales de una forma segura.

2.3.1.2 Componentes de las credenciales

Se requiere que el sistema ofrezca la funcionalidad de configurar, registrar y administrar al menos los siguientes componentes para los [IDES] ESTABLECIMIENTOS:

 [IDES] Identificador único del establecimiento (consorcio)

 [USER] Usuario con el que se estarán conectando al sistema

 [PWD] Contraseña para acceder al sistema

 [IDIN] Identificador de instancia

 [ISRV] Identificador de servidor

2.1.4 MECANISMO DE “POLLING”

Se requiere que el sistema cuente con un mecanismo de “polling” o detección de las conexiones disponibles con cada uno de los establecimientos supervisados, y de igual forma permitir que los establecimientos puedan determinar la disponibilidad de la conexión con el sistema central.

2.2 JUEGOS XX XXXX

2.2.1 REGISTRO DE JUEGOS XX XXXX

2.2.1.1 Registro general y reglas

Se requiere que el sistema ofrezca la funcionalidad de registro de todos los diferentes tipos de juegos xx xxxx autorizados por el Ministerio de Hacienda junto con sus reglas, de forma paramétrica y que permita establecer, al menos:

 Las reglas aplicables de control básicas necesarias para la operación del sistema, incluyendo la determinación de la forma de pago de cada una.

2.2.1.2 Códigos de identificación

Se requiere que el sistema ofrezca la funcionalidad de registro de los códigos de identificación únicos que se emplearán en los mensajes transaccionales para tanto los juegos xx xxxx, como los sorteos asociados a los mismos.

 [IDJA] Identificador del juego xx xxxx

 [CSRT] Código de sorteo específico

 [JGDA] Formato para registrar las jugadas que se realizarían para dicho juego xx xxxx.

2.2.2 CIERRE DE VENTAS

Se requiere que el sistema ofrezca la funcionalidad de configurar los juegos xx xxxx que requieran un CIERRE DE VENTAS previo a poderse realizar PAGOS DE GANADORES, como en los casos de sorteos de loterías.

2.2.3 SORTEOS

Se requiere que el sistema ofrezca la funcionalidad de definir, configurar y mantener la configuración de los sorteos específicos relacionados con el JUEGO XX XXXX [IDJA] en particular, que permita especificar el

día y la hora específicos en la que se llevan a cabo, así como las reglas para poder validar las JUGADAS

[JGDA] aceptables para dichos sorteos y para el pago de los ganadores.

2.2.4 JUGADAS

Se requiere que el sistema ofrezca la funcionalidad de definir, configurar y mantener los formatos para el envío y reporte de las jugadas relacionadas los JUEGOS XX XXXX [IDJA] y SORTEOS ESPECÍFICOS [CSRT] en las diversas transacciones de integración con los sistemas de los ESTABLECIMIENTOS [IDES] supervisados.

2.3 REGISTRO Y CONTROL DE OPERACIONES

2.3.1 ENTIDAD DE AUTENTICACIÓN EN-LÍNEA

Se requiere que el sistema actúe como una entidad central de autenticación de operaciones y registrar las mismas, basadas en mensajes transaccionales según los TIPOS DE OPERACIONES [TIPO] que serán enviados con la información necesaria para poder identificar hasta el nivel de la terminal (consorcio, banca y terminal), para cada uno de los establecimientos bajo control, ya sea desde la empresa proveedora del servicio tecnológico o UNIDAD CENTRAL DE JUEGO a través de la cual se autentiquen en sus operaciones. Como resultado, el sistema deberá responder en-línea con un mensaje de respuesta basado en el tipo de operación, con un código de respuesta y un número de autenticación único (en caso de éxito) que deberá ser parte del comprobante de la operación que se le ofrece al jugador y deberá quedar impreso en el comprobante de jugada.

2.3.2 ACUMULADORES

Se requiere que el sistema ofrezca la funcionalidad de acumular todos los registros diarios por tipo de operaciones soportadas, calculando los volúmenes de ventas para períodos configurables en el sistema (diario, mensual, trimestral…) y que los mismos puedan ser consultados por diversos criterios para fines de control y supervisión.

2.3.3 LÍMITES

Se requiere que el sistema ofrezca la funcionalidad de configuración y control de límites de operación en términos de montos y cantidades bajo diversos criterios, que deben incluir:

 Por tipo de establecimiento [TPES]

 Por establecimiento [IDES]

 Por tipo de juego xx xxxx [IDJA]

 Por jugador [IDJU]

 Por tipo de operación [TIPO]

 Frecuencia (diaria, semanal, mensual…)

 Combinaciones de las anteriores

En casos de excederse de dichos límites, se requiere que el sistema ofrezca la funcionalidad de configurar el rechazo de las operaciones solicitadas o establecer un registro de alerta de límite excedido, sobre el que se tome una acción futura.

2.3.4 TIPOS DE OPERACIONES (TRANSACCIONES)

Se requiere que el sistema ofrezca la funcionalidad de configuración y manejo de los múltiples tipos de operaciones (transacciones) que se describen a continuación.

2.3.4.1 Inicio (apertura de día)

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de inicio de día (apertura de día).

2.3.4.2 Apuesta

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de apuestas.

2.3.4.3 Compra de fondos

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de compras de fondos (crédito) para su uso posterior en apuestas.

2.3.4.4 Pago ganador

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de pagos a los jugadores ganadores como resultado de una apuesta previa.

2.3.4.5 Anulación

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de anulación de transacciones previas, que por alguna razón requieran ser anuladas.

2.3.4.6 Cierre de sorteo

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de cierre de ventas de para sorteos específicos.

2.3.4.7 Cierre de día

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de cierre de operaciones del día.

2.3.4.8 Compra y venta de mayoreo

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de compras de mayoreo de una banca a otra, para el traspaso de jugadas.

Se requiere que el sistema ofrezca la funcionalidad de manejar las transacciones como COMPRAS para el que compra de mayoreo, y como VENTAS para el que vende, por lo que toda operación de COMPRA DE MAYOREO deberá ser conciliada contra una operación de VENTA DE MAYOREO similar y complementaria.

2.3.4.9 Pago y cobro de mayoreo

Se requiere que el sistema ofrezca la funcionalidad de manejo de transacciones de pago de las jugadas ganadoras producto de COMPRAS DE MAYOREO reportadas previamente.

Se requiere que el sistema ofrezca la funcionalidad de manejar las transacciones como COBROS para quien recibe el pago de jugadas, y como PAGOS para quien lo ejecuta, por lo que toda operación de PAGO DE MAYOREO deberá ser conciliada contra una operación de COBRO DE MAYOREO similar y complementaria.

2.3.5 CONTROL DE PROTECCIÓN JUGADOR

2.3.5.1 Lista de exclusión

Se requiere que el sistema ofrezca la funcionalidad de registro y control de los jugadores participantes, de forma que se pueda establecer una lista de restricción o exclusión basados en el documento de identidad del jugador aplicable a menores, personas con problemas de ludopatía, o criterios de prevención de fraude, lavado de activos u otros.

2.3.5.2 Tiempo de exclusión

Se requiere que el sistema ofrezca la funcionalidad de exclusión temporal, estableciendo una fecha de inicio y una fecha de término de la exclusión. Esto aplicable a casos de autoexclusión o limitación temporal amparada en alguna medida de prevención.

2.3.6 CUENTA DE JUGADOR

2.3.6.1 Configuración de cuentas de jugador

Se requiere que el sistema ofrezca la funcionalidad de configuración de cuentas de jugadores asociados a los IDENTIFICADORES DE JUGADOR [IDJU] para permitir que se realicen créditos y consultas y llevar un control auditable de los fondos disponibles para un jugador (de forma que se pueda determinar en cualquier momento el balance de que dispone el jugador) y la aplicabilidad del uso de las transacciones que hagan uso de dichas cuentas basados en el TIPO DE ESTABLECIMIENTO [TPES] y JUEGO XX XXXX [IDJA].

2.3.6.2 Control de habilitación

Se requiere que el sistema ofrezca la funcionalidad de control para poder habilitar e inhabilitar dichas cuentas y rechazar transacciones relacionadas con ellas en base a los criterios de exclusión por protección al jugador, así como por otras razones de control diversas.

2.3.7 CONTROL DE MENSAJES TRANSACCIONALES

2.3.7.1 Control de conexión

Se requiere que el sistema ofrezca el control de que solo una vez sea establecida la conexión entre el sistema del establecimiento y el sistema central del Ministerio de Hacienda, se puedan enviar y procesar los diversos mensajes transaccionales originados por los establecimientos.

2.3.7.2 Control de día

Se requiere que el sistema ofrezca el control de que todas las transacciones ocurran dentro de un día de operación cuya referencia deberá establecer el sistema con una REFERENCIA DE DÍA [REFD]. El día de operación quedará comprendido entre el mensaje de INICIO (APERTURA DE DÍA) y CIERRE DE DÍA.

2.3.7.3 Registro y control de transacciones

Se requiere que el sistema ofrezca la funcionalidad de mantener un registro y control de cada transacción procesada, cuyo estado de registro solo podrá ser uno de los siguientes:

 Aprobada – cuando todas las reglas para la autenticación fueron cumplidas al momento de recibir la transacción.

 Rechazada – cuando al menos una de las reglas para la autenticación falló al momento de recibir la transacción original.

 Anulada – cuando una vez aprobada la transacción original y estar registrada como APROBADA, se produjo una anulación exitosa mediante una transacción de anulación posterior, cuyo estado quedará registrado como APROBADA.

2.3.7.4 Control de unicidad de operaciones

Se requiere que el sistema ofrezca el control de que toda transacción de un establecimiento contenga un CÓDIGO ÚNICO DE OPERACIÓN [CUOP] que no podrá repetirse para ninguna transacción del ESTABLECIMIENTO [IDES] durante el DÍA DE OPERACIÓN EN [REFD], por lo que el sistema deberá rechazar cualquier otra transacción con dichos códigos, contemplando el manejo especial del MENSAJE DE RÉPLICA.

2.3.7.5 Control de transacciones

Se requiere que el sistema ofrezca el soporte y control del manejo de transacciones según el diagrama de secuencia anexo y los aspectos que destacamos a continuación.

 Las TRANSACCIONES representan todas las operaciones requeridas por el sistema central, salvo

INICIO y CIERRE DE DÍA.

 Las TRANSACCIONES DE CAJA representan aquellas operaciones que se originan directamente en la terminal del punto de venta de una banca (apuesta, pago de ganador, anulación, compra de fondos).

 Las TRANSACCIONES DE MAYOREO representan aquellas operaciones que deberán manejarse a nivel centralizado por algún tipo de supervisor del establecimiento y en las que previo a reportarse se debe establecer una negociación entre dos bancas – ambas con licencias vigentes de operación del Ministerio de Hacienda (compra/venta de mayoreo, pago/cobro de mayoreo y anulaciones de ese tipo de transacciones).

 Durante el transcurso de un día se deberán poder reportar los CIERRES DE VENTA para cada

SORTEO [CSRT] que ocurra durante un día de operación y según sea configurado en el sistema.

2.3.8 MENSAJE DE RÉPLICA

Se requiere que el sistema ofrezca la funcionalidad de manejar MENSAJES DE RÉPLICA.

 Si el sistema del establecimiento no detecta una respuesta de forma instantánea del sistema central del Ministerio de Hacienda, el sistema del establecimiento podrá enviar un segundo mensaje (copia idéntica del anterior) una vez haya transcurrido un tiempo configurado en el sistema central del Ministerio de Hacienda y preestablecido entre las partes (medido en segundos o fracciones de segundos) para intentar obtener su autenticación. Este mensaje será considerado el MENSAJE DE RÉPLICA.

Se requiere que el sistema identifique de forma inequívoca cuando se trate de un MENSAJE DE RÉPLICA

(copia idéntica de todos los campos) a diferencia de otras transacciones y sobre esa base responder.

 Si la transacción enviada como MENSAJE DE RÉPLICA no está registrada en el sistema central, este deberá responder esta transacción de la forma regular y realizar el registro de la misma.

 Si la transacción enviada como MENSAJE DE RÉPLICA ya había sido registrada en el sistema central, éste deberá rechazar la transacción indicando a través de su código de respuesta correspondiente, que ya existe el registro de dicha transacción y manteniendo el registro de la transacción original sin cambio.

o Sin embargo, si la transacción fue previamente APROBADA, deberá no solo responder con un rechazo que indique la condición de que dicha transacción ya había sido previamente APROBADA sino devolver el CÓDIGO ÚNICO DE AUTENTICACIÓN [NAUT] de la transacción

original, permitiendo que se obtenga el NAUT ya emitido para la operación y evitando que se emita un NAUT nuevo para una misma transacción.

Se requiere que el sistema ofrezca la funcionalidad de que si la RÉPLICA no es respondida por el sistema central del Ministerio de Hacienda, una vez transcurrido el tiempo de espera configurado y acordado entre las partes, el sistema del establecimiento podrá proceder a operar en formato de FUERA DE LÍNEA (offline) – ver la sección correspondiente.

2.3.9 RECHAZOS

2.3.9.1 Razones de rechazo

Se requiere que el sistema ofrezca la funcionalidad de configuración de las diversas razones de rechazo junto con sus respectivos códigos de respuesta y descripción.

2.3.9.2 Aplicación de rechazos

Se requiere que el sistema ofrezca la funcionalidad de que si el mensaje transaccional recibido del establecimiento no corresponde con las reglas configuradas en el sistema, o existen condiciones presentes para no autorizar la operación, la transacción sea rechazada con un mensaje que indique la razón.

2.3.9.3 Registro de rechazos

Se requiere que el sistema ofrezca la funcionalidad de registrar la transacción oficialmente en el sistema, SOLO cuando el mensaje llegue bien formado y sus razones de rechazo correspondan al contenido, NO a la estructura del mensaje, en cuyo caso deberá permitir consultarse en la bitácora de mensajes, pero no en el registro de transacciones.

2.4 DATOS DEL MENSAJE

Para cada uno de los tipos de operación (transacciones) requeridos, se ofrece una breve descripción de cada uno de los datos que se requiere que sean gestionados y controlados por el sistema central y que deberán estar presentes en los mensajes transaccionales para cada operación soportada por el sistema.

2.4.1 DATOS DE LA TRANSACCIÓN

Datos enviados como parte de los mensajes de solicitud de autenticación al sistema central del Ministerio de Hacienda.

2.4.1.1 [FEHS] Fecha-hora solicitud

Campo que refleje la fecha y hora en la que se somete la solicitud para el tipo de operación indicada. Deberá permitir establecer con certeza el día (año, mes, día) y la hora (hh:mm:ss) en formato militar de 24 horas. Debe de indicar la fecha y hora en la que se somete la solicitud independientemente de si por alguna eventualidad corresponda a un día de operación diferente (REFERENCIA DEL DÍA).

2.4.1.2 [REFD] Referencia del día (identificador día de operación)

Campo identificador de día de operación al que se refiere la propia transacción, independientemente de que por alguna eventualidad la operación correspondiente sea sometida en una FECHA-HORA DE SOLICITUD diferente. Deberá permitir establecer con certeza el día (año, mes, día).

2.4.1.3 [TIPO] Tipo de operación

Campo indicador del tipo de operación del mensaje, según se describe en el punto 2.3.2 (inicio, apuesta, pago ganador…).

2.4.1.4 [CUOP] Código único de operación

Código único definido para cada operación enviada, que será establecido por la entidad que envía al Ministerio de Hacienda, pero que NO SE PODRÁ REPETIR para dicho establecimiento al menos durante un DÍA DE OPERACIÓN [REFD] para permitir la identificación de cada operación de forma individual y permitir procesar adecuadamente los mensajes de respuesta, las anulaciones y las operaciones fuera de línea. El equivalente a un número de comprobante o ticket para cada transacción.

2.4.1.5 [IDES] Identificador único del establecimiento

Identificador único para el establecimiento supervisado según la configuración del sistema central del Ministerio de Hacienda. En el caso de bancas de lotería, el equivalente al consorcio.

2.4.1.6 [IDLF] Identificador único del local físico

Identificador único para el local físico desde el que se origina la transacción supervisado según la configuración del sistema central del Ministerio de Hacienda. En el caso de bancas de lotería, el equivalente a la banca per se (como parte de un consorcio) y que podrá tener más de una terminal (caja).

2.4.1.7 [IDTR] Identificador único de la terminal

Identificador único de la terminal de la entidad que origina la transacción (según la configuración del sistema central del Ministerio de Hacienda), ubicada dentro del local establecido bajo el identificador único del local que pertenece a un establecimiento supervisado. La estructura mínima que se requiere es:

 [IDES] Establecimiento (consorcio) – entidad compuesta de múltiples bancas (locales)

 [IDLF] Banca (local físico desde el que se opera) – podrá tener más de una terminal (caja)

 [IDTR] Terminal (punto de venta o equipo físico desde el que se emiten los recibos)

2.4.1.8 [IDJU] Identificador único del jugador

Identificador único del jugador que permite establecer la identidad del jugador y que consta de los subcampos:

 [TDJU] Tipo de documento del jugador

 [NDJU] Número del documento del jugador

2.4.1.9 [TDJU] Tipo de documento del jugador

Tipo de documento (cédula, pasaporte, licencia…) que junto con el NÚMERO DE DOCUMENTO PARTICULAR DEL JUGADOR [JUND] conforma el IDENTIFICADOR ÚNICO DEL JUGADOR [IDJU].

2.4.1.10 [NDJU] Número del documento del jugador

Número de documento del tipo indicado en [TDJU] y junto con el cual se conforme el IDENTIFICADOR ÚNICO DEL JUGADOR [XXXX].

2.4.1.11 [IDJA] Identificador del juego xx xxxx

Identificador del juego xx xxxx del que se trate, según haya sido configurado en el sistema central del Ministerio de Hacienda.

2.4.1.12 [CSRT] Código de sorteo específico

Código de sorteo específico que aplica para un JUEGO XX XXXX [IDJA] en particular y que permita especificar el día y hora en específico en el que se lleva a cabo el mismo.

2.4.1.13 [JGDA] Jugada realizada

Detalles de la jugada realizada en una operación, bajo un formato pre-configurable para cada tipo de

JUEGO XX XXXX [IDJA].

2.4.1.14 [CNTA] Uso de cuenta del jugador

Campo tipo FLAG que establece si se usará la CUENTA DE JUGADOR para los propósitos de la operación a la que esté asociada. El balance de dicha cuenta se establecerá tomando en cuenta los créditos y débitos a la misma por las diferentes transacciones:

 COMPRA DE FONDOS - aumentará el disponible por el monto acreditado

 APUESTAS realizadas contra la cuenta del jugador - disminuirá el disponible por el monto apostado

2.4.1.15 [CTOP] Cantidad total de operaciones

La cantidad total de operaciones correspondientes a un día de cierre y que deberá coincidir con la suma de la CANTIDAD DE OPERACIONES POR TIPO [CTOT] para un día de operaciones, cuyo detalle deberá figurar en el campo DESGLOSE DE LA OPERACIÓN [DGLO] para una transacción de CIERRE DE DÍA.

2.4.1.16 [CTOT] Cantidad de operaciones de un TIPO

Cantidad total de operaciones de un TIPO que se sumarizan en un CIERRE DE DÍA, que debe de contemplar solo las transacciones con respuesta exitosa por el sistema central del Ministerio de Hacienda y por tanto excluir las rechazadas. Debe de incluir las transacciones enviadas en formato OFFLINE, excluyendo en el conteo las transacciones que no recibieron respuesta.

2.4.1.17 [CTAP] Cantidad de apuestas para una jugada

Cantidad de apuestas realizadas para una JUGADA [JGDA] en particular en un cierre de ventas para un

SORTEO ESPECÍFICO [CSRT].

2.4.1.18 [MTAP] Monto apostado para una jugada

Monto económico apostado a una JUGADA [JGDA] en particular en un cierre de ventas para un SORTEO ESPECÍFICO [CSRT].

2.4.1.19 [MTOT] Monto de operaciones de un TIPO

Monto económico del total de operaciones de un TIPO que se sumarizan en un CIERRE DE DÍA, que debe de contemplar solo las transacciones con respuesta exitosa por el sistema central el Ministerio de Hacienda y por tanto excluir las rechazadas. Debe de incluir las transacciones enviadas en formato OFFLINE, excluyendo en el conteo las transacciones que no recibieron respuesta.

2.4.1.20 [MTOP] Monto de la operación

El monto económico de la operación de la que se trate.

 APUESTA – monto total apostado, resultado de la suma de cada apuesta (jugada individual) incluida en la misma transacción en el campo de DESGLOSE DE LA OPERACIÓN [DGLO].

 COMPRA DE FONDOS – monto total acreditado (comprado).

 PAGO GANADOR – monto total pagado, resultado de la suma de cada pago individual registrado bajo dicha transacción en el campo de DESGLOSE DE LA OPERACIÓN [DGLO] correspondiente a cada jugada ganadora registrada en el ticket original reclamado.

 COMPRA Y VENTA MAYOREO – monto total comprado (vendido), resultado de la suma de cada apuesta (jugada individual) incluida en la misma transacción en el campo de DESGLOSE DE LA OPERACIÓN [DGLO].

 PAGO Y COBRO MAYOREO – monto total pagado (cobrado), resultado de la suma de cada pago individual registrado bajo dicha transacción en el campo de DESGLOSE DE LA OPERACIÓN correspondiente a cada jugada ganadora registrada en el ticket original reclamado.

 CIERRE DE VENTAS (SORTEO) – monto total apostado, resultado de la suma de cada apuesta (jugada individual) incluida en el campo de DESGLOSE DE LA OPERACIÓN [DGLO].

 CIERRE DE DÍA – monto total de todas las operaciones, resultado de la suma de cada subtotal por

TIPO DE TRANSACCIÓN [TIPO] registrado en dicho cierre en el campo de DESGLOSE DE LA OPERACIÓN

[DGLO] correspondiente al día de operación.

2.4.1.21 [DGLO] Desglose de la operación

Un arreglo [1-n] que desglose por cada fila, los detalles incluidos bajo este campo en la operación de la que se trate.

 Para APUESTA, COMPRA Y VENTA DE MAYOREO – el detalle de las apuestas realizadas bajo la operación, que permita identificar para cada jugada al menos lo siguiente:

o [IDJA] Identificador del juego xx xxxx

o [CSRT] Código de sorteo específico (cuando aplique)

o [JGDA] Jugada realizada – detalles de la apuesta, bajo un formato pre-configurable por cada tipo de juego xx xxxx

o [MTAP] Monto apostado por la jugada

 Para PAGO GANADOR, PAGO Y COBRO MAYOREO – el detalle de los pagos realizados bajo la operación, que permita identificar para cada jugada de la apuesta original a la que está vinculada dicha operación, qué pago se está realizando para cada uno:

o [IDJA] Identificador del juego xx xxxx

o [CSRT] Código de sorteo específico (cuando aplique)

o [JGDA] Jugada realizada – detalles de la apuesta, bajo un formato pre-configurable por cada tipo de juego xx xxxx

o [MTAP] Monto apostado por la jugada

o [MPAG] Monto pagado por apuesta individual (0 si no resultó ganadora)

 Para CIERRE DE VENTAS (SORTEO) – el detalle de todas las jugadas individuales que fueron apostadas para un cierre de sorteo específico:

o [JGDA] Jugada realizada

o [CTAP] Cantidad de apuestas para dicha jugada

o [MTAP] Monto apostado para dicha jugada

 Para CIERRE DE DÍA – el detalle del total de transacciones y montos asociados que permita conciliar todas las operaciones reportadas durante el DÍA DE OPERACIÓN [REFD]. Se excluyen las operaciones de INICIO y CIERRE.

o [TIPO] Tipo de operación

o [CTOT] Cantidad de operaciones de ese TIPO

o [MTOT] Monto de todas las operaciones de ese TIPO

2.4.1.22 [CRZC] Código de razón de anulación

Código configurable en el sistema del Ministerio de Hacienda que deberá indicar un establecimiento como razón de ANULACIÓN de una operación previamente reportada (error de jugada, duplicación de apuestas, etc. y que debe de contemplar casos especiales, como la devolución por motivo de anulación de juego).

2.4.2 DATOS DE REFERENCIA

Datos con el mismo significado y formato que los datos originales que se utilizan para referirse al contenido de una transacción anterior o una entidad similar que se requiere como referencia a la actual.

En cada transacción se especifica el uso particular y queda identificado el campo con el código original del campo seguido de “-R” para indicar “referencia”. Por ejemplo, cuando se requiere usar un campo que se refiera a un CÓDIGO ÚNICO DE OPERACIÓN [CUOP] anterior, dicho campo se documentará como CUOP- R y en la descripción del campo en la transacción correspondiente se dará el significado del contenido exacto que deberá reportarse en dicho campo.

2.4.3 DATOS DE RESPUESTA

Datos enviados como parte de los mensajes de respuesta desde el Ministerio de Hacienda a la entidad que reporta.

2.4.3.0 Mensaje de respuesta

Se requiere que el sistema en sus mensajes de respuesta incluya, en todos los casos, el mensaje original de la solicitud transaccional que realizó el establecimiento, para fines de una correcta identificación de los mismos y trazabilidad.

2.4.3.1 [XXXX] Fecha-hora respuesta

Campo que refleje la fecha y hora en la que se responde la solicitud para el tipo de operación indicado. Deberá permitir establecer con certeza el día (año, mes, día) y la hora (hh:mm:ss) en formato militar de 24 horas. Debe de indicar la fecha y hora en la que se responde la solicitud independientemente de si por alguna eventualidad corresponde a un día de operación diferente (REFERENCIA DEL DÍA).

2.4.3.2 [CRES] Código de respuesta

Código de respuesta numérico resultado de una tabla de posibles respuestas que el sistema central del Ministerio de Hacienda deberá controlar para indicar con claridad la respuesta que se ofrece a la transacción original.

2.4.3.3 [MRES] Mensaje de respuesta – breve descripción (cuando aplique)

Mensaje textual de respuesta con una breve descripción (cuando aplique) de la razón por la que se produce un rechazo. Este mensaje deberá ser parte de la configuración del sistema central del Ministerio de Hacienda en sincronización con su código.

2.4.3.4 [TAUT] Tipo de autenticación (online, offline)

Identificador del tipo de autenticación (online, offline). El tipo deberá indicar ONLINE si fue ofrecida por el sistema central del Ministerio de Hacienda y OFFLINE si fue generada de forma “calculada” por el sistema del establecimiento como mecanismo de contingencia – ver punto 2.14.

2.4.3.5 [CVFL] Código de validación de fuera de línea

Código alfanumérico de cambio diario y diferente para cada establecimiento emitido por el Ministerio de Hacienda para cuando el sistema central no responda, se pueda generar un NÚMERO DE AUTENTICACIÓN ÚNICO CALCULADO mediante la aplicación de un algoritmo de hash criptográfico derivado del uso de este CÓDIGO DE VALIDACIÓN FUERA DE LÍNEA [CVFL], el IDENTIFICADOR ÚNICO DEL ESTABLECIMIENTO [IDES] y el

CÓDIGO ÚNICO DE OPERACIÓN [CUOP], como parámetros para conformar el código con el que el establecimiento envíe posteriormente la operación, una vez esté disponible, y el sistema central pueda comprobar la validez del mismo, mediante la re-aplicación del algoritmo. Ver sección FUERA DE LÍNEA (offline).

NÚMERO DE AUTENTICACIÓN ÚNICO CALCULADO = HASH (“

CÓDIGO DE VALIDACIÓN FUERA DE LÍNEA [CVFL], IDENTIFICADOR ÚNICO DEL ESTABLECIMIENTO [IDES], CÓDIGO ÚNICO DE OPERACIÓN [CUOP]”

“ )

Este NÚMERO DE AUTENTICACIÓN ÚNICO CALCULADO deberá ser incluido en el campo de NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT].

Nota: Solo aplica para la apertura de día. Por lo que en el resto de los mensajes de respuesta NO deberá estar incluido.

2.4.3.6 [MISR] Monto de retención impositiva

Monto económico aplicable como resultado de la retención impositiva por concepto de ISR a un PAGO DE GANADOR cuando aplique y según las reglas configuradas en el sistema central del Ministerio de Hacienda de acuerdo con la normativa vigente.

2.4.3.7 [NAUT] Número de autenticación único

Número de autenticación único ofrecido como respuesta por el sistema central del Ministerio de Hacienda para los tipos de operación de los establecimientos para los que aplique (apuestas, compra de fondos).

2.4.3.8 [NAUT] Calculado

En casos de gestión fuera de línea (offline), el NÚMERO DE AUTENTICACIÓN ÚNICO CALCULADO (ver sección correspondiente) deberá ser incluido en el campo [NAUT] en la sección de respuesta el mensaje del establecimiento al sistema central del Ministerio de Hacienda.

2.5 REGLAS GENERALES

2.5.0 APLICABILIDAD DE REGLAS

Se requiere que el sistema ofrezca la funcionalidad de aplicar las siguientes reglas para todos los tipos de operaciones (transacciones) soportadas.

Se requiere que el sistema ofrezca la funcionalidad de aplicar, en adición, para cada tipo de transacción (transacción) las reglas particulares aplicables a cada una.

2.5.1 DÍA DE OPERACIÓN Y CIERRES

2.5.1.1 Día de operación

Se requiere que el sistema valide que solo se puedan someter transacciones correspondientes al DÍA DE OPERACIÓN [REFD] en curso, luego de un inicio (apertura de día) exitoso y previo al cierre de día.

2.5.1.2 Número único de autenticación

Se requiere que el sistema valide que solo las transacciones exitosas retornen un NÚMERO ÚNICO DE AUTENTICACIÓN [NAUT].

2.5.1.3 Acumulación y proceso de cierre y conciliación

Se requiere que el sistema acumule los totales de cada transacción según la configuración del sistema (ver sección ACUMULADORES) y para cada día de operación validarlos contra los mensajes de cierre de ventas y cierre de día en el PROCESO DE CIERRE Y CONCILIACIÓN diario.

2.5.2 CAMPOS, FORMATOS Y CONTENIDO

2.5.2.1 Formato y estructura

Se requiere que el sistema impida que una transacción sea autenticada si está mal formado el mensaje en cuanto a su estructura o formato.

2.5.2.2 Códigos inválidos

Se requiere que el sistema impida que una transacción sea autenticada si algunos de los códigos son inválidos.

2.5.2.3 Errores de contenido

Se requiere que el sistema impida que una transacción sea autenticada, si a pesar de estar bien formado el mensaje, incluir códigos válidos y no contener errores en los campos, se viola algún aspecto con respecto al contenido del propio campo, tales como:

a. Un campo cuyo valor no pueda repetirse, y se repite (por ejemplo, un CUOP repetido en dos transacciones diferentes).

b. Un campo cuyo valor haga referencia a un contenido anterior que no se identifica (por ejemplo, una relación en un CUOP-R a un valor CUOP no encontrado).

c. Un campo cuyo valor haga referencia a la suma de otros campos en el mismo mensaje, y no coincida la suma (por ejemplo, un MTOP cuyo valor no corresponda al detalle de montos desglosados en DGLO).

d. Un campo cuyo valor haga referencia a un código parte de una estructura y la misma no coincida (por ejemplo, un CSRT que no pertenezca a un IDJA).

i. Cualquier otro tipo de problema vinculado al contenido mismo del campo en el que haya una discrepancia identificable mediante la aplicación de una inspección de reglas de contenido.

Se requiere que el sistema registre la transacción en el sistema SOLO cuando el mensaje llegue bien formado y sus razones de rechazo correspondan al contenido, NO a la estructura del mensaje, en cuyo caso se requiere que el sistema disponga de la capacidad de consultar en la bitácora de mensajes, pero no en el registro de transacciones.

2.5.3 JUEGOS Y SORTEOS

2.5.3.1 Validación de habilitación

Se requiere que el sistema valide que los juegos y sorteos a los que se refieran las transacciones estén habilitados para recibir apuestas y de no estarlos, rechazar la transacción.

2.5.3.2 Cumplimiento de reglas

Se requiere que el sistema valide el cumplimiento de las reglas configuradas para los diversos JUEGOS XX XXXX [IDJA] y SORTEOS [CSRT] y rechazar la transacción si no cumple con las mismas.

2.5.4 CONTROLES DE LÍMITES

Se requiere que el sistema valide el cumplimiento de los límites establecidos en el sistema y rechazar de acuerdo con los mismos cuando aplique – ver sección de LÍMITES.

2.5.5 CONTROLES DE PROTECCIÓN AL JUGADOR

Se requiere que el sistema valide el cumplimiento del control de protección al jugador y rechazar la transacción si el JUGADOR [IDJU] se encuentra en la lista de exclusión temporal o permanente.

2.5.6 CUENTAS DE JUGADOR

Se requiere que el sistema para una transacción que contempla la cuenta de un jugador [CNTA], valide que:

a. El uso de cuentas de jugador esté habilitado para el ESTABLECIMIENTO [IDES] y JUEGO XX XXXX

[IDJA] que se incluya en la transacción.

b. La cuenta de jugador esté habilitada para dicho JUGADOR [IDJU] en particular.

c. En casos de un débito, que se disponga de los fondos suficientes para la operación y reducir del total equivalente a la transacción.

d. En casos de un crédito, que los fondos se hagan disponibles por el total equivalente a la transacción en la cuenta del jugador.

2.5.7 ANULACIONES

2.5.7.1 Validación de dependencia

Se requiere que el sistema controle que una transacción sea anulada siempre que no se haya producido ya el cierre de día o esté referida a otra transacción que dependa de ella que esté sin anular.

2.5.7.2 Reversión de acumuladores

Se requiere que el sistema valide, de ser exitosa una anulación:

a. Revierta los acumuladores relacionados a la misma con relación a los montos, jugadas y cantidades.

b. Revierta el efecto (débito/crédito) de los fondos si se realizó contra una cuenta de jugador.

2.5.7.3 Fuera de línea

Se requiere que el sistema controle que para una transacción reportada fuera de línea (OFFLINE), su anulación cumpla con las mismas condiciones que para una en-línea con las salvedades establecidas por el proceso de FUERA DE LÍNEA y CIERRE Y CONCILIACIÓN DIARIA.

2.5.8 FUERA DE LÍNEA

2.5.8.1 Validación de criterios

Se requiere que el sistema controle que toda transacción fuera de línea sea validada bajo los mismos criterios de las que se procesan en línea y de haber incumplimiento que llevase al rechazo se indique

con un mensaje de respuesta que reconozca la aceptación de la transacción, pero con observaciones a ser resueltas mediante el proceso de cierre y conciliación.

2.5.8.2 Restricción

Se requiere que el sistema controle que toda transacción pueda reportarse como fuera de línea, salvo inicio de día, pago de ganadores y cierre de día.

2.6 MENSAJE DE APERTURA DE DÍA (INICIO)

2.6.1 REQUERIMIENTO DEL MENSAJE

Se requiere que el sistema autentique la APERTURA DE DÍA (INICIO) de cada ESTABLECIMIENTO [IDES] supervisado, para el día indicado bajo LA REFERENCIA DE DÍA [REFD] y previo al envío de peticiones de autenticación de otras operaciones.

Como resultado de una aprobación de inicio de día al establecimiento, se requiere que el sistema responda retornando al establecimiento un CÓDIGO DE VALIDACIÓN DE FUERA DE LÍNEA [CVFL] para controlar los escenarios en los que deba operar en formato OFFLINE – ver sección FUERA DE LÍNEA.

2.6.2 ESTRUCTURA DEL MENSAJE

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.	Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación: inicio
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único del establecimiento
Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
CVFL	Código de validación de fuera de línea

Para los propósitos de inicio de día solo se requiere identificar el establecimiento a nivel de consorcio.

2.6.3 SECUENCIA DE MENSAJES

La transacción de INICIO (APERTURA DE DÍA) deberá ser sometida por el sistema del establecimiento y deberá esperar respuesta del sistema central del Ministerio de Hacienda, quien de ser exitosa la solicitud responderá con una respuesta de aprobación que incluirá el CÓDIGO DE VALIDACIÓN DE FUERA DE LÍNEA [CVFL].

2.6.4 REGLAS ESPECÍFICAS

Se requiere que el sistema, en adición a las reglas generales, controle la validación y aplicación de las siguientes reglas específicas:

1. El establecimiento haya establecido una conexión exitosa con sus credenciales con el sistema central del Ministerio de Hacienda previo al envío de cualquier otra transacción.

2. El sistema controle que solo se pueda tener un inicio de día por establecimiento y que no se pueda abrir un día que no corresponda con el día de operación en curso.

3. No se acepte como una operación de fuera de línea (offline).

4. No se pueda anular una transacción de inicio de día.

5. El sistema deberá controlar que toda otra operación sea rechazada si no ha sido precedida de un inicio (apertura de día) exitoso.

6. Como resultado de una aprobación de inicio de día al establecimiento, el sistema central del Ministerio de Hacienda responder retornando al establecimiento un CÓDIGO DE VALIDACIÓN DE FUERA DE LÍNEA [CVFL] para controlar los escenarios en los que deba operar en formato OFFLINE – ver sección FUERA DE LÍNEA.

2.7 MENSAJE DE APUESTA

2.7.1 REQUERIMIENTO DEL MENSAJE

Se requiere que el sistema autentique cada operación de APUESTA emitida a un jugador, que de ser exitosa incluirá el NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT] que deberá formar parte del comprobante a entregarse al jugador.

2.7.2 ESTRUCTURA DEL MENSAJE

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.	Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación: apuesta

CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único de establecimiento
IDLF	Identificador único del local físico (banca)
IDTR	Identificador único de la terminal de la entidad que origina la transacción
IDJU	Identificador único del jugador
		TDJU	Tipo de documento del jugador
		NDJU	Número del documento del jugador
CNTA*	Campo tipo FLAG que establece si dicha apuesta se realiza contra la CUENTA DEL JUGADOR – usando los fondos disponibles del jugador, siempre que el monto de la operación lo permita.
MTOP	El monto de la operación (suma de cada apuesta incluida, en casos de ser múltiples bajo una misma operación)
DGLO	Desglose de la operación Arreglo [1-n] que desglosa por cada fila las apuestas individuales por cada jugada que conforma esta transacción. 1-n
Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
TAUT	Tipo de autenticación (online, offline)
NAUT	Número de autenticación único

IDJA	Identificador del juego xx xxxx
CSRT	Código de sorteo específico
JGDA	Jugada realizada – detalles de la apuesta, bajo un formato pre-configurable por cada tipo de juego xx xxxx
MTAP	Monto apostado por la jugada

2.7.3 SECUENCIA DE MENSAJES

La transacción de APUESTA deberá ser sometida por el sistema del establecimiento y deberá esperar respuesta del sistema central del Ministerio de Hacienda, quien de ser exitosa responderá con una respuesta que incluirá el NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT].

2.7.4 REGLAS ESPECÍFICAS

Se requiere que el sistema, en adición a las reglas generales, controle la validación y aplicación de las siguientes reglas específicas:

1. En adición a las reglas generales, una apuesta podrá ser anulada mediante una transacción de anulación siempre que no se haya emitido ya el cierre de ventas para al menos uno de los SORTEOS [CSRT] para los que contenga jugadas.

2. Toda apuesta con autenticación exitosa deberá poder ser consultada vía el portal de consultas del sistema central del Ministerio de Hacienda habilitadas para el público – PORTAL DE CONSULTA.

3. Según sea configurado en el sistema central de Hacienda se podrá permitir que para determinados ESTABLECIMIENTOS [IDES] y/o JUEGOS XX XXXX [IDJA] se puedan realizar apuestas en base a los fondos disponibles en una cuenta del jugador. Para estos propósitos, se indica con un flag en el campo [CNTA] esta condición.

2.8 MENSAJE DE COMPRA DE FONDOS

2.8.1 REQUERIMIENTO DEL MENSAJE

Se requiere que el sistema autentique transacciones de COMPRA DE FONDOS (CRÉDITOS) para la realización de apuestas posteriores mediante el uso de los fondos disponibles en una cuenta asociada al JUGADOR [IDJU].

2.8.2 ESTRUCTURA DEL MENSAJE

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.	Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación: compra de fondos
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único de establecimiento

IDLF	Identificador único del local físico (banca)
IDTR	Identificador único de la terminal de la entidad que origina la transacción
IDJU	Identificador único del jugador
		TDJU	Tipo de documento del jugador
		NDJU	Número del documento del jugador
MTOP	El monto de la operación (total de fondos acreditados)
Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
TAUT	Tipo de autenticación (online, offline)
NAUT	Número de autenticación único

2.8.3 SECUENCIA DE MENSAJES

La transacción de COMPRA DE FONDOS es sometida por el sistema del establecimiento y deberá esperar respuesta del sistema central del Ministerio de Hacienda, quien de ser exitosa la solicitud responderá con una respuesta exitosa que incluirá el NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT].

2.9 MENSAJE DE ANULACIÓN DE OPERACIÓN

2.9.1 REQUERIMIENTO DEL MENSAJE

Se requiere que el sistema autentique transacciones de ANULACIÓN de operaciones que hayan sido previamente autenticadas, y que por una razón requieran ser anuladas, y que deberán indicar tanto el

CÓDIGO ÚNICO DE LA OPERACIÓN [CUOP] de la transacción original, como el NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT] otorgado por el Ministerio de Hacienda a la transacción original.

2.9.2 ESTRUCTURA DEL MENSAJE

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.	Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación: anulación
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único de establecimiento
IDLF	Identificador único del local físico (banca)
IDTR	Identificador único de la terminal de la entidad que origina la transacción
CRZC	Código de razón de anulación
CUOP- R	Código CUOP original de la operación a cancelar
NAUT- R	Código NAUT emitido para la operación original a cancelar (cuando aplique)
MTOP	El monto de la operación (el de la operación original a cancelar)
Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
TAUT	Tipo de autenticación (online, offline)
NAUT	Número de autenticación único

2.9.3 SECUENCIA DE MENSAJES

La transacción de ANULACIÓN es sometida por el sistema del establecimiento indicando tanto el CÓDIGO ÚNICO DE LA OPERACIÓN [CUOP-R] que se desea cancelar, como el NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT-

R] ofrecido previamente por el Ministerio, y deberá esperar respuesta del sistema central del Ministerio de Hacienda, quien de ser exitosa la solicitud responderá confirmando la anulación de la transacción.

2.10 MENSAJE DE PAGO DE GANADORES

2.10.1 REQUERIMIENTO DEL MENSAJE

Se requiere que el sistema autentique las transacciones de PAGO A LOS GANADORES resultados de sorteos en los que realizaron apuestas y que deberán incluir tanto la referencia al CUOP del ticket de la apuesta [CUOP-R], como el NAUT original [NAUT-R].

2.10.2 ESTRUCTURA DEL MENSAJE

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.		Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación: pago ganador
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único de establecimiento
IDLF	Identificador único del local físico (banca)
IDTR	Identificador único de la terminal de la entidad que origina la transacción
IDJU	Identificador único del jugador
		TDJU	Tipo de documento del jugador
		NDJU	Número del documento del jugador
CUOP-	Código CUOP original de la operación que originó la jugada ganadora

R
NAUT- R	Código NAUT emitido para la operación original que resultó ganadora
MTOP	El monto de la operación (suma de cada pago incluido, en casos de ser múltiples bajo una misma operación)
DGLO	Desglose de la operación Arreglo [1-n] que desglosa por cada fila los pagos individuales que resultan del ticket ganador que se está pagando. 1-n
Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
MISR	El monto a retenerse por concepto de ISR al pago, según las reglas configuradas en el sistema central.
TAUT	Tipo de autenticación (online, offline)
NAUT	Número de autenticación único

IDJA	Identificador del juego xx xxxx
CSRT	Código de sorteo específico
JGDA	Jugada realizada – detalles de la apuesta, bajo un formato pre-configurable por cada tipo de juego xx xxxx
MTAP	Monto apostado por la jugada
MPAG	Monto pagado por apuesta individual (0 si no resultó ganadora)

2.10.3 SECUENCIA DE MENSAJES

La transacción de PAGO DE GANADOR es sometida por el sistema del establecimiento indicando tanto el

CÓDIGO ÚNICO DE LA OPERACIÓN [CUOP-R] de la apuesta que se desea pagar, como el NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT-R] ofrecido previamente por el Ministerio para dicha apuesta, y deberá esperar respuesta del sistema central del Ministerio de Hacienda, quien de ser exitosa la solicitud responderá autenticando la transacción.

2.10.4 REGLAS ESPECÍFICAS

Se requiere que el sistema, en adición a las reglas generales, controle la validación y aplicación de las siguientes reglas específicas:

1. El sistema deberá poder determinar si no hay coincidencia con una apuesta original (ya sea por el código de la operación original, NAUT emitido o por la apuesta misma), y según la configuración establecida, rechazar la transacción o generar una alerta y registrarla para ser conciliada.

2. El sistema deberá rechazar transacciones de pagos que no correspondan a jugadas realizadas previamente en apuestas y reportadas en el cierre de ventas (sorteo) al que corresponda.

3. El sistema deberá determinar si el monto a pagarse exige la retención del ISR al premio del ganador y sobre la base de la configuración disponible según la Ley establecer el mensaje de respuesta con la información de retención correspondiente que aplica y que deberá ser impreso en el volante de pago.

4. No se deberán admitir operaciones de pago de ganadores FUERA DE LÍNEA (OFFLINE).

2.11 MENSAJES DE COMPRA Y VENTA DE MAYOREO

2.11.1 REQUERIMIENTO DE LOS MENSAJES

Se requiere que el sistema autentique transacciones de COMPRAS Y VENTAS DE MAYOREO entre establecimientos licenciados. Cada establecimiento deberá reportar la operación por su lado: el que COMPRA y el que VENDE. Se requiere que el sistema autentique tanto la COMPRA como la VENTA y aplique las reglas para garantizar la complementariedad de ambas.

2.11.2 ESTRUCTURA DEL MENSAJE

IDJA	Identificador del juego xx xxxx
CSRT	Código de sorteo específico
JGDA	Jugada realizada – detalles de la apuesta, bajo un formato pre-configurable por cada tipo de juego xx xxxx
MTAP	Monto apostado por la jugada

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.	Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación:  compra de mayoreo para el que compra  venta de mayoreo para el que vende
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único del establecimiento (quien envía el mensaje)
IDES-R	Identificador único del establecimiento relacionado – en caso de compra, identificar a la que se le vende. En caso venta, identificar el que hace la compra.
CUOP- R	Código de referencia de mayoreo - debe de corresponder con el CUOP de la transacción del establecimiento que reporta la venta y figurar tanto en el mensaje de compra como en el de venta para que sirva como referencia cruzada de las dos operaciones para poder ser posteriormente conciliadas.
NAUT- R	Número de autenticación único emitido por el MH como resultado de la operación de venta. Solo aplica para el establecimiento que compra.
MTOP	El monto de la operación (suma de cada apuesta incluida, en casos de ser múltiples bajo una misma operación)
DGLO	Desglose de la operación Arreglo [1-n] que desglosa por cada fila las apuestas individuales por cada jugada que conforma esta transacción. 1-n

Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
TAUT	Tipo de autenticación (online, offline)
NAUT	Número de autenticación único

2.11.3 SECUENCIA DE MENSAJES

La transacción de VENTA DE MAYOREO debe ser la primera en someterse. De resultar exitosa la autenticación de dicha venta, el establecimiento que compra deberá reportar la transacción de COMPRA DE MAYOREO utilizando como referencia el CÓDIGO ÚNICO DE OPERACIÓN de la transacción original de venta [CUOP-R] del vendedor y el NÚMERO ÚNICO DE AUTENTICACIÓN ofrecido por el Ministerio de Hacienda [NAUT-R].

2.11.4 REGLAS ESPECÍFICAS

Se requiere que el sistema, en adición a las reglas generales, controle la validación y aplicación de las siguientes reglas específicas:

1. El sistema deberá detectar cualquier diferencia entre las compras registradas por un establecimiento y las ventas reportadas por otro, rechazar la transacción o generar una alerta y registrarla para ser conciliada.

2. Si al cierre del sorteo específico [CSRT] no se ha realizado la operación de compra que complementa la de venta, la operación de venta deberá quedar anulada.

2.12 MENSAJES DE PAGO Y COBRO DE MAYOREO

2.12.1 REQUERIMIENTO DE LOS MENSAJES

Se requiere que el sistema autentique transacciones de PAGOS Y COBROS DE MAYOREO entre establecimientos licenciados, que hayan resultado en jugadas ganadoras para el comprador y que previamente hayan sido autenticadas a través de transacciones de COMPRAS Y VENTAS DE MAYOREO. Cada establecimiento deberá reportar la operación por su lado: el que PAGA y el que COBRA.

Se requiere que el sistema autentique tanto el PAGO como el COBRO y que aplique las reglas para garantizar la complementariedad de ambas y su validez con respecto a las transacciones anteriores: PAGO DE MAYOREO para el que realizó la VENTA DE MAYOREO, y COBRO DE MAYOREO para el que realizó a COMPRA DE MAYOREO.

2.12.2 ESTRUCTURA DEL MENSAJE

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.		Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación:  pago de mayoreo para quien paga el mayoreo  cobro de mayoreo para quien recibe el pago
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único de establecimiento
IDLF	Identificador único del local físico (banca)
IDTR	Identificador único de la terminal de la entidad que origina la transacción
IDJU	Identificador único del jugador
		TDJU	Tipo de documento del jugador
		NDJU	Número del documento del jugador
CUOP- R	Código CUOP original de la operación que originó la jugada ganadora
NAUT- R	Código NAUT emitido para la operación original que resultó ganadora
MTOP	El monto de la operación (suma de cada pago incluido, en casos de ser

	múltiples bajo una misma operación)
DGLO	Desglose de la operación Arreglo [1-n] que desglosa por cada fila los pagos individuales que resultan del ticket ganador que se está pagando. 1-n
Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
MISR	El monto a retenerse por concepto de ISR al pago, según las reglas configuradas en el sistema central.
TAUT	Tipo de autenticación (online, offline)
NAUT	Número de autenticación único

IDJA	Identificador del juego xx xxxx
CSRT	Código de sorteo específico
JGDA	Jugada realizada – detalles de la apuesta, bajo un formato pre-configurable por cada tipo de juego xx xxxx
MTAP	Monto apostado por la jugada
MPAG	Monto pagado por apuesta individual (0 si no resultó ganadora)

2.12.3 SECUENCIA DE MENSAJES

La transacción de PAGO DE MAYOREO debe ser la primera en someterse desde el establecimiento que lo paga. En dicha transacción deberá indicarse el código de referencia de mayoreo [CUOP-R] correspondiente a la venta de mayoreo que se está pagando. De resultar exitosa la autenticación de dicho pago, el establecimiento que compró deberá reportar la transacción de COMPRA DE MAYOREO utilizando como referencia el mismo código de referencia de mayoreo original [CUOP-R] y el NUMERO ÚNICO DE AUTENTICACIÓN resultado de la aceptación de la transacción de pago de mayoreo [NAUT-R].

2.12.4 REGLAS ESPECÍFICAS

Se requiere que el sistema, en adición a las reglas generales, controle la validación y aplicación de las siguientes reglas específicas:

1. El sistema deberá detectar cualquier diferencia entre los pagos de mayoreo reportados por un establecimiento y los cobros de mayoreo reportados por otro, rechazar la transacción o generar una alerta y registrarla para ser conciliada.

2. No se deberán admitir operaciones de pagos y cobros de mayoreo fuera de línea (offline).

3. Si al cierre del día no se ha realizado la operación de cobro que complementa la de pago, la operación de pago deberá quedar anulada.

2.13 MENSAJES DE CIERRE DE SORTEO (VENTAS)

2.13.1 REQUERIMIENTO DEL MENSAJE

Se requiere que el sistema autentique transacciones de CIERRES DE SORTEOS (VENTAS) para cada SORTEO ESPECÍFICO [CSRT] que incluyan la cantidad total y monto total de jugadas realizadas para dicho sorteo para ser conciliado con los mensajes de apuestas individuales autenticados y controlar los posibles ganadores que podrán resultar en los mismos.

El sistema que el sistema determine cualquier diferencia, generar una alerta y registrarla para ser cuadrada.

2.13.2 ESTRUCTURA DEL MENSAJE

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.	Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación: cierre de sorteo
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único del establecimiento
IDJA	Identificador del juego xx xxxx
CSRT	Código de sorteo específico
CTOP	Cantidad total de operaciones exitosas para el cierre de ventas del sorteo (suma de cada cantidad de jugadas CTAP en el campo DGLO).
MTOP	El monto total de las apuestas para el cierre de ventas del sorteo (suma de los montos apostados MTAP en el campo DGLO).

DGLO	Desglose de totales Arreglo [0-n] que desglosa por cada fila los detalles incluidos bajo este campo en el cierre de ventas, por cada jugada que recibió apuestas deberá haber una fila. Las cantidades y totales deberá contemplar solo las transacciones NO rechazadas (en línea o fuera de línea) y NO contemplar las que fueron repetidas previo a obtener autenticación. 0-n
Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
CVFL	Código de validación de fuera de línea

JGDA	Jugada realizada
CTAP	Cantidad de apuestas para dicha jugada
MTAP	Monto apostado para dicha jugada

2.13.3 SECUENCIA DE MENSAJES

La transacción de CIERRE DE VENTAS es sometida por el sistema del establecimiento y deberá esperar respuesta del sistema central del Ministerio de Hacienda, quien de ser exitosa la solicitud responderá confirmando la autenticación de la transacción.

2.14 MENSAJE CIERRE DE DÍA

2.14.1 REQUERIMIENTO DEL MENSAJE

Se requiere que el sistema autentique el CIERRE DE DÍA de cada ESTABLECIMIENTO [IDES] supervisado para el día indicado bajo LA REFERENCIA DE DÍA [REFD], que deberá incluir el total transacciones del día y montos de las mismas, correspondientes a todos los tipos de operaciones realizadas durante dicho día para ser conciliado con los mensajes individuales autenticados, y con esto formalizar la conclusión de las operaciones del día.

El sistema que el sistema determine cualquier diferencia, generar una alerta y registrarla para ser cuadrada.

2.14.2 ESTRUCTURA DEL MENSAJE

TIPO	Tipo de operación
CTOT	Cantidad de operaciones de ese TIPO
MTOT	Monto de todas las operaciones de ese TIPO

El sistema deberá soportar un mensaje transaccional con la siguiente información mínima:

Ref.	Dato
FEHS	Fecha-hora solicitud
REFD	Referencia del día (identificador de día de operación)
TIPO	Tipo de operación: cierre de día
CUOP	Código único de operación (establecido por la entidad que envía)
IDES	Identificador único del establecimiento
CTOP	Cantidad total de operaciones exitosas para el día de cierre (suma de cada cantidad de operaciones por TIPO en el campo DGLO).
MTOP	El monto total de las operaciones para el día de cierre (suma de monto de operaciones por TIPO en el campo DGLO).
DGLO	Desglose de totales Arreglo [1-n] que desglosa por cada fila, los detalles incluidos bajo este campo en el cierre de día, por cada tipo de operación deberá haber una fila. Las cantidades y totales deberá contemplar solo las transacciones NO rechazadas (en línea y fuera de línea) y NO contemplar las que fueron repetidas previo a obtener autenticación 0-n

Respuesta
XXXX	Fecha-hora respuesta
CRES	Código de respuesta
MRES	Mensaje de respuesta – breve descripción (cuando aplique)
CVFL	Código de validación de fuera de línea

2.14.3 SECUENCIA DE MENSAJES

La transacción de CIERRE DE DÍA es sometida por el sistema del establecimiento y deberá esperar respuesta del sistema central del Ministerio de Hacienda, quien de ser exitosa la solicitud responderá confirmando la autenticación de la transacción.

2.15 GESTIÓN FUERA DE LÍNEA (OFFLINE)

Si durante el transcurso del día de operación, el sistema central del Ministerio de Hacienda no responde a un establecimiento de forma instantánea, el sistema del establecimiento podrá enviar un MENSAJE DE RÉPLICA una vez haya transcurrido un tiempo preestablecido entre las partes (medido en segundos o fracciones de segundos).

Si la respuesta al MENSAJE DE RÉPLICA no es recibida por el establecimiento una vez transcurrido el tiempo de espera configurado y acordado entre las partes, el sistema del establecimiento podrá proceder a operar en formato de FUERA DE LÍNEA (offline).

Previo al cierre de día, el establecimiento deberá enviar todos los mensajes pendientes con tipo de autenticación “OFFLINE” una vez detectada mediante “POLLING” que la conexión esté restablecida.

Se requiere que el sistema pueda certificar la validez de dichos mensajes mediante la re-aplicación del algoritmo de hash criptográfico sobre los mismos, basados en los parámetros para el día en cuestión -ver CÓDIGO DE VALIDACIÓN DE FUERA DE LÍNEA [CVFL] y responder con un código de respuesta que permita establecer las condiciones de rechazar si no se cumplen con los criterios.

 Si la transacción enviada como OFFLINE no figura registrada en el sistema central, éste deberá registrarla junto con el NAUT CALCULADO enviado por el establecimiento con estado que figure como FUERA DE LÍNEA.

 Si la transacción enviada como OFFLINE ya había sido registrada en el sistema central, éste deberá responder la transacción indicando a través de su código de respuesta correspondiente, que ya existe el registro de dicha transacción y cómo fue respondida (APROBADA, RECHAZADA).

o Si la transacción fue previamente APROBADA, el sistema central deberá devolver el CÓDIGO ÚNICO DE AUTENTICACIÓN [NAUT] de la transacción original, permitiendo que se obtenga el NAUT ya emitido para la operación y evitando que se emita un NAUT nuevo para una misma transacción. Sin embargo, como ya el establecimiento emitió un CÓDIGO DE AUTENTICACIÓN CALCULADO el sistema central deberá conservar también el registro del NAUT CALCULADO generado por el establecimiento y permitirse su consulta a través del PORTAL DE CONSULTAS.

o Si la transacción fue previamente RECHAZADA, el sistema central deberá luego de responder cambiar al estado de dicha transacción a DISPUTA, de forma que posteriormente se pueda gestionar mediante un proceso de conciliación. Sin embargo,

como ya el establecimiento emitió un CÓDIGO DE AUTENTICACIÓN CALCULADO el sistema central deberá conservar también el registro del NAUT calculado generado por el establecimiento y permitirse su consulta a través del PORTAL DE CONSULTAS.

2.16 PROCESOS DE CIERRE Y CONCILIACIÓN

2.16.1 CIERRE Y CONCILIACIÓN DIARIA

2.16.1.1 Control horario

Se requiere que el sistema pueda contemplar su propio horario de inicio y cierre de día, establecido como ventana de tiempo para el control de sus operaciones, acumuladores y conciliación de operaciones.

2.16.1.2 Acumuladores

Se requiere que el sistema calcule los acumuladores relacionados con las operaciones realizadas por

TIPO DE OPERACIÓN [TIPO], ESTABLECIMIENTO [IDES], TIPO DE JUEGO XX XXXX [IDJA], JUGADOR [IDJU], MONTOS

APOSTADOS [MTOP], y otros acumuladores para fines de estadística, cálculo impositivo y restricciones de límites.

2.16.1.3 Conciliación

Se requiere que el sistema tenga la funcionalidad de conciliación de cada establecimiento de forma diaria y el registro de diferencias, tomando en cuenta:

 Sus operaciones diarias contra sus reportes de cierres.

 Sus operaciones diarias contras las operaciones de los establecimientos y contra los que se efectuaron operaciones de mayoreo.

 Cualquier otro tipo de diferencia o inconsistencia entre las operaciones individuales y el resultado de los cierres.

2.16.1.4 Posición financiera

Se requiere que el sistema reporte la posición financiera neta (saldos en cuentas) de los establecimientos basados en todas las operaciones del día y como cámara de compensación inter- bancas, así como realizar ajustes basados en el resultado de las conciliaciones y auditorias.

2.16.2 ESCRUTINIO

2.16.2.1 Módulo de escrutinio

Se requiere que el sistema cuente con un módulo de escrutinio que permita a partir de la entrada automática vía una interfaz con el sistema de la Lotería Nacional o a través de una entrada manual controlada, registrar los resultados de los sorteos con la información necesaria para establecer los ganadores, jugadas ganadoras y tickets ganadores resultantes de los diversos sorteos cuyos cierres de ventas ya hayan acontecido.

2.16.2.2 Control de pago de ganadores

Se requiere que el sistema la funcionalidad de autenticación o rechazo de transacciones de PAGO DE GANADORES, incluyendo las de MAYOREO (PAGO y COBRO), mediante la validación contra todos tickets en los que dichas jugadas ganadoras fueron adquiridas.

2.16.2.3 Premios no reclamados

Se requiere que el sistema lleve un control e inventario de todos aquellos premios no reclamados y configurar un plazo de vencimiento (en días) para que dichos premios puedan ser monitoreados directamente por el Ministerio de Hacienda, a través de la funcionalidad de CONSULTA Y MONITOREO DE PREMIOS NO RECLAMADOS.

2.17 CÁLCULO IMPOSITIVO

Se requiere que el sistema sobre la base de una configuración paramétrica pueda establecer la tasa de impuesto aplicable al establecimiento (con su frecuencia de aplicación) según la configuración establecida, para al menos los siguientes criterios:

 Por [TPES] TIPO DE ESTABLECIMIENTO

 Por [IDJA] JUEGO XX XXXX]

 Por [TIPO] TIPO DE OPERACIÓN

 Por locales físicos (bancas) – para todas aquellas que estén habilitadas y en operación.

 Por volúmenes (ventas, impuesto único, cantidad de dispositivos, etc.).

 Por pago de ganadores – basados en las reglas del sistema y tomando en cuenta la retención correspondiente del impuesto sobre la renta (ISR).

 Combinaciones de las anteriores.

2.18 PORTAL DE CONSULTA

2.18.1 MÓDULO DE CONSULTA

Se requiere que el sistema disponga de un portal de consulta habilitada al público mediante un acceso web que en base a todas las apuestas registradas en el sistema y los resultados de los diferentes sorteos de juegos xx xxxx controlados por el sistema, permita la validación de tickets de apuestas contra los registros disponibles mediante la entrada del NÚMERO ÚNICO DE AUTENTICACIÓN [NAUT].

2.18.2 VALIDACIÓN DE TICKETS

Se requiere que el sistema retorne la información mínima para identificar correctamente una apuesta mediante la entrada del NÚMERO DE AUTENTICACIÓN ÚNICO [NAUT] de la misma. La respuesta deberá incluir al menos:

 [REFD] DÍA DE OPERACIÓN

 [IDES] ESTABLECIMIENTO, incluyendo nombre del establecimiento

 [CUOP] CÓDIGO ÚNICO DE OPERACIÓN

2.18.3 VALIDACIÓN DE RESULTADOS DE SORTEOS

Se requiere que el sistema ofrezca la funcionalidad de consultar los resultados de los sorteos registrados.

2.18.4 APLICACIÓN MÓVIL

2.18.4.1 Consulta manual

Se requiere que la solución disponga de una aplicación móvil habilitada para plataformas Android y iOS que permita las mismas consultas que se tengan disponibles en el portal de consulta web a través de la digitación del número único de autenticación.

2.18.4.2 Consulta por código xx xxxxxx

Se requiere que la solución disponga de una aplicación móvil que permita la lectura basada en CÓDIGO XX XXXXXX para el escaneo de comprobantes impresos por los establecimientos, facilitando la validación de los tickets.

2.18.4.3 Consulta por QR Code

Se requiere que la solución disponga de una aplicación móvil que permita la lectura basada en QR CODE para el escaneo de comprobantes impresos por los establecimientos, facilitando la validación de los tickets.

2.19 CONSULTA Y MONITOREO DE PREMIOS NO RECLAMADOS

Se requiere que el sistema al momento de vencerse un plazo preconfigurado (en días), aquellas apuestas que resultasen ganadoras (premios) que no hayan sido reclamadas por los jugadores, las identifique e incorpore en un inventario administrable.

2.20 CONSULTAS, REPORTES Y “ DASHBOARDS”

2.20.1 CONSULTAS Y REPORTES DIVERSOS

Se requiere que el sistema ofrezca la funcionalidad de consultas y generar de reportes diversos, tanto impresos como en formato electrónico, basados en la información registrada, de forma jerárquica, por filtros varios, y con capacidades de pivoteo.

 Por fechas y rango de fechas

 Por establecimientos

 Por tipos de establecimientos

 Por bancas

 Por terminales

 Por tipo de operaciones

 Por juegos xx xxxx

 Por sorteos

 Por jugador

 Por jugadas

 Volúmenes y estadísticas

 Cierres, cuadres e inconsistencias

 Recaudación fiscal y proyecciones

 Consultas y reportes administrativos

 Consultas y reportes de fuera de línea

2.20.1.1 Por fecha y rangos de fecha

Se requiere que el sistema permita la consulta y generación de reportes de actividad diaria, semanal, mensual, trimestral, semestral, anual, por fechas y rangos de fechas en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.2 Reportes por establecimientos

Se requiere que el sistema permita la consulta y generación de reportes por establecimientos y tipos de establecimientos en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.3 Reportes por tipos de establecimientos

2.20.1.4 Por bancas

Se requiere que el sistema permita la consulta y generación de reportes por bancas y terminales en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.5 Por terminales

2.20.1.6 Por tipo de operaciones

Se requiere que el sistema permita la consulta y generación de reportes por tipo de operaciones en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.7 Por juegos xx xxxx

Se requiere que el sistema permita la consulta y generación de reportes por juegos xx xxxx en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.8 Por sorteos

Se requiere que el sistema permita la consulta y generación de reportes por sorteos en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.9 Por jugador

Se requiere que el sistema permita la consulta y generación de reportes por jugador en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.10 Por jugadas

Se requiere que el sistema permita la consulta y generación de reportes por jugadas en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.11 Volúmenes y estadísticas

Se requiere que el sistema permita la consulta y generación de reportes de volúmenes de venta, operaciones y estadísticas en base a toda la información disponible y sus acumuladores.

 Por fechas y rango de fechas

 Por establecimientos

 Por tipos de establecimientos

 Por bancas

 Por terminales

 Por tipo de operaciones

 Por juegos xx xxxx

 Por sorteos

 Por jugador

 Por jugadas

 Cierres, cuadres e inconsistencias

 Recaudación fiscal y proyecciones

2.20.1.12 Cierres, cuadres e inconsistencias

Se requiere que el sistema permita la consulta y generación cierres, cuadres e inconsistencias en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.13 Recaudación fiscal y proyecciones

Se requiere que el sistema permita la consulta y generación de reportes de recaudación fiscal y proyecciones en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.14 Consultas y reportes administrativos

Se requiere que el sistema permita la consulta y generación de reportes administrativos en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.1.15 Consultas y reportes de fuera de línea

Se requiere que el sistema permita la consulta y generación de reportes de eventos de fuera de línea en base a toda la información disponible y sus acumuladores, incluyendo información sobre volúmenes de venta y operaciones.

2.20.2 REPORTES A LA MEDIDA

Se requiere que el sistema permita la creación de reportes a la medida en base a toda la información registrada en el sistema.

2.20.3 GENERACIÓN AUTOMÁTICA

Se requiere que el sistema permita la generación automática de reportes basados en actividades como cierres de sorteos, cierres de día y para determinadas fechas y períodos - incluyendo diarias, semanal, mensual, trimestral, semestral y anual.

2.20.4 ENVÍO AUTOMÁTICO

Se requiere que el sistema permita el envío automático de reportes por correo electrónico.

2.20.5 DASHBOARDS

Se requiere que el sistema cuente con “dashboards” de negocios que permitan el monitoreo comercial de toda la operación, con la capacidad de adaptación y de “drill down”.

2.21 INTERFACES CON SISTEMAS

2.21.1 REQUERIMIENTO DE INTEGRACIÓN

Se requiere que el sistema disponga de la capacidad de integración vía interfaces definidos con otros sistemas, en adición a los de los establecimientos.

Para todas las integraciones, es responsabilidad del oferente definir los interfaces necesarios con todos los sistemas de terceros y desarrollar los componentes de los mismos pertinentes al sistema ofertado. Cada entidad con sistema de terceros será responsable de diseñar los componentes de los interfaces pertinentes a sus sistemas de conformidad con los diseños propuestos por los oferentes.

2.21.2 INTEGRACIONES REQUERIDAS

2.21.2.1 Sistema de recaudación de la DGII

Se requiere integración vía interfaz con el sistema de recaudación de la DGII para todo lo referente a las proyecciones de cálculo de tarifas impositivas aplicables basados en la configuración del sistema central.

2.21.2.2 Sistema de control interno del Ministerio de Hacienda

Se requiere integración vía interfaz con el sistema de control interno del Ministerio de Hacienda para todo lo referente a la sincronización de la información relacionada con los establecimientos con licencias, juegos xx xxxx autorizados y cualquier otra información de control requerida para operar.

2.21.2.3 Sistema de la Lotería Nacional

Se requiere integración vía interfaz con el Sistema de la Lotería Nacional para todo lo referente a la validación de resultados de sorteos.

2.22 ALERTAS

Se requiere la capacidad de soportar la configuración de alertas automáticas basadas en reglas de negocios o fallas del sistema.

2.23 SOPORTE A MÚLTIPLES FORMATOS DE MENSAJES

Se requiere la capacidad de soportar múltiples formatos de mensajes con orientación transaccional (XML, Xxxxx, etc.), así como mensajes personalizables y transformación de un tipo de formato a otro (parsing).

*********************** FIN DE REQUERIMIENTOS FUNCIONALES (SECCION A) *************************

2.8.2 REQUERIMIENTOS NO FUNCIONALES (SECCION B)

Esta sección incluye los requisitos no-funcionales que deberán ser cumplidos por el oferente.

******************* INICIO DE REQUERIMIENTOS NO- FUNCIONALES (SECCION B) **********************

3.1 OFERTA BASADA EN SOLUCIÓN DISPONIBLE

3.1.1 SOLUCIÓN DISPONIBLE

Se requiere que la propuesta esté basada en una solución disponible y en operación, y para cada ítem de este documento especificar el cumplimiento o no con cada requerimiento. Para los requerimientos que no son obligatorios, en el caso de que la solución no incluya la funcionalidad específica se requiere indicar el tiempo para su desarrollo e incluir en la propuesta económica el costo detallado de cada requerimiento a desarrollar, como parte de la misma.

3.1.2 TIEMPO DE OPERACIÓN

Se requiere que la solución propuesta haya estado en operación por al menos tres (3) años y que su soporte y mantenimiento haya estado bajo la responsabilidad directa del oferente.

El oferente deberá presentar documentación que avale este requerimiento.

3.2 CONFIGURACIÓN DEL SISTEMA

3.2.0 FLEXIBILIDAD

Se requiere que la solución sea flexible, capaz de crecer y ajustarse a las necesidades y reglas comerciales del Ministerio de Hacienda. La flexibilidad y la adaptabilidad son fundamentales ya que se puede esperar que el entorno de juegos evolucione a lo largo del tiempo de operación de la solución.

3.2.1 AMBIENTE DE PRODUCCIÓN

3.2.1.1 Configuración ambiente producción

Se requiere que la solución propuesta tenga la capacidad de ser implementada en un sitio primario y un secundario, en ambiente de alta disponibilidad, procesando las transacciones en tiempo real. El oferente deberá presentar la arquitectura requerida para lograr este propósito.

3.2.1.2 Mecanismo sincronización de tiempo

Los sistemas de producción deberán tener un mecanismo de sincronización de tiempo para asegurar el registro consistente de las fechas-horas y los reportes de eventos y transacciones.

3.2.2 ESCALABILIDAD DEL SISTEMA

3.2.2.1 Requerimiento de escalabilidad

Se requiere que la solución propuesta sea escalable para adaptarse a los cambios en las demandas de procesamiento. Las demandas pueden cambiar por razones tales como: aumento de establecimientos incorporados al sistema, aumento de transacciones, mayor número de juegos ofrecidos.

3.2.2.1 Descripción de escalabilidad

Se requiere que el oferente describa cómo su sistema puede ser escalable.

3.2.3 ARQUITECTURA TECNOLÓGICA

3.2.3.1 Diagrama de arquitectura

Se requiere que el oferente proporcione diagramas de configuración de los componentes de la solución propuesta de forma tal que se cumplan con los requisitos del sistema establecidos en este pliego.

Cada elemento de hardware (solo si es especializado) y software se deberá identificar por fabricante, nombre del producto y número de modelo, según corresponda. Para el software, se deberán proporcionar los números de versión, garantizando que se trate de la última versión.

Incluir en el diagrama todos los componentes de la solución y cómo se integran, tales como:

 Sistema operativo

 Base de datos

 Servidor aplicativo

 Servidor Web

 Hardware especializado (en caso de aplicar)

3.2.3.2 Componentes de software

Se requiere que el oferente provea un inventario de todos los componentes de software requeridos para operar la solución de forma tal que se cumplan con los requisitos del sistema establecidos en este pliego, incluyendo componentes de terceros que sean necesarios para operar, junto con la descripción correspondiente.

3.2.3.3 Licenciamiento requerido

Se requiere que el oferente detalle todo licenciamiento que sea requerido e indicar con claridad si es parte del costo propuesto.

3.2.3.4 Dimensionamiento de hardware

Se requiere que el oferente presente un dimensionamiento del hardware requerido para correr la solución basados en los elementos de desempeño y volumen de la sección de DESEMPEÑO.

3.2.4 CAPACIDAD DE OPERACIÓN EN FORMATO “CLOUD” Y “ON-PREMISE”

3.2.4.1 Requerimiento de operación híbrida

Se requiere que la solución disponga de la capacidad de operación en formato tanto “cloud”, como “on- premise” y que se pueda correr en un formato híbrido de estos dos formatos, de forma que se pueda contar con un componente “front-end” en formato “cloud” para gestionar todas las interconexiones con todos los establecimientos y un componente “back-office” que pueda operar “on-premise” para toda la gestión de datos, reportería, configuración, conciliación, etc.

3.2.4.2 Arquitectura de operación híbrida

Se requiere que el oferente presente la arquitectura requerida para los propósitos de operar en estos formatos: cloud, on-premise e híbrido.

3.3 SOFTWARE

3.3.1 IDIOMA ESPAÑOL

Se requiere que el sistema esté disponible en español, incluyendo toda la documentación relacionada.

3.3.2 MONEDA DOMINICANA

Se requiere que el sistema esté disponible para pesos dominicanos.

3.3.3 MANTENIMIENTO DEL SOFTWARE

Se requiere que el oferente tenga capacidad instalada para poder soportar el mantenimiento del software. Se requiere la presentación de las capacidades para este propósito.

3.3.4 RESPALDO Y RESTAURACIÓN

3.3.4.1 Capacidad de respaldo y restauración

Se requiere que el sistema soporte la funcionalidad de respaldo y restauración de archivos críticos, software y datos, así como procesos para probar procedimientos de respaldo y restauración.

3.3.4.2 Procedimiento

Se requiere la presentación del procedimiento para estos propósitos de respaldo y restauración.

3.3.5 CAPACIDAD DE INTEGRACIÓN

Se requiere que la solución permita la integración con otras aplicaciones obedeciendo a criterios de integración, interfaces y protocolos basados en estándares. Se requiere que la solución soporte WEB SERVICES.

3.3.6 DESEMPEÑO

3.3.6.1 Capacidad transaccional

Se requiere que el sistema pueda llegar a procesar transacciones a una tasa de 5 MILLONES DE TRANSACCIONES DIARIAS, con 125 TPS (transacciones por segundo) en periodos normales y picos de 250 TPS. Se requiere que el sistema pueda escalar a tasas de desempeño mayores.

3.3.6.2 Requerimientos de hardware

El oferente deberá presentar los requerimientos de hardware que garanticen esta capacidad de procesamiento.

3.3.7 SOPORTE A ESQUEMAS DE SEGURIDAD Y ENCRIPCIÓN

La seguridad de sistema representa un componente crítico para proteger la información e integridad del Ministerio de Hacienda. Los siguientes requisitos de seguridad se aplican a todos los componentes en la configuración del oferente.

3.3.7.1 Encripción de datos

Se requiere que la solución disponga de la capacidad de encripción de datos y de mensajes de punto a punto, basados en estándares.

3.3.7.2 Controles de accesos

Se requiere que el sistema disponga de controles relacionados con la autenticación, autorización y acceso de los usuarios.

3.3.7.3 Controles y procedimientos de auditoría

Se requiere que el sistema disponga de controles y procedimientos que permitan al Ministerio de Hacienda auditar todo el acceso al sistema y cambios realizados.

3.3.7.4 Vulnerabilidad

Se requiere que el sistema no sea vulnerable al acceso no autorizado.

3.3.8 LOGS TRANSACCIONALES

Se requiere soporte para el almacenamiento de todas las transacciones procesadas en el sistema, así como la consulta de los históricos con facilidades para el filtrado de datos y búsquedas.

4. CONSIDERACIONES GENERALES

4.1 CON RELACIÓN AL ALCANCE Y PRECIO DE LA PROPUESTA

Se requiere que todos los elementos presentados a continuación sean parte del precio de la propuesta y son obligatorios en la propuesta técnica:

 Software y componentes requeridos

 Configuración y desarrollo de todo lo necesario para cumplir con los requisitos xxx xxxxxx de condiciones

 Derechos de propiedad sobre el código fuente

 Propiedad intelectual de los desarrollos

 Prueba de concepto

 Entrenamiento para soporte técnico y mantenimiento de la solución

 Acompañamiento en pruebas de calidad, certificación, y desempeño (estrés)

 La solución se considerará completada una vez esté totalmente libre de errores

 Garantía

4.1.1 SOFTWARE Y COMPONENTES REQUERIDOS

Se requiere que el oferente como parte de la propuesta económica incluya TODOS los elementos del software y componentes desarrollados por terceros requeridos para la operación de la plataforma.

4.1.2 PERSONALIZACIÓN PARA CUMPLIR CON REQUERIMIENTOS

Se requiere que el oferente como parte de la propuesta económica incluya todos los servicios de configuración y desarrollos necesarios para cumplir con los requisitos xxx xxxxxx de condiciones, en adición a lo que la solución base ya traiga incluido.

4.1.3 DERECHO DE PROPIEDAD CÓDIGO FUENTE

Se requiere que el oferente incluya en su oferta los programas fuentes de la solución base utilizada, con todas sus modificaciones, actualizaciones y mantenimientos, garantizando además la correspondencia con los ejecutables instalados y operativos. De tal manera que el Ministerio de Hacienda esté en capacidad de asumir la evolución, el soporte y el mantenimiento de la solución.

4.1.4 PROPIEDAD INTELECTUAL DE LOS DESARROLLOS

4.1.4.1 Propiedad intelectual

Se requiere que la propiedad intelectual de los desarrollos realizados para adaptar el sistema de información a los requerimientos del Ministerio de Hacienda sea exclusiva del Ministerio de Hacienda.

4.1.4.2 Derecho de uso

No será permitido hacer uso de todo o parte del desarrollo adicional para la funcionalidad requerida por el Ministerio de Hacienda, para ofrecerlo a otras instituciones, ya sea dentro o fuera de la República Dominicana.

4.1.5 PRUEBA DE CONCEPTO

4.1.5.1 Obligatoriedad

Se requiere que los oferentes que cumplan con TODOS los requerimientos básicos realicen una PRUEBA DE CONCEPTO en las instalaciones del MINISTERIO DE HACIENDA, como parte del proceso de evaluación, que deberá incluir las funcionalidades básicas descritas en el anexo correspondiente.

4.1.5.2 Ubicación – fecha y hora

Se requiere que el oferente ejecute la PRUEBA DE CONCEPTO en las instalaciones del Ministerio de Hacienda en las fechas y horas indicadas en el calendario del proceso.

4.1.5.43 Correspondencia de solución

Se requiere que la solución presentada por el oferente a los efectos de esta PRUEBA DE CONCEPTO

corresponda con la que se proporcionará si resultase ganadora.

4.1.5.4 Presentación de la prueba de concepto

La falla de un oferente en presentar la prueba de concepto dará como resultado el rechazo de la propuesta.

4.1.6 CAPACITACIÓN

4.1.6.1 Capacitación in-sito

Se requiere que el oferente proporcione capacitación al menos veinte (20) recursos del Ministerio de Hacienda, en las oficinas del Ministerio de Hacienda.

4.1.6.2 Idioma de la capacitación

Se requiere que el oferente proporcione toda la capacitación y documentación en español.

4.1.6.3 Capacitación inicial

Se requiere que el oferente capacite al menos veinte (20) recursos del Ministerio de Hacienda sobre el uso y el funcionamiento de la solución, y proporcione manuales de procedimientos, tanto al inicio como en todas las actualizaciones cuando cualquier cambio se realice en el sistema.

4.1.6.4 Capacitación de seguimiento

Se requiere que el oferente, además de la capacitación inicial en el momento de la implementación, proporcione una capacitación de seguimiento para al menos veinte (20) recursos cuando se realicen cambios o actualizaciones en el sistema que lo ameriten, durante la vigencia de la implementación.

4.1.6.5 Capacitación personalizada

Se requiere que el oferente ofrezca la capacitación de manera personalizada para satisfacer las necesidades únicas de los recursos del Ministerio de Hacienda que realizan actividades primarias y de apoyo específicas en las siguientes áreas de funciones:

 Desarrollo y mantenimiento

 Operaciones sobre el sistema

 Soporte

 Administración de seguridad

 Auditoría

4.1.6.6 Documentación

Se requiere que el oferente proporcione documentación para respaldar todas las actividades de capacitación.

4.1.7 ACOMPAÑAMIENTO

4.1.7.1 Pruebas de calidad

Se requiere que el oferente provea su acompañamiento en las pruebas de calidad sobre la solución.

4.1.7.2 Certificación

Se requiere que el oferente provea su acompañamiento en la certificación de la solución.

4.1.7.3 Desempeño (estrés)

Se requiere que el oferente provea su acompañamiento en las pruebas de desempeño sobre la solución.

4.1.7.4 Post-implementación

Se requiere que el oferente provea su acompañamiento post-implementación de la solución por un periodo de tres (3) meses.

 Las personas que vayan a asumir el acompañamiento post-implementación deberán haber sido parte del equipo que haya realizado la implementación.

 De no cumplirse con este requerimiento, el oferente estará sujeto a una penalización del 1% del valor del proyecto.

4.1.8 LIBRE DE ERRORES

La solución se considerará completada una vez esté totalmente libre de errores.

4.1.9 GARANTÍA

Se requiere que el oferente provea una garantía de seis (6) meses de servicios para que se corrija cualquier error que se detecte luego de la aceptación del software.

 Las personas que provean el servicio de garantía deberán haber sido parte del equipo que haya realizado la implementación.

********************** FIN DE REQUERIMIENTOS NO-FUNCIONALES (SECCION B) **********************

2.8.3 CAPACIDAD Y EXPERIENCIA (SECCION C)

************* INICIO DE REQUERIMIENTOS CAPACIDAD Y EXPERIENCIA (SECCION C) *****************

5. REQUERIMIENTOS DE CAPACIDAD Y EXPERIENCIA

Esta sección se incluyen los requisitos de capacidad y experiencia que deberán ser cumplidos por el oferente.

5.1 CAPACIDAD Y EXPERIENCIA

5.1.1 DESCRIPCIÓN DE CAPACIDAD Y EXPERIENCIA

Se requiere que el oferente provea su acompañamiento describa la experiencia y las capacidades para proporcionar los servicios requeridos en este documento.

5.1.2 EXPERIENCIA DE INTEGRACIÓN

Se requiere que el oferente detalle la experiencia de integración de la solución propuesta con plataformas de terceros.

5.1.3 COMPETENCIAS FUNDAMENTALES

Se requiere que el oferente describa las competencias fundamentales y aspectos por los que el oferente entiende tiene una ventaja competitiva.

5.1.4 DESCRIPCIÓN DETALLADA DE CLIENTES

Se requiere que el oferente proporcione una descripción detallada de todos los clientes donde esté instalado el software propuesto, su nivel de uso y el tiempo de uso, así como el tipo de servicios proporcionado directamente por el oferente.

5.1.5 EXPERIENCIA LOCAL

Se requiere que el oferente tenga al menos una implementación activa de la solución base propuesta con no menos de 3 años de haberse implementado en el mercado dominicano y que el mantenimiento de la misma esté bajo su responsabilidad.

5.1.6 ACTUALIZACIÓN DEL SOFTWARE

Se requiere que el oferente describa el proceso por el cual el software propuesto fue desarrollado y se mantiene y conserva actualizado.

5.1.7 PRÁCTICAS DE CALIDAD DE SOFTWARE

Se requiere que el oferente describa las prácticas de calidad de ingeniería de software del oferente. Identifique cualquier certificación bajo estándares de calidad de software reconocidos.

5.1.8 EQUIPO DE TRABAJO

a. Se requiere que el equipo de proyecto del oferente que resulte adjudicatario:

1. Esté dedicado de forma exclusiva a las tareas del proyecto.

2. Ser de habla hispana, todo el personal que tenga contacto con el Ministerio de Hacienda.

3. Dos equipos: un equipo para el desarrollo e implementación del proyecto y un equipo de trabajo para la atención y solución de errores.

b. Se requiere que los profesionales contratados por la empresa oferente que resulte adjudicataria firmen una carta de compromiso de participación en el proyecto por el tiempo de vigencia del mismo. Sin perjuicio de lo anterior, en caso de impedimento absoluto de cualquier profesional, la empresa podrá reemplazarlo por otro de igual capacidad, debidamente calificado y aceptado antes de la contratación por el Ministerio de Hacienda.

c. Cualquier cambio en el equipo de trabajo propuesto, con lo antes indicado generará una penalidad de un uno por ciento (1%) del valor del contrato adjudicado.

d. El Ministerio de Hacienda se reserva el derecho de solicitar a la empresa contratada, el reemplazo de uno o más de los profesionales que formen parte del equipo del proyecto, con expresión de causa o motivo, debiendo la empresa en tal situación, presentar por lo menos tres

(3) alternativas, mediante la entrega de antecedentes curriculares de similares características a las del profesional a reemplazar, en un plazo no mayor xx xxxx (10) días.

e. En cuanto a la composición del equipo de trabajo asignado por el oferente que resulte adjudicatario al proyecto debe tener como mínimo los siguientes recursos con sus perfiles detallados a continuación:

1. Un administrador de proyecto.

2. Un (1) líder técnico.

3. Equipo de desarrolladores necesarios para la subsanación de todas las funcionalidades complementarias dentro del periodo de tiempo presentado por el oferente.

4. Un (1) líder funcional.

f. A continuación, se especifica la definición de perfiles:

1. Administrador de proyecto

Administrador de Proyecto  Responsable de coordinar todas las acciones internas necesarias en el equipo de proyecto designado para estos fines por el oferente que resulte adjudicatario.  Garantizar la ejecución oportuna de todas las actividades en el plan de trabajo del proyecto cumpliendo con los estándares de calidad y mejores prácticas.  Coordinación de la ejecución del proyecto con el administrador del proyecto designado por el Ministerio de Hacienda.  Informar al comité ejecutivo del proyecto del estatus del mismo y de los riesgos identificados que pudieran afectar la ejecución de la planificación del proyecto.
Conocimientos relevantes		Dirección de proyectos
Preparación académica		Licenciado o ingeniero en tecnología, Ingeniero industrial x
		xxxxxxxx afines.
		Maestría en administración o áreas afines
		Certificación vigente en metodología de Proyectos como PMP,
		Agile, etc.
Experiencia laboral		Cinco (5) años como Administrador de proyectos, especialidad en proyectos de software.
		Experiencia con equipos de trabajo de más de 20 personas.
		Al menos tres (3) implementaciones en proyectos de tecnología
Otros requisitos		El idioma de este perfil debe ser español hablado y escrito.

2. Líder técnico

Líder técnico

 Responsable de coordinar todas las labores técnicas del personal a su cargo.

 Obedece a las instrucciones del PM del oferente que resulte adjudicatario.

 Xxxxxxxx con líder técnico del Ministerio de Hacienda asignado.
Conocimientos relevantes		Especialidad en software.
		Conocimientos de Hardware.
Preparación académica		Licenciado o ingeniero en sistemas
Experiencia laboral		Mínimo cinco (5) años como Líder técnico en lenguaje de
		programación de la solución propuesta.
		Experiencia liderando equipos de trabajo.
		Al menos dos (2) años laborando en la solución propuesta.
Otros requisitos		El idioma de este perfil debe ser español hablado y escrito.

3. Líder funcional

Líder funcional  Responsable de coordinar todos los analistas funcionales para la identificación de brechas de la solución propuesta y la operativa actual.  Obedece a las instrucciones del PM del oferente que resulte adjudicatario.
Conocimientos relevantes		Conocimientos de metodología de proyectos según el PMI,
		Agile, entre otras.
		Conocimientos y aplicación Lenguaje Unificado de
		Modelamiento (UML).
Preparación académica		Licenciado o ingeniero en tecnología, Ingeniero Industrial x xxxxxxxx afines.
Experiencia laboral		Mínimo tres (3) años en posición similar.
Otros requisitos		El idioma de este perfil debe ser español hablado y escrito.

5.1.9 REFERENCIAS DEL OFERENTE

Se requiere que el oferente presente cartas de recomendación de al menos tres (3) clientes con el software propuesto en operación durante los últimos 3 años.

Para cada una de ellas, el oferente deberá incluir el nombre, la posición, la dirección y el número de teléfono de la persona de contacto y el tiempo de operación con el software propuesto.

************* FIN DE REQUERIMIENTOS CAPACIDAD Y EXPERIENCIA (SECCION C) *****************

2.8.4 REQUERIMIENTOS PRUEBA DE CONCEPTO

*********************** INICIO DE REQUERIMIENTOS DE PRUEBA DE CONCEPTO *********************

1. OBJETIVO GENERAL

El objetivo general de la PRUEBA DE CONCEPTO es demostrar la viabilidad del sistema propuesto por el oferente en base al subconjunto de funcionalidades que se incluyen en este documento y en la matriz de requerimientos preseleccionados que forma parte de este pliego. En adición, se seleccionará un conjunto de Requisitos Básicos y de Requisitos Complementarios que el oferente haya indicado que cumple en su propuesta técnica, para que sean demostrados operando correctamente durante la prueba de concepto.

2. REQUERIMIENTOS PRESELECCIONADOS DE LA PRUEBA DE CONCEPTO

2.1 OPERACIONES

2.1.1 TIPOS DE OPERACIONES

El oferente deberá simular la generación de los siguientes tipos de operaciones hacia el sistema central, y basados en las reglas pre configuradas bajo su plataforma responder con autenticaciones exitosas y fallidas, estableciendo códigos de respuestas apropiados para cada escenario.

 Inicio (apertura de día) – simulación de la autenticación de inicio de día

 Apuesta – simulación de la autenticación de apuestas

 Anulación – simulación de anulaciones de apuestas

 Pago ganador – simulación de pagos de ganadores

 Cierre de sorteo – simulación de un cierre de sorteo

 Cierre de día – simulación de cierre de día

2.1.2 CONDICIONES DE LA SIMULACIÓN

2.1.2.1 Establecimientos

El oferente deberá simular la generación de operaciones desde tres (3) establecimientos (consorcios), cada uno de los cuales con tres (3) locales (bancas) con una (1) terminal cada uno.

2.1.2.2 Jugadas

El oferente deberá simular la generación de jugadas tanto en apuestas individuales como en apuestas múltiples.

2.1.2.3 Transacciones incorrectas

El oferente deberá simular la generación de transacciones que generen rechazos por:

 Formato y estructura – mensaje mal formado en cuanto a su estructura o formato.

 Códigos inválidos – uso de códigos incorrectos.

 Errores de contenido – violación de algún aspecto con respecto al contenido del propio campo u otras condiciones.

2.1.2.4 Reglas

El oferente deberá simular la generación de transacciones que generen rechazos por:

 Reglas de juegos

 Controles de límites

2.2 REGISTRO DE OPERACIONES

El oferente deberá demostrar el procesamiento de cada uno de los tipos de operaciones anteriores, incluyendo:

 Registro de transacciones – el registro apropiado para cada una de las transacciones que fueron simuladas, permitiendo conservar para cada una los detalles específicos de su contenido, así como el estado resultado de la respuesta del sistema central.

 Consulta de transacciones – la consulta de todas las transacciones que fueron simuladas, de forma que se pueda validar el conjunto total de las mismas y realizar filtros y consultas para encontrar cualesquiera de las transacciones basado en criterios relacionados con los campos, que deberá incluir al menos el día de operación, establecimiento, tipo de operación, monto de la apuesta o pago, mensajes de respuestas identificando sus códigos de respuesta, así como la combinación de los mismos.

2.3 MANEJO DE MENSAJES

El oferente deberá demostrar el manejo adecuado de los mensajes transaccionales, así como el rechazo de transacciones basadas en errores de formato o estructura del mensaje.

El oferente deberá demostrar la bitácora de mensajes transaccionales, independientemente de si los mismos resultan aprobados o rechazados, de forma que se puedan rastrear todas las interacciones con los establecimientos.

 Registro de mensajes – el registro apropiado de intercambio de mensajes resultado de cada petición de los establecimientos al sistema central del Ministerio de Hacienda.

 Consulta de mensajes – la consulta de todos los mensajes de entrada y salida al sistema, en base a criterios y filtros que permitan establecer cualquier condición de error o flujo adecuado de mensajes.

2.4 CONSULTAS

El oferente deberá demostrar las funcionalidades del sistema propuesto para la realización de consultas, tales como:

 Consulta de ventas – consulta que permita la determinación de los volúmenes de ventas de los diversos establecimientos, tomando en cuenta solo las transacciones que no fueron rechazadas y que permita al menos el uso de filtros para búsqueda:

o Por fecha y rangos de fecha

o Por establecimientos

o Por sorteos

 Consulta de ganadores – consulta que permita la determinación de ganadores basado en las apuestas registradas y ESCRUTINIO.

2.5 ESCRUTINIO

El oferente deberá demostrar la funcionalidad de escrutinio a partir de una entrada manual de resultados simulados de un sorteo específico y establecer los ganadores resultantes de las diversas apuestas con jugadas ganadoras registradas en el sistema.

 Se deberá poder identificar las jugadas ganadoras que no hayan sido reclamadas.

2.6 CONFIGURACIÓN GENERAL

El oferente deberá demostrar la configuración general realizada en su sistema para poder gestionar cada uno de los elementos del alcance propuesto y comprobar que el sistema actúa en función de los mismos. El oferente deberá incluir en la demostración al menos la configuración de:

 Establecimientos (consorcio)

 Locales (bancas)

 Terminales

 Juegos xx xxxx

 Sorteos

*********************** FIN DE REQUERIMIENTOS DE PRUEBA DE CONCEPTO **************************

2.9 Plazo y Lugar de Trabajo

La Convocatoria a licitación se hace sobre la base de un plazo para la ejecución de los trabajos de no mayor de dieciocho (18) meses, con un cronograma estimado a nivel de cada producto, actividad o logro de objetivos.

El Adjudicatario realizará su trabajo en las facilidades del Ministerio de Hacienda y en las facilidades de la empresa oferente según sea establecido en las sesiones de trabajo.

2.10 Visita obligatoria a reunión explicativa

Se realizará una (1) convocatoria obligatoria para una reunión donde se realizará la explicación de los pliegos y los objetivos generales de esta licitación. La asistencia a la misma por parte de los oferentes es de carácter obligatorio. En caso de que algún oferente no asista a esta reunión no podrá participar en el proceso de licitación.

Luego de esta reunión los oferentes podrán realizar por escrito todas las preguntas que consideren pertinentes. Estas preguntas serán contestadas en las condiciones especificadas en el pliego dentro de los plazos establecidos en el mismo.

2.11 Resultados o Productos Esperados

Los productos o resultados que debe entregar el Proponente que resulte Adjudicatario serán los especificados en los requerimientos funcionales y no-funcionales de este pliego.

Todos los productos serán propiedad de la Entidad Contratante de acuerdo a las condiciones establecidas en el punto 2.8 de este pliego.

2.12 Coordinación, Supervisión e Informes

El Proponente que resulte Adjudicatario deberá programar sus actividades con el PAFI y la Dirección de Casinos y Juegos xx Xxxx de este Ministerio de Hacienda.

2.13 Duración del Servicio

La Convocatoria a Licitación se hace sobre la base de un suministro para un período máximo de 18 meses

conforme se establezca este Pliego de Condiciones.

2.14 Presentación de Propuestas Técnicas y Económicas “Sobre A” y “Sobre B”

Las Ofertas se presentarán en un Sobre cerrado y rotulado con las siguientes inscripciones:

NOMBRE DEL OFERENTE

(Sello social)

Firma del Representante Legal

COMITÉ DE COMPRAS Y CONTRATACIONES

Ministerio de Hacienda

Referencia: MINISTERIO HACIENDA-CCC-LPN-2018-00034

Dirección: Av. México No.45, Xxxxxx

Teléfono: (809) 687-5131 ext. 2436

Correo electrónico: xxxxxxxxxxx@xxxxxxxx.xxx.xx

Este Sobre contendrá en su interior el “Sobre A” Propuesta Técnica y el “Sobre B” Propuesta Económica.

Ninguna oferta presentada en término podrá ser desestimada en el acto de apertura. Las que fueren observadas durante el acto de apertura se agregaran para su análisis por parte de los peritos designados.

4 La referencia corresponde al nombre de la institución-Comité de Compras y Contrataciones-Licitación Pública Nacional, Licitación Pública Internacional o Licitación Restringida- Año- número secuencial de procedimientos llevados a cabo.

2.15 Xxxxx, Xxxxx y Hora

La presentación de Propuestas “Sobre A” y “Sobre B” se efectuará en acto público, ante el Comité de Compras y Contrataciones y el Notario Público actuante, en el Salón Xxxxxx Xxxxx Xxxxx, sito Av. México No.45, Gazcue, el día miércoles 11 de Julio desde las 8:00 hasta las 10:00 A.M, Apertura sobre "A" 02:00 PM., y sólo podrá postergarse por causas de Fuerza Mayor o Caso Fortuito definidos en el presente Pliego de Condiciones Específicas.

Los “Sobres B” quedarán bajo la custodia del Consultor Jurídico de la institución, en su calidad de Asesor Legal del Comité de Compras y Contrataciones hasta la fecha de su apertura, jueves 02 xx Xxxxxx a las 02:00PM en el Salón Xxxxxx Xxxxx Xxxxx, conforme al Cronograma establecido.

La Entidad Contratante no recibirá sobres que no estuviesen debidamente cerrados e identificados según lo dispuesto anteriormente.

2.16 Forma para la Presentación de los Documentos Contenidos en el “Sobre A”

Los documentos contenidos en el "Sobre A" deberán ser presentados en original debidamente marcado como DOS (2) "ORIGINALES en la primera página del ejemplar, junto con UNA (1), fotocopia simple de los mismos, debidamente marcada, en su primera página, como "COPIA". Las originales y las copias deberán firmarse en todas las páginas por el Representante Legal, debidamente foliadas y deberán llevar el sello social de la compañía.

En adición a la presentación física de la Oferta Técnica del Sobre A, el Proponente deberá entregar una copia de la oferta en formato digital o magnético en archivo tipo PDF.

El “Sobre A” deberá contener en su cubierta la siguiente identificación:

NOMBRE DEL OFERENTE/PROPONENTE

(Sello Social)

Firma del Representante Legal

COMITÉ DE COMPRAS Y CONTRATACIONES

Ministerio de Hacienda

PRESENTACIÓN: OFERTA TÉCNICA

REFERENCIA: MINISTERIO HACIENDA-CCC-LPN-2018-0003

2.17 Documentación a Presentar

A. Documentación Legal:

1. Formulario de Presentación de Oferta (SNCC.F.034);

2. Formulario de Información sobre el Oferente (SNCC.F.042);

3. Copia de los Estatutos Sociales del oferente participante, en caso de ser un oferente constituido bajo las leyes de la República Dominicana los indicados Estatutos deberán estar conforme a la Xxx Xx. 000-00, de fecha 11 de diciembre de 2008, sobre las Sociedades Comerciales y Empresas Individuales de Responsabilidad Limitada y sus modificaciones;

4. Copia legible, vigente y actualizada del Certificado de Registro Mercantil o equivalente del oferente, donde conste que se dedica(n) a la actividad comercial del ámbito de la licitación.;

5. Copia de la última Acta de Asamblea y Nómina de Presencia del oferente;

6. Constancia de inscripción en el Registro de Proveedores del Estado (RPE) en donde el oferente acredite su inscripción en un rubro de la actividad comercial requerida para participar en esta licitación. En el caso de un oferente extranjero, no necesitará estar registrado en el RPE, salvo el caso de que se encuentre domiciliado en la República Dominicana. Sin embargo, si resulta adjudicatario, previa suscripción del contrato, deberá obtener y depositar el registro correspondiente, según lo establecido en los artículos del 21 al 25 del Decreto No. 543-12, de fecha 6 de septiembre de 2012, sobre el Reglamento de aplicación de la precitada Xxx Xx. 000-00;

El Registro de Proveedores del Estado (RPE) deberá estar actualizado conforme lo establece el artículo 19 del Decreto No. 543-12, de fecha 6 de septiembre de 2012, sobre el Reglamento de aplicación de la Xxx Xx. 000-00 y sus modificaciones, así como la Resolución No. 14-2015, de fecha 27 de enero de 2015, dictada por la Dirección General de Contrataciones Públicas;

7. El oferente nacional o extranjero, aún se encuentre inscrito en el Registro de Proveedores del Estado (RPE), deberá presentar una (1) declaración simple en original, en las que se haga constar lo siguiente:

a) Que el oferente no se encuentra afectado por las prohibiciones establecidas en el artículo 14 de la Xxx Xx. 000-00 y sus modificaciones, sobre Compras y Contrataciones de Bienes, Servicios, Obras y Concesiones.

b) Que el oferente tiene o no juicios con el Estado Dominicano o sus entidades del Gobierno Central, de las Instituciones Descentralizadas y Autónomas no Financieras, y de las Instituciones Públicas de la Seguridad Social.

El oferente deberá utilizar el modelo de declaración simple que dispone la Dirección General de Contrataciones Públicas, para estos fines;

8. Certificación actualizada y legible de la Dirección General de Impuestos Internos (DGII) o en su defecto del organismo que en el país de origen del Oferente (si éste no se encuentra domiciliado y/o legalmente representado en la República Dominicana) sea el que determine que se encuentra al día en el pago de sus obligaciones fiscales;

9. Certificación de pago de la Tesorería de la Seguridad Social (TSS) del oferente. En el caso de un oferente extranjero, este requisito sólo aplicará cuando dicho oferente se encuentre domiciliado y/o legalmente representado en la República Dominicana;

10. Poder de Representación otorgado ante Notario Público Nacional o copia del Acta de la Asamblea del Consejo de Administración o de la Asamblea General de Accionistas u Socios, según sea el caso. Si la sociedad comercial participante está representada por su Presidente o Gerente, y siempre y cuando los Estatutos Sociales le otorguen el Poder de Representación de la sociedad, no es necesario presentar este requerimiento;

11. Copia legible y vigente de la Cédula de Identidad y Electoral del Representante Legal. En caso de ser extranjero con residencia, depositará copia legible y vigente de la Cédula de Identidad o Pasaporte si no reside en el país.

B. Documentación Financiera:

1. Estados Financieros de los dos (2) últimos ejercicios contables consecutivos. Años 2016 y 2017.

C. Documentación Técnica:

1. Oferta Técnica (conforme a las especificaciones técnicas suministradas en el acápite 2.8 de este Pliego de Condiciones), incluyendo los documentos de las matrices de evaluación de los requerimientos funcionales, requerimientos no-funcionales y requerimientos de capacidad y experiencia, totalmente completados.

2. Autorización del Fabricante y/o Representante en los casos de que los Bienes no sean fabricados por el Oferente (SNCC.F.047).

3. Certificaciones de recomendación de al menos tres (3) clientes con el software propuesto en operación durante los últimos 3 años.

4. Cartas de compromiso de participación en el proyecto por el tiempo de vigencia del mismo para cada miembro del equipo propuesto.

Para los consorcios:

En adición a los requisitos anteriormente expuestos, los consorcios deberán presentar:

1. Original del Acto Notarial por el cual se formaliza el consorcio, incluyendo su objeto, las obligaciones de las partes, su duración la capacidad de ejercicio de cada miembro del consorcio, así como sus generales.

2. Poder especial de designación del representante o gerente único del Consorcio autorizado por todas las empresas participantes en el consorcio.

2.18 Presentación de la Documentación Contenida en el “Sobre B”

A) Formulario de Presentación de Oferta Económica (SNCC.F.33), presentado en Dos (2) originales debidamente marcados como “ORIGINALES” en la primera página de la Oferta, junto con una (1) fotocopia simple de la misma, debidamente marcada, en su primera página, como “COPIA”. El original y las copias deberán estar firmados en todas las páginas por el Representante Legal, debidamente foliadas y deberán llevar el sello social de la compañía.

B) Garantía de la Seriedad de la Oferta. Correspondiente a Garantía Bancaria. La vigencia de la garantía deberá ser igual al plazo de validez de la oferta establecido en el numeral 3.8 del presente Pliego de Condiciones.

El “Sobre B” deberá contener en su cubierta la siguiente identificación:

NOMBRE DEL OFERENTE/PROPONENTE

(Sello Social)

Firma del Representante Legal

COMITÉ DE COMPRAS Y CONTRATACIONES

Ministerio de Hacienda

PRESENTACIÓN: OFERTA ECONÓMICA

REFERENCIA: MINISTERIO HACIENDA-CCC-LPN-2018-00035

5 La referencia corresponde al nombre de la institución-Comité de Compras y Contrataciones-Licitación Pública Nacional, Licitación Pública Internacional o Licitación Restringida- Año- número secuencial de procedimientos llevados a cabo.

Las Ofertas Económicas deberán ser presentadas únicas y exclusivamente en el formulario designado al efecto, (SNCC.F.033), siendo inválida toda oferta bajo otra presentación.

La Oferta deberá presentarse en Pesos Dominicanos (RD$). Los precios deberán expresarse en dos decimales (XX.XX) que tendrán que incluir todos los impuestos y gastos, transparentados e implícitos según corresponda. Los precios no deberán presentar alteraciones ni correcciones.

El Oferente será responsable y pagará todos los impuestos gubernamentales, dentro y fuera de la República Dominicana, relacionados con los servicios a ser prestados. Ninguna institución sujeta a las disposiciones de la Ley que realice contrataciones, podrá contratar o convenir sobre disposiciones o cláusulas que dispongan sobre exenciones o exoneraciones de impuestos y otros atributos, o dejar de pagarlos, sin la debida aprobación del Congreso Nacional.

El Oferente/Proponente que cotice en cualquier moneda distinta al Peso Dominicano (RD$), se auto- descalifica para ser adjudicatario.

A fin de cubrir las eventuales variaciones de la tasa de cambio xxx Xxxxx de los Estados Unidos de Norteamérica (US$), El Ministerio de Hacienda podrá considerar eventuales ajustes, una vez que las variaciones registradas sobrepasen el CINCO POR CIENTO (5%) con relación al precio adjudicado o de última aplicación. La aplicación del ajuste podrá ser igual o menor que los cambios registrados en la Tasa de Cambio Oficial xxx Xxxxx Americano (US$) publicada por el Banco Central de la República Dominicana, a la fecha de la entrega de la Oferta Económica.

En el caso de que el Oferente/Proponente Adjudicatario solicitara un eventual ajuste, El Ministerio de Hacienda se compromete a dar respuesta dentro de los siguientes cinco (5) días laborables, contados a partir de la fecha de acuse de recibo de la solicitud realizada.

La solicitud de ajuste no modifica el Plan de Trabajo y el Cronograma de Entrega por lo que, el Oferente Adjudicatario se compromete a no alterar la fecha de programación de entrega de los productos pactados, bajo el alegato de esperar respuesta a su solicitud.

Los precios no deberán presentar alteraciones ni correcciones.

Sección III

Apertura y Validación de Ofertas

3.1 Procedimiento de Apertura de Sobres

La apertura de Sobres se realizará en acto público en presencia del Comité de Compras y Contrataciones y xxx Xxxxxxx Público actuante, en la fecha, lugar y hora establecidos en el Cronograma de Licitación.

Una vez pasada la hora establecida para la recepción de los Sobres de los Oferentes/Proponentes, no se aceptará la presentación de nuevas propuestas, aunque el acto de apertura no se inicie a la hora señalada.

3.2 Apertura de “Sobre A”, contentivo de Propuestas Técnicas

El Notario Público actuante procederá a la apertura de los “Sobres A”, según el orden de llegada, procediendo a verificar que la documentación contenida en los mismos esté correcta de conformidad con el listado que al efecto le será entregado. El Notario actuante, deberá rubricar y sellar cada una de las páginas de los documentos contenidos en los “Sobres A”, haciendo constar en el mismo la cantidad de páginas existentes.

En caso de que surja alguna discrepancia entre la relación y los documentos efectivamente presentados, el Notario Público autorizado dejará constancia de ello en el acta notarial.

El Notario Público actuante elaborará el acta notarial correspondiente, incluyendo las observaciones realizadas en el desarrollo del acto de apertura de los Sobres A, si las hubiere.

El Notario Público actuante concluido el acto de recepción, dará por clausurado el mismo, indicando la hora de cierre.

Las actas notariales estarán disponibles para los Oferentes/ Proponentes, o sus Representantes Legales, quienes para obtenerlas deberán hacer llegar su solicitud a través de la Oficina de Acceso a la Información (OAI).

3.3 Validación y Verificación de Documentos

Los Peritos, procederá a la validación y verificación de los documentos contenidos en el referido “Sobre A”. Ante cualquier duda sobre la información presentada, podrá comprobar, por los medios que considere adecuados, la veracidad de la información recibida.

No se considerarán aclaraciones a una oferta presentadas por Oferentes cuando no sean en respuesta a una solicitud de la Entidad Contratante. La solicitud de aclaración por la Entidad Contratante y la respuesta deberán ser hechas por escrito.

Antes de proceder a la evaluación detallada del “Sobre A”, los Peritos determinarán si cada Oferta se ajusta sustancialmente al presente Pliego de Condiciones Específica; o si existen desviaciones, reservas, omisiones o errores de naturaleza o de tipo subsanables de conformidad a lo establecido en el numeral

1.21 del presente documento.

En los casos en que se presenten desviaciones, reservas, omisiones o errores de naturaleza o tipo subsanables, los Peritos procederán de conformidad con los procedimientos establecidos en el presente Pliego de Condiciones Específicas.

3.4 Criterios de Evaluación

El Proponente deberá ser una persona jurídica, (nacional o extranjera) que reúna las calificaciones siguientes:

Las Propuestas deberán contener la documentación necesaria, suficiente y fehaciente para demostrar los siguientes aspectos que serán verificados bajo la modalidad “CUMPLE/ NO CUMPLE”.

Adicionalmente, en este pliego se está incluyendo un listado especifico de los criterios de evaluación que serán utilizados en el mismo.

3.4.1 Elegibilidad

Que el Proponente esté legalmente autorizado para realizar sus actividades comerciales, ofertar los servicios de instalación y de soporte técnico en el país.

3.4.2 Capacidad Técnica

1. Que el Proponente demuestre capacidad técnica y que los Bienes y Servicios cumplen con todos los requisitos básicos especificados en las descripciones de las Fichas Técnicas; y

2. Se evaluarán las propuestas técnicas de cada oferente, si en alguno de los requerimientos básicos de especificaciones técnicas, la propuesta de algún oferente no cumple, se determinará que dicha propuesta no cumple y este oferente será descalificado técnicamente.

3. Adicionalmente, se está incluyendo en este pliego un listado de las capacidades técnicas requeridas que serán evaluadas de acuerdo a los criterios de evaluación establecidos.

3.4.3 Situación financiera

Que cuenta con la estabilidad financiera suficiente para ejecutar satisfactoriamente el eventual Contrato.

El Oferente deberá presentar los Estados Financieros de los dos (2) últimos ejercicios contables consecutivos. Obligatoriamente estarán firmados por un Contador Público Autorizado, siendo causal de exclusión la no presentación de alguno de los mismos o la falta de certificación.

Sobre el último balance, se aplicarán para su análisis los siguientes indicadores:

a) Índice de solvencia = ACTIVO TOTAL / PASIVO TOTAL

Límite establecido: Mayor 1.20

b) Índice de liquidez corriente = ACTIVO CORRIENTE / PASIVO CORRIENTE

Límite establecido: Mayor 0.9

c) Índice de endeudamiento = PASIVO TOTAL/ PATRIMONIO NETO

Límite establecido: Menor 1.50

3.4.4 Criterios de evaluación y calificación particulares

Para la evaluación y calificación de las propuestas referentes a las tablas de cumplimiento, se verificará la página de la propuesta en donde los Oferentes avalaron los requerimientos, mediante las siguientes matrices:

Tabla de Calificación de las Propuestas Matriz de Requerimientos Funcionales Matriz de Requerimientos No Funcionales

Matriz de Requerimientos de Capacidad y Experiencia

Tabla de calificación de las Propuestas Técnicas y Propuestas Económicas
No. Referencia	Factores a Evaluar	Ponderación	Puntaje Máximo
1	Precio total	100%	20
1.1	Precio menor ofertado entre precio oferta
2	Requisitos complementarios	100%	40
2.1	Cumplimiento de requerimientos complementarios funcionales, de manera proporcional. Cantidad de requisitos complementarios cubiertos al inicio de la oferta entre cantidad total de requisitos complementarios.
3	Experiencia de la empresa oferente	100%	30
3.1	Experiencia local Se requiere que el oferente tenga al menos una implementación activa de la solución base propuesta con no menos de 3 años de haberse implementado en el mercado dominicano y que el mantenimiento de la misma esté bajo su responsabilidad.
4	Tiempo total de implementación	100%	10
4.1	Tiempo total de implementación, de acuerdo a los criterios de evaluación y calificación de este pliego.
Total General			100

MATRIZ DE REQUERIMIENTOS FUNCIONALES
Cada requerimiento deberá cumplir con el detalle ofrecido en la sección con # Referencia* del Documento de Requerimientos funcionales, no-funcionales y de capacidad y experiencia de la empresa oferente
No. Elemento	No. Referencia	Ítem a Evaluar	Criticidad Funcionalidades		Completar por el Oferente
No. Elemento	No. Referencia	Ítem a Evaluar	Básica	Comp.	Cumple	No Cumple	Referencia documental en la propuesta técnica del oferente	Acción de sub- sanación en caso de no cumplir (solo aplica para funcionalidades complementarias)	Tiempo de entrega
1	A.	REQUERIMIENTOS FUNCIONALES			REQUERIMIENTOS FUNCIONALES
2	1.	Objetivo general			Objetivo general
3	1.1	Esquema de operación	x
4	2.	Requerimientos funcionales			Requerimientos funcionales
5	2.1	Registro de establecimientos y su estructura			Registro de establecimientos y su estructura
6	2.1.1	Registro general	x
7	2.1.2	Estructura jerárquica			Estructura jerárquica
8	2.1.2.1	Niveles de la estructura	x
9	2.1.2.2	Establecimiento (consorcio)	x
10	2.1.2.3	Locales físicos (bancas)	x
11	2.1.2.4	Terminales	x
12	2.1.3	Credenciales y accesos			Credenciales y accesos
13	2.1.3.1	Gestión de credenciales y accesos	x
14	2.3.1.2	Componentes de las credenciales		x
15	2.1.4	Mecanismo de “polling”		x
16	2.2	Juegos xx xxxx			Juegos xx xxxx
17	2.2.1	Registro de juegos xx xxxx	x
18	2.2.1.1	Registro general y reglas	x
19	2.2.1.2	Códigos de identificación	x
20	2.2.2	Cierre de ventas	x

21	2.2.3	Sorteos	x
22	2.2.4	Jugadas	x
23	2.3	Registro y control de operaciones			Registro y control de operaciones
24	2.3.1	Entidad de autenticación en-línea	x
25	2.3.2	Acumuladores	x
26	2.3.3	Límites	x
27	2.3.4	Tipos de operaciones (transacciones)			Tipos de operaciones (transacciones)
28	2.3.4.1	Inicio (apertura de día)	x
29	2.3.4.2	Apuesta	x
30	2.3.4.3	Compra de fondos		x
31	2.3.4.4	Pago ganador	x
32	2.3.4.5	Anulación	x
33	2.3.4.6	Cierre de sorteo	x
34	2.3.4.7	Cierre de día	x
35	2.3.4.8	Compra y venta de mayoreo		x
36	2.3.4.9	Pago y cobro de mayoreo		x
37	2.3.5	Control de protección jugador			Control de protección jugador
38	2.3.5.1	Lista de exclusión		x
39	2.3.5.2	Tiempo de exclusión		x
40	2.3.6	Cuenta de jugador			Cuenta de jugador
41	2.3.6.1	Configuración de cuentas de jugador		x
42	2.3.6.2	Control de habilitación		x
43	2.3.7	Control de mensajes transaccionales			Control de mensajes transaccionales
44	2.3.7.1	Control de conexión	x
45	2.3.7.2	Control de día	x
46	2.3.7.3	Registro y control de transacciones	x
47	2.3.7.4	Control de unicidad de operaciones	x
48	2.3.7.5	Control de transacciones		x
49	2.3.8	Mensaje de réplica		x
50	2.3.9	Rechazos			Rechazos

51	2.3.9.1	Razones de rechazo	x
52	2.3.9.2	Aplicación de rechazos	x
53	2.3.9.3	Registro de rechazos	x
54	2.4	Datos del mensaje			Datos del mensaje
55	2.4.1	Datos de la transacción			Datos de la transacción
56	2.4.1.1	[FEHS] Fecha-hora solicitud		x
57	2.4.1.2	[REFD] Referencia del día (identificador día de operación)		x
58	2.4.1.3	[TIPO] Tipo de operación		x
59	2.4.1.4	[CUOP] Código único de operación		x
60	2.4.1.5	[IDES] Identificador único del establecimiento		x
61	2.4.1.6	[IDLF] Identificador único del local físico		x
62	2.4.1.7	[IDTR] Identificador único de la terminal		x
63	2.4.1.8	[IDJU] Identificador único del jugador		x
64	2.4.1.9	[TDJU] Tipo de documento del jugador		x
65	2.4.1.10	[NDJU] Número del documento del jugador		x
66	2.4.1.11	[IDJA] Identificador del juego xx xxxx		x
67	2.4.1.12	[CSRT] Código de sorteo específico		x
68	2.4.1.13	[JGDA] Jugada realizada		x
69	2.4.1.14	[CNTA] Uso de cuenta del jugador		x
70	2.4.1.15	[CTOP] Cantidad total de operaciones		x
71	2.4.1.16	[CTOT] Cantidad de operaciones de un TIPO		x
72	2.4.1.17	[CTAP] Cantidad de apuestas para una jugada		x
73	2.4.1.18	[MTAP] Monto apostado para una jugada		x
74	2.4.1.19	[MTOT] Monto de operaciones de un TIPO		x
75	2.4.1.20	[MTOP] Monto de la operación		x
76	2.4.1.21	[DGLO] Desglose de la operación		x
77	2.4.1.22	[CRZC] Código de razón de anulación		x
78	2.4.2	Datos de referencia		x
79	2.4.3	Datos de respuesta			Datos de respuesta
80	2.4.3.0	Mensaje de respuesta		x

81	2.4.3.1	[XXXX] Fecha-hora respuesta		x
82	2.4.3.2	[CRES] Código de respuesta		x
83	2.4.3.3	[MRES] Mensaje de respuesta – breve descripción (cuando aplique)		x
84	2.4.3.4	[TAUT] Tipo de autenticación (online, offline)		x
85	2.4.3.5	[CVFL] Código de validación de fuera de línea		x
86	2.4.3.6	[MISR] Monto de retención impositiva		x
87	2.4.3.7	[NAUT] Número de autenticación único		x
88	2.4.3.8	[NAUT] Calculado		x
89	2.5	Reglas generales			Reglas generales
90	2.5.0	Aplicabilidad de reglas	x
91	2.5.1	Día de operación y cierres			Día de operación y cierres
92	2.5.1.1	Día de operación	x
93	2.5.1.2	Número único de autenticación		x
94	2.5.1.3	Acumulación y proceso de cierre y conciliación		x
95	2.5.2	Campos, formatos y contenido			Campos, formatos y contenido
96	2.5.2.1	Formato y estructura	x
97	2.5.2.2	Códigos inválidos	x
98	2.5.2.3	Errores de contenido	x
99	2.5.3	Juegos y sorteos			Juegos y sorteos
100	2.5.3.1	Validación de habilitación	x
101	2.5.3.2	Cumplimiento de reglas	x
102	2.5.4	Controles de límites	x
103	2.5.5	Controles de protección al jugador		x
104	2.5.6	Cuentas de jugador		x
105	2.5.7	Anulaciones			Anulaciones
106	2.5.7.1	Validación de dependencia	x
107	2.5.7.2	Reversión de acumuladores	x
108	2.5.7.3	Fuera de línea		x
109	2.5.8	Fuera de línea			Fuera de línea
110	2.5.8.1	Validación de criterios		x

111	2.5.8.2	Restricción	x
112	2.6	Mensaje de Apertura de día (inicio)		Mensaje de Apertura de día (inicio)
113	2.6.1	Requerimiento del mensaje	x
114	2.6.2	Estructura del mensaje	x
115	2.6.3	Secuencia de mensajes	x
116	2.6.4	Reglas específicas	x
117	2.7	Mensaje de apuesta		Mensaje de apuesta
118	2.7.1	Requerimiento del mensaje	x
119	2.7.2	Estructura del mensaje	x
120	2.7.3	Secuencia de mensajes	x
121	2.7.4	Reglas específicas	x
122	2.8	Mensaje de Compra de fondos		Mensaje de Compra de fondos
123	2.8.1	Requerimiento del mensaje	x
124	2.8.2	Estructura del mensaje	x
125	2.8.3	Secuencia de mensajes	x
126	2.9	Mensaje de anulación de operación		Mensaje de anulación de operación
127	2.9.1	Requerimiento del mensaje	x
128	2.9.2	Estructura del mensaje	x
129	2.9.3	Secuencia de mensajes	x
130	2.10	Mensaje de pago de ganadores		Mensaje de pago de ganadores
131	2.10.1	Requerimiento del mensaje	x
132	2.10.2	Estructura del mensaje	x
133	2.10.3	Secuencia de mensajes	x
134	2.10.4	Reglas específicas	x
135	2.11	Mensajes de compra y venta de mayoreo		Mensajes de compra y venta de mayoreo
136	2.11.1	Requerimiento de los mensajes	x
137	2.11.2	Estructura del mensaje	x
138	2.11.3	Secuencia de mensajes	x
139	2.11.4	Reglas específicas	x
140	2.12	Mensajes de pago y cobro de mayoreo		Mensajes de pago y cobro de mayoreo

141	2.12.1	Requerimiento de los mensajes		x
142	2.12.2	Estructura del mensaje		x
143	2.12.3	Secuencia de mensajes		x
144	2.12.4	Reglas específicas		x
145	2.13	Mensajes de cierre de sorteo (ventas)			Mensajes de cierre de sorteo (ventas)
146	2.13.1	Requerimiento del mensaje		x
147	2.13.2	Estructura del mensaje		x
148	2.13.3	Secuencia de mensajes		x
149	2.14	Mensaje Cierre de día			Mensaje Cierre de día
150	2.14.1	Requerimiento del mensaje		x
151	2.14.2	Estructura del mensaje		x
152	2.14.3	Secuencia de mensajes		x
153	2.15	Gestión fuera de línea (offline)		x
154	2.16	Procesos de cierre y conciliación			Procesos de cierre y conciliación
155	2.16.1	Cierre y conciliación diaria			Cierre y conciliación diaria
156	2.16.1.1	Control horario	x
157	2.16.1.2	Acumuladores		x
158	2.16.1.3	Conciliación		x
159	2.16.1.4	Posición financiera		x
160	2.16.2	Xxxxxxxxxx			Xxxxxxxxxx
161	2.16.2.1	Módulo de escrutinio	x
162	2.16.2.2	Control de pago de ganadores	x
163	2.16.2.3	Premios no reclamados		x
164	2.17	Cálculo impositivo		x
165	2.18	Portal de consulta			Portal de consulta
166	2.18.1	Módulo de consulta		x
167	2.18.2	Validación de tickets		x
168	2.18.3	Validación de resultados de sorteos		x
169	2.18.4	Aplicación móvil			Aplicación móvil
170	2.18.4.1	Consulta manual		x

171	2.18.4.2	Consulta por código xx xxxxxx		x
172	2.18.4.3	Consulta por QR Code		x
173	2.19	Consulta y monitoreo de premios no reclamados		x
174	2.20	Consultas, Reportes y “dashboards”			Consultas, Reportes y “dashboards”
175	2.20.1	Consultas y reportes diversos			Consultas y reportes diversos
176	2.20.1.1	Por fecha y rangos de fecha	x
177	2.20.1.2	Reportes por establecimientos	x
178	2.20.1.3	Reportes por tipos de establecimientos		x
179	2.20.1.4	Por bancas	x
180	2.20.1.5	Por terminales	x
181	2.20.1.6	Por tipo de operaciones	x
182	2.20.1.7	Por juegos xx xxxx	x
183	2.20.1.8	Por sorteos	x
184	2.20.1.9	Por jugador		x
185	2.20.1.10	Por jugadas	x
186	2.20.1.11	Volúmenes y estadísticas		x
187	2.20.1.12	Cierres, cuadres e inconsistencias		x
188	2.20.1.13	Recaudación fiscal y proyecciones		x
189	2.20.1.14	Consultas y reportes administrativos	x
190	2.20.1.15	Consultas y reportes de fuera de línea		x
191	2.20.2	Reportes a la medida		x
192	2.20.3	Generación automática		x
193	2.20.4	Envío automático		x
194	2.20.5	Dashboards		x
195	2.21	Interfaces con sistemas			Interfaces con sistemas
196	2.21.1	Requerimiento de integración	x
197	2.21.2	Integraciones requeridas			Integraciones requeridas
198	2.21.2.1	Sistema de recaudación de la DGII		x
199	2.21.2.2	Sistema de control interno del Ministerio de Hacienda		x
200	2.21.2.3	Sistema de la Lotería Nacional		x

201	2.22	Alertas		x
202	2.23	Soporte a múltiples formatos de mensajes		x
			52	110

MATRIZ DE REQUERIMIENTOS NO-FUNCIONALES
Cada requerimiento deberá cumplir con el detalle ofrecido en la sección con # Referencia* del Documento de Requerimientos funcionales, no-funcionales y de capacidad y experiencia de la empresa oferente
No. Elemento	No. Referencia	Ítem a Evaluar	Criticidad Requerimientos		Completado por el Oferente
No. Elemento	No. Referencia	Ítem a Evaluar	Básica	Complemen taria	Cumple	No Cumple	Referencia documental en la propuesta técnica del oferente	Acción de sub- sanación en caso de no cumplir (solo aplica para funcionalidades complementarias)	Tiempo de entrega
1	B.	REQUERIMIENTOS NO-FUNCIONALES			REQUERIMIENTOS NO-FUNCIONALES
2	3.	Requerimientos no-funcionales			Requerimientos no-funcionales
3	3.1	Oferta basada en solución disponible			Oferta basada en solución disponible
4	3.1.1	Solución disponible	x
5	3.1.2	Tiempo de operación	x
6	3.2	Configuración del sistema			Configuración del sistema
7	3.2.0	Flexibilidad	x
8	3.2.1	Ambiente de producción			Ambiente de producción
9	3.2.1.1	Configuración ambiente producción	x
10	3.2.1.2	Mecanismo sincronización de tiempo	x
11	3.2.2	Escalabilidad del sistema			Escalabilidad del sistema
12	3.2.2.1	Requerimiento de escalabilidad	x
13	3.2.2.1	Descripción de escalabilidad	x
14	3.2.3	Arquitectura tecnológica			Arquitectura tecnológica
15	3.2.3.1	Diagrama de arquitectura	x
16	3.2.3.2	Componentes de software	x
17	3.2.3.3	Licenciamiento requerido	x
18	3.2.3.4	Dimensionamiento de hardware	x
19	3.2.4	Capacidad de operación en formato “cloud” y “on-premise”			Capacidad de operación en formato “cloud” y “on-premise”
20	3.2.4.1	Requerimiento de operación híbrida	x

Document Metadata

Table of Contents

REPÚBLICA DOMINICANA

Document Metadata