Bu seri Model Bağlam Protokolü'nün, Anthropic'in 2024'te yayınladığı açık standardın bir yük API'sine nasıl eşlendiği ile başladı, ardından 2026'da gönderilen yük MCP sunucularını söktü geldi ve sonrasında nasıl güvence altına alınır'i kapsadı. Daha önceki 3 bölümün tamamı aynı noktada bitiyor: acente bir yük (load) rezerve etti. Bu bölüm, sonrasında neler olacağını ve işletmelerin aslında zorlandığı kısmı anlatıyor. Kayıt sistemine hiç ulaşmayan bir rezervasyon, finans ekibinizin güvendiği bir rezervasyon değildir. Bu nedenle, gerçek entegrasyon sorusu "acente rezervasyon yapabilir mi" değil, "acente o rezervasyonu defteri bozmadan SAP, Oracle veya NetSuite'e geri yazabilir mi" sorusudur.
Pazaryeri tarafında, API aracılığıyla rezervasyonları gösterip müşterilerin bunları kendi arka ofislerine nasıl entegre ettiklerini izlerken bunu yazıyorum. Rezervasyon araması kolay yarı. Mühendislik zamanının gittiği yer, geri yazma kısmıdır.
Neden geri yazma zor kısımdır
Bir yük rezerve etmek tek, tatmin edici bir eylemdir. Bunu mutabakatını sağlamak ise en az 4 ayrı yükümlülükten oluşan uzun bir süreçtir. Sevkiyatın finans bölümündeki birinin tanıyacağı bir kayıt olarak görünmesi gerekir. Maliyeti doğru hesaba işlenmelidir. Kamyon hareket ettikçe durumu güncellenmeye devam etmelidir. Taşıyıcı faturası geldiğinde, son rakam orijinal tahminle karşılaştırılarak kapatılmalıdır. Bunların her biri, bir yapay zeka temsilcisinin kalemi elinde tutacağı kimsenin hayal etmediği bir zamanda tasarlanmış bir sisteme ayrı bir yazmadır.
Bunu yanlış yapmak sessiz ama gerçek bir hasara yol açar. Yinelenen bir navlun siparişi, tahakkukları şişirir. Hiç senkronize olmayan bir rezervasyon, maliyeti eklenmemiş bir sevkiyatın hareket etmesine neden olur. Güncellemesi duran bir durum, bir sevkiyatçıyı manuel kontrol aramalarına geri gönderir; bu da temsilcinin kaldırması gereken tam iştir. Temsilci, tanıtımda etkileyici görünür ve üretimde bir mutabakat birikimine neden olur.
Referans akış, uçtan uca
Satıcı adları ayıklandığında, her çalışan kurulum aynı yolu izler. Aracı, Claude veya Copilot gibi bir asistanda çalışır. Fiyat teklifi almak ve ardından rezervasyon yapmak için MCP pazar yerini çağırır. Rezervasyon çağrısı bir rezervasyon tanımlayıcısı ve yapılandırılmış bir maliyet döndürür. Aracı veya arkasındaki ince bir hizmet, bu sonucu bir nakliye kaydı olarak ERP'ye yazar ve oradan itibaren ERP doğruluk kaynağı olurken, pazar yeri ona güncellemeler besler.
- MCP pazar yerinden **teklif al ve rezervasyon yap**. Kitap yanıtı, yalnızca toplam maliyet değil, aynı zamanda kararlı bir rezervasyon kimliği ve maliyet dökümü içerir.
- ERP'de, bağlantının kalıcı olması için o rezervasyon kimliğiyle damgalanmış nakliye kaydını oluşturun.
- Gönderi ilerledikçe, API'ye yoğun istek gönderen bir yoklama döngüsü yerine ideal olarak olaylardan gelen **Senkronizasyon durumu**.
- **Maliyeti kesinleştirin** taşıyıcı faturası geldiğinde, nihai sayıyı orijinal tahminle eşleştirerek.
Rezervasyon kimliği, tüm akışın omurgasıdır. Her sonraki adımın ait olduğu kaydı bulmasını sağlayan değerdir ve yeniden denemeyi tehlikeli değil, güvenli hale getiren değerdir.
ERP nesne modeline bir navlun rezervasyonu eşleme
Üç yük ekibinin işlediği 3 sistem, aynı rezervasyonu belirgin şekilde farklı şekillerde yönetir, bu nedenle eşleme, entegrasyon planlarının yaşayacağı veya öleceği yerdir. Aşağıdaki çapraz başvuru, müşterilerimize hangi alanın nereye gideceğini sorduklarında verdiğimiz tablodur.
| Pazar yeri alanı | SAP TM | NetSuite / Oracle |
| Rezervasyon kimliği | Nakliye Siparişi numarası | Mal Fişi veya Siparişteki Anahtar |
| Teklif edilen maliyet | Nakliye Siparişi İçin Tahmini Maliyet | Tahmini Toplam Maliyet |
| Taşıyıcı faturası | Yük Tahsilat Belgesi | Gerçek Toplam Maliyet - Fatura Muhasebesi Yoluyla |
| Durum kilometre taşları | Nakliye Siparişi olayları | Ürün Teslimat ve Gerçekleştirme Durumu |
Maliyet nadiren tek bir sayı olarak ortaya çıkar, bu nedenle dökümü de eşler. Hat nakliyesi ve yakıt, rezervasyon sırasında bilinir ve tahmini navlun gideri olarak kaydedilir. Gecikme veya hamaliye ücreti gibi ek masraflar genellikle yalnızca nakliyeci faturasında görünür, bu nedenle orijinal Navlun Emri'nde değil, mutabakat sırasında Navlun Mutabakat Belgesi'ne ulaşırlar.
SAP Ulaştırma Yönetimi
SAP TM, yolculuğu bir navlun siparişi olarak, parayı ise ayrı bir navlun mutabakat belgesi olarak modeller. Bu ayrım yardımcıdır çünkü operasyonel kaydın rezervasyon sırasında oluşturulmasına ve faturanın netleştiğinde finansal tarafın daha sonra işlenmesine olanak tanır. SAP TM'ye giriş yapan bir acente, rezervasyon zamanında navlun siparişini oluşturmalı ve henüz bir nihai maliyet içermeyen bir kayda zorlamak yerine, mutabakatı taşıyıcı faturası için bırakmalıdır.
Oracle ve NetSuite
Oracle ve NetSuite, navlunun taşınan mallara yayılan bir varış maliyeti olarak ortaya çıktığı satın alma ve teslim alma döngüsüne dayanır. Burada acentenin görevi, rezervasyonu ve maliyetini doğru satın alma siparişine veya ürün teslim makbuzuna eklemektir, böylece navlun gideri, yetim bir ücret olarak ortada kalmak yerine envanteri takip eder. Tahmini bakiye rezervasyonda, gerçeği yerleşikte güncellenir ve varış maliyeti oradan yeniden hesaplanır.
Her üçünün de genel dersi, üzerinde çalıştığınız modele saygı duymaktır. Bir pazar yeri rezervasyonu bizim tarafımızda tek bir nesnedir. ERP tarafında ise operasyonel bir ve finansal bir olmak üzere 2 kayıt haline gelir ve en temiz entegrasyonlar bu 2 ritmi ayrı tutar.
İdempotans: çift rezervasyon tuzağı
Çağrı sırasında ağlar çöker. Bir temsilci tekrar dener. Koruma olmadan, bu yeniden deneme, zaten bir sevkiyatı olan bir sevkiyat için ikinci bir navlun emri oluşturur ve şimdi ay sonuna kadar kimsenin fark etmediği şekilde artışlarınız yanlıştır. İdempotans çözümüdür ve para söz konusu olduğunda isteğe bağlı değildir.
Desen oldukça basit. Bir kaydı oluşturan veya sonlandıran her yazma işlemi, bir idempotency anahtarı taşır ve rezervasyon kimliği doğal olanıdır. ERP'ye yönelik hizmet, yazmadan önce o anahtar için zaten bir kayıt olup olmadığını kontrol eder. Varsa, hizmet yeni kayıt eklemek yerine günceller veya mevcut kaydı döndürür. Yeniden deneme, yinelenen bir işlem yerine güvenli bir işleme dönüşür. Rezervasyonu MCP'miz aracılığıyla sunduğumuzda, tam da bu nedenle kararlı bir kimlik döndürürüz, böylece arka ofis idempotency yazımları oluşturmak için güvenilir bir çapaya sahip olur. Desen, yazmadan önce rezervasyon kimliğine göre anahtarlanmış mevcut bir kaydı kontrol etmektir: varsa, onu güncelleyin, yoksa navlun siparişini oluşturun. İlk çalıştırma oluşturur, bir zaman aşımından sonraki her yeniden deneme aynı kaydı günceller ve kararsız bir ağ, yedek bir aramadan daha fazlasına mal olmaz.
Sınırda kimlik
Tek başına hareket eden bir aracı kişi bir insan değildir ve ERP değişikliği kimin ne zaman yaptığını bilmek ister. Temiz bir yaklaşım, entegrasyon için insan kullanıcının geniş izinlerini ödünç alan bir aracı yerine, yalnızca gerçekleştirdiği birkaç eylemle sınırlı özel bir hizmet kimliğidir. Nakliye siparişleri oluşturabilen ve ödemeleri gönderebilen, bunun dışında hiçbir şeyi yapamayan bir hizmet hesabı, etki alanını küçük tutar ve denetim izini dürüst tutar. Bu, bu dizinin güvenlik kısmı'teki aynı kapsamlı, en az ayrıcalık düşüncesinin, ağın ERP tarafına taşınmasıdır.
Yazma işleminin temiz olması için MCP hangi pazar yerini açığa çıkarmalıdır
Tek taşıyıcılı bir sunucu, öğrenmesi gereken yalnızca bir şekil olduğu için rezervasyon nesnesi hakkında muğlak olabilir. Bir pazar yeri sunucusu olamaz, çünkü müşteri, birçok taşıyıcıyı tek bir muhasebe kaydında uzlaştırıyor. 3 şey fark yaratır.
- **Sabit bir rezervasyon kimliği** — sevkiyatın tüm ömrü boyunca asla değişmez, böylece ERP kaydı her güncellemede bağlantılı kalır.
- Yapılandırılmış bir maliyet dökümü, tek bir toplam yerine, böylece nakliye, yakıt ve ek masraflar doğru hesaplara atanabilir ve tahsilat adımında uzlaştırılacak bir şey olur.
- Durum olayları, böylece ERP, saatlerce gelmeyebilecek bir değişikliği sorgulamak yerine bir kilometre taşı gerçekleştiğinde bundan haberdar olur.
Bu üçü mevcut olduğunda, ERP geri yazımı çoğunlukla deterministiktir. Bunlar eksik olduğunda, her müşteri aynı kırılgan yapıştırıcıyı yeniden oluşturur ve temsilcinin rezervasyonu uygun bir kılık değiştirmiş bir mutabakat sorununa dönüşür.
Deftere bir temsilciyi bağlamadan önceki referans kontrol listesi
- Her ERP yazımını pazar yerindeki rezervasyon kimliğine sabitleyin ve bu kimliği aynı zamanda tekilleştirme anahtarı yapın.
- Rezervasyon anında operasyonel kaydı oluşturun ve finansal mutabakatı, fatura tahsil edildiğinde, öncesinde değil, yapın.
- Maliyet dökümünü tek bir toplamı tek bir satıra girmek yerine, kasıtlı olarak hesaplara eşleyin.
- Mümkün olduğunca olaylardan sürücü durumunu alın ve makul bir aralıkla yalnızca yoklamaya geri dönün.
- Entegrasyona asla bir insanın geniş oturum açma bilgisi yerine kendi kapsamlı hizmet kimliğini verin.
- Uzlaşmada tahmini gerçekle mutabık kılın ve boşluğu sessizce üzerine yazmak yerine işaretleyin.
Bunların hiçbiri aracılara özgü değil. Sistemden sisteme gerçekleşen tüm nakliye entegrasyonlarının zaten sahip olması gereken disiplin budur. Acente, rezervasyonu yalnızca daha hızlı yapar, bu da ayak uydurabilmek için geri bildiriminin de en az o kadar güvenilir olması gerektiği anlamına gelir.
Sıkça Sorulan Sorular
Bir yapay zeka aracısı, doğrudan SAP veya NetSuite'e nakliye rezervasyonu yazabilir mi?
Evet, ERP'nin kendi API'si ve kapsamlı bir hizmet kimliği aracılığıyla, yinelenen kayıtların önlenmesi için yeniden denemelerde yinelenenlerin oluşturulmaması adına, pazar yeri rezervasyon kimliği bir değişmezlik anahtarı olarak kullanılır. Acente yazmayı önerir, ancak mantığın test edilebilir kalması ve izinlerin daraltılmış olması için dar bir hizmetin ERP'ye karşı bunu gerçekleştirmesi gerekir.
ERP'den geri yazmada en sık neler bozulur?
Yine de başarılı olmayan denemelerden yinelenen kayıtlar ve entegrasyonun bir tahmin yayınlayıp taşıyıcı faturasıyla mutabakat yapmayı unutması nedeniyle asla uzlaşmayan maliyetler. Her ikisi de, yazmaları sabit bir rezervasyon kimliğine sabitleyerek ve operasyonel ve finansal adımları ayrı tutarak çözülür.
Rezervasyon kimliği neden bu kadar önemli?
Burası pazar yeri ile defter arasındaki bağlantıdır. Her durum güncellemesi, belge ve mutabakat o kimlik aracılığıyla kaydını bulur ve yeniden denemenin güvenli olmasını sağlayan tekillik anahtarı olarak da işlev görür. Kararlı bir kimliği olmayan bir rezervasyon nesnesi, arka ofisi tahmin etmeye zorlar, bu da yinelenen ve sahipsiz maliyetlerin kaynağıdır.
Durum güncellemeleri yoklanmalı mı yoksa itilmeli mi?
Pazar yerinin olayları desteklediği yerlere iletildi, çünkü yoklama ya gerçek kilometre taşlarını geciktirir ya da güncel kalmak için API'yi zorlar. Pragmatik bir entegrasyon, önemli anlar için olayları alır ve yalnızca bir geri bildirim olarak mütevazı bir yoklama aralığı kullanır.
Bu, 2026 itibarıyla güncel olan 4 bölümlük MCP serisini tamamlıyor. Buraya ilk kez geldiyseniz, protokol primer ile başlayın, Yıkım'te gönderilen sunucuları görün ve güvenlik kılavuzu ile kilitleyin.