Formatbeschreibung des Salonexports

Fassung vom 8. November 2026 · Schemafassung 2

Diese Seite beschreibt Aufbau und Inhalt des Salonexports von Tagano: Datei, Datentypen, alle Datenbereiche mit ihren Feldern, Verknüpfungen und Grenzen. Sie ist das Online-Register der Datenstrukturen und Datenformate nach Art. 26 Buchst. b der EU-Datenverordnung (Verordnung (EU) 2023/2854). Wie du exportierst und wie ein Anbieterwechsel abläuft, erklärt die Seite „Datenexport und Anbieterwechsel“.

1 Datei und Aufbau

• Der Export ist eine einzelne JSON-Datei (RFC 8259) in UTF-8 mit dem Namen tagano-salon-export.json. Er ist kein ZIP-Archiv und enthält keine Bilddateien.
• Die Datei enthält ein JSON-Objekt mit 51 Feldern. Alle Felder sind in jedem Export vorhanden, auch wenn sie leer sind: leere Listen als [], leere Einstellungen meist als {}, fehlende Werte als null oder bei Textfeldern als leerer Text "".
• format hat den Wert easybook-salon-export-v2, schema_version den Wert 2. exported_at ist der Erstellungszeitpunkt. scope ist ein erläuternder Text zu Umfang und Ausschlüssen, kein Datenbereich.
• Der Export ist eine Momentaufnahme der vorhandenen Daten. Bereits gelöschte Daten werden nicht wiederhergestellt. Er ist keine Datenbanksicherung. Ein gesondertes JSON-Schema und eine Signatur der Gesamtdatei werden nicht mitgeliefert.
• Die Reihenfolge von Feldern und Datensätzen ist nicht festgelegt. Verknüpfe Datensätze über ihre Kennungen, nicht über ihre Position.

2 Abruf und Übergabe

• Den Export erstellt der Betreiber des Salons nach erneuter Eingabe seines Passworts. Im Browser: Einstellungen → Datenschutz → Datenrückgabe und Vertragsende → Vollständigen Salonexport herunterladen. In der App: Datenschutz verwalten → Daten und Nachweise exportieren → Alle Salondaten → JSON-Datei speichern. Teammitglieder haben keinen Zugriff auf den Gesamtexport.
• Der Export ist auch nach Ende von Test oder Abo verfügbar, solange der Salon besteht.
• Einen eigenen Zugang für den neuen Anbieter gibt es nicht, also keine Schnittstelle, keinen Download-Link und keine automatische Übertragung zwischen Anbietern. Der Betreiber übergibt die Datei auf einem mit dem neuen Anbieter abgestimmten, geschützten Weg. Tagano-Passwörter oder Zugangsdaten muss er dafür nicht weitergeben. Unterstützung beim Wechsel stimmst du mit uns über kontakt@tagano.de ab.
• Auskünfte zu einzelnen Kunden, Mitarbeitern oder Gästen haben einen anderen Umfang und eigene Formate. Diese Seite beschreibt nur den Salonexport.

3 Grenzen des Exports

Gesondert übergebene Dateien. Gespeicherte Mitarbeiterbilder sind nicht in der Datei enthalten. Der Export nennt sie in separate_files und wird trotzdem vollständig erstellt.

Ausgelassene Datensätze. Datensätze, die sich nicht eindeutig deinem Salon zuordnen lassen, gibt der Export nicht aus. Er nennt sie mit Kennung und Grund in omitted_records. Die gespeicherten Originaldaten bleiben dabei unverändert. Frei eingegebene Texte kann der Export nicht darauf prüfen, welche Personen darin erwähnt sind.

Nicht enthalten sind:

• Passwörter und Passwort-Hashes, Anmelde-, Sitzungs- und Push-Token sowie verwendbare Schlüssel zur Buchungsverwaltung oder zum Widerruf
• Zahlungs- und Checkout-Links, vollständige Karten- oder PayPal-Daten, Ereignisarchive und interne Parameter des Zahlungsanbieters sowie vollständige Rechnungsakten
• Vergleichswerte zur Erkennung mehrfacher Tests
• anbieterweite Administrator- und Analyseberechtigungen von Tagano, vollständige Einladungs- und Sitzungsverläufe, Geräte-Token und persönliche Vorschau-Einstellungen
• Wartungsankündigungen, Reichweitenzahlen von Tagano sowie Betriebs- und Sicherheitsprotokolle
• Support- und Kontaktvorgänge, externe Postfächer und Rechnungen
• bereits gelöschte Daten, auch bereinigte E-Mail-Kopien und Hinweise; Löschnachweise sind keine Kopien der gelöschten Daten. Noch gespeicherte E-Mail-Daten sind bis zu ihrer Bereinigung enthalten, auch wenn ihre Frist schon abgelaufen ist
• Daten anderer Salons, der Quellcode von Tagano, Datenbanksicherungen und vertrauliche Konfiguration

