Historisierte MOS-Reports

Zweck und Granularität

getHistoryMoss liefert historische Monatsblätter für Power BI. Eine Ergebniszeile entspricht einem vorhandenen MOS-Dokument. Die Zeitachse basiert auf mos_start beziehungsweise auf mos_year und mos_month.

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: vwEmpMoss
Alias: vwEmploymentMonthSheetStaffs
Selection: SELECT Form="mos" & qee_waste != 1

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

Historische Zuordnungen

Die MOS-Zeile wird über ihre historischen Verknüpfungen angereichert:

• mos_emp_unid -> die damals gültige Beschäftigung (emp_*)

• mos_per_unid -> die Person (per_*)

• mos_emp_unid und mos_year -> das passende Jahresblatt (yes_*)

• vorhandene mos_ou1_*, mos_ou2_* und mos_ou3_* -> historische Organisation

Es wird kein aktuelles EMP anstelle des in MOS referenzierten historischen EMP verwendet. Das ist wichtig, wenn sich Beschäftigung, FTE, Funktion oder Organisation innerhalb eines Auswertungszeitraums geändert haben.

Aufruf

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

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

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

MOS-Parameter

YES-Anreicherung

params=lastyear,detail=yes
params=lastyear,detail=summary
params=lastyear,detail=mos

detail=yes und detail=summary ergänzen passende vorhandene yes_*-Felder. Ohne detail wird die MOS-Standardlogik verwendet. detail=mos lässt die YES-Anreicherung weg.

Historische Filter

Alle gesetzten Filter werden mit AND kombiniert. UNIDs werden unabhängig von Groß-/Kleinschreibung verglichen.

...?fct=getHistoryMoss&params=lastyear,per=<PER_UNID>
...?fct=getHistoryMoss&params=lastyear,emp=<EMP_UNID>
...?fct=getHistoryMoss&params=lastyear,ou1=<OU1_UNID>
...?fct=getHistoryMoss&params=lastyear,ou2=<OU2_UNID>,ou3=<OU3_UNID>
...?fct=getHistoryMoss&params=lastyear,per=<PER_UNID>,ou1=<OU1_UNID>
...?fct=getHistoryMoss&params=lastyear,all

Die OU-Filter verwenden die historischen MOS-Snapshots und nicht die aktuelle EMP-Organisation. Der Beschäftigungsfilter wird gegen mos_emp_unid, der Personenfilter gegen mos_per_unid geprüft.

Gelieferte Feldgruppen

Zeitliche Identifikation

qee_unid
mos_year
mos_month
mos_start
mos_end

mos_month folgt der bestehenden Zero-based-Konvention: 0 ist Januar, 1 ist Februar und 11 ist Dezember.

Historische Schlüssel und Organisation

mos_emp_unid
mos_per_unid
mos_ou1_unid
mos_ou2_unid
mos_ou3_unid
mos_ou1_name
mos_ou2_name
mos_ou3_name

MOS-Stunden und Kapazität

mos_soll_hrs
mos_soll_hrs_act
mos_ist_hrs
mos_cap_hrs
mos_over_hrs
mos_over2_hrs
mos_gld_hrs
mos_payed_hrs
mos_total_hrs

EMP-Daten

emp_brutto_percent
emp_netto_percent
emp_week_hrs
emp_start
emp_end
emp_end_unlimited

Weitere freigegebene emp_*, per_* und yes_*-Felder werden gemäß der bestehenden Report-Feldliste geliefert. Technische und nicht benötigte Dokumentfelder werden nicht pauschal übernommen.

Synthetische MOS-Felder

Die Engine ergänzt ausschließlich Felder in der REST-Antwort; MOS-, EMP-, PER- und YES-Dokumente werden nicht geändert.

Ein FTE-Faktor von 0.5 bedeutet, dass die tatsächlichen Stunden für den Vergleich mit einer idealen 100-%-FTE durch 0.5 geteilt werden. Das ändert nicht die tatsächliche Arbeitszeit.

Wenn der Ausgangswert leer ist oder kein gültiger FTE-Faktor vorliegt, bleibt das synthetische Ergebnis leer. emp_netto_percent wird von diesen FTE-Feldern nicht verwendet.

Response

{
  "collection": {
    "version": "1.0",
    "queries": [],
    "links": [],
    "items": [
      {
        "data": [
          {"nm": "qee_unid", "vl": "<MOS_UNID>"},
          {"nm": "mos_start", "vl": "01.01.2026"},
          {"nm": "mos_per_unid", "vl": "<PER_UNID>"},
          {"nm": "mos_ist_hrs", "vl": 84},
          {"nm": "emp_fte_percent", "vl": 0.5},
          {"nm": "mos_ist_hrs_fte", "vl": 168}
        ]
      }
    ]
  }
}

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

Geeignete MOS-Fragen

Mit MOS lassen sich insbesondere monatliche Fragen beantworten:

• Mitarbeiterstand und FTE im Zeitraum beziehungsweise je historischem Team/Bereich

• Entwicklung von Soll-, Ist-, Kapazitäts- und Überstundenwerten

• Entwicklung von Krankenstand, Urlaub, Gleiten und weiteren vorhandenen Monatswerten

• FTE und Überstunden beziehungsweise FTE und verfügbare Kapazität

• Eintritte und Austritte über emp_entry und emp_exit

• Beschäftigungsstruktur sowie Teilzeit-/Vollzeitentwicklung

• Entwicklung von Funktionen, Standorten, Altersstruktur und historischen Organisationen, sofern die entsprechenden emp_*- und per_*-Felder freigegeben sind

• verfügbare FTE-Kapazitäten und monatliche Leistungskennzahlen

Grenzen

MOS enthält überwiegend kumulierte Monatswerte. getHistoryMoss bildet deshalb nicht zuverlässig ab:

• exakte Tagesprofile,

• die Anzahl der Tage mit mehr als zehn Arbeitsstunden,

• detaillierte Projektkontierungen,

• Kostenstellen- und Vertriebskontierungen,

• produktive versus unproduktive Einzelkontierungen.

Für diese Detailfragen ist die historische TIM-Quelle zu verwenden.