Cargar tu historial

Esta página está escrita sobre todo para el agente de IA que hace la carga. Si eres una persona, basta con que conectes tu agente, adjuntes tu Excel o el informe del proveedor y le digas "Carga estos mantenimientos en zensset con sus fechas".

Un trabajo ya hecho no se registra como una orden en vivo. Si se crea con Ejecutar ahora, entra en la programación de hoy y cuenta en el cumplimiento de esta semana. Además, la fecha de ejecución quedaría como hoy. Para eso existe registrar un trabajo ya hecho, que lo pueden hacer un Propietario, un Administrador o un Encargado (permiso work_order.backdate).

Todas las herramientas de zensset reciben { operation, items: [ ... ] }: un ítem por cosa que leer o cambiar.

1. Las órdenes ya hechas

Herramienta work_order_upsert, operación record_history, un ítem por trabajo:

Campo	Qué es
`asset_id`	El activo, de `asset_query`
`executed_finished_at`	Cuándo se hizo. Obligatorio, no puede ser en el futuro. Una fecha con hora y zona, por ejemplo `2026-09-12T10:00:00-05:00`
`executed_started_at`	Cuándo empezó (opcional)
`procedure_id`	El procedimiento que se hizo. Con él, el plan de mantenimiento lo cuenta como una ejecución
`nature_id`	La naturaleza, de `work_nature_list`; solo si no hay procedimiento
`description`, `observations`	Qué se hizo y la nota de cierre
`consumption`	Lo que se usó: `labor`, `materials`, `services` (como en `consumption_record`) y `note`. Por defecto con la fecha de la ejecución
`close`	`true` para dejarla también revisada y cerrada, con sus costos fijos
`provider_id`	Quién lo hizo, si fue un proveedor externo (de `reference_list_query`, operación `provider`). Queda como "Ejecutada por" y como proveedor de sus servicios

La orden queda Ejecutada, o Cerrada si pediste close. Queda con sus fechas reales y fuera de cualquier programación, y su historial dice que se registró como trabajo ya hecho.

Ejemplo: cinco aires acondicionados mantenidos el 12 de septiembre por un proveedor externo, a $35 cada uno.

{ "operation": "record_history", "items": [
  { "asset_id": "…AC-01…", "procedure_id": "…", "executed_finished_at": "2026-09-12T10:00:00-05:00",
    "description": "Mantenimiento del técnico externo", "provider_id": "…Wilson…",
    "consumption": { "services": [ { "description": "Mantenimiento AC", "cost": 35 } ] },
    "close": true }
] }

Si el proveedor todavía no existe, créalo antes con reference_list_upsert, operación provider: legal_name (obligatorio), trade_name y tax_id (opcionales).

2. El plan de mantenimiento con su historia

Si el plan todavía no existe, créalo con la última ejecución de cada activo (plan_upsert, operación create):

last_executed_on: { "<asset_id>": "2026-09-12", … }. Cada activo cuenta desde su fecha, aunque sean distintas.
schedule_mode: floating ("Desde la última ejecución") o fixed ("Fechas fijas"). Ver Cómo cuenta las fechas.

Si el plan ya existe, el modo Desde la última ejecución cuenta solo desde las órdenes del paso 1. En Fechas fijas, o si la ejecución no quedó como orden, indica la última ejecución de la línea: plan_upsert, operación line_update, con anchor_at y un reason.

3. Si la próxima fecha queda vencida

Con una ejecución antigua, la próxima fecha puede caer antes de hoy. En ese caso line_update falla con The next due date would be in the past, y el detalle trae la fecha. Pregúntale a la persona qué quiere y repite la llamada con past_due:

keep: dejarla vencida. El trabajo está atrasado y la orden se genera ahora.
today: moverla a hoy. Las siguientes fechas cuentan desde hoy.

No elijas por tu cuenta: una orden vencida que nadie esperaba es justo lo que esta pregunta evita.