Çok Kanallı POS Yazılımı: Mağaza–E-Ticaret

Hem vitrinde hem sitede satıyorsanız en sık kırılan halka kasadır: mağazada satılan ürün sitede hâlâ “stokta” görünür, fiyat listesi gecikir, fiş ile e-fatura birbirini tutmaz. Çok kanallı POS yazılımı, sipariş paneli veya e-ticaret arayüzünün yerini almaz; kasa, barkod, fiş ve offline satışı online stok ve fiyatla aynı gerçeklik üzerinde tutar. Bu rehber, OMS ile farkı netleştirir; senkron gereksinimlerini, offline–fiş–e-fatura akışını, donanım uyumunu ve pilot mağaza kontrol listesini adım adım kurar.

Omnichannel POS nedir, OMS ve e-ticaret panelinden farkı

Omnichannel POS, fiziksel noktada yapılan her satış ve iade hareketini tek ürün–stok–müşteri kaynağına yazan kasa katmanıdır. Amaç “her yerden sipariş almak” değil; mağaza hareketinin saniyeler içinde (veya bağlantı gelince) online kanala yansımasıdır.

OMS ile POS aynı şey mi?

OMS (sipariş yönetim sistemi) site, pazaryeri ve mağaza siparişlerini toplar, depo ataması ve kargo etiketi üretir. POS ise mağaza anında tahsilat, barkod okuma, fiş basımı ve offline kuyruk işidir. OMS’siz POS ile mağaza–site stoku senkron edilebilir; POS’suz OMS ise kasa ekranı, yazarkasa/e-fatura fişi ve offline satışı karşılamaz. İkisi birbirini tamamlar, birbirinin yerine geçmez.

E-ticaret paneli neden kasa olmaz?

E-ticaret paneli ürün kartı, sepet ve sanal ödeme için tasarlanmıştır. Mağazada ihtiyaç duyduğunuz şeyler genelde şunlardır:

• Barkodla hızlı ürün bulma ve varyant seçimi
• Nakit, kart, karışık ödeme ve para üstü
• Fiş / e-arşiv / e-fatura tetikleme
• İnternet kesilince satışa devam, sonra senkron
• Kasa devir, vardiya kapanışı ve Z/X benzeri günlük özet

Panelden “manuel stok düşürme” ile günü kurtarmak, yoğun saatte hata ve stok çakışması üretir. Çok kanallı bir POS, bu hareketi otomatik ve izlenebilir yapar.

Stok, fiyat ve müşteri senkron gereksinimleri

Entegrasyon “ürün gitsin gelsin” demek değildir. Önce hangi verinin tek kaynak olduğunu yazın; aksi halde mağaza ve site birbirini ezer.

Tek kaynak karar matrisi

Stok senkronunda kaçınılacak tuzaklar

• Çift rezervasyon: Site sepeti stok ayırırken mağaza aynı SKU’yu satarsa “satıldı ama kargolandı” oluşur. Rezerv süresi ve satılabilir stok formülü net olmalı.
• Varyant kayması: Beden/renk barkodu tek SKU’ya map edilmezse yanlış stok düşer.
• İade yönü: Mağazaya iade edilen ürün hangi lokasyona yazılacak? Online siparişin mağaza iadesi ayrı kural ister.
• Sayım farkı: Fiziksel sayım sonucu POS’tan merkeze yansımazsa ertesi gün online stok yine bozulur.

Fiyat ve kampanya

Mağaza etiketindeki fiyat ile ürün sayfası fiyatı farklıysa güven kaybı anlıktır. POS’un kampanya motoru ya merkezi kuralları okumalı ya da mağaza özel etiketleri merkeze “istisna” olarak bildirmelidir. Saatlik flash indirim kullanıyorsanız kasa saat senkronu (NTP) ve kural bitiş zamanı test edilmeden canlıya çıkmayın.

Müşteri verisi ve KVKK disiplini

Kasa ekranında gereksiz kimlik alanı açmayın. Telefon veya sadakat numarası ile eşleme çoğu perakende senaryosu için yeterlidir. Aydınlatma metni, açık rıza ve saklama süreleri iş sürecinize göre hukuk danışmanıyla netleştirilmelidir; yazılım tek başına uyum belgesi değildir.

