Historisierte TIM-Reports

Zweck und Granularität

getHistoryTims liefert historische, zugeordnete Zeitkontierungen für Power BI. Eine Ergebniszeile entspricht einem vorhandenen TIM-Dokument. Dadurch können Monats-, Tages- und Wochenreihen aus tim_date und tim_work_duration gebildet werden, ohne die Kontierungen serverseitig zu aggregieren.

Der Standardmodus ist der schnelle PER-Kontext: Er liefert per_ou1_*, per_ou2_* und per_ou3_* als aktuelle OU-Zuordnung der Person. Mit detail=emp wird zusätzlich das historisch am tim_date gültige EMP geladen. Dann stehen sowohl die aktuellen per_ou*- als auch die historischen emp_ou*-Felder sowie die EMP-/FTE-Felder zur Verfügung.

Die gemeinsamen Regeln für Authentifizierung, Zeiträume, Filter und Collection+JSON stehen auf Historisierte HR-Reports.

Datenquelle

Die Abfrage verwendet die bestehende Arbeitsansicht:

View: vwTims_assigned
Selection: SELECT Form="tim" & tim_state = 200 & qee_waste != 1

Die Ansicht filtert tim_state und qee_waste bereits aus. Die API dupliziert diese Auswahl nicht.

Aufruf

Der Funktionsname bestimmt die Quelle. form=tim muss nicht zusätzlich übertragen werden.

<https://server/synapcus.nsf/xrCmpCtrl.xsp/rest/api?fct=getHistoryTims&params=thisyear>
<https://server/synapcus.nsf/xrCmpCtrl.xsp/rest/api?fct=getHistoryTims&params=lastyear>
<https://server/synapcus.nsf/xrCmpCtrl.xsp/rest/api?fct=getHistoryTims&params=last3months>
<https://server/synapcus.nsf/xrCmpCtrl.xsp/rest/api?fct=getHistoryTims&params=custom,2026-01-01,2026-03-31>
<https://server/synapcus.nsf/xrCmpCtrl.xsp/rest/api?fct=getHistoryTims&params=lastyear,detail=emp>
<https://server/synapcus.nsf/xrCmpCtrl.xsp/rest/api?fct=getHistoryTims&params=lastyear,ou3=<OU3_UNID>>,detail=emp

Für Authentifizierung und gemeinsame Zeitraumregeln siehe die Übersichtsseite.

TIM-Filter

Alle gesetzten Filter werden mit AND kombiniert:

...?fct=getHistoryTims&params=lastyear,per=<PER_UNID>
...?fct=getHistoryTims&params=lastyear,emp=<EMP_UNID>,detail=emp
...?fct=getHistoryTims&params=lastyear,ou3=<OU3_UNID>,detail=emp
...?fct=getHistoryTims&params=lastyear,ou1=<OU1_UNID>,ou2=<OU2_UNID>,category=prod,detail=emp
...?fct=getHistoryTims&params=lastyear,per=<PER_UNID>,parent=prj
...?fct=getHistoryTims&params=lastyear,prj=<PRJ_UNID>,sac=<SAC_UNID>

Historischer Person-/EMP-Kontext

TIM besitzt tim_per_unid. Im Standardmodus wird die Person und deren aktuelle PER-Organisation geladen. Mit detail=emp wird zusätzlich das EMP mit Gültigkeit am tim_date bestimmt. Die Ausgabe enthält dann neben der aktuellen PER-Organisation auch die zeitlich passende Organisation, Funktion und FTE-Basis:

tim_per_unid -> PER -> per_ou1/2/3_* (Standard)
tim_per_unid -> PER -> EMP gültig am tim_date (detail=emp)

Das ist für Personen mit OU-, Vertrags- oder Beschäftigungswechsel innerhalb eines Jahres entscheidend.

Produktivität und Abwesenheit

Die Klassifizierung wird ausschließlich über die bestehende Methode QEETim.getProdType() gebildet. Die Werte sind:

Beispiele für Kategoriefilter:

...?fct=getHistoryTims&params=lastyear,category=prod
...?fct=getHistoryTims&params=lastyear,category=notprod
...?fct=getHistoryTims&params=lastyear,category=lev
...?fct=getHistoryTims&params=lastyear,category=gld
...?fct=getHistoryTims&params=lastyear,category=ill

tim_work_duration ist die Nettozeit nach der bestehenden Pausenlogik und die primäre Stundenkennzahl. Die TIM-Zeilen bleiben unaggregiert, damit Power BI nach Monat, Tag, Person, OU, Projekt oder Kategorie aggregieren kann.

Gelieferte Feldgruppen

Die Ausgabe enthält eine kontrollierte Auswahl vorhandener fachlicher TIM-Felder:

