4. Modelo técnico

4. Modelo técnico

4.1 Estructura de la información.

4.1.1 Registros.

Se denomina registro a cada información transmitida, y que técnicamente está constituido por un elemento de información definido en el XSD del modelo de datos de monitorización (en adelante XSD).

4.1.2 Subregistros.

Se denomina subregistro (subdivisión del registro) a cada una de las partes, formadas por varios elementos XML, en las que, por razones técnicas originadas por la posible existencia de registros muy voluminosos, pueden dividirse éstos.

4.1.3 Lote.

Se denomina lote a un elemento XML definido en el XSD, que tiene una información de cabecera.

– Información periódica (RU, CJ, OP, JUA, CEV): cada registro se reportará en un lote (o en varios, si hay fragmentación del registro en más de 10 subregistros). Se genera diaria y/o mensualmente, según el tipo de fichero. Se ha de cumplir la siguiente regla: A partir de 10 subregistros, se debe generar un nuevo lote (y sólo se puede generar uno cuando se haya cubierto el cupo de 10 subregistros en el anterior). Por tanto, sólo el último lote correspondiente a un registro (es decir, el que contiene los últimos subregistros) puede contener un número de subregistros menor que 10. Un lote no debe incluir información relativa a registros distintos. En particular, no deben existir rectificaciones de dos registros distintos en un mismo lote.

– Información en tiempo real (JUC): en este caso, un lote contiene información de uno o varios registros, cada uno de los cuales se corresponde con una apuesta, torneo, concurso, sorteo o sesión, dependiendo del tipo de juego de que se trate. Se generará un lote cuando transcurran 15 minutos desde que se generó el lote anterior o cuando se alcance la cifra de 500 subregistros en dicho lote (lo que suceda antes).

Un lote representa un fichero que se guardará en el Almacén.

4.1.4 Firma del lote.

El lote es un elemento XML que debe ir firmado con el certificado del operador, o, en su caso, con el certificado de una empresa debidamente capacitada y autorizada por el operador.

La especificación para la firma digital de los lotes es XAdES-BES versión 1.3.2. Dentro de esta especificación, se aceptarán dos métodos de firma, pudiendo el operador optar por cualquiera de los mismos:

– Utilizar la firma XAdES-BES 1.3.2 «enveloped».

• En este caso la firma estará incluida dentro del propio XML del lote, ya que el formato «enveloped» incrusta un elemento «Signature» dentro del XML del lote.

• El fichero firmado se denominará enveloped.xml».

– Utilizar la firma XAdES-BES 1.3.2 «enveloping de un manifiesto» del lote.

• La firma de un manifiesto está específicamente diseñada para optimizar el proceso de firma.

• En este caso se obtendrán dos documentos: el lote original, que se denominará «lote.xml», y firma del manifiesto del lote, que se denominará «enveloping.xml».

• Se realizará la firma «enveloping» del manifiesto, tal y como se describe en http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest y http://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloping.

• El manifiesto referencia al fichero «lote.xml» mediante la URI <Reference> y contiene el hash SHA-256 del lote.

En el caso de tener algún problema con la firma enveloped, dependiendo de la implementación del operador, pueden intentar solucionarlo añadiendo en la cabecera del lote el espacio de nombres de xmldsig y el elemento schemaLocation con la localización de la definición del esquema tal y como se muestra en el ejemplo a continuación:

<Lote	xmlns="http://cnjuego.gob.es/sci/v1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://cnjuego.gob.es/sci/v1.0.xsd CNJ_Monitorizacion_1.0.xsd http://www.w3.org/2000/09/xmldsig# xmldsig-core-schema.xsd"> 

4.1.5 Compresión y cifrado del lote.

El lote ya firmado, se debe comprimir y cifrar mediante la generación de un fichero ZIP.

En el caso de firma «enveloped», el fichero ZIP contendrá un único fichero denominado «enveloped.xml».

En el caso de firma «enveloping de un manifiesto», el fichero ZIP contendrá dos ficheros, «lote.xml» y «enveloping.xml».

Para garantizar la compatibilidad del formato ZIP, el formato debe respetar las extensiones de WinZip sobre la especificación de PKWare para introducir cifrado AES-256. La información puede obtenerse de http://www.winzip.com/aes_info.htm y ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip

El algoritmo de compresión será «Deflate».

