İçeriğe geç
ERP & İş Süreçleri9 dk okuma

Satın Alma Onay Süreci: Talep Formu, Yetki Matrisi ve ERP Bağlantısı

Satın alma onay süreci hangi adımlardan oluşur?

Satın alma onay süreci, bir ihtiyacın talep olarak kaydedilmesinden siparişin ERP'ye yazılıp malın teslim alınmasına kadar süren akıştır ve pratikte yedi adımda ele alınabilir. Adımları önce kâğıt üzerinde netleştirmek, yazılımdan bağımsız olarak yapılması gereken ilk iştir.

  1. Talep. İhtiyacı olan kişi ne, ne kadar, ne zaman ve neden lazım olduğunu yazar.
  2. Ön kontrol. Depoda var mı, bütçede yer var mı, aynı ürün için açık bir talep var mı?
  3. Teklif toplama. Tutar ve kategoriye göre bir ya da birden fazla tedarikçiden teklif alınır.
  4. Karşılaştırma. Teklifler fiyat, teslim süresi ve ödeme koşuluyla yan yana konur; seçim gerekçesi yazılır.
  5. Onay. Talep, yetki matrisindeki kurala göre doğru kişiye ya da kişilere gider.
  6. Sipariş. Onaylanan talep ERP'de satın alma siparişine dönüşür ve tedarikçiye gönderilir.
  7. Mal kabul ve fatura. Gelen mal siparişle, fatura da sipariş ve irsaliyeyle karşılaştırılır.

Excel ve e-postayla yürüyen süreçte kopukluk çoğu zaman beşinci ve altıncı adım arasında olur. Onay e-postada kalır, sipariş ERP'ye geç ya da hiç girilmez. Mal kabulde karşılaştırılacak bir sipariş olmayınca yedinci adım da anlamını kaybeder.

Satın alma talep formu: hangi alanlar zorunlu olmalı?

İyi bir satın alma talep formu, onaylayanın soru sormadan karar verebileceği kadar bilgi ister ve bundan fazlasını istemez. Fazla alan formu doldurulmaz hâle getirir; eksik alan ise onayı e-posta trafiğine geri döndürür.

AlanNeden gerekliKim doldurur
Ürün ya da hizmet (stok kartından seçim)Siparişin ERP'ye doğru kodla yazılması içinTalep eden
Miktar, birim, istenen teslim tarihiTeklif ve termin içinTalep eden
Gerekçe ve kullanım yeri (proje, makine, departman)Onaylayanın karar vermesi ve maliyet takibi içinTalep eden
Tahmini tutar ya da önerilen tedarikçiDoğru onay kademesinin seçilmesi içinTalep eden ya da satın alma
Ek dosya (teknik şartname, fotoğraf)Yanlış ürün alımını önlemek içinTalep eden
Teklifler ve seçim gerekçesiEn ucuzun seçilmediği durumda iz kaydı içinSatın alma

Ürünün serbest metin yerine stok kartından seçilmesi küçük bir ayrıntı gibi görünür ama sonradan çok iş kazandırır. "Eldiven", "iş eldiveni", "nitril eld." gibi farklı yazımlar ERP'de eşleşmez. Stok kartı olmayan bir alım için form, satın almaya "yeni kart açılsın" diye bir adım ekler.

Yetki matrisi örneği: kim, hangi tutara kadar onaylar?

Yetki matrisi, bir talebin tutarına ve kategorisine göre hangi kişilerin onayından geçeceğini ve kaç teklif gerektirdiğini gösteren tablodur. Matris kişi adlarıyla değil rollerle yazılır; böylece biri izne çıktığında ya da görev değiştirdiğinde tablo değişmez.

Aşağıdaki örnekte tutar sınırları harf olarak bırakıldı. Eşikleri şirketiniz, bütçe yapınıza göre belirler.

