Comprendre le schéma de la base de données de reporting

BETA : La base de données de reporting est actuellement en bêta et peut encore évoluer. Elle est disponible uniquement sur inscription. Pour rejoindre la bêta ou poser des questions, contactez support@azumuta.com.

Où vivent vos données

La base de données de reporting gérée stocke les données déclarables de votre espace de travail dans un schéma nommé company_<normalized-workspace-id>. Le nom utilise des lettres minuscules et remplace les autres caractères, sauf les chiffres, par des underscores. Une base de données personnalisée peut utiliser un nom de schéma différent. Utilisez votre nom de schéma configuré dans les exemples ci-dessous.

Les tables principales

Activer la base de données de reporting synchronise toutes les tables ci-dessous. Vous ne pouvez pas sélectionner des tables individuelles.

Table	Ce qu'elle contient
workinstruction, workinstruction_version, workinstruction_tag	Instructions de travail, leurs versions et les étiquettes qui leur sont assignées. Les versions incluent les versions non approuvées. Utilisez is_approved et is_effective pour vérifier l'état d'approbation et la date effective.
instruction_step	Les étapes individuelles d'une version d'instruction de travail.
instruction_visit, instruction_total_visit, instruction_partial_check	Chaque fois qu'un opérateur parcourt une étape, les totaux par étape et les soumissions de contrôles partiels.
recording, recording_status, recording_variant, recording_step	Enregistrements liés à une version d'instruction et leur historique de statut, informations sur la variante sélectionnée et données par étape. Ils peuvent inclure des audits planifiés qui n'ont pas démarré.
issue, board, issue_column	Problèmes, leurs tableaux et les colonnes de tableau. Cela inclut les tableaux d'amélioration continue, d'approbation, Andon et de trajectoire de formation. Utilisez issue.board_type pour sélectionner un type de tableau.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist	Éléments attachés à un problème.
issue_transition	L'historique des déplacements d'un problème entre les colonnes du tableau.
product_order, product_order_workinstruction, product_order_workinstruction_spot	Ordres de production et les instructions de travail qui leur sont liées.
article, article_category	Articles produits et leurs catégories, pas les articles de la base de connaissances.
tree_node	La structure de l'arborescence Explore qui organise modules, dossiers et contenu.
user, user_group, user_group_member	Personnes et groupes de votre espace de travail.

Enregistrements d'audit dans la base de reporting

La table recording inclut uniquement les enregistrements avec une version d'instruction numérique. Un enregistrement sans version est exclu, même lorsque son statut est Finished (FINISHED).

L'enregistrement n'a pas besoin d'être In progress (IN_PROGRESS) ou Finished pour être inclus. Un téléchargement hors ligne peut lier une version d'instruction alors que le statut reste Planned (IN_QUEUE). Après une synchronisation réussie de la base de reporting, cet enregistrement peut apparaître avec le statut IN_QUEUE.

Les téléchargements automatiques dépendent du contenu sélectionné sur l'appareil et de la plage de dates. Ils peuvent se produire avant qu'un opérateur n'ouvre un audit. Voir Paramètres de l'appareil : Hors ligne.

Clore un audit non démarré comme N/A (NOT_APPLICABLE) ne lie pas en soi une version d'instruction. Si l'enregistrement n'a pas de version, la base de reporting continue de l'exclure. Le statut seul n'explique pas si un audit apparaît dans la base de données.

Statut et résultat sont différents

La colonne status contient la valeur stockée, comme IN_QUEUE, et non le libellé d'affichage Planned. Voir Status, result, and notes pour tous les libellés anglais et les valeurs stockées.

La table recording_status contient les changements de statut. Elle ne contient pas les changements de résultat.

La colonne recording.result stocke le résultat sélectionné, comme Success (SUCCESS), Failed (FAILED), N/A (NOT_APPLICABLE) ou Cancelled (CANCELLED). Les nouveaux enregistrements démarrent avec PLANNED. Cette valeur peut rester si aucun résultat n'est sélectionné. Si l'enregistrement source n'a pas de valeur de résultat, la colonne est NULL. Utilisez status, pas result, pour identifier l'état d'exécution.

La colonne is_failure est calculée à partir des contrôles, événements et retouches. Elle peut être true en raison de :

• Un contrôle ou une double-vérification échouée.
• Un résultat de couple (torque) égal à NOK.
• Une valeur en dehors des limites autorisées.
• Un événement Andon, qui signale un problème durant l'exécution.
• Un statut Rework (REWORK) actuel ou précédent.

La colonne is_defect utilise les mêmes contrôles mais exclut la retouche seule. Par exemple, une retouche sans contrôle échoué ni événement Andon donne is_failure = true et is_defect = false. Une retouche précédente peut maintenir is_failure = true après la fin de l'enregistrement. Voir Rework pour le workflow.

