Job (Werkorder)

De Job-entiteit is de centrale entiteit voor werkzaamheden in Ultimo. Jobs worden gebruikt voor correctief onderhoud, storingen, servicedesk-meldingen, selfservice-aanvragen, inspecties en veel meer. Door het uitgebreide context-systeem kan een Job in meer dan 20 verschillende verschijningsvormen voorkomen.

Entiteitsnaam: Job Databasetabel: Job Primaire sleutel: JOBID (nvarchar 12)

Contextsbewerken

Statussenbewerken

Belangrijkste propertiesbewerken

Functionaliteit & property-gedragbewerken

Veel Job-properties worden niet (alleen) handmatig ingevuld maar door workflows berekend en gevuld. Onderstaande paragrafen beschrijven het gedrag van de belangrijkste velden; gebruik lookup_property_usage("Job", "<property>") voor de volledige, actuele lijst workflows per property en lookup_workflow("<naam>") voor de XML.

• Planningsdatums (ScheduledStartDate, TargetDate) — Deze worden door ~20-25 workflows geschreven en zelden direct ingetypt. De kern is de keten prioriteit → doorlooptijd → datums: Job_RecalculatePlanningDatesBasedOnPriority leest de Priority van de job en zet ScheduledStartDate/TargetDate op basis van de bij die prioriteit horende doorlooptijd (Priority.DurationUntil...). Job_CalculatePlanningDatesBasedOnDuration herberekent de tegenoverliggende datum zodra één datum of de duur wijzigt, en Job_SetPlanningDatesBySLA overschrijft ze vanuit het servicecontract (SLA). Planborden schrijven ze rechtstreeks terug bij verslepen (AssetPlanner_JobChangeDateFromStartDate, Gantt_ModifyJob). Consultanttip: pas je de prioriteit-doorlooptijden of het SLA aan, dan verschuiven bestaande jobs pas bij een herberekening — niet met terugwerkende kracht.

• Priority — Wordt gevuld door Job_SetDefaultPriority (standaard uit de context/meldingstype) en, in de ITSM-context, door Job_SetPriorityByImpactAndUrgency dat de prioriteit afleidt uit de impact×urgentie-matrix. Omdat de prioriteit de planningsdatums aanstuurt (zie hierboven), triggert een prioriteitswijziging doorgaans een herberekening.

• ServiceContractTargetFinishedDate — Uitsluitend gezet door Job_SetPlanningDatesBySLA (vanuit het gekoppelde ServiceContract) en geleegd door Job_ResetSLARelatedValues wanneer de SLA-koppeling vervalt. Wordt door 30 workflows gelézen voor SLA-bewaking, maar mag niet handmatig worden overschreven.

• Status (recordstatus) — De levenscyclus loopt via dedicated workflows in plaats van vrije statuswijziging: Job_CreateAndInitialize (beginstatus), de Job_Pre*-reeks (Job_PreApprove, Job_PreActivate, Job_PreComplete, Job_PreClose, Job_PreDelete) als gates per statusovergang, en Job_ChangeProgressStatus voor de functionele ProgressStatus. 71 workflows schrijven Status (grotendeels via ChangeStatus); filter erop met de statusmatrix.

• AcceptedBy / AcceptedDate — Gezet door Job_Accept (en Mobile_Job_Accept vanuit de app): de uitvoerder accepteert de job, waarna deze velden de medewerker en het tijdstip vastleggen. Bepalend voor de "geaccepteerd"-stap in de werkstroom.

• Equipment / kostendragers — Bij het koppelen of wijzigen van equipment nemen workflows als Job_ChangeEquipment en Job_CopyCostunitsFromBuilding automatisch kostendragers (CostCenter, Department, Site, ProcessFunction) over van het object, zodat kosten op de juiste dragers landen.

Het volledige, gegenereerde overzicht van álle Job-properties met hun schrijvende/lezende/filterende workflows staat in reference/properties/Job.

Relaties met andere entiteitenbewerken

Tips voor consultantsbewerken

