Bewerken: Job (Werkorder)

Sectie: Functionaliteit & property-gedrag

Reden:

## Functionaliteit & property-gedrag

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 [[contract|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 [[progress-status|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 ([[cost-center|CostCenter]], [[department|Department]], [[site|Site]], [[process-function|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]].

---