Tutar kademesiOnaylayanTeklif sayısıEk koşul
A eşiğinin altıBirim yöneticisiTek teklif yeterliBütçe dahilindeyse
A ile B eşiği arasıBirim yöneticisi, sonra satın alma müdürüEn az ikiSeçim gerekçesi zorunlu
B ile C eşiği arasıSatın alma müdürü, sonra genel müdürEn az üçMali işler görüşü eklenir
C eşiğinin üstüGenel müdür, sonra yönetim kurulu ya da ortaklarEn az üçSözleşme taslağı eklenir

Tutar tek ölçüt değildir. Tutardan bağımsız olarak ek onay isteyen durumlar da matrise yazılır:

  • Bütçe dışı alım: Tutar ne olursa olsun mali işler onayı.
  • Yeni tedarikçi: İlk alımda satın alma müdürü onayı ve tedarikçi bilgilerinin kontrolü.
  • Yatırım malı (demirbaş): Muhasebe kaydı farklı olduğu için mali işler görüşü. Kayıt yöntemi mali müşavirinizle belirlenir.
  • Acil alım: Onay sonradan verilebilir, ama sistemde "acil" olarak işaretlenir ve ay sonunda ayrıca listelenir.

İki kural daha matrisin parçasıdır. Birincisi, talep eden kişi kendi talebini onaylayamaz. Microsoft'un Business Central belgesi bu konuda açık bir uyarı yapıyor: aynı kullanıcı bir iş akışı kullanıcı grubunda hem talep eden hem onaylayan olursa talepleri her zaman otomatik onaylanır. İkincisi, büyük bir alımı eşiğin altında kalacak parçalara bölmek engellenmelidir. Aynı tedarikçiye kısa aralıklarla açılan benzer talepler sistemde uyarı üretir.

Onay akışı yazılımında olması gerekenler

Onay akışı yazılımının işi, yetki matrisini kendiliğinden uygulamak ve her kararı kayda geçirmektir. Ekranların güzelliği ikinci plandadır; aşağıdaki işlevler yoksa akış e-postaya geri döner.

  • Kurala göre yönlendirme. Talep, tutar ve kategoriye göre doğru onaylayana kendiliğinden gider. Kimin onaylayacağını talep eden seçmez.
  • İz kaydı. Her adımın kimin tarafından, ne zaman ve hangi notla yapıldığı silinemez biçimde tutulur. Onaydan sonra tutar ya da miktar değişirse talep yeniden onaya düşer.
  • Mobil onay. Onaylayan telefonundan talebi, teklifleri ve ek dosyaları görüp tek dokunuşla onaylar ya da gerekçe yazarak reddeder. Masaya dönmeyi bekleyen onay, sürecin en uzun beklemesidir.
  • Hatırlatma ve zaman aşımı. Belirli sürede cevaplanmayan talep için hatırlatma gider; süre dolarsa bir üst role yükselir.
  • Vekâlet. İzindeki onaylayanın yerine kimin bakacağı önceden tanımlanır.
  • Durum görünürlüğü. Talep eden, talebinin hangi adımda beklediğini kimseyi aramadan görür.
  • Raporlama. Kategori, departman ve tedarikçi bazında ne harcandığı; ortalama onay süresi; acil işaretli alımların listesi.

ERP'nin kendi onay modülü yetiyor mu?

Kullandığınız ERP'nin satın alma onay özelliği ihtiyacınızı karşılıyorsa ayrı bir yazılıma gerek yoktur. Önce buna bakılmalıdır, çünkü ERP içindeki onay akışı ayrı bir entegrasyon gerektirmez.

Örneğin Microsoft'un Business Central belgeleri, satın alma siparişleri için hazır bir onay iş akışı şablonunu ve Onay Kullanıcısı Kurulumu sayfasında her onaylayana yerel para biriminde bir satın alma onay limiti ve yerine bakacak bir vekil tanımlanabildiğini anlatıyor. Başka ERP'lerde de benzer modüller bulunabilir; sizin lisansınızda açık olup olmadığı yetkili bayinizle teyit edilir.