• Context is allesbepalend: De context bepaalt welke velden zichtbaar zijn, welke workflows actief zijn en welke statustransities mogelijk zijn. TD (1) is de standaard voor technisch onderhoud.
• Statusflow: De standaard statusflow is: Aanvraag (64) -> Open (1) -> Goedgekeurd (2) -> Actief (4) -> Gereed (16) -> Compleet (4096) -> Gesloten (32). Niet alle statussen worden in elke context gebruikt.
• Multijobs: Via IsMultijob en Multijob/SubJobs kunnen jobs hiermee worden gebundeld.
• Kostenregistratie: Kosten worden opgebouwd uit uren (WeekLabs), materialen (Materials), externe kosten (Externals), resources (Resources) en gereedschappen (Tools).
• SLA-bewaking: Via ServiceContract, ServiceContractTargetFinishedDate en gerelateerde velden wordt de SLA-naleving gevolgd.
• Remark-velden: Er zijn veel RemarkChar-, RemarkInt-, RemarkDate- en RemarkText-velden beschikbaar voor klantspecifieke uitbreiding.
• Selfservice: Jobs met context SelfService (524288) worden typisch aangemaakt via het eindgebruikersportaal.
• Werkvergunningen: Via de Permits-relatie kunnen werkvergunningen worden gekoppeld aan een job.

Database Detailsbewerken

De tabel dba.Job bevat 308 kolommen -- verreweg de grootste tabel in Ultimo. Hieronder de belangrijkste technische details.

Computed columns (berekende velden)bewerken

Kolommen gezet door triggers (selectie van 43 trigger-kolommen)bewerken

Kostengerelateerde kolommen (allemaal decimal(21,5), bijgewerkt vanuit Cost/PurchaseLine/etc.):

Urengerelateerde kolommen:

Statusgerelateerde kolommen:

Belangrijke defaultsbewerken

Triggers en externe triggersbewerken

Job heeft 5 eigen triggers (INSERT, UPDATE, INSTEAD OF DELETE, plus 2 summary-triggers) en wordt beinvloed door 40 externe triggers -- het hoogste aantal van alle entiteiten:

• Cost-triggers: Wijzigingen in kostenboekingen updaten alle kostenvelden
• PurchaseLine/PurchaseRequestLine-triggers: Inkoopgerelateerde kostenaggregatie
• JobMat/JobExt/JobTls/JobRes-triggers: Materiaal-, externe-, gereedschaps- en resourceregels
• JobWeek-triggers: Weekplanning-aggregatie
• JobSchedulePart-triggers: Planningsuren-aggregatie
• JobInsp-triggers: Inspectielijnaantallen
• InvoiceOutLine/JobInvOutTerm-triggers: Facturatie-aggregatie
• JobMaintRangeHistory-triggers: Onderhoudsbereik-historie
• BackOffice-triggers: Backoffice-toewijzing
• Project/Incident-triggers: Project- en incident-statuswijzigingen propageren naar de job
• SDefPrsContext-triggers: Procesfunctie-context synchronisatie
• UmmSettings-triggers: Applicatie-instellingen propagatie

Consultanttip: Door de 40 externe triggers is de Job-tabel sterk gekoppeld aan andere entiteiten. Bulkwijzigingen op gerelateerde tabellen (bijv. Cost, PurchaseLine) kunnen significante performance-impact hebben. Het INSTEAD OF DELETE-trigger voorkomt directe verwijdering.

Brondatabewerken

Let op: De wiki-samenvatting hierboven toont een curated subset van properties en praktische consultant-tips. Voor ground truth (exacte kolomnamen, alle properties, defaults, triggers) gebruik de onderstaande tools.

• Entity-definitie — lookup_entity("Job") · reference/entities/Job Alle properties, contexts en statussen. Bron: Entities.xml.
• DB-schema — lookup_table_schema("Job") · reference/tables/Job Alle DB-kolommen, triggers, computed columns en defaults. Bron: database-schema.json.
• Gerelateerde workflows — find_workflows("", entity="Job") Alle Before/After Save events en andere workflow-ActionFields voor Job. Bron: workflows.xml.
• Property-gebruik — lookup_property_usage("Job", "ScheduledStartDate") · reference/properties/Job Welke workflows een specifieke Job-property lezen/schrijven/filteren. Bron: workflows.xml.
• Workflow-XML van een vuller — lookup_workflow("Job_RecalculatePlanningDatesBasedOnPriority") De volledige logica achter het property-gedrag hierboven. Bron: workflows.xml.

Zie ookbewerken

• equipment - Assets waaraan wordt gewerkt
• pm-workorder - Preventief onderhoud dat jobs genereert
• purchase - Bestellingen vanuit jobs
• purchase-request - Bestelaanvragen vanuit jobs
• permit - Werkvergunningen
• work-order - Werkorders/projecten
• employee - Medewerkers