Her sipariş, alımdan ödenmiş faturaya kadar tek bir zaman çizelgesinde.
Siparişten tahsilata (order to cash), satın almadan ödemeye (procure to pay) ve hizmet talebinden faturaya uzanan süreçler ERP, CRM, e-ticaret, depo, taşıma ve finans sistemlerinden geçer. Bunları belgelenmiş API’ler ve olaylarla bağlıyor, her siparişe bu sistemler genelinde tek bir durum veriyor ve her istisnayı, bir kişinin onayına sunulacak bir çözüm hazırlayan bir ajana gönderiyoruz.
Birden fazla AB üye devletinde, her birinin kendi sistemleri, taşıyıcıları ve e-fatura kurallarıyla satış, satın alma ve faturalama yapan kuruluşlar için.
Bir sipariş, satın alma siparişi ya da hizmet talebi asıl kayıt sisteminde bir kez kaydedilir ve belgelenmiş API’ler ve olaylar üzerinden diğer sistemlere dağıtılır. Durum olayları her sipariş için tek bir zaman çizelgesi oluşturur. Bir adım başarısız olduğunda ya da tolerans dışına çıktığında bir ajan bağlamı toplar ve bir çözüm önerir; bir kişi bunu onaylar, ardından çözüm asıl kayıt sisteminde yürütülür. Faturalar yapılandırılmış e-fatura olarak gönderilip eşleştirilir; süreç sahipleri akışı ve arayüzlerin sağlığını gözden geçirir.
Önce ve sonra
Günlük operasyonlarda neler değişir
Bugün
Sistemle birlikte
Bugün
Bugün: Her devirde yeniden giriş
Web mağazasında ya da satış ekibince alınan bir sipariş ERP’ye yeniden yazılır; teslimat ve fatura bilgileri depo, taşıma ve finans sistemlerine elle kopyalanır.
Sistemle birlikte
Sistemle birlikte: Bir kez girilir, her yerde kullanılır
Her sipariş, teslimat ve fatura, sahibi olan sistemde oluşturulur ve bir olay olarak yayımlanır. Diğer sistemler onu yeniden yazmak yerine bu olaya abone olur.
Bugün
Bugün: Dünün durumu
Gece çalışan toplu arayüzler yüzünden müşteri hizmetleri, planlama ve finans aynı siparişin farklı ve güncel olmayan bir durumunu görür. Teslimatının nerede olduğunu soran müşteri, geri aranmayı bekler.
Sistemle birlikte
Sistemle birlikte: Tek bir güncel durum
Her sipariş ya da talep, geçtiği tüm sistemlerin olaylarından oluşan tek bir zaman çizelgesine sahiptir. Müşteri hizmetleri, planlama ve finans aynı olgulara bakar; durum sorularını yanıtlayan bir hizmet asistanı da öyle.
Bugün
Bugün: Gelen kutularında çözülen istisnalar
Stok eksikleri, fiyat uyuşmazlıkları, başarısız teslimatlar ve reddedilen e-faturalar e-posta ve tablolarla çözülür; sonradan kimin neye karar verdiğini kimse söyleyemez.
Sistemle birlikte
Sistemle birlikte: İstisnalar bir öneriyle gelir
Bir ajan her istisnanın arkasındaki veriyi toplar ve bir çözüm önerir. Bir kişi bunu tek bir istisna masasında onaylar, düzenler ya da reddeder ve karar kaydedilir.
Bugün
Bugün: Birbirini tutmayan ana veri
Aynı müşteri, tedarikçi, ürün ya da fiyat birkaç sistemde farklı değerlerle bulunur ve hangisinin doğru olduğundan kimse sorumlu değildir.
Sistemle birlikte
Sistemle birlikte: Her veri nesnesi için tek sahip
Müşteriler, tedarikçiler, ürünler ve fiyatların her biri için kararlaştırılmış bir asıl kayıt sistemi ve adı belli bir sahip vardır. Mükerrer kayıtlar ve çelişkiler, sonraki sistemlerde sessizce düzeltilmek yerine o sahibe bildirilir.
Bugün
Bugün: Her değişiklik yeni bir arayüz
Yeni bir satış kanalı, pazar yeri ya da tüzel kişi, bir noktadan noktaya bağlantı daha demektir. Kamu kurumlarına gönderilen e-faturalar ve diğer ülkelerin e-fatura zorunlulukları da her sürece ayrıca yapılandırılmış bir biçim ve bir ağ ekler.
Sistemle birlikte
Sistemle birlikte: Yeni bağlantılar aynı sözleşmeleri kullanır
Yeni bir kanal, tüzel kişi ya da e-fatura ağı, her sisteme ayrı ayrı değil, belgelenmiş API’lere ve olaylara bir kez bağlanır.
İş akışı
İş akışı nasıl işler
Veri temiz olduğunda ana yol hiçbir elle işlem gerektirmez. Bir sipariş, teslimat ya da fatura saptığında istisna döngüsü onu kanıtlar ve bir öneriyle birlikte bir kişiye getirir; onaylanan düzeltme aynı entegrasyon katmanı üzerinden geri akar.
Örnek iş akışı
7 adım · 1 insan kontrol noktası
Açıklama
Sistem
Yapay zekâ ajanı
Kişi
İnsan kontrol noktası
İstisna yolu
Bağlantılı süreçler: istisna döngüsü olan örnek iş akışı
Diyagramı metin olarak oku
Ana yol, bir iş olayının asıl kayıt sisteminde bir kez kaydedilmesiyle başlar; API’ler ve olaylarla diğer sistemlere dağıtılması ve sipariş başına tek bir zaman çizelgesi oluşturulmasından geçerek faturalama, eşleştirme ve kapanışa ulaşır. Süreç sahiplerinin akışı gözden geçirip istisnaların nedenlerini gidermesiyle biter.
Bir adım başarısız olduğunda, geciktiğinde ya da tolerans dışına çıktığında istisna, zaman çizelgesi adımından sonra ana yoldan ayrılır. Bir ajan bağlamı toplar ve bir çözüm önerir; bir kişi bunu onaylar, düzenler ya da reddeder. Onaylanan işlem asıl kayıt sisteminde yürütülür ve yeni bir olay olarak dağıtım adımına geri döner.
Onay adımı insan kontrol noktasıdır: bir kişi olmadan hiçbir mali kayıt atılmaz, fiyat ya da kredi limiti değiştirilmez ve bir müşteriye taahhütte bulunulmaz.
01
Adım 1: Olayı bir kez kaydetmeSistem
Web mağazası, bir pazar yeri, EDI ya da satış ekibi üzerinden gelen bir satış siparişi, bir satın alma siparişi ya da bir hizmet talebi, sahibi olan sistemde oluşturulur. O sistem, bir AsyncAPI sözleşmesinde tanımlanan bir CloudEvents zarfı içinde bir iş olayı yayımlar. Kâğıt ve PDF siparişler ile tedarikçi faturaları önce Akıllı belge işleme adımından geçer.
02
Adım 2: API’ler ve olaylarla dağıtımSistem
Entegrasyon katmanı olayı depo, taşıma, finans ve CRM sistemlerine, belgelenmiş API’leri (OpenAPI) üzerinden iletir. Tüketiciler idempotent çalışır, böylece tekrarlanan bir mesaj asla ikinci bir sevkiyat ya da fatura oluşturmaz; iletilemeyen mesajlar yeniden oynatılmak üzere bir hata kuyruğunda bekler.
03
Adım 3: Sipariş başına tek zaman çizelgesiSistem
Her sistemden gelen durum olayları (onaylandı, toplandı, sevk edildi, teslim edildi, faturalandı, ödendi) iş referansı üzerinden tek bir zaman çizelgesinde ilişkilendirilir. Kilometre taşı ve tolerans kuralları, bir adım başarısız olduğunda, geciktiğinde ya da eşleşmediğinde bir istisna oluşturur: bir stok eksiği, kararlaştırılan toleransın dışında bir fiyat, başarısız bir teslimat, reddedilen bir e-fatura.
04
Adım 4: Bağlamı toplama ve öneriYapay zekâ ajanı
Her istisna için bir ajan, ilgili sistemlerden ihtiyaç duyduğunu okur: sipariş, stok seviyeleri, fiyat anlaşması, taşıyıcı durumu ve müşterinin koşulları. Gerekçesini ve kullandığı veriyi göstererek bir çözüm önerir: muadil bir ürün, düzeltilmiş bir fiyat, yeniden planlanmış bir teslimat ya da düzeltilmiş bir fatura.
İstisna yolu: Adım başarısız ya da tolerans dışında
05
Adım 5: Eşikler dâhilinde onayKişi
Müşteri hizmetleri, lojistik ya da finanstaki bir çalışan istisnayı, kanıtları ve öneriyi istisna masasında görür ve onaylar, düzenler ya da reddeder. Onaylanan işlem asıl kayıt sisteminin API’si üzerinden yürütülür; sistem değişikliği yeni bir olay olarak yayımlar.
İstisna yolu: Adım başarısız ya da tolerans dışında· Dönüş: adım 2
İnsan kontrol noktası
Ajanlar onay olmadan asla mali kayıt atmaz, fiyatları ya da kredi limitlerini değiştirmez ve bir müşteriye taahhütte bulunmaz; kararı insan verir. İşlem türü başına eşikler kimin onaylayacağını belirler; her öneri ve karar kaydedilir.
06
Adım 6: Fatura, eşleştirme ve kapanışSistem
Giden faturalar ERP’den yapılandırılmış e-fatura olarak (Peppol BIS Billing 3.0, EN 16931) bir erişim noktası üzerinden çıkar. Gelen tedarikçi faturaları satın alma siparişleri ve mal kabulleriyle eşleştirilir; bankadan ya da ödeme hizmeti sağlayıcısından gelen ödeme durumu zaman çizelgesini kapatır.
07
Adım 7: Akışı gözden geçirme ve nedenleri gidermeKişi
Süreç sahipleri ve entegrasyon ekibi, gerekçesine göre istisnaları, arayüz hatalarını ve ana veri çelişkilerini düzenli aralıklarla gözden geçirir. Aynı istisnayı tekrar tekrar çözmek yerine nedeni bulunduğu yerde giderirler: bir ana veri kaydında, bir tolerans kuralında ya da bir eşlemede.
Bileşenler
Neler kuracağız
01
Olay güdümlü entegrasyon katmanı
ERP, CRM, e-ticaret, depo, taşıma ve finans arasında, OpenAPI ve AsyncAPI ile tanımlanmış, CloudEvents zarflı, sözleşme öncelikli API’ler ve olaylar; mevcut entegrasyon platformunuzda ya da bulutta yerel olarak kurulur.
Her veri nesnesi için kararlaştırılmış bir asıl kayıt sistemi ve sahip, müşteriler, tedarikçiler ve ürünler için eşleştirme kuralları ve bunların sahiplerine yönelik mükerrer kayıt ve çelişki raporları.
Olayları sipariş ya da talep başına tek bir zaman çizelgesinde ilişkilendiren, kilometre taşı ve tolerans kurallarını uygulayan ve süreç sahiplerine akışı ve istisnaları gösteren bir hizmet.
Toplanan bağlamı ve ajanın önerisini gösteren bir istisna kuyruğu; onaylama, düzenleme ve reddetme işlemleri ve işlemin yürütüldüğü noktada işlem türü başına uygulanan onay eşikleriyle.
UBL biçiminde Peppol BIS Billing 3.0 ve EN 16931 faturaları; bir erişim noktası üzerinden gönderilir ve alınır, gönderilmeden önce doğrulanır, reddedilen faturalar istisna masasına yönlendirilir.
Arayüz başına sağlık izleme ve uyarılar, operasyon ekibi için çalıştırma kılavuzları ve başarısız mesajların kontrollü yeniden oynatılması; bulut ortamınıza kod olarak altyapı yöntemiyle kurulur.
SAP S/4HANA satış, satın alma ve finansPlatformSAP
Salesforce Sales, Service ve Commerce CloudPlatformSalesforce
Odoo satış, stok, satın alma ve muhasebePlatformOdoo
E-ticaret platformları, pazar yerleri ve taşıyıcı API’leri
Depo ve taşıma yönetim sistemleri
Peppol erişim noktası, bankalar ve ödeme hizmeti sağlayıcıları
Ürün bilgi yönetimi ve veri platformu
Kontroller
Tasarıma yerleştirilen kontroller
Erişim sınırları
Her entegrasyon ve ajan, her sistemde yalnızca ihtiyaç duyduğu API işlemleriyle sınırlı kendi hizmet kimliğiyle çalışır. Ajan bağlam toplamak için sistemler arasında okuma yapabilir, ama yalnızca asıl kayıt sisteminin API’si üzerinden yürütülen kısa bir onaylı işlem listesiyle yazabilir; veri tabanına asla doğrudan erişmez.
İnsan incelemesi
Onay eşikleri süreç sahibiyle birlikte işlem türü başına belirlenir: ajanın yalnızca önerebileceği işlemler, bir ekip üyesinin onayladığı işlemler ve ikinci bir onaylayıcı gerektiren işlemler. Mali kayıtlar, fiyat ve kredi limiti değişiklikleri ve müşterilere taahhütler her zaman bir kişiyi bekler. Başarısız bir mesajı yeniden denemek gibi etkisi düşük ve geri alınabilir işlemler, sahip kabul ederse onaysız çalışabilir.
Denetlenebilirlik
Her olay, öneri, onay, ret ve yürütülen işlem; ajanın kullandığı veri, model ve istem sürümü ve onaylayan kişiyle birlikte sipariş ya da talep referansına kaydedilir. İtiraz edilen bir fatura ya da bir müşteri şikâyeti adım adım izlenebilir.
Veri koruma
Müşteri ve tedarikçi iletişim verileri yalnızca onlara ihtiyaç duyan sistemlere akar. Zaman çizelgesi kayıtların tamamını değil, iş referanslarını ve durumları saklar; kayıtlar sizin belirlediğiniz saklama sürelerine uyar. İşleme kararlaştırılan bölgede kalır.
Yapay zekâ şeffaflığı
Ajanın önerileri istisna masasında öneri olarak işaretlenir; kanıtlar ve gerekçe yanlarında gösterilir. Asıl kayıt sistemleri belirleyici olmaya devam eder: zaman çizelgesi onların bildirdiğini gösterir ve onları asla geçersiz kılmaz.
Ölçütler
Neleri ölçeceğiz
Bu ölçütleri keşif aşamasında sizinle birlikte belirliyor ve başlangıç değerini, hiçbir şey değişmeden önce mevcut sistem ve arayüz kayıtlarınızdan alıyoruz.
Neleri ölçeceğiz
Ölçüt
Neden önemli
Nasıl ölçeriz
01Sipariş döngü süresi
Neden önemliMüşterilerin ilk fark ettiği ve siparişlerin nerede beklediğini gösteren ölçüt.
Nasıl ölçerizSipariş alımından teslimata ve ödemeye kadar geçen süre; kanal ve tüzel kişi başına, zaman çizelgesi olaylarından.
02Elle müdahale gerektirmeyen siparişler
Neden önemliAkışın ne kadarının temiz veri ve kararlaştırılmış kurallarla işlediğini gösterir.
Nasıl ölçerizHiçbir elle adım ya da istisna olmadan kapanışa ulaşan sipariş ve taleplerin payı; zaman çizelgesinden.
03Gerekçesine göre istisnalar ve çözüm süresi
Neden önemliHangi nedenlerin önce giderilmesi gerektiğini ve istisna masasının yetişip yetişmediğini gösterir.
Nasıl ölçerizGerekçe kodu başına istisna hacmi ve tespitten yürütülen çözüme kadar geçen süre; istisna masası kayıtlarından.
04E-fatura ret oranı
Neden önemliReddedilen faturalar ödemeyi geciktirir ve çoğu zaman ana veri ya da eşleme hatalarına işaret eder.
Nasıl ölçerizGönderilen ve alınan e-faturalardan reddedilenlerin payı; gerekçesine göre, erişim noktası yanıtlarından.
05Arayüz hataları ve toparlanma süresi
Neden önemliEntegrasyon katmanının güvenilir olup olmadığını ve hataların hızla fark edilip giderilip giderilmediğini gösterir.
Nasıl ölçerizArayüz başına başarısız mesajlar ve hatadan başarılı yeniden oynatmaya kadar geçen süre; entegrasyon izlemesinden.
06Ana veride mükerrer kayıtlar ve çelişkiler
Neden önemliİstisnaların çoğu, sistemler arasında farklılaşan veriden kaynaklanır.
Nasıl ölçerizVeri nesnesi ve sistem başına açık mükerrer kayıtlar ve çelişen değerler; eşleştirme raporlarından.
Başlangıç değeri belirlenmeden hedef konmaz.
Devreye alma
Nasıl devreye alırız
Aşama 01
Keşif ve süreç haritası
Tek bir satış kanalı için siparişten tahsilata gibi tek bir süreç ve tek bir istisna türü. Sistemleri, arayüzleri, veri sahiplerini ve istisnaların bugün nasıl ele alındığını haritalıyoruz.
Çıkış kriterleri
Süreç, sistemler ve veri sahipleri haritalandı
İlk istisna türü ve onay eşikleri kararlaştırıldı
Başlangıç değeri mevcut kayıtlardan alındı
Aşama 02
Entegrasyon ve zaman çizelgesi
Kapsamdaki sistemler için belgelenmiş API’ler ve olaylar; zaman çizelgesi mevcut arayüzlerin yanında, onları değiştirmeden çalışır.
Çıkış kriterleri
Olay sözleşmeleri yayımlandı ve sürümlendi
Zaman çizelgesi, örneklenen siparişlerde asıl kayıt sistemleriyle örtüşüyor
Yeniden oynatma ve çalıştırma kılavuzları test edildi
Aşama 03
İstisna masası pilotu
Ajan, seçilen istisna türü için çözüm önerir ve her öneriyi insanlar onaylar. Önerileri, çalışanların yapacağıyla karşılaştırıyoruz.
Eşikler ve onaylayıcılar işlem türü başına belirlendi
Denetim izi finans ve iç kontrol tarafından incelendi
Aşama 04
Genişletme ve eskiyi kapatma
Daha fazla istisna türü, kanal, tüzel kişi ve satın almadan ödemeye gibi süreçler; hepsi aynı sözleşmeler üzerinde. Eski noktadan noktaya arayüzler tek tek kapatılır.
Çıkış kriterleri
Her yeni akış aynı sözleşmeler ve izleme üzerinde
Yerine yenisi gelen arayüzler hizmetten kaldırıldı
Gıda, içecek ve yapı malzemesi üreticilerinde siparişe göre üretim ve yedek parça siparişleri, ERP’den depoya ve taşıyıcılara; tedarikçi onayları ve e-faturalar satın alma siparişleriyle eşleştirilir.
Enerji hizmet şirketlerinde güneş paneli ve ısı pompası kurulum talepleri, iş emrinden saha ziyaretine ve faturaya kadar izlenir; malzemeler çerçeve anlaşmalara göre satın alınır.
Kamu kurumlarının aldığı EN 16931 e-faturaları dâhil, satın almadan ödemeye: faturalar ödeme öncesinde siparişler ve mal kabulleriyle eşleştirilir.
Açıklayıcı örnek
Kamu alıcılarına da satış yapan bir gıda ve içecek üreticisi
Durum
Bir gıda ve içecek üreticisi perakendecilere, otellere ve kamu kurumlarına satış yapıyor; siparişler EDI, e-posta ve saha satış ekibi üzerinden geliyor. Siparişler ERP’ye yeniden yazılıyor, teslimat sorunları e-postayla bildiriliyor ve kamu kurumlarına giden faturalar ayrıca elle hazırlanıyor.
Sistem
Siparişler, stok, sevkiyatlar ve faturalar ERP, depo sistemi ve dağıtım araçları arasında olay olarak akar; her siparişin tek bir zaman çizelgesi vardır. Kamu kurumlarına giden faturalar, EN 16931 standardında yapılandırılmış e-fatura olarak alıcının kabul ettiği kanal üzerinden gönderilir.
İnsan denetimi
Stok eksikleri ve başarısız teslimatlar tek bir istisna masasına düşer; ajan muadil bir ürün ya da yeni bir teslimat tarihi önerir. Her öneriyi müşteri hizmetleri onaylar ve kararı insan verir; fiyat değişiklikleri ve alacak dekontları finans onayı gerektirir.
Neyi ölçeriz
Müşteri türü ve kanal başına elle müdahale gerektirmeyen siparişlerin payı, gerekçesine göre istisnalar ve çözüm süresi ve e-fatura ret oranı.
Kıbrıs
Tek süreç, farklı ülkeler ve kurallar
Kıbrıs Cumhuriyeti’nde faaliyet gösteren pek çok şirket, siparişten tahsilata ve satın almadan ödemeye süreçlerini birden fazla ülkede, farklı ERP kurulumları, taşıyıcılar ve bankalarla yürütür. Kıbrıs Cumhuriyeti’nde 89(I)/2019 sayılı Yasa uyarınca ihale makamları EN 16931 standardına uygun e-faturaları alır ve işler; diğer ülkelerin zorunlulukları farklı tarihlerde geliyor ve AB’nin Dijital Çağda KDV (ViDA) paketi 1 Temmuz 2030’dan itibaren AB içi B2B teslimlerde yapılandırılmış e-faturayı varsayılan hâlegetiriyor. Her ülkenin biçimini ve ağını aynı olayların arkasına yerleştiren tek bir entegrasyon katmanı tasarlıyoruz; böylece yeni bir zorunluluk yeni bir süreç değil, yeni bir bağlayıcı anlamına gelir.
12 Eylül 2025’ten bu yana uygulanan AB Veri Yasası, veri işleme hizmetleri arasında geçişe ilişkin kurallar koyar; bu yüzden olay sözleşmelerini ve veri dışa aktarımlarını taşınabilir tutuyoruz. İstisna masasındaki ajanlar AB Yapay Zekâ Yasası gözetilerek tasarlanır. Entegrasyonlar, Ağ ve Bilgi Sistemleri Güvenliği Yasası kapsamında tedarik zinciri güvenliğini göstermesi gereken müşteriler için kayıtlı erişim ve belgelenmiş bileşenlerle gelir.
01Her şey için tek bir platforma mı ihtiyacımız var?
Hayır. ERP’niz, CRM’iniz, web mağazanız ve depo sisteminiz her biri kendi işini yapar. Bu asıl kayıt sistemlerinin etrafında entegrasyon kuruyor, hangi sistemin hangi verinin sahibi olduğunu kararlaştırıyor ve sürece bunlar genelinde tek bir zaman çizelgesi veriyoruz. Eski bir sipariş ya da ERP sistemi değişimi engelliyorsa, Eski sistemlerin modernizasyonu yaklaşımıyla önce onu API’lerin arkasına alıyoruz.
02Entegrasyon ara katman yazılımımızı değiştiriyor musunuz?
İşini görüyorsa hayır. Zaten çalıştırdığınız entegrasyon platformu ya da mesaj aracısı üzerine inşa ediyor, eksik olan yerlere sözleşmeler, izleme ve yeniden oynatma ekliyoruz. Hiçbiri yoksa bulutta yerel olarak kuruyoruz. Entegrasyon çalışmalarımız için Entegrasyonlar ve API’ler sayfasına bakın.
03Ajanlar kendi başlarına işlem yapabilir mi?
Yalnızca işlem türü başına kararlaştırdığınız eşikler dâhilinde ve yalnızca başarısız bir mesajı yeniden denemek gibi etkisi düşük, geri alınabilir işlemler için. Mali kayıtlar, fiyatlar, kredi limitleri ve müşterilere taahhütler her zaman bir kişiyi gerektirir. Yapay zekâ ajanlarının nerede insan onayına ihtiyaç duyduğunu okuyun.
04E-fatura gereklilikleri buna nasıl uyar?
Kıbrıs Cumhuriyeti’nde 89(I)/2019 sayılı Yasa, ihale makamlarının ve ihale yapan kuruluşların EN 16931 standardına uygun e-faturaları almasını ve işlemesini öngörür; tedarikçilere bir zorunluluk getirmez ve şirketler arası (B2B) bir e-fatura zorunluluğu yürürlükte değildir. Diğer ülkelerin e-fatura zorunlulukları farklı tarihlerde geliyor ve AB’nin Dijital Çağda KDV (ViDA) paketi, 1 Temmuz 2030’dan itibaren AB içi B2B teslimlerde yapılandırılmış e-faturayı varsayılan hâlegetiriyor. E-faturayı süreçteki bir olay daha olarak ele alıyoruz: ERP’den düzenlenir, bir erişim noktası üzerinden gönderilir ve reddedildiğinde istisna masasında ele alınır. Peppol ve e-fatura rehberimizi okuyun.
05Kırılgan bir noktadan noktaya bağlantı ağını yeniden kurmaktan nasıl kaçınıyorsunuz?
Sistemler, belgelenmiş olayları ve API’leri birbirine doğrudan bağlanarak değil, tek bir katman üzerinden yayımlar ve tüketir. Sözleşmeler sürümlenir, tüketiciler idempotent çalışır, başarısız mesajlar yeniden oynatılabilir ve her akışın adı belli bir sahibi vardır. Yeni bir kanal, her sisteme bir bağlantı eklemek yerine mevcut olaylara abone olur.
06İlk kapsam nasıl olmalı?
Tek bir süreç ve tek bir istisna türü; örneğin ilk istisna olarak stok eksikleriyle, tek bir satış kanalı için siparişten tahsilata. Bu, daha fazlası eklenmeden önce olayları, zaman çizelgesini ve onay akışını kanıtlar. Nasıl teslim ettiğimizi Yaklaşımımız sayfasında okuyun.
Sipariş ve fatura akışlarınızı konuşalım
Bir süreç ve yürüdüğü ülkeleri seçin. Sistemleri, arayüzleri ve istisnaları sizinle birlikte haritalayalım ve tüm tüzel kişileriniz genelinde çalışan bir ilk sürüm önerelim.