# 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.

```json
{ "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](/docs/preventive-plans).

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.