Gespeicherte Bilder, Supportunterlagen und Rechnungen übergeben wir auf Anfrage gesondert. Schreib dazu an kontakt@tagano.de; Umfang und geschützten Übergabeweg stimmen wir im Einzelfall ab. Einzelne Vertrags-, Registrierungs- und Löschweisungsnachweise kannst du außerdem im Betreiberkonto herunterladen.

4 Datentypen, Zeiten und Einheiten

• Zeitstempel werden nicht in Ortszeit umgerechnet. In gespeicherten Schnappschüssen behalten sie ihre ursprüngliche Genauigkeit und Schreibweise.
• Termine: date, hour und minute geben Tag und Uhrzeit in der Ortszeit Europe/Berlin (IANA-Zeitzonendatenbank) an, ohne Zeitzonenangabe. Beachte bei der Übernahme Sommer- und Winterzeit. Der Kundenbesuch endet nach duration_minutes; Vor- und Nachbereitung können darüber hinausgehen.
• Öffnungszeiten und Dienstplan: Uhrzeiten als Text HHMM, z. B. 0900; ältere Werte auch HH:MM. Uhrzeiten reichen von 00:00 bis 23:59. Leere Dienstplanzeiten sind möglich und können auf Wochenplan oder Öffnungszeiten verweisen.
• Dauern, Phasen und Einwirkzeiten stehen in Minuten, cancellation_hours, rescheduling_hours und reminder_hours in Stunden, Lösch-, Aufbewahrungs- und Testfristen in Tagen.
• Preise und Aufschläge sind Ganzzahlen in Cent. Beträge mit eigenem Währungsfeld stehen in der kleinsten Einheit dieser Währung; der Währungscode folgt ISO 4217 in Kleinbuchstaben, z. B. eur.
• Stundenlohn und Monatslohn sind historische Ganzzahlen ohne festgelegte Einheit. Interpretiere sie nicht als Cent.
• Mengen und Mischverhältnisse in Rezepturen sind freie Texte.

Gespeicherte Dokumente und Schnappschüsse werden in ihrer historischen Struktur ausgegeben. Ältere Fassungen können Felder auslassen oder zusätzliche enthalten. Ein fehlendes Feld bedeutet nicht null. Verwirf unbekannte Felder beim Import nicht stillschweigend.

5 Kennungen und Verknüpfungen

Kennungen sind die dauerhaften Kennungen aus Tagano. Sie werden für den Export nicht neu vergeben. Sie gelten im Zusammenhang mit dem jeweiligen Datenbereich, nicht als allgemeine Kennungen für andere Systeme.

• Historische Verweise, etwa auf gelöschte Leistungen, Kategorien oder Konten, können ohne Gegenstück sein. Verknüpfe sie nicht mit einem anderen aktuellen Datensatz.
• Schnappschüsse enthalten bewusst die Namen, Preise und Zuordnungen des damaligen Zeitpunkts.
• Auf ausgelassene Datensätze kann noch verwiesen werden. Werte omitted_records deshalb vor der Übernahme aus.
• contract_acceptances.release_id bezeichnet die angenommene Vertragsfassung; ihr Inhalt steht vollständig im Annahmedokument.

6 Datenbereiche und Felder

„oder null“ bedeutet, dass das Feld den Wert null haben kann. Felder, deren Aufbau Abschnitt 7 beschreibt, sind mit „siehe 7“ gekennzeichnet.

separate_files – gesondert herauszugebende Dateien (Liste)

Bilddaten, Dateinamen, Speicherpfade und Download-Schlüssel werden nicht ausgegeben.

omitted_records – ausgelassene Datensätze (Liste)

