Contexten en Modules

Contexten zijn het mechanisme waarmee Ultimo dezelfde database-entiteit (bijv. Equipment of Job) in verschillende modules met verschillende betekenis, schermen, workflows en gedrag kan gebruiken. Een context bepaalt hoe een record eruitziet, welke velden beschikbaar zijn, welke statusovergangen mogelijk zijn en in welk backoffice het verschijnt.

Dit is een van de meest fundamentele concepten in Ultimo. Als consultant moet je contexten begrijpen om schermen, workflows en process settings correct te configureren.

Gerelateerd: ../configuration/process-settings, ../entities/equipment, ../entities/job, ../entities/pm-workorder

Hoe werken contexten?bewerken

Eén tabel, meerdere betekenissenbewerken

In de database bestaat er maar één tabel Equipment. Maar via de context-kolom (EqmContext) kan hetzelfde record een installatie, een voertuig, een instrument of een configuratie-item zijn:

Wat bepaalt de context?bewerken

De context bepaalt:

1. In welk backoffice/module het record verschijnt — Een installatie verschijnt in het TD-backoffice, een fleet-object in het Wagenparkbeheer
2. Welke schermen worden gebruikt — Elk backoffice heeft eigen schermconfiguraties
3. Welke velden zichtbaar/verplicht zijn — Via ../configuration/process-settings per context
4. Welke workflows worden getriggerd — Workflows kunnen filteren op context
5. Welke statusovergangen mogelijk zijn — De status matrix kan per context verschillen
6. Welke menu-items zichtbaar zijn — Het menu is ingericht per backoffice
7. Welke rapportages beschikbaar zijn — BI-rapporten filteren op context

Contexten per entiteitbewerken

Equipmentbewerken

Zie ../entities/equipment voor alle contexten. De belangrijkste:

Valkuil: Een gebruiker in het TD-backoffice ziet alleen installaties. Als een collega vraagt "ik kan asset X niet vinden", check dan of die in de juiste context zoekt.

Jobbewerken

Zie ../entities/job voor alle contexten. Jobs hebben de meeste contexten:

Belangrijk: De context van een job bepaalt welke workflows draaien. Een Job_PostApproved workflow voor context TD doet iets anders dan voor context Selfservice. Check altijd de context in je workflow-condities.

PmWorkOrder (Periodiek Onderhoud)bewerken

Zie ../entities/pm-workorder voor alle contexten:

Contexten configurerenbewerken

Waar configureer je contexten?bewerken

UCT > Database > Contexts & Statuses

Hier kun je: - Bestaande contexten bekijken - Contexten activeren/deactiveren per omgeving - De status matrix per context instellen

Process Settings per contextbewerken

UCT > Settings > Process Settings

Elke combinatie van tabel + context kan eigen instellingen hebben: - Verplichte velden - Standaardwaarden - Veld-zichtbaarheid - Barcode label configuratie

Zie ../configuration/process-settings voor het volledige overzicht.

Schermen per contextbewerken

Schermen zijn gekoppeld aan een tabel, maar de weergave wordt bepaald door het backoffice (en daarmee de context). Een equipment-scherm in het TD-backoffice toont andere velden dan hetzelfde scherm in het Fleet-backoffice.

Praktische tips voor consultantsbewerken

1. Context-bewust configurerenbewerken

Wanneer je een workflow, screen rule of process setting configureert, vraag jezelf altijd af: voor welke context geldt dit? Een instelling voor TD geldt niet automatisch voor Fleet of Infra.

2. Meerdere contexten activerenbewerken

Een klant kan meerdere contexten tegelijk actief hebben. Bijvoorbeeld: - TD (installaties) + Fleet (voertuigen) + Instrument (meetinstrumenten) - Elke context heeft eigen schermen, workflows en rechten

3. Context in workflows checkenbewerken

<When Name="Alleen voor TD-jobs" 
      Condition="${Job.Context} == JobContext.TD">
    <!-- Logica specifiek voor TD -->
</When>

4. Context bij data-importbewerken

Bij het importeren van data moet je de juiste context meegeven. Een equipment zonder context (of met context 0) verschijnt nergens.

5. Autorisatie per contextbewerken

Via de autorisatie kun je per backoffice (en daarmee per context) bepalen welke gebruikers toegang hebben. Een TD-medewerker hoeft geen Fleet-objecten te zien.

6. Rapportage per contextbewerken

BI-rapporten en selectielijsten filteren standaard op context. Als een klant vraagt "waar zijn mijn assets?", check of het rapport de juiste context filtert.

Veelgestelde vragenbewerken

Kan een record van context wisselen?bewerken

Nee, de context wordt bij aanmaak bepaald en kan daarna niet meer worden gewijzigd (behalve via directe database-manipulatie, wat wordt afgeraden).

Kan ik een custom context aanmaken?bewerken

Nee, contexten zijn door Ultimo gedefinieerd. Je kunt ze wel activeren of deactiveren.

Waarom ziet een gebruiker bepaalde records niet?bewerken

Check drie dingen: 1. Zit de gebruiker in het juiste backoffice? (autorisatie/groep) 2. Heeft het record de juiste context? 3. Heeft de gebruiker de juiste record-autorisatie (vestiging/afdeling)?

Equipment-contexten in de praktijk: hoe assets verschillen per modulebewerken