Aucun de ces calculs n'utilise le résultat sélectionné. Pour identifier N/A ou Success, utilisez result, pas is_failure = false. Un enregistrement peut avoir is_failure = false sans résultat sélectionné.

Notes de l'enregistrement

La colonne recording.notes contient les notes de l'enregistrement, y compris les notes saisies avec un résultat. Vous pouvez filtrer sur notes = 'auto cleanup' pour identifier les enregistrements avec cette note exacte. Les notes manquantes ou vides apparaissent comme NULL.

Les lignes synchronisées avant l'ajout des colonnes result et notes peuvent encore avoir NULL dans ces colonnes. Une synchronisation normale met à jour uniquement les enregistrements modifiés. Une resynchronisation complète est nécessaire pour remplir ces colonnes pour des enregistrements historiques inchangés.

Travail effectué et ordres clos

Le statut d'enregistrement et le statut de l'ordre de production décrivent des niveaux de travail différents :

Champ et valeur	Signification
recording.status = 'FINISHED'	L'enregistrement est terminé. Vérifiez result séparément.
product_order.enhanced_status = 'all-complete' (All complete)	L'ordre actif répond aux conditions de complétion calculées. Celles-ci tiennent compte de ses instructions de travail, quantités et ordres enfants non archivés.
product_order.enhanced_status = 'finished' (Finished)	L'ordre a été clos.

Un ordre peut rester In progress lorsque ses enregistrements sont terminés mais que sa quantité complétée ne correspond pas à sa quantité requise. Un ordre actif sans instructions de travail ni ordres enfants est All complete. Voir Product-order status.

Forcer la finalisation d'un ordre annule ses enregistrements inachevés. Ces enregistrements reçoivent le statut FINISHED et le résultat CANCELLED. Ainsi, la clôture n'est pas une preuve d'exécution réussie. product_order.finished_at enregistre la fermeture de l'ordre, pas nécessairement le moment où tout le travail a été accompli.

product_order.activated_at enregistre le moment où l'ordre a été activé pour la première fois. Il est NULL pour un ordre qui n'a jamais été activé, et pour un ordre activé avant qu'Azumuta n'enregistre les heures d'activation. Il n'est pas dérivé de execution_date, qui est une date planifiée. Les ordres déjà synchronisés avant l'existence de cette colonne ne reçoivent une valeur que lorsqu'ils changent. Pour la remplir pour tous les ordres existants, demandez au support Azumuta de purger vos données de reporting afin que la prochaine synchronisation les reconstruise.

Associations de zones et affectation

product_order_workinstruction_spot relie chaque article d'ordre à ses zones. Le zone_type identifie la source :

• assigned : une zone assignée à l'article de l'ordre.
• accessed : une zone enregistrée lors de l'activité de l'opérateur, sauf si la même zone est déjà assigned.
• associated : une zone provenant du placement de l'instruction de travail, utilisée uniquement lorsque l'article n'a pas de zones assignées ou accédées.

La table combine les zones assignées et accédées. Elle conserve une ligne par article et zone, assigned ayant la priorité. Une affectation verrouillée n'est pas un type SQL de zone distinct.

Par exemple, un article est assigné à A, accédé à A et B, et a un placement par défaut C. Les lignes sont assigned A et accessed B, sans C. Un filtre sur zone_type = 'accessed' manque donc l'accès à A.

Le placement de secours utilise le nœud parent direct de l'instruction de travail lorsque ce nœud est une zone. Il ne parcourt pas des ancêtres arbitraires.

Les affectations peuvent changer. Les champs assigned_spot_id décrivent l'affectation, pas un lieu d'exécution immuable. La table d'association n'est pas un historique des affectations. Ses règles ne correspondent pas non plus à tous les widgets intégrés. Voir Filtrage par zone pour les widgets d'ordre de production pour la configuration des widgets.

Jointure au niveau de l'article d'ordre

Pour compter le travail planifié, partez de product_order_workinstruction. Si vous avez besoin des détails d'enregistrement, utilisez une jointure gauche depuis son recording_id vers recording.id. Cela conserve les articles sans ligne d'enregistrement dans le reporting.

Joignez les zones via product_order_workinstruction_spot.product_order_workinstruction_id = product_order_workinstruction.id. Ne joignez pas uniquement par workinstruction_id : plusieurs articles d'ordre peuvent utiliser la même instruction de travail.

Des zones ou visites multiples peuvent faire répéter la quantité d'un article ou la durée d'un enregistrement dans un résultat joint. Utilisez EXISTS pour un filtre d'association, ou agrégerez chaque source avant de joindre. Voir Compter les articles d'ordre associés à une zone.

Utilisateurs planifiés et opérateurs réels

