Çok şubeli işletme yazılımı, her kayda yalnızca bir şube alanı eklemekten ibaret değildir. Merkezin hangi veriyi yöneteceği, şubenin hangi kararı vereceği ve işlemlerin şubeler arasında nasıl hareket edeceği açık bir veri kapsamı ister.
Merkezî ve yerel kararları ayırın
Ürün kodu, fiyat politikası ve hesap planı merkezden yönetilebilirken müşteri kabulü, yerel stok sayımı veya personel vardiyası şubeye bırakılabilir. Her veri kümesi için “sahibi kim, kim görebilir, kim değiştirebilir?” sorularını yanıtlayan bir yetki matrisi oluşturun.
Merkez kullanıcısının tüm kayıtları görmesi, her kaydı değiştirmesi gerektiği anlamına gelmez. Onay, düzeltme ve yalnızca raporlama yetkileri ayrı tutulduğunda hatalı müdahale riski azalır.
Şubeler arası işlemi çift taraflı düşünün
Transfer, gönderen şubede çıkış ve alıcı şubede giriş olarak tek transaction mantığıyla izlenmelidir. Yolda, kısmi kabul, ret ve iptal durumları olmadan yalnızca stok miktarı değiştirilirse iki şube arasında açıklanamayan farklar oluşur. Her hareketin kaynak belgesi ve zaman çizgisi korunmalıdır.
Ortak raporda aynı tanımı kullanın
- Satış tarihi sipariş mi, fatura mı?
- Şube cirosu vergi dâhil mi, hariç mi?
- Stok değeri hangi maliyet yöntemiyle hesaplanıyor?
- İade hangi döneme ve hangi şubeye yazılıyor?
Bu tanımlar rapor ekranından önce veri sözleşmesine yazılmalıdır. Çok kullanıcılı özel yazılım tasarımında şube kapsamı backend seviyesinde uygulanır; yalnızca arayüz filtresine güvenilmez.
Şube açma ve kapama senaryosu
Yeni şubenin kod, depo, kullanıcı, fiyat ve onay ayarlarını hangi şablondan alacağı belirlenmelidir. Kapanan şubenin geçmiş verisi silinmez; yeni işlem kabul etmeden raporlarda doğru dönemle görünür kalır. Personel başka şubeye geçtiğinde eski kayıtların sahipliği ve yeni veri kapsamı ayrı ele alınır. Bu yaşam döngüsü test edilmezse ilk kurulum çalışan sistem, organizasyon değiştiğinde manuel ve riskli düzeltmelere bağımlı hâle gelir.