B2B E Ticaret Çok Şirketli Yapılarda Sipariş ve Fatura Yetkilerini Nasıl Yönetir?

Çok şirketli B2B yapısı neden ayrı yetki modeli gerektirir?

Çok şirketli yapı, her işlemin hangi tüzel kişilik adına yapıldığını sistematik biçimde belirlemek zorunda olduğu için ayrı bir yetki modeli gerektirir. Tek kullanıcı hesabına sınırsız şirket erişimi vermek yerine kullanıcı, şirket, rol ve işlem yetkisi birlikte değerlendirilmelidir. Temel güvenlik sınırı şirket bağlamıdır; kullanıcı portalda şirket değiştirdiğinde fiyat, adres, fatura, sipariş geçmişi ve onay akışı da seçilen bağlama göre değişmelidir.

Yetki modeli hangi nesneleri birbirinden ayırmalıdır?

Kurgu yalnızca giriş yetkisini değil, kullanıcının her şirket içinde ne görebileceğini ve hangi işlemi hangi aşamaya kadar ilerletebileceğini tanımlar. Bu nedenle kurumsal e-ticaret yazılımının teknik özellikleri değerlendirilirken hesap ve rol modeli, katalog kadar kritik bir gereksinimdir. Mimari sade tutulduğunda yeni şirket, rol veya onay seviyesi eklemek de daha kontrollü hale gelir.

• Kullanıcı ile erişebildiği şirketler ayrı ilişki olarak tutulmalıdır.
• Her şirketin fiyat, ürün ve adres kuralları bağımsız tanımlanmalıdır.
• Rol yetkileri şirket bazında farklılaştırılabilmelidir.
• Sipariş ve fatura işlemleri aynı şirket bağlamını korumalıdır.
• Yetki değişiklikleri geçmişe dönük izlenebilir olmalıdır.

Sadelik, güvenilirliğin ön koşuludur. - Edsger W. Dijkstra

Bir kullanıcı birden fazla şirket adına nasıl işlem yapar?

Bir kullanıcı birden fazla şirket adına, yalnızca kendisine atanmış şirketler arasından aktif işlem bağlamını seçerek hareket etmelidir. Portal oturumu kullanıcı kimliğini korurken seçilen şirket ayrı bir çalışma bağlamı olarak tutulur. Böylece aynı kişi A şirketinde satın alma talebi oluşturabilir, B şirketinde yalnızca sipariş görüntüleyebilir ve C şirketinde hiçbir finansal bilgiye erişemeyebilir. Şirket değiştirme işlemi açık, görünür ve yanlış seçim riskini azaltacak şekilde tasarlanmalıdır.

Çoklu hesap deneyiminde hangi kontroller gerekir?

B2B çoklu hesap yönetiminde kullanıcıya tek oturum kolaylığı sağlanırken şirketler arasındaki veri sınırı gevşetilmemelidir. Şirket seçimi yapıldığında sepet, teslimat adresleri, ödeme koşulları ve onay zinciri yeniden doğrulanmalıdır. Benzer biçimde portal yazılımında modül ve entegrasyon planlaması yapılırken şirket seçicinin yalnızca arayüz bileşeni değil, tüm iş kurallarını etkileyen merkezi bir bağlam olduğu kabul edilmelidir.

• Kullanıcı yalnızca atanmış şirketleri seçebilmelidir.
• Aktif şirket ekranın anlaşılır bir noktasında gösterilmelidir.
• Şirket değişiminde sepet ve oturum verileri yeniden kontrol edilmelidir.
• Rol ve limitler seçilen şirkete göre tekrar hesaplanmalıdır.
• Yetkisiz şirket kimliği URL veya API üzerinden kullanılamamalıdır.

Ürün ve fiyat erişimi şirket bazında nasıl ayrıştırılır?

