Desincronización en el Cálculo de Ventas: El Impacto del Costo de Envío en TuTiendaWeb

Esta publicación aborda un hallazgo crítico de consistencia de datos identificado durante una auditoría de seguridad de Firebase en el proyecto TuTiendaWeb. Aunque la auditoría se centró en la seguridad, reveló una falla en la lógica de negocio que afectaba directamente la precisión de los registros de ventas, específicamente cómo se maneja la tarifa de envío.

La Situación

Durante una fase de pruebas de integración, se detectó una discrepancia importante en el procesamiento de ventas de TuTiendaWeb. La lógica inicial en buildTrustedSale (ubicada en checkout.service.ts) calculaba el total de una venta incluyendo correctamente el deliveryFee (tarifa de envío), es decir, total = subtotal + deliveryFee. Sin embargo, al momento de persistir la venta a través de createSale (sale.service.ts), el total se recalculaba como total = subtotal - discount, descartando por completo el deliveryFee previamente considerado. Además, el esquema de datos saleTotalsSchema no incluía un campo para deliveryFee, lo que impedía su almacenamiento.

El Problema Detallado

La consecuencia directa de esta desincronización es que, para todos los pedidos con delivery (envío a domicilio), el valor total persistido en la base de datos terminaba siendo subtotal, ignorando el costo de envío. Aunque el cliente y el comercio veían el total correcto (que incluía el envío) en mensajes de confirmación, las estadísticas de ventas calculadas internamente por calculateSalesStats subcontaban el monto real de los ingresos al no considerar los envíos. Curiosamente, este problema no fue capturado por los tests de integración de Fase 2 porque los casos de prueba se centraban en ventas con retiro (retiro en tienda), donde el deliveryFee es cero, enmascarando el error para las entregas a domicilio.

El Hallazgo y su Importancia

Este hallazgo, clasificado como INT-01 con Severidad Media, subraya la importancia de una revisión exhaustiva de la lógica de negocio, incluso en auditorías con un enfoque diferente. Aunque este Pull Request solo documenta el problema en docs/test/60-firebase-security-audit.md sin aplicar una solución inmediata, su registro es crucial para priorizar y abordar la corrección en futuras iteraciones. La decisión sobre si el envío debe o no integrar el total final de la venta y cómo debe reflejarse en el esquema de datos es una discusión clave que deberá resolverse aparte.

La Documentación del Hallazgo

La acción principal de este PR fue la documentación detallada del problema. Aquí un ejemplo conceptual de cómo la discrepancia podría manifestarse en el código:

// Lógica de cálculo en el checkout (ej. buildTrustedSale)
interface SaleDetails { 
  subtotal: number; 
  deliveryFee: number; 
  discount: number; 
}

function calculateInitialTotal(details: SaleDetails): number {
  return details.subtotal + details.deliveryFee - details.discount; 
}

// Lógica de persistencia (ej. createSale)
interface PersistedSaleData {
  subtotal: number; 
  discount: number; 
  total: number; // ¡deliveryFee faltante aquí!
}

function prepareForPersistence(details: SaleDetails): PersistedSaleData {
  return {
    subtotal: details.subtotal,
    discount: details.discount,
    total: details.subtotal - details.discount // ERROR: Descartando deliveryFee
  };
}

Este ejemplo ilustra cómo una función podría calcular un total initialTotal que incluye el costo de envío, mientras que otra, prepareForPersistence, construye un objeto para la base de datos donde este costo se omite involuntariamente del total final. La clave aquí es la falta de consistencia entre los cálculos y la estructura del esquema de datos persistido.

La Lección Técnica (Sí, Hay Una)

La principal lección técnica es la crítica necesidad de alinear la lógica de negocio con el modelo de datos persistido. Un saleTotalsSchema incompleto o una discrepancia en las funciones de cálculo y almacenamiento pueden llevar a datos inconsistentes y a métricas de negocio erróneas. Es como construir una casa con dos planos diferentes: uno para el arquitecto y otro para el constructor; el resultado será un caos estructural. Para sistemas basados en Firebase, donde la flexibilidad de los esquemas es alta, la disciplina en la definición y validación de los datos es aún más importante para mantener la integridad transaccional.

El Aprendizaje Clave

Es fundamental implementar pruebas de integración exhaustivas que cubran todos los flujos de negocio y sus variaciones (por ejemplo, pedidos con envío y sin envío). Además, la validación de esquemas en el momento de la escritura de datos es crucial. Cada campo que influye en los cálculos financieros debe ser persistido y utilizado consistentemente a lo largo de todo el ciclo de vida de la transacción. Documentar estos hallazgos es el primer paso vital para garantizar que la integridad de los datos se mantenga, incluso antes de que se implemente una solución técnica.

Generated with Gitvlg.com