S
Serhan Kurt
Misafir
Misafir
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
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:
Temel navlun satırının bağlı olduğu rate table da şöyle görünsün (TRY / sefer):
İ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
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.
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:
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.
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.
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
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
, 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:
- Freight Agreement, Calculation Sheet ve Rate Table’ın birbirine nasıl bağlandığı
- Navlun siparişinde masrafın nasıl hesaplandığı
- Freight Settlement Document’in MM’e nasıl aktarıldığı
- Ve en önemlisi: bu masrafların FI/CO’da hangi kayıtları oluşturduğu ve karlılığa nasıl yansıdığı
Anlaşmadan muhasebe kaydına süreç akışı
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.
Üç yapı taşı: Agreement, Calculation Sheet ve Rate Table
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.
1. Freight Agreement (Navlun Anlaşması): “Kiminle?”
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.
2. Calculation Sheet (Hesaplama Tablosu): “Hangi kalemler?”
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:
- Bir rate table‘dan (en yaygın)
- Sabit tutar olarak
- Başka bir satırın yüzdesi olarak (ör. temel navlunun %12’si yakıt eküreti)
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.
3. Rate Table (Fiyat Tablosu): “Ne kadar?”
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.
Bir örnekle birlikte okuyalım
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.
Navlun siparişinde masraf nasıl hesaplanı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:
- Anlaşma tayini: Sistem FO’daki satın alma organizasyonu ve taşıyıcıyla eşleşen, tarihi geçerli ve ön koşulları tutan freight agreement’ı bulur.
- Hesaplama tablosu: Anlaşma kalemindeki calculation sheet okunur; hangi charge type’ların hesaplanacağı belli olur.
- Fiyat okuma: Her satır için FO’dan ilgili değerler alınır (ağırlık, varış lokasyonu, mesafe vb.) ve rate table’daki doğru hücre bulunur.
- Sonuç: Hesaplanan tutarlar FO’nun Charges sekmesine yazılı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.
Freight Settlement Document: lojistikten muhasebeye geçiş
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 nasıl yaratılır?
- Tekil ya da toplu: Bir FSD tek bir navlun siparişi/rezervasyonu için yaratılabileceği gibi, aynı taşıyıcının birden fazla belgesi için toplu (collective) da yaratılabilir.
- Giriş noktaları: FO ya da FB ekranı, settlement iş listeleri ve toplu yaratma için arka plan işi (Creation and Transfer of Freight Settlement Documents).
- Masraflar: Genellikle FO’dan kopyalanır; istenirse freight agreement’a göre yeniden hesaplanır.
- Belge tipi ve profil: FSD tipi, FO tipinden gelir. Settlement profile ise FO’daki satın alma organizasyonuna atanmış charges profile üzerinden belirlenir.
FSD genel bakış: taşıyıcı, satın alma organizasyonu ve yaşam döngüsü statüsü
MM’e aktarım: satın alma siparişi ve hizmet girişi
FSD kaydedilip aktarıldığında (Save and Post) S/4HANA’da arka arkaya şu belgeler oluşur:
- Hizmet satın alma siparişi (PO): FSD’deki her masraf bölümü bir PO kalemi olur. Aşama (stage) bazlı hesaplamada her aşama ayrı bir PO kalemine dönüşür.
- Hizmet giriş kâğıdı (Service Entry Sheet, SES): Her PO kalemi için kabul edilmiş bir hizmet girişi yaratılır.
- Tahakkuk kaydı: Hizmet kabulü, FI’da tahakkuk muhasebe belgesini oluşturur ve FSD statüsü Accruals Posted olur.
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.
Eşleştirme ayarları: TM’den MM’e hangi bilgi taşınır?
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
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
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) |
FI/CO etkisi: navlun masrafı bilançoya ve kârlılığa nasıl yansır?
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.
Senaryo A: Masraf dağıtımı olmadan (masraf yeri)
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.
Senaryo B: Masraf dağıtımı (cost distribution) ile
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:
- Giden taşımalarda CO-PA’da her satış siparişi kalemi ve müşteri için “gelir – taşıma maliyeti” ilişkisi görünür hale gelir. Hangi müşteriye yapılan satışın navlun yüzünden zarar ettiğini artık tahmin etmezsiniz, raporda görürsünüz.
- Gelen taşımalarda navlun malzemenin değerine eklenir. Hareketli ortalama fiyatlı malzemelerde etki kayıt anında, standart fiyatlı malzemelerde bir sonraki değerleme çalışmasında görülür. Etkiyi MM03 → Muhasebe 1 görünümü → Mat. Price Analysis ile izleyebilirsiniz.
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.
Fatura doğrulama: üç yol
| 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
Sonuç: navlun faturası artık sürpriz değil
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.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.