Ürün ve fiyat erişimi, müşteri grubundan daha ayrıntılı bir şirket kuralı gerektiğinde tüzel şirket bazında ayrıştırılabilir. Aynı kullanıcı farklı şirketlere geçtiğinde farklı katalog, iskonto yapısı, sözleşmeli ürün, minimum sipariş kuralı veya para birimi görebilir. Fiyatın kaynağı kullanıcı değil şirket hesabı olmalıdır; böylece kişisel erişim değişse bile ticari koşullar doğru tüzel kişiliğe bağlı kalır ve yönetilebilirlik korunur.

Katalog ve ticari koşullar nasıl modellenmelidir?

Kurumsal satın alma portalı geliştirirken ürün görünürlüğü ile fiyatlama kuralını tek bir yetki alanına sıkıştırmak yerine ayrı katmanlar olarak modellemek daha sağlıklıdır. Bir şirket ürünü görebilir fakat sipariş veremeyebilir; başka bir şirket aynı ürünü farklı fiyat listesiyle satın alabilir. Bu ayrım, kampanya ve özel sözleşme koşullarının da daha açık yönetilmesini sağlar ve müşteri yöneticisinin hangi alanı değiştirebileceğini netleştirir.

• Ürün görünürlüğü şirket veya şirket grubu bazında tanımlanabilir.
• Fiyat listeleri cari hesap veya sözleşme mantığına bağlanabilir.
• İskonto ve ödeme koşulları ayrı kurallar olarak yönetilebilir.
• Satın alma engelleri ürün görünürlüğünden bağımsız uygulanabilir.
• Özel katalog değişiklikleri kayıt altına alınmalıdır.

Teslimat ve fatura yetkileri şirket bazında nasıl sınırlandırılır?

Teslimat ve fatura yetkileri, kullanıcıya serbest metinle bilgi girdirmek yerine seçilen şirketin doğrulanmış adres ve hesap kayıtları üzerinden sınırlandırılmalıdır. Bir kullanıcının sipariş oluşturabilmesi, yeni teslimat adresi ekleyebileceği veya fatura bilgisi değiştirebileceği anlamına gelmez. Şirket bazlı fatura yetkisi özellikle farklı vergi kimlikleri, şubeler veya iştirakler bulunan yapılarda siparişin yanlış tüzel kişiliğe bağlanmasını önleyen temel kontrol katmanlarından biridir.

Adres ve fatura verisinde sorumluluk nasıl ayrılır?

Satış şirketi ana cari, vergi ve sözleşme verilerinin kaynağını yönetirken müşteri şirketi yöneticisine yalnızca yetki verilen operasyonel alanlar açılabilir. Örneğin müşteri yöneticisi mevcut adresleri kullanıcılara atayabilir ancak yeni fatura hesabı açamaz. Bu ayrım, veri sahipliğini belirsiz bırakmadan operasyonu hızlandırır. Kritik değişikliklerin doğrudan sipariş sırasında değil, kontrollü bir yönetim akışında yapılması hata riskini azaltır.

• Fatura hesabı seçilen şirket ile zorunlu olarak eşleşmelidir.
• Teslimat adresleri kullanıcı bazında ayrıca kısıtlanabilmelidir.
• Yeni adres ekleme yetkisi sipariş verme yetkisinden ayrılmalıdır.
• Vergi ve cari alanlarında değişiklik daha yüksek yetki gerektirmelidir.
• Pasif veya doğrulanmamış kayıtlar siparişte kullanılamamalıdır.

Sipariş için kaç onay seviyesi gerektiği nasıl belirlenir?

Sipariş için gereken onay seviyesi sabit bir sayıdan değil, kurumun satın alma politikası ve risk yapısından türetilmelidir. Küçük bir talep tek onayla ilerleyebilirken belirli ürün grupları, bütçe eşikleri, maliyet merkezleri veya şirketler ek onay gerektirebilir. Onay akışlı sipariş yazılımı tasarlanırken amaç mümkün olduğunca çok adım eklemek değil, doğru işlemi doğru sorumlunun onayına taşımak olmalıdır.

Rol tabanlı onay akışı nasıl kurgulanmalıdır?

