SAP SD: ne yapar ve implementasyonlar nerede aksar

SAP SD (Sales and Distribution), SAP'de order-to-cash sürecini yürütür: teklif, satış siparişi, teslimat, faturalama ve finansa devir. S/4HANA'da proje kapsamı açısından önem taşıyan şekillerde değişir. Müşteriler business partner olur, kredi yönetimi SAP Credit Management'a taşınır, rebate'ler koşul sözleşmelerine geçer ve faturalama doğrudan Universal Journal'a kayıt atar. Bu rehber, SD'nin ne yaptığını ve nerede aksadığını bilmesi gereken satış operasyonları liderleri, finans kontrolörleri ve proje yöneticileri için. İkinci noktadaki kısa yanıt: müşteri ana verileri, fiyatlandırma koşulları, kullanılabilirlik kontrolü ve hesap belirleme. Bu dördünü canlıya geçişten önce gerçek verilerle test edin.

Tam bir SAP implementasyonunun ardından gelen bir rollout'ta order-to-cash adımları tam tasarlandığı gibi kuruldu. Süreç haritasında iyi görünüyorlardı. Üretimden stok güncellemelerinin nasıl geldiğini kimse kontrol etmemişti.

Satış müşterilere beş gün dedi. Üretim ise sürenin on güne yakın olduğunu biliyordu.

Bu fark, geç teslimatlardan fazlasına mal oldu. Güvene mal oldu ve güveni yeniden kazanmak, bir konfigürasyon ayarını düzeltmekten daha zordur.

SD, lojistik zincirinin başında yer alır. Bir müşterinin ilgisini, bir belge zinciri aracılığıyla faturaya dönüştürür:

1. Talep: müşteri fiyat veya stok kullanılabilirliği sorar
2. Teklif: geçerlilik süresi olan resmî bir fiyat ve teslimat teklifi
3. Satış siparişi: müşteri taahhüt eder, kullanılabilirlik kontrolü çalışır ve bir teslimat tarihi teyit edilir
4. Teslimat: depo toplar ve paketler; mal çıkışı stoku azaltır
5. Faturalama: fatura, muhasebe belgesiyle birlikte oluşturulur
6. Ödeme: finans gelen ödemeyi açık kalemle mahsup eder

Her belge bir öncekine referans verir. Bu belge akışı, order-to-cash sürecini izlenebilir kılar. Zincir temizse her faturayı ilk talebe kadar izleyebilirsiniz. Belgeler sırasız oluşturulur ya da atlanırsa raporlama bozulur ve anlaşmazlıklar başlar.

1. 01TalepFiyat veya stok kullanılabilirliği sorulur
2. 02TeklifGeçerlilik tarihli resmî teklif
3. 03Satış siparişiKullanılabilirlik kontrolü tarihi teyit eder
4. 04TeslimatToplama, paketleme, mal çıkışı
5. 05FaturalamaFatura ve muhasebe belgesi
6. 06ÖdemeFinans açık kalemi mahsup eder

Her fatura ilk talebe kadar izlenebilir

İyi yapıldığında bu zincir elle devirleri ortadan kaldırır. Bir üretim müşterisi, SD canlıya geçtikten sonra order-to-cash döngüsünü %40 kısalttı; bunu çoğunlukla satış, depo ve finans arasındaki devirleri ortadan kaldırarak başardı.

Satış siparişleri ve kullanılabilirlik kontrolü

Satış siparişi işleme, SD konfigürasyon çabasının çoğunun toplandığı yerdir: sipariş türleri, kalem kategorileri, teslimat planı satırları ve kullanılabilirlik kontrolü.

Available-to-promise (ATP) en kritik iş parçasıdır. İstenen tarihin stoktan, planlanan girişlerden ve mevcut taahhütlerden karşılanıp karşılanamayacağını kontrol eder. Doğru yapılandırıldığında satış, müşterilere sistemin gerçekten taahhüt edebileceğini söyler. Kötü yapılandırıldığında satış, müşterilere teslim etmeyi umduğu şeyi söyler.

Baştaki rollout'ta üretimden stok güncellemelerinin nasıl geldiğini kimse kontrol etmemişti. Satış, fabrikanın tutturamayacağı tarihleri veriyordu.

Fiyatlandırma ve koşullar

Fiyatlandırma, SD'de en çok hafife alınan kurulumdur. İlk fatura anlaşmazlığına kadar basit görünür.