Ein Datensatz kann mit mehreren Gründen mehrfach erscheinen. Fehlt ein ungeklärter Termin, fehlen auch seine Gäste, sein Verlauf, seine Termin-E-Mails und Buchungsunterlagen. Bei einer unsicheren Mitarbeiterbeziehung bleibt der Mitarbeiter erhalten: user_id wird null, fremde Leistungsausschlüsse fehlen, ein unsicherer Wochenplan erscheint als []. Eine Ressourcenkonfiguration mit fremden Verweisen erscheint als {}. Ist bei einem Vertragsende ein Nachweis unsicher, fehlt dieser Nachweis; bei basis fehlt dann das ganze Objekt. Der Vorgang und die übrigen Nachweise bleiben. Gehört der auslösende Vorgang zu einem anderen Salon, fehlt der ganze Vertragsende-Datensatz. Jede solche Auslassung steht in omitted_records. Eine leere Liste heißt, dass die Zuordnungsprüfung nichts ausgelassen hat. Sie heißt nicht, dass gesondert übergebene oder ausgeschlossene Daten in der Datei enthalten sind.

salon – Salon und Buchungseinstellungen (Objekt)

accounts – Konten von Betreiber und Team (Liste)

Ob ein Zugang nutzbar ist, ergibt sich aus is_active, der E-Mail-Bestätigung und bei Teammitgliedern aus employees.active und processing_restricted_at. Eine archivierte oder gesperrte Zuordnung ist keine Zugangsfreigabe.

employees – Mitarbeiter, auch archivierte (Liste)

services – Leistungen (Liste)

service_categories – Leistungskategorien (Liste)

roster – Dienstplaneinträge (Liste)

opening_hours – Öffnungszeiten und Ausnahmen (Liste)

salon_closures – Schließzeiten (Liste)

resource_planning – Räume, Plätze und Geräte (Objekt)

notices – Salonhinweise (Liste)

staff_notifications – Hinweise an Team und Betreiber (Liste)

push_devices – registrierte Geräte (Liste)

customers – Kundenkartei (Liste)

appointment_guests – weitere Gäste eines Termins (Liste)

treatment_notes – Notizen und Rezepturen (Liste)

Eine Notiz gehört genau einem Kunden oder einem Gast. Ist der Termin gelöscht, kann appointment_id null sein.

appointment_series – Terminserien (Liste)

Die vorhandenen Einzeltermine stehen in appointments. Gelöschte Termine werden nicht rekonstruiert.

appointments – Termine, auch stornierte und abgeschlossene (Liste)

history – Änderungsverlauf der Termine (Liste)

booking_mail – Termin-E-Mails (Liste)

account_mail – Konto-E-Mails (Liste)

booking_legal_records – Buchungsunterlagen und Widerrufe (Liste)

billing_agreements – Tarif- und Bestellvereinbarungen (Liste)

plan_agreements – angenommene Tarifbestellungen und -wechsel (Objekt)

Einträge in checkouts:

Einträge in changes:

trial_offer – kostenloser Test (Objekt)

agreements – AV-Vertragsannahmen (Liste)

registration_agreements – Registrierungsnachweise (Liste)

contract_acceptances – Annahmen neuer Vertragsfassungen (Liste)

governance_notices – Ankündigungen von Tagano (Liste)

subprocessor_releases – Dienstleisterlisten (Liste)

Enthalten sind nur Fassungen, auf die ein Vorgang deines Salons verweist.

subprocessor_changes – Dienstleisteränderungen für deinen Salon (Liste)

price_campaigns – Preisänderungen (Liste)

Enthalten sind nur Preisänderungen, die deinen Salon betreffen.

price_changes – Umsetzung einer Preisänderung für deinen Salon (Liste)

provider_terminations – Kündigungen durch Tagano (Liste)

customer_contract_ends – Kündigungen des Salons zu einem besonderen Termin (Liste)

provider_switch_cases – Anbieterwechsel (Liste)

appointment_retention – automatische Terminlöschung (Liste mit höchstens einem Eintrag)

additional_retention – weitere Löschfristen (Liste mit höchstens einem Eintrag)

deletion_evidence – Lösch-, Sperr- und Datenschutznachweise (Liste)

Der Nachweis über den gerade erstellten Export erscheint erst im nächsten Export.

privacy_actions – Auskünfte und Löschungen zu Kunden (Liste)

requests – Anfragen betroffener Personen (Liste)

salon_holds – salonweite Sperren (Liste)