Tipik akışta talep oluşturan kullanıcı, bölüm veya şirket onaylayıcısı ve siparişi kesinleştiren yetkili farklı rollerde bulunabilir. Gerektiğinde finans, merkez satın alma veya özel ürün sorumlusu koşullu onay adımı olarak eklenebilir. Akışın şirket bazında parametrik olması, aynı portal içinde farklı iştiraklerin farklı kurallarla çalışmasına izin verir. Ret, iade ve revizyon senaryoları da ilk tasarımda düşünülmelidir; yalnızca başarılı onay yolunu modellemek yeterli değildir.

• Onay seviyesi şirket ve sipariş koşullarına göre belirlenmelidir.
• Tutar, ürün grubu veya maliyet merkezi tetikleyici olabilir.
• Onaylayan ile siparişi oluşturan roller ayrıştırılabilir.
• Ret ve revizyon adımları açık durumlarla izlenmelidir.
• Vekâlet ve geçici yetki için başlangıç ve bitiş tarihi tutulmalıdır.

ERP’ye doğru cari ve şirket kodu nasıl güvenle aktarılır?

ERP’ye doğru cari ve şirket kodu, sipariş anındaki kullanıcı seçimine güvenilerek değil portalın şirket eşleştirme tablosu ve sunucu tarafı doğrulaması üzerinden aktarılmalıdır. Portal şirketi, ERP cari hesabı, satış organizasyonu ve gerekiyorsa şube ya da depo kodu önceden ilişkilendirilmelidir. Sipariş kesinleşirken sistem bu eşleşmeyi yeniden kontrol etmeli; eksik veya çelişkili kayıt varsa aktarımı durdurup kontrollü hata sürecine yönlendirmelidir.

Entegrasyonda hangi alanlar birlikte doğrulanmalıdır?

Çok şirketli B2B sipariş sisteminde entegrasyon yalnızca sipariş numarası göndermekten ibaret değildir. Cari hesap, fiyat koşulu, teslimat noktası, ödeme planı, vergi bilgisi ve siparişi oluşturan şirket aynı bağlamı taşımalıdır. ERP entegrasyonlu B2B e-ticaret yapısının planlanması sırasında veri eşleme kuralları, hata kodları ve tekrar gönderim senaryoları teknik şartnamenin açık bir parçası olmalıdır.

• Portal şirketi ile ERP cari hesabı tekil biçimde eşleştirilmelidir.
• Şirket kodu sunucu tarafında doğrulanmadan ERP’ye gönderilmemelidir.
• Adres ve vergi alanları sipariş bağlamıyla karşılaştırılmalıdır.
• Başarısız aktarım için tekrar deneme ve hata kaydı bulunmalıdır.
• ERP yanıtı portal siparişine referans olarak kaydedilmelidir.

Satış ve müşteri yöneticileri hangi ayarları yönetmelidir?

Satış şirketi ile müşteri şirketi yöneticileri aynı yönetim yetkilerine sahip olmamalıdır. Satış tarafı ticari hesap eşleştirmesi, fiyat kaynağı, ERP bağlantısı ve ana sözleşme verilerini yönetirken müşteri yöneticisi kendi şirketindeki kullanıcı davetleri, rol atamaları ve operasyonel onaycıları yönetebilir. Bu ayrım, self servis kullanım kolaylığını korurken kritik ticari verilerin kontrolünü satıcı organizasyonda bırakır.

Yönetim sınırları sözleşme ve süreçle nasıl netleştirilir?

Kurumsal müşteri portalı geliştirme kapsamında hangi ayarın kime ait olduğu yalnızca ekran tasarımında değil proje kapsamı ve işletim modelinde de yazılmalıdır. kurumsal B2B e-ticaret projesi ve teklif kapsamı değerlendirilirken yönetici rolleri, destek sorumlulukları ve veri sahipliği ayrıca ele alınmalıdır. Böylece canlı kullanımda her değişiklik için yazılım ekibine bağımlı kalınmaz, ancak kritik alanlarda kontrolsüz self servis de oluşmaz.

