Comprender el esquema de la base de datos de informes

BETA: The reporting database is currently in beta and may still evolve. It is available by opt-in only. To join the beta or ask questions, contact support@azumuta.com.

Dónde se almacenan sus datos

La base de datos gestionada de reporting almacena los datos reportables de su espacio de trabajo en un esquema llamado company_<normalized-workspace-id>. El nombre usa letras minúsculas y reemplaza otros caracteres, salvo dígitos, por guiones bajos. Una base de datos personalizada puede usar un nombre de esquema distinto. Use su nombre de esquema configurado en los ejemplos que siguen.

Las tablas principales

Enabling the reporting database sincroniza todas las tablas que aparecen a continuación. No puede seleccionar tablas individuales.

Table	What it holds
workinstruction, workinstruction_version, workinstruction_tag	Instrucciones de trabajo, sus versiones y las etiquetas asignadas. Las versiones incluyen versiones no aprobadas. Use is_approved e is_effective para comprobar el estado de aprobación y la fecha efectiva.
instruction_step	Los pasos individuales dentro de una versión de una Work Instruction.
instruction_visit, instruction_total_visit, instruction_partial_check	Cada vez que un operario recorre un paso, totales por paso y envíos de comprobaciones parciales.
recording, recording_status, recording_variant, recording_step	Grabaciones con una versión de instrucción y su historial de estados, información de la variante seleccionada y datos por paso de la grabación. Pueden incluir auditorías planificadas que no han empezado.
issue, board, issue_column	Incidencias, sus tableros y las columnas de dichos tableros. Incluyen tableros de Mejora Continua, aprobación, Andon y trayectorias de formación. Use issue.board_type para seleccionar un tipo de tablero.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist	Elementos adjuntos a una incidencia.
issue_transition	Historial de movimientos de una incidencia entre columnas del tablero.
product_order, product_order_workinstruction, product_order_workinstruction_spot	Órdenes de producción y las work instructions vinculadas a ellas.
article, article_category	Artículos de producto y sus categorías, no artículos de la base de conocimiento.
tree_node	La estructura del árbol Explore que organiza módulos, carpetas y contenido.
user, user_group, user_group_member	Personas y grupos en su espacio de trabajo.

Grabaciones de auditoría en la base de reporting

La tabla recording incluye únicamente grabaciones con una versión de instrucción numérica. Se excluye una grabación sin versión, incluso cuando su estado es Finished (FINISHED).

La grabación no tiene que estar In progress (IN_PROGRESS) ni Finished para ser incluida. Una descarga offline puede vincular una versión de instrucción mientras el estado permanece Planned (IN_QUEUE). Tras una sincronización exitosa de la base de reporting, esa grabación puede aparecer con estado IN_QUEUE.

Las descargas automáticas dependen del contenido y el rango de fechas seleccionados en el dispositivo. Pueden ocurrir antes de que un operario abra una auditoría. Consulte Device Settings: Offline.

Cerrar una auditoría no iniciada como N/A (NOT_APPLICABLE) no vincula por sí mismo una versión de instrucción. Si la grabación no tiene versión, la base de reporting continúa excluyéndola. El estado por sí solo no explica si una auditoría aparece en la base de datos.

Estado y resultado son distintos

La columna status contiene el valor almacenado, por ejemplo IN_QUEUE, no la etiqueta de visualización Planned. Consulte Status, result, and notes para todas las etiquetas en inglés y los valores almacenados.

La tabla recording_status contiene los cambios de estado. No contiene cambios de resultado.

La columna recording.result almacena el resultado seleccionado, como Success (SUCCESS), Failed (FAILED), N/A (NOT_APPLICABLE) o Cancelled (CANCELLED). Las nuevas grabaciones empiezan con PLANNED. Este valor puede permanecer si no se selecciona resultado. Si la grabación origen no tiene valor de resultado, la columna es NULL. Use status, no result, para identificar el estado de ejecución.

La columna is_failure se calcula a partir de comprobaciones, eventos y retrabajos. Puede ser true debido a:

• Una comprobación fallida o una doble comprobación fallida.
• Un resultado de par de apriete (torque) de NOK.
• Un valor fuera de los límites permitidos.
• Un evento Andon, que indica un problema durante la ejecución.
• Un estado actual o previo de Rework (REWORK).

La columna is_defect usa las mismas comprobaciones pero excluye únicamente el retrabajo. Por ejemplo, un retrabajo sin una comprobación fallida ni evento Andon da is_failure = true e is_defect = false. Un retrabajo previo puede mantener is_failure = true después de que la grabación termine. Consulte Rework para el flujo de trabajo.