inactivity_schedules – vorgemerkte Löschung bei Inaktivität (Liste)

inactivity_reminders – Erinnerungen vor der Löschung (Liste)

salon_deletion_cases – Salonlöschung (Liste)

Nach vollständiger Löschung gibt es keinen Salonexport mehr. Abgeschlossene Löschvorgänge erscheinen deshalb normalerweise nicht.

deletion_confirmations – Löschbestätigungen (Liste)

Eine Bestätigung entsteht erst nach der Löschung. Im Export eines bestehenden Salons ist die Liste normalerweise leer; nach der Löschung erhältst du die Bestätigung per E-Mail.

7 Verschachtelte Strukturen

employees.weekly_schedule

Liste von Wochenplänen mit from (Datum, Beginn der Gültigkeit) und days (Liste mit sieben Tagen, Index 0 = Montag bis 6 = Sonntag). Jeder Tag hat present (Wahrheitswert) sowie start und end (Text HHMM oder leer). Es gilt der jüngste Plan mit from am oder vor dem jeweiligen Datum. Die Liste kann leer sein. Spätere Änderungen der Öffnungszeiten ändern gespeicherte Wochenpläne nicht.

services.employee_price_adjustments

Objekt mit der Mitarbeiterkennung als Text-Schlüssel und dem Aufpreis in Cent als Ganzzahl ab 0. Fehlt ein Mitarbeiter, gilt kein Aufpreis. Ältere Daten können Aufpreise von 0 und frühere Mitarbeiter enthalten.

services.workflow

{} bei einfachen oder älteren Leistungen. Sonst: version (Ganzzahl, 1), kind (simple oder multi) und steps (Liste). Ein Schritt enthält:

• name (Text) und kind: treatment (Behandlung), processing (Einwirkzeit) oder buffer (Puffer)
• minutes (Ganzzahl, 1 bis 1.440)
• staff: same (die federführende Person), any (jede geeignete und verfügbare Person, auch die federführende) oder none (kein Personal)
• employee_ids (Liste von Ganzzahlen; leer = keine Eingrenzung)
• resources (Liste von Anforderungen mit ids, einer Liste alternativer Ressourcenkennungen, und quantity, der Anzahl auszuwählender Ressourcen)
• customer_present (Wahrheitswert; false = Vor- oder Nachbereitung außerhalb der Besuchsdauer)
• optional staff_count (gleichzeitig benötigte Personen; fehlt das Feld, gilt 0 bei none, sonst 1) und source_service_id (kopierte Ursprungsleistung, gegebenenfalls gelöscht)

treatment_notes.recipe

product, shade, amount, developer und mixing_ratio (Texte, gegebenenfalls leer) sowie processing_minutes (Ganzzahl oder null). Ältere Rezepturen können weniger Felder enthalten. Werte eine fehlende Angabe nicht als 0.

appointments.service_snapshot

Liste der Leistungen zum Buchungszeitpunkt mit id, name, duration (Minuten), category_id (Ganzzahl oder null), guest_count, base_price_cents, surcharge_cents (Mitarbeiteraufschlag) und price_cents. Ältere Einträge enthalten nur id, name, duration, price_cents und gegebenenfalls category_id. Es gelten die gespeicherten Preise, nicht der heutige Katalogpreis.

appointments.phase_snapshot

Liste der Ablaufphasen, bei älteren Terminen gegebenenfalls leer. start und end sind Minuten ab Terminbeginn; das Ende zählt nicht mit.

• Standardform: kind (treatment, processing oder finish), start, end, service_id und name. Während processing ist die Person frei, Kunde und Platz bleiben belegt.
• Flexible Form, erkennbar an workflow: true: die Felder eines Ablaufschritts aus services.workflow sowie start, end, service_id und service_name. start kann bei Vorbereitung negativ sein, end nach dem Besuchsende liegen. kind ist treatment, processing oder buffer, in älteren Daten auch finish.

Verwende die gespeicherten Phasen und ersetze sie nicht durch den heutigen Ablauf der Leistung.

appointments.planning_snapshot

{} bei älteren Standardterminen. Sonst: version (1), staff, resources, seat_id, seat_name und phases (Kopie der Phasen).

