Aforos manuales
El aforo manual (/gauging) es la lectura física de un tanque que el operador en turno captura a
mano: el nivel, la temperatura y el agua libre. Una vez aprobado, ese aforo sustituye al
radar en el cálculo —es la lectura "de verdad" que gana sobre la telemetría automática—. Esta página
está orientada al operador: cómo registrar un aforo paso a paso.
El aforo manual es una lectura puntual de inventario. No debe confundirse con:
- el gauging ticket custody-grade (header atómico all-or-none, override de radar persistente), que tiene su propia página — ver Gauging tickets (próximamente, Plan 64-02); ni con
- la muestra de laboratorio, que aporta la densidad y el BSW —propiedades que el aforo manual nunca captura—.
Quién hace qué
| Rol | Crear / enviar (manual:submit) | Aprobar / rechazar (manual:approve) | Anular (manual:void) |
|---|---|---|---|
| Operador | ✓ | – | – |
| Técnico de laboratorio | ✓ | – | – |
| Supervisor | ✓ | ✓ | ✓ |
El operador y el técnico de laboratorio capturan y envían aforos. El supervisor los aprueba o rechaza, y es el único que puede anularlos.
El ciclo de vida en 5 estados
El aforo manual usa una máquina de estados más simple que la de laboratorio: 5 estados. Cada flecha indica la autoridad y la guardia que la protege.
| Estado origen | Acción | Estado destino | Autoridad | Guardia / SoD |
|---|---|---|---|---|
DRAFT | Enviar | SUBMITTED | manual:submit | — |
SUBMITTED | Aprobar | APPROVED | manual:approve | sodGuard: actor ≠ submitter |
SUBMITTED | Rechazar | REJECTED | manual:approve | sodGuard: actor ≠ submitter |
REJECTED | Reenviar | SUBMITTED | manual:submit | submitterOnlyGuard: actor = submitter |
APPROVED | Anular | VOIDED | manual:void | voidActorGuard: rol = supervisor + SoD |
Cualquier otro par (estado, acción) devuelve INVALID_TRANSITION.
Paso a paso
1. Capturar el dip (DRAFT)
Desde el CTA "Nuevo aforo" se abre /gauging/new, sección S1 — Aforo. El operador elige el
tanque y la fecha/hora de lectura (readingTs) y captura el dip:
| Cantidad | Campo | Unidad (almacenamiento SI) |
|---|---|---|
| Nivel | level | mm |
| Temperatura | temperature | °C |
| Agua libre | freeWater | mm |
El almacenamiento es siempre SI, pero el formulario y la lectura pueden mostrarse en imperial (pie · pulgada · fracción para el nivel y el agua libre, °F para la temperatura) según la preferencia de unidades del usuario; la conversión es de presentación y no pierde precisión.
El aforo manual registra solo lo que se mide físicamente en el tanque (nivel, temperatura, agua libre). La densidad y el BSW vienen del laboratorio (MAN-07) — se registran y aprueban en la muestra de laboratorio, no aquí. El formulario lo recuerda explícitamente.
readingTs no puede ser futura. El valor se almacena en unidades SI (mm para nivel y agua libre,
°C para temperatura).
2. Enviar (DRAFT → SUBMITTED)
Al enviar, el aforo pasa a SUBMITTED y entra en la cola de pendientes del supervisor.
3. Cola de pendientes
El supervisor ve los aforos SUBMITTED en su cola de aprobación. Cada acción queda auditada.
4. Aprobar o rechazar (SUBMITTED → APPROVED | REJECTED)
El supervisor aprueba o rechaza el aforo, sujeto a la separación de funciones (ver abajo). Un rechazo puede incluir una razón.
5. Reenviar tras rechazo (REJECTED → SUBMITTED)
Solo el submitter original puede corregir y reenviar un aforo rechazado.
6. Anular (APPROVED → VOIDED)
Un aforo aprobado se anula —vía exclusiva del supervisor, con una razón obligatoria y sujeta a la SoD—. El aforo anulado deja de alimentar el cálculo.
Separación de funciones
Como en el laboratorio, quien captura un aforo no puede aprobarlo ni anularlo:
- Aprobar / rechazar: el actor no puede ser el submitter (
submitterId ≠ approver). - Anular: el anulador no puede ser el submitter (
submitterId ≠ voider), y solo el supervisor puede anular.
La regla se aplica en el servidor antes de la mutación; el UI oculta el botón, pero un llamado directo al endpoint —saltándose el UI— recibe 403.
La cola de aprobación de aforos vive en /gauging/approval y se documenta en Gauging tickets
(próximamente, Plan 64-02).
La lectura sustituye al radar
Esta es la parte que conecta el aforo con el cálculo custody. Una lectura manual APPROVED alimenta el motor de cálculo como entrada — y en la escalera de procedencia del calc engine (Auto → Manual → Lab → Default) la lectura manual gana sobre la automática del radar.
La escalera de procedencia ordena de dónde toma cada valor el motor: primero la lectura automática del radar, pero si existe una lectura manual aprobada para esa cantidad, esa es la que entra al cálculo. Así, cuando el operador afora un tanque a mano y el supervisor lo aprueba, el inventario se calcula con el dip verificado, no con el radar. En el detalle de tanque, la ProvenanceTable muestra qué valor ganó para cada campo —si fue Auto, Manual, Lab o Default—.
Además del aforo puntual (S1), /gauging/new ofrece un formulario separado, S2 — Override de
radar, para registrar lecturas lifecycle:'persistent' que enmascaran un sensor en falla (con un
warning explícito antes de enviar). S1 y S2 nunca se fusionan (D-02). El override persistente se detalla
en Gauging tickets (próximamente, Plan 64-02).
Workspace de aforos
El workspace (/gauging) organiza los aforos en 2 pestañas (pending / approved) y expone el
CTA "Nuevo aforo".
Screenshot pendiente del barrido diferido — ver 61-DEFERRED-SWEEP.md (/gauging workspace pestañas).
Páginas relacionadas
- La densidad y el BSW que el aforo manual no captura provienen de la muestra de laboratorio.
- Para ver qué valor ganó en el cálculo (Auto / Manual / Lab / Default) y la cadena de factores custody, ver el detalle de tanque.
- El gauging ticket custody-grade (header atómico all-or-none, override de radar, cola de aprobación de aforos) se documenta en Gauging tickets (próximamente, Plan 64-02).