El algoritmo de cifrado será «AES-256». La contraseña tendrá una longitud de 50 caracteres y contendrá obligatoriamente dígitos, caracteres y caracteres especiales (tipo: #, $, & ó !) y junto con el resto de claves será responsabilidad del operador su custodia.

El resultado es un fichero firmado, comprimido y cifrado que se deposita en el sistema de ficheros del Almacén.

4.2 Estructura de directorios.

El Almacén constará de la siguiente estructura de directorios, también organizada por áreas:

Nivel 1: CNJ.

Nivel 2: <OperadorId>. (Para el caso de que haya varios operadores en un mismo Almacén).

Niveles 3, 4, 5 y 6:

– RU: Registro de Usuario.

• Diario / Mensual.

○ RUD: Registro de usuario (por jugador).

• Mensual.

○ RUT: Registro de usuario (totales).

○ RUR: Registro de usuario en red (por jugador).

○ RUG: Registro de usuarios ganadores en juegos sin registro previo (por jugador).

– CJ: Cuenta de Juego.

• Diario / Mensual.

○ CJT: Cuenta de juego (totales).

○ CJD: Cuenta de juego (por jugador).

– OP: Operador.

• Subcarpetas para cada Tipo de Juego (según lista del apartado «Tipo de Juego»).

○ OPT: Cuenta de Operador (totales).

○ ORT: Cuenta de Operador de Red (totales).

○ BOT: Cuenta de botes y partidas vivas (totales).

– JU: Juego.

• <AAAAMMDD>: Día en curso.

○ SES: RegistroOtrosJuegos.

○ POT: RegistroPokerTorneo.

○ RAC: RegistroApuestaContrapartida.

○ RAM: RegistroApuestaMutua.

○ COC: RegistroConcurso.

○ LOT: RegistroLoteria.

○ LOP: RegistroLoteriaPresorteada.

• Anteriores.

• Mensual.

○ JUA: Ajustes de Apuestas.

○ CEV: Catálogo de Eventos (mensuales).

• Diario.

○ CEV: Catálogo de Eventos (diarios).

Los nombres de las carpetas en el SCI del operador (indicados aquí mediante un subrayado) han de coincidir exactamente con lo que se especifica, utilizando mayúsculas y minúsculas como corresponda.

4.3 Empaquetado de los datos de juegos.

Respecto a los datos de JU: Juegos, se mantienen los lotes del día en curso, pero los días anteriores se deben agrupar en un único fichero.

El nivel 4 para los Juegos tendrá una carpeta para los ficheros de periodicidad mensual, otra para los de periodicidad diaria, una carpeta para el día en curso, y otra carpeta para días anteriores:

– Mensual: Para depositar los ficheros con los ajustes de apuestas (JUA) y catálogo de eventos (CEV) de periodicidad mensual.

– Diario: Para depositar los ficheros del catálogo de eventos (CEV) de periodicidad diaria.

– AAAAMMDD: Para el día en curso. Los registros de Juegos (JUC) se generan en tiempo real. El día en curso contendrá todos los lotes/ficheros generados individualmente.

– Anteriores: Para días anteriores.

Cuando finalice el día (24:00), el operador procederá a empaquetar toda la carpeta Juegos del día que ha finalizado en un fichero ZIP sin compresión ni cifrado. Por tanto, esto solo afecta a ficheros de tipo JUC.

Este fichero empaquetado conservará la ruta relativa (la estructura de subcarpetas a partir de AAAAMMDD) y todos los lotes/ficheros del día, estos sí, comprimidos y cifrados con la clave correspondiente. Hay un tamaño máximo de fichero de 1 GB para este archivo total de Juegos del día, de forma que, si supera el umbral de 1 GB, se generarán varios fragmentos.

Finalmente, este fichero ZIP (o varios ficheros de fragmentos del ZIP) se moverá a la carpeta «Anteriores» y el operador deberá eliminar la carpeta de Juegos del día finalizado.

4.4 Nomenclatura de archivos.

4.4.1 RU: Registro de Usuario.

La nomenclatura es:

<OperadorId>_<AlmacenId>_<Tipo>_<Subtipo>_<Periodicidad>_<Fecha>_<LoteId>.zip

Valores:

– <OperadorId> es el identificador del operador.

– <AlmacenId> es el identificador del Almacén.

– <Tipo> será RU.

– <Subtipo> puede ser: RUT, RUD, RUR, RUG.

– <Periodicidad> puede ser: D (diario) o M (mensual).

– <Fecha> es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Para información diaria tendrá el valor AAAAMMDD y para información mensual AAAAMM.

– <LoteId> es el identificador del lote.

4.4.2 CJ: Cuenta de juego.

La nomenclatura es:

<OperadorId>_<AlmacenId>_<Tipo>_<Subtipo>_<Periodicidad>_<Fecha>_<LoteId>.zip

Valores:

– <OperadorId> es el identificador del operador.

– <AlmacenId> es el identificador del Almacén.

– <Tipo> será CJ.

– <Subtipo> puede ser: CJT, CJD.

– <Periodicidad> puede ser: D (diario) o M (mensual).

– <Fecha> es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Para información diaria tendrá el valor AAAAMMDD y para información mensual AAAAMM.

– <LoteId> es el identificador del lote.

4.4.3 OP: Cuenta de Operador.

La nomenclatura es:

<OperadorId>_<AlmacenId>_<Tipo>_<Subtipo>_<TipoJuego>_<Periodicidad>_ <Fecha>_<LoteId>.zip

Valores:

– <OperadorId> es el identificador del operador.

– <AlmacenId> es el identificador del Almacén.

– <Tipo> será OP.

– <Subtipo> puede ser: OPT, ORT o BOT.

– <TipoJuego> según la lista de tipos de juego Juego (ver apartado «Tipo de Juego»).

– <Periodicidad > solo puede ser: M (mensual).

– <Fecha> es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Tendrá formato AAAAMM.

– <LoteId> es el identificador del lote.

4.4.4 JU: Registro de Juego.

Los ficheros del día en curso tendrán la siguiente nomenclatura:

<OperadorId>_<AlmacenId>_<Tipo>_<Subtipo>_<TipoJuego>_<Fecha/Hora>_<LoteId>.zip

Valores:

– <OperadorId> es el identificador del operador.

– <Tipo> será: JU.

– <Subtipo> será: JUC.

– <TipoJuego> según la lista de tipos de registro (SES, POT, RAC, RAM, COC, LOT o LOP).

– <Fecha/Hora> es la fecha del lote, formato AAAAMMDDHHMMSS.

– <LoteId> es el identificador del lote.

Los ficheros empaquetados para los Juegos de días anteriores tendrán la siguiente nomenclatura:

<OperadorId>_<AlmacenId>_<Tipo>_DIARIO_<Fecha>.<zip>

Valores:

– <OperadorId> es el identificador del operador.

– <Tipo> será: JU.

– <Fecha > es la fecha del día agrupado, formato AAAAMMDD.

– <ZIP>: La extensión será «zip», pero si ha de fragmentarse por superar el tamaño de 1 GB aparecerán otras extensiones correlativas. Estas adoptarán la forma «zip.00x», donde x será 1 para el primer fragmento, 2 para el segundo, y así sucesivamente.

4.4.5 JUA: Ajustes de Apuestas y CEV: Catálogo de Eventos.

La nomenclatura es:

<OperadorId>_<AlmacenId>_<Tipo>_<Subtipo>_<Periodicidad>_<Fecha>_<LoteId>.zip

Valores:

– <OperadorId> es el identificador del operador.

– <AlmacenId> es el identificador del Almacén.

– <Tipo> será JU.

– <Subtipo> puede ser: JUA o CEV.

– <Periodicidad> solo puede ser: D (diario) o M (mensual).

– <Fecha> es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Para información diaria tendrá el valor AAAAMMDD y para información mensual AAAAMM.

– <LoteId> es el identificador del lote.

4.5 Conceptos generales.

4.5.1 OperadorId.

Este código es proporcionado por la Dirección General de Ordenación del Juego en el proceso de obtención de licencia y es único y nominativo para cada operador.

Siempre que se haga referencia a un operador, debe indicarse el OperadorId único proporcionado por la Dirección General de Ordenación del Juego.

4.5.2 AlmacenId.

Este código es proporcionado por la Dirección General de Ordenación del Juego en el proceso de obtención de licencia y es único para cada Almacén.

Los Almacenes que actúan como réplica no deben utilizar un AlmacenId distinto del Almacén principal.

4.5.3 Registro.

Un registro representa una unidad de información completa en un periodo determinado que se reporta al Almacén.

Un registro queda definido por tres parámetros:

– El tipo de información: RU, CJ, OP o JU.

– La periodicidad: Mensual, diaria o tiempo real.

– El nivel de detalle: Totalizada y Desglosada.

Por ejemplo, registro de usuario detallado de un día, la cuenta de juego totalizada de un mes o cada uno de los registros de juego en el momento que se conoce su resultado.

Los registros constan de una cabecera común e información específica para cada tipo de información.

El RegistroBase es el tipo del que se derivan todos los registros. Se trata de un tipo abstracto, lo cual quiere decir que no puede reportarse directamente. Los registros que han de reportarse se derivan del RegistroBase o de otros tipos abstractos intermedios.

Descomposición de un registro en subregistros:

Todos los registros con desglose a nivel de jugador (RUD, RUR, RUG, CJD y JUC) con un número de jugadores superior a 1.000 se deberán descomponer en subregistros, con un máximo de 1.000 jugadores cada uno. Antes de empezar un subregistro nuevo, hay que agotar los 1.000 jugadores que le caben al subregistro en curso.

Esta misma descomposición en subregistros es aplicable también al catálogo de eventos (CEV) y al registro de ajustes de apuestas (JUA), contabilizándose 1000 eventos por subregistro para CEV y 1.000 ajustes por subregistro para JUA.

4.5.4 Rectificaciones.

Si el operador detecta que los datos que ha grabado en algún registro son erróneos, debe proceder a su rectificación.

Sustitución completa de un registro anterior presentando el nuevo registro. En la grabación del nuevo registro se hará uso de los campos «Rectificacion» para indicar cuál es el registro sustituido. En la sustitución, debe indicarse contenido para todos los campos (no únicamente las modificaciones).

La sustitución debe generarse siempre dentro del mismo Almacén.

El registro sustituido no debe eliminarse físicamente. Se entenderá anulado lógicamente.

El registro para realizar la sustitución completa es un registro nuevo que tenga informados los campos de «Rectificación».

4.5.5 Registros periódicos.

Los registros de información periódica se basan en tipos derivados del RegistroBase, con campos adicionales que permiten determinar el periodo respecto al cuál se reportan los datos. Son de nuevo tipos abstractos, que no pueden presentarse directamente.

– Si el registro es susceptible de reporte mensual y diario (RUD, CJD, CJT y CEV), se utilizará RegistroPeriodicoBase.

– Si el registro sólo se puede reportar mensualmente (RUT, RUR, RUG, OPT, ORT, BOT y JUA), se utilizará RegistroMensualBase.

4.5.6 Registros de Juego (JUC).

Los juegos de casino: póquer cash, bingo, slots, ruleta, black Jack, punto y banca, juegos complementarios y loterías presorteadas deben desarrollarse en el marco de una sesión de juego.

Para su reporte se tendrá que generar un fichero de tipo RegistroOtrosJuegos para cada sesión de juego realizada por cada jugador.

Este RegistroOtrosJuegos tendrá la información del jugador, los parámetros de configuración de la sesión y la información agregada por cada uno de los tipos de juego.

Por ejemplo, un jugador a lo largo de un día abre dos sesiones de juego, en la primera juega solo al bingo, en tres partidas de bingo; más tarde abre una segunda sesión en la que juega a dos manos de póquer cash, 5 tiradas de la ruleta y 10 tiradas de slots.

A la finalización de cada sesión deberá reportar un registro de tipo RegistroOtrosJuegos, en el primero habrá un único bloque de juego con el total del resultado de las tres partidas de bingo. El segundo tendrá tres bloques de juego, uno para el resultado agregado de las dos manos de póquer cash, otro para el resultado del juego de ruleta y uno con el resultado agregado de las 10 tiradas de slots.

Esto aplica igualmente para el reporte de las sesiones de juego de loterías presorteadas utilizando en este caso el registro tipo RegistroLoteriaPresorteada.

Los registros que no están englobados en una sesión de juego y se envían individualmente con cada participación del jugador son:

– RegistroPoquerTorneo.

– RegistroApuestaContrapartida.

– RegistroApuestaMutua.

– RegistroConcurso.

– RegistroLoteria.

4.5.6.1 Juegos y Registros.

A continuación, se muestran los registros utilizados para cada uno de los tipos de Juego.

4.5.7 Lote.

Un lote se utiliza para agrupar registros (sería inmanejable tener un fichero para cada registro generado, en el caso de los JUs), pero también para fragmentarlos (en los casos en los que los registros son muy voluminosos, p.ej. RU o CJs).

4.5.8 Periodicidad y fragmentación.

Los lotes se deben generar de acuerdo con las siguientes reglas:

– Información periódica (RU, CJ, OP, JUA, CEV): cada registro irá en un lote (o varios si hay fragmentación del registro en subregistros). Se genera diaria y/o mensualmente, según el tipo de fichero. Se ha de cumplir la siguiente regla: A partir de 10 subregistros, se debe generar un nuevo lote (y sólo se puede generar uno cuando se haya cubierto el cupo de 10 subregistros en el anterior). Por tanto, sólo el último lote correspondiente a un registro (es decir, el que contiene los últimos subregistros) puede contener un número de subregistros menor que 10. Un lote no debe incluir información relativa a registros distintos. En particular, no deben existir rectificaciones de dos registros distintos en un mismo lote.

– Información en tiempo real (JUC): en este caso, un lote contiene información de uno o varios registros, cada uno de los cuales se corresponde con un conjunto de juegos de un mismo tipo durante una sesión, una apuesta, un torneo, un concurso o un sorteo, dependiendo del tipo de juego de que se trate. Se generará un lote cuando transcurran 15 minutos desde que se generó el lote anterior o cuando se alcance la cifra de 500 subregistros en dicho lote (lo que suceda antes).

4.5.9 Tipos de movimiento libres.

El operador debe explicar todos los movimientos que causen variaciones de saldo del jugador. Los tipos de movimiento predefinidos, como «depósitos», «retiradas», «participación» y «premios», no permiten adaptarse a todos los posibles tipos de movimientos que pueden tener impacto en el saldo del jugador.

El elemento «Concepto» del campo «Otros» es libre y permite al operador extender el modelo definiendo sus propios tipos de movimiento cuando no existe una correspondencia con uno de los tipos de movimiento predefinidos.

En cualquier caso, el operador debe utilizar preferentemente el elemento predefinido si está disponible.

La Dirección General de Ordenación del Juego se reserva la posibilidad de definir algún otro concepto de uso obligatorio.

4.5.10 Desgloses que se repiten varias veces.

Se crean varios tipos de datos que representan desgloses para facilitar el mantenimiento del modelo.

DesgloseOperador.

Importe total y desglose por operador.

DesgloseTipoJuego.

Importe total y desglose por tipo de juego.

DesgloseConcepto.

Importe total y desglose por concepto.

DesgloseConceptoOP.

Importe total y desglose por operador y concepto.

DesgloseConceptoBonosT.

Importe total y desglose por concepto de bonos (CONCESION, LIBERACION Y CANCELACION) totalizado.

DesgloseConceptoBonosD.

Importe total y desglose por concepto de bonos (CONCESION, LIBERACION Y CANCELACION) con detalle.

DesgloseBotes.

Importe total y desglose por operador.

DesgloseBotesId.

Importe total y desglose por bote.

DesgloseMedioPagoT.

Importe total y desglose por medio y tipo de pago, totalizada.

DesgloseMedioPagoD.

Importe total y desglose de cada una de las operaciones de depósito o retirada de efectivo desglosada.

4.5.11 Sobre campos económicos vacíos en ficheros.

4.5.11.1 Campos Obligatorios.

Ningún campo obligatorio puede permanecer vacío o sin definición porque se producirá un error de incumplimiento de la gramática. Esto ocurre por ejemplo con los elementos, «Total» en «Depositos» y «Retiradas». Para estos elementos se esperan valores incluso si no hay ingresos (Depósitos) o retiros (Retiradas) porque el XSD los marca como obligatorios. En estos casos se rellenan a 0.

Ejemplo: Forma correcta de Jugador sin depósito.

<Depositos> <Total>0</Total>
</Depositos>

Ejemplo: Formas Incorrectas de Jugador sin depósito.

<Depositos> <Total></Total>
</Depositos>

<Depositos> <Total/>
</Depositos>

<Depositos>
</Depositos>

4.5.11.2 Campos Opcionales.

Para otros elementos, donde la definición del xsd permite 0 ocurrencias, los campos pueden quedar sin definición (vacías) o rellenas a 0.

«Línea» en Participación sería un ejemplo de este tipo de campo. Para un jugador sin participación (0 euros de participación) cualquiera de las siguientes opciones es correcta:

<Participacion> <Total/>
</Participacion>

<Participacion> <Total> <Linea> <Cantidad>0.00</Cantidad> <Unidad>EUR</Unidad> </Linea> </Total> <Desglose> <OperadorId>1234</OperadorId> <TipoJuego>POC</TipoJuego> <Importe> <Linea> <Cantidad>0.00</Cantidad> <Unidad>EUR</Unidad> </Linea> </Importe> </Desglose> <Desglose> <OperadorId>1234</OperadorId> <TipoJuego>BNG</TipoJuego> <Importe> <Linea> <Cantidad>0.00</Cantidad> <Unidad>EUR</Unidad> </Linea> </Importe> </Desglose>
</Participación> 

<Participacion> <Total></Total>
</Participacion>