Die Tabelle `hcc_room_ooo` verwaltet fachliche Datensätze innerhalb der Buchungs-, Preis- oder Verfügbarkeitslogik. Sie hilft dabei, fachliche Regeln, Zeitfenster, Kontingente oder betriebliche Sperrungen strukturiert und nachvollziehbar abzubilden.

Der Hauptzweck dieser Tabelle besteht darin, fachliche Datensätze als eigenständigen Teil der Buchungslogik zu führen. Dadurch können Preisregeln, Kontingentsteuerungen, Prüfschritte oder Betriebszustände über klar definierte Felder wie `ooo_id`, `ooo_hotel_nr`, `ooo_room_id`, `ooo_start_date`, `ooo_end_date`, `ooo_status` verwaltet werden, statt in einzelnen Sonderfällen im Code zu verschwinden.

Diese Tabelle existiert, weil Preis- und Verfügbarkeitslogik in der Praxis viel differenzierter ist als nur „Zimmer ist buchbar“ oder „Preis steht fest“. Saisonfenster, Regeln, Einschränkungen, Kontingente, Sperrungen und Änderungsprotokolle benötigen eigene Datenstrukturen, damit Buchungslogik nachvollziehbar, wartbar und sicher bleibt.

Die Tabelle ist geschäftlich wichtig, weil sie direkt Einfluss auf Buchbarkeit, Preissteuerung, Betriebssicherheit oder Nachvollziehbarkeit hat. Fehler oder Lücken in diesem Bereich wirken sich oft unmittelbar auf Umsatz, Auslastung oder Supportaufwand aus.

Einfach erklärt steuert diese Tabelle, wann ein Zimmer vorübergehend aus dem normalen Betrieb herausgenommen ist. Das kann zum Beispiel wegen Reinigung, Reparatur, technischer Störung oder interner Sperrung passieren. Für Nicht-Techniker ist wichtig: Hier wird nicht beschrieben, wie das Zimmer aussieht, sondern ob und warum es aktuell nicht normal verkauft oder genutzt werden soll.

Technisch ist `hcc_room_ooo` ein Baustein der Preis-, Verfügbarkeits- oder Restriktionslogik. Solche Tabellen werden häufig in Kombination mit Scope-Feldern, Datumsfenstern, Prioritäten, Statuswerten oder Rateplan-/Zimmerreferenzen verarbeitet. Wichtige Felder sind hier `ooo_id`, `ooo_hotel_nr`, `ooo_room_id`, `ooo_start_date`, `ooo_end_date`, `ooo_status`, `ooo_reason`, `ooo_notes`. Fachlich hängt die Tabelle typischerweise mit `hcc_hotel`, `hcc_inventory_restrictions_day`, `hcc_zimmer` zusammen.

Änderungen an dieser Tabelle können direkte Auswirkungen auf Preisberechnung, Verfügbarkeit, Sperrlogik oder Nachvollziehbarkeit haben. Strukturänderungen sollten deshalb immer zusammen mit Importen, Validierungen und angrenzenden Buchungsprozessen geprüft werden.

• Pflege von Preis-, Saison-, Kontingent- oder Restriktionsdaten
• Auswertung in Buchungslogik, Validierung oder Tagesverarbeitung
• Nachvollziehen von Ausnahmen, Sperrungen oder Regeländerungen

• Felder wie `ooo_id`, `ooo_hotel_nr`, `ooo_room_id`, `ooo_start_date`
• Felder wie `ooo_end_date`, `ooo_status`, `ooo_reason`, `ooo_notes`
• Felder wie `ooo_created_by`, `ooo_created_at`, `ooo_updated_at`

• Für `hcc_room_ooo` wird eine Regel, ein Zeitraum oder ein Betriebszustand gepflegt, der später die Buchungslogik beeinflusst
• Ein Supportfall kann anhand der gespeicherten Datensätze nachvollziehen, warum eine Buchung möglich oder gesperrt war

• Bezieht sich fachlich auf ein Hotel und erbt oft dessen Mandanten-Scope
• Ergänzt oder erklärt operative Restriktionen auf Tagesebene
• Kann auf Zimmer- oder Raumlogik Bezug nehmen

• Fehlerhafte Daten können Buchbarkeit, Preislogik oder Betriebssperren direkt beeinflussen
• Mehrdeutige Zustände oder fehlende Referenzen erschweren Support und Fehlersuche
• Historisch gewachsene Felder sollten vor größeren Umstellungen geprüft werden

• Die Tabelle ist hotelbezogen und sollte in Mehrmandanten-Szenarien immer mit sauberem Hotel-Scope betrachtet werden.
• Bei Problemen in diesem Bereich lohnt sich fast immer ein Blick auf zeitliche Gültigkeiten, Statuswerte und Scope-Felder.