Die Tabelle `hcc_restriction_rule_targets` 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 `rrt_id`, `rrt_hotel_nr`, `rrt_rrs_id`, `rrt_scope`, `rrt_room_id`, `rrt_type_id` 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 regelt diese Tabelle einen Teil der Preis- oder Buchungslogik. Sie sagt also nicht nur „was es gibt“, sondern hilft dem System zu entscheiden, wann etwas buchbar ist, welche Regeln gelten oder warum sich ein Preis bzw. eine Verfügbarkeit in einer bestimmten Situation anders verhält. Für Nicht-Techniker ist das die Art von Tabelle, die im Hintergrund dafür sorgt, dass Buchungsregeln konsistent und kontrollierbar bleiben.

Technisch ist `hcc_restriction_rule_targets` 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 `rrt_id`, `rrt_hotel_nr`, `rrt_rrs_id`, `rrt_scope`, `rrt_room_id`, `rrt_type_id`. 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 `rrt_id`, `rrt_hotel_nr`, `rrt_rrs_id`, `rrt_scope`
• Felder wie `rrt_room_id`, `rrt_type_id`

• Für `hcc_restriction_rule_targets` 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.