De Equipment-entiteit is het beste voorbeeld van hoe contexten het gedrag van dezelfde tabel volledig veranderen. Hieronder concrete voorbeelden van hoe registratie, velden en workflows per context verschillen.

Registratieproces per contextbewerken

Context-specifieke veldenbewerken

Velden die alleen in bepaalde contexten relevant of zichtbaar zijn:

Context-specifieke onderhoudsclassificatiesbewerken

De manier waarop periodiek onderhoud wordt georganiseerd verschilt per context:

• TD (Installation): Onderhoudsclassificaties via tabblad Onderhoudsclassificaties met groeps-PO-modellen en optie Individueel PO
• MT (Instrument): Onderhoudsclassificaties met risicoclassificatie, risicofactoren en FMEA. Periodieke activiteiten worden goedgekeurd en gekoppeld aan instrumentsoorten
• Fleet: PO-modellen in schema voor grote/kleine beurten op basis van kilometerstand
• Infra: Conditiemetingen op basis van NEN 2767 met gebrekenboek

Consultanttip: Bij het inrichten van een nieuwe module, controleer altijd welke tabbladen en velden beschikbaar zijn voor die context. Gebruik Process Settings per context om onnodige velden te verbergen en verplichte velden af te dwingen.

Voorbeeld: dezelfde Equipment, ander gedragbewerken

Stel dat je een pomp (Installation) en een druksensor (Instrument) wilt registreren. Beide zijn Equipment-records in dezelfde tabel, maar:

1. De pomp wordt geregistreerd via TD > Installaties, heeft een stuklijst met reserveonderdelen, ongeplande stilstandregistratie, en een procesfunctie als bovenliggend object
2. De druksensor wordt geregistreerd via MT > Instrumenten, heeft een onderhoudsclassificatie met risicobeoordeling, een vrijgavestatus, een instrumentsticker, en verschijnt in de AOC-verkenner

Dezelfde tabel, volledig andere gebruikerservaring. Dit is de kracht van contexten.

ITSM-contexten: Equipment als CI en Jobs als Incidenten/Problemen/Wijzigingenbewerken

De IT Service Management module maakt intensief gebruik van contexten. Dit is belangrijk omdat ITSM meer verschillende contexten gebruikt dan de meeste andere modules.

Equipment als ConfigurationItembewerken

In de ITSM-module is een Equipment-record met context ConfigurationItem (32) een configuratie-item (CI). Een CI vertegenwoordigt een individueel IT-onderdeel: server, laptop, printer, monitor.

Naast ConfigurationItem kent de Equipment-tabel in ITSM ook: - Software (64): applicaties en licenties - Network (128): switches, routers - Telephony (256): telefoontoestellen

Een configuratie (groepering van CI's, zoals een werkplek) is een apart concept maar eveneens gebaseerd op de Equipment-tabel.

Praktische gevolgen: - Een CI verschijnt alleen in het IT-backoffice, niet in TD of Fleet - Een CI heeft eigen tabbladen (Software, Netwerk, Stuklijst, Contracten, Indienststelling) die niet bestaan op TD-installaties - CI types (de ITSM-variant van assetsoorten) worden apart beheerd via Stamgegevens > IT > Configuratiebeheer > Configuratie-item types - Kosten worden net als bij installaties berekend op basis van uitgevoerde jobs

Jobs als Incidenten, Problemen, Wijzigingen en Serviceaanvragenbewerken

De Job-tabel herbergt in ITSM vier contexten:

Relaties tussen ITSM-contexten: - Een incident kan worden geescaleerd naar een probleem (als de oorzaak structureel is) - Een incident kan worden omgezet naar een serviceaanvraag (als het een standaardverzoek is) - Vanuit een incident of probleem kan een wijziging worden aangemaakt - Een probleem kan leiden tot een bekende fout (gedocumenteerde root cause met workaround)

Contexten in de backoffice-configuratie:

Ultimo gebruikt contexten ook voor backoffice-filtering bij self-service en servicedesk. Het tabblad Contextfiltering op een backoffice bepaalt welke voortgangsstatussen, jobsoorten, prioriteiten en objecten beschikbaar zijn in de afhandelsjablonen van dat backoffice.

Valkuil: Als een gebruiker een incidentsoort niet kan selecteren, controleer dan of het backoffice de juiste contextfiltering heeft. Als een CI niet zichtbaar is, controleer dan of het record context 32 (ConfigurationItem) heeft.

PO-modellen in ITSMbewerken

Periodiek onderhoud voor IT-configuratie-items gebruikt de context IT. Bulk-PO is mogelijk: meerdere CI's in een serviceaanvraag, waarbij Ultimo bij gereedmelding automatisch per CI een serviceaanvraag aanmaakt.

Zie ookbewerken

• ../configuration/process-settings — Instellingen per entiteit + context
• ../entities/equipment — Equipment entiteit met alle contexten
• ../entities/job — Job entiteit met alle contexten
• ../entities/pm-workorder — PO-model contexten
• ../concepts/autorisatie — Autorisatie per backoffice
• ../concepts/uct-overzicht — UCT configuratie
• ../concepts/assets — Assets registratie en beheer per context
• itsm — IT Service Management module
• kennisboom — Kennisboom met contextafhankelijke suggesties
• self-service — Self-service met backoffice-routering via contexten