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ù résident vos données

La base de données de reporting gérée stocke les données reportables 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 le 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	Contenu
workinstruction, workinstruction_version, workinstruction_tag	Instructions de travail, leurs versions et les tags qui leur sont assignés. Les versions incluent les versions non approuvées. Utilisez is_approved et is_effective pour vérifier l’état d’approbation et la date d’effet.
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 checks partiels.
recording, recording_status, recording_variant, recording_step	Enregistrements avec une version d’instruction et leur historique de statut, informations sur la variante sélectionnée et données d’enregistrement par étape. Cela peut inclure des audits planifiés qui n’ont pas démarré.
issue, board, issue_column	Issues, leurs tableaux et les colonnes des tableaux. Cela inclut les tableaux d’amélioration continue, d’approbation, Andon et de parcours de formation. Utilisez issue.board_type pour sélectionner un type de tableau.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist	Les éléments attachés à une issue.
issue_transition	L’historique des déplacements d’une issue 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’arbre Explore qui organise modules, dossiers et contenu.
user, user_group, user_group_member	Personnes et groupes dans votre espace de travail.
competency_training, competency_level	Chaque fait de formation derrière une cellule de la matrice de compétences : le niveau, la façon dont il a été donné (formation, formation sans formateur, revue d’ordre de production, ou défini manuellement), le formateur évalué, les durées, la version formée et une période de validité personnalisée. competency_level contient le label que votre espace de travail affiche pour chaque niveau.
qualification	Qualifications avec leur type.
qualification_competency_setting	Les paramètres de matrice de compétences de chaque qualification : si un niveau nécessite une pièce jointe ou une période de validité personnalisée, et les périodes de validité et d’avertissement.
recording_trainee	Les stagiaires planifiés de chaque formation, avec le niveau obtenu par chacun.
workinstruction_competency_setting	Les paramètres Learning & Development de chaque instruction de travail : le niveau minimum pour démarrer un ordre de production, les niveaux pour avancer rapidement et pour éviter les doubles-contrôles, et la période de validité.
tree_node_competency_coverage	Pour chaque ligne et niveau de la matrice de compétences, combien de personnes doivent atteindre ce niveau. Un dossier sans valeur propre prend la plus petite valeur de ses enfants disponibles, comme dans la matrice de compétences.
skill_matrix_cell	Chaque cellule de la matrice de compétences telle qu’elle est affichée : le niveau et le statut de chaque personne sur chaque instruction de travail ou qualification, et le score de chaque dossier. Rempli seulement si votre espace de travail utilise des cellules de matrice de compétences stockées.

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 et de la plage de dates sélectionnés sur l’appareil. Ils peuvent survenir 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 lui-même une version d’instruction. Si l’enregistrement n’a pas de version, la base de reporting continue à l’exclure. Le seul statut n’explique pas si un audit apparaît dans la base.

Statut et résultat sont différents

La colonne status contient la valeur stockée, par exemple IN_QUEUE, et non le libellé affiché 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 commencent 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 checks, des événements et des retouches. Elle peut être true en raison de :

• Un check ou double-check échoué.
• Un résultat de couple NOK.
• Une valeur en dehors des limites permises.
• Un événement Andon, qui signale un problème durant l’exécution.
• Un statut actuel ou précédent Rework (REWORK).

La colonne is_defect utilise les mêmes checks mais exclut la retouche seule. Par exemple, une retouche sans check é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 d’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 de result et notes peuvent encore avoir NULL dans ces colonnes. Une synchronisation normale met à jour uniquement les enregistrements modifiés. Voir Remplir les colonnes pour les données existantes pour remplir ces colonnes pour les enregistrements historiques inchangés.

Sélectionner audits et instructions de travail avec des tags

Les tags que vous attachez à une instruction de travail ou à un audit se trouvent dans la table workinstruction_tag, une ligne par tag. Utilisez-les pour sélectionner les bons audits sans faire correspondre les noms ou descriptions, qui se cassent lorsqu’un utilisateur édite le texte.

Colonne	Contenu
workinstruction_id	L’instruction de travail ou l’audit auquel le tag est attaché.
workinstruction_name	Son nom d’affichage.
tag	Un tag. Les tags sont du texte libre, donc mettez-vous d’accord sur l’orthographe dans votre espace de travail.

Par exemple, pour lister les audits qui portent le tag calculate_quality_score :

select r.id, r.status, r.result
from "company_<your-workspace-id>".recording r
join "company_<your-workspace-id>".workinstruction_tag t
    on t.workinstruction_id = r.workinstruction_id
where r.type = 'AUDIT'
    and t.tag = 'calculate_quality_score';

La table workinstruction n’a pas de colonne qui marque les audits. Sélectionnez les audits avec recording.type = 'AUDIT'.

Travaux complétés et ordres clos

Le statut d’un enregistrement et le statut d’un 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 remplit les 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é fermé.

Un ordre peut rester In progress lorsque ses enregistrements sont terminés mais que la quantité complétée ne correspond pas à la quantité requise. Un ordre actif sans instructions de travail ni ordres enfants est All complete. Voir Statut de l’ordre de production.

Forcer la clôture d’un ordre annule ses enregistrements non terminé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 quand l’ordre a été activé pour la première fois. Il est NULL pour un ordre jamais activé, et pour un ordre activé avant qu’Azumuta n’enregistre les temps d’activation. Il n’est pas dérivé de execution_date, qui est une date prévue. Les ordres déjà synchronisés avant l’ajout 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 vider vos données de reporting afin que la prochaine synchronisation les reconstruise.

Associations de zones et affectation

product_order_workinstruction_spot relie chaque ligne d’ordre à ses zones. Le zone_type identifie la source :

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

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

Par exemple, un item est assigné à A, accédé en 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 en A.

Le placement de secours utilise le nœud parent direct de l’instruction lorsqu’il s’agit d’une zone. Il ne recherche 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 la ligne d’ordre

Pour compter le travail planifié, partez de product_order_workinstruction. Si vous avez besoin des détails d’un enregistrement, faites une jointure gauche depuis recording_id vers recording.id. Cela conserve les lignes sans ligne d’enregistrement dans la table de reporting.

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

Plusieurs zones ou visites peuvent répéter la quantité d’une ligne 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 lignes d’ordre associées à 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 qui ont réalisé le travail. instruction_visit.user_id identifie l’opérateur de cette visite.

Pour une formation, planned_user_id est le formateur prévu et recording.trainer_id est le formateur qui a terminé la formation. Les stagiaires sont dans recording_trainee.

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

Filtrer les étapes par type de check

instruction_step.check_type contient le type de check sur une étape. Utilisez-le au lieu de faire correspondre step_description, qui change lorsqu’un utilisateur édite l’étape. La colonne est NULL pour une étape sans check.

Valeur	Check
choice/ok-nok	OK/NOK
choice/yes-no	Yes/No
choice/single	Choix unique
choice/multiple	Choix multiple
number/prompt	Numérique
number/slider	Curseur
number/score	Score
tools/torque	Couple (torque)
text/line	Ligne unique
text/paragraph	Paragraphe
text/masked	Saisie masquée
text/unique-id	Identifiant automatique
camera/bar-code	Code-barres
camera/picture	Photos
camera/signature	Signature manuscrite
table	Tableau
special/attachment	Fichiers
special/print	Impression
special/email	Email
special/procedure	Procédure
special/identifier	Numéro d’ordre de production
special/variants	Variantes
special/timer	Minuteur
special/link-product	Lier un ordre de production
special/scan-parts	Pièces
special/electronic-signature	Signature électronique

Par exemple, pour lister les étapes avec un check OK/NOK :

select workinstruction_name, step_description
from "company_<your-workspace-id>".instruction_step
where check_type = 'choice/ok-nok';

Les valeurs figurent aussi dans la description de la colonne ; voir le dictionnaire de données intégré.

Visites, tentatives et étapes applicables

• instruction_visit a une ligne quand un opérateur quitte une étape. Une visite encore ouverte peut ne pas encore avoir de ligne.
• type = 'normal' et type = 'double-check' sont des groupes de visites séparés. is_last_visit marque la dernière visite dans son groupe, pas nécessairement la dernière visite avec une réponse. Voir Double-checks.
• Un check 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 est parti, pas les pressions de bouton individuelles.
• instruction_total_visit contient les 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 Variantes et configuration des variantes.

Une donnée manquante seule ne prouve 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 pour interpréter des étapes historiques. L’approbation est une propriété séparée ; voir Historique des révisions.

Les paramètres sont stockés en tant qu’objet JSON indexé par nom de paramètre. Lisez une valeur avec parameters->>'key'. Un enregistrement ou ordre sans paramètres a la valeur NULL.

Pour rendre une réponse disponible dans la base de reporting, activez Write value to parameters sur le check et donnez-lui une clé stable, par exemple machine_operator. Voir Utiliser un paramètre dans un Product Check. Filtrez sur cette clé au lieu de faire correspondre des descriptions d’étape :

select id, parameters->>'machine_operator' as machine_operator
from "company_<your-workspace-id>".recording
where parameters->>'machine_operator' = 'Jan';

Un enregistrement lié à un ordre de production conserve ses paramètres sur l’ordre, donc recording.parameters est vide pour celui-ci. Lisez product_order.parameters via recording.product_order_id. La colonne est aussi un objet JSON, donc la même expression fonctionne :

select r.id, o.parameters->>'batch' as batch
from "company_<your-workspace-id>".recording r
join "company_<your-workspace-id>".product_order o
    on o.id = r.product_order_id;

Les audits et autres enregistrements qui ne sont pas liés à un ordre de production utilisent 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 une donnée manquante, pas zéro ou une réponse échouée.

Remplir les colonnes pour les données existantes

Une nouvelle colonne ou table se remplit lors de la prochaine synchronisation. Une ligne déjà existante ne reçoit une valeur dans une nouvelle colonne que lorsque son enregistrement source change à nouveau, donc les données historiques peuvent rester vides. Cela s’applique aux colonnes ajoutées après l’activation de la base de reporting, telles que recording.result, recording.notes, recording.parameters, recording.trainer_id, tree_node.competency_importance, workinstruction_version.is_training_required et instruction_step.check_type. La table workinstruction_tag se remplit elle-même.

Pour remplir l’historique une fois, utilisez Clear data dans la configuration de reporting. Cela supprime toutes les lignes synchronisées pour votre espace de travail tout en gardant la base de reporting activée. La synchronisation suivante remplit chaque table depuis le départ.

Attention : Les requêtes et rapports BI n’affichent aucune donnée tant que cette synchronisation n’est pas terminée. Le bouton n’est pas disponible pendant qu’une synchronisation est en cours. Voir Activer la base de données de reporting.

Conventions utilisées partout

• Clés primaires. Chaque table a une clé primaire texte nommée id. Ceci identifie un enregistrement source ou une ligne générée. Les colonnes liées utilisent des noms tels que recording_id et workinstruction_id. Par exemple, joignez recording.workinstruction_id à workinstruction.id.
• Suppressions. Quand une synchronisation détecte un enregistrement source supprimé, elle supprime les lignes correspondantes dans le reporting. Les définitions de table actuelles n’incluent pas deleted_at. Les bases plus anciennes peuvent conserver cette colonne parce que les mises à jour de schéma ne suppriment pas les anciennes colonnes. La synchronisation 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 issues archivées.
• Horodatages de sync. Chaque table a first_synced_at et last_synced_at. Ils enregistrent la première et la dernière synchronisation qui a écrit la ligne, pas la création ou la modification de l’enregistrement source.
• Horodatages source. Des colonnes comme 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 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 en JSON. Les données qui varient de forme (comme parameters ou une answer d’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 possède une description lisible par l’humain qui lui est 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 Requêtes analytiques d’exemple.