Sektörel çözüm mimarisi

Çok Şubeli Perakende

Şube, kanal, stok ve tahsilat aynı ticari omurgada.

Şube bağımsız çalışabilen kasa, merkezi fiyat ve kampanya dağıtımı, mağazalar arası transfer ve gün sonu mutabakatı.

Çok Şubeli Perakende
Saha gerçeği + ERP + çalışan ürünler
Kritik süreç zinciri

Bir noktadaki değişiklik, bütün operasyonda görünür.

  1. 01Kanal ve fiyat
  2. 02Şube ve stok
  3. 03Satış ve ödeme
  4. 04İade ve mutabakat
Sektör rehberi

Çok şubeli perakendede kritik karar

Kritik karar merkezîleşmenin derecesidir: fiyat ve kampanya merkezden yönetilmeli, ancak satış işlemi şubede merkezden bağımsız tamamlanabilmelidir. Merkezden onay bekleyen bir kasa tasarımında hat kesintisi doğrudan ciro kaybına dönüşür. Bu mimariyi çevrimdışı POS tasarımı rehberimizde ayrıntılı anlatıyoruz.

Kritik süreçler

  • Çevrimdışı satış: Yerel fiyat/kampanya kopyası, satış kuyruğu ve bağlantı gelince çakışmasız senkronizasyon.
  • Merkezi fiyat ve kampanya: Kural setinin sürümlenmesi ve hangi kasanın hangi sürümle çalıştığının izlenmesi.
  • Şube bazlı stok: Mağaza stoğu, mağazalar arası transfer, transfer onayı ve yoldaki stok.
  • Gün sonu mutabakatı: Kasa satış toplamı, mali cihaz raporu, banka POS toplamı ve fiziksel sayımın karşılaştırılması.
  • Yetki matrisi: Mağaza müdürünün onaylayabileceği iskonto ve iade sınırları.
  • Sadakat ve müşteri: Puan bakiyesinin çevrimdışı limitle çalışması.

Hangi çözüm neye karşılık geliyor?

Kasa ve mağaza operasyonu için perakende POS, online kanal ve pazaryeri için e-ticaret yazılımı, müşteri ve kampanya yönetimi için CRM, personel vardiya ve mesai hesabı için PDKS kullanılır. Merkez stok, satın alma ve maliyet ERP danışmanlığı kapsamındadır. Şube ağı ve hat yedekliliği kurumsal ağ çözümleri tarafında planlanır.

Zorunlu entegrasyonlar

Yeni nesil ÖKC ve ödeme cihazları, banka POS mutabakatı (banka entegrasyonu), e-fatura ve e-arşiv, terazi ve barkod donanımı, pazaryeri kanalları, kargo firmaları ve muhasebe.

Nereden başlıyoruz?

Çok şubeli perakendede başlangıç durumu çoğunlukla şudur: her mağazada yerel bir kasa programı, merkezde ayrı bir stok programı ve aralarında günlük dosya aktarımı. Fiyat değişikliği mağazalara elle iletilir, gün sonu farkları haftalar sonra fark edilir.

İlk çalışmanın çıktısı hangi kararın nerede alınacağının haritasıdır: fiyat merkezde, iskonto yetkisi mağaza müdüründe, iade kuralı merkezde, stok sayımı mağazada. Bu harita netleşmeden ne kasa tasarımı ne de yetki matrisi kurulabilir.

Veri modelinde net olması gerekenler

  • Fiş satırı: Kasa kimliği, kasiyer, ürün, miktar, uygulanan kampanya kuralı ve kural sürümü.
  • Ödeme satırı: Ödeme tipi, cihaz işlem numarası, taksit ve banka referansı — fiş toplamıyla ayrı satırlar hâlinde.
  • İade referansı: Hangi fişe karşı iade yapıldığı; referanssız iade ayrı bir işlem türü olarak işaretlenmeli.
  • Kampanya sürümü: Kural setinin sürüm numarası ve hangi kasada hangi sürümün aktif olduğu.
  • Transfer durumu: Çıkış, yolda ve kabul aşamaları ayrı; tek adımlı transfer stok farkı üretir.
  • Sayım oturumu: Sayan kişi, tarih, sayım öncesi ve sonrası stok; düzeltme kaydı ayrı tutulmalı.

