fix(analytics): parsear las fechas de la API en vez de usar new Date()#5
Open
Asermar wants to merge 1 commit into
Open
fix(analytics): parsear las fechas de la API en vez de usar new Date()#5Asermar wants to merge 1 commit into
Asermar wants to merge 1 commit into
Conversation
La API de FacturaScripts devuelve las fechas con el estilo de FS (por defecto
`d-m-Y`: "04-01-2023", "01-09-2025 10:48:33"), pero los KPI las pasaban por
`new Date()`, que interpreta esa cadena como MM-DD-YYYY. Consecuencia, siempre
en silencio:
- día <= 12: se intercambian mes y día, y el registro cuenta en el mes equivocado
new Date('04-01-2023') -> 1 de ABRIL de 2023
- día > 12: Invalid Date, y el registro DESAPARECE del cálculo
new Date('19-08-2025') -> Invalid Date
Es decir, 19 de cada 31 días se caían de cualquier KPI filtrado o agrupado por
fecha, y el resto se contabilizaba en el mes que no era. Afecta a aging de cobros,
DSO, clientes perdidos, lifetime value, comparativa de periodos y funnel.
Añade `utils/fsDate.ts` con `parseFsDate()`, que entiende `d-m-Y`, `d/m/Y` (el
estilo de fecha es configurable) e ISO, con hora opcional, y valida que la fecha
exista (`31-02` ya no desborda a marzo). Devuelve `Date` para poder sustituir a
`new Date()` en el sitio de llamada sin reestructurar nada.
Se sustituyen las 38 llamadas que parsean valores de la API o entradas del usuario;
se dejan intactas las que construyen la fecha actual o clonan un Date.
Corrige además el cálculo de primera/última compra en get_clientes_lifetime_value,
que comparaba las fechas como CADENAS `d-m-Y` y por tanto ordenaba por día
(31-01-2023 salía posterior a 01-02-2023).
Incluye tests con el runner de Node (`npm test`), sin dependencias nuevas.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problema
Los KPI de
analyticsdescartan o descolocan la mayoría de los registros al filtrar o agrupar por fecha, sin dar ningún error.Causa
La API de FacturaScripts devuelve las fechas con el estilo de FS (por defecto
d-m-Y):"04-01-2023","01-09-2025 10:48:33". Pero los KPI las pasan pornew Date(), que interpreta esa cadena como MM-DD-YYYY:Con día ≤ 12 el registro se contabiliza en el mes equivocado; con día > 12 la comparación es siempre falsa y el registro desaparece del cálculo. Es decir, 19 de cada 31 días se caen de cualquier KPI filtrado por fecha y el resto se cuenta mal.
Afecta a aging de cobros, DSO, clientes perdidos, lifetime value, comparativa de periodos y funnel.
Hay un segundo caso de la misma familia en
get_clientes_lifetime_value: la primera/última compra se calculaban comparando las fechas como cadenasd-m-Y, lo que ordena por día (31-01-2023salía posterior a01-02-2023).Solución
Nuevo
utils/fsDate.tsconparseFsDate(), que entiended-m-Y,d/m/Y(el estilo de fecha es configurable en FS) e ISO, con hora opcional, y valida que la fecha exista (31-02ya no desborda a marzo).Devuelve
Datea propósito, para poder sustituir anew Date()en el sitio de llamada sin reestructurar la lógica. Con entradas no interpretables devuelveInvalid Date, igual que antes, así que no cambia el comportamiento para valores basura.Alcance
38 llamadas sustituidas en
modules/analytics/index.tsykpis-extended.ts: solo las que parsean valores de la API o entradas del usuario. Se dejan intactas las que construyen la fecha actual (new Date()) o clonan unDateexistente, que son correctas.Verificación
Se añade
npm testcon el runner integrado de Node, sin dependencias nuevas. 11 tests sobre el parseo, que es donde el fallo pasaba desapercibido: el formato de la API, días > 12, el separador de barra, ISO, fechas inexistentes y la ordenación cronológica.