Ayrı bir onay akışı şu durumlarda anlam kazanır:

  • Talep edenlerin ERP erişimi yok. Şantiye şefi, ustabaşı ya da saha personeli için ERP kullanıcısı açmak hem lisans hem eğitim yükü getirir. Basit bir web formu ya da mobil ekran yeterlidir.
  • Onay sahadan ya da telefondan veriliyor. ERP'nin mobil erişimi yoksa ya da kısıtlıysa onaylayanlar e-postaya geri döner.
  • Teklifler dışarıdan toplanıyor. Tedarikçilerin teklifini bir bağlantı üzerinden girmesi gibi işler çoğu ERP'nin standart kapsamında değildir.
  • Birden fazla şirket ya da program var. Grup şirketleri farklı programlar kullanıyorsa tek bir onay ekranı bunların üstünde durabilir.

Bu durumlarda doğru yapı, ERP'yi değiştirmek değil, yanına ince bir onay katmanı kurmaktır. Talep ve onay bu katmanda yaşar; onaylanan sipariş ERP'ye yazılır. Bu, iş süreci otomasyonu ile ERP entegrasyonunun birlikte kullanıldığı tipik bir durumdur.

Onaylanan sipariş ERP'ye nasıl yazılır?

Onaylanan sipariş, ERP'ye programın resmî arayüzü üzerinden yazılmalıdır; veritabanına doğrudan kayıt atılmaz. Resmî arayüzde programın kendi kontrolleri devreye girer: cari doğrulama, stok kartı kontrolü, zorunlu alanlar, fiş ile satır arasındaki ilişki. Hata varsa anlamlı bir mesaj döner ve veri bozulmaz.

Türkiye'de yaygın programlarda resmî yollar farklıdır:

ProgramBelgelenmiş yazma yoluNot
Logo Tiger 3 / WingsLogo Objects ve Logo REST ServisErişim çoğunlukla yetkili bayi kanalından açılır
Logo Netsis 3NetOpenX ve NetOpenX RestHangi belge türlerinin açık olduğu kurulumda teyit edilir
MikroMikro Desktop APIAPI Key gerekir; başvuru ve lisans adımları üreticiyle teyit edilir
Dynamics 365 Business CentralAPI v2.0, purchaseOrders kaynağıSipariş oluşturma, güncelleme ve teslim al-faturala işlemi belgede

Microsoft'un Business Central API belgesi, satın alma siparişi kaynağı için oluşturma, okuma, güncelleme ve silme işlemlerini, siparişin "Taslak", "İncelemede" ve "Açık" durumlarını listeliyor. Diğer programlarda satın alma siparişinin resmî arayüzde hangi alanlarla açık olduğu, kurulumda üreticinin güncel belgesiyle doğrulanır.

Bağlantı kurulurken üç teknik ayrıntı süreci sağlam kılar:

  1. Tekrar korumalı yazma. Her talebin benzersiz bir numarası olur. Ağ kesildiği için aynı istek iki kez gönderilirse ERP'de iki sipariş oluşmaz.
  2. Eşleme tablosu. Stok kodu, cari kodu, birim ve ambar eşlemeleri kodda değil, yönetilebilir bir tabloda tutulur.
  3. Geri bildirim. ERP'nin verdiği sipariş numarası onay katmanına geri yazılır. Talep eden, talebinin hangi siparişe dönüştüğünü görür; mal kabul ekranı da bu numarayla çalışır.

Excel'den onaylı sürece geçiş planı