tim_date, tim_start, tim_end
tim_per_unid, tim_per_name
tim_duration, tim_break_duration, tim_work_duration
tim_created_from, tim_top_parent
tim_prj_unid, tim_prj_name
tim_sac_unid, tim_sac_name
tim_cce_unid, tim_cce_name
tim_sop_unid, tim_sop_name
tim_pos_unid, tim_pos_name, tim_pos_nr, tim_pos_type, tim_pos_cdr_type
tim_rqa_unid, tim_rqa_type, tim_rqa_state
tim_desc, tim_auto, tim_subtype
tim_fee, tim_fee_sale, tim_fee_sale_inv, tim_hourly_fee

Zusätzlich werden immer die freigegebenen per_*-Felder einschließlich per_ou1/2/3_unid und per_ou1/2/3_name geliefert. Nur mit detail=emp kommen historisch passende emp_*-Felder hinzu. Dazu gehören auch emp_hourly_fee, emp_hourly_fee_method und emp_hourly_fee_priv. UI-Felder wie bdl_*, tim_html, tim_tip, CSS-/Formula-Felder und show* werden nicht in die History-Zeile kopiert.

Synthetische TIM-Felder

Die synthetischen TIM-Felder werden nur in der REST-Antwort erzeugt:

Ohne gültigen FTE-Faktor bleiben die FTE-Stunden leer. Die FTE-Normierung verändert nicht tim_work_duration, sondern stellt eine zusätzliche Vergleichsgröße für Teilzeit und Vollzeit bereit.

Response

{
  "collection": {
    "version": "1.0",
    "queries": [],
    "links": [],
    "items": [
      {
        "data": [
          {"nm": "qee_unid", "vl": "<TIM_UNID>"},
          {"nm": "tim_date", "vl": "15.02.2026"},
          {"nm": "tim_per_unid", "vl": "<PER_UNID>"},
          {"nm": "tim_work_duration", "vl": 4},
          {"nm": "tim_top_parent", "vl": "prj"},
          {"nm": "tim_prod_type", "vl": 100},
           {"nm": "per_ou3_unid", "vl": "<CURRENT_OU3_UNID>"},
           {"nm": "per_ou3_name", "vl": "<CURRENT_OU3_NAME>"},
           {"nm": "emp_ou3_unid", "vl": "<HISTORICAL_OU3_UNID>"},
          {"nm": "emp_fte_percent", "vl": 0.5},
          {"nm": "tim_work_duration_fte", "vl": 8}
        ]
      }
    ]
  }
}

collection.items enthält die Kontierungen. data[].nm ist der vorhandene oder dokumentierte synthetische Synapcus-Feldname; data[].vl ist der Wert.

Geeignete TIM-Fragen

Mit getHistoryTims lassen sich insbesondere folgende Fragen beantworten:

• Wie entwickeln sich verfügbare FTE-Kapazitäten und produktive Projektstunden zueinander?

• Welche Teams steigern ihre produktive Leistung bei gleichbleibender oder veränderter FTE-Kapazität?

• Wie entwickeln sich produktive Projektstunden eines Mitarbeiters im Zeitverlauf?

• Wie entwickeln sich unproduktive Stunden beziehungsweise Kontierungen auf Kostenstellen?

• Wie lassen sich produktive und unproduktive Zeiten monatlich auf Mitarbeiter-, Team- und Bereichsebene vergleichen?

• Wie entwickeln sich Urlaub, Gleiten und Krankheit als Zeitreihe?

• Wie hat sich das Wochenprofil eines Mitarbeiters im Zeitraum X verändert?

• An wie vielen Tagen pro Woche wurde mehr als zehn Stunden gearbeitet?

• Wie können Teams, Personen, Projekte und Kategorien über ou1, ou2, ou3, per, prj und category verglichen werden?

Detail-Modi

Ohne detail=emp verwendet der Aufruf den aktuellen PER-Kontext und liefert per_ou1_*, per_ou2_* und per_ou3_*. Dies ist der schnelle Standardmodus; emp_ou1_*, emp_ou2_* und emp_ou3_* werden nicht geliefert.

Mit detail=emp wird zusätzlich das am tim_date gültige EMP bestimmt. Die Antwort enthält dann beide OU-Kontexte: per_ou1/2/3_* für die aktuelle PER-Zuordnung und emp_ou1/2/3_* für die historische Beschäftigungszuordnung. Zusätzlich werden die historischen EMP-Felder und synthetischen FTE-Felder geliefert.

detail=emp ist für historische OU-, Beschäftigungs- und FTE-Vergleiche zu verwenden. Der Standardmodus ist ausreichend, wenn die aktuelle PER-OU-Zuordnung und eine möglichst schnelle Antwort benötigt werden.

Grenzen

Die schnelle Standardausgabe verwendet die aktuelle PER-OU-Zuordnung. Für zeitlich korrekte OU-, Vertrags- und FTE-Auswertungen ist detail=emp erforderlich. Soll-Zeiten, die nicht im historischen EMP-Kontext oder in den TIM-Daten vorhanden sind, können nicht zuverlässig aus den Kontierungen rekonstruiert werden. Für monatliche MOS-Kennzahlen ist Historisierte MOS-Reports zu verwenden.