Trakey One

Antes de ese punto el reloj corre para el proveedor; después corre para la empresa. Esa división es la que hace que los tiempos signifiquen algo y la primera pregunta a hacerse cuando algo parece trabado.

Después de la primera cotización puede agregar otras, con su nombre, su monto y qué cambia respecto de la anterior. Todas quedan a la vista, con la más baja marcada.

Elegir cuál sirve y aprobar el monto son dos pasos: primero se define la solución técnica, después se firma la plata. Mientras haya más de una opción abierta, el sistema no deja aprobar — obliga a decidir primero.

Con aviso al proveedor. Queda registrado qué se le descartó y por qué monto, que después alimenta las estadísticas.

Acá compiten opciones de un mismo proveedor dentro de un ticket. En los mellizos compiten proveedores distintos, cada uno con su ticket. Las dos cosas pueden pasar a la vez: tres proveedores, y uno de ellos con dos alternativas.

No son una columna del kanban: son una sección aparte donde se ve cuáles están en curso, cuáles ya tienen todas las cotizaciones y están listas para decidir, y cuáles se resolvieron. Con el rango de precios y la diferencia porcentual a la vista.

Las ofertas en columnas: monto, cuánto se aparta cada una de la más baja, detalle, plazo, cuántos días tardó cada proveedor y cuántas consultas hizo.

Cuando todos cotizaron, se elige con cuál seguir. Esa oferta continúa como un ticket normal —le podés consultar algo, pedirle una cotización corregida, delegar la aprobación o aprobarla— y las otras quedan sin efecto con aviso al proveedor. Decidir con quién trabajás y aprobar el monto son dos momentos distintos.

La comparativa marca cuál es la más baja, pero no decide: el detalle y el plazo cambian la ecuación. Lo que se apruebe queda registrado con nombre y apellido.

No son aprobación, así que los puede hacer cualquier interno tenga o no el permiso. Eso es lo que garantiza que nadie quede obligado a delegar algo con lo que no está de acuerdo solo porque no le alcanza el permiso.

Un canal corto entre el interno y el proveedor dentro de cada obra: solicitudes escritas en dos líneas, sin formularios largos.

Se sube desde el mismo lugar y queda pegado a la obra, no a un mail.

Cualquiera de las dos partes abre una incidencia explicando algo. Le llega al otro como notificación.

Los campos quedan editables y se guarda lo confirmado, no lo extraído. Una extracción equivocada que nadie revisó es peor que cargar a mano.

Adjunto a la cotización, a la certificación o a la obra, no en un mail. Después se puede volver a ver de dónde salió cada número.

Se registra qué documento se subió, quién lo subió y qué se extrajo. Si un monto no cierra, se puede reconstruir el origen.

El que emite no responde su propio pedido. Eso es lo que convierte el hilo en un acuerdo entre dos partes y no en un monólogo.

Emitir y responder son acciones dirigidas a una persona concreta, así que la notificación no es configurable: llega siempre.

En la solicitud y en cada respuesta. Una foto del problema ahorra tres mensajes.

La puede marcar cualquiera de los dos, el proveedor o el interno. Es una declaración de que la ejecución terminó, no una aprobación.

El monto no se escribe a mano: sale del monto de la obra. El proveedor pone el porcentaje que está certificando y el sistema calcula. El período se elige con calendario, entre dos fechas. Puede subir el archivo y dejar que la IA complete, o cargar los campos directamente: cualquiera de las dos alcanza.

Solo el interno decide, y tiene tres salidas. El certificado presentado le aparece en "Mis solicitudes" y le llega como notificación, para que no quede esperando en silencio.

Si el proveedor pudiera finalizar la obra, certificaría su propio trabajo. Si solo el interno pudiera declararla concluida, el proveedor quedaría esperando que alguien se acuerde. Cada uno hace lo que le corresponde.

Todo lo que se adjuntó al ticket —de los dos lados, porque tanto el interno como el proveedor pueden adjuntar— pasa a la obra.

El hilo sigue, no se corta. Los comentarios internos siguen siendo internos.

La obra muestra la historia desde el alta del ticket: quién lo creó, qué consultas hubo, quién dio conformidad, quién aprobó, y después todo lo de la ejecución. La pared rige igual: el proveedor ve la historia sin la vida interna de la empresa.

Una urgencia, un contrato marco ya cerrado, un trabajo que viene de antes. Se crea la obra directamente, vinculada a su activo, sin pasar por el circuito de cotización.

Muchas ampliaciones pedidas y muchas consultas necesitadas no son buena señal: significan que ese proveedor cotiza incompleto o no entiende el pedido a la primera. En el cara a cara están marcadas así — menos es mejor.

Un proveedor puede tener tasa de aprobación baja porque le pedís presupuesto para tantear precios. El dato sirve para hacer la pregunta, no para responderla.

Valor de venta original + ampliaciones aprobadas + actualizaciones por índice. La obra muestra el desglose completo de cómo se llegó ahí.

Por activo, por proveedor, por estado, por columna de obra, por interno responsable y por fecha —últimos 7, 30, 90 días, último año, o entre dos fechas elegidas con calendario. Los filtros se combinan y se aplican al dashboard, al kanban y a la planilla por igual.

El administrador ve, para cada persona: cuántos tickets tiene abiertos, cuántas cotizaciones le esperan resolución y por cuánta plata, cuántas consultas tiene sin contestar, su tiempo medio de respuesta y cuál es su pendiente más viejo. Se toca una fila y el tablero entero queda filtrado por esa persona.

Hasta CE mide al proveedor. Desde CE mide a la empresa. Cuánto se pasa en consulta y de qué lado.

Fecha de fin pasada con avance menor al 100%, marcada en la tarjeta.

Se gestionan fuera. Lo único que hace Trakey es cerrar el hilo: al aprobar la certificación ofrece notificar a un interno habilitado para que arranque la solicitud de factura, con la obra, el certificado y el monto. Ese aviso queda en la trazabilidad.

ART, seguros y habilitaciones se controlan en otra plataforma.