Satın Alma Siparişi ve Sözleşme Süreci Nasıl Yönetilir?
Ders 7 / 10 · 30 dakika okuma · İleri
Onaylanan satın alma kararını doğru tedarikçi, fiyat, miktar, teslimat, ödeme ve sözleşme koşullarıyla satın alma siparişine dönüştürmeyi; PO değişikliklerini, çerçeve sözleşmeleri ve ERP aktarımını kontrollü yönetmeyi öğrenin.
Bu Derste Öğrenecekleriniz
- ✓Satın alma siparişinin ticari ve operasyonel işlevini açıklamak
- ✓Onaylı talep, seçilen teklif, sözleşme ve PO arasındaki veri zincirini kurmak
- ✓PO'da bulunması gereken kritik ticari ve teslimat alanlarını belirlemek
- ✓Çerçeve sözleşme ile tekil satın alma siparişi arasındaki ilişkiyi yönetmek
- ✓PO değişikliklerinde yeniden onay ve versiyonlama kuralları oluşturmak
- ✓ERP entegrasyonunda mükerrer kayıt, aktarım hatası ve durum senkronizasyonunu kontrol etmek
- ✓PO kapanış, iptal ve kalan miktar yönetimini tasarlamak
Tedarikçi seçildiğinde satın alma süreci bitmez. Seçim kararının doğru kapsam ve koşullarla siparişe dönüşmesi gerekir. Satın alma siparişi (PO), işletmenin neyi, kimden, ne miktarda, hangi fiyat ve teslimat koşullarıyla satın aldığını operasyonel olarak görünür hale getiren temel kayıtlardan biridir.
Not — PO yalnız çıktı belgesi değildir
1. Seçim kararından PO'ya veri zincirini koruyun
PO oluşturulurken tedarikçi, fiyat veya ödeme koşullarının yeniden manuel yazılması seçim sürecindeki doğrulanmış verinin kaybolmasına neden olabilir. Mümkün olduğunda onaylı talep, nihai teklif ve sözleşmedeki ilgili alanlar PO'ya kontrollü biçimde aktarılmalıdır.
| Kaynak | PO'ya taşınabilecek veri | Kontrol |
|---|---|---|
| Satın alma talebi | İhtiyaç, maliyet merkezi, proje, teslimat noktası | Onaylı talep referansı |
| Nihai teklif | Birim fiyat, para birimi, termin, ticari koşullar | Seçilen teklif versiyonu |
| Tedarikçi ana verisi | Tedarikçi kimliği ve onaylı ticari bilgiler | Aktif/uygun tedarikçi |
| Sözleşme | Fiyat, süre, SLA, ödeme, özel koşullar | Geçerli sözleşme ve kapsam |
| Onay kararı | Yetki ve istisna kayıtları | PO tutarı/kapsamı onayla uyumlu mu? |
2. PO'nun kritik alanlarını standartlaştırın
Sipariş numarası ve tedarikçi adı tek başına yeterli değildir. Ürün/hizmet tanımı, miktar, birim, fiyat, para birimi, teslimat tarihi ve yeri, ödeme koşulu, vergi yaklaşımı, ilgili sözleşme ve talep referansları gibi alanlar satın alma türüne göre yapılandırılmalıdır.
- PO numarası ve versiyonu
- Tedarikçi kimliği
- Ürün/hizmet kodu ve açıklaması
- Miktar ve ölçü birimi
- Birim fiyat ve toplam
- Para birimi
- Vergi ve varsa iskonto bilgisi
- Teslimat tarihi/planı
- Teslimat veya hizmet lokasyonu
- Ödeme koşulu
- Sözleşme/teklif/talep referansı
- Maliyet merkezi/proje
- Sipariş sahibi ve onay izi
Uyarı — Serbest metin bağımlılığını azaltın
3. Sözleşme ile PO'nun görevini ayırın
Sözleşme tarafların genel veya dönemsel hukuki ve ticari çerçevesini belirleyebilir; PO ise belirli ürün, miktar, hizmet dönemi veya teslimat için işlem kaydı oluşturur. Her satın alma için ayrı kapsamlı sözleşme gerekmediği gibi, sözleşme varlığı da her durumda PO ihtiyacını ortadan kaldırmaz.
| Kayıt | Tipik işlev | Örnek |
|---|---|---|
| Çerçeve sözleşme | Dönemsel fiyat, hizmet, sorumluluk ve ticari koşullar | 12 aylık ambalaj tedarik sözleşmesi |
| PO | Belirli miktar/tarih/lokasyon için sipariş | Mayıs ayında 20.000 kutu siparişi |
| Call-off / release | Çerçeve anlaşmadaki miktar/limitten kullanım | Sözleşme limitinden 5.000 adet çekiş |
| SOW / iş emri | Belirli hizmet kapsamı ve çıktılar | Entegrasyon projesi fazı |
4. Çerçeve sözleşmelerde limit ve kullanım takibi yapın
Sözleşmenin 5 milyon TL üst limiti varsa ve alt siparişler bu sözleşmeye bağlı oluşturuluyorsa kullanılan, açık taahhüt ve kalan limit görünür olmalıdır. Aksi halde sözleşme limiti fark edilmeden aşılabilir.
Örnek — Sözleşme limitinin görünür olması
5. PO onayını önceki onayın kopyası haline getirmeyin
Talep onayı ihtiyacın ve bütçenin kabulü olabilir; tedarikçi seçim onayı ticari kararın kabulüdür. PO onayı ise nihai işlem kaydının bu kararlarla uyumlu olduğunu doğrulayabilir. Aynı kişilerin aynı bilgiyi tekrar tekrar onayladığı gereksiz zincirlerden kaçınılmalıdır.
İpucu — Kontrol amacını yazın
6. PO değişikliklerini versiyonlayın ve etkisine göre yeniden onaylayın
Sipariş verildikten sonra miktar, fiyat, teslimat tarihi veya kapsam değişebilir. Değişiklik doğrudan eski değerin üzerine yazılırsa ilk taahhüt ve sonradan neyin değiştiği kaybolur. Değişiklik geçmişi ve gerekli yeniden onay kuralları tutulmalıdır.
| Değişiklik | Olası kontrol |
|---|---|
| Miktar/tutar artışı | Yeni toplamın yetki/bütçe eşiğine göre yeniden onayı |
| Birim fiyat değişikliği | Nihai teklif/sözleşme uyumu ve ticari onay |
| Tedarikçi değişikliği | Yeni seçim/uygunluk kontrolü |
| Teslimat tarihi | Operasyon etkisi ve gerekiyorsa onay |
| Kapsam değişikliği | Talep/teknik gereksinim ve sözleşme kontrolü |
| Ödeme koşulu | Finans ve yetki kontrolü |
Örnek — Kritik değişiklik
7. Tedarikçinin PO'yu aldığını ve kabul ettiğini izleyin
PO'nun e-posta ile gönderilmiş olması tedarikçinin siparişi kabul ettiği anlamına gelmez. Kritik satın almalarda teslim alındı, kabul edildi, kısmi kabul veya değişiklik talebi gibi durumlar izlenebilir olmalıdır.
| Durum | Anlam |
|---|---|
| Gönderildi | PO tedarikçiye iletildi |
| Teslim alındı | Tedarikçi sisteme/iletiye erişti |
| Kabul edildi | Tedarikçi sipariş koşullarını kabul etti |
| Değişiklik talebi | Tedarikçi koşul/termin değişikliği istedi |
| Kısmi teyit | Siparişin yalnız bir kısmı teyit edildi |
| İptal/reddedildi | Sipariş kabul edilmedi veya iptal edildi |
8. ERP aktarımında idempotency ve hata yönetimi kurun
Satın alma portalındaki PO ERP'ye aktarılırken bağlantı zaman aşımı yaşanabilir. Kullanıcının tekrar göndermesi ERP'de ikinci sipariş oluşturmamalıdır. Aynı işleme ait tekrar denemeleri tanıyan idempotency anahtarı ve sistemler arası referans kullanılmalıdır.
- Portal PO için benzersiz işlem/referans üretir.
- ERP aktarım isteği bu referansla gönderilir.
- Geçici hata varsa kontrollü retry yapılır.
- ERP aynı referansla gelen tekrarı ikinci PO olarak oluşturmaz.
- Kalıcı hata hata kuyruğuna alınır ve sorumluya görünür.
- Portal ve ERP PO numaraları karşılıklı referans olarak saklanır.
Uyarı — Başarısız aktarımı Excel ile gizlemeyin
9. PO durumlarını iki sistem arasında uzlaştırın
Portal 'açık', ERP 'iptal' gösteriyorsa satın alma ekibi yanlış açık taahhüt görebilir. Durum değişikliklerinin hangi sistemde master olduğu ve senkronizasyon hatalarının nasıl uzlaştırılacağı belirlenmelidir.
| Durum | Kontrol sorusu |
|---|---|
| Açık | Kalan miktar/tutar nedir? |
| Kısmi teslim | Teslim edilen ve açık kalan nedir? |
| Tam teslim | Mal/hizmet kabulü tamamlandı mı? |
| İptal | Kalan taahhüt/bütçe rezervasyonu çözüldü mü? |
| Kapalı | Teslimat, fatura ve açık kalem açısından kapanış uygun mu? |
10. Açık siparişleri yaşlandırın ve kontrollü kapatın
Aylarca açık kalan ve artık teslim edilmeyecek PO'lar bütçe, taahhüt ve tedarikçi performans raporlarını bozar. Açık PO yaşlandırması yapılmalı; kalan miktarın gerçekten beklenip beklenmediği düzenli olarak gözden geçirilmelidir.
İlgili çözüm: Satın Alma ve Tedarikçi Portalı
Şimdi Uygulayın
Uygulama Görevi — PO Kontrol ve Değişiklik Matrisi
İşletmenizdeki bir satın alma siparişini örnek alın. PO'nun hangi kayıtlardan veri aldığını, hangi alanların manuel girildiğini, hangi değişikliklerin yeniden onay gerektirdiğini, ERP'ye nasıl aktarıldığını ve hangi koşulda kapatıldığını yazın. Ardından kontrolsüz manuel alanları ve mükerrer kayıt risklerini işaretleyin.
| Kontrol noktası | Mevcut durum | Risk | Hedef kural |
|---|---|---|---|
| Tedarikçi/fiyat kaynağı | … | … | … |
| Onay referansı | … | … | … |
| Sözleşme bağlantısı | … | … | … |
| PO değişikliği | … | … | … |
| ERP aktarımı | … | … | … |
| Kapanış | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓Satın alma siparişi, onaylanmış satın alma kararının operasyonel ve ticari kayda dönüşmesidir.
- ✓PO; doğru tedarikçi, kapsam, miktar, fiyat, teslimat, ödeme ve ilgili sözleşme koşullarını taşımalıdır.
- ✓Sonradan yapılan kritik değişiklikler versiyonlanmalı ve gerektiğinde yeniden onaylanmalıdır.
- ✓ERP entegrasyonunda idempotency, hata yönetimi ve durum uzlaştırması kurulmalı; açık siparişler teslimat, iptal ve kalan taahhüt açısından kontrollü kapatılmalıdır.