La Ley 13/2011, de 27 de mayo, de regulación del juego, establece el marco regulatorio de la actividad de juego en el ámbito de aplicación estatal en sus distintas modalidades, con el fin de garantizar la protección del orden público, luchar contra el fraude, prevenir las conductas adictivas, proteger los derechos de los menores y salvaguardar los derechos de los participantes en los juegos.
El establecimiento de los requisitos técnicos de las actividades de juego de la referida Ley 13/2011, de 27 de mayo, ha sido desarrollado en el Real Decreto 1613/2011, de 14 de noviembre, que, interpretado de acuerdo con la disposición adicional décima de la Ley 3/2013, de 4 de junio, de creación de la Comisión Nacional de los Mercados y Competencia, atribuye en la disposición final primera a la Dirección General de Ordenación del Juego, la competencia para dictar aquellas disposiciones que sean precisas para el desarrollo y ejecución de dicha norma.
Así, dando cumplimiento al mandato reglamentario se adoptaron las siguientes resoluciones: Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del juego, por la que se aprueba el modelo de datos del sistema de monitorización de la información; Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego; y Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación.
Desde su adopción se han sucedido diversas novedades normativas que obligan ahora a, por una parte, adoptar un nuevo modelo de datos del sistema de monitorización de la información y, por otra, a modificar los anexos de las resoluciones relativas a los requisitos técnicos y a la identificación y prohibiciones subjetivas a la participación en las actividades de juego. Esas novedades normativas se concretan en la aprobación del Real Decreto 958/2020, de 3 de noviembre, de comunicaciones comerciales de las actividades de juego, y del Real Decreto 176/2023, de 14 de marzo, por el que se desarrollan entornos más seguros de juego, las cuales han supuesto la imposición de una serie de obligaciones a los operadores, susceptibles de ser monitorizadas por la Dirección General de Ordenación del Juego, mediante la introducción de los cambios necesarios en el modelo de datos del sistema de monitorización.
Todo ello unido a la experiencia adquirida a lo largo de los últimos doce años, han motivado esta adopción de un nuevo modelo de datos, con el objeto de dotarlo de una mayor funcionalidad y claridad, así como evitar la comisión de errores, redundancias o un tamaño excesivo del sistema.
Esta nueva versión del modelo de datos introduce cambios significativos derivados de la situación anterior descrita y que se ven reflejados a lo largo de su contenido. Ejemplo de ello es la incorporación de una descripción de la información contenida en el Registro de Usuario detallado (RUD) donde se introduce un campo denominado «perfil especial», siguiendo las definiciones de perfiles de jugadores especiales, en el que se reportarán las fechas de inicio y fin del jugador en el perfil correspondiente (si esta última se conoce), así como la propia clasificación del Perfil del jugador especial, donde se contemplan los siguientes valores: cliente privilegiado; jugador intensivo; participante joven; comportamiento de riesgo u otros, todo ello de conformidad con el Real Decreto 176/2023, de 14 de marzo.
De igual modo, se sustituye la periodicidad diaria de los Registros de Usuario totalizado (RUT) por una periodicidad mensual, y se adapta el modelo a la metodología establecida en el estándar de datos de supervisión aprobado por el Comité Europeo de Normalización.
Idéntica situación se produce en relación con las otras dos resoluciones cuyos anexos precisan ser modificados, pues deben adaptarse a lo dispuesto en determinados preceptos de los reales decretos citados, actualizar la normativa mencionada y homogeneizar los plazos de conservación de la información.
La resolución ha sido sometida al trámite de información pública, se ha recabado informe previo favorable de la Abogacía del Estado del Ministerio de Consumo y ha sido sometida al procedimiento de información en materia de normas y reglamentaciones técnicas y de reglamentos relativos a los servicios de la sociedad de la información previsto en la Directiva (UE) 2015/1535 del Parlamento Europeo y del Consejo, de 9 de septiembre de 2015, por la que se establece un procedimiento de información en materia de reglamentaciones técnicas y de reglas relativas a los servicios de la sociedad de la información.
En su virtud y en el ejercicio de las competencias atribuidas a la Dirección General de Ordenación del Juego, resuelve:
Primero.
Aprobar el Modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego que se acompaña como anexo I.
Segundo.
Aprobar la estructura de ficheros del sistema de monitorización de datos en formato XSD (Definición XML), que se publicará en la sede electrónica de la Dirección General de la Ordenación del Juego.
Tercero.
Modificar el anexo I de la Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego.
El anexo I de la Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego, queda modificado como sigue:
Uno. El apartado 2.1.2 Conservación de copia de los documentos aportados queda redactado como sigue:
Dos. El apartado 2.1.4 Servicios de verificación ofrecidos por la Dirección General de Ordenación del Juego queda redactado como sigue:
Tres. El apartado 2.1.5 Activación del registro de usuario y limitación en la participación queda redactado como sigue:
Cuatro. El apartado 2.1.14 Registro de la configuración de la sesión destinada al juego de máquinas de azar queda redactado como sigue:
Cinco. Se añade un nuevo apartado 2.1.15 Registro de las comunicaciones del servicio de atención al jugador, con la siguiente redacción:
Seis. El apartado 2.3.1 Registro de las operaciones de pago y cobro queda redactado como sigue:
Siete. El apartado 2.4.1 Protección de datos queda redactado como sigue:
Ocho. La letra d) del apartado 4.13 Gestión de cambios queda redactada como sigue:
Nueve. El apartado 5.1.13 Conservación de la información del SCI queda redactado como sigue:
Diez. El apartado 5.1.14 Ubicación del almacén en España queda redactado como sigue:
Once. El apartado 6.1 Registro y trazabilidad queda redactado como sigue:
Cuarto.
Modificar el anexo I de Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación.
El anexo I de la Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación, queda modificado como sigue:
Único. El punto 5 del apartado séptimo. Verificación a través del Sistema de Verificación de Identidad, queda redactado como sigue:
Quinto.
A la entrada en vigor de la presente resolución queda derogada la Resolución de 6 de octubre de 2014, de la Dirección general de Ordenación del Juego, por la que se aprueba el modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego.
Sexto.
La presente resolución entrará en vigor a los nueve meses de su publicación en el «Boletín Oficial del Estado», sin perjuicio de que aquellos operadores que hubieran podido adaptar sus sistemas al modelo de datos aprobado en la misma puedan, de forma facultativa, empezar a utilizarlo en sus relaciones con la DGOJ a partir de los seis meses desde la publicación de esta resolución.
Madrid, 6 de junio de 2024.–El Director General de Ordenación del Juego, Mikel Arana Echezarreta.
ANEXO I
Modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego
Índice
1. Contenido.
2. Definiciones.
3. Modelo de datos funcional.
3.1 Tipos de información.
3.2 Obligación de reporte.
3.2.1 Obligaciones del gestor de liquidez compartida.
3.3 Periodicidad.
3.4 Descripción de la información.
3.4.1 Registro de usuario.
3.4.2 Registro de Cuenta de juego.
3.4.3 Registro de Cuenta del operador.
3.4.4 Registros de Datos de Juego.
3.4.4.1 Registro JUC: juegos.
3.4.5 Registro de Ajustes de Apuestas.
3.4.6 Registro de Catálogo de eventos.
3.4.7 Rectificaciones.
3.4.8 Clasificaciones y normalizaciones.
4. Modelo técnico.
4.1 Estructura de la información.
4.1.1 Registros.
4.1.2 Subregistros.
4.1.3 Lote.
4.1.4 Firma del lote.
4.1.5 Compresión y cifrado del lote.
4.2 Estructura de directorios.
4.3 Empaquetado de los datos de juegos.
4.4 Nomenclatura de archivos.
4.4.1 RU: Registro de Usuario.
4.4.2 CJ: Cuenta de juego.
4.4.3 OP: Cuenta de Operador.
4.4.4 JU: Registro de Juego.
4.4.5 JUA: Ajustes de Apuestas y CEV: Catálogo de Eventos.
4.5 Conceptos generales.
4.5.1 OperadorId.
4.5.2 AlmacenId.
4.5.3 Registro.
4.5.4 Rectificaciones.
4.5.5 Registros periódicos.
4.5.6 Registros de Juego (JUC).
4.5.7 Lote.
4.5.8 Periodicidad y fragmentación.
4.5.9 Tipos de movimiento libres.
4.5.10 Desgloses que se repiten varias veces.
4.5.11 Sobre campos económicos vacíos en ficheros.
1. Anexos.
1.1 Listas y enumerados.
CambioEnDatos: Cambio en datos (RUD).
ConceptoBonos: Concepto bonos (CJD, CJT, CJR).
ConceptoOPT: Ajustes de cuenta del operador (OPT, ORT).
EstadoCNJ: Estado CNJ (RUD, RUR, RUT).
ListaCodigo: Lista de códigos de eventos admitidos (CEV).
MotivoEstado: Motivo por el cual la cuenta del jugador ha sido Suspendida o Cancelada (RUD).
MotivoFinSesion: Motivo por el cual se ha cerrado la sesión (RegistroOtrosJuegos, RegistroLoteriaPresorteada).
PaisISO: Países y territorios según el código ISO de 2 caracteres (RUD, RUG, CEV). (Códigos ISO 3166).
PerfilJugador: Perfil del jugador especial según RD de juego seguro (RUD).
PeriodoLimite: Periodo al que aplica el límite del jugador (RUD).
Sexo: Sexo del jugador (RUD, RUR).
SexoCompeticion: Género a la que pertenece la competición deportiva (CEV).
TipoApuesta: Tipo de apuesta realizada (RegistroApuestaContrapartida, RegistroApuestaMutua).
TipoDispositivo: Tipo de dispositivo del jugador (CJD, RUD, RegistroPoquerTorneo, RegistroApuestaContrapartida, RegistroApuestaMutua, RegistroLoteriaPresorteada).
TipoDocumento: Tipo de documento aportado por el jugador no residente (RUD, RUG).
TipoJuego: Tipo de juego (todos los registros).
TipoLimite: Tipo de limite (RUD).
TipoMedioPago: Lista de códigos de medios de pago admitidos (CJD).
TipoRegistro: Tipos de registro JUC.
TipoResultado: Resultado de la operación de depósito o retirada (CJD).
TipoVerificacionDocumental: Tipo de verificación documental del jugador realizada (RUD).
UnidadLimite: Valores posibles de las unidades de los límites del jugador (RUD).
VariantePoker: Variante de juego de póquer (RegistroPoquerTorneo).
VarianteSesion: Variantes de los juegos de Póquer Cash, Black Jack y Ruleta (RegistroOtrosJuegos).
1.2 Tipos de campos.
Campos de cadena de caracteres.
Campos numéricos.
Campos de tipo fecha.
1. Contenido
El presente anexo contiene el modelo de datos funcional y el modelo técnico del sistema de monitorización de la información correspondiente a los registros de operaciones de juego.
2. Definiciones
Registro de usuario.
Se entiende por registro de usuario el registro único que permite al participante acceder a las actividades de juego de un determinado operador y en la que se recogen, entre otros, los datos que permiten la identificación del participante, los límites del jugador o su estado dentro de la plataforma del operador.
Cuenta de juego.
Se entiende por cuenta de juego a la cuenta o cuentas abiertas por el participante, de forma vinculada a su registro de usuario, en la que se cargan los ingresos de las cantidades económicas destinadas por éste al pago de la participación en las actividades de juego y se abonan los importes de los premios obtenidos por la participación. Incluye tanto la cuenta en euros como el resto de las cuentas de bonos y participaciones gratuitas.
Juego sin registro de usuario previo.
Juegos autorizados por la DGOJ para la participación sin la previa identificación de los participantes.
Operador gestor de registro de usuario.
Operador donde el jugador realiza el registro de usuario.
Operador coorganizador.
Operador que gestiona plataformas de juego en las que sean miembros o se adhieran otros operadores de juego que pongan en común cantidades jugadas por sus respectivos usuarios.
Juego coorganizado en red.
Juego que es gestionado por operadores coorganizadores.
Operador adscrito a una red.
Operador que se adhiere a una red coorganizada a la que aporta las cantidades jugadas por sus usuarios.
Gestor de botes compartidos.
Operador que gestiona las contribuciones y los premios de botes compartidos en red.
Jugadores con actividad.
Número de jugadores que hayan realizado al menos una apuesta en euros durante el periodo.
GGR (Gross Gaming Revenue).
Importe total de las cantidades que se dediquen a la participación en el juego, así como cualquier otro ingreso que el operador pueda obtener, directamente derivado de la organización o celebración de los juegos, deducidos los premios satisfechos por el operador a los participantes. Cuando se trate de apuestas cruzadas o de juegos en los que el operador no obtenga como ingresos propios los importes jugados, sino que, simplemente, efectúen su traslado a los jugadores que los hubieran ganado, estará formado por las comisiones, así como por cualesquiera cantidades obtenidas por servicios relacionados con las actividades de juego, cualquiera que sea su denominación, pagadas por los jugadores al operador.
Botes.
Cantidades jugadas por los jugadores e incorporadas a botes de máquinas de azar, premios adicionales del bingo, fondos de juego no repartido por ausencia de ganadores de una categoría en las apuestas mutuas, y en general todos los fondos de juego que se hubieran dotado o constituido en una partida o juego y que vayan a ser repartidos o aplicados en una partida o juego distinto.
Bonos.
Actividades de promoción o promociones: bonos, bonificaciones, descuentos, regalos de apuestas o partidas, multiplicadores de cuotas o premios, ofertas o cualquier otro mecanismo similar, gratuito o sujeto a condiciones, destinado a promover de forma efectiva la participación en el juego, o la fidelización de clientes. Quedan excluidos de las actividades de promoción los mecanismos de distribución del fondo para premios acumulados en un determinado juego.
Partidas vivas.
Las partidas o juegos cuya comercialización se ha iniciado pero que, en el momento de generar la información contable, no han concluido y que por tanto no se conoce el participante o participantes ganadores.
Tipos Medio de pago.
Clasificación de los diferentes medios de pago usados por el operador en las transacciones económicas con los participantes.
Medio de pago.
Nombre del proveedor de servicios de pago o del medio de pago concreto.
Sesión de usuario.
Período de tiempo que un usuario permanece conectado al sitio web del operador, y que comprende desde la autenticación valida del usuario en el sistema hasta la desconexión del mismo.
Sesión de juego.
Sesión de juego bajo la licencia general de «Otros juegos»: Conjunto de partidas, manos o tiradas jugadas por un participante en cualquiera de los juegos ofertados por un operador bajo la licencia general de «Otros juegos», durante un periodo de tiempo delimitado. El establecimiento de la sesión de juegos aplica a los siguientes juegos: póquer cash, bingo, máquinas de azar, blackjack, ruleta, juegos complementarios y punto y banca.
Sesión de juego de lotería instantánea o presorteada: Conjunto de billetes, boletos o cualquier otra forma de participación adquirida por un jugador en esta modalidad de juego durante un periodo de tiempo delimitado.
Activación del Registro de Usuario.
La activación del Registro de Usuario es el proceso a través del cual el operador habilita al usuario para poder participar en el juego, toda vez, que se han realizado las verificaciones establecidas por la normativa de juego.
Juego ofertado en un entorno de liquidez internacional.
Aquel en el que las cantidades económicas que se dedican a la participación en el juego provienen de jugadores con registro de usuario español y de jugadores sin registro de usuario español.
Gestor de liquidez internacional.
El operador que gestiona un juego ofertado en un entorno de liquidez internacional.
Jugador con registro de usuario español.
Aquel que participa en el juego mediante una cuenta abierta en un operador de juego, de acuerdo con la Ley 13/2011, de 27 de mayo, de regulación del juego.
3. Modelo de datos funcional
3.1 Tipos de información.
Atendiendo a su naturaleza, la información que debe ser recogida en el Almacén del Sistema de Control Interno del operador (SCI) se clasificará en las siguientes categorías:
1. Registro de usuario.
El Registro de Usuario recoge los datos de identificación de los participantes, los relativos a los límites de depósitos y otros datos de configuración tales como el estado del participante en la plataforma de juego.
Se definen los siguientes tipos de archivo para el registro de usuario:
1. El Registro de Usuario detallado (RUD) que deberán reportar los operadores que tienen relación directa con los participantes y gestionan los contratos de juego.
2. El Registro de Usuario de los operadores de red (RUR) que deberán reportar los operadores coorganizadores que gestionen una red de juego.
3. El registro de usuario ganadores en juegos con participación sin registro de usuario previo (RUG), recoge los datos relativos a los participantes premiados en los juegos autorizados para la participación sin registro de usuario previo.
4. El Registro de Usuario totalizado (RUT), como registro de control de la integridad de los datos.
2. Cuenta de juego de los participantes.
El registro Cuenta de Juego incluye, para cada periodo y participante, el saldo inicial, las transacciones realizadas por depósitos o retiradas, los bonos que se le hayan reconocido, las participaciones en los juegos, los premios obtenidos y cualquier otro movimiento realizado en la cuenta, así como el saldo final. La cuenta de juego es un reflejo de la información que el propio participante puede obtener cuando accede a su cuenta de juego en la plataforma de juego.
Se definen los siguientes tipos de archivo para la cuenta de juego:
1. La cuenta de juego detallada (CJD) con los detalles de las cuentas de juego de cada jugador.
2. Los totales de la cuenta de juego (CJT) como registro de control de integridad de los datos.
3. Cuenta de operador.
La Cuenta de Operador es un reflejo de la cuenta de ingresos por juego del operador. Deberá permitir el cálculo de los ingresos brutos (GGR, gross gaming revenue) del operador y, en los casos de redes de operadores, la distribución entre los participantes de la red de los ingresos por juego generados para cada uno de los juegos ofertados por el operador.
Se definen dos tipos de archivo para la cuenta de operador:
1. La cuenta de operador completa (OPT), para aquellos operadores que gestionen el registro de usuario o sean operadores adscritos a una red.
2. La cuenta de operador coorganizador (ORT) para aquellos operadores que gestionen la plataforma de juego en una red coorganizada.
4. Cuenta de botes y partidas vivas.
La Cuenta de Botes recoge la información correspondiente a cantidades, jugadas por los participantes, incorporadas a botes de máquinas de azar, premios adicionales del bingo, fondos de juego no repartidos por ausencia de ganadores de una categoría en las apuestas mutuas, y en general todos los fondos de juego que se hubieran dotado o constituido en una partida o juego y que vayan a ser repartidos o aplicados en una partida o juego distinto.
La Cuenta de Partidas Vivas es un reflejo del saldo del fondo de juego correspondiente a las partidas que al final del periodo considerado no han concluido por lo que no se conoce el participante o participantes ganadores.
La información de la cuenta de botes y de la cuenta de partidas vivas es remitida a través del archivo BOT.
5. Registro de juego.
El Registro de Juego recoge los datos de detalle de los juegos, con información específica de cada tipo de juego.
El registro de juego deberá ser reportado por los operadores que gestionen el registro de usuario.
El tipo de archivo registro de juego (JUC) contiene los datos del juego y de los jugadores implicados, así como sus participaciones, premios y botes.
6. Ajustes de Apuestas.
Los Ajustes de Apuestas (JUA) recogen los datos normalizados de aquellas modificaciones realizadas sobre premios de apuestas –por anulación de la apuesta, modificación de cuota, o por cualquier otra circunstancia– que son efectuadas con posterioridad al momento en que se ha reportado la existencia del premio.
7. Catálogo de Eventos.
El Catálogo de Eventos (CEV) incluye los datos normalizados de los eventos deportivos que componen la oferta de apuestas del operador. Recogerá todos los eventos sobre los que el operador ha comercializado apuestas en el periodo.
3.2 Obligación de reporte.
La obligación de los operadores de reportar los tipos de información descritos en el apartado anterior se recoge en el siguiente cuadro:
Cuando un operador gestiona el registro de usuario tiene obligación de reportar el registro de usuario total y detallado, la cuenta de juego de los participantes total y detallada, la cuenta de operador, la cuenta de botes y partidas vidas, los registros de juego para dichos juegos y, en su caso, ajustes de apuestas y catálogo de eventos.
Cuando se trata de un juego coorganizado en red el operador adscrito a la red de juego no tiene obligación de reportar la cuenta de botes y partidas vidas, ni los registros de juego para dicho juego, salvo en los juegos que formen parte de la sesión de otros juegos (ej. póquer cash). Sí tiene obligación de reportar el registro de usuario total y detallado, la cuenta de juego y la cuenta de operador.
El operador coorganizador tiene obligación de reportar el registro de usuario de red, la cuenta de operador coorganizador de red, la cuenta de botes y partidas vidas y los registros de juego.
El operador gestor de botes compartidos solo tiene que reportar la cuenta de botes.
En el caso de juegos sin registro de usuario previo, el operador deberá reportar el registro de ganadores, la cuenta del operador, los registros de juego y en su caso, la cuenta de botes y partidas vivas.
3.2.1 Obligaciones del gestor de liquidez compartida.
El gestor de liquidez internacional solo deberá informar de los juegos en los que participe, al menos, un jugador con registro de usuario español.
En los ficheros RUR/RUT, BOT, JUC solo se incluirán datos de jugadores con registro de usuario español. En el fichero ORT, se remitirá la información económica correspondiente a los juegos con liquidez internacional desglosada por operador (B2C) del dominio «.es» y por jurisdicción para los jugadores no pertenecientes al dominio «.es» que participen en el juego.
3.3 Periodicidad.
La periodicidad del reporte de la información para cada tipo de registro se indica en la siguiente tabla:
El envío al almacén de los registros de periodicidad diaria debe producirse antes de las 4 a.m. del día siguiente al día sobre el que se está informando.
El envío al almacén de los registros de periodicidad mensual debe producirse antes de las 23:59 del primer día del mes siguiente.
3.4 Descripción de la información.
En los siguientes apartados se detalla la información contenida en los registros.
3.4.1 Registro de usuario.
3.4.1.1 Registro RUD: Registro de usuario detallado.
Información en el registro de usuario detallado.
El registro de usuario detallado recoge los datos de identificación de los participantes, los relativos a los límites de depósitos y otros datos de configuración tales como el estado del participante en la plataforma de juego.
Operadores obligados.
El registro de usuario detallado debe ser reportado por los operadores que tienen relación directa con los participantes y gestionan los contratos de juego.
Los operadores que comercialicen juegos con participación sin registro de usuario previo no deberán incluir en el tipo de información «registro de usuario detallado» la relativa a los ganadores ni a ningún otro participante.
Periodicidad de la información.
Diaria: El registro de usuario diario sólo contendrá los datos de los participantes nuevos o con alguna modificación en sus datos de registro de usuario (incluyendo límites, estado, perfil y exclusiones) durante el periodo.
Mensual: El registro de usuario mensual contendrá los datos de todos los participantes existentes en la plataforma de juego, independientemente de si han experimentado o no modificaciones en sus datos durante el periodo, o de si su estado es activo o no.
Descripción de la información contenida en el registro de usuario detallado:
Controles Principales.
– El número de identificación fiscal (NIF) o el número de identificación de extranjeros (NIE) debe tener un formato válido. Ver epígrafe «Formato válido del NIF y del NIE».
– No se considerarán válidos aquellos registros de usuario que se declaren no residentes y simultáneamente indiquen España como su país de residencia.
– Los límites del jugador se contrastarán con los reportados en el resto de los registros.
– Los jugadores autoexcluidos no podrán tener participación, ni depósitos en los juegos correspondientes en el periodo definido.
3.4.1.2 Registro RUT: Registro de usuario totalizado.
Información en el registro de usuario totalizado.
El registro de usuario totalizado contiene el número de jugadores, altas, bajas, jugadores activos por periodo, así como los estados de los mismos.
Operadores obligados.
El registro de usuario totalizado debe ser reportado por los operadores que tienen relación directa con los participantes y gestionan los contratos de juego.
También debe ser reportado por los operadores coorganizadores que gestionen una red de juego.
Los operadores que comercialicen juegos con participación sin registro previo de usuario no deberán contar a los participantes de dichos juegos en el tipo de información «registro de usuario totalizado». En el caso de que el operador comercialice únicamente juegos con participación sin registro previo de usuario, no deberá transmitir el tipo de información «registro de usuario totalizado».
Periodicidad de la información.
Mensual: El registro contendrá el total de los participantes existentes en la plataforma de juego, independientemente de si han experimentado o no modificaciones en sus datos durante el periodo, o de si su estado es activo o no.
Contenido del registro.
Controles principales.
– La suma de todos los jugadores agrupados por estados debe ser igual al número total de jugadores.
– La suma de los jugadores del Registro de Usuario Detallado (RUD) mensual debe coincidir con el número de jugadores reportados en el Registro de Usuario Totalizada (RUT).
– La suma de los jugadores del Registro de Usuario de los operadores de Red (RUR) debe coincidir con el número de jugadores reportados en el Registro de Usuario Totalizada (RUT).
3.4.1.3 Registro RUR: Registro de usuario en la red.
Información en el registro de usuario en la red.
El registro de usuario en la red recoge los datos de identificación de los participantes en la red coorganizada, estos datos se corresponderán con el identificador del operador en el cual está registrado el jugador y su identificador en dicho operador, además debe incluir el estado del participante en la plataforma de juego (activo, suspendido, bloqueado, …).
El registro de usuario en la red contendrá todos los datos de los participantes dados de alta en la plataforma de juego, independientemente de si han experimentado o no modificaciones en sus datos durante el periodo, o de si su estado es activo o no.
Operadores obligados.
El registro de usuario en la red debe ser reportado por los operadores coorganizadores que gestionen una red de juego.
Periodicidad de la información.
Mensual: contendrá los datos de todos los participantes dados de alta en la plataforma de juego coorganizada independientemente del estado del jugador.
Contenido del registro.
Controles Principales.
– Correspondencia con los usuarios de los operadores clientes de la red: Los identificadores de jugadores que participan en juegos en red deberán coincidir con los identificadores adicionales indicados por el operador cliente en su registro de usuario detallado (RUD).
3.4.1.4 RegistroRUG: Registro de Usuarios Ganadores.
Información del registro de ganadores en juegos sin registro de usuario previo.
El registro de usuarios ganadores recoge los datos de identificación de los participantes que han obtenido uno o varios premios en juegos sin registro de usuario previo.
Operadores obligados.
Deberán presentar este registro de usuarios los operadores autorizados a comercializar juegos con participación sin registro previo de usuario.
Periodicidad.
Mensual. Contendrá todos los usuarios que han obtenido premios durante el periodo.
Contenido del registro.
En cada periodo, se incluirá la información correspondiente a los usuarios ganadores por premios reconocidos en el periodo.
Descripción de la información contenida en el registro. Los campos empleados tienen el mismo significado que en el RUD. Además, tienen los siguientes campos particulares que se usarán para los ganadores de premios de loterías sujetos a verificación de identidad por la normativa de prevención de blanqueo de capitales:
3.4.2 Registro de Cuenta de juego.
3.4.2.1 Registro CJD: Cuenta de juego detallada.
Información en la cuenta de juego detallada.
La cuenta de juego es un reflejo de la información que el propio participante puede obtener cuando accede a su cuenta de juego en la plataforma de juego. Incluye, para cada periodo y participante, los totales correspondientes al saldo inicial, las transacciones realizadas por depósitos o retiradas, los bonos que se le hayan reconocido, las participaciones en los juegos, los premios obtenidos y cualquier otro movimiento realizado en la cuenta, así como el saldo final en cada periodo.
En la cuenta de juego se incluirán todos los movimientos realizados, tanto si se contabilizan en unidades monetarias como los contabilizados en cualquier otra unidad como puntos, u otros, indicándose en cada caso la unidad de medida utilizada. Los valores monetarios deberán ser expresados en euros.
Puesto que la cuenta de juego es un reflejo de la información que el propio participante puede obtener cuando accede a su registro de usuario y cuenta de juego, los movimientos que supongan un incremento del saldo del jugador como depósitos realizados, bonos reconocidos o premios, se registrarán con signo positivo. Todos los movimientos que supongan una disminución del saldo del jugador como participaciones en los juegos o retiradas de fondos se registrarán con signo negativo.
Operadores obligados.
La cuenta de juego deberá ser reportada por todos los operadores que gestionan registros de usuario.
Los jugadores se identificarán mediante el identificador único de jugador asociado a éste en el proceso de registro en la plataforma.
Se reportarán todos los conceptos económicos de la cuenta de juego, con independencia de que el operador esté adscrito o no a una red.
Los operadores que comercialicen juegos con participación sin registro previo de usuario no deberán incluir en el tipo de información «cuenta de juego» la relativa a los ganadores ni a ningún otro participante en dichos juegos. En el caso de que el operador comercialice únicamente juegos con participación sin registro previo de usuario, no deberá transmitir el tipo de información «cuenta de juego».
Periodicidad.
– Diaria. Diariamente se incluirá la información de las cuentas de juego que hayan presentado algún tipo de movimiento durante el día.
– Mensual. Mensualmente se incluirá la información de todas las cuentas de juego registradas en la plataforma del operador.
Contenido del registro.
Para cada uno de los participantes con cuenta de juego en la plataforma se incluirá la siguiente información:
Controles Principales.
– En todo momento, el saldo en la cuenta de juego para cada uno de los participantes reportado ha de ser igual al saldo que el propio participante puede obtener cuando accede a su registro de usuario y cuenta de juego.
– El saldo inicial en cada periodo considerado para cada uno de los participantes debe coincidir con el saldo final del periodo inmediatamente anterior para cada una de las unidades.
– Dentro de cada periodo el saldo final debe coincidir con el saldo inicial más los movimientos ocurridos durante el periodo para cada una de las unidades reportadas, sin considerar los importes incluidos en el registro Comisiones, Premios en Especie y Regalos que tienen carácter informativo.
– Para cada participante deberán incluirse todos los movimientos realizados en el periodo de forma que quede explicado el saldo final a partir del saldo inicial y los movimientos del periodo en cada una de las unidades. Cualquier movimiento que modifique el saldo de la cuenta de juego y no se corresponda con depósitos, retiradas, participación, devolución de la participación, premios, premios en especie, ajustes o anulaciones en los premios, bonos o transferencias entre monederos, se incluirán en el apartado «Otros», donde se deberá utilizar el campo «concepto» para desglosar la tipología de «Otros» movimientos, siempre con un nivel de detalle equivalente al de la contabilidad del operador.
– En el campo «Otros» no deben reportarse movimientos que pertenezcan a una categoría definida en el modelo, especialmente las cancelaciones o anulaciones de depósitos y retiradas deben ser reportadas en su categoría correspondiente.
– El Total y el Desglose deben coincidir en todos los casos.
3.4.2.2 Registro CJT: Cuenta de juego totalizada.
Información en totales de la cuenta de juego.
El registro CJT contiene la información agregada de las cuentas de juego de los jugadores.
El registro de totales de la cuenta de juego es un registro de control que permite comprobar que los datos de la cuenta de juego se han registrado de forma completa y correcta.
Operadores obligados.
El registro de totales de la cuenta de juego deberá ser reportado junto al registro de cuenta de juego detallada.
Periodicidad.
– Diaria. Diariamente se incluirá la información de las cuentas de juego que hayan presentado algún tipo de movimiento durante el día. Debe ser congruente con la cuenta de juego detallada correspondiente al mismo día.
– Mensual. Mensualmente se incluirá la información de todas las cuentas de juego registradas en la plataforma del operador.
Contenido del registro.
La definición de los campos se corresponde exactamente con la proporcionada en el punto anterior, correspondiente al registro CJD, con las siguientes excepciones:
– No hay identificador del jugador ni de la cuenta dado que son datos agregados.
– El desglose de los Depósitos y Retiradas solo tiene los campos: MedioPago, TipoMedioPago e Importe.
– Los campos Trans_IN y Trans_OUT no tienen desglose.
– Bonos solo se desglosa por Concepto (CONCESION, LIBERACION y CANCELACION).
– Premios en especie desglosa solo por tipo de juego.
– No se reporta el campo Regalos.
Controles Principales.
– En los registros mensuales, el saldo inicial debe coincidir con el saldo final del mes inmediatamente anterior.
– Dentro de cada periodo el saldo final debe coincidir con el saldo inicial más los movimientos ocurridos durante el periodo para cada una de las unidades reportadas, sin considerar los importes incluidos en los campos Comisiones, Premios en especie y Regalos.
– Para cada uno de los conceptos, el importe incluido en el registro Cuenta de Juego Totalizada deberá ser igual a la suma de los importes detallados por participante en la Cuenta de Juego Detallada.
3.4.3 Registro de Cuenta del operador.
3.4.3.1 Registro OPT: Cuenta de operador completa.
Información en la cuenta de operador completa.
La cuenta del operador es un reflejo de la cuenta de ingresos por juego del operador. Deberá permitir el cálculo de los ingresos brutos (GGR, gross gaming revenue) del operador.
Con carácter general el desglose de operador atenderá a la siguiente diferenciación:
– En el caso del operador adscrito a la red no se precisa desglose ya que sólo tendrán que incluir el detalle de los ingresos procedentes de la red y el cálculo de los ingresos brutos (GGR).
– En el caso del operador que gestiona completamente el juego se indicará el propio código de operador que gestiona el juego.
Operadores obligados.
La cuenta de operador deberá ser reportada por los operadores que gestionen los juegos o por los operadores adscritos a una red, en cuyo caso sólo tendrán que incluir el detalle de los ingresos procedentes de la red y el cálculo de los ingresos brutos (GGR).
La cuenta de operador se organiza por tipo de juego. Los juegos sin registro previo también deberán ser incluidos en la cuenta de operador.
Periodicidad.
Mensual. Se incluirá la información registrada en la plataforma del operador durante el periodo.
Contenido del registro.
Descripción de la información contenida en el registro:
Controles Principales.
– Cálculo de la Ganancia Bruta del Operador (GGR).
– Correspondencia entre los ingresos procedentes de la red reportados por el operador adscrito a la red y los reportados por el operador de red.
– Cuando el operador gestiona el juego de forma completa en el desglose de operador indicará su propio código de operador.
– El Total y el Desglose de todos los movimientos reportados deben coincidir en todos los casos.
3.4.3.2 Registro ORT: Cuenta del operador de red.
Información en la cuenta de operador coorganizador.
La cuenta del operador es un reflejo de la cuenta de ingresos por juego generados en un juego gestionado en red. Deberá permitir el cálculo de los ingresos brutos (GGR, gross gaming revenue) del juego coorganizado y su distribución entre los operadores adscritos a la red de operadores.
En el desglose de operador se repartirán las cantidades por los operadores que proporcionan los clientes a la red de juego.
Operadores obligados.
La cuenta de operador deberá ser reportada por los operadores coorganizadores por cada uno de los tipos de juego que gestionan.
Juegos ofertados en un entorno de liquidez internacional.
En los juegos ofertados en un entorno de liquidez internacional en los que participe al menos un jugador con registro de usuario español, deberán reportarse:
– Por las operaciones de operadores de la jurisdicción española, los datos agregados por operador.
– Por las operaciones de operadores de otras jurisdicciones, los datos agregados por jurisdicción. Por ejemplo, en el caso de Francia se reportará OperadorId=FR, IT para Italia y PT para Portugal.
Periodicidad.
Mensual. Se incluirá la información registrada en la plataforma del operador durante el periodo.
Contenido del registro.
La estructura y contenido es igual que la del registro OPT, teniendo en cuenta que los apuntes vendrán desglosados por operador que ha aportado los participantes a la red. En la Ganancia Bruta del Operador (GGR) se reflejará el GGR total de la red y en los Ajustes de Red el desglose por cada uno de los operadores que aportan jugadores.
En el caso de juegos ofertados en un entorno de liquidez internacional, el gestor de liquidez internacional deberá informar de las magnitudes económicas desglosándolas por operador en el caso de los operadores que dispongan de licencia en España, y por un agregado por jurisdicción para el resto de los operadores.
3.4.3.3 Registro BOT: Botes y partidas vivas.
Información en la cuenta de botes y partidas vivas.
La cuenta de botes y partidas vivas es un reflejo de los importes de las participaciones en los juegos que, al final del periodo considerado, todavía no se han repartido en premios, bien porque se han incorporado a botes, bien porque las partidas no han finalizado.
Operadores obligados.
La cuenta de botes y partidas vivas debe comunicarla todo operador que gestione el desarrollo del juego, ya sea de manera completa o gestionando la red. Los operadores adscritos a una red que no gestionen el juego no deben informarla.
La cuenta de botes deberá ser reportada por los operadores que gestionen los fondos para botes directamente. En los casos de juegos en red será el operador coorganizador quien presentará la información correspondiente a botes.
En la cuenta de Botes se incluirán todos los botes activos en el periodo. Un bote está activo desde el momento en que los participantes pueden contribuir al mismo, hasta que se cierra, normalmente por el reparto de todos los premios asociados o, en su caso, por el redireccionamiento a otro bote. Por tanto, en la cuenta de botes se incluirán todos los botes que se hayan comercializado durante el periodo, independientemente de que su comercialización se hubiera iniciado en un periodo anterior, o de que hayan finalizado durante el periodo considerado.
Los botes se identificarán de forma individualizada.
La cuenta de partidas vivas será reportada por los operadores que gestionen juegos de Apuestas, Torneos de póquer y Concursos. En los casos de juegos en red será el operador coorganizador quien presentará la información correspondiente a partidas vivas.
El operador podrá solicitar a la DGOJ la no inclusión en el registro de otros juegos en los que las partidas tengan una duración inferior a un día, contada desde el momento en que se inicia la comercialización hasta el momento en que se reconocen los premios.
Dada la dinámica de los juegos de Póquer cash, Ruleta, Blackjack, Punto y banca, Bingo, Máquinas de azar y Juegos complementarios, la información de partidas vivas no ha de ser reportada. La Dirección General de Ordenación del Juego podrá requerir al operador para que se incluya la información de partidas vivas en los casos en que su volumen sea significativo.
Periodicidad.
La periodicidad de generación del registro será mensual.
Contenido del registro.
La información que se recoge en el registro de botes y partidas vivas es la siguiente:
Controles Principales.
– El saldo inicial más el importe total de los movimientos deben coincidir con el saldo final tanto para Botes como Partidas Vivas.
– Las cantidades indicadas como aplicaciones de botes por reparto de premios tendrán su reflejo en los importes de premios reportados por el operador en la cuenta del operador.
– El saldo inicial de los Botes y las Partidas Vivas debe ser el mismo que el saldo final de dichas variables en el fichero BOT del mes anterior.
3.4.4 Registros de Datos de Juego.
3.4.4.1 Registro JUC: juegos.
Información en registros de juegos.
Los registros de juegos contendrán información a nivel de sesión, torneo, apuesta, concurso o sorteo:
– Póquer cash, bingo, máquinas de azar, ruleta, blackjack, punto y banca, juegos complementarios y loterías presorteadas: cada sesión de juego.
– Póquer torneo: cada torneo.
– Apuestas: cada combinación de deportes, competiciones, eventos y hechos sobre lo que se apuesta.
– Concursos: cada concurso.
– Loterías: cada sorteo.
Dado que cada juego tiene sus características particulares, se han definido distintos tipos de registros de juego, estos son:
– RegistroOtrosJuegos: para juegos de casinos, se incluyen los tipos de juego: POC, BNG, AZA, PUN, RLT, BLJ y COM.
– RegistroPoquerTorneo: para el tipo de juego POT.
– RegistroApuestaContrapartida: se incluirán todos los juegos de apuestas de contrapartida: ADC, AHC y AOC.
– RegistroApuestaMutua: incluye los juegos de apuestas mutuos y los de cruzadas: ADM, AHM, ADX y AOX.
– RegistroConcurso: para los juegos COC.
– RegistroLoteria: para todos los juegos de loterías.
– RegistroLoteriaPresorteada: para las sesiones de juego de lotería instantánea o presorteada.
Operadores obligados.
Los registros de juegos deben ser transmitirlos por los operadores que gestionen el desarrollo del juego, ya sea de manera completa o gestionando una red coorganizada. No debe ser trasmitida por los operadores que únicamente gestionen jugadores.
Periodicidad.
Los datos de los registros de juegos se deben generar en tiempo real en el sistema del operador de forma que recoja la información del evento tal y como se produce en el sistema.
Los eventos serán:
– Póquer cash, bingo, máquinas de azar, ruleta, blackjack, punto y banca, juegos complementarios, loterías presorteadas: cuando finalice la sesión.
– Póquer torneo: cuando finalice el torneo.
– Apuestas: el momento en que se conoce el resultado de los hechos sobre los que se apuesta.
– Concursos: cuando finalice cada concurso.
– Loterías: cuando se conozca el conjunto de ganadores.
La periodicidad del envío de los registros de juegos al almacén está definida en el apartado «Periodicidad y fragmentación».
Las correcciones o ajustes en los juegos realizados con posterioridad a su envío al almacén se reportarán como rectificaciones, sin que, en ningún caso, se pueda borrar la transacción original corregida o ajustada. Esto se hará para todos los juegos donde se produzca estas circunstancias a excepción de las apuestas, cuyas correcciones y ajustes deberán ser informadas de forma individual en el registro denominado Ajuste de Apuestas. Este registro deberá recoger cualquier corrección o ajuste de las apuestas ya realizadas indicando las cuantías y los motivos.
Cuando la variación de los registros de los juegos se debe a causas diferentes al funcionamiento normal de los juegos, como a errores en la generación del reporte u otros errores de carácter técnico la trasmisión de los datos correctos se realizará mediante la rectificación de los datos (ver epígrafe «Rectificaciones»).
La información de todos los tipos de juego está compuesta por una información del juego y por una información del jugador o jugadores. Los registros RegistroOtrosJuegos, RegistroApuestaContrapartida y RegistroLoteriaPresorteada tienen información de un único jugador, el resto de los registros están preparados para reportar entre 1 y muchos jugadores.
Datos del juego.
Se definen 7 tipos distintos de registros JUC, dependiendo del tipo de juego y de si son juegos mutuos o de contrapartida. Todos tienen una mayoría de campos comunes y unos pocos específicos de cada juego. Están compuestos por dos bloques, uno con la información del juego y otra con la del jugador.
Campos comunes del bloque de Juego.
Campos comunes del bloque de Jugador.
Campos específicos del registro Otros Juegos (RegistroOtrosJuegos).
Este registro JUC será el utilizado para reportar la información para cada uno de los juegos de casino (POC, BNG, AZA, BLJ, RLT, PUN y COM) de la sesión, se generará uno por cada sesión de juego.
A diferencia del resto de registros el desglose de los movimientos monetarios (participación, devolución, premios y botes) se reportará en el bloque juego y no en el de jugador ya que se requiere conocer el total de estos movimientos por cada uno de los tipos de juego en los que ha participado el jugador durante la sesión de juego.
Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego:
Y los siguientes campos específicos para el bloque Jugador:
Campos específicos del registro Póquer Torneo (RegistroPokerTorneo).
Este registro JUC será el utilizado para reportar la información para cada uno de los torneos de póquer (POT). Se generará un registro por cada torneo.
Este registro reporta todos los jugadores que participan en el torneo.
Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego:
Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple. Se reportarán todos los jugadores de la jurisdicción española que hayan participado en el torneo de póquer reportado:
Campos específicos del registro Apuestas de Contrapartida (RegistroApuestaContrapartida).
Este registro JUC será el utilizado para reportar la información para cada una de las apuestas realizadas por un jugador de los tipos de apuesta de contrapartida (ADC, AHC, AOC). Se generará un registro por cada apuesta cerrada.
Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego:
Y los siguientes campos específicos para el bloque Jugador:
Campos específicos del registro Apuestas Mutuas (RegistroApuestaMutua).
Este registro JUC será el utilizado para reportar la información para cada una de las apuestas realizadas por varios jugadores de los tipos de apuesta mutuas o cruzadas (ADM, AHM, ADX y AOX), se generará uno por cada apuesta de este tipo cerrada.
Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego:
Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple, se reportarán todos los jugadores que hayan participado en la apuesta reportada:
Campos específicos del registro Concurso (RegistroConcurso).
Este registro JUC será el utilizado para reportar la información para cada uno de los concursos (COC), se generará uno por concurso.
Este registro reporta todos los jugadores que participan en el concurso.
Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego:
Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple, se reportarán todos los jugadores que hayan participado en el concurso reportado:
Campos específicos del registro Loterías (RegistroLoteria).
Este registro JUC será el utilizado para reportar la información para cada uno de los sorteos de loterías (PDM, PHM, PLN, PLP, PEU, PBL, PGP, PLT, PED, PCP, PSO, PTX, PMD, PEJ, PRK, OLN, OLP, OEU, OBL, OGP, OLT, OED, OCP, OSO, OTX, OMD, OEJ, ORK). Se generará uno por sorteo.
Se excluyen de este registro las sesiones de usuario de lotería presorteada o instantánea.
Este registro reporta todos los jugadores que participan en el sorteo para los juegos.
Para los juegos presenciales se reportarán los totales agrupados de todos los jugadores presenciales.
Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego:
Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple, se reportarán todos los jugadores que hayan participado en el sorteo reportado para los juegosy para los juegos presenciales solo se reportará un único bloque Jugador con los valores totales de participación, devolución, premios y botes:
Campos específicos del registro LoteríasPresorteadas (RegistroLoteriaPresorteada).
Este registro JUC será el utilizado para reportar la información para cada una de las sesiones de usuario de juegos de loterías presorteadas o instantáneas. Se generará un registro por sesión.
Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego:
Y los siguientes campos específicos para el bloque Jugador:
3.4.5 Registro de Ajustes de Apuestas.
Información en registros de ajustes de apuestas.
Datos normalizados de los ajustes realizados en apuestas con posterioridad al momento en que se determina la existencia de premios.
El registro de los ajustes de apuestas se denomina RegistroJUA.
Operadores obligados.
El registro de ajuste de apuestas debe transmitirlo todo operador que, en posesión de la licencia singular correspondiente para ofertar apuestas deportivas, hípicas u otras, gestione el desarrollo de alguna de estas apuestas, ya sea de manera completa o gestionando una red coorganizada de apuestas.
Periodicidad.
Mensual. En el caso de que no haya ningún ajuste durante el periodo el registro se generará igualmente con contenido vacío.
Datos del registro.
La información se desglosa para cada ajuste:
Controles principales.
– El EventoID declarado debe encontrarse definido en el registro del catálogo de eventos.
– El TicketApuesta debe haber sido reportado en algún registro de juego de apuestas (RegistroApuestaContrapartida o RegistroApuestaMutua).
3.4.6 Registro de Catálogo de eventos.
Información en catálogo de eventos.
Datos normalizados de los eventos que componen la oferta de apuestas del operador. Recogerá todos los nuevos eventos o actualizaciones sobre eventos reportados previamente sobre los que el operador ha comercializado apuestas en el periodo, independientemente de que dichos eventos hayan finalizado o no.
El registro de catálogo de Eventos se denomina RegistroCEV.
Operadores obligados.
Los operadores que comercializan apuestas.
Periodicidad.
– Diaria. Diariamente se incluirá la información de los eventos nuevos o que hayan sido modificados en el día.
– Mensual. Mensualmente se incluirá la información de todos los eventos reportados durante el mes, tanto las altas como las modificaciones. En el caso de haber varias modificaciones en el mes para el mismo evento, se reportará la información de la última actualización.
Datos del catálogo.
La descripción del registro que notifica los eventos sobre los que se realizan apuestas se detalla a continuación:
Controles principales.
Todos los eventos reportados en las apuestas mediante un identificador de evento deberán estar recogidos en el catálogo correspondiente. No debe haber eventos duplicados, en caso de reportar un duplicado se entiende que es una actualización de los datos de un evento previo y por tanto debe ser señalizado con el campo Actualizado=«S» o será considerado erróneo.
3.4.7 Rectificaciones.
Cuando un operador transmita datos erróneos, deberá corregir los datos transmitidos erróneamente. En lo sucesivo, en la presente Disposición se denominará «rectificación» a la corrección de errores.
La rectificación en ningún caso debe permitir o implicar el borrado de la información que ya conste en el Almacén, excepto en aquellos casos en que se haya obtenido la aprobación previa y explícita de la Dirección General de Ordenación del Juego.
Para la rectificación de la información se utilizará la declaración de la nueva información, junto con una indicación de la información anterior errónea que debe ser sustituida.
3.4.8 Clasificaciones y normalizaciones.
3.4.8.1 Tipo de Juego.
Los tipos de juego para el modelo de monitorización (sin considerar los juegos de loterías) son los siguientes:
– ADC: Apuestas Deportivas de Contrapartida.
– ADM: Apuestas Deportivas Mutuas.
– ADX: Apuestas Deportivas Cruzadas.
– AHC: Apuestas Hípicas de Contrapartida.
– AHM: Apuestas Hípicas Mutuas.
– AOC: Otras Apuestas de Contrapartida.
– AOX: Otras Apuestas Cruzadas.
– AZA: Máquinas de Azar.
– BLJ: Blackjack.
– BNG: Bingo.
– COC: Concursos.
– COM: Juegos Complementarios.
– POT: Póquer Torneo.
– POC: Póquer Cash.
– PUN: Punto y Banca.
– RLT: Ruleta.
3.4.8.2 Estado del jugador.
El «estado» del jugador está compuesto por los campos:
– EstadoCNJ, en el que se pide al operador diferenciar entre:
• A: Activo. Refleja el estado en el que el jugador se encuentra debidamente identificado y verificado documentalmente.
• PV: Pendiente de verificación documental. Refleja el estado de un jugador residente, cuya identificación no ha sido cotejada fehacientemente mediante un sistema de verificación documental.
• S: Suspendido. Refleja el estado del jugador que el operador ha optado por suspender. En este caso, el operador debe reportar el motivo de la suspensión en el campo MotivoEstado entre uno de los valores de la lista.
• C: Cancelado. Refleja el estado del jugador que ha sido cancelado. En este caso, el operador debe reportar el motivo de la cancelación en el campo MotivoEstado entre uno de los valores de la lista.
• CD: Cancelado por defunción. Jugador que ha fallecido.
• PR: Prohibición subjetiva. Refleja el estado del jugador sujeto a cualquiera de las prohibiciones subjetivas establecidas en el artículo 6 de la Ley 13/2011 (menores, inscritos en el RGIAJ, vinculados,...).
• AE: Autoexcluido. Refleja el estado del jugador que voluntariamente ha decidido autoexcluirse del juego ofertado por el operador.
• O: Otros. Resto de situaciones en que pueda encontrarse un jugador y no estén incluidas en ninguna de las anteriores.
– EstadoOperador, en el que el operador introducirá el nombre del estado tal y como se denomina en su plataforma.
– MotivoEstado, en caso de que el EstadoCNJ sea Suspendido o Cancelado se debe rellenar este campo seleccionando el motivo por el cual la cuenta ha sido suspendida o cancelada. El campo es un enumerado, la lista de valores disponibles se encuentra en el listado correspondiente del anexo 1.
3.4.8.3 Formato válido NIF y NIE.
Para que un formato de NIF y NIE sea válido ha de cumplir las siguientes reglas:
– Se deben rellenar con ceros a la izquierda hasta contemplar el número exacto de dígitos del DNI (8) y NIE (7). Por ejemplo, en el caso del NIF: Número de 8 dígitos seguido de una letra (digito de control). En caso de no ser un número con 8 dígitos, se completará el número con ceros a la izquierda hasta llegar a 8 dígitos.
– En el caso del NIE, debe tenerse en cuenta la siguiente excepción. Cuando se detecte un NIE de 10 dígitos que empiece por X y a continuación haya un 0, debe suprimirse el primer cero tras la X, quedando un NIE formado por 9 caracteres.
Para el cálculo del dígito de control del NIF/NIE podrá consultarse la siguiente página web: http://www.ordenacionjuego.es/es/calculo-digito-control
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:
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.
Ejemplo: Formas Incorrectas de Jugador sin depósito.
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:
1. Anexos
1.1 Listas y enumerados.
CambioEnDatos: Cambio en datos (RUD).
ConceptoBonos: Concepto bonos (CJD, CJT, CJR).
ConceptoOPT: Ajustes de cuenta del operador (OPT, ORT).
EstadoCNJ: Estado CNJ (RUD, RUR, RUT).
ListaCodigo: Lista de códigos de eventos admitidos (CEV).
MotivoEstado: Motivo por el cual la cuenta del jugador ha sido Suspendida o Cancelada (RUD).
MotivoFinSesion: Motivo por el cual se ha cerrado la sesión (RegistroOtrosJuegos, RegistroLoteriaPresorteada).
PaisISO: Países y territorios según el código ISO de 2 caracteres (RUD, RUG, CEV). (Códigos ISO 3166).
PerfilJugador: Perfil del jugador especial según RD de juego seguro (RUD).
PeriodoLimite: Periodo al que aplica el límite del jugador (RUD).
Sexo: Sexo del jugador (RUD, RUR).
SexoCompeticion: Género a la que pertenece la competición deportiva (CEV).
TipoApuesta: Tipo de apuesta realizada (RegistroApuestaContrapartida, RegistroApuestaMutua).
TipoDispositivo: Tipo de dispositivo del jugador (CJD, RUD, RegistroPoquerTorneo, RegistroApuestaContrapartida, RegistroApuestaMutua, RegistroLoteriaPresorteada).
TipoDocumento: Tipo de documento aportado por el jugador no residente (RUD, RUG).
TipoJuego: Tipo de juego (todos los registros).
TipoLimite: Tipo de limite (RUD).
TipoMedioPago: Lista de códigos de medios de pago admitidos (CJD).
TipoRegistro: Tipos de registro JUC.
TipoResultado: Resultado de la operación de depósito o retirada (CJD).
TipoVerificacionDocumental: Tipo de verificación documental del jugador realizada (RUD).
UnidadLimite: Valores posibles de las unidades de los límites del jugador (RUD).
VariantePoker: Variante de juego de póquer (RegistroPoquerTorneo).
VarianteSesion: Variantes de los juegos de Póquer Cash, Black Jack y Ruleta (RegistroOtrosJuegos).
1.2 Tipos de campos.
La experiencia de los años de funcionamiento del modelo de datos de la SCI, en sus versiones 1.x y 2.x nos ha hecho ver la importancia de detallar lo máximo posible el formato, tipo y longitud de los campos del modelo. Por eso en la nueva versión 3.x se han definido una serie de campos de cadena de longitudes fijas para evitar los errores del pasado.
Campos de cadena de caracteres.
Cualquiera de estos campos marca la longitud máxima de la información que contienen, pero no la mínima.
Estos nuevos campos son:
– cadena10. Cadena de caracteres de longitud máxima 10.
– cadena20. Longitud máxima de 20 caracteres.
– cadena50. Longitud máxima de 50 caracteres.
– cadena100. Longitud máxima de 100 caracteres.
– cadena200. Longitud máxima de 200 caracteres.
– cadena1000. Longitud máxima de 1000 caracteres.
Campos numéricos.
Se define un tipo de campo numérico:
– cantidad. Decimal con un máximo de 2 decimales y un total de 12 dígitos de longitud máxima.
– entero3. Número entero de 3 dígitos de longitud máxima.
– entero6. Número entero de 6 dígitos de longitud máxima.
– entero8. Número entero de 8 dígitos de longitud máxima.
Campos de tipo fecha.
Hay varios campos de tipo Fecha definidos en el modelo, estos son:
– date-aaaamm: Año y mes. Por ejemplo: 202301.
– date-hhmmss: Hora, minutos y segundos. Por ejemplo: 081125.
– Date-ddhhmm: Días, horas y minutos. Por ejemplo: 270811.
– date-aaaammdd: Año, mes y día. Por ejemplo: 20230127.
– date-aaaammddhhmmss: Año, mes, día, hora, minuto y segundo. Por ejemplo: 20230127081125.
– date-aaaammddhhmmssTZ: la misma anterior añadiendo la zona horaria. Por ejemplo: 20230127081125+0100.