Nordlet

← Blog

ERP Sistemleri Nasıl Çalışır: Modüller, Veri Akışı ve Temeldeki Defter

Bir işlemin ERP'nin tüm modüllerindeki yolculuğu, gerçek yevmiye kayıtları ve genel defterin diğer her şeyin okuduğu tek kaynak olmasının nedeni.

Nordlet Team · · 8 dk okuma

Bir ERP sistemi, her ticari olayı tek bir veritabanına bir kez kaydederek ve her modülün bu paylaşılan kaydı okuyup yazmasına olanak tanıyarak çalışır. Gönderilmiş bir sipariş; ister depodaki personel, ister satış ekibi, isterse muhasebeci tarafından incelensin, her zaman aynı kayıttır. Tüm sistemin tutarlı kalmasını sağlayan modül ise genel defterdir (general ledger): Para değeri taşıyan her olay burada dengeli bir yevmiye kaydıyla (journal entry) sonlanır ve her rapor bu kayıtlardan türetilir.

Bu makale, bir satış işlemini modüller boyunca takip ederek ürettiği yevmiye kayıtlarını gösterecek ve bir ERP entegrasyonunun ekranlar etrafında değil, olaylar (events) ve defter etrafında dönmesinin nedenini açıklayacaktır.

Paylaşılan veritabanı

ERP'den önce her departman kendi programını çalıştırırdı. Stok bir depo sisteminde, faturalar bir faturalandırma sisteminde, defterler ise bir muhasebe paketinde yer alırdı. Ay sonları bu üçünü mutabık hale getirmekle (reconciling) geçerdi. ERP yazılımı nedir yazısı bu kategoriyi açıklar; sistemin çalışmasını sağlayan mekanizma ise şu unsurları içeren tek bir veri modelidir:

  • iş ortağı (partner) kaydı, satış, satın alma ve defter tarafından ortaklaşa kullanılır,
  • kalem (item) kaydı stok miktarını, FIFO maliyet katmanlarını, satış fiyatını ve gelir hesabını barındırır,
  • bir belge (sipariş, fatura, alacak dekontu, satın alma, üretim emri) iş ortaklarına ve kalemlere atıfta bulunur ve tam olarak bir yevmiye kaydı seti üretir,
  • bir yevmiye kaydı, kendisini üreten belgeye atıfta bulunur, böylece bir rapordaki her rakam kaynağına kadar takip edilebilir.

Kayıtlar paylaşıldığında, modüller arasında mutabakat yapılacak bir şey kalmaz. Mutabakat yapılması gereken tek yer dış dünyadır: banka ekstresi ve vergi beyannameleri.

Modül haritası

Modül Yazar (Yazar-Yazar) Okur
Satış Siparişler, faturalar, alacak dekontları İş ortakları, kalemler, fiyatlar, KDV kuralları
Satın Alma Satın alma siparişleri, tedarikçi faturaları İş ortakları, kalemler, gider hesapları
Envanter Stok hareketleri, FIFO maliyet katmanları, sayımlar Kalemler, depolar
Üretim Üretim emirleri, bileşen tüketimi, mamuller Ürün reçeteleri, stok
Banka İçe aktarılan işlemler, ödeme eşleşmeleri Açık faturalar, banka hesapları
Bordro Bordro çalıştırmaları, kesintiler, beyanlar Çalışanlar, sözleşmeler, vergi tabloları
Varlıklar Varlık sicili, amortisman çalıştırmaları Varlık grupları, faydalı ömürler
Vergi KDV beyannameleri, AB satış listeleri, Intrastat, e-faturalar Düzenlenen ve kaydedilen belgeler
Genel defter Yevmiye kayıtları, dönem kilitleri Yukarıdaki her şey
Raporlama Hiçbiri Genel defter ve muavin defterler

Son ikisi hariç her satır, genel deftere bir yazma işlemiyle biter. Bu, bir ERP'yi bir dizi birbirine bağlı araçtan ayıran tasarım kuralıdır.

Uygulamalı bir veri akışı

