Hay dos problemas

1. Agrupación de datos diarios y mensuales

Dependiendo de la fecha/hora de la transacción, al trabajar con UTC se puede clasificar es un día/mes u otro. Conciderar el siguiente caso diario.

Webhook tx

Esto es lo que llega del webhook.

{
  "date": "18/10/2025",
  "time": "00:04:01",
  "transTimeZone": "Europe/Paris",
  "datetime": "2025-10-18T00:04:01+02:00", 
}

Transaction

Esto es lo que guardamos nosotros en la transacción.

{
  "date": "18/10/2025",
  "time": "00:04:01",
  "transTimeZone": "Europe/Paris",
  "datetime": "2025-10-17T22:04:01.000Z", 
}

Daily record

Al tomar la transacción y clasificarla esto es lo que terminamos guardando como registro diario. Los 4 valores se toman usando la fecha/hora UTC, lo cual es correcto, sin embargo desde el punto de vista de los intereses de la agrupación, la agrupación falla. La transaccion es del 18 de OCT pero en Europe/Madrid, en UTC es del 17. Por ende, el regsitro diario del 18 no incluye esta transacción.

{
  /* dateTime = startOfDay of the transaction in UTC */
  "dateTime": "2025-10-17T00:00:00.000+00:00",
  "year": 2025,
  "month": "oct",
  "day": 17
}

2. Zona horaria local

Como ya sabemos la zona horario en los servidores es UTC (+00:00). Sin embargo, mi computadora (donde trabajo) no es un servidor y la zona horaria es Madrid. Esta zona horaria afecta al servidor cuando lo corro localmente. En principio esto no es un problema perce, sin embargo en procegur se ha requerido ejecutar scripts y esos scripts han corrido localmente consumiendo la base de datos de producción. Ahora que lo confirme, es sin duda un punto de entradas donde dependiendo de la fecha de la transaccion manipulada, se pudo haber introducido errores de totales adicionales.

Solución para mi (Si tienen otra propuesta es bienvenida)

El total por hora es el unico que se salva del problema anterior (#1). Al tener una agrupación por hora, se pueden crear los grupos horarios sin problema (es la unidad minima de agrupación y no hay cabida para agrupar mal).

Propongo quedarnos con este total unicamente, y los totales diarios y mensuales heredaran los resultados que tenemos por hora.

Que hay que hacer.

Hay que actualizar los endpoints: /invoiced, /invoiced/totals y /invoiced/daily para que desde ahora usen los totales por hora para generar totales de mayor escala. Esto se logrará con agrupaciones a nivel de base de datos lo cual es lo más rápido y eficiente.
Todos los endpoints usados en el dashboard/home deben incluir el Timezone, ya que es necesario aplicar el mismo proceso de agrupación por timezone que ya se hizo para /hourly y /daily y así poder agrupar correctamente basado en la nececidad del frontend.
Los calculos perse que tenemos en backend estan bien (la manera que tenemos de sumar, calcular promedios, etc). Sin embargo, tenemos que re calcular los totales por hora nuevamente ya que como dije en el problema dos, hemos introducido fallos de calculos al ejecutar scripts localmente. El orden que propongo es procesar las transacciones de la más reciente a la más nueva, de esa manera los totales que primero tenemos arreglados son los más recientes.

Desarrollo y ejecución

Actualizar endpoints en backend
Script para calcular totales diarios (ejecutado en el servidor, no local) con el sistema cronjob y poder configurar su ejecución recursiva hasta que termine.
Despliegue en staging ejecutar el script (Se deberia intentar copiar la data de un merchant desde prod a staging para probar con datos reales en staging).
Correcciones de ser necesarias.
Despliegue en producción y ejecución de script.

Estimo que todo el proceso puede demorar entre 5 y 10 días (Pausando V2).

V2

Recomiendo atender esto antes de lanzar V2, ya que los totales de V2 estan basados en lo que tenemos ahora. Adicionalmente al hacer este cambio o cualquier otro que propongan sobre los totales, muy probablemente implique actualizar el modulo de multi merchant al rededor de los totales.

Luiyit/prosegur-pay-invoiced.md