Offline satış, fiş ve e-fatura akışı

Mağaza interneti her zaman stabil değildir. İyi bir çok kanallı POS yazılımı, bağlantı kopunca satışı durdurmaz; güvenli bir kuyrukta tutar.

Offline çalışma için minimum beklenti

1. Yerel ürün–barkod–fiyat önbelleği (son başarılı senkron anı)
2. Satış fişi ve ödeme kaydının cihaz veya yerel sunucuda tutulması
3. Bağlantı gelince stok ve sipariş hareketinin merkeze basılması
4. Çakışma kuralı: aynı SKU online’da da satıldıysa hangi kanalın kazanacağı ve nasıl düzeltileceği
5. Vardiya kapanışında offline kuyruk boş mu kontrolü

Offline’da “stok garantisi” yoktur; sadece son bilinen stokla satış yapılır. Yüksek riskli SKU’larda (tek adet, yüksek bedel) offline satışı kısıtlamak operasyonel bir tercihtir.

Fiş, e-arşiv ve e-fatura

Perakendede fiş basımı ile e-belge süreci iç içedir. POS seçerken şunları net isteyin:

• Hangi belgenin (fiş, e-arşiv, e-fatura) hangi tutar/müşteri tipinde tetikleneceği
• Özel entegratör veya GİB uyumlu akışın kasa adımına gömülü olup olmadığı
• İptal ve iade belgelerinin orijinal satışla bağlanması
• Gün sonu toplamlarının muhasebe veya ön muhasebe aktarımına hazır olması

Yasal belge zorunlulukları işletme türü ve cirosuna göre değişir; güncel yükümlülük için mali müşavir onayı alın. Yazılım “e-fatura keser” demek, sizin mükellefiyetinizi otomatik karşılamaz.

Donanım–yazılım uyumu ve seçim kriterleri

Yazılım güzel, yazıcı fiş basmıyorsa kasa işlemez. Seçimi özellik listesinden değil, saha senaryosundan yapın.

Donanım kontrol listesi

• Barkod okuyucu: 1D/2D, el tipi veya gömülü; hızlı tarama ve Türkçe karakterli etiketler
• Fiş yazıcı: Termal bağlantı (USB/Ethernet), kâğıt genişliği, logo/QR basımı
• Müşteri ekranı: Tutar ve kampanya görünürlüğü
• Ödeme terminali: Banka/POS cihazı entegrasyonu veya manuel tutar girişi disiplini
• Kasa çekmecesi ve terazi: Gıda / gramajlı ürün varsa
• Yedek cihaz: Tablet veya ikinci kasa; tek noktada arıza riski

Yazılım seçim kriterleri (ticari niyet net)

1. Çok lokasyon stok modeli: Mağaza A satınca yalnız A düşmeli; depo ve diğer mağazalar ayrı
2. API / webhook olgunluğu: E-ticaret, muhasebe ve sadakat ile çift yönlü akış — ayrıntılı plan için API entegrasyonu planlama rehberi faydalı bir çerçeve sunar
3. Offline kuyruk ve çakışma raporu: “Sessiz kayıp satış” olmamalı
4. Rol ve yetki: İndirim limiti, iade onayı, kasa açılış/kapanış
5. Rapor: Ürün, kasa, vardiya, ödeme tipi; Excel’e bağımlı kalmayın
6. Güncelleme ve cihaz yönetimi: Mağaza bilgisayarlarına uzaktan sürüm basılabilmeli
7. Eğitim yükü: Yeni kasiyer 1–2 vardiyada fiş kesebilmeli

HazırSoft tarafında perakende ve e-ticaret yazılım ihtiyaçlarını katalogdan süzmek isteyenler hazır yazılım kataloğu üzerinden ilgili çözümleri inceleyebilir; karar yine sizin operasyon senaryonuza göre verilmelidir.

Pilot mağaza kurulumu ve kontrol listesi

Tüm mağazalara aynı anda basmak, stok ve eğitim riskini katlar. Tek mağaza + sınırlı SKU ile pilot koşun.