recording.planned_user_id et planned_group_id décrivent l'affectation. Ils n'identifient pas toutes les personnes ayant réalisé le travail. instruction_visit.user_id identifie l'opérateur pour cette visite.

Plusieurs opérateurs peuvent contribuer à un enregistrement. Comptez les identifiants d'enregistrement distincts pour chaque opérateur, pas les lignes de visite. Un enregistrement partagé compte ainsi pour chaque opérateur contributeur. Voir Recordings pour le workflow de reporting et la requête opérateur pour ce calcul.

Visites, tentatives et étapes applicables

• instruction_visit a une ligne lorsqu'un opérateur quitte une étape. Une visite encore ouverte peut ne pas avoir de ligne.
• type = 'normal' et type = 'double-check' sont des groupes de visite séparés. is_last_visit marque la dernière visite au sein de son groupe, pas nécessairement la dernière visite avec une réponse. Voir Double-checks.
• Un contrôle bloqué ou invalide compte comme une tentative mais ne fournit pas de réponse acceptée. instruction_total_visit.answer_attempts compte les visites avec une tentative après que l'opérateur soit parti, pas les pressions de bouton individuelles.
• instruction_total_visit contient des totaux et la réponse finale enregistrée pour chaque enregistrement, étape et type de visite. Une réponse enregistrée n'est pas nécessairement une réponse réussie.
• recording_step.active = false signifie que les variantes excluent l'étape. Aucune visite n'est attendue. Les anciens enregistrements sans sélection de variante stockée traitent toutes les étapes comme actives. Voir Variants et configuration de variante.

Les données manquantes seules ne prouvent pas un échec. Vérifiez l'applicabilité, le statut de l'enregistrement et si l'étape exige une réponse. Voir Comparer les étapes applicables avec les réponses enregistrées.

Contexte de version et de paramètres

Joignez recording.workinstruction_version_id à workinstruction_version.id pour lire la version liée à l'enregistrement. N'utilisez pas la version courante de l'instruction de travail pour interpréter des étapes historiques. L'approbation est une propriété séparée ; voir Historique des révisions.

Pour les enregistrements d'ordre de production, lisez les paramètres dans product_order.parameters via recording.product_order_id. D'autres paramètres d'enregistrement peuvent se trouver dans recording.parameters. Voir Paramètres d'ordre de production et Introduction aux paramètres pour savoir ce qu'est un paramètre.

Les champs JSON peuvent contenir des listes ou des objets imbriqués, pas seulement des nombres ou du texte. Vérifiez le type de chaque valeur avant de la convertir. Un NULL SQL indique des données manquantes, pas zéro ni une réponse échouée.

Conventions utilisées partout

• Clés primaires. Chaque table a une clé primaire texte nommée id. Celle-ci identifie un enregistrement source ou une ligne générée. Les colonnes associées utilisent des noms tels que recording_id et workinstruction_id. Par exemple, joignez recording.workinstruction_id à workinstruction.id.
• Suppressions. Lorsqu'une synchro détecte un enregistrement source supprimé, elle supprime les lignes de reporting correspondantes. Les définitions de table actuelles n'incluent pas deleted_at. Les bases de données plus anciennes peuvent conserver cette colonne car les mises à jour de schéma ne suppriment pas les anciennes colonnes. La synchro actuelle ne la maintient pas ; ne l'utilisez pas comme indicateur de suppression actuel. Les enregistrements archivés sont différents des enregistrements supprimés. Par exemple, issue.archived_at identifie les problèmes archivés.
• Horodatages de synchro. Chaque table a first_synced_at et last_synced_at. Ceux-ci enregistrent la première et la plus récente synchro qui a écrit la ligne, pas la date de création ou de modification de l'enregistrement source.
• Horodatages source. Des colonnes telles que created_at, updated_at et started_at dépendent de la table. PostgreSQL stocke ces horodatages comme des instants en UTC et les affiche dans le fuseau horaire de la session.
• Durées d'enregistrement. recording.actual_duration et recording.rework_time sont en secondes et peuvent contenir des fractions. Ne les divisez pas par 1000. Consultez la description de colonne pour l'unité des autres champs.
• Champs flexibles utilisent JSON. Les données dont la forme varie (comme parameters ou la answer d'une instruction) sont stockées en jsonb, que vous pouvez interroger avec les opérateurs JSON de PostgreSQL.
• Valeurs pré-calculées. Pour vous éviter des jointures supplémentaires, certaines tables incluent des comptes et métriques prêts à l'emploi, par exemple issue.comment_count, issue.open_task_count ou recording.rework_time.

Le dictionnaire de données intégré

Chaque table et chaque colonne a une description lisible par l'humain attachée. La plupart des clients SQL et outils BI les affichent automatiquement. Par exemple, dans psql :

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

Vous pouvez aussi les lire avec une requête :

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;

Prêt à interroger ? Voir Exemples de requêtes analytiques.