Devreye alma sırası

  1. Tek mağaza pilotu: Kasa, fiyat, kampanya ve gün sonu akışının tek şubede uçtan uca çalıştırılması.
  2. Merkez entegrasyonu: Fiyat/kampanya dağıtımı, satış aktarımı, banka POS mutabakatı.
  3. Çoklu mağaza: Transfer akışı, mağazalar arası stok görünürlüğü, yetki matrisi.
  4. Kanal genişletme: Online kanal, pazaryeri ve mağaza stoğunun yayına açılması.

Pilot mağazanın seçimi önemlidir: en kolay değil, en karmaşık şube seçilmelidir. Kolay mağazada çalışan bir kurgu, yaygınlaştırmada kırılır.

Neyi ölçüyoruz?

  • Gün sonu farkının kaynağına göre dağılımı (kasa, banka POS, sayım)
  • Kasa başına çevrimdışı çalışma süresi ve kuyrukta bekleyen işlem sayısı
  • Kampanya kural sürümünün mağazalara ulaşma süresi
  • Mağazalar arası transferin kabul edilme süresi ve yoldaki stok tutarı
  • Referanssız iade oranı

Sık yapılan hatalar

  • Kasayı merkeze bağımlı tasarlamak. Hat kesildiğinde satış durur; bu, mimari bir tercihtir, altyapı sorunu değil.
  • Kampanyayı sürümlememek. Geçmiş fişin hangi kuralla hesaplandığı sonradan doğrulanamaz.
  • Transferi tek adımda kapatmak. Yoldaki stok görünmez, sayım farkı transfer farkıyla karışır.
  • Mağaza stoğunu sayım doğruluğu olmadan online kanala açmak. Aşırı satışın en sık nedeni budur.

Sık sorulan sorular

Mağaza stoğunu online satışa açmalı mıyız?

Açabilirsiniz, ancak ön koşul mağaza sayım doğruluğudur. Sayım güvenilir değilken mağaza stoğunu yayına açmak, aşırı satışın en sık nedenidir; konuyu e-ticaret stok senkronizasyonu rehberinde ele alıyoruz.

Kaç şubeden sonra merkezi yapı zorunlu olur?

Şube sayısından çok, mağazalar arası transfer ve merkezi kampanya ihtiyacı belirleyicidir. İki mağaza arasında bile düzenli transfer varsa merkezi stok görünürlüğü gerekir.

Gün sonu farkının kaynağı nasıl bulunur?

Her satışın kasa kimliği, kasiyer, ödeme tipi, cihaz işlem numarası ve iade referansıyla saklanması gerekir. Bu alanlar baştan tasarlanmazsa fark analizi elle yapılan bir işe döner.

Tek mağazalı işletmeler bu yapıya ihtiyaç duyar mı?

Tek mağazada merkezi dağıtım ve transfer akışı gereksizdir; ancak çevrimdışı satış, gün sonu mutabakatı ve kampanya sürümleme aynı ölçüde geçerlidir. Büyüme planı varsa, kasa mimarisinin baştan şube bağımsız tasarlanması sonradan yapılan geçişten daha az maliyetlidir.

Franchise ve kendi mağazaları aynı sistemde yönetilebilir mi?

Yönetilebilir, ancak yetki ve veri görünürlüğü ayrışmalıdır: franchise kendi cirosunu ve stoğunu görür, diğer şubeleri görmez. Bu ayrım rol bazlı yetki ile değil, veri kapsamı (scope) tanımıyla kurulmalıdır; yalnızca ekran gizleme yeterli değildir.