SD'nin koşul tekniği; baz fiyatları, müşteri iskontolarını, hacim kademelerini, ek ücretleri, navlunu ve vergiyi yönetir. Her öğe, bir erişim sırasına sahip bir koşul türüdür ve değeri koşul kaydı tutar.

En sık gördüğüm fiyatlandırma sorunu: canlıya geçişten kalan ve hiç güncellenmeyen eski fiyatlandırma koşulları. İş birimi bir iskontoyu yeniden müzakere eder, kimse SD'deki koşul kaydını güncellemez, fatura yanlış çıkar ve anlaşmazlık alacak hesaplarına düşer.

Fiyatlandırma yönetişimi bir konfigürasyon kararı değil, bir süreç kararıdır. Birinin koşul kaydı bakımının sahibi olması gerekir.

Sevkiyat

Teslimat işleme; toplama, paketleme ve mal çıkışını kapsar. Mal çıkışı kritik olaydır: stok azalışını kaydeder, teslimatı faturalama bekleyen listesine koyar ve gerçek teslimat tarihini kaydeder. Sevkiyat noktası ve rota belirleme, teslimatların nasıl oluşturulacağını kontrol eder. Karmaşık dağıtım ağlarına sahip şirketler bunu SAP Transportation Management (TM) ile genişletir.

Faturalama, hesap belirleme ve vergi

Faturalama, teslimatı faturaya dönüştürür ve muhasebe belgesini oluşturur. Hesap belirleme, her faturalama kalemini satış organizasyonuna, müşteri ve malzeme hesap atama gruplarına ve koşul türüne göre gelir, vergi ve diğer ana defter hesaplarına eşler. Yanlış olduğunda fatura yanlış hesaba kaydedilir ve finans bunu ay sonunda fark eder.

Vergi belirleme de aynı derecede kırılgandır. Müşterinin vergi sınıflandırmasına, malzemenin vergi sınıflandırmasına ve teslim eden ülkeye ya da yargı alanına bağlıdır. Bir uyumsuzluk, vergiye tabi bir satışta sıfır vergili bir fatura ya da muaf bir satışta vergi doğurabilir.

Kredi yönetimi

Kredi kontrolleri, bir müşteriyi kredi limitinin ötesine taşıyacak siparişleri bloke eder ya da işaretler. Yalnızca limitler güncel tutulursa işe yarar. Canlıya geçişte belirlenen statik limitler, ödeme davranışı ve hacimler değiştikçe anlamını yitirir.

Bir limit, müşterinin olağan sipariş büyüklüğünün altına düştüğünde her sipariş otomatik olarak bloke edilir. Satış ekipleri de limit incelemesi istemek yerine blokları kaldırmayı öğrenir.

Bu kredi yönetimi değildir. Bu bir geçici çözümdür.

SD yapı öğeleri ve her birinin neye bağlandığı şöyle.

Yapı öğesi	SAP SD'deki amacı	Temel bağlantı
Satış organizasyonu	En üst düzey satış birimi; satış koşullarından ve yükümlülükten sorumlu	FI'daki bir şirket koduna atanır
Dağıtım kanalı	Ürünlerin müşteriye ulaşma biçimi (toptan, perakende, doğrudan)	Fiyatlandırmayı, ana verileri ve partner belirlemeyi kontrol eder
Bölüm	Satış organizasyonu içindeki ürün grubu	Raporlama ve çıktı için malzeme gruplaması
Satış alanı	Satış organizasyonu, dağıtım kanalı ve bölümün birlikte oluşturduğu yapı	Her satış belgesi ve müşteri kaydı için zorunludur
Satış ofisi	Coğrafi satış birimi	Bölgesel raporlama ve partner belirleme
Satış grubu	Bir satış ofisi içindeki ekip	Siparişlerde sorumlu kişi
Sevkiyat noktası	Malların sevk edildiği yer	SD'yi depo yönetimine ve taşımaya bağlar
Üretim yeri (plant)	Üreten veya tedarik eden birim	Stokun kaynağı, sevkiyat noktasına bağlı

Satış alanı operatif birimdir. Müşteri satış verileri satış alanı bazında tutulur ve her satış belgesi bir satış alanında oluşturulur. Birçok veri taşıma çalışması burada tökezler: satış alanlarıyla temiz eşleşmeyen eski müşteri kayıtları, yüklemeden önce gerçek bir hazırlık gerektirir.