Pilot öncesi hazırlık

• SKU ve barkod temizliği: mükerrer barkod, eksik varyant, “adı var stoğu yok” kartlar
• Lokasyon tanımları: depo, mağaza, “satılabilir” ve “rezerve” ayrımı
• Fiyat listesi ve aktif kampanyaların kasa ile aynı kaynaktan gelmesi
• Kasiyer rolleri, indirim tavanı, iade yetkisi
• E-belge test ortamı (mümkünse) ve iptal senaryosu denemesi
• İnterneti bilerek kesip offline satış + geri senkron denemesi

Pilot haftası günlük kontrol

1. Sabah: stok ve fiyat senkron saati, başarısız iş kuyruğu var mı?
2. Öğle: rastgele 10 SKU’nun mağaza–site adedi aynı mı?
3. Yoğun saat: barkod okuma süresi ve fiş basım gecikmesi loglanıyor mu?
4. Akşam: vardiya kapanışı, nakit–kart mutabakatı, offline kuyruk boş mu?
5. Ertesi sabah: bir önceki günün e-belge / muhasebe aktarımı tutuyor mu?

Canlıya geçiş kriterleri (örnek eşik)

Sayısal “garanti” vermeden, ekibin kendi eşiğini yazması gerekir. Pratik örnekler: pilot süresince çözülmemiş stok çakışması kalmamış olması; kasiyerlerin yazılı prosedür olmadan standart satışı tamamlayabilmesi; iade ve iptalin orijinal fişe bağlanabilmesi; destek ekibinin uzaktan log okuyabilmesi.

Yaygın operasyon hataları

• Mağaza “kendi Excel fiyatını” kullanmaya devam etmek
• Sayımı POS dışında yapıp merkeze hiç yazmamak
• Aynı ürünü hem gramaj hem adet barkoduyla karışık satmak
• Entegrasyonu yalnız “ürün aktarımı” sanıp sipariş/iade yönünü test etmemek
• Onay ve istisna süreçlerini e-postada bırakmak — tekrarlayan mağaza onayları için iş akışı otomasyonu disiplini işe yarar

Uygulanabilir entegrasyon çerçevesi

Teknik ekip veya yazılım ortağınızla şu sırayı sabitleyin:

1. Veri sözleşmesi: Hangi alan tek kaynak, hangi olay (satış, iade, sayım, fiyat) kimi tetikler
2. Kimlikler: SKU, barkod, lokasyon ID, müşteri ID eşlemesi
3. Olay yönü: POS → merkez (satış), merkez → POS (fiyat, yeni ürün), iki yönlü stok mutabakatı
4. Hata kuyruğu: Başarısız kayıt silinmez; alarm ve yeniden deneme
5. Güvenlik: Cihaz yetkisi, API anahtarı rotasyonu, kasa kullanıcısı paylaşılmaması
6. Dokümantasyon: Mağaza prosedürü kısa ve görsel; uzun PDF rafta kalır — süreç dokümanlarını düzenli tutmak için doküman yönetim sistemi seçimi yaklaşımı yardımcı olur

Kurumsal ölçekte birden fazla marka veya franchise varsa “merkez fiyatı zorunlu / mağaza indirimi tavanlı” gibi politika motoru şarttır. KOBİ ölçeğinde ise sade tutun: az kural, sık mutabakat, temiz barkod.

Sonuç: kasayı kanalın parçası yapın

Çok kanallı POS yazılımı, vitrin ile sepeti aynı stok ve fiyat gerçeğinde buluşturur. OMS siparişi taşır; e-ticaret paneli kataloğu yönetir; POS ise mağaza anını kaydeder. Seçim ve kurulumda tek kaynak veriyi, offline kuyruğu, fiş–e-belge bağını ve pilot mutabakatı önceleyin. İhtiyaçlarınıza uygun yazılım seçeneklerini değerlendirmek için HazırSoft üzerindeki ilgili kategorilere bakabilir, entegrasyon planınızı mağaza gerçeğiyle test ederek ilerleyebilirsiniz.