Imputación de promociones, simulación de cuotas, gestión del catálogo y experiencia PINPAD. Relevamiento del código disponible en TsPromos, TsTicket y TsPagos.
3 servicios16 cambios documentadosVersión Maven: 14.10.2026Código e historial revisadosIncluye cambios locales sin commit
El cambio organiza tres responsabilidades: TsPromos calcula e imputa beneficios por medio y cuota; TsTicket coordina la selección y entrega configuración al POS; TsPagos administra el catálogo local y procesa el resultado PINPAD. El frontend continúa ingresando por TsTicket.
Dos puntos centrales. El contrato actual usa códigos numéricos nro/subnro y matching real por nro + subnro + nroCuota. La simulación mantiene ticket y caché sin cambios, pero sí genera auditoría en TsPromos y, con la ampliación local, en TsTicket.
Versiones y alcance del relevamiento
Servicio
Versión del proyecto (pom.xml)
Spring Boot (parent)
HEAD revisado
Estado local
TsPromos
14.10.2026
3.4.0
08678af
Sin cambios locales
TsTicket
14.10.2026
4.1.0
cfdcdbc
Con modificaciones y/o archivos sin commit
TsPagos
14.10.2026
3.4.2
0f91a13
Con modificaciones y/o archivos sin commit
Versiones extraídas del elemento project/version de cada pom.xml, diferenciadas de la versión del parent Spring Boot. El relevamiento cubre la evolución reciente del 09 al 16/10/2026 y el estado del workspace al emitir este documento. No representa una certificación del binario desplegado. TsPromos contiene además el commit de auditoría del 15/10 manteniendo la versión Maven del 14/10.
TsPromos v14.10.2026
Énfasis: nueva imputación por terna y simulación de alternativas reutilizando el motor de promociones.
La consulta no modifica el ticket recibido ni la caché, pero sí escribe auditoría.
Detalle e impacto
01
Nueva identificación e imputación de promociones por medio y cuota
Implementado en historial revisado
Contexto
La identificación anterior usaba mediodepagoid. La versión actual retira ese campo del pago y cambia la regla de coincidencia.
Cambio
El modo MDP exige coincidencia de nro + subnro + nroCuota contra una misma entrada del padrón. La misma regla determina elegibilidad y ordenOrigen; se priorizan pagos OPEN. No se combinan atributos tomados de distintas entradas.
Impacto
El beneficio queda asociado al origen del pago correspondiente. Una cuota distinta no habilita la promoción aunque coincidan medio y submedio. Se mantienen las reglas de cálculo e impuestos del motor.
Evidencia
Código y diff revisados: matchesPayment, matchesPaymentMethod y resolvePromotionOrderOrigin. Existe caso matchingReal_usaTernaCompletaSinDependerDelId en PromoServiceTest.
Los clientes deben abandonar el selector anterior por ID y los códigos transportados como cadenas.
Cambio
nro, subnro y nroCuota se representan como enteros no negativos; no se admiten decimales ni valores fuera de Integer. En simulación se solicitan nro, subnro y ticket. El padrón incorpora mediodepagocuotaid, nro y subNro; nroCuota identifica la cantidad de cuotas.
Impacto
El ID de plan mediodepagocuotaid permanece en las alternativas de simulación: no es el ID del medio retirado. El matching real utiliza la terna; no usa el ID del plan como selector del pago.
Evidencia
DTOs, CodigoEnteroDeserializer y Docs/sql/PadronPromos_V2.sql revisados. Entrada inválida: HTTP 400. El SQL fuente externo configurado requiere actualización operativa; no se modifica automáticamente.
TsPromos/src/main/java/com/tipre/tspromos/model/dto/RequestSimularCuotas.java:11 Símbolo: public class RequestSimularCuotas
03
Nuevo simulador de cuotas sobre el total de la compra
Implementado en historial revisado
Contexto
Se necesita conocer descuentos y recargos de las alternativas antes de confirmar un pago.
Cambio
POST /promos/v1/promoTicket/simularCuotas toma un único snapshot de promociones y evalúa cada ID de plan en una copia independiente del ticket. Conserva ITEMS y reutiliza el core MDP, sus condiciones, acumulación y topes. Ordena por cantidad de cuotas y luego por ID.
Impacto
Devuelve mediodepagocuotaid, nro, subnro, cuotas, total y descRec. total es el importe completo, no el valor de una cuota. descRec negativo significa descuento; positivo, recargo. Usa precisión de 8 decimales y HALF_EVEN. No cotiza pagos parciales ni valida habilitación bancaria.
Evidencia
Controller y core revisados. Sin planes: lista vacía. Plan incompleto o cuotas inconsistentes: HTTP 409. Existen pruebas de aislamiento, topes, condiciones y redondeo; no ejecutadas en esta revisión.
El cambio más reciente del servicio agrega trazabilidad a las consultas de simulación.
Cambio
Cada llamada con entrada válida intenta guardar una fila en TrxPromo con modoComputo="SIMULA", identidad del ticket, request y response. Incluye cotización exitosa, resultado vacío y errores de padrón o cálculo. Un fallo de auditoría se registra en log y preserva la respuesta o excepción original.
Impacto
La consulta no modifica el ticket recibido ni la caché, pero sí escribe auditoría. La afirmación histórica “sin grabar nada en BD” ya no describe esta implementación. Entradas rechazadas antes de calcular no generan esa fila.
Evidencia
Commit 08678af del 15/10/2026 y registrarSimulacion revisados. Existen pruebas de auditoría única, resultado vacío y fallo de persistencia. La versión del pom continúa en 14.10.2026.
Sin raw se omite TARJETA sin bloquear tickets históricos.
Detalle e impacto
05
Catálogo en configuración del cliente y registro POS
Implementado en historial revisado
Contexto
El POS necesita recibir los medios administrados centralmente al iniciar o recargar su configuración.
Cambio
GET /ticket/v1/pos/configtoclient y POST /ticket/v1/pos/register exitoso entregan data.config.mediosPago.mediosDisponibles con la misma composición. Incluyen habilitados y deshabilitados, nroCuota, presentación, límites, opciones, restricciones, timeout y procesador. Ordenan por orden, nro y subnro.
Impacto
El cliente puede obtener el catálogo directamente del registro y decide visibilidad según habilitado. Se preservan propiedades previas del grupo mediosPago mediante copia profunda. El catálogo no se agrega a cada ticket ni a respuestas operativas de pago.
Evidencia
ConfiguracionMediosPagoService.enriquecer y PosRestController.subscribeTerminal revisados. Registro rechazado no consulta catálogo. Registro exitoso sin catálogo válido conserva éxito y devuelve lista vacía con NO_DISPONIBLE.
TsTicket/src/main/java/com/tipre/tsticket/service/ConfiguracionMediosPagoService.java:25 Símbolo: public PosConfigDto enriquecer
06
Exclusiones heredadas y tolerancia a fallos del catálogo
Implementado en historial revisado
Contexto
La disponibilidad por terminal requiere combinar reglas locales y una vista consistente del catálogo de TsPagos.
Cambio
mediosExcluidos usa parejas numéricas nro/subnro y herencia por reemplazo TERMINAL → NEGOCIO → SUCURSAL → COMERCIO; [] borra la herencia. Se informa versionCatalogo, actualizadoEn y estadoCatalogo. La caché conserva la última vista ante errores como DESACTUALIZADO; sin vista válida informa NO_DISPONIBLE.
Impacto
Una exclusión inválida entrega lista vacía y errorConfiguracion. Parejas desconocidas se ignoran con advertencia. El cliente HTTP deriva su URL de pago.url, usa timeout de 3000 ms, recarga por defecto cada 60000 ms y buffer de 4 MiB.
Evidencia
Servicios de catálogo/composición, cliente HTTP y documentación local revisados. Hay pruebas específicas de herencia, controlador POS y cliente HTTP. No se comprobó disponibilidad de servicios desplegados.
TsTicket/src/main/java/com/tipre/tsticket/service/MediosPagoCatalogoService.java:51 Símbolo: public void actualizar
07
Simulación REST/STOMP y auditoría del intercambio
Incluye cambio local sin commit
Contexto
El frontend consume TsTicket como entrada única; la simulación debe conservar correlación y diagnóstico.
Cambio
POST /ticket/v1/simularCuotas y STOMP /app/simularCuotas reciben ticketDto, nro y subnro. STOMP responde en /user/queue/simularCuotas. La correlación vuelve en data2.simularCuotasCorrelationId. Se llama a TsPromos por códigos, sin resolver IDs ni depender del catálogo de configuración.
Impacto
El campo mediodepagoid retirado se rechaza. REST responde 400 ante validaciones y 502 ante fallos de TsPromos. La auditoría en trx_detalle registra commandReference=simularCuotas, request/correlación, respuesta y resultado; no altera el ticket ni la caché. Validaciones previas no generan intercambio.
Evidencia
Controladores, RequestTicketSimularCuotasDto, PromoService y PromoApiClient revisados. Auditoría ampliada y tratamiento de respuestas forman parte del diff local. Existen SimularCuotasControllerTest y SimularCuotasHttpAuditTest.
TsTicket/src/main/java/com/tipre/tsticket/service/PromoService.java:47 Símbolo: public List<CotizacionCuotaDto> simularCuotas
08
Selección de medio y cuotas ligada a la orden persistida
Incluye cambio local sin commit
Contexto
La elección usada para calcular MDP y ejecutar el pago debe corresponder a la intención persistida.
Cambio
CREATE_INTENT valida la selección y evita nuevas intenciones si existe otra activa. La terna se guarda en ordenDePago y luego en mediosDePago, dentro de Trx.jsonticket. EXECUTE_PAYMENT recupera selección de la orden persistida; si el cliente envía valores diferentes, rechaza la operación.
Impacto
No requiere columnas nuevas. nroCuota de un pago real no se contrasta contra las alternativas del catálogo. Códigos históricos como "02" se leen como entero 2 sin reescribir el historial. La información se envía a TsPromos para imputación por terna.
Evidencia
prepararSeleccionPago, RequestPromoTicket y DTOs revisados. SeleccionPagoTest cubre reglas de selección. Este método contiene también la ampliación PINPAD local descrita a continuación.
PINPAD: intención provisional y confirmación tardía del medio real
Incluye cambio local sin commit
Contexto
PINPAD puede conocer el medio y las cuotas reales después de crear la intención.
Cambio
CREATE_INTENT PINPAD permite 0/0/0 provisional sin validarlo contra catálogo ni aplicar MDP a esa terna; conserva ITEMS. EXECUTE_PAYMENT exige la misma orden PINPAD OPEN e ID y confirma nro/subnro/nroCuota reales. Calcula MDP, actualiza importe y persiste antes de enviar a TsPagos.
Impacto
seleccionPinpadConfirmada evita cambiar una selección ya confirmada, incluso si tiene ceros. Se toma del persistido. Simular no modifica la intención. Otros procesadores conservan la selección fijada. Una denegación deja orden ERROR y permite gestionar un nuevo intento.
Evidencia
TicketService.prepararSeleccionPago, prepareTicketForPaymentRequest y PromoService.resolveModoComputo revisados. Cambio presente en archivos locales sin commit; no acredita despliegue ni prueba con dispositivo.
Voucher TARJETA y recuperación sin repetir el cobro
Incluye cambio local sin commit
Contexto
El comprobante del cliente recibido de APIDRIVER debe conservarse e imprimirse tras aprobar el pago PINPAD.
Cambio
Se preserva el ResponsePayment normalizado y, dentro de su customData, el JSON original. La tarea TARJETA usa datosHost.vouchercliente_raw para generar ESC/POS Base64, una copia cliente por pago con orden PAGADA; incluye idProcessorPayment opcional. Reintentos conservan vouchers ya generados.
Impacto
Sin raw se omite TARJETA sin bloquear tickets históricos. Raw inválido o error de generación deja la tarea pendiente y el ticket VOUCHERPENDING; recuperar cierre no vuelve a cobrar. Reimpresión usa datosImpreso persistido. No reconstruye automáticamente tickets históricos CLOSE.
Evidencia
generarVouchersTarjeta, VoucherService.generarVoucherTarjeta y VoucherTarjetaParser.parsear revisados. Existen VoucherTarjetaTest y guía VOUCHER_TARJETA_PINPAD.md. Cambios locales; pendiente probar impresión física y recepción frontend.
Habilita persistencia y generación del voucher TARJETA en TsTicket.
Detalle e impacto
11
Nuevo catálogo local, administrado desde TsPagos
Implementado en historial revisado
Contexto
La gestión de medios deja de depender de la sincronización externa y de IDs del catálogo anterior.
Cambio
El catálogo vigente reside en dbo.medios_pago_local y dbo.medios_pago_local_estado. Cada medio se identifica por nro/subnro enteros, sin ID. Tiene un procesador requerido y atributos de presentación, límites, restricciones, opciones, orden, habilitado, timeout y nroCuota. No contiene planes de cuotas.
Impacto
GET /pagos/v1/mediosdepago entrega catálogo completo, incluidos deshabilitados; filtro sólo por pareja completa. Se retiran sincronización externa, consulta por ID y rutas de planes del esquema anterior. Las tablas legadas no se convierten automáticamente.
Evidencia
MedioPago, MediosPagoController y DDL V20261014__crear_medios_pago_local.sql revisados. Campos de configuración POS no incorporan por sí solos nuevas reglas de ejecución de cobros.
TsPagos/src/main/java/com/tipre/tspagos/mediospago/MedioPago.java:12 Símbolo: public record MedioPago
12
Panel de medios: alta, edición y baja lógica
Implementado en historial revisado
Contexto
Se incorpora una sección específica para administrar medios en el panel existente de operaciones y promociones pospago.
Cambio
La pestaña Medios de pago permite buscar por descripción, filtrar medio/procesador/tipo/estado, crear, editar y deshabilitar/reactivar. Presenta grupos de configuración y la fila Nro. | Subnro. | NroCta. Usa POST /panel/mediosdepago y PUT /panel/mediosdepago?nro=...&subnro=... bajo /pagos/v1.
Impacto
No hay DELETE: se usa habilitado=false. PUT reemplaza configuración completa; la query identifica pareja original y el cuerpo puede renombrarla. Renombrar no traslada exclusiones de TsTicket: deben revisarse para evitar que el nuevo código quede visible.
Evidencia
index.html, assets/panel.js y MediosPagoController revisados. Alta responde 201; edición 200; registro inexistente 404; pareja u orden duplicados 409. Actualizar vista consulta catálogo local, sin sincronización externa.
El ABM necesita configuraciones completas y coherentes aun cuando se omiten grupos opcionales.
Cambio
Identificación exige título, descripción, tipo, códigos, orden, habilitado y procesador. Orden es único incluso en deshabilitados. Mínimos/máximos son no negativos y coherentes. nroCuota es atributo entero no negativo, default 0; no integra la clave. El panel lo solicita y API normaliza ausencia/null/vacío a 0.
Impacto
Opcionales reciben defaults: textos vacíos, mínimos 0, máximos 99999999.99, opciones false y timeout 180 segundos. En PUT, omitir opcionales aplica defaults. Guardar contenido idéntico no incrementa versión; cambios efectivos de cuota sí la incrementan.
Evidencia
MedioPago, deserializadores y repositorio revisados. API devuelve 400 ante formato o validación inválidos. Script manual V20261014_4__agregar_nro_cuota_medios_pago.sql agrega columna/default/check para instalaciones compatibles existentes.
TsPagos/src/main/java/com/tipre/tspagos/mediospago/MedioPago.java:33 Símbolo: public MedioPago {
14
Caché versionada y publicación tras commit
Implementado en historial revisado
Contexto
Las ediciones deben publicar una vista consistente de filas y metadatos, incluso con varias instancias.
Cambio
Las escrituras usan transacción y bloqueo del estado; actualizan versión sólo ante cambio efectivo. Se publica el snapshot después del commit. Carga y recarga periódica leen únicamente la BD propia. Si la recarga falla, conserva la última vista y marca DESACTUALIZADO; sin vista válida, NO_DISPONIBLE.
Impacto
data2 contiene versionCatalogo, actualizadoEn UTC, estadoCatalogo, ultimoError y zonaHoraria. Otras instancias incorporan cambios al recargar; por defecto cada 60000 ms. Editar tablas sin incrementar versión puede dejar cachés sin actualizar.
Evidencia
MediosPagoService.guardar/recargar y MediosPagoRepository.guardar revisados. Existen pruebas de ABM, repositorio, controlador y servicio; no se ejecutaron en esta revisión.
TsPagos/src/main/java/com/tipre/tspagos/mediospago/MediosPagoService.java:55 Símbolo: public synchronized void recargar
15
PINPAD: identificación de intención y auditoría local
Implementado en historial revisado
Contexto
PINPAD requiere correlación estable aunque el intercambio con el dispositivo ocurra fuera de TsPagos.
Cambio
CREATE_INTENT genera un ID aleatorio positivo menor a 2^53; las operaciones posteriores conservan idProcessorPayment recibido y rechazan ausencia. AuditContext registra operación, request/response, duración y error/cancelación sin inventar un endpoint ni un estado HTTP de gateway.
Impacto
EXECUTE_PAYMENT interpreta datosHost/datosPos y completa estado, autorización, cupón, lote, terminal, plan y datos de tarjeta. Una respuesta de rechazo genera error y no debe tratarse como aprobación. El ID identifica la intención, sin constituir garantía de unicidad de base de datos.
Evidencia
PinpadBuilder, commits bb5e3ca/e34f513 y PinpadAuditTest revisados. Limitación del código actual: combina mapeo exacto de estado con contains("APROBADA"); no se acredita robustez ante mensajes ambiguos o nulos.
TsPagos/src/main/java/com/tipre/tspagos/service/servicebuilder/PinpadBuilder.java:31 Símbolo: public Mono<ResponsePayment> executeOperation
16
PINPAD: conservación del JSON original para voucher
Incluye cambio local sin commit
Contexto
TsTicket necesita el comprobante original APIDRIVER además de los campos normalizados.
Cambio
En ejecución PINPAD, ResponsePayment.customData incorpora el mismo string JSON recibido, sin reserializarlo. Los campos normalizados continúan al mismo nivel y el campo opcional se omite cuando es nulo.
Impacto
Habilita persistencia y generación del voucher TARJETA en TsTicket. No agrega endpoint ni columnas. El frontend debe aceptar tipo TARJETA, imprimir Base64 y tolerar idProcessorPayment opcional antes de activar el flujo completo.
Evidencia
Diff local de PinpadBuilder y ResponsePayment, y caso agregado en PinpadBuilderTest revisados. Cambio aún sin commit. No se probó comunicación real con APIDRIVER ni impresión.
Coordinar POS, TsTicket, TsPagos y TsPromos con códigos numéricos y sin selector mediodepagoid. Planificar cambio sin órdenes abiertas. Revisar exclusiones y no trasladar IDs viejos como códigos.
Pendiente validar en ambiente destino.
Catálogo TsPagos
Instalación nueva: V20261014__crear_medios_pago_local.sql. Para instalaciones compatibles existentes: revisar V20261014_2__orden_unico_procesador_requerido.sql y V20261014_4__agregar_nro_cuota_medios_pago.sql. Son scripts manuales; no convierten automáticamente esquemas anteriores ni tablas legadas.
No se ejecutó DDL ni se inspeccionó BD real.
Padrón TsPromos
Actualizar el SQL realmente configurado en app.promociones-update.scripts.promocion, cuyo default es C:/promociones/update/sql/promocion.sql, con campos de medio/plan/cuota; luego actualizar padrón y caché mediante administración.
Se revisó Docs/sql/PadronPromos_V2.sql; no se verificó instalación externa.
Configuración POS
Tras desplegar, verificar register y configtoclient: catálogo, cuota, habilitados/deshabilitados, orden, exclusiones y estados de disponibilidad.
No se consultaron endpoints en vivo.
PINPAD y comprobante
Para activar voucher TARJETA: adaptar frontend y TsTicket antes de publicar el envío del original desde TsPagos. Probar selección provisional → real con mismo ID, aprobación, rechazo, recuperación de cierre e impresión física.
Implementación local revisada; integración con POS/APIDRIVER e impresora pendiente.
Trazabilidad de entrega
Revisar y versionar los diffs locales antes de armar la entrega. La versión pom 14.10.2026 no distingue por sí sola los cambios aún sin commit.
Documento refleja HEAD más archivos actuales del workspace.
Evidencia y alcance de verificación
Verificado en esta tarea: versiones Maven, historial Git, estado local y diffs, DTOs, controladores, servicios, SQL de referencia, panel HTML/JavaScript y documentación existente. Cada cambio indica archivo y símbolo; las líneas corresponden al workspace revisado, y pueden variar en otra revisión.
Pruebas disponibles: TsPromos: PromoServiceTest y PromoControllerTest (matching, simulación, validación y auditoría). TsTicket: PosCatalogoControllerTest, ConfiguracionMediosPagoServiceTest, MediosPagoHerenciaTest, PagoCatalogoApiClientTest, SimularCuotasControllerTest, SimularCuotasHttpAuditTest, SeleccionPagoTest y VoucherTarjetaTest. TsPagos: MediosPagoAbmTest, MediosPagoRepositoryTest, MediosPagoServiceTest, MediosPagoControllerTest, PinpadBuilderTest y PinpadAuditTest.
Límite de evidencia. No se ejecutaron pruebas Maven ni servicios para elaborar este documento. No se encontraron reportes en las ubicaciones estándar target/surefire-reports de los tres servicios. La existencia de pruebas no implica ejecución satisfactoria. No se certifican SQL Server, deploy, cobros reales, comunicación PINPAD ni impresión física. No se modificó código de los servicios ni base de datos.
Referencias documentales contrastadas: TsPromos/README.md; TsPagos/documentacion/CONFIGURACION_MEDIOS_PAGO.md; TsTicket/documentacion/CONFIGURACION_MEDIOS_PAGO.md; TsTicket/documentacion/INTEGRACION_SIMULAR_CUOTAS.html; TsTicket/documentacion/VOUCHER_TARJETA_PINPAD.md. El código actual prevalece cuando una frase histórica de estas guías quedó desactualizada.