ECC'den geçiyorsanız, kapsama planlamanız gereken SD değişiklikleri şunlar. SAP bu alanı S/4HANA dokümantasyonunda “Sales” başlığı altında listeler, ancak çoğu ekip hâlâ buna SD diyor.

ECCS/4HANA

MüşterilerECCMüşteri ana kaydıS/4HANAMüşteri rolüne sahip business partner

Kredi yönetimiECCFI-AR-CRS/4HANASAP Credit Management (FIN-FSCM-CR), isteğe bağlı değil

Rebate'lerECCBir indeksten yeniden oluşturulan SD rebate işlemeS/4HANASettlement Management'taki koşul sözleşmeleri

Kullanılabilirlik kontrolüECCTemel ürün kullanılabilirlik kontrolüS/4HANAAdvanced ATP: tahsis, bekleyen siparişler, alternatif üretim yerleri

FaturalamaECCFI ve CO ayrı ayrı mutabık kılınırS/4HANAUniversal Journal'da (ACDOCA) tek kalem

Gelir tanımaECCBirçok programda özel ertelenmiş gelir mantığıS/4HANAAyrıca lisanslanan SAP Revenue Accounting and Reporting

1. Müşteriler business partner olur. Müşteri ana verisi, müşteri rolüne sahip business partner üzerinden tutulur. Bir dönüşümde, müşteri-satıcı entegrasyonunun dönüşüm çalışmadan önce kurulması gerekir.
2. Kredi yönetimi SAP Credit Management'a taşınır. ECC kredi yönetimi (FI-AR-CR) S/4HANA'da bulunmaz. SAP Credit Management (FIN-FSCM-CR) onun yerini alır; dolayısıyla bir dönüşümün kredi verilerini ve ayarlarını taşıması gerekir. İsteğe bağlı değildir.
3. Rebate'ler koşul sözleşmelerine taşınır. Klasik SD rebate işleme, Settlement Management (koşul sözleşmesi yönetimi) ile değiştirilir. Rebate koşulları, bir indeksten yeniden oluşturulmak yerine hemen uygulanır.
4. Advanced ATP. S/4HANA'nın advanced ATP özelliği ürün tahsisi, bekleyen sipariş işleme, üretim yerleri arasında alternatif tabanlı teyit, teslimat için serbest bırakma ve tedarik ataması ekler. S/4HANA Cloud'da bu işlevler standart lisansın parçasıdır. On-premise'de etkinleştirildikten sonra ayrı bir lisans gerekir.
5. Faturalama Universal Journal'a kayıt atar. FI, CO ve marj analizi ACDOCA'da tek bir kalemi paylaşır; bu da ECC'deki FI-CO mutabakat işini ortadan kaldırır. Bunun karşılığı: bir hesap belirleme hatası, kalem düzeyinde görünen, yanlış hesaba anında yapılan bir kayıttır.
6. Gelir tanıma. Çok unsurlu sözleşmeler, abonelikler veya IFRS 15 kapsamındaki uzun vadeli hizmetler için SAP Revenue Accounting and Reporting, birçok ECC programının geliştirdiği özel ertelenmiş gelir mantığının yerini alır. Ayrıca lisanslanır ve yıl sonunda keşfedilmek yerine canlıya geçişten önce tasarlanması gerekir.

Clean Core, SD özelleştirmesinin nasıl ele alınacağını değiştirir. Public cloud'da çekirdekte özel kod mümkün değildir. Private cloud ve on-premise'de mümkündür ama her yükseltmeyi zorlaştırır. Eski fiyatlandırma Z-rutinlerinin çoğu standart koşul türleri, formüller ve BAdI'lerle değiştirilebilir. Gerçekten kalanlar SAP BTP üzerinde side-by-side bir uzantıya aittir. Clean Core rehberim kararı ele alıyor.

SD ile MM

Kullanılabilirlik kontrolü stoku MM'den okur ve mal çıkışı stok hareketini kaydeder. Envanter verisi yanlışsa ATP sonuçları güvenilmezdir. Stok gerçekte sevkiyat noktasında olmadığı için mal çıkışı başarısız olursa teslimat tamamlanamaz ve faturalama durur. İkisini ana veriler ve disiplin yoluyla uyumlu tutun: standart kayıtları atlayan elle stok düzeltmesi yapılmaz.

SD ile PP

Make-to-order senaryolarında bir satış siparişi doğrudan üretimi tetikleyebilir; böylece teyit edilen tarih, bir üretim siparişinin arkasında duran bir taahhüde dönüşür. Malzeme ana kaydındaki strateji grubu, satış siparişleri ile tahminlerin nasıl etkileşeceğini kontrol eder. Yanlış ayarlanırsa birbirini götürmek yerine toplanırlar, planlama çalıştırması talebi olduğundan yüksek gösterir ve fazla üretim gelir. SAP PP rehberim planlama tarafını ele alıyor.

SD ile FI

Faturalama belgesi arayüzdür. Her fatura, geliri, vergiyi ve müşteri açık kalemini Universal Journal'a kaydeden bir muhasebe belgesi oluşturur. Müşteri ana kaydındaki ödeme koşulları vade tarihini belirler. Satış, finansa söylemeden koşullar müzakere ettiğinde sistem, finansın hiç onaylamadığı koşulları uygular.

SD tasarımı tüm geliri faturalama anında tanınmış sayıyor ve sözleşmeler aksini söylüyorsa, sonradan düzeltme pahalıdır. Gelir tanımayı, tasarım onaylanmadan önce finansla kararlaştırın. Entegrasyonun finans tarafı için SAP FICO rehberime bakın.

Canlıya geçiş sonrası sıkıntının çoğuna dört kırılma noktası yol açar.

Müşteri ana verisi hazır değil. Her alan aşağı akışta önemlidir. Eksik vergi sınıflandırması yanlış vergi demektir. Eksik ödeme koşulları, FI'ın vade tarihlerini hesaplayamaması demektir. Eksik sevkiyat koşulları teslimat planlamasını bozar. Hacimler plandaki varsayımdan büyük, kaynak veri ise daha kötüdür ve temizlik iş kararları gerektirir. Erken başlayın ve bunu teknik bir yükleme değil, bir iş akışı olarak ele alın. SAP veri taşıma neden başarısız olur yazım yöntemi ele alıyor.

Fiyatlandırma koşulları bakımı yapılmıyor. Kimsenin gözden geçirmediği canlıya geçiş koşulları, ilk yıl içinde fatura anlaşmazlıklarına dönüşür.

Kullanılabilirlik kontrolü gerçeklikten kopuk. Eskimiş veriyi okuyan ATP, iş biriminin tutamayacağı vaatler üretir. Birim testinde kullanılan temiz test verisiyle değil, gerçek üretim ve stok senaryolarıyla doğrulayın.

Hesap belirleme boşlukları canlıya geçişten sonra fark ediliyor. Gerçek hesap planı, vergi kodları ve malzeme gruplarıyla test edin. Eşleşmeyen vergi kodları, siparişleri bloke edebilir ya da kimse neyin yanlış olduğunu fark etmeden fatura anlaşmazlıklarını tetikleyebilir.

Tablo, UAT onayından önce üzerinden geçeceğim kontrol listesidir.

Risk	Etki	Azaltma
Eksik müşteri ana verisi	Fatura hataları, teslimat başarısızlıkları, FI kayıt boşlukları	Veri iş akışına erken başlayın; veri taşımadan önce satış alanı bazında zorunlu alanları tanımlayın
Eskimiş fiyatlandırma koşulları	Fatura anlaşmazlıkları, hatalı gelir	Canlıya geçişte bir koşul kaydı sahibi ve inceleme döngüsü belirleyin
PP veya MM'den kopuk ATP	Güvenilmez teslimat vaatleri	UAT onayından önce ATP'yi canlı planlama senaryolarıyla test edin
Hesap belirleme boşlukları	Gelirin yanlış hesaplara kaydedilmesi	Gerçek hesap planı ve tam vergi kodu setiyle test edin
Rutin olarak kaldırılan kredi blokları	Kontrolsüz risk, alacak anlaşmazlıkları	Limit incelemelerini zorunlu kılın; ilk 90 günde elle kaldırmaları izleyin
Çıktı test edilmemiş	Faturalar ve irsaliyeler otomatik gönderilmiyor	Canlıya geçişten önce her çıktı türünü gerçek yazdırma ve e-posta yönlendirmesiyle test edin
Uyumsuz ödeme koşulları	Yanlış vade tarihleri, nakit tahmin hataları	Müşteri verisi yüklenmeden önce koşulları satış ve finans arasında kararlaştırın

Satış ekibi inceleme istemek yerine kredi bloklarını rutin olarak kaldırıyorsa, alışkanlık yerleşmeden önce, ilk doksan gün içinde düzeltin.

SAP SD nedir ve ne yapar?

SAP SD (Sales and Distribution) order-to-cash sürecini yönetir: talepler, teklifler, satış siparişleri, teslimatlar, faturalama ve finansal muhasebeye devir. Belge akışı her adımı bir öncekine bağlar; böylece her fatura ilk siparişe kadar izlenebilir. Stok ve mal çıkışı için MM, make-to-order ve kullanılabilirlik için PP, gelir, vergi ve alacaklar için FI ile entegre çalışır.

SAP SD'de organizasyon yapısı nedir?

Operatif birim satış alanıdır: bir satış organizasyonu, dağıtım kanalı ve bölümün birleşimi. Her satış belgesi bir satış alanında oluşturulur ve müşteri satış verileri satış alanı bazında tutulur. Satış ofisleri ve satış grupları raporlama ve sorumluluk için altta yer alır. Lojistik tarafında, malların nereden sevk edileceğini sevkiyat noktaları ve üretim yerleri belirler. Müşteri verisi yüklenmeden önce yapıyı doğru kurun, çünkü sonradan değiştirmek verileri yeniden yüklemek demektir.

SAP SD'de fiyatlandırma nasıl çalışır?

Fiyatlandırma koşul tekniğini kullanır. Her fiyat öğesi bir koşul türüdür, bir erişim sırası hangi koşul kaydının geçerli olacağına karar verir ve bir fiyatlandırma prosedürü koşul türlerini sırayla birleştirir. Fiyatlandırma anlaşmazlıklarının çoğu konfigürasyon hatalarına değil, ticari koşullar değiştiğinde güncellenmeyen koşul kayıtlarına dayanır.

SAP S/4HANA'da advanced ATP nedir?

Advanced available-to-promise (aATP), S/4HANA'nın kullanılabilirlik kontrolüdür. Temel ürün kullanılabilirlik kontrolünün ötesinde ürün tahsisi, bekleyen sipariş işleme, üretim yerleri arasında alternatif tabanlı teyit, teslimat için serbest bırakma ve tedarik ataması ekler. Bu işlevler S/4HANA Cloud'a dahildir ve on-premise'de etkinleştirildikten sonra ayrı bir lisans gerektirir. Tedarikin kısıtlı olduğu ya da tahsis kurallarının önemli olduğu yerlerde kullanın. İstikrarlı tedarik zincirlerinde iyi yapılandırılmış bir temel kontrol çoğu zaman yeterlidir.

SAP SD finansal muhasebe ile nasıl entegre olur?

Faturalama belgesi üzerinden. Bir faturalama belgesini muhasebeye aktarmak; gelir, vergi ve müşteri açık kalemi için bir yevmiye kaydı oluşturur. Hesap belirleme, ana defter hesaplarına satış organizasyonu, hesap atama grupları ve koşul türünden karar verir. Vergi, müşteri ve malzeme vergi sınıflandırmalarına bağlıdır. Müşteri ana kaydındaki ödeme koşulları vade tarihini belirler. IFRS 15 durumlarında SAP Revenue Accounting and Reporting geliri zamana yayarak erteler ve tanır.

ECC'den S/4HANA'ya geçerken SAP SD'de neler değişir?

Müşteriler business partner olur. Kredi yönetimi FI-AR-CR'dan, zorunlu olan SAP Credit Management'a taşınır. Rebate işleme, Settlement Management'taki koşul sözleşmeleriyle değiştirilir. Advanced ATP kullanılabilir hale gelir ve faturalama Universal Journal'a kayıt atar. Bunların hepsini kapsama erkenden alın, çünkü her biri konfigürasyon, veri taşıma ve test gerektirir.

En yaygın SAP SD implementasyon hataları nelerdir?

Beş hata sürekli karşıma çıkıyor. Müşteri ana verisini hafife almak. Fiyatlandırma koşullarını canlıya geçişten sonra sahipsiz bırakmak. ATP'yi yalnızca temiz veriyle test etmek. Hesap belirlemeyi sadeleştirilmiş veriyle test etmek. Çıktıyı uçtan uca test etmemek. Sonuncusunu kaçırmak kolaydır. Faturalar otomatik gitmediğinde biri bunları elle yazdırmaya başlar ve bu geçici çözüm kalıcı hale gelir.