67 lines
3.5 KiB
Markdown
67 lines
3.5 KiB
Markdown
# Fase D5.5 · Planificación web y checklist
|
|
|
|
## Objetivo
|
|
|
|
Consolidar la preparación de una visita desde oficina antes de su inicio en campo. La planificación queda anclada a un Área y a una Organización operadora vigente, incorpora antecedentes y próximos controles automáticamente, permite sumar registros preventivos y exige que toda exclusión quede justificada y trazable.
|
|
|
|
## Contexto operativo explícito
|
|
|
|
Cada visita nueva puede guardar `operational_area_id` y `operator_company_id`. La API valida que ambos pertenezcan a tipos con roles `AREA` y `COMPANY` y que exista una relación `OPERATOR` vigente entre ellos. El `scope_asset_id` conserva compatibilidad y, para la planificación D5.5, referencia el Área seleccionada.
|
|
|
|
La web resuelve primero el Área y luego ofrece únicamente las Organizaciones operadoras vigentes de ese Área.
|
|
|
|
## Checklist automático
|
|
|
|
Cada generación se conserva como una fotografía append-only en `inspection_visit_checklist_items`. La generación vigente clasifica los hallazgos del contexto en:
|
|
|
|
- `COMPANY_OVERDUE`: respuesta de empresa vencida.
|
|
- `VERIFICATION_OVERDUE`: control de campo vencido.
|
|
- `UPCOMING_CONTROL`: control previsto dentro de los próximos 30 días desde la fecha planificada.
|
|
- `ANTECEDENT`: antecedente histórico sin acción automática inmediata.
|
|
|
|
Los registros con vencimientos o controles accionables se incorporan automáticamente a la visita. Regenerar no borra generaciones anteriores.
|
|
|
|
Si cambia Área, Operadora o fecha de inicio, el checklist vigente queda marcado como no válido hasta que oficina lo regenere y revise. La confirmación a `PLANNED` no regenera silenciosamente: exige una generación vigente.
|
|
|
|
## Registros preventivos y exclusiones
|
|
|
|
Oficina puede agregar registros del Inventario que pertenezcan al mismo Área y Operadora aunque no tengan un pendiente previo. Esos registros quedan identificados con origen `PREVENTIVE`.
|
|
|
|
Los orígenes disponibles son:
|
|
|
|
- `LEGACY`
|
|
- `AUTOMATIC`
|
|
- `PREVENTIVE`
|
|
- `VERIFICATION`
|
|
|
|
Retirar un registro de la visita requiere una exclusión específica con motivo de al menos 10 caracteres. La proyección vigente se guarda en `inspection_visit_assets`, mientras la historia se agrega a `inspection_visit_asset_events`. Una reincorporación no elimina la exclusión anterior. Un registro excluido tampoco puede reincorporarse por la operación genérica de alta preventiva.
|
|
|
|
## Visitas de verificación
|
|
|
|
Las visitas creadas desde Hallazgos continúan siendo visitas normales, ahora con Área y Operadora explícitas y registros con origen `VERIFICATION`. La planificación debe completar equipo y checklist antes de confirmarse.
|
|
|
|
## Inicio exclusivo desde APK
|
|
|
|
La web crea, configura y confirma la planificación. No expone una acción de inicio. El endpoint de inicio mantiene `assertMobileInspector`, que exige transporte bearer y rol inspector, por lo que el inicio y la ejecución de campo permanecen reservados a la APK.
|
|
|
|
## Trazabilidad
|
|
|
|
D5.5 agrega auditoría de:
|
|
|
|
- generación de checklist;
|
|
- exclusión de un registro;
|
|
- reincorporación de un registro.
|
|
|
|
Las tablas históricas nuevas sólo conceden `SELECT` e `INSERT` al rol de aplicación y revocan `UPDATE` y `DELETE`.
|
|
|
|
## Compatibilidad preservada
|
|
|
|
D5.5 no modifica las reglas consolidadas:
|
|
|
|
- una visita genera una sola Acta;
|
|
- el Acta cerrada no se reescribe;
|
|
- los hallazgos y respuestas históricas permanecen protegidos;
|
|
- las verificaciones sucesivas siguen siendo append-only;
|
|
- el catálogo contextual D5.4.1 continúa validando aplicabilidad y gravedad;
|
|
- SMTP puede seguir pendiente sin bloquear esta fase.
|