Ninguno de estos cálculos usa el resultado seleccionado. Para identificar N/A o Success, use result, no is_failure = false. Una grabación puede tener is_failure = false sin un resultado seleccionado.

Notas de la grabación

La columna recording.notes contiene las notas de la grabación, incluidas las notas introducidas con un resultado. Puede filtrar con notes = 'auto cleanup' para identificar grabaciones con exactamente esa nota. Las notas ausentes o vacías aparecen como NULL.

Filas sincronizadas antes de que se añadieran result y notes aún pueden tener NULL en estas columnas. Una sincronización normal actualiza solo las grabaciones cambiadas. Se necesita una resincornización completa para rellenar estas columnas en grabaciones históricas sin cambios.

Trabajo completado y órdenes cerradas

El estado de la grabación y el estado de la orden de producto describen niveles diferentes de trabajo:

Field and value	Meaning
recording.status = 'FINISHED'	La grabación ha terminado. Compruebe result por separado.
product_order.enhanced_status = 'all-complete' (All complete)	La orden activa cumple las condiciones calculadas de finalización. Estas consideran sus work instructions, cantidades y órdenes hijas no archivadas.
product_order.enhanced_status = 'finished' (Finished)	La orden ha sido cerrada.

Una orden puede permanecer In progress cuando sus grabaciones han finalizado pero la cantidad completada no coincide con la cantidad requerida. Una orden activa sin work instructions ni órdenes hijas es All complete. Consulte Product-order status.

Force-finishing an order cancela sus grabaciones no finalizadas. Esas grabaciones reciben estado FINISHED y resultado CANCELLED. Por tanto, el cierre no demuestra ejecución exitosa. product_order.finished_at registra el cierre de la orden, no necesariamente el momento en que se completó todo el trabajo.

product_order.activated_at registra cuándo se activó la orden por primera vez. Es NULL para una orden que nunca se activó, y para una orden activada antes de que Azumuta registrase tiempos de activación. No se deriva de execution_date, que es una fecha planificada. Las órdenes que ya se sincronizaron antes de que existiera esta columna solo reciben un valor cuando cambian. Para rellenarla para todas las órdenes existentes, pida al soporte de Azumuta que borre sus datos de reporting para que la próxima sincronización los reconstruya.

Asociaciones de zona y asignación

product_order_workinstruction_spot relaciona cada elemento de la orden con sus zonas. El zone_type identifica la fuente:

• assigned: una zona asignada al elemento de la orden.
• accessed: una zona registrada durante la actividad del operario, salvo que la misma zona ya esté assigned.
• associated: una zona por colocación de la work instruction, usada solo cuando el elemento no tiene zonas asignadas ni accesadas.

La tabla combina zonas asignadas y accesadas. Mantiene una fila por elemento y zona, con assigned teniendo prioridad. Una asignación bloqueada no es un tipo SQL de zona separado.

Por ejemplo, un elemento está asignado a A, se accede en A y B, y tiene colocación predeterminada C. Las filas son assigned A y accessed B, sin C. Un filtro por zone_type = 'accessed' por tanto no detecta el acceso en A.

La colocación de reserva utiliza el nodo padre directo de la work instruction cuando ese nodo es una zona. No busca en ancestros arbitrarios.

Las asignaciones pueden cambiar. Los campos assigned_spot_id describen la asignación, no una ubicación de ejecución inmutable. La tabla de asociación no es un historial de asignaciones. Sus reglas tampoco coinciden con todos los widgets incorporados. Consulte Zone filtering for product-order widgets para la configuración de widgets.

Unir a nivel de elemento de orden

Para contar trabajo planificado, empiece desde product_order_workinstruction. Si necesita detalles de grabación, use una left join desde su recording_id hasta recording.id. Esto conserva elementos sin una fila de reporting para una grabación.

Una las zonas a través de product_order_workinstruction_spot.product_order_workinstruction_id = product_order_workinstruction.id. No haga join solo por workinstruction_id: varios elementos de orden pueden usar la misma work instruction.

Múltiples zonas o visitas pueden duplicar la cantidad de un elemento o la duración de una grabación en un resultado con joins. Use EXISTS para un filtro de asociación, o agregue cada origen antes de unir. Consulte Count order items associated with a zone.

Usuarios planificados y operarios reales

recording.planned_user_id y planned_group_id describen la asignación. No identifican a todas las personas que realizaron el trabajo. instruction_visit.user_id identifica al operario de esa visita.