Aşağıdaki örnekte Nordlet uç noktaları (endpoints) ve sistemle birlikte gelen Litvanya hesap planının varsayılan hesapları kullanılmaktadır. Her ERP aynı adımları uygular; hesap kodları ve uç nokta adları farklılık gösterir.

1. Sipariş

Bir e-ticaret mağazası POST /v1/ecommerce/orders/create aracılığıyla bir sipariş verir: bir iş ortağı, kalemler ve miktarlar içeren satırlar ve sevkıyat ülkesi. Deftere henüz hiçbir kayıt atılmaz. Sipariş bir taahhüttür, bir işlem değildir.

2. Stok rezervasyonu

orders/reserve çağrısı, aynı birimlerin ikinci bir siparişle satılmasını önlemek için miktarları ayırır. Yine yevmiye kaydı yoktur: rezerve edilmiş stok hâlâ şirkete aittir.

3. Karşılama (Fulfilment)

orders/fulfill malların depodan çıkışını kaydeder. Tek bir veritabanı işleminde iki şey gerçekleşir:

  • Stok FIFO maliyeti üzerinden tüketilir: Her kalem için en eski maliyet katmanları ilk olarak kullanılır. Bu yöntem, FIFO envanter değerlemesi sözlük maddesinde açıklanan yöntemdir.
  • Bu birimlerin maliyeti; satılan malın maliyetine borç, stoğa alacak kaydı olarak bir yevmiye kaydı şeklinde işlenir.
Hesap Borç Alacak
6000 Satılan Malın Maliyeti 600.00
2040 Stok 600.00

Karşılama aynı zamanda sipariş için bir taslak fatura oluşturur ve AB KDV motoru yardımıyla sevkıyat ülkesine göre KDV uygulamasını belirler.

4. Fatura düzenleme

Faturanın düzenlenmesi, anlık (point-in-time) bir satış için gelirin tahakkuk ettiği andır. Belge, atlamasız (gapless) numarasını alır ve dengeli tek bir kayıt işlenir: brüt tutar alacaklara, KDV hesaplanan KDV hesabına ve net tutar gelir hesabına yazılır.

%21 Litvanya KDV oranına sahip 1.000 € net satış için:

Hesap Borç Alacak
2410 Ticari Alacaklar 1,210.00
5000 Mal Satış Gelirleri 1,000.00
4492 Ödenecek Hesaplanan KDV 210.00

Bir satır anlık satış dışında bir gelir tahakkuk yöntemine sahipse, net tutar ertelenmiş gelirlere gider ve gelir tahakkuk motoru bunu takvime göre serbest bırakır. Alacaklar ve KDV kayıtları bundan etkilenmez.

Fatura artık PDF olarak, Peppol BIS 3.0 e-fatura formatında veya şirketin ülkesinin gerektirdiği ulusal e-fatura formatında gönderilebilir.

5. Banka eşleştirmesi

İki hafta sonra 1.210 € hesaba gelir. Bu hareket, bir PSD2 banka akışı veya bir camt.053 hesap özeti içe aktarımı aracılığıyla sisteme girer. Banka modülü aday faturaları tutara, ödeme referansına, karşı taraf adına ve IBAN'a göre puanlar ve bank/transactions/match mutabakatı işler:

Hesap Borç Alacak
2710 Banka 1,210.00
2410 Ticari Alacaklar 1,210.00

Fatura durumu ödendi olarak değişir ve bir sale_invoice.paid webhook olayı tetiklenir. Ödeme mutabakatı maddesi eşleştirme mantığını daha ayrıntılı olarak açıklar. Başka bir para birimindeki bir ödeme, gerçekleşen kur farkını aynı adımda gelir veya gider hesabına kaydeder.

6. KDV beyannamesi

