ERP modülleri gerçekte nasıl entegre olur

Entegre kelimesi üç farklı şeyi gizler

Neredeyse her ERP broşürü entegre kelimesini kullanır. Bu kelimenin altında, ay sonunda bir şeyler ters gittiğinde çok farklı davranan en az üç düzenleme yatar. Birincisi dosya ya da zamanlanmış toplu aktarımdır: bir sistem dışa aktarır, diğeri genellikle gece içe aktarır. İkincisi API ya da ara katman senkronizasyonudur; iki ayrı veritabanı mesaj alışverişiyle uyumlu tutulur. Üçüncüsü gerçek anlamda ortak veridir; burada modüller ayrı sistemler değil, tek bir tablo setinin, tek bir büyük defterin ve tek bir ana kayıt setinin farklı görünümleridir.

Bunların hiçbiri her durumda doğru değildir. Toplu aktarım ucuzdur, mantığı kolay kavranır ve herhangi bir taraftaki kesintiyi atlatır; çünkü dosya bekler. Ama tasarımı gereği her zaman bayattır ve başarısız bir iş, biri bir raporu sorgulayana kadar fark edilmeyebilir. API senkronizasyonu gerçek zamana yakın bir davranış sağlar ve tutmak için iyi nedenleriniz olan sistemleri korumanıza izin verir; ancak artık dağıtık bir sistemin sahibisiniz: yeniden denemeler, sıralama, kısmi hatalar ve birbiriyle çelişebilecek iki gerçek kopyası. Ortak veri, iki veritabanının birbirinden uzaklaştığı sorun sınıfını ortadan kaldırır, çünkü yalnızca bir tane vardır; ama bu, modüllerin tek bir hesap planında, tek bir stok kalemi tanımında ve tek bir sürüm takviminde uzlaşması demektir ve bu bedava bir fayda değil, bir kısıttır.

Pratik soru hangi düzeyin en iyi olduğu değil, her akışın hangi düzeyi hak ettiğidir. Bir banka ekstresinin gece aktarılması sorun değildir. Canlı bir satış noktasının arkasındaki stok seviyelerinin gece aktarılması ise sorundur. Skyline Nexus kendi modülleri için üçüncü düzeyde durur: muhasebe, satış noktası ve stok, CRM, bakım, insan kaynakları, filo ve varlıklar tek bir büyük deftere ve tek bir ana veri setine yazar; müşterinin korumaya değer bir sistemi olduğunda da dış sistemlerle API üzerinden entegre olur.

Ayrışma ana veride başlar

Entegrasyon hataları genellikle arayüzlere yüklenir, ama ilk çatlak normalde biraz farklı içerikle iki kez var olan bir ana kayıttır. İki sistemin her biri kendi müşteri listesini tuttuğu anda listeler birkaç hafta içinde ayrışır ve sonraki her rakam bu ayrışmayı devralır.

• Müşteri: satış, faturalama, tahsilat ve kredi kontrolü genelinde tek bir kimlik; aksi halde yaşlandırılmış alacaklar satış raporuyla uyuşmaz.
• Tedarikçi: satın alma, ticari borçlar ve ödemeler arasında, mükerrer olduğunda dolandırıcılık hedefi haline gelen banka bilgileri dahil ortak.
• Stok kalemi: tek kod, tek ölçü birimi, tek maliyetleme yöntemi. İki kalem ana verisi, iki stok değerlemesi demektir.
• Hesap planı: tek bir yapı. Bir modül kendi hesap listesini tutup sizinkine eşliyorsa, eşleme bakımı yapılacak ve yanlış yapılabilecek ikinci bir şeydir.
• Vergi kodları: hem işlemin hem de beyannamenin kullandığı tek bir oran, uygulama ve yürürlük tarihi tanımı.
• Şube ve lokasyon: ortak; çünkü hem stok hem de muhasebe bu boyuta göre ayrılır.
• Çalışan: bordro, devam takibi, bakım iş emirleri ve araç tahsisinin arkasında tek bir kayıt.
• Varlık: amortisman, bakım geçmişi ve elden çıkarmanın arkasında tek bir sicil.

Muavin defterler ve kontrol hesabı