Geçiş, yazılım seçimiyle değil, mevcut sürecin yazıya dökülmesiyle başlar. Aşağıdaki sıra, kesintisiz bir geçiş için pratik bir çerçevedir.

  1. Mevcut durumu yazın. Son birkaç ayın alımlarını kategoriye ve tutara göre gruplayın. Hangi onaylar fiilen kimden geçiyor?
  2. Yetki matrisini kâğıtta onaylatın. Eşikler, roller ve istisnalar yönetim tarafından imzalanır. Yazılım bu kararı veremez, yalnızca uygular.
  3. Formu sadeleştirin. Yukarıdaki tablodan başlayın; ilk ay kullanılmayan alanı kaldırın.
  4. Tek kategoriyle başlayın. Örneğin sarf malzemesi alımları. Akış oturunca diğer kategoriler eklenir.
  5. ERP bağlantısını en son açın. Önce onaylanan talepler elle siparişe çevrilir ve kontrol edilir. Kurallar doğru çalışınca siparişin resmî arayüzden otomatik yazılmasına geçilir.

Sıkça Sorulan Sorular

Satın alma onay akışı için ERP'yi değiştirmek gerekir mi?

Gerekmez. ERP'nin onay modülü yetiyorsa o kullanılır. Yetmiyorsa talep ve onay ayrı bir katmanda yürür, onaylanan sipariş ERP'ye resmî arayüzünden yazılır. ERP yerinde kalır.

Yetki matrisinde tutar eşiklerini kim belirler?

Eşikleri şirket yönetimi, bütçe yapısına ve risk tercihine göre belirler. Yazılım bu kararı vermez, yalnızca uygular. Eşikler sisteme yazılı bir yönetim kararı olarak girilmeli ve değiştiğinde değişiklik tarihiyle birlikte kayda geçmelidir.

Onaylar telefondan verilebilir mi?

Verilebilir. Onaylayan, talebi, teklifleri ve ek dosyaları telefonundan görüp onaylar ya da gerekçe yazarak reddeder. Önemli olan, mobil onayın da masaüstündeki gibi iz kaydına geçmesi ve onaylayanın kimliğinin doğrulanmasıdır.

Acil alımlar akışı yavaşlatmaz mı?

Acil alım için akışta ayrı bir yol tanımlanır: alım yapılabilir, onay sonradan verilir. Ama talep sistemde "acil" olarak işaretlenir ve ay sonunda ayrıca listelenir. Böylece acil yol, onaysız alımın kalıcı kapısına dönüşmez.

Onaylanan sipariş ERP'ye neden doğrudan veritabanına yazılmıyor?

Doğrudan veritabanına yazmak, programın kendi kontrollerini atlar: cari doğrulama, zorunlu alanlar, fiş-satır ilişkisi. Hatalı kayıt fark edilmeden muhasebeye ve stoğa yansıyabilir. Resmî arayüzde ise hatalı kayıt baştan reddedilir ve sebebi yazılır.

Sonraki adım: yetki matrisinizi birlikte sisteme taşıyalım

Satın alma sürecinizi ve kullandığınız ERP'yi birlikte inceleyebiliriz: ERP'nin kendi onay modülü yetiyor mu, yetmiyorsa ince bir onay katmanı nasıl kurulur, sipariş hangi resmî yoldan yazılır. Teslimden sonra 15 gün ücretsiz hata düzeltme standardımızdır. Ücretsiz online keşif görüşmesi için iletişime geçin. İsterseniz WhatsApp'tan da yazabilirsiniz.

YAZAR

Doğuhan Bulut

Kurucu & CTO

Muhasebe/ERP entegrasyonları, otomasyon ve web mimarisi. 10+ yıl yazılım geliştirme deneyimi.

SIRADAKİ ADIM

Programınızı değiştirmeden bağlayalım

Logo, Netsis, Mikro, Paraşüt, Luca ve diğerleri: hangi programın verisini hangi resmi yoldan açtığını, neyin okunup neyin yazılabileceğini tek sayfada anlattık.

ERP entegrasyonu sayfası
BENZER İÇERİKLER İSTERSEN

Aylık dijital özet bültenimiz

Ayda 1 e-posta — yeni yazılar, KOBİ + KVKK güncellemeleri, entegrasyon ve otomasyon notları. Spam yok, istediğiniz an çıkış.