Este es un recorrido de producto, no el caso de ningún cliente real: describe qué pasa dentro de FieldOps cuando se cotiza y se registra una refacción en una orden de servicio, sin cifras inventadas ni un negocio en particular. La pregunta que resuelve es simple: si un técnico instala una refacción que no es nueva, ¿el sistema deja constancia de que el cliente lo autorizó, o esa autorización vive sólo en la memoria del técnico?
Esquema del recorrido · ilustración, no es una pantalla del sistema
- 1. Se arma la cotizaciónEl técnico agrega renglones a la cotización de la orden: descripción, cantidad y precio por refacción y mano de obra.
- 2. El cliente aprueba el totalEl cliente recibe el enlace, ve el monto total y lo aprueba en línea (token de aprobación de la cotización).
- 3. El técnico instala lo que haySi la refacción original no está en stock, el técnico decide en el momento usar una usada o reacondicionada.
- 4. ¿Y la autorización?Ni el renglón de la cotización ni la orden registran si esa pieza es nueva, ni una autorización expresa distinta a la aprobación genérica del total.
1. El renglón de la cotización, verificado en el código
En medware-fieldops-mx, la tabla quote_items (migración 1700000050000_quoting.cjs) guarda cada renglón de una cotización con tres columnas de sustancia: description, qty y unit_price_mxn. No hay una columna de condición de la pieza (nueva, usada, reacondicionada) ni de autorización del cliente para usar algo que no sea nuevo. El presupuesto por escrito que exige el art. 59 LFPC sale del sistema con descripción y precio, pero sin ese dato específico.
2. La aprobación del cliente es del total, no de la refacción
El token de aprobación (approval_token, en quoting.service.ts) autoriza la cotización completa: el cliente aprueba un monto, no un renglón. Es exactamente el mecanismo que el negocio necesita para cobrar, pero no es el mismo que exige el art. 60 LFPC: una autorización expresa sobre el punto concreto de usar una refacción que no es nueva. Hoy, ambas cosas son, en el sistema, el mismo clic.
3. La refacción instalada, verificada en el código
El tipo OrderPart (packages/shared-types/src/dispatch.ts), que representa la refacción efectivamente usada en la orden, tiene description, qty, unit, quién la registró y cuándo. Misma ausencia: sin campo de condición, sin campo de autorización. El portal del cliente (services/dispatch/src/portal/portal.service.ts) sí expone la fecha de garantía del trabajo (workWarrantyUntil), pero nada sobre la refacción instalada.
4. Lo que esto le cuesta al negocio
El costo no es teórico: si un cliente presenta una queja en PROFECO por una refacción que resultó no ser nueva, la carga de probar que hubo autorización expresa recae en el negocio (art. 60 LFPC). Sin un campo que capture esa autorización en el momento — no después, reconstruida de memoria —, esa prueba hoy depende de que alguien se haya acordado de dejarlo por escrito fuera del sistema, cotización por cotización.
Preguntas frecuentes
¿FieldOps distingue refacción nueva de usada hoy?
No. Ni quote_items ni OrderPart tienen un campo de condición de la pieza.
¿La aprobación de la cotización cuenta como la autorización que pide la ley?
No exactamente: aprueba el monto total, no una autorización expresa y específica sobre usar una refacción que no es nueva, que es lo que exige el art. 60 LFPC.
¿Dónde queda hoy esa autorización si el técnico la pide de palabra?
Fuera del sistema: no hay ningún campo en la orden de servicio ni en la cotización que la registre.
Fundamento legal completo en refacción usada sin autorización del cliente: la multa PROFECO que nadie ve venir.
Ve el flujo completo en una demo
Te mostramos cómo cotiza y registra refacciones FieldOps hoy y qué parte de la autorización todavía vive fuera del sistema.
Agenda una demo gratis