PMS verisinden günlük otel raporu: SabeeApp API entegrasyonu nasıl kurulur

Bir otelde gün genellikle aynı sorularla başlar: dün kaç rezervasyon geldi, önümüzdeki haftaların doluluğu ne durumda, fiyatlarımız kanallarda tutarlı mı? Bu soruların cevabı çoğu otelde PMS'in içindedir ama oradan dışarı çıkmaz. Birisi her sabah ekranlardan rakam toplar, bir tabloya yazar, e-postayla yollar. Bu yazı, SabeeApp kullanan oteller için geliştirdiğimiz iki çözümden, Otel Rapor ve Yönetim Sistemi ile Sabeeapp Shortcode Eklentisi'nden çıkan yaklaşımı anlatıyor: veriyi PMS'ten nasıl çekeriz, günlük raporu nasıl kurarız, senkron nerede bozulur ve aynı veriyi web sitesine nasıl taşırız.

Veri neden PMS'te kalmamalı?

PMS operasyonu yürütmek için tasarlanır: rezervasyonu kaydetmek, odayı atamak, misafirin giriş ve çıkışını yapmak. Yönetimin sorduğu sorular ise farklıdır ve çoğu zaman birden fazla kaynağı birleştirmeyi gerektirir: PMS'teki doluluk, OTA'lardaki fiyat, son günlerdeki rezervasyon temposu. Bunları PMS ekranlarından elle toplamak hem zaman alır hem de her seferinde biraz farklı yapıldığı için rakamlar tutarsızlaşır.

• Birden fazla tesisi yöneten bir grup, her tesis için ayrı ekrana bakmak zorunda kalır.
• Hazır PMS raporları sabit formattadır; yönetimin istediği kırılımı her zaman vermez.
• Fiyat paritesi gibi PMS dışı veriler zaten orada yoktur.
• Elle derlenen rapor, onu hazırlayan kişi izindeyken çıkmaz.

Otel Rapor ve Yönetim Sistemi'ni bu boşluk için kurduk: SabeeApp PMS API'sinden rezervasyon ve doluluk verisini otomatik çeken, Booking.com, Trivago ve diğer OTA platformlarındaki fiyatları izleyen, birden fazla oteli tek panelden yöneten bir SaaS platformu.

API'den veri çekme: mimari kararlar

Platformun arka ucu PHP ile modüler, RESTful bir API olarak yazıldı; veri MySQL'de ilişkisel modelle tutuluyor. Arayüz React ile geliştirildi, oturum ve global durum React Context API ile yönetiliyor. Bu ayrım önemli: PMS ile konuşan katman arayüzden bağımsız ve aynı veri hem panele hem rapor üreticisine hizmet ediyor.

PMS entegrasyonunda ilk karar, veriyi her istekte canlı mı çekeceğiniz yoksa kendi veritabanınıza mı kopyalayacağınızdır. Canlı çekim basit görünür ama her panel açılışında PMS'e istek gider, PMS yavaşladığında paneliniz de yavaşlar ve geçmişe dönük karşılaştırma yapamazsınız. Kopyalama kendi senkron mantığınızı yazmanızı gerektirir, ama raporlama, grafik ve dönem karşılaştırması için sağlam zemin budur.

Biz rezervasyon ve doluluk verisini kendi veritabanımıza senkronize eden ve üzerine bir önbellek katmanı koyan yolu seçtik. Panel ve raporlar doğrudan PMS'e değil, kendi veritabanımıza ve önbelleğe bakıyor; böylece PMS'e giden istek sayısı kontrol altında kalıyor ve panel hızlı açılıyor.

Senkron sorunları: nerede bozulur?

PMS entegrasyonlarında sorun nadiren ilk veri çekiminde çıkar; asıl sorunlar zamanla birikir. Bu tür entegrasyonlarda sık karşılaşılan durumlar şunlar:

• Geçmiş değişir. Bir rezervasyon iptal edilir, tarihi uzatılır ya da tutarı güncellenir. Yalnızca yeni kayıtları çeken bir senkron, değişen eski kayıtları kaçırır.
• Aynı kayıt iki kez gelir. Ağ hatasından sonra tekrar denenen bir istek, tablonuzda çift rezervasyon üretebilir.
• Saat dilimi karışır. Sunucu saati ile otelin yerel saati farklıysa "bugünün rezervasyonları" yanlış güne düşer.
• Senkron yarıda kesilir. Kısmi başarısızlık veriyi tutarsız bırakır ve çoğu zaman kimse fark etmez.

Bunların ortak çözümü senkronu tekrar çalıştırılabilir (idempotent) yazmaktır: aynı veri kaç kez gelirse gelsin sonuç değişmemeli. En basit yolu, PMS'in kayıt kimliğini kendi tablonuzda benzersiz anahtar yapmak ve düz ekleme yerine "varsa güncelle" mantığı kullanmaktır. Aşağıdaki örnek bu fikri MySQL üzerinde gösteriyor; tablo ve alan adları örnektir.

-- PMS kayıt kimliği otel bazında benzersiz:
-- aynı rezervasyon iki kez gelirse çift kayıt oluşmaz
CREATE TABLE reservations (
  id          BIGINT AUTO_INCREMENT PRIMARY KEY,
  hotel_id    INT NOT NULL,
  pms_id      VARCHAR(64) NOT NULL,
  status      VARCHAR(20) NOT NULL,
  arrival     DATE NOT NULL,
  departure   DATE NOT NULL,
  amount      DECIMAL(12,2) NOT NULL,
  synced_at   DATETIME NOT NULL,
  UNIQUE KEY uq_hotel_pms (hotel_id, pms_id)
);

-- İptal veya tarih değişikliği gelirse mevcut satır güncellenir
INSERT INTO reservations
  (hotel_id, pms_id, status, arrival, departure, amount, synced_at)
