Ay sonu. Muhasebe ekibinin masasında yüzlerce navlun faturası var. Her birinde farklı bir yakıt eküreti, bekleme ücreti ya da “unutulmuş” bir köprü geçişi. Lojistik ekibi Excel’deki fiyat listesine bakıyor, finans ekibi satın alma siparişine. Kimse faturanın doğru olup olmadığını tam olarak bilmiyor, ama ödeme vadesi geliyor.
Tanıdık geldi mi? Navlun, birçok üretim ve dağıtım şirketinde satılan malın maliyetinin en büyük kalemlerinden biri. Buna rağmen en az denetlenen kalemlerden biri olmaya devam ediyor.
SAP Transportation Management (TM) bu süreci tersine çeviriyor: masrafı, fatura gelmeden önce sistem hesaplıyor. Taşıyıcıyla yapılan anlaşma, fiyat tabloları ve hesaplama kuralları sistemde duruyor; her navlun siparişinin maliyeti bu kurallarla otomatik çıkıyor. Fatura geldiğinde yapılacak tek şey, sistemin beklenen tutarıyla karşılaştırmak.
Bu yazıda şunları adım adım anlatıyoruz:
Ayrıntılara girmeden önce zincirin tamamına bakalım. Her halka bir sonrakini besler; bir halkadaki eksik ayar, zincirin sonunda yanlış bir muhasebe kaydı olarak geri döner.

Masraf, anlaşmadaki kurallarla navlun siparişinde hesaplanır, FSD ile MM’e aktarılır ve tahakkuk olarak FI’ya düşer. Masraf dağıtımı açıksa tutar giden taşımalarda CO-PA’ya, gelen taşımalarda stok değerine taşınır.
SAP TM’de navlun masrafı tek bir fiyat listesinden değil, iç içe geçmiş üç ana nesneden hesaplanır. Bunları bir sözleşmenin katmanları gibi düşünebilirsiniz: kiminle anlaştınız, hangi kalemleri ödeyeceksiniz ve ne kadar ödeyeceksiniz.

Freight Agreement → Calculation Sheet → Rate Table ve muhasebeye köprü
Anlaşma kalemi bir calculation sheet’i, calculation sheet’in satırları da rate table’ları gösterir. Her satırın charge type’ı ise masrafın hangi ana hesaba gideceğini belirleyen zinciri başlatır.
Freight agreement, yük sahibi ya da lojistik hizmet sağlayıcı ile taşıyıcı arasındaki uzun vadeli sözleşmedir. Başlıkta geçerlilik tarihleri, para birimi, satın alma organizasyonu ve taşıyıcı bulunur. Kalemlerde (item) ise hangi hesaplama tablosunun kullanılacağı, ön koşullar (ör. taşıma türü, güzergah) ve ödeme koşulları tanımlanır.
Sistem, navlun siparişi için uygun anlaşmayı satın alma organizasyonu, taşıyıcı, geçerlilik tarihi ve ön koşullara bakarak kendisi bulur. Bir anlaşma birden fazla satın alma organizasyonunu kapsayabilir.
Calculation sheet, taşıma masrafının hangi kalemlerden oluşacağını tanımlayan hiyerarşik bir tablodur. Her satır bir charge type (masraf türü) taşır: temel navlun, yakıt eküreti, ara durak ücreti, indirim gibi. Bir satırın tutarı üç şekilde gelebilir:
Satırlarda ayrıca calculation resolution base seçilir. Bu alan masrafın hangi seviyede hesaplanacağını belirler: belge başlığı (root), aşama (stage), konteyner veya ürün. Hesaplama yöntemi olarak standart yöntemin yanında break-weight ve clipping de kullanılabilir.
Rate table, gerçek fiyatların tutulduğu yerdir. Fiyatlar scale (ölçek) adı verilen boyutlara göre girilir: varış bölgesi, ağırlık, mesafe, hacim, araç tipi gibi. Bir rate table’da en fazla 14 boyut kullanılabilir ve her fiyat seti kendi geçerlilik dönemine sahiptir. Aynı rate table birden fazla calculation sheet’ten referans alınabilir; fiyatlar Excel ile içe ve dışa aktarılabilir.
Aşağıdaki değerler tamamen örnektir. Bir calculation sheet üç satırdan oluşsun:
Satır | Charge type | Tutarın kaynağı | Resolution base |
10 | Temel navlun | Rate table: varış bölgesi × ağırlık | Root |
20 | Yakıt eküreti | Satır 10'un %12'si | Root |
30 | Ara durak ücreti | Sabit: 750 TRY / durak | Stage |
Temel navlun satırının bağlı olduğu rate table da şöyle görünsün (TRY / sefer):
Varış bölgesi | 0–5.000 kg | 5.001–12.000 kg | 12.001–24.000 kg |
Marmara | 9.500 | 14.000 | 18.500 |
İç Anadolu | 15.000 | 21.000 | 27.500 |
Ege | 13.000 | 19.000 | 24.000 |
İstanbul’dan Ankara’ya 10.000 kg’lık, tek ara duraklı bir sevkiyatta sistem şu hesabı yapar: temel navlun 21.000 TRY, yakıt eküreti 2.520 TRY (%12), ara durak ücreti 750 TRY. Toplam beklenen masraf 24.270 TRY. Taşıyıcının faturası bu tutarla karşılaştırılır.
Planlamacı navlun siparişini (Freight Order) oluşturup taşıyıcıyı atadığında masraf hesaplama tetiklenir. Arka planda dört adım çalışır:

Navlun siparişi: Charges sekmesi; agreement, calculation sheet ve charge type satırları
Charges sekmesi mutabakatın kalbidir. Burada her masraf satırının hangi anlaşmadan, hangi calculation sheet’ten ve hangi rate table hücresinden geldiğini görebilirsiniz. Taşıyıcı bir kalemi itiraz konusu yaptığında tartışma “bizim Excel’e göre” diye değil, “anlaşmanın şu satırına göre” diye yapılır.
Sistemin hesapladığı tutar her zaman son söz değildir. Bekleme ücreti gibi öngörülemeyen kalemler FO’ya manuel eklenebilir, çünkü bu kalemler ancak taşıma gerçekleşince bilinir.
Charge type ile muhasebe arasındaki ilk köprü burada kurulur. Her charge type bir charge category ve subcategory‘ye (ör. Basic Freight, Accessorial) bağlıdır. Bu sınıflandırma, ileride masrafın hangi hizmet ana verisine ve dolayısıyla hangi ana hesaba gideceğini belirler.
Taşıma tamamlandığında masrafın muhasebeleşmesi için Freight Settlement Document (FSD) yaratılır. FSD; lojistik verileri, masrafları ve ticari bilgileri bir arada taşıyan belgedir.

FSD genel bakış: taşıyıcı, satın alma organizasyonu ve yaşam döngüsü statüsü
FSD kaydedilip aktarıldığında (Save and Post) S/4HANA’da arka arkaya şu belgeler oluşur:
SAP’nin kendi ifadesiyle bu PO ve SES “yalnızca tahakkuk kaydı için teknik amaçla” kullanılır. Ama çok değerli bir yan etkileri vardır: SES, taşıyıcı faturası geldiğinde fatura doğrulamanın çalışma listesi olur.
Embedded S/4HANA’da bu aktarım bgRFC ile asenkron çalışır. Hatalı aktarımlar FSD’nin uygulama günlüğünden ve SBGRFCMON işlem koduyla izlenebilir.
Aktarımın doğru çalışması üç eşleştirmeye bağlıdır (Customizing yolu: Transportation Management → Settlement → Freight Settlement → Integration for Settlement Posting). TM organizasyon yapısının PPOME tarafındaki kurgusu bu eşleştirmelerin temelini oluşturur.
Eşleştirme | Ne belirler? |
TM satın alma org. → MM satın alma org. | PPOME'de TM organizasyonunun BSG Org. Unit alanına MM satın alma organizasyonu girilir |
FSD tipi → PO tipi, mal grubu, üretim yeri, satın alma grubu | Assign Purchasing Information for Posting ile oluşacak PO'nun temel verileri |
Charge type → hizmet ana verisi + hesap tayin kategorisi | Assign Service Master Record and Account Assignment Category; hizmet ana verisinin değerleme sınıfı ana hesabı belirler (ör. K = masraf yeri) |
Navlun masrafı FI/CO’ya iki aşamada girer: önce tahakkuk (hizmet alındı, fatura henüz yok), sonra fatura (taşıyıcıya borç oluşur). Aradaki fark, masrafın nereye dağıtıldığıdır.
En basit kurguda navlun bir genel gider olarak masraf yerine yazılır. Hesap, charge type’a eşlenen hizmet ana verisinin değerleme sınıfından bulunur.
Adım | Borç | Alacak | Tetikleyen |
1. Tahakkuk | Navlun gideri (masraf yeri) | GR/IR (mal girişi/fatura girişi) ara hesabı | SES kabulü |
2. Fatura | GR/IR ara hesabı | Taşıyıcı (satıcı hesabı) | Fatura doğrulama (MIRO) |
3. Ödeme | Taşıyıcı | Banka | Ödeme çalıştırması |
Sorun şu: bu kurguda navlun, hangi müşteriye ya da hangi ürüne ait olduğu bilinmeden masraf yerinde yığılır. Müşteri bazlı kârlılık raporları navlunu görmez.
TM, FO’daki toplam navlunu sevkiyattaki sipariş ve teslimat kalemlerine (ERP item) dağıtır. Dağıtım kuralı brüt ağırlık, net ağırlık, brüt hacim, mesafe × ağırlık ya da BAdI ile tanımlanan özel bir kural olabilir.
Örneğin 22.000 kg’lık bir FO üç teslimat taşısın (5.000, 10.000 ve 7.000 kg) ve temel navlun 5.000 USD olsun. Ağırlığa göre dağıtımda teslimatlar sırasıyla 1.135, 2.275 ve 1.590 USD pay alır (bu örnek SAP Learning eğitim içeriğinden alınmıştır).
Dağıtımın muhasebe karşılığı iki adımda oluşur. Tahakkuk önce bir navlun ara hesabına yazılır (OBYC’de GBB işlemi ile belirlenir). Ardından LO Settlement Management’ın yarattığı masraf dağıtım belgesi (belge türü 1600) tutarı nihai hedefine taşır:
Akış | Borç | Alacak | Kârlılığa etkisi |
Tahakkuk (her iki akış) | Navlun ara hesabı | GR/IR ara hesabı | Henüz yok |
Giden (satış) | Navlun gideri: satış siparişi kalemi / CO-PA segmenti | Navlun ara hesabı | Müşteri ve ürün bazlı kârlılıkta navlun görünür |
Gelen (satın alma) | Stok hesabı (malzeme değerlemesi) | Navlun ara hesabı | Navlun stok maliyetine eklenir, satışta SMM'ye döner |
Fatura (her iki akış) | GR/IR ara hesabı | Taşıyıcı (satıcı hesabı) | Yok, tahakkuk kapanır |
Bu akışın iki önemli sonucu vardır:

WLFLTM2: masraf dağıtım belgesi; dağıtılan tutarlar ve hedef nesneler
Kurulum sırası kısaca şöyledir: dağıtım yöntemi (direct ya da hierarchical) ve profilini tanımlayın, profili charges profile’a, charges profile’ı da PPOME’de satın alma organizasyonuna atayın. FO, FB ve FSD tiplerinde dağıtımı açın, charge type’ları MM koşul türlerine eşleyin ve Settlement Management temel ayarlarını yapın. Bu iş, finans ekibiyle birlikte yapılmalıdır.
Yöntem | Nasıl çalışır? | Ne zaman uygun? |
Manuel fatura doğrulama (MIRO) | Kullanıcıya TM_INVOICE_CLERK parametresi verildiğinde MIRO'da TM Ref. sekmesi açılır; FO numarası ya da taşıyıcıyla fatura, sistemdeki masraflarla karşılaştırılır | Taşıyıcı fatura kesiyor, kontrol ekibi var |
Self-billing / ERS | Taşıyıcı fatura göndermez; ödeme FO verisine göre otomatik oluşur, farklar sonradan borç/alacak olarak işlenir | Güvenilir, yüksek hacimli taşıyıcılar |
Kredi notu | Faturalı FO'dan masraf kaldırılamaz; düzeltme FSD'ye dayalı kredi notuyla yapılır | Fatura sonrası düzeltmeler |

MIRO: TM Ref. sekmesi ile navlun siparişi referanslı fatura girişi
SAP TM Freight Settlement ile navlun süreci üç şey kazanır. Öngörülebilirlik: masraf, taşıma başlamadan anlaşmaya göre hesaplanır. Denetlenebilirlik: her fatura kalemi, anlaşmanın bir satırına ve rate table’ın bir hücresine dayanır. Görünürlük: navlun, masraf yerinde kaybolmak yerine satış siparişine, müşteriye ya da stok maliyetine doğru yansır.
MDP Group olarak S/4HANA TM projelerinde navlun anlaşmalarının sisteme taşınmasından masraf dağıtımı ve FI/CO entegrasyonuna kadar tüm settlement sürecini uçtan uca kurguluyoruz. Navlun maliyetlerinizi kontrol altına almak istiyorsanız ekibimizle iletişime geçin.

SAP TM – EWM Danışmanı
Serhan Kurt, taşıma planlama, navlun yönetimi ve depo süreçlerinde SAP TM ve EWM projelerinde yer almaktadır. SAP TM alanında türkçe yazılmış ilk kitap olaran “SAP TM: Senaryolar, Testler ve Uyarlamalar ile Birlikte”nin yazarıdır.
Mailiniz başarıyla gönderilmiştir en kısa sürede sizinle iletişime geçilecektir.
Mesajınız ulaştırılamadı! Lütfen daha sonra tekrar deneyin.