Neden cari bakiye yerine defter tabanlı stoğu seçtik

Cari bakiyelerle ilgili sorun

Çoğu envanter sistemi konum başına kalem başına tek bir sayı saklar: eldeki mevcut miktar. Bir satın alım geldiğinde sistem buna ekler. Bir reçete stok tükettiğinde çıkarır. Basit, hızlı, sorgulaması kolay.

Ta ki bozulana kadar.

Cari bakiyeler tespit etmesi zor ve düzeltmesi daha da zor şekillerde bozulur. Arka plan görevi, fatura kaydedilirken yarıda çöker. Kullanıcı formu çift gönderir. Geliştirici, miktarları istemeden ayarlayan bir migrasyon betiği çalıştırır. Tedarikçi iadesi kısmen işlenir. Ekrandaki rakam kurguya dönüşür, ancak gerçeklikten ne zaman ve ne kadar saptığını söyleyecek geçmiş yoktur.

Defter tabanlı stok nasıl görünür

Defter tabanlı bir sistem miktarı hiçbir zaman güncellemez. Yalnızca kayıt ekler. Her stok hareketi — satın alma makbuzu, reçete tüketimi, fire olayı, transfer, stok sayımı — StockMove tablosunda yeni bir satır olur. Eldeki mevcut miktar, belirli bir kalem ve lokasyon için tüm hareketlerin toplamından türetilir.

SELECT SUM(qty) FROM stock_moves
WHERE item_id = $1 AND location_id = $2

Bu sorgu gerçeğin kaynağıdır. Senkronizasyondan çıkabilecek ayrı bir "mevcut miktar" alanı yoktur. Bir hareket yanlış kaydedildiyse, düzeltici bir hareket kaydederek düzeltirsiniz — orijinali düzenleyerek değil.

Orion mark-to-market sorunu

Bir rakip platformda gözlemlediğimiz (iç referans: "Orion mark-to-market hatası", sürümler 4.1.19'dan 6.1.20'ye) belirli bir hata biçiminden öğrendik. Sistemleri, bir tedarikçi fiyatı her güncellendiğinde tüm geçmiş tüketim hareketlerinin birim maliyetini yeniden hesaplıyordu.

Yüzeyde bu makul görünür: malzeme artık daha pahalıysa, geçmiş SMMM bunu yansıtmamalı mı? Hayır. Kapatılmış dönemlerin bütünlüğünü yok eder. Ocak'ta onayladığınız bir P&L, bir tedarikçi fiyatları artırdığı için Mart'ta değişmemelidir.

Orion hatası, bir toplu fiyat güncellemesi her çalıştığında kapatılmış aylara ait bildirilen yiyecek maliyeti yüzdelerinin sessizce 2–4 puan kaymasına neden oldu. Finans ekipleri zaten değişmiş rakamlara karşı mutabakat yapıyordu.

EYP Ops'un çözümü: değiştirilemez birim maliyetler

EYP Ops'ta her StockMove satırı, kayıt sırasında yazılan ve asla değiştirilmeyen bir unitCost alanı taşır. Bir reçete tüketiminin maliyeti, üretim kaydedildiği andaki malzemelerin ağırlıklı ortalama maliyetidir — bugünün fiyatı değil, ay sonundaki fiyat değil.

Bu şu anlama gelir:

• Kapatılmış dönemler kapalı kalır. Bir Şubat P&L'i, Şubat'ta göründüğü gibi Nisan'da da aynı yiyecek maliyetini gösterecektir.
• Fiyat değişiklikleri ileriye dönüktür. Daha yüksek fiyatlı yeni bir teslimat, o teslimatın ileriye dönük hareketlerini etkiler, geriye dönük değil.
• Denetim önemsizdir. Her SMMM satırı, her biri kayıtlı birim maliyetiyle onu oluşturan belirli stok hareketlerine izlenebilir.

Bu neden çok lokasyonlu operasyonlar için önemlidir

Birden fazla şubesi olan restoranlar bu sorunun bileşik versiyonuyla karşılaşır. Ana depodan mutfağa transfer, envanteri lokasyonlar arasında taşır. Cari bakiye saklıyorsanız, bir transfer iki satırın güncellenmesini gerektirir — ve bu iki güncelleme arasında yaşanan bir çöküş defterleri dengesiz bırakır.

Defter tabanlı stokla, bir transfer iki harekettir: kaynaktan TRANSFER_OUT ve hedefe TRANSFER_IN. Tek bir veritabanı işleminde yazılırlar. Ya ikisi de başarılı olur ya da hiçbiri olmaz. Defterler her zaman tutarlıdır.

Ana depo, mutfak, bar olmak üzere üç şube üzerinde faaliyet gösteren bir grup için defter yaklaşımı, grup P&L'iyle mutabık kılınabilecek doğru şube düzeyinde SMMM'ye giden tek uygulanabilir yoldur.

Takas: sorgu karmaşıklığı

Takas gerçektir. Her bakiye sorgusunda tüm hareketleri toplamak, tek bir alanı okumaktan yavaştır. Yıllarca geçmişe ve yüzlerce kaleme sahip bir operasyon için saf bir uygulama yavaşlayacaktır.

Çözüm defter modelini terk etmek değil — temel hareketlerin denetim bütünlüğünden ödün vermeksizin dönem toplamlarını önbelleğe alan uygun materyalize görünümler veya anlık görüntü tabloları oluşturmaktır. Önbellek yanlış olabilir; defter olamaz.

Altyapı olmadan başlamak

Bu ilkelerden bugün yararlanmak için amaca özel bir defter sistemi gerekmez. Bir elektronik tabloda bile, her hareketi kaydetme (toplam güncelleme yerine) ve kayıt sırasındaki birim maliyeti koruma pratiği size kurtarılabilir bir denetim izi verecektir. Disiplin önce gelir; otomasyon onu izler.