planner

Reviewed Jan 1, 2000.

• tools: 6 tools scanned
• metadata: scanned

No findings.

Tools (6)

• solve_submit

  Reicht einen Dienstplan-Solve-Job ein. `payload` ist der self-contained Request: Pflicht: start_date, end_date (ISO), department {id}, employees [{id, contractHoursPerWeek, qualificationIds}], shifts [{id, departmentId, name, startTime, endTime, shiftType, minStaff}]. Optional u. a.: planning_rules, wishes, vacations, sick_leaves, holiday_dates, locked_assignments, social_points, wish_costs, config {timeout_seconds}. vacations darf Termine NACH end_date enthalten — noetig bei Datums-Kopplungsregeln mit Block-Tagen hinter dem Fenster (siehe Instructions). Datenschutz: IDs statt Namen verwenden. Antwort: {job_id, status}.

• solve_status

  Status eines Solve-Jobs (pending/running/completed/failed) inkl. Fortschritt.

• solve_result

  Ergebnis eines fertigen Solve-Jobs: assignments [{employee_id, shift_id, date}], unassigned_shifts mit Begründung, Statistiken.

• account_balance

  Aktuelles Token-Guthaben der eigenen Organisation (Solves kosten Tokens).

• service_info

  Build-Stand des laufenden Planner-Service: version (fortlaufende Build-Nummer), gitCommit, buildTime (UTC). Fuer Support-Anfragen und um Ergebnisse einem Software-Stand zuzuordnen.

• example_payload

  Ein sofort lauffähiger Beispiel-Payload für solve_submit. kind='simple' (1 Woche, 3 MA, 2 Schichten), kind='wishes' (Wünsche, Social Points, Wunschkosten) oder kind='rules' (ArbZG-Planungsregeln: 11 h Ruhe hart + max. 5 Folgetage — zeigt, wie Regeln den Plan formen; Param-Namen sind exakt, falsche werden still ignoriert).