monia

Un solo módulo hace toda la aritmética sobre montos. Un monto es un bigint en las unidades menores de su propia moneda, y la escala sale de una columna currencies.decimals y no de una constante fija: los pesos están configurados a dos decimales acá porque Bancolombia reporta centavos en las líneas de impuestos e intereses. Ningún number de JavaScript toca nunca un monto, ni para parsearlo, ni para convertirlo, ni para formatearlo. El redondeo es medio hacia afuera del cero, así que un débito y un crédito del mismo tamaño redondean igual. Un redondeo asimétrico sesgaría los gastos contra los ingresos.

Hay una pasada de puesta al día para correo nuevo, que es chica y corre a diario, y una caminata de relleno que va hacia atrás en la historia, es grande, y toma días. Toda ruta serverless tiene un tope de duración, así que un bucle del lado del servidor que pasa ese tope muere a medio vuelo y no reporta nada. En cambio cada request está acotado y aterriza su propio trabajo: escribe sus filas y mueve el piso de la historia antes de responder. Una corrida que muere, sea por una pestaña cerrada o por un deploy, pierde a lo sumo el bloque en vuelo. El bucle del navegador lee 800 mensajes por bloque; el cron lee 80.

Dos tablas cargan el estado de importación. Una guarda una fila por mensaje que el importador ha mirado, con el resultado al que llegó y la evidencia que tenía. La otra guarda una fila por usuario con el día más viejo leído hasta ahora. Cuando un usuario agrega una cuenta o una plantilla, la app borra las filas de vistos que ese cambio desbloquea, para que la siguiente importación las lea otra vez. Sin ese paso, el correo que estaba a una cuenta de aterrizar queda marcado como visto para siempre. La trampa: un usuario sin fila de relleno nunca ha caminado hacia atrás, que es el mismo estado que una caminata sin terminar, y le pertenece a la cuenta más nueva, la misma para la que existe el job. La consulta que recoge a ese usuario necesita un LEFT JOIN.

reporting_currency existía como columna, aparecía en la pantalla de ajustes, y nadie la leía. Cada página fijaba la base de almacenamiento, así que un usuario colombiano con 7.749 filas en pesos solo podía ver dólares. El arreglo es una expresión SQL con tres casos, en orden de costo. Si la moneda de reporte es igual a la base de almacenamiento, devuelve la columna congelada sin tocar, para que los números de hoy sean iguales a los de ayer por construcción. Si la fila ya está en la moneda de reporte, devuelve su monto nativo, porque un viaje de ida y vuelta por USD pierde un centavo por fila para nada. Si no, divide por la tasa de la fecha de esa fila, nunca por la de hoy. Un script de verificación después caminó las filas que de verdad necesitaban conversión, comparándolas una por una: cero diferencias en las 184.

El monto base en USD de cada fila se escribe una vez al insertar y nunca se recalcula, así que los totales históricos son estables por construcción, y por eso la moneda base no puede cambiar sin invalidar cada fila guardada. La moneda de reporte por usuario no cuesta nada cambiarla, porque no se guarda nada en ella.

Pregúntale a un modelo de lenguaje cuánto gastaste en comida en marzo y produce una cifra segura, plausible y equivocada. En un libro contable una cifra plausible y equivocada es peor que ninguna respuesta, porque el usuario no la puede distinguir de una correcta. Así que la aplicación calcula cada cifra primero, con las mismas consultas tipadas que usan las pantallas, y le entrega al modelo una hoja de datos; el modelo dice qué cifras responden la pregunta y escribe la frase alrededor. Rechacé tres diseños por escrito antes. SQL crudo para el modelo está a una consulta mal formada de un total equivocado y a un DELETE de algo peor. Las herramientas de consulta son mejores, pero el modelo igual elige la ventana y el filtro, así que igual es dueño del número. La recuperación sobre el texto de las transacciones responde bien "¿pagué X?" y mal "¿cuánto?".

Prefiero entregar una función más angosta que siempre acierta.

Iniciar sesión con Google pide identidad y nada más. gmail.readonly se pide aparte, desde Ajustes, y solo por las cuentas que importan correo. La razón es regulatoria y no ergonómica: es un permiso restringido de Google, y pegarlo al inicio de sesión mete la aplicación entera bajo el régimen de permisos restringidos. Publicar la pantalla de consentimiento exige entonces una evaluación anual CASA Tier 2 de un tercero, y hasta que eso pase Google vence cada refresh token a los siete días, lo que rompe el cron de importación diaria. El costo es un paso extra de consentimiento, que pagan solo los usuarios que lo necesitan.

Un bucle serverless que pasa el tope de duración muere a medio vuelo y no reporta nada, así que a ningún request se le permite depender del siguiente. Cada uno escribe sus filas y mueve el piso de la historia antes de responder, y una conexión caída pierde a lo sumo un bloque. El intercambio es progreso por bloques y más requests, y en esta plataforma la corrida larga nunca estuvo disponible.

Cuando una fila no tiene tasa de cambio la conversión devuelve NULL, y sum() la salta sin decir nada. La app cuenta esas filas y muestra el conteo al lado del total. La alternativa es un número que se ve limpio sobre datos incompletos, que es el tipo de bug que un usuario nunca reporta.