Mağaza personelinin vardiya ve mesai hesabı nasıl bağlanır?

Kasa oturumu ile personel kaydının aynı kimlik üzerinden eşleşmesi gerekir. Böylece kasiyer bazlı satış analizi ile PDKS verisi aynı kişide birleşir; iki ayrı personel listesi tutulduğunda eşleşme elle yapılır ve zamanla bozulur.

Sektörel ERP kapsamı

ERP bu operasyonun kayıt, planlama ve finans omurgasıdır.

ERP; ürün, stok, satın alma ve finans ana kaydını tutar. POS, e-ticaret, ödeme ve CRM ürünleri bu omurgaya anlık işlem ve saha verisi taşır.

01

Ürün, fiyat ve kampanya ana verisi

Ürün, varyant, barkod, fiyat listesi, vergi ve kampanya kuralları mağaza ile dijital kanallara tek kaynaktan dağılır.

02

Talep ve ikmal planlama

Satış hızı, sezon, güvenlik stoğu ve tedarik süresi şube bazlı ikmal ve satın alma kararına dönüşür.

03

POS, şube ve e-ticaret akışı

Satış, iade, transfer ve stok hareketleri çevrim içi ya da kesintili çalışmada aynı işlem zincirinde izlenir.

04

Tahsilat, mutabakat ve finans

Nakit, kart, banka, pazar yeri ve hediye çeki hareketleri kasa kapanışı ve muhasebe kaydıyla karşılaştırılır.

ERP’yi tamamlayan ürünler

Saha, satış, müşteri ve ödeme verisini aynı omurgaya bağlayın.

Bu ürünler ERP’nin yerine geçmez; ERP’deki ana veri ve finansal kayıtla çift yönlü çalışarak operasyonun ekrandaki karşılığını tamamlar.

FAB Perakende · Perakende

Perakende POS

İnternet kesilse de satış sürer; fiyat, kampanya ve stok merkezde kalır.

Merkez bağlantısı koptuğunda da satışa devam eden, merkezi fiyat ve kampanya yönetimiyle çalışan çok mağazalı satış noktası platformu.

  • Satış ekranı
  • Ödeme
  • Kampanya & fiyat
  • Gün sonu
  • Stok & sayım
  • Merkez raporları
FAB Ticaret · E-Ticaret

E-Ticaret ve Pazaryeri Yönetimi

Mağaza ve pazaryerlerini tek stok ve sipariş gerçeğinde birleştirin.

Kendi mağazanız ve pazaryeri kanallarınızı tek stok kaydı üzerinden yöneten; aşırı satışı önlemek için satılabilir stok mantığıyla çalışan altyapı.

  • Kanal & sipariş
FAB Ticaret kanal stoku ve sipariş havuzu ekranı
FAB CRM · Satış

CRM

İlk temastan teklife, satış ekibinin bütün hareketi tek yerde.

Müşteri, fırsat ve teklif süreçlerini tek veri modelinde birleştiren; satış hunisinin hangi aşamada tıkandığını ölçülebilir hâle getiren CRM.

  • Pipeline
  • Müşteri 360°
  • Teklif
  • Yönetici panosu
  • Mobil
FAB CRM yönetici panosu: aşama süreleri, kazanma oranı ve temsilci performansı
FAB Banka · Entegrasyon

Banka Entegrasyonu

Banka hareketlerini cari hesaplarla otomatik eşleştirin; yalnızca farklara bakın.

Desteklenen bankaların hesap hareketlerini otomatik çekip tahsilatı cari hesapla eşleştiren; farkları türüne göre listeleyen mutabakat altyapısı.

  • Hareketler & mutabakat
  • Eşleştirme kuralları
FAB Banka hareket eşleştirme ve mutabakat ekranı
Çok Şubeli Perakende

Kendi akışınız üzerinden bir çözüm oturumu planlayalım.

İletişime Geçin →
Sizi arayalım