Este es un recorrido de producto, no el caso de ninguna operación real: describe cómo se mueve -y dónde se desconecta del artículo 32 de la LFPIORPI- el registro de un abono dentro de TerraWare. La pregunta que resuelve es concreta: ¿en qué paso exacto deja de compararse el valor total de la venta, y sólo se mira el abono que se está cobrando? Según lo visto en TerraWare bloquea el efectivo que rebasa el límite en un solo pago, pero no si se fracciona en abonos.
Esquema del recorrido · ilustración, no es una pantalla del sistema
- 1. Se apartó una unidad y se armó el plan de pagosEl plan guarda el valor total de la venta (
totalCents), el enganche y el calendario de mensualidades. - 2. Alguien registra un abonoEl plan ya está cargado en memoria, con su valor total incluido.
- 3. El sistema evalúa el límite de efectivoCompara el monto de ESE abono contra el umbral -nunca el valor total del plan que ya tiene a la mano.
- 4. Si el abono es pequeño, pasa sin avisoNingún acumulado por operación se consulta en ningún otro punto del código.
- 5. Se repite con cada abono siguienteMismo control, mismo alcance limitado, cada vez.
- 6. La venta se liquida por completo en efectivo, en varios abonosSin que el control del art. 32 se haya activado ni una sola vez.
1-2. El plan ya trae el valor total antes de evaluar el primer abono
recordPayment() carga el plan con findPlanById() antes de tocar cualquier otra cosa -es lo primero que hace la función-, así que plan.totalCents está disponible en la misma ejecución en la que se evalúa el límite de efectivo. No es un dato que haya que ir a buscar a otra tabla o a otro servicio: ya está ahí.
3-6. La comparación se queda en el abono, nunca llega al total
evaluarOperacion() recibe tres datos: la configuración de PLD del tenant, el monto del abono, y el método de pago. No recibe -ni su firma lo contempla- el valor total de la operación. Cada vez que se registra un abono nuevo, la función vuelve a evaluar ese abono de forma aislada, sin memoria de los abonos anteriores del mismo plan ni del valor que falta por liquidar.
| Parada | ¿Compara contra el valor total de la operación? |
|---|---|
1. Carga del plan (findPlanById) | El dato está disponible, pero aún no se usa para esto |
| 2. Carga de configuración PLD | No aplica -sólo trae los umbrales del tenant |
3. evaluarOperacion(pld, amountCents, method) | No -el tercer argumento es el abono, no plan.totalCents |
| 4. Umbral de aviso (si aplica) | Mismo alcance: por abono, no por operación |
| 5-6. Abonos siguientes | Se repite igual, sin acumulado entre pagos |
Puedes estimar la exposición de este hallazgo, con tus propios números, en la calculadora de exposición por efectivo fraccionado LFPIORPI.
Preguntas frecuentes
¿TerraWare no sabe cuánto vale la operación?
Sí lo sabe: el plan de pagos guarda el valor total desde que se crea. Lo que no hace es usar ese dato al evaluar si un abono en efectivo está permitido.
¿El umbral de aviso (art. 17) tiene el mismo problema?
Sí, mismo mecanismo: evaluarOperacion() calcula requiereAviso con el mismo monto de abono aislado, no con el acumulado ni con el valor total.
¿TerraWare corrige esto automáticamente?
No, hoy no. Es un hallazgo verificado en el código actual, no una función ya resuelta.
Ve el recorrido completo en tu propia demo
Te mostramos en vivo el registro de un abono y el control que hoy compara contra el límite de efectivo.
Agenda una demo gratis