VALUES (?, ?, ?, ?, ?, ?, NOW())
ON DUPLICATE KEY UPDATE
  status    = VALUES(status),
  arrival   = VALUES(arrival),
  departure = VALUES(departure),
  amount    = VALUES(amount),
  synced_at = NOW();

Geçmişin değişmesine karşı ise senkron penceresini yalnızca "son çekimden bu yana oluşanlar" ile sınırlamamak gerekir. Gelecek tarihli konaklamaları ve yakın geçmişi düzenli aralıklarla yeniden taramak, iptal ve değişiklikleri yakalar. synced_at gibi bir alan da verinin ne kadar taze olduğunu panelde göstermeyi sağlar; kullanıcı baktığı rakamın ne zamana ait olduğunu bilmeli.

Günlük operasyon raporu: ne gösterilmeli?

İyi bir günlük rapor kısadır; yönetici sabah açtığında birkaç dakikada durumu anlamalıdır. Platformun interaktif panelinde bu iş için öne çıkan göstergeler günlük pickup, doluluk oranı ve gelir tahminleri. Grafikler Chart.js ile çiziliyor.

• Pickup: belirli bir günde gelen net rezervasyon. Doluluk rakamından daha erken sinyal verir; tempo düştüğünde fiyat ya da kanal kararı için zaman kalır.
• Doluluk oranı: gelecek tarihler için elde olan durum. Önceki dönemle yan yana konduğunda anlam kazanır.
• Gelir tahmini: mevcut rezervasyonların gelecek dönemlere yansıması.
• Fiyat paritesi: aynı oda ve tarih için kanallar arasındaki fark. Platform Booking.com, Trivago ve OTA platformlarını izliyor; Trivago ve RateCare API entegrasyonlarıyla dinamik fiyat karşılaştırması yapıyor.

Raporu panelde göstermek tek başına yetmez; insanların rapora gitmesini beklemek yerine raporun insanlara gelmesi gerekir. Platform raporları otomatik olarak PDF'e dönüştürüp zamanlanmış e-postayla gönderiyor. Panelden anlık indirme için ise jsPDF ve html2canvas ile PDF dışa aktarma kullanılıyor.

Birden fazla otel ve farklı kullanıcılar olduğunda yetki de rapor tasarımının parçasıdır. Platformdaki rol tabanlı yetkilendirme sayesinde her kullanıcı yalnızca yetkili olduğu verileri görüyor; tek bir tesisin sorumlusu ile grubun tamamına bakan yönetici aynı panelde farklı kapsamla çalışabiliyor.

Aynı veriyi web sitesine taşımak: shortcode eklentisi

Verinin PMS'te kalmamasının ikinci tarafı otelin kendi web sitesidir. Rezervasyon ve fiyat bilgisi PMS tarafında yaşar; site ise çoğu zaman WordPress üzerindedir. İkisini bağlamanın en az sürtünmeli yolu, içerik editörünün kod yazmadan kullanabileceği bir araçtır.

Sabeeapp Shortcode Eklentisi bu ihtiyaç için geliştirdiğimiz özel bir WordPress eklentisi: SabeeApp hizmetlerini, parametreleri yapılandırılabilen shortcode'larla sayfalara yerleştiriyor. Ayarları admin paneli üzerinden yapılıyor; duyarlı tasarıma uyumlu, çoklu dil destekli ve önbellek kullanıyor. Editör, istediği sayfaya kısa bir shortcode ekleyerek içeriği yerleştirebiliyor; şablon dosyalarına dokunmak gerekmiyor.

Bir otel sitesinde bu tür entegrasyonların tipik kullanımı, müsaitlik ve fiyat bilgisini ziyaretçinin zaten bulunduğu sayfada göstermektir. Burada da raporlamadaki ilke geçerli: her sayfa görüntülemesinde dış servise gitmek hem sayfayı yavaşlatır hem de servis tarafında gereksiz yük oluşturur. Önbellek bu yüzden bir ek özellik değil, zorunluluktur.

Ama önbellek süresi bilinçli seçilmeli. Müsaitlik gibi hızlı değişen bilgide uzun önbellek, ziyaretçiye artık geçerli olmayan bir oda ya da fiyat göstermek demektir. Sitede gösterilen bilgiyi yönlendirici, rezervasyon adımındaki bilgiyi ise kesin kabul etmek ve son kontrolü orada yapmak bu riski kapatır.

Başlamadan önce karar listesi

1. Hangi sorulara cevap arıyorsunuz? Pickup, doluluk, parite, gelir; raporun içeriğini önce bu listeden çıkarın.
2. Veriyi canlı mı çekeceksiniz, kopyalayacak mısınız? Raporlama ve geçmiş karşılaştırma gerekiyorsa kopyalayın.
3. Senkron tekrar çalıştırılabilir mi? PMS kayıt kimliği benzersiz anahtar mı, iptaller ve değişiklikler yakalanıyor mu?
4. Saat dilimi tek yerde mi tanımlı? "Bugün" otelin yerel saatine göre mi hesaplanıyor?
5. Verinin tazeliği görünür mü? Kullanıcı son senkronun ne zaman yapıldığını biliyor mu?
6. Rapor kime, hangi sıklıkta, hangi formatta gidecek? Rol ve yetki tanımları net mi?
7. Web sitesinde gösterilen müsaitlik ve fiyat için önbellek süresi, verinin değişme hızına uygun mu?

Bu soruların cevabı netse, PMS'teki veri her sabah elle derlenen bir tablodan kendiliğinden gelen bir rapora dönüşür. Teknoloji seçimi bunun ardından gelir.

• #otel yazılımı
• #pms entegrasyonu
• #raporlama
• #wordpress