Ay sonunda hiçbir veri elle yeniden girilmez. KDV beyannamesi, düzenlenen ve kaydedilen belgelerden hesaplanır: Ulusal beyanname (Litvanya'da FR0600) için declarations/eu/vat-return/compute, Birlik düzenlemesi (Union scheme) kapsamındaki sınır ötesi tüketici satışları için declarations/eu/oss/compute kullanılır. Yukarıdaki satış, KDV şeması domestic (yurtiçi) olduğu için yurtiçi beyannamenin standart oranlı hanesine yazılır.

7. Dönem kilidi

Beyanname verildiğinde ledger/periods/lock ile ay kapatılır. O andan itibaren, geç bir banka eşleştirmesi veya yeniden denenen bir API çağrısı dahil olmak üzere bu döneme tarihlenen herhangi bir kayıt HTTP 409 hatasıyla reddedilir. Kilitleme ayrıca dönem sonuna kadar gerçekleşmesi gereken ertelenmiş gelirlerin tahakkukunu tetikler, böylece kazanılmış gelir borç hesabında bırakılarak bir ay kapatılamaz.

Defter neden yasal kayıt sistemidir?

Yukarıdaki her modül bir muavin defter (subledger) tutar: müşterilere göre alacaklar, tedarikçilere göre borçlar, kalemlere göre stok, varlıklara göre varlıklar. Genel defter, bu muavin defterlerin mutabık olması gereken toplamları barındırır. Muavin defter ile genel defter ilişkisi bu durumu kapsar; pratik açıdan bakıldığında, genel defterden oluşturulan bir rapor ile muavin defterden oluşturulan bir rapor aynı rakamı vermelidir ve bir ERP, her ikisini de aynı yevmiye kayıtlarından üreterek bunu garanti eder.

Defteri güvenilir bir kayıt kaynağı yapan üç özellik vardır:

  1. Bakiye zorunluluğu. Nordlet'te veritabanı, borçların alacaklara eşit olmadığı bir kaydı reddeder. Bir modüldeki hata, dengesiz bir kayıt oluşturamaz.
  2. Geçmişin sadece eklemeli (append-only) olması. Deftere işlenmiş bir kayıt asla düzenlenmez. Bir hata, orijinaline bağlı olan bir ters kayıt ve yeni bir kayıtla düzeltilir. Değiştirilemez defter (immutable ledger) maddesi denetçilerin bu konuda neden ısrarcı olduğunu açıklar.
  3. Dönemlerin kapanması. Kilitli bir ay değiştirilemez, dolayısıyla beyan ettiğiniz rakamlar sistemde kalan rakamlardır.

Entegrasyon: Gecelik toplu işler yerine olaylar (events) ve idempotency

Eski ERP entegrasyonları geceleri değiş tokuş edilen dosyalarla çalışırdı: siparişleri dışarı aktar, içeri aktar, sabah hata günlüğünü kontrol et. Modern ERP'ler bir API sunar ve entegrasyon iki disiplin etrafında şekillenir.

Dışa doğru olaylar (Events out). Bir şey değiştiğinde ERP bunu size bildirir. Nordlet, her webhook olayını değişiklik ile aynı veritabanı işleminde bir gidenler kuyruğuna (outbox) yazar; böylece geri alınan (rolled back) bir belge asla bir olay yaymaz ve hiçbir olay kaybolmaz. Teslimatlar HMAC-SHA256 ile imzalanır ve üstel artan bekleme süresiyle (exponential backoff) yeniden denenir. Sisteminiz her beş dakikada bir her şeyin ödenip ödenmediğini sormak yerine sale_invoice.paid olayına tepki verir.

İçeriye doğru güvenli yeniden denemeler (Safe retries in). Ağlar kesintiye uğrayabilir ve yeniden denenen bir istek ikinci bir fatura oluşturmamalıdır. Nordlet, veri değiştiren her çağrıda bir Idempotency-Key üst bilgisini (header) kabul eder: aynı yük (payload) ile aynı anahtar saklanan yanıtı döndürür, farklı yük ile aynı anahtar reddedilir ve anahtarlar 24 saat sonra geçerliliğini yitirir. Idempotency sözlük maddesi ve API kuralları tam davranışı açıklar.

Her işlem bir POST /v1/{module}/{resource}/{action} çağrısı olduğundan ve uygulama aynı uç noktaları kullandığından, bir entegrasyon kimse bir ekran açmak zorunda kalmadan yukarıdaki akışın tamamını çalıştırabilir. Bir bulut muhasebe API'si bir SaaS platformuna nasıl entegre edilir yazısı böyle bir yapının adım adım kurulumunu ele alır.

Raporlama neyi okur?

Raporlar rakamları saklamaz. Raporlar, belirli bir andaki genel defter ve muavin defterler üzerinde yapılan sorgulardır:

  • Mizan, bilanço, gelir tablosu ve nakit akış tablosu, hesap ve döneme göre yevmiye kayıtlarını okur.
  • Yaşlandırma raporları, vade tarihine göre açık alacak ve borçları okur.
  • Stok bakiyesi ve hareketi, envanter muavin defterini ve FIFO katmanlarını okur.
  • KDV özeti, düzenlenen ve kaydedilen belgelerin KDV satırlarını okur.
  • Maliyet merkezi raporları, her yevmiye satırındaki maliyet merkezi boyutunu okur.

Nordlet'te bir rapor arka planda XLSX, PDF veya JSON olarak oluşturulur ve dosya hazır olduğunda bir webhook tetiklenir. Grup rakamları, birden fazla şirketin defterlerini sahiplik payı ve para birimi çevrimi ile birleştiren konsolidasyon yoluyla elde edilir.

Pratikte bu sistem nerede aksar?

Çoğu ERP sorunu yazılımdan değil, paylaşılan kayıt ilkesinin ihlal edilmesinden kaynaklanır. Yaygın durumlar şunlardır:

  • ERP'nin "yapamadığı" bir şey için kullanılan ve daha sonra defterlerle çelişen paralel bir e-tablo (spreadsheet).
  • Belgeyi düzeltmek yerine modül çıktısını düzeltmek için kullanılan ve rapordan kaynağa giden izlenebilirliği bozan manuel yevmiye kayıtları.
  • Belge yerine bakiyeleri yazan ve böylece defterin kimsenin açıklayamadığı toplamlar barındırmasına neden olan entegrasyonlar.
  • Aylarca kilitlenmeden bırakılan açık dönemler, bu da geçen çeyreğin beyan edilen rakamlarının kaymasına neden olur.

ERP uygulamaları neden başarısız olur yazısı bu alışkanlıkların bir dağıtım sırasında nasıl oluştuğunu kapsar ve gerçekçi ERP uygulama takvimleri projenin neresinde ortaya çıktıklarını gösterir.

FAQ

Bir ERP sisteminin çekirdeği nedir?

Genel defter ve etrafındaki paylaşılan veri modelidir. Her modül dengeli yevmiye kayıtları üreten belgeler yazar ve her rapor bu kayıtlardan türetilir.

Veri bir ERP içinde nasıl akar?

Bir olay belge olarak bir kez kaydedilir (sipariş, fatura, hareket, bordro çalıştırma). Belge, defterde yevmiye kayıtları ve ilgili muavin defterde hareketler üretir. Raporlar ve vergi beyannameleri bu kayıtlardan hesaplanır. Modüller arasında hiçbir veri kopyalanmaz.

Modül ile entegrasyon arasındaki fark nedir?

Bir modül, sistemin geri kalanıyla aynı veritabanına ve aynı deftere yazma yapar. Bir entegrasyon ise ERP'nin API'sini çağıran harici bir programdır. API odaklı bir ERP'de bu ayrım küçüktür, çünkü entegrasyon modüllerin kullandığı uç noktaların aynısını kullanır.

Bir ERP muhasebe kayıtlarını otomatik olarak işler mi?

Evet. Fatura düzenlemek, sipariş karşılamak, ödeme eşleştirmek, bordro çalıştırmak veya bir varlığı amortismana tabi tutmak, bir kişinin borç ve alacak oluşturmasına gerek kalmadan kendi yevmiye kaydını üretir. Kullanılan hesaplar, şirket bazında değiştirilebilen deftere nakil kurallarından (posting rules) gelir.

ERP'ler muhasebe dönemlerini neden kilitler?

Bir dönem için raporlanan veya beyan edilen rakamların daha sonra değiştirilememesi için. Kilitli bir dönem yeni kayıtları reddeder; bu da denetim izini (audit trail) korur ve düzeltmelerin görünür oldukları cari döneme yapılmasını zorunlu kılar.

İleri okuma