• Satış yöneticisi cari ve entegrasyon eşleşmelerini yönetebilir.
• Müşteri yöneticisi kendi şirket kullanıcılarını yönetebilir.
• Fiyat ve sözleşme alanları sınırlı yetkide tutulabilir.
• Onaycı atama hakkı şirket politikasına göre devredilebilir.
• Kritik ayarlar için çift kontrol veya merkez onayı tanımlanabilir.

Yetki değişiklikleri ve erişim kayıtları nasıl tutulmalıdır?

Yetki değişiklikleri; kimin, hangi kullanıcıya, hangi şirkette, hangi rolü, ne zaman verdiği veya kaldırdığı bilgisiyle kaydedilmelidir. Erişim kayıtları ise yalnızca oturum açmayı değil şirket değiştirme, sipariş oluşturma, onay verme, fatura hesabı seçme ve kritik yönetim işlemlerini de kapsamalıdır. Denetim izi sonradan oluşturulan bir rapor değil, işlem anında üretilen kayıt olmalıdır.

Kayıtlar operasyon ve güvenlik için nasıl kullanılmalıdır?

Bu kayıtlar hata araştırması, müşteri destek süreci, yetkisiz işlem incelemesi ve süreç iyileştirmesi için ortak referans sağlar. Her olay için kullanıcı, şirket, işlem, zaman, sonuç ve mümkünse ilgili sipariş veya kayıt kimliği tutulmalıdır. Log erişimi de rol bazında sınırlandırılmalı; normal kullanıcıların hassas denetim kayıtlarını görmesi engellenmelidir. Saklama ve erişim politikaları kurumun teknik, sözleşmesel ve mevzuata ilişkin gereksinimlerine göre ayrıca belirlenmelidir.

• Rol ekleme ve kaldırma işlemleri ayrı olay olarak kaydedilmelidir.
• Şirket bağlamı her kritik işlem kaydında bulunmalıdır.
• Onay ve ret işlemleri sipariş kimliğiyle ilişkilendirilmelidir.
• Log görüntüleme yetkisi sınırlı yönetici rollerine verilmelidir.
• Kayıt saklama politikası kurum gereksinimlerine göre tanımlanmalıdır.

Çok şirketli B2B portal projesi nasıl aşamalı planlanır?

Çok şirketli B2B portal projesi, önce şirket ve kullanıcı modelini doğrulayan çekirdek kapsamla başlayıp daha sonra onay akışları, ERP entegrasyonu ve gelişmiş yönetim yetkilerini ekleyecek şekilde aşamalı planlanabilir. İlk keşifte şirket sayısı, kullanıcı rolleri, onay seviyeleri, fiyat kaynakları, adres yapısı ve ERP’deki cari kodlama mantığı netleştirilmelidir. Bu bilgiler olmadan yalnız ekran listesi üzerinden alınan tekliflerin kapsamı karşılaştırmak güçleşir.

Teknik mimari görüşmesine hangi bilgilerle hazırlanılmalıdır?

Çözüm karşılaştırırken yalnız özellik sayısına değil, şirket sınırlarının nasıl uygulandığına, entegrasyon hatalarının nasıl yönetildiğine ve yöneticilerin hangi işlemleri self servis yapabildiğine bakılmalıdır. Aşamalı geliştirme, temel veri modelini sonradan değiştirmeyecek bir mimariyle planlandığında daha kontrollü ilerler. Teklif talebinde örnek şirket yapısını, rollerinizi ve onay senaryolarınızı paylaşmak, geliştirme ekibinin gerçek iş akışına göre teknik kapsam çıkarmasını kolaylaştırır.

• Şirket ve kullanıcı matrisi keşif öncesinde hazırlanmalıdır.
• Onay seviyeleri ve koşulları örnek senaryolarla açıklanmalıdır.
• ERP cari ve şirket kodu eşleşmeleri paylaşılmalıdır.
• İlk faz ile sonraki fazların sınırı açıkça belirlenmelidir.
• Yetki, log ve yönetim sorumlulukları teklifte ayrı kalemler olmalıdır.