Varios operarios pueden contribuir a una misma grabación. Cuente IDs de grabación distintos por cada operario, no las filas de visita. Una grabación compartida contará entonces para cada operario que contribuyó. Consulte Recordings para el flujo de informes y the operator query para este cálculo.

Visitas, intentos y pasos aplicables

• instruction_visit tiene una fila cuando un operario abandona un paso. Una visita aún abierta puede no tener fila todavía.
• type = 'normal' y type = 'double-check' son grupos de visita separados. is_last_visit marca la última visita dentro de su grupo, no necesariamente la última visita con una respuesta. Consulte Double-checks.
• Una comprobación bloqueada o inválida cuenta como un intento pero no suministra una respuesta aceptada. instruction_total_visit.answer_attempts cuenta visitas con un intento tras el abandono del operario, no pulsaciones de botón individuales.
• instruction_total_visit contiene totales y la respuesta final registrada para cada grabación, paso y tipo de visita. Una respuesta registrada no es necesariamente una respuesta correcta.
• recording_step.active = false significa que las variantes excluyen el paso. No se espera una visita. Las grabaciones antiguas sin selección de variante almacenada tratan todos los pasos como activos. Consulte Variants y variant configuration.

Los datos faltantes por sí solos no prueban fallo. Compruebe la aplicabilidad, el estado de la grabación y si el paso requiere una respuesta. Consulte Compare applicable steps with recorded answers.

Contexto de versión y parámetros

Una join de recording.workinstruction_version_id a workinstruction_version.id permite leer la versión vinculada a la grabación. No use la versión actual de la work instruction para interpretar pasos históricos. La aprobación es una propiedad separada; consulte Revision History.

Para grabaciones de órdenes de producto, lea parámetros desde product_order.parameters a través de recording.product_order_id. Otros parámetros de grabación pueden estar en recording.parameters. Consulte Product-order parameters e Introduction to parameters para saber qué es un parámetro.

Los campos JSON pueden contener listas u objetos anidados, no solo números o texto. Compruebe el tipo de cada valor antes de convertirlo. Un NULL en SQL indica datos ausentes, no cero ni una respuesta fallida.

Convenciones usadas en todo el documento

• Primary keys. Cada tabla tiene una clave primaria de texto llamada id. Esto identifica un registro origen o una fila generada. Las columnas relacionadas usan nombres como recording_id y workinstruction_id. Por ejemplo, haga join de recording.workinstruction_id a workinstruction.id.
• Deletions. Cuando una sincronización detecta un registro origen eliminado, elimina las filas de reporting correspondientes. Las definiciones actuales de tablas no incluyen deleted_at. Bases de datos antiguas pueden conservar esta columna porque las actualizaciones de esquema no eliminan columnas antiguas. La sincronización actual no la mantiene; no la use como indicador de eliminación actual. Los registros archivados son diferentes de los eliminados. Por ejemplo, issue.archived_at identifica incidencias archivadas.
• Sync timestamps. Cada tabla tiene first_synced_at y last_synced_at. Registran la primera y la sincronización más reciente que escribió la fila, no el momento de creación o modificación del registro origen.
• Source timestamps. Columnas como created_at, updated_at y started_at dependen de la tabla. PostgreSQL almacena estas marcas temporales como instantes en UTC y las muestra en la zona horaria de la sesión.
• Recording durations. recording.actual_duration y recording.rework_time están en segundos y pueden contener fracciones. No las divida por 1000. Consulte la descripción de la columna para la unidad de otros campos.
• Flexible fields use JSON. Datos que varían en forma (como parameters o una answer de instrucción) se almacenan como jsonb, que puede consultar con los operadores JSON de PostgreSQL.
• Pre-computed values. Para evitar joins adicionales, algunas tablas incluyen cuentas y métricas ya calculadas, por ejemplo issue.comment_count, issue.open_task_count o recording.rework_time.

El diccionario de datos incorporado

Cada tabla y cada columna tiene una descripción legible por humanos adjunta. La mayoría de clientes SQL y herramientas BI las muestran automáticamente. Por ejemplo, en psql:

\d+ "company_<your-workspace-id>".issue

También puede leerlas con una consulta:

select column_name, col_description(
    ('company_<your-workspace-id>.issue')::regclass,
    ordinal_position
) as description
from information_schema.columns
where table_schema = 'company_<your-workspace-id>'
  and table_name = 'issue'
order by ordinal_position;

¿Listo para consultar? Consulte Example Analytics Queries.