Raporlama ihtiyacını işlem ihtiyacından ayırın
Rezervasyonla bağlantılı bir adisyonun durumunu sorgulamak ile geçen ayın bütün menü satışlarını analiz etmek iki farklı iştir. İlkinde operasyonel işlem bağlamı, ikincisinde toplu ve dönemsel veri gereksinimi bulunur.
Oracle STS Gen2 kullanım kılavuzunda menü fiyat analitiği, toplu adisyon verisi çıkarımı ve genel raporlamanın bu arayüzün amaçlanan kullanımı olmadığını açıkça belirtir.
Hangi veri için hangi arayüz?
Belirli gelir merkezindeki desteklenen check işlemleri ve dijital işlem süreçleri için STS Gen2'nin Checks API'si değerlendirilir. Çok sayıda işlem, ürün veya dönem verisini raporlamak için Oracle'ın BI API'si ve geçerli abonelik koşulları incelenir.
Bunların dışında POS konfigürasyonunun okunması/değiştirilmesi ayrı bir C&C API değerlendirmesi olabilir.
Örnek: Misafir geçmişi ve satış analitiği
Bir misafir ziyaretinin doğrulanmış kapanış harcamasını rezervasyon kartıyla ilişkilendirmek ile bütün işletmenin satış dağılımını grafikleştirmek aynı sistem davranışı değildir. İşletme önce beklediği çıktıyı; ziyaret bazlı kayıt mı, toplu satış raporu mu, menü kalemi analizi mi, açıkça tanımlamalıdır.
Veri ihtiyacını tek cümlede tanımladıktan sonra uygun API aboneliği, erişim kapsamı ve güncelleme yöntemi belirlenebilir.
Kabul kontrolü
Örnek raporda dönem, lokasyon, gelir merkezi, iade/iptal kapsamı, zaman dilimi ve tutarların doğruluğunu POS kaynak raporlarıyla karşılaştırın. Bir API üzerinden veri alınması tek başına işletme raporlarıyla eşitlik kanıtı değildir.
Rapor talebini ölçülebilir hale getirin
'Satışları görmek istiyoruz' talebi tek başına uygun API'yi belirlemez. İstenen raporun zaman aralığını, lokasyonları, vergi ve servis bedeli kapsamını, iade/iptal işlemlerini, veri yenileme sıklığını ve hangi hesapla karşılaştırılacağını yazın. Bu ayrıntılar raporlama ihtiyacının işlem API'si üzerinden çözülmeye çalışılmasını önler.
Örneğin bir restoran grubunun günlük kapanış tutarlarını şubeler arasında karşılaştırması gereken rapor ile tek bir rezervasyona bağlı adisyonun kapanış durumunu izlemesi farklı veri erişimleri gerektirir. İlkini BI/API raporlama yetkileri ve uygun veri modeliyle; ikincisini desteklenen STS Gen2 işlem akışlarıyla değerlendirmek gerekir.
Rezervem ile sınırların açıklığı
Rezervem'in mevcut Oracle Simphony STS Gen2 entegrasyonu doğrulanmış rezervasyon–adisyon ve uygun ödeme iş akışları içindir. İşletmenin ayrı BI API lisansını veya her tür toplu analitik özelliğini içerdiği iddia edilmez. Oracle entegrasyon sayfası doğrulanan işlem kapsamını anlatır.
Oracle resmî kaynakları
Oracle Simphony integration programme · STS Gen2 API · API Accounts.