Büyük defter özetlenmiş bakiyeleri tutar. Ayrıntı muavin defterlerde yaşar ve her muavin defter büyük defterdeki bir kontrol hesabına bağlıdır. Ticari alacaklar, her müşteri faturası ve tahsilatı için bir satır tutar ve bunların toplamı alacaklar kontrol hesabını verir. Ticari borçlar da tedarikçi faturaları için aynısını yapar. Stok hareketleri bir stok kontrol hesabına kaydedilir ve mallar çıktıkça satılan malın maliyeti muhasebeleştirilir. Bordro; brüt ücreti, işveren katkılarını, kesintileri ve net yükümlülükleri kaydeder. Sabit kıymetler; girişleri, amortismanı ve elden çıkarmaları varlık maliyeti ve birikmiş amortisman karşısında kaydeder. Satış noktası; satışları, tahsil edilen vergiyi, ödeme türlerini ve sürekli envanter kullanılıyorsa her satışın maliyet tarafını kaydeder.

Bunu güvenilir kılan kural basittir: muavin defter, kontrol hesabıyla her zaman kuruşu kuruşuna mutabık olmalıdır. Alacak yaşlandırması bir rakam, alacaklar kontrol hesabı başka bir rakam söylüyorsa, bunlardan biri yanlıştır ve hangisi olduğunu inceleme yapmadan bilemezsiniz. Kontrol hesaplarına doğrudan yevmiye kaydı girilmesinin normalde engellenmesinin nedeni budur. Alacaklara elle girilen bir yevmiye kaydı, hiçbir müşterinin borçlu olmadığı bir bakiye yaratır ve gönderdiğiniz hiçbir ekstrede görünmez.

Mutabakat, birinin tuttuğu bir elektronik tablo değil, istendiğinde çalıştırılabilen bir rapor olmalıdır. Modüller tek bir büyük defteri paylaştığında mutabakat neredeyse bir totolojidir. Paylaşmadıklarında ise otomatikleştirebileceğiniz en önemli kontroldür.

Kayıt kuralları ve denetim izi

Her büyük defter satırı bir kaynak belgeye kadar izlenebilmelidir: bir fatura numarası, bir mal kabul, bir bordro çalıştırması, bir amortisman tablosu, bir satış noktası işlemi. Kaynağı olmayan bir satır varsa, biri süreci atlamıştır. Belge tanımlayıcısı ayrı bir eşleme tablosunda durmamalı, büyük defter satırıyla birlikte taşınmalıdır.

Kaydedilmiş kayıtlar sessizce düzenlenebilir olmamalıdır. Düzeltmeler, hem orijinali hem de düzeltmeyi kendi tarihleri ve kendi kullanıcılarıyla görünür bırakan ters kayıtlarla ya da alacak dekontlarıyla yapılmalıdır. Dönem kapanışı, insanların geriye tarihli kayıt girmemeyi hatırlamasına güvenmek yerine dönemi kilitlemelidir. Test şudur: herhangi bir bakiyeyi alıp açabiliyor ve sistemden çıkmadan onu üreten belgelere kadar inebiliyor musunuz?

Entegrasyonlar gerçekte nerede kırılır

Hata türleri iyi bilinir ve neredeyse her zaman aynılardır.

• Zamanlama ve dönemsellik ayrımı: dönemin son günü gece yarısından hemen önce kaydedilen bir satış diğer sisteme kesim zamanından sonra ulaşır, böylece iki dönem hiçbir zaman eşleşmez.
• Kimsenin izlemediği başarısız işler: zamanlanmış bir aktarım çalışmayı bırakır ve verinin yokluğu sakin bir hafta gibi görünür.
• Kısmi yazmalar: fatura başlığı oluşturulur, satırlar başarısız olur ve bir taraf artık diğerinin tanımadığı bir belge tutar.
• Mükerrer anahtarlar: yeniden denenen bir mesaj aynı faturanın ikinci bir kopyasını oluşturur ya da bir numaralandırma şeması şubeler arasında çakışır.
• Para birimi ve yuvarlama kayması: farklı noktalarda yuvarlama yapan ya da aynı gün için farklı kurlar kullanan iki sistem, zamanla biriken küçük farklar üretir.
• İki kez hesaplanan vergi: işlem sistemi ve muhasebe sistemi, indirimler, vergi dahil fiyatlama ya da satır bazında veya belge bazında yuvarlama konusunda biraz farklı kurallar kullanarak vergiyi ayrı ayrı hesaplar. Müşteriye verilen fatura ile beyannamedeki rakam birbirini tutmaz.

