Çevrimdışı POS'ta temel kural nedir?

Temel kural şudur: satış kaydı kasada tamamlanır, merkez sonradan öğrenir. Kasa uygulaması satırı yerel veritabanına yazar, fişi basar ve işlemi merkeze gönderilmek üzere kuyruğa alır. Merkez erişilemez olduğunda satış durmaz; yalnızca merkezdeki görünürlük gecikir. Merkezden onay bekleyen bir tasarımda ise hat kesintisi doğrudan ciro kaybıdır.

Kasada yerelde tutulması gerekenler

  • Ürün, barkod, birim ve vergi oranları
  • Geçerli fiyat listesi ve kampanya kuralları (başlangıç/bitiş tarihleriyle)
  • Müşteri kartı ve puan bakiyesi (bakiye için çevrimdışı limit tanımlanmalı)
  • Kasiyer yetkileri ve iade/iptal kuralları
  • Açık fiş, gün başı devir, kasa sayım verileri

Fiyat ve kampanya verisi kasaya önceden dağıtılmalıdır. Satış anında merkeze fiyat sormak, çevrimdışı çalışabilme iddiasını geçersiz kılar.

Kampanya kuralları nerede çalışmalı?

Kampanya motoru kasada çalışmalıdır; merkez yalnızca kural setini dağıtır. Bu, iki gereklilik doğurur: kuralların sürümlenmesi ve hangi kasanın hangi sürümü uyguladığının takip edilmesi. Bir kampanya yanlış hesaplandığında, "hangi kasa hangi kural sürümüyle çalışıyordu" sorusunun cevabı kayıtlarda bulunabilmelidir.

Ödeme cihazı ve mali cihaz entegrasyonu

Kart ödemesi ve mali işlem, uygulamanın kendi kuyruğundan farklı bir dünyadır: bu işlemler cihaz ve banka tarafında gerçekleşir ve geri alınması kendi kurallarına bağlıdır. Kritik senaryo, ödeme başarılı olduğu hâlde kasa uygulamasının yanıtı alamamasıdır. Bu durumda uygulama:

  • İşlemi "sonucu belirsiz" olarak işaretlemeli,
  • Cihazdan son işlem durumunu sorgulayabilmeli,
  • Kasiyeri ikinci kez tahsilat yapmaktan alıkoyan bir uyarı göstermelidir.

Bu senaryo test edilmeden devreye alınan kurulumlarda çift tahsilat ve gün sonu farkı kaçınılmazdır.

Gün sonu mutabakatı

Gün sonunda dört küme karşılaştırılır: kasa uygulamasının satış toplamı, mali cihaz raporu, banka POS toplamı ve fiziksel kasa sayımı. Farkların kaynağını bulabilmek için her satışın; kasa kimliği, kasiyer, ödeme tipi, cihaz işlem numarası ve varsa iade referansıyla birlikte saklanması gerekir. Bu alanlar en baştan tasarlanmazsa fark analizi elle yapılan bir işe dönüşür.

Merkez tarafında beklenen davranış

Kuyruktaki satışlar merkeze ulaştığında sıralama garantisi olmayabilir. Merkez, aynı satışın iki kez gelmesine karşı satış kimliğiyle tekrar kontrolü yapmalı; geç gelen bir satışı, o günün kapanmış raporlarına doğru dönemde yansıtabilmelidir. Bu davranışın ayrıntısını API entegrasyonu rehberinde anlatıyoruz.

Çok mağazalı yapıya geçerken değişen üç şey

  • Stok: mağaza bazlı stok ve mağazalar arası transfer süreci gerekir.
  • Fiyat: mağaza/bölge bazlı fiyat farkı ve yetki devri tanımlanmalıdır.
  • Yetki: mağaza müdürü hangi iskontoyu onaylayabilir, hangi işlem bölge onayı ister?

Tek mağaza için yazılmış bir veri modeli bu üç noktada kırılır; çok mağazalı yapı en baştan veri modeline yazılmalıdır.

Sık sorulan sorular

Kasa çevrimdışıyken stok nasıl doğru kalır?

Kasa yerel stok sayacını düşer, merkez ise satış kayıtları ulaştığında kendi bakiyesini günceller. Kısa süreli sapma kabul edilir. Kritik olan, negatife düşen stok durumunda kasanın satışı engellemek yerine uyarıp kaydı işaretlemesidir; aksi hâlde çevrimdışı çalışma amacı ortadan kalkar.

Çevrimdışı süre ne kadar olabilir?

Sınırı kuyruk boyutu ve fiyat/kampanya verisinin tazeliği belirler. Uygulamada bir üst sınır tanımlanır ve bu süre aşıldığında kasa, yöneticiye uyarı gösterir. Sınırsız çevrimdışı çalışma, eski fiyatla satış riskini büyütür.

İade işlemi çevrimdışı yapılabilir mi?

Fiş referansı kasada bulunabiliyorsa yapılabilir. Başka bir mağazadan yapılan satışın iadesi çevrimdışıyken güvenli değildir; bu senaryoda işlem merkez erişimi gerektirmelidir.