La cotización no termina cuando se paga.

Mariana escribe por WhatsApp: «quiero 500 libretas con mi logo». Hoy eso va a un papel. Pedro lo dijo sin rodeos: «me llamaron cinco personas, tú lo anotas en un papel de momento». La propuesta de búsquedas ya decidió dónde nace la fila —del mensaje, con sourceMessageId— y quién la trabaja —assignedAgentId, validado por permiso. Lo que faltaba es qué se escribe en la tarjeta, y eso lo dictó Pedro en la reunión, campo por campo.

La búsqueda cuesta 100 dólares. Es un servicio: ubicar el producto con tres proveedores y comparar precio, calidad y tiempo. Hoy ese cobro no tiene forma: «ahorita los pagos simplemente son un campo abierto, él va pagando lo que le da la gana». Y como no tiene forma, no se puede contar: ni cuántos pagaron, ni cuántos desaparecieron cuando supieron que se cobraba.

La búsqueda nace con su cotización. Al pulsar «Crear y cobrar», la plataforma crea la búsqueda con una sola línea —«Búsqueda de productos», USD 100, o 200 o 300: el monto se edita antes de crear— y le manda a Mariana un mensaje con el enlace de pago. Nada de esto se inventa: el tablero ya tiene la acción «Cobrar», que genera un enlace firmado por lo que falta pagar y lo entrega por WhatsApp. Lo que cambia es que se dispara sola al crear, en vez de esperar a que alguien se acuerde.

La condición sin la cual «Cobrar» cobraría cero

Aquí está el «monto total cero» que Pedro vio en pantalla, y no es un dato migrado mal: es una regla. La cotización deriva su propio total solo de los productos y sus opciones; una búsqueda recién creada no tiene productos con precio, así que su total es cero aunque la factura tenga la línea de 100. Las dos cifras divergen a propósito, y el código lo documenta. Para que «Cobrar» genere un enlace de 100 y no de cero, el total de una búsqueda tiene que leerse de la factura, que es la que tiene la línea. Es un cambio de lectura, no de modelo — y arregla de paso el cero de las migradas, por la misma razón.

recalculateTotals · service-quotes.service.ts:3007-3046 · divergencia declarada en :2771-2775

Aquí estaba la confusión de la reunión, y se resolvió en la reunión. Pedro venía pensando la gestión de compra como un caso dentro de la búsqueda: «yo pensaba que era dentro de búsqueda de productos, había algunos que eran gestiones de compra». David lo separó: la búsqueda es abrir la vaina y cuesta 100; la gestión es lo que viene después. Son dos documentos distintos para el mismo cliente, y el esquema ya lo sabía: ServiceQuoteTypeEnum tiene los dos valores desde hace meses.

Mariana paga los 100 por Zelle. Hoy Pedro se entera porque Jesús le avisa: «yo sé que ya pagó, ya lo notificó Jesús». Y el tablero no se mueve, porque nadie volvió a escribirle. La propuesta de búsquedas ya dijo que el estatus se lee, no se marca: es cruzar el estado del trato con el del cobro. Lo que se agrega aquí es qué pasa en ese cruce.

El salto no es un cron ni un servicio nuevo: es una condición sobre dos columnas que la lista ya devuelve juntas, status y paymentStatus. La pieza de búsquedas lo demostró para «En seguimiento»; aquí es la misma regla con otro par de valores.

La cotización de la compra se pagó. El proveedor termina la producción y los tubos pesan más: se venden por peso, y el sobrante se manda y se cobra. El flete doméstico, en cambio, salió más barato. Pedro necesita tocar dos líneas de una cotización pagada, y hoy no puede: «hay que hacer lo que dijo David de yo poder modificar los precios después». Lo resolvió con un descuento de 40 dólares. Funciona, y miente: el documento dice «descuento» donde hubo un ajuste de peso y uno de flete.

Propuesto · corregir, no descontar

El camino ya está abierto; lo que falta es que exista en todas y que deje rastro. Se corrige el precio del proveedor elegido y el monto del flete doméstico, y la línea se recalcula sola, como ya lo hace. Se agregan tres cosas: que las migradas tengan ese proveedor, que cada corrección deje bitácora, y que la diferencia contra lo pagado se vuelva saldo —a favor o por cobrar— en vez de un descuento inventado.

Pedro escribe las especificaciones dentro del nombre del producto «para que pueda salir aquí». La columna existe —y se esconde sola cuando ninguna línea trae specs, que es siempre en una migrada, porque no hay producto del que leerlas—. Y los pagos salen con método, fecha y monto, sin la referencia, así que cuando un Zelle llega a nombre de otro no hay cómo casarlo con el documento. Es una columna que se destapa, un dato que se imprime, y una cabecera más compacta, con el cuadro a la derecha, que Pedro pidió y llamó estética — y tiene razón: es lo primero que ve el cliente.

Pedro lo dijo con números inventados y con la pregunta exacta: «una estadística de 100 clientes que pagaron la búsqueda, 80 le dieron play, los otros 20 no». Nada de esto se puede contar hoy porque las dos cotizaciones tienen el mismo tipo y no se apuntan entre sí. Con el tipo bien puesto, la marca de exonerada y searchQuoteId, el embudo es una consulta sobre columnas que ya existen.