• staff: employee_id, start, end (Minuten ab Terminbeginn), step (Phasenindex ab 0) und name (damaliger Name). Mehrere Einträge je Phase sind möglich.
• resources: resource_id (Text), start, end, units (derzeit 1), step und name. step = -1 bedeutet Belegung über den gesamten Ablauf einschließlich Puffer. Räume sind ebenfalls Ressourcen.

resource_planning.configuration

{} ist möglich. Sonst: enabled und women_area (Wahrheitswerte), seats (Liste) sowie optional resources (Liste) und service_order (Liste von Leistungskennungen, auch nicht mehr vorhandener).

• Platz: id und name (Texte), zone (general oder women), service_ids, category_ids und employee_ids (Listen von Ganzzahlen), optional room_id. Erlaubt ist eine Leistung, wenn sie selbst oder ihre Kategorie genannt ist; sind beide Listen leer, gilt keine Beschränkung. Eine leere employee_ids-Liste bedeutet keine Beschränkung.
• Ressource: id und name (Texte), kind (room, place oder device), room_id (bei Räumen leer, sonst der zugehörige Raum), capacity (Räume 1 bis 100, sonst 1), active (Wahrheitswert) und zone.

Platz- und Ressourcenkennungen sind dauerhafte Texte.

history.before, history.after und booking_mail.snapshot

Historischer Terminzustand mit date (Datum), time (Text HH:MM, Ortszeit), status, cancellation_reason, customer_id und employee_id (Ganzzahl oder null), employee (damaliger Name), employee_ids, services (wie service_snapshot), duration (Minuten), price_cents, phases (wie phase_snapshot), planning (wie planning_snapshot), seat_id, seat_name und booking_gender.

Nach Löschungen oder Einschränkungen können diese Angaben verkürzt sein: employee_id kann null sein, Listen können verkürzt sein, Namen können durch einen neutralen Ersatztext ersetzt sein. In planning.staff kann zusätzlich employee_name stehen. Werte solche Einträge nicht als aktuelle Zuordnung. Betroffene E-Mail-Kopien können ganz fehlen.

agreements.document

Historischer AV-Vertrag mit version, salon (company, representative, email, address, postal_code, city), provider (provider_name, provider_business_name, provider_address, privacy_contact; in Testständen {}), contract (Vertragstext), tom (technische und organisatorische Maßnahmen), subprocessors (Liste mit name, address, purpose, data, countries, transfer_basis; bei Zeilen aus der Vertragsanlage zusätzlich source_cells mit den fünf ursprünglichen Tabellenzellen), backup_retention_days (Ganzzahl) und acceptance (Annahmeerklärung). Einzelne ältere Fassungen enthalten zusätzlich release_scope und private_notice. Nach Annahme einer neuen Fassung kommen annex2 und full_text hinzu; full_text ist der vollständige AV-Vertrag mit beiden Anlagen.

registration_agreements.document

test_mode (Wahrheitswert), provider (wie oben), terms und privacy (jeweils version, text, digest), acceptance, business_declaration und privacy_notice (Texte), bei einzelnen älteren Fassungen release_scope und private_notice. Registrierungen nach Veröffentlichung einer neuen Vertragsfassung enthalten zusätzlich avv (version, contract, tom, annex2, full_text, subprocessors), release_id, release_digest und source_documents. source_documents enthält die Schlüssel imprint, privacy, terms, avv, switching und accessibility, jeweils mit filename, version, text (vollständiger Originaltext) und sha256. Ältere Nachweise werden nicht nachträglich geändert.

contract_acceptances.document

release (Version), release_digest, terms (version, text), avv (version, contract, tom, annex2, full_text, subprocessors, salon, provider, backup_retention_days, acceptance; Unterformen wie bei agreements.document) und capabilities (Liste der angenommenen Vertragsmerkmale). Neuere Annahmen enthalten zusätzlich source_documents wie oben.

deletion_evidence.details

Inhalt je nach action:

• instruction: enabled, days, effective_at, preview_count, document, digest und acknowledgements (Liste der bestätigten Erklärungen). document enthält version, paragraphs (Liste von Texten), acknowledgements (authority, reviewed, instructed), avv_url, avv_version und je nach Fassung provider_release_digest, provider, release_scope und private_notice.
• automatic: days, appointment_ids; manual: appointment_ids; customer_erasure: customer_id, appointment_ids
• hold_changed: appointment_id, before und after (Sperrgründe als Text)
• data_instruction: version, terms, periods (customer_days, roster_days, staff_days), enabled, digest, revision, counts (customers, roster, staff); data_cleanup: counts, revision
• data_hold: model (customer, employee oder roster), id, hold
• processing_restriction: model, id, reference, restricted, informed_before_lift, recipients_reviewed
• closure_requested: execute_after, returned_or_waived
• guest_export und guest_erasure: guest_id; guest_restriction: guest_id, enabled
• notice_published: version, digest; notice_link_updated: digest
• inactivity_expired: due_at, accepted_at, anchor_kind, cycle
• paused, data_paused, closure_cancelled und salon_export: {}

Historische Texte in diesen Nachweisen dürfen beim Import nicht durch heutige Fassungen ersetzt werden.

provider_switch_cases.workflow

{} bei älteren Vormerkungen. Sonst:

• version (1; unabhängig von schema_version) und kind: provider (Wechsel zu einem anderen Anbieter), own_system (eigene Systeme) oder delete (nur Löschung)
• request_reference, owner_id (Betreiberkonto), received_at (Eingang) und accepted_at (zugrunde liegende Vertragsannahme)
• notice_end (Ende der Ankündigungsfrist), transition_deadline (geltende Übergangsfrist), exception_notice_due (Frist für eine Begründung, falls der Wechsel technisch nicht möglich ist) und maximum_alternative_end (späteste alternative Frist)
• extension_used (Wahrheitswert: Verlängerung auf Kundenwunsch genutzt)
• fees: Liste vereinbarter Wechselentgelte mit amount_cents, direct_cost_cents, service_at, agreed_at (oder null) und agreement_reference; keine Rechnung
• events: Bearbeitungsverlauf mit at, actor, action (request, exception, extension, fee, handover oder completed) und details
• je nach Verlauf exception (reason, sent_at, notice_reference, alternate_end), extension (until, customer_reference, reason), handover (sent_at, delivery_reference, verification_reference), contract_end_reference, contract_end_at und actual_completion_at (Abschluss des Wechsels, Beginn der Abrufphase)

In events enthält details bei request den Wert customer_confirmed, bei completed end_reference und retrieval_until, sonst das jeweilige Objekt. Übertragene Dateien sind nicht eingebettet.

customer_contract_ends.evidence

{}, solange kein Nachweis vorliegt. Sonst je nach Vorgang: basis (source, notice_id, sent_at, objected_at, request_reference, kind, owner_id), settlement_reference und final_settlement_reference (geprüfte Abrechnung), actual_subscription_end (tatsächliches Aboende beim Zahlungsanbieter), late_end_acknowledged und late_end_resolution_reference (verspätetes Aboende geprüft und ausgeglichen) sowie no_subscription (kein bezahltes Abo). Referenzen sind Kennungen; die zugrunde liegenden Unterlagen sind nicht eingebettet.

salon_deletion_cases.provider_record

Häufig {}. Bei Löschung wegen Inaktivität trigger (inactivity) und inactivity_cycle. Bei Löschung nach einem Anbieterwechsel trigger (provider_switch), switch_reference, request_reference, return_reference, operator und switch_workflow (wie provider_switch_cases.workflow). Der Abschlussnachweis kann company, owner_email, stripe_customer_id, stripe_subscription_id, subscription_status und purpose enthalten. Das sind Belegreferenzen, keine Zugangsschlüssel.

deletion_confirmations.remaining

Liste der Restbestände mit category (backups, contract_and_deletion_evidence, invoices, je nach Fall auch recovery_journal, trial_comparison oder confirmation_mail_queue), presence (retained = bei uns vorhanden, conditional_external = möglicherweise bei einem externen Dienst), description, reason, duration (Frist in Worten) und until (Zeitstempel oder null). null bedeutet, dass sich kein konkreter Termin bestimmen lässt, nicht unbegrenzte Aufbewahrung.

8 Versionierung

Ändert sich der Aufbau des Exports, erhöhen wir schema_version und aktualisieren diese Seite. Schemafassung 2 ergänzt gegenüber Fassung 1 die Bereiche separate_files und omitted_records, Salonrollen, Leistungsausschlüsse, Terminserien und weitere eingeplante Mitarbeiter, Vertragsannahmen und Ankündigungen sowie Dienstleister-, Preis-, Kündigungs-, Inaktivitäts-, Wechsel- und Löschvorgänge und salonweite Sperren.