İdempotans ve iki tarafın uyuştuğunu kanıtlamak

Yeniden denenebilecek her şey yeniden denenecektir; bu yüzden her kayıt işlemi, kaynak belgeden türetilmiş sabit bir anahtara ihtiyaç duyar. Aynı faturayı iki kez göndermek iki kayıt değil, tek kayıt üretmelidir. Alıcı taraf hangi anahtarları zaten işlediğini kaydetmeli ve yeni bir kayıt oluşturmak yerine önceki sonucu döndürmelidir. Bu olmadan sıradan ağ davranışı mükerrer hasılata dönüşür.

Bunun yanında mutabakata birinci sınıf bir özellik olarak ihtiyaç vardır: dönem ve belge türü başına adetler ve toplamlar, iki tarafta karşılaştırılır ve farklar özetlenmek yerine tek tek listelenir. Yalnızca son işin başarılı olduğunu söyleyen yeşil bir onay işareti, uyumun kanıtı değildir. İşe yarayan rapor, bir tarafta olup diğerinde olmayan yedi belgenin adını veren rapordur.

Şubeler ve para birimleri

Çok şubeli çalışma, her işlemin lokasyonunu sonradan rapor mantığıyla atanan bir bilgi olarak değil, oluşturulduğu andan itibaren bir boyut olarak taşıması demektir. Stok, hasılat, maliyet ve personel bir şubeye aittir; şubeler arası transferlerin her iki tarafının da kaydedilmesi gerekir, aksi halde iki şubenin stok rakamlarının toplamı şirket rakamını vermez. Belge numaralandırması şubeler arasında benzersiz olmalı, aynı zamanda bir şube içinde anlamlı kalmalıdır.

Çoklu para birimi, işlem para biriminin, kullanılan kurun ve ana para birimi tutarının satırda birlikte saklanmasını gerektirir. Yalnızca çevrilmiş tutarı saklamak kanıtı yok eder. Böylece açık bakiyelerin kur değerlemesi ile kapatmada gerçekleşen kur kârı ya da zararı kaydedilecek bir yer bulur ve kur farkı bir yuvarlama gizemi olmaktan çıkar.

Bölgesel not: onay modeli zamanlamayı değiştirir

Bir e-fatura rejiminin uygulandığı yerlerde entegrasyonun zamanlaması bir tasarım tercihi olmaktan çıkar. Birçok vergi idaresi artık faturaların alıcıya ulaşmadan önce ya da ulaştığı anda idare tarafından onaylanmasını veya idareye bildirilmesini şart koşuyor. Suudi Arabistan'daki ZATCA rejimi canlı bir örnektir: faturalar tanımlı bir yapı, kriptografik unsurlar ve tanımlayıcılarla üretilir ve idare sonradan bir özet almak yerine belgenin yaşam döngüsünün içinde yer alır. Bu, fatura oluşturmayı gerçek zamanlı bir entegrasyon sorununa dönüştürür. Gece çalışan bir toplu iş, müşterinin kasada beklediği bir belgeyi üretemez.

Başka yerlerde tablo farklıdır ve kesin olmakta fayda var. Amerika Birleşik Devletleri'nde federal bir e-fatura zorunluluğu yoktur ve satış vergisi eyalet düzeyinde yönetilir; kurallar ve oranlar eyalete, çoğu zaman da yerel yönetime göre değişir. Kanada, federal düzeyde GST ve HST uygular; bazı eyaletlerde eyalet satış vergileri dahil eyaletlere göre farklılıklar vardır. Daha geniş MENA pazarları farklı aşamalardadır. Tasarım dersi, vergi belirleme ve belge düzenlemeyi tek bir yerde tutmaktır; böylece bildirimden onay modeline geçen bir pazar mimariyi değil, yapılandırmayı değiştirir. Skyline Nexus, ZATCA onayını büyük defter kaydını yazan aynı işlemden yürütür; böylece müşterinin aldığı fatura ile beyannamedeki rakam tek bir hesaplamadan gelir.