Het schema van de rapportagedatabase begrijpen

BETA: De rapportagedatabase bevindt zich momenteel in bèta en kan nog veranderen. Deze is alleen beschikbaar na aanmelding. Om deel te nemen aan de bèta of vragen te stellen, neemt u contact op met support@azumuta.com.

Waar uw gegevens zich bevinden

De beheerde rapportagedatabase slaat de rapporteerbare gegevens van uw workspace op in een schema met de naam company_<normalized-workspace-id>. De naam gebruikt kleine letters en vervangt andere tekens, behalve cijfers, door underscores. Een aangepaste database kan een andere schema-naam gebruiken. Gebruik uw geconfigureerde schema-naam in de voorbeelden hieronder.

De hoofdtabellen

Het inschakelen van de rapportagedatabase synchroniseert alle onderstaande tabellen. U kunt geen individuele tabellen selecteren.

Table	What it holds
workinstruction, workinstruction_version, workinstruction_tag	Werkinstructies, hun versies en hun toegewezen tags. Versies omvatten ook niet-goedgekeurde versies. Gebruik is_approved en is_effective om goedkeuring en de ingangsdatumstatus te controleren.
instruction_step	De individuele stappen binnen een versie van een werkinstructie.
instruction_visit, instruction_total_visit, instruction_partial_check	Elke keer dat een operator een stap doorloopt, per-stap totalen en indieningen van gedeeltelijke controles.
recording, recording_status, recording_variant, recording_step	Opnames gekoppeld aan een werkinstructieversie en hun statushistorie, geselecteerde variantinformatie en per-stap opnamegegevens. Deze kunnen geplande audits bevatten die nog niet zijn gestart.
issue, board, issue_column	Issues, hun borden en de kolommen van die borden. Dit omvat Continuous Improvement-, approval-, Andon- en training trajectory-borden. Gebruik issue.board_type om een bordtype te selecteren.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist	De items die aan een issue zijn gekoppeld.
issue_transition	De geschiedenis van een issue dat tussen bordkolommen beweegt.
product_order, product_order_workinstruction, product_order_workinstruction_spot	Productorders en de werkinstructies die eraan gekoppeld zijn.
article, article_category	Productartikelen en hun categorieën, niet kennisbankartikelen.
tree_node	De Explore-boomstructuur die modules, mappen en inhoud organiseert.
user, user_group, user_group_member	Personen en groepen in uw workspace.

Audit-opnames in de rapportagedatabase

De tabel recording bevat alleen opnames met een numerieke werkinstructieversie. Een opname zonder versie wordt uitgesloten, zelfs wanneer de status Finished (FINISHED) is.

De opname hoeft niet In progress (IN_PROGRESS) of Finished te zijn om te worden opgenomen. Een offline download kan een werkinstructieversie koppelen terwijl de status Planned (IN_QUEUE) blijft. Na een succesvolle synchronisatie met de rapportagedatabase kan die opname dus met status IN_QUEUE verschijnen.

Automatische downloads hangen af van de op het apparaat geselecteerde inhoud en datumbereik. Ze kunnen plaatsvinden vóórdat een operator een audit opent. Zie Device Settings: Offline.

Het sluiten van een niet-gestarte audit als N/A (NOT_APPLICABLE) koppelt op zich geen werkinstructieversie. Als de opname geen versie heeft, blijft de rapportagedatabase deze uitsluiten. De status alleen verklaart dus niet of een audit in de database verschijnt.

Status en resultaat zijn verschillend

De kolom status bevat de opgeslagen waarde, zoals IN_QUEUE, niet het weergavelabel Planned. Zie Status, result, and notes voor alle Engelse labels en opgeslagen waarden.

De tabel recording_status bevat statuswijzigingen. Deze bevat geen wijziging van het resultaat.

De kolom recording.result slaat het geselecteerde resultaat op, bijvoorbeeld Success (SUCCESS), Failed (FAILED), N/A (NOT_APPLICABLE) of Cancelled (CANCELLED). Nieuwe opnames starten met PLANNED. Deze waarde kan blijven staan als er geen resultaat is geselecteerd. Als de bronopname geen resultaatwaarde heeft, is de kolom NULL. Gebruik status, niet result, om de uitvoeringstoestand te identificeren.

De kolom is_failure wordt berekend op basis van checks, events en rework. Deze kan true zijn door:

• Een gefaalde check of double-check.
• Een draaimomentresultaat (torque) van NOK.
• Een waarde buiten de toegestane grenzen.
• Een Andon-event, dat tijdens de uitvoering een probleem signaleert.
• Een huidige of vorige Rework (REWORK) status.

De kolom is_defect gebruikt dezelfde controles maar sluit alleen rework uit. Bijvoorbeeld: rework zonder een gefaalde check of Andon-event geeft is_failure = true en is_defect = false. Vorige rework kan is_failure = true houden nadat de opname is beëindigd. Zie Rework voor de workflow.

Geen van beide berekeningen gebruikt het geselecteerde resultaat. Gebruik result, niet is_failure = false, om N/A of Success te identificeren. Een opname kan is_failure = false hebben zonder een geselecteerd resultaat.

Opname-notities

De kolom recording.notes bevat de notities van de opname, inclusief notities die zijn ingevoerd bij een resultaat. U kunt filteren op notes = 'auto cleanup' om opnames met exact die notitie te identificeren. Ontbrekende of lege notities verschijnen als NULL.

Rijen gesynchroniseerd voordat result en notes werden toegevoegd, kunnen nog steeds NULL in deze kolommen hebben. Een normale synchronisatie werkt alleen gewijzigde opnames bij. Een volledige resync is nodig om deze kolommen voor ongewijzigde historische opnames te vullen.

Voltooid werk en gesloten orders

Opnamestatus en product-orderstatus beschrijven verschillende niveaus van werk:

Field and value	Meaning
recording.status = 'FINISHED'	De opname is beëindigd. Controleer result afzonderlijk.
product_order.enhanced_status = 'all-complete' (All complete)	De actieve order voldoet aan de berekende voltooiingsvoorwaarden. Deze houden rekening met de werkinstructies, hoeveelheden en niet-gearchiveerde child-orders.
product_order.enhanced_status = 'finished' (Finished)	De order is gesloten.

Een order kan In progress blijven terwijl zijn opnames zijn beëindigd maar de voltooide hoeveelheid niet overeenkomt met de vereiste hoeveelheid. Een actieve order zonder werkinstructies of child-orders is All complete. Zie Product-order status.

Force-finishing an order annuleert ongebruikte opnames. Die opnames krijgen status FINISHED en resultaat CANCELLED. Sluiting is dus geen bewijs van succesvolle uitvoering. product_order.finished_at registreert de closure van de order, niet noodzakelijkerwijs het tijdstip waarop al het werk voltooid was.

product_order.activated_at registreert wanneer de order voor het eerst werd geactiveerd. Het is NULL voor een order die nooit is geactiveerd, en voor een order die werd geactiveerd voordat Azumuta activatietijden registreerde. Het wordt niet afgeleid van execution_date, wat een geplande datum is. Orders die al waren gesynchroniseerd voordat deze kolom bestond, krijgen pas een waarde wanneer ze veranderen. Om het voor alle bestaande orders te vullen, vraagt u Azumuta-support uw rapportagegegevens te wissen zodat de volgende sync het opnieuw opbouwt.

Zone-associaties en toewijzing

product_order_workinstruction_spot legt voor elk order-item de relatie met zijn zones vast. Het zone_type identificeert de bron:

• assigned: een zone die aan het order-item is toegewezen.
• accessed: een zone die tijdens operatoractiviteit is geregistreerd, tenzij dezelfde zone al assigned is.
• associated: een zone afkomstig van de plaatsing van de werkinstructie, gebruikt alleen wanneer het item geen assigned- of accessed-zones heeft.

De tabel combineert assigned- en accessed-zones. Hij behoudt één rij per item en zone, waarbij assigned voorrang krijgt. Een vergrendelde toewijzing is geen apart SQL-zone-type.

Bijvoorbeeld: een item is toegewezen aan A, benaderd op A en B, en heeft standaardplaatsing C. De rijen zijn assigned A en accessed B, zonder C. Een filter op zone_type = 'accessed' mist daarom de toegang op A.

Fallback-plaatsing gebruikt de directe ouder tree node van de werkinstructie wanneer die node een zone is. Er wordt niet naar willekeurige voorouders gezocht.

Toewijzingen kunnen veranderen. De velden assigned_spot_id beschrijven toewijzing, niet een onveranderlijke uitvoeringslocatie. De associatietabel is geen geschiedenis van toewijzingen. De regels ervan komen ook niet altijd overeen met elke ingebouwde widget. Zie Zone filtering for product-order widgets voor widgetconfiguratie.

Koppelen op orderregelniveau

Om gepland werk te tellen, begint u bij product_order_workinstruction. Als u opname-details nodig heeft, gebruikt u een left join vanaf diens recording_id naar recording.id. Dit behoudt items zonder een rapportageregel voor een opname.

Koppel zones via product_order_workinstruction_spot.product_order_workinstruction_id = product_order_workinstruction.id. Koppel niet alleen op workinstruction_id: meerdere orderitems kunnen dezelfde werkinstructie gebruiken.

Meerdere zones of bezoeken kunnen de hoeveelheid van een item of de duur van een opname in een samengevoegd resultaat herhalen. Gebruik EXISTS voor een associatiefilter, of aggregeer elke bron voordat u koppelt. Zie Count order items associated with a zone.

Geplande gebruikers en daadwerkelijke operators

recording.planned_user_id en planned_group_id beschrijven toewijzing. Ze identificeren niet iedereen die het werk uitvoerde. instruction_visit.user_id identificeert de operator voor dat bezoek.

Meerdere operators kunnen bijdragen aan één opname. Tel distinct recording IDs per operator, niet bezoekrijen. Een gedeelde opname telt dan voor elke bijdragende operator. Zie Recordings voor de rapportworkflow en the operator query voor deze berekening.

Bezoeken, pogingen en toepasselijke stappen

• instruction_visit heeft een rij wanneer een operator een stap verlaat. Een bezoek dat nog open is, kan nog geen rij hebben.
• type = 'normal' en type = 'double-check' zijn aparte bezoekgroepen. is_last_visit markeert het laatste bezoek binnen zijn groep, niet noodzakelijkerwijs het laatste bezoek met een antwoord. Zie Double-checks.
• Een geblokkeerde of ongeldige check telt als een poging maar levert geen geaccepteerd antwoord. instruction_total_visit.answer_attempts telt bezoeken met een poging nadat de operator vertrekt, niet individuele knopdrukken.
• instruction_total_visit bevat totalen en het uiteindelijk geregistreerde antwoord voor elke opname, stap en bezoektype. Een geregistreerd antwoord is niet per definitie een succesvol antwoord.
• recording_step.active = false betekent dat varianten de stap uitsluiten. Er wordt geen bezoek verwacht. Oudere opnames zonder opgeslagen variantselectie behandelen alle stappen als actief. Zie Variants en variant configuration.

Alleen ontbrekende gegevens bewijzen geen mislukking. Controleer toepasbaarheid, opname-status en of de stap een antwoord vereist. Zie Compare applicable steps with recorded answers.

Versie- en parametercontext

Koppel recording.workinstruction_version_id aan workinstruction_version.id om de versie te lezen die aan de opname is gekoppeld. Gebruik niet de huidige werkinstructieversie om historische stappen te interpreteren. Goedkeuring is een aparte eigenschap; zie Revision History.

Voor product-order-opnames leest u parameters uit product_order.parameters via recording.product_order_id. Andere opname-parameters kunnen in recording.parameters staan. Zie Product-order parameters en Introduction to parameters voor wat een parameter is.

JSON-velden kunnen lijsten of geneste objecten bevatten, niet alleen nummers of tekst. Controleer het type van elke waarde voordat u deze converteert. Een SQL NULL duidt op ontbrekende gegevens, niet op nul of een mislukte beantwoording.

Gehanteerde conventies

• Primary keys. Elke tabel heeft een tekst primary key met de naam id. Dit identificeert een bronrecord of een gegenereerde rij. Gerelateerde kolommen gebruiken namen zoals recording_id en workinstruction_id. Bijvoorbeeld, koppel recording.workinstruction_id aan workinstruction.id.
• Verwijderingen. Wanneer een sync een verwijderd bronrecord detecteert, verwijdert deze de corresponderende rapportagerijen. Huidige tabeldefinities bevatten deleted_at niet. Oudere databases kunnen deze kolom behouden omdat schema-updates oude kolommen niet verwijderen. De huidige sync onderhoudt deze kolom niet; gebruik deze niet als actuele indicator voor verwijdering. Gearchiveerde records verschillen van verwijderde records. Bijvoorbeeld identificeert issue.archived_at gearchiveerde issues.
• Sync-timestamps. Elke tabel heeft first_synced_at en last_synced_at. Deze registreren de eerste en meest recente sync die de rij heeft geschreven, niet de aanmaak- of wijzigingstijd van het bronrecord.
• Bron-timestamps. Kolommen zoals created_at, updated_at en started_at hangen af van de tabel. PostgreSQL slaat deze timestamps op als instanties in UTC en toont ze in de sessietijdzone.
• Opnameduren. recording.actual_duration en recording.rework_time zijn in seconden en kunnen fracties bevatten. Deel ze niet door 1000. Controleer de kolombeschrijving voor de eenheid van andere velden.
• Flexibele velden gebruiken JSON. Gegevens die in vorm variëren (zoals parameters of een instructie-answer) worden opgeslagen als jsonb, die u kunt bevragen met PostgreSQL's JSON-operators.
• Vooraf berekende waarden. Om extra joins te besparen, bevatten sommige tabellen kant-en-klare tellingen en metrics, bijvoorbeeld issue.comment_count, issue.open_task_count of recording.rework_time.

De ingebouwde datadictionary

Elke tabel en elke kolom heeft een leesbare beschrijving eraan gekoppeld. De meeste SQL-clients en BI-tools tonen deze automatisch. Bijvoorbeeld in psql:

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

U kunt ze ook met een query lezen:

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;

Klaar om te queryen? Zie Example Analytics Queries.