Cotización del dólar — Guía del gestor

1Qué es el sistema

El sistema guarda la cotización del dólar billete de cada región y se la entrega a dos destinatarios: a las cajas del POS, que la piden a un servicio llamado Pizarra cada vez que un cliente paga con el medio de pago 9/10 DOLAR, y a la pantalla (TV) de cada sucursal, que la muestra a los clientes. Usted carga los valores en el back-office (el “gestor”); cada carga queda registrada con quién, cuándo y de cuánto a cuánto.

Lo esencial en 30 segundos

1. Cada sucursal pertenece a una región, y la cotización se fija por región y medio de pago.
2. Para cambiar el precio, el Cotizador entra en Cotizaciones → Nueva cotización, elige región y medio de pago y carga el valor (ver sección 4).
3. Las cajas y las pantallas toman el valor nuevo enseguida (o desde la fecha programada). Para comprobar qué recibe una caja, el Administrador usa Sucursales → Probar consulta (5.5).

Glosario

2Ingreso, contraseña y roles

2.1 Ingresar

1. Abra en el navegador la dirección del back-office que le dio TI.
2. Escriba su Usuario y Contraseña y pulse Ingresar. Si alguno de los dos es incorrecto, el mensaje no dice cuál (es a propósito).
3. Al entrar se abre Cotizaciones vigentes.

2.2 Primer ingreso y contraseña de un solo uso

Cuando el Administrador le crea el usuario o le restablece la contraseña, usted recibe una contraseña de un solo uso. Al ingresar con ella, el sistema le pide cambiarla antes de hacer cualquier otra cosa.

Complete Contraseña actual (la de un solo uso), Contraseña nueva y Repita la contraseña nueva. Reglas que muestra la pantalla: al menos 8 caracteres, y no puede ser la que recibió al principio ni su nombre de usuario.

2.3 Cambiar su contraseña cuando quiera

En el pie del menú lateral, pulse Cambiar mi contraseña. Es la misma pantalla de arriba, sin el aviso. Cualquier usuario puede cambiar la suya; el cambio queda en la auditoría (sin los valores).

¿Olvidó la contraseña? No hay recuperación por correo: pídale a un Administrador que use Restablecer contraseña (8.1).

2.4 Roles: qué puede hacer cada uno

• Un usuario puede tener Administrador y Cotizador a la vez (así Becerra puede operar con un solo usuario). El administrador inicial tiene los dos.
• El Auditor no se combina con ningún otro rol.
• El menú muestra solo lo que sus roles permiten; además, el servidor vuelve a controlar cada operación.

3El menú lateral

• 1Grupos del menú: Cotizaciones, Sucursales, Auditoría y Configuración. El grupo abierto se resalta en rojo.
• 2Pestañas del grupo abierto, arriba de la pantalla.
• 3Referencias (solo informativo): el dólar de BCRA, CriptoYa y DolarAPI (4.1).
• 4Tabla de cotizaciones por región y medio de pago, con la próxima programada.
• 5Su usuario y roles, Cambiar mi contraseña y Cerrar sesión.

Al pulsar un grupo se abre su primera pestaña disponible.

En el celular

En pantallas angostas el menú se oculta. Pulse el botón ☰ (arriba a la izquierda) para abrirlo; se cierra al elegir una sección, al tocar fuera de él o con Esc.

4Cotizaciones

4.1 Cotizaciones vigentes

Muestra, para cada región × medio de pago, el valor Vigente, Desde cuándo rige y la Próxima programada (si la hay). Sin cotización significa que las cajas de esa región reciben “No se encontró la cotización” para ese medio de pago. Arriba de la tabla figura la Hora del servidor (hora de Argentina): es la que cuenta para decidir qué está vigente, no la de su computadora. La captura está en la sección 3.

4.2 Nueva cotización (Cotizador)

1. Entre en Cotizaciones → Nueva cotización.
2. Elija la Región y el Medio de pago (normalmente DOLAR (9/10)).
3. En Qué se carga deje Fijar un valor y escriba el Valor (ver formatos abajo). Debajo verá el valor vigente y el umbral.
4. En Vigencia elija Inmediata o Programada (con fecha y hora de Argentina).
5. Si aparece el campo Motivo, complételo (ver confirmación reforzada).
6. Pulse Cargar cotización (o Confirmar y cargar si se pidió motivo).

Cómo escribir el valor

Confirmación reforzada: cuándo se pide un motivo

El campo Motivo aparece, y es obligatorio, en dos casos:

• Primera carga (no hay valor vigente para comparar) o la vigente es una suspensión.
• El valor nuevo se aparta más del umbral (10 % por defecto) del valor vigente ahora — también si la nueva es programada.

La versión cargada con motivo queda marcada como Desvío reforzado en el historial y en la auditoría. El servidor vuelve a controlar la regla aunque la pantalla no la hubiera detectado.

El mensaje de éxito dice qué pasa con las cajas:

Vigencia programada

• La fecha y hora no pueden ser anteriores a la hora del servidor: una carga “hacia atrás” se rechaza.
• No puede haber dos versiones activas con la misma región, medio de pago y fecha “desde”; el error indica el valor existente y quién lo cargó.
• Mientras no llegue su hora, la versión figura como Próxima programada en Cotizaciones vigentes y se puede anular desde el historial.

Suspensión

Elija Suspensión en Qué se carga (no se pide valor). Desde que rige, las cajas de esa región reciben “Cotización suspendida” y no pueden cobrar en dólares con ese medio de pago, y la pantalla de la sucursal no muestra valor. Para volver a operar, cargue un valor nuevo (se pedirá motivo, porque no hay valor vigente con el cual comparar).

4.3 Historial y anulación

En Cotizaciones → Historial elija región y medio de pago para ver todas sus versiones: Rige desde, Valor, Cargada (quién y cuándo), Motivo y Estado.

Para anular una versión futura (solo el Cotizador): pulse Anular en su fila, escriba el Motivo de la anulación y pulse Confirmar anulación. Una versión ya vigente o pasada no se puede anular: para corregir un valor que ya rige, cargue una versión nueva inmediata.

5Sucursales (Administrador)

El grupo Sucursales define dónde se aplica cada cotización. El orden natural de alta es: región → sucursal → medio de pago (si falta) → cotización → enlace de pantalla → probar consulta.

5.1 Regiones

Una región inactiva deja a todas sus sucursales sin cotización: las cajas reciben “No se encontró la cotización”.

5.2 Sucursales

• El Número de sucursal es único y debe ser el mismo número que envían las cajas de ese local. Si no coincide, la Pizarra no la reconoce (aparece en Alertas como sucursal desconocida).
• La Región es obligatoria: define qué cotización recibe.
• Una sucursal deshabilitada recibe “No se encontró la cotización”.
• La columna Pantalla dice Configurada o Sin configurar según la sucursal tenga un enlace de pantalla.

5.3 Medios de pago

Cada medio tiene Id del medio de pago, Id del sub-medio (los números que envía la caja), Nombre y Habilitado. Los Ids no se pueden cambiar después del alta. Un medio deshabilitado hace que las cajas reciban “No se encontró la cotización” para él.

5.4 Enlace de pantalla (la TV de la sucursal)

Cada TV muestra la cotización mediante un enlace propio de su sucursal. El enlace se genera desde el back-office y se muestra una sola vez.

1. En Sucursales → Sucursales, pulse Enlace de pantalla en la fila de la sucursal.
2. Si la sucursal ya tenía un enlace, el sistema pide confirmar: “Se va a generar un enlace nuevo… El enlace anterior deja de funcionar”. Pulse Generar nuevo enlace (o Cancelar). Si no tenía, se genera directamente.
3. Aparece el panel URL de la pantalla de la sucursal N. Pulse Copiar.
4. Abra ese enlace en el navegador de la TV, en pantalla completa (F11 o el modo kiosco del navegador). No lo abra en su propia computadora.
5. Pulse Cerrar. El enlace ya no se puede volver a ver; si lo pierde, genere uno nuevo.

5.5 Probar consulta

Muestra exactamente lo que la Pizarra le respondería ahora a una caja para una sucursal y un medio de pago. Úsela después de cargar o cambiar algo, o cuando una caja “no toma el dólar”.

1. En Sucursales → Probar consulta, elija la Sucursal (BranchNumber) de la lista. Para un número que no está en la lista (por ejemplo, el que envía una caja mal configurada), elija Otro número… y escríbalo en Número de sucursal.
2. Elija el Medio de pago y pulse Probar.

Debajo figura la Respuesta exacta que recibiría el POS. La prueba no se registra como consulta del POS, pero sí queda en la Auditoría de cambios como “Prueba de consulta”, con usuario, fecha, sucursal, medio de pago y resultado.

6Pantalla de la sucursal

Es lo que ven los clientes en la TV del local: el logo de Becerra, el nombre de la sucursal y, por cada medio de pago con valor, la cotización vigente de su región y desde cuándo rige.

• Se actualiza sola cada 30 segundos: un cambio de cotización aparece en la TV en menos de medio minuto, sin tocar nada.
• Muestra solo la marca del cliente, con letra grande para leerse a distancia. Las Referencias nunca aparecen aquí.
• El navegador de la TV guarda el enlace: si la TV se reinicia, basta con abrir la dirección /pantalla/<número de sucursal> (sin la parte secreta). Solo hay que cargar el enlace completo otra vez si se borran los datos del navegador o si se genera un enlace nuevo.
• Por eso no conviene abrir el enlace en otra computadora para probarlo: quedaría guardado allí, y con más de 10 intentos fallidos por minuto desde una misma dirección la pantalla se bloquea temporalmente. Para comprobar el valor use Probar consulta.

“Cotización no disponible”

La pantalla nunca muestra un valor viejo: ante cualquier problema muestra “Cotización no disponible” y vuelve a intentar a los 30 segundos. Causas habituales: la región no tiene valor vigente (o está suspendida), se generó un enlace nuevo y la TV todavía tiene el anterior, la sucursal está deshabilitada o la TV perdió la red. Ver Preguntas frecuentes.

7Auditoría

7.1 Auditoría de cambios

Registra todo cambio hecho en el back-office: quién, cuándo, sobre qué y el valor anterior y nuevo. Se puede filtrar por Entidad (Región, Sucursal, Medio de pago, Cotización, Usuario, Configuración, Prueba de consulta), Id de la entidad y período (Desde/Hasta, hora de Argentina).

Ver detalle despliega el valor anterior y el nuevo completos; Ocultar detalle lo cierra. Las contraseñas y los enlaces de pantalla nunca se guardan: solo figura que cambiaron (Token de pantalla: cambiado).

7.2 Consultas del POS

Cada vez que una caja consulta la Pizarra queda una fila. Filtros: Sucursal, Desde/Hasta, Id de transacción y Resultado. La tabla guarda todas las consultas: combine el resultado con un período o una sucursal para que la búsqueda sea rápida.

Resultados posibles

7.3 Alertas

8Configuración (Administrador)

8.1 Usuarios

Crear un usuario

1. Pulse Nuevo usuario.
2. Escriba el Usuario (letras, números y . _ @ -) y una Contraseña de un solo uso de al menos 8 caracteres.
3. Marque los Roles. Si marca Auditor, las otras casillas se deshabilitan (el Auditor es exclusivo).
4. Pulse Crear usuario y entregue la contraseña a la persona por un medio seguro. En su primer ingreso deberá cambiarla (2.2).

Cambiar roles

Nadie puede quitarse a sí mismo el rol Administrador, y no se le puede quitar al último administrador activo. Desactivar da de baja al usuario sin borrarlo (su historia en la auditoría se conserva); el mismo botón lo vuelve a activar.

Restablecer contraseña

Al pulsar Confirmar restablecimiento, la contraseña anterior deja de servir y el sistema genera una contraseña de un solo uso, que aparece una sola vez en un panel con Copiar y Cerrar. Entréguela por un medio seguro; hasta que el usuario la cambie, el sistema solo le permite cambiarla. El restablecimiento queda auditado, sin la contraseña.

8.2 Umbral de confirmación reforzada

Define el Porcentaje a partir del cual un cambio de valor exige motivo (4.2). Acepta un número mayor que 0 y hasta 100, con hasta 2 decimales (por ejemplo 10 o 12,5). El cambio queda en la auditoría.

9Preguntas frecuentes y problemas comunes

10Arquitectura y red

El servidor expone dos puertos HTTP distintos. Las cajas (POS) hablan TCP directo con la Pizarra, sin TLS; el back-office y la pantalla de sucursal pasan por un proxy de TLS.

Cajas (POS) hacia la Pizarra

Back-office y pantalla (TV de kiosco) hacia el servidor

11Requisitos

Archivos de la release

Se descargan de la GitHub Release del tag. El servidor nunca necesita el árbol de fuentes.

Verifique los hashes antes de usar nada. Todas las líneas tienen que decir OK:

cd C:\Descargas\release
Get-Content SHA256SUMS | ForEach-Object {
  $hash, $nombre = $_ -split '  ', 2
  $real = (Get-FileHash $nombre -Algorithm SHA256).Hash.ToLower()
  "{0}  {1}" -f ($(if ($real -eq $hash) { 'OK    ' } else { 'FALLA ' })), $nombre
}

12Primera instalación paso a paso

1. Decidir el proxy y pedir datos a Becerra. Confirmar quién provee el proxy de TLS y el dominio (bloquea el inicio, ver sección 17) y pedir las subredes de las cajas.
2. Verificar los archivos de la release (comando de la sección 11).
3. Crear la base y los dos logins (fase A, abajo).
4. Instalar Temurin 25 y el junction C:\Tipre\jdk; Python 3.10+ para el seed; comprobar NTP.
5. Crear carpetas y la cuenta del servicio con sus permisos.
6. Escribir config\application.yml (sección 13), con 127.0.0.1/32 en la allowlist, y la marca del cliente.
7. Instalar y arrancar el servicio. Primer arranque: Flyway crea las tablas.
8. Fase B: bloque DENY, matriz de permisos y reinicio.
9. Firewall y proxy de TLS; comprobar que /actuator/health por el proxy da 404 o 403.
10. Chequeo de humo (sección 15). La Pizarra da 404 hasta cargar la primera versión; repítalo después.
11. Ingresar con el primer administrador y cambiar su contraseña; cargar el catálogo (seed o ABM).
12. Cargar la primera versión de cotización vigente por región para el medio 9/10 ("Nueva versión").
13. Generar el token de la pantalla de cada sucursal desde "Sucursales" (se muestra una sola vez).
14. Monitoreo, respaldos y ventanas de parches.
15. Prueba de laboratorio con un POS real antes de apuntar las cajas, y prerrequisitos de cada POS (sección 14).

Carpetas y cuenta del servicio

<INSTALL>\bimonetarismo-service.exe   WinSW 2.12.0, renombrado igual que el XML
<INSTALL>\bimonetarismo-service.xml   plantilla de la release
<INSTALL>\bimonetarismo.jar           jar de release, renombrado (sin la versión)
<INSTALL>\config\application.yml      configuración externa
<INSTALL>\logs\                       lo escribe WinSW
<INSTALL>\clientes\<cliente>\         carpeta de marca del cliente
C:\Tipre\jdk                         junction al JDK de Temurin instalado

Cierre <RAIZ> antes de poner nada dentro (quita la herencia de permisos; *S-1-5-32-544 es Administradores y *S-1-5-18 es SYSTEM). Si <RAIZ> ya existe con otro contenido, revíselo antes con icacls.

New-Item -ItemType Directory -Force <RAIZ> | Out-Null
icacls <RAIZ> /inheritance:r /grant:r "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F"
New-Item -ItemType Directory -Force <INSTALL>\config, <INSTALL>\logs | Out-Null
cmd /c mklink /J <RAIZ>\jdk "C:\Program Files\Eclipse Adoptium\jdk-25.x.y-hotspot"
& <RAIZ>\jdk\bin\java.exe -version

Cuenta local dedicada, sin inicio de sesión interactivo. La contraseña se pide sin eco y no se escribe en el XML:

$clave = Read-Host "Contraseña de la cuenta del servicio" -AsSecureString
New-LocalUser -Name svc-bimonetarismo -Password $clave -PasswordNeverExpires -UserMayNotChangePassword -Description "SistemaBiMonetarismo"

$cuenta = "$env:COMPUTERNAME\svc-bimonetarismo"
icacls <RAIZ> /grant "${cuenta}:(OI)(CI)RX"
icacls <INSTALL>\logs /grant "${cuenta}:(OI)(CI)M"
icacls <INSTALL>\config /inheritance:r /grant:r "*S-1-5-32-544:(OI)(CI)F" "${cuenta}:(OI)(CI)R"
icacls <RAIZ>
icacls <INSTALL>\config

Los dos icacls finales son la comprobación: en <RAIZ> solo Administradores, SYSTEM y la cuenta; en config solo Administradores y la cuenta (guarda las contraseñas de la base). Si <INSTALL> está fuera de <RAIZ>, la cuenta no hereda nada: agregue icacls <INSTALL> /grant "${cuenta}:(OI)(CI)RX".

Base de datos y logins de SQL Server

Hay dos logins por mínimo privilegio. Los permisos se aplican en dos fases porque Flyway crea las tablas en el primer arranque y un DENY exige que la tabla exista.

Fase A, antes del primer arranque (con un login que pueda crear bases y logins; contraseñas largas y distintas):

CREATE DATABASE [<base>];
GO
CREATE LOGIN [<dueño>]   WITH PASSWORD = N'<contraseña larga 1>', CHECK_POLICY = ON, CHECK_EXPIRATION = OFF, DEFAULT_DATABASE = [<base>];
CREATE LOGIN [<runtime>] WITH PASSWORD = N'<contraseña larga 2>', CHECK_POLICY = ON, CHECK_EXPIRATION = OFF, DEFAULT_DATABASE = [<base>];
GO
USE [<base>];
CREATE USER [<dueño>]   FOR LOGIN [<dueño>];
ALTER ROLE db_owner ADD MEMBER [<dueño>];
CREATE USER [<runtime>] FOR LOGIN [<runtime>];
GRANT SELECT, INSERT, UPDATE ON SCHEMA::dbo TO [<runtime>];
GO

Fase B, después del primer arranque (con el login dueño):

USE [<base>];
DENY  DELETE ON SCHEMA::dbo TO [<runtime>];
DENY  UPDATE ON OBJECT::dbo.auditoria_cambio    TO [<runtime>];
DENY  UPDATE ON OBJECT::dbo.consulta_cotizacion TO [<runtime>];
DENY  INSERT, UPDATE ON OBJECT::dbo.flyway_schema_history TO [<runtime>];
GRANT UPDATE ON OBJECT::dbo.seq_transaction_id TO [<runtime>];

Reinicie el servicio y verifique los permisos efectivos (no cambia nada):

EXECUTE AS USER = '<runtime>';
SELECT t.name AS tabla,
       HAS_PERMS_BY_NAME('dbo.' + t.name, 'OBJECT', 'SELECT') AS sel,
       HAS_PERMS_BY_NAME('dbo.' + t.name, 'OBJECT', 'INSERT') AS ins,
       HAS_PERMS_BY_NAME('dbo.' + t.name, 'OBJECT', 'UPDATE') AS upd,
       HAS_PERMS_BY_NAME('dbo.' + t.name, 'OBJECT', 'DELETE') AS del
FROM sys.tables t ORDER BY t.name;
REVERT;

Cuando una release agrega tablas, vuelva a correr esta matriz: un DENY no se hereda hacia adelante y las notas de la release dicen qué DENY agregar.

Servicio Windows (WinSW)

La plantilla define reinicio automático (startmode Automatic; reintentos a los 10 s, 20 s y 60 s), logs en <INSTALL>\logs (8 archivos de 10 MB), directorio de trabajo <INSTALL> y parada con stoptimeout de 60 s. Edite el XML solo si el junction no está en C:\Tipre\jdk o si hace falta un proxy de salida. No agregue ninguna contraseña al XML.

Desde una consola de administrador, en <INSTALL>. install /p pregunta la cuenta (escriba .\svc-bimonetarismo) y su contraseña; responda y a "Log on as a service":

.\bimonetarismo-service.exe install /p
.\bimonetarismo-service.exe start
Get-Service BimonetarismoService
Get-ChildItem <INSTALL>\logs

El log dice Successfully applied N migration en el primer arranque. Si el servicio no inicia con el error 1069, la cuenta no tiene el derecho "Iniciar sesión como servicio" (concédalo en la Directiva de seguridad local).

Primer administrador

Las claves bm.admin.usuario y bm.admin.password de application.yml crean el primer Administrador solo mientras la tabla de usuarios está vacía; los reinicios no tocan los usuarios. La contraseña la elige quien instala (no es de un solo uso) y no se registra en el log ni en la auditoría.

1. Ingrese con ese usuario (la contraseña se pide por consola): curl.exe -u <usuario> http://localhost:8080/api/v1/me tiene que dar 200.
2. Cambie la contraseña desde "Cambiar contraseña" (/cambiar-password) o con PUT /api/v1/me/password ({actual, nueva}). La interfaz no lo obliga.
3. Después puede borrar bm.admin.usuario y bm.admin.password de application.yml.

Si nadie puede ingresar, corrija el bloque y reinicie (mientras no haya usuarios, se vuelve a intentar). Nunca escriba usuario:contraseña en la línea de comandos: -u <usuario> hace que curl.exe pida la contraseña.

Proxy de TLS

El proxy no es parte de la aplicación ni de la release. Publica una lista explícita de rutas (todo lo demás es 404) y niega /actuator: / exacta, /favicon.svg, /login, /cambiar-password, /gestion/..., /pantalla/..., /assets/... y /api/.... Ejemplo mínimo de nginx:

server {
    listen 443 ssl;
    server_name cotizacion.<cliente>.<dominio>;
    ssl_certificate     <ruta>/fullchain.pem;
    ssl_certificate_key <ruta>/privkey.pem;

    location ^~ /actuator { return 404; }
    location = /          { proxy_pass http://<servidor>:8080; proxy_set_header Host $host; }
    location = /favicon.svg { proxy_pass http://<servidor>:8080; proxy_set_header Host $host; }
    location ~ ^/(login|cambiar-password|gestion|pantalla|assets|api)(/|$) { proxy_pass http://<servidor>:8080; proxy_set_header Host $host; }
    location / { return 404; }
}

En IIS con ARR: una regla de bloqueo para ^actuator antes de las reglas de reenvío. El proxy no necesita enviar X-Forwarded-For: la aplicación lo ignora, por lo que detrás del proxy el límite de intentos de la pantalla actúa sobre la IP del proxy.

Firewall del servidor

New-NetFirewallRule -DisplayName "Bimonetarismo Pizarra (cajas)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8084 -RemoteAddress 10.x.x.x/16,10.y.y.y/16
New-NetFirewallRule -DisplayName "Bimonetarismo principal (proxy y operacion)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8080 -RemoteAddress <IP del proxy>,<red de operacion>
Get-NetFirewallRule -Direction Inbound -Enabled True -Action Allow | Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -in '8080','8084','Any' }

La tercera línea no debe listar ninguna regla más que las dos primeras (por ejemplo una regla automática de "Java Platform SE binary" que abra el puerto a cualquier origen).

13Referencia de configuración

El archivo se llama config\application.yml y sale de application.yml.example, reemplazando cada CHANGE-ME. No se commitea nunca y no va dentro del jar. La ruta se resuelve contra el directorio de trabajo del proceso (<INSTALL>), no contra la ubicación del jar. La aplicación no arranca sin las claves spring.datasource.*, bm.pizarra.port y bm.pizarra.allowlist. Antes de editar un archivo existente, haga una copia con la fecha.

Certificado de SQL Server

encrypt=true;trustServerCertificate=false exige que el certificado sea de una CA en la que la JVM confíe. Decisión abierta Si la base está en el mismo servidor, trustServerCertificate=true no agrega riesgo. Si está en otra máquina, se recomienda instalar la CA en un almacén propio (trustStore=<ruta>;trustStorePassword=<contraseña> en las dos URL) y no en el cacerts del JDK: un parche de Temurin trae el suyo y la conexión empieza a fallar sin que nadie toque nada.

14Prerrequisitos en el POS

Sin esto el POS nunca consulta la Pizarra: en Becerra el dólar hoy no está operativo en el POS. En la base de cada POS:

Además, el NroSuc de cada POS tiene que estar dado de alta como sucursal en el servidor (con su región y una cotización vigente para 9/10) y la IP de las cajas dentro de la allowlist. Una sucursal que consulta sin estar dada de alta aparece en las alertas ("sucursales desconocidas") y recibe 404.

La prueba de laboratorio con un POS real (RUNBOOK 11) valida que lo grabado por el POS coincide con lo auditado en el servidor.

15Verificar que funciona

Corra estos comandos desde el propio servidor, después de la instalación y de cada despliegue. Reemplace el puerto, la sucursal de prueba y el dominio.

# 1. El servicio corre
Get-Service BimonetarismoService

# 2. Arrancó y cargó el snapshot (buscar estas dos líneas)
Select-String -Path <INSTALL>\logs\bimonetarismo-service.out.log -Pattern "Started BimonetarismoApplication","Snapshot loaded with"

# 3. Vivo, y la UI y el branding salen del jar
curl.exe -s http://localhost:8080/actuator/health                      # {"groups":["liveness","readiness"],"status":"UP"}
curl.exe -s -o NUL -w "%{http_code}`n" http://localhost:8080/login     # 200
curl.exe -s http://localhost:8080/api/v1/branding                      # nombre y colores del cliente

# 4. Un administrador puede ingresar
curl.exe -s -u <administrador> http://localhost:8080/api/v1/me         # pide la contraseña; roles ADMINISTRADOR, COTIZADOR

# 5. La Pizarra contesta como la ve el POS
curl.exe -s -i "http://127.0.0.1:8084/APIPizarraPrecios/Tipre/GetCurrentPrice?BranchNumber=<NroSuc>&PaymentMethod.Id=9&PaymentMethod.SubId=10"

# 6. El proxy NO publica el actuator: 404 o 403
curl.exe -s -o NUL -w "%{http_code}`n" https://<dominio>/actuator/health

• Repita el paso 5 desde una IP de la allowlist (una caja o un equipo de su subred, con la IP del servidor en lugar de 127.0.0.1): comprueba el firewall y la lista.
• Una ruta que no es GetCurrentPrice en el puerto de la Pizarra da 404 vacío: curl.exe -s -o NUL -w "%{http_code}`n" http://127.0.0.1:8084/actuator/health tiene que dar 404.
• Métricas normales: pizarra.snapshot.edad.segundos menor que 120, pizarra.auditoria.escritor.vivo en 1 y pizarra.auditoria.perdidas en 0.
• Back-office: abra la interfaz por el proxy (HTTPS), ingrese, vea las cotizaciones vigentes y la sección de alertas.
• Kiosco: abra /pantalla/<NroSuc> con el token de la sucursal (generado en "Sucursales") en el navegador de la TV.
• Marca: el log tiene Branding of this install: client name '<nombre>'; el nombre neutro "Cotización del dólar" significa que el import no ocurrió (ruta incorrecta). GET /api/v1/branding/logo-cliente debe dar 200.

16Operación: actualizaciones, respaldos y logs

Actualizar una versión (RUNBOOK 6.2)

Fuera del horario pico de las cajas: mientras el servicio está detenido, las cajas no tienen dólar (unos 12 a 16 s de arranque, más lo que tarde el respaldo).

1. Lea las notas de la release, empezando por la sección calculada (migraciones nuevas y cambios de application.yml.example). Si salteó versiones, lea la de cada release intermedia. Una clave obligatoria nueva impide el arranque.
2. Copie config\application.yml antes de editarlo y aplique los cambios.
3. Verifique el hash del jar.
4. Detenga el servicio y confirme el cierre: .\bimonetarismo-service.exe stop; busque Audit shutdown: 0 audit entries remain unflushed en el log.
5. Respaldo completo después de detener, y anote la versión del esquema:

   BACKUP DATABASE [<base>] TO DISK = N'<ruta>\pre-<tag>.bak' WITH COPY_ONLY, COMPRESSION, CHECKSUM, STATS = 10;
   RESTORE VERIFYONLY FROM DISK = N'<ruta>\pre-<tag>.bak' WITH CHECKSUM;
   SELECT TOP 1 version, description FROM flyway_schema_history WHERE success = 1 ORDER BY installed_rank DESC;

6. Conserve el jar anterior (bimonetarismo.jar.anterior-<fecha>) y copie el nuevo como bimonetarismo.jar.
7. Arranque: .\bimonetarismo-service.exe start. Flyway aplica las migraciones pendientes.
8. Si la release agregó tablas, vuelva a correr la matriz de permisos y agregue los DENY indicados.
9. Chequeo de humo (sección 15) y anote fecha, tag y SHA-256 en el registro de cambios.

Volver atrás (RUNBOOK 6.4)

• Solo el jar (sin migraciones aplicadas): detenga el servicio, restaure bimonetarismo.jar.anterior-<fecha> y el application.yml anterior, arranque y haga el chequeo de humo.
• Con restauración (la release aplicó migraciones): no asuma que el jar anterior es compatible con el esquema nuevo. Siga el procedimiento B del RUNBOOK, que incluye adelantar la secuencia (abajo).

Respaldos y restauración (RUNBOOK 6.7)

• Respaldo completo diario y respaldo del log de transacciones con la frecuencia que fije Becerra. Pruebe la restauración periódicamente: un respaldo que nunca se restauró no está probado.
• Retención: las versiones de cotización y la auditoría se guardan para siempre; las consultas del POS, toda la vida operativa, sin purga. El back-office alerta cuando consulta_cotizacion supera 10 GB (bm.alertas.consultas-max-gb).

DECLARE @actual BIGINT = (SELECT CAST(current_value AS BIGINT) FROM sys.sequences WHERE name = 'seq_transaction_id');
DECLARE @sql NVARCHAR(200) = N'ALTER SEQUENCE dbo.seq_transaction_id RESTART WITH ' + CAST(@actual + 100000000 AS NVARCHAR(30));
EXEC (@sql);
SELECT CAST(current_value AS BIGINT) AS secuencia_actual FROM sys.sequences WHERE name = 'seq_transaction_id';

Logs y monitoreo

• WinSW captura la salida en <INSTALL>\logs con rotación (8 archivos de 10 MB). Los nombres reales los muestra Get-ChildItem <INSTALL>\logs; el RUNBOOK usa bimonetarismo-service.out.log y .err.log. Ningún secreto se escribe en el log.
• El monitoreo lee desde el propio servidor: curl.exe -s http://localhost:8080/actuator/metrics/<nombre>. Alerte por el aumento de pizarra.auditoria.perdidas (vuelve a 0 al reiniciar: anótelo antes), por pizarra.auditoria.cola.tamano mayor que 50000, pizarra.auditoria.escritor.vivo en 0 y pizarra.snapshot.edad.segundos mayor que 300 (o -1 pasado el arranque). Tabla completa en RUNBOOK 7.2.
• Fuera de la aplicación, vigile el estado del servicio, los eventos 7031 y 7034 del Service Control Manager, el disco del servidor y de la base, y la cola de respaldos.
• Reinicios y parches (Temurin trimestral, Windows, SQL Server): siempre fuera del pico; antes de reiniciar Windows detenga el servicio y busque la línea Audit shutdown. Con un parche de Temurin, reapunte el junction (RUNBOOK 6.8).
• Fragmentación del índice de consulta_cotizacion: revísela periódicamente (RUNBOOK 10).

Diagnóstico técnico rápido

Para incidentes (base caída, la Pizarra no responde, auditoría perdida) siga los playbooks de las secciones 15.1, 15.2 y 15.3 del RUNBOOK, y complete antes de producción su tabla de contactos.

17Estado del procedimiento y decisiones abiertas

La tabla de decisiones del RUNBOOK (sección 1) tiene la columna "Confirmado (quién, fecha)" vacía en todas sus filas: todas siguen abiertas. Estas son las que más afectan a quien instala; "Si no se confirma" es lo que rige mientras nadie diga otra cosa.

El resto (6 umbrales de alerta, 7 calentamiento, 8 secuencia tras restaurar, 9 remedición, 15 fragmentación, 18 límite de despliegue) también figura sin confirmar en la sección 1 del RUNBOOK. Quien valida registra ahí quién confirmó cada una y cuándo.

Pendientes de proyecto relacionados: la POS_MMON.DLL de Becerra (sección 14, AC-25), la lista real de sucursales y el mapeo de NroSuc (R-06; el CSV de clientes\becerra\ trae marcadores de posición) y la tabla de contactos de incidentes (RUNBOOK 15).

18Alcance y verificación de esta guía

• Las capturas se tomaron el 5 de octubre de 2026 sobre la versión más reciente de la interfaz, en un ambiente de prueba con una base de datos descartable. Contiene datos de prueba que no existen en producción: el medio de pago FIXTURE AC-16, los usuarios cot-fixture, pantalla-fixture, cotizador.demo y auditor.prueba, la Región de prueba y la sucursal 99 — Sucursal de prueba.
• Las capturas de escritorio son de 1440×900 px; las de celular, de 375 px de ancho; las de la pantalla de la sucursal, de 1280×720. Los círculos rojos numerados se agregaron sobre las capturas para esta guía.
• Ninguna captura muestra secretos: los campos de contraseña aparecen vacíos o enmascarados, la parte secreta del enlace de pantalla está tapada, y de Restablecer contraseña solo se muestra la confirmación. El ejemplo de desvío (sección 4.2) no se envió.
• El contenido se contrastó con la interfaz en vivo, con su código fuente y con SPEC.md, ACCEPTANCE.md, docs/API.md y docs/RUNBOOK.md. La parte técnica (secciones 10 a 17) resume el RUNBOOK, que es la fuente de detalle; sus procedimientos todavía son borradores a validar en laboratorio.
• Los vínculos a RUNBOOK.md funcionan al abrir la guía desde el repositorio; si la guía se publica sola como sitio estático, el RUNBOOK debe consultarse en el repositorio.