S/4HANA’da İç Sipariş Ana Verileri: KOT2_OPA, KO01, BS23

S/4HANA'da iç sipariş ana verileri: KOT2_OPA ile sipariş türü, sipariş düzeni, numara aralığı grubu ve KO01 ile ilk siparişin adım adım kurulumu.

Bir ilaç şirketinde yeni bir ürünün tanıtım kampanyası birkaç ay sürer, kendine ait bir bütçesi olur ve bittiğinde kapanır. Bu tür işlerin masrafını departman masraf yerlerinin içinde izlemek zordur. SAP'de bunun için iç sipariş kullanılır: belirli bir iş için açılan, masrafı toplayan ve iş bitince kapatılan bir masraf taşıyıcısı.

Bu yazıda SAP S/4HANA 2025 sandbox sistemimizde, örnek şirketimiz SMUH (İstanbul Jenerik İlaç A.Ş.) için iç sipariş ana verilerini sıfırdan kuruyoruz. Dört adımda ilerleyeceğiz: sipariş yönetimini etkinleştirip pazarlama siparişleri için bir sipariş türü tanımlayacağız, sipariş ekranının sekmelerini düzenleyeceğiz, SMUH'ye ait bir numara aralığı açacağız ve ilk siparişi yaratıp onaylayacağız. Yol boyunca sistemin beklediğimizden farklı davrandığı üç yerle karşılaştık; onları da olduğu gibi anlatıyoruz.

[post_ads_2]

• [accordion]
• 1. Sipariş Yönetimini Etkinleştirme ve Sipariş Türü
• İç siparişlerle ilgili bütün uyarlama adımları IMG'de Maliyet muhasebesi ve kontrol ▸ İç siparişler düğümünün altındadır.
  

  

  Ekran 1: IMG'de İç siparişler düğümü ve Sipariş ana verileri adımları

  Kontrol Kodunda sipariş yönetimi
  İlk adım Kontrol kodunda sipariş yönetiminin etkinleştirilmesi. Bu adım yeni bir ekran açmaz; Kontrol Kodunu tanımlarken kullandığımız OKKP ekranının Bileşenleri etkinleştir/denetim göstergeleri bölümüne götürür. Ayarlar mali yıl aralığına bağlıdır; SMUH'de aralık 2026–9999.
  

  

  Ekran 2: OKKP: SMUH Kontrol Kodunda Sipariş yönetimi bileşeni etkin

  Burada Sipariş yönetimi alanı Bileşen etkin olmalıdır. Etkin değilse iç siparişe kayıt yapılamaz. Bir satır altındaki Açık kalem yönetimi alanı adından ötürü yanıltıcıdır: FI'daki açık kalem yönetimiyle ilgisi yoktur. İngilizcesi "Commitment Management"tır ve satınalma talebi ile siparişlerinden doğan, henüz faturalanmamış yükümlülüklerin siparişte izlenmesini sağlar. Bütçe kontrolü kullanacaksanız bu bileşen de etkin olmalıdır.
  
  Sipariş türü: Z400
  Sipariş türü, benzer amaçlı siparişleri gruplar ve numara aralığı, masraf yükleme profili, bütçe profili gibi ayarları belirler. SAP pazarlama, yatırım, bakım gibi amaçlar için hazır türler teslim eder. Bunları doğrudan kullanmak yerine kopyalayıp kendi türümüzü yaratıyoruz. İşlem kodu KOT2_OPA, IMG'deki adım Sipariş türlerini tanımla.
  
  Listede 0400 İç sipariş – pazarlama satırını seçip Farklı kopyala ile Z400 türünü yarattık. Sipariş türleri istemci düzeyindedir, yani sistemdeki bütün şirketler aynı listeyi görür. Bu yüzden tanıma şirketin adını ekledik: SMUH İç sipariş – pazarlama. Aşağıdaki listede sistemin kendi Y400 "İç sipariş: Pazarlama" türü de görünüyor; ad eklemek ikisini karıştırmamayı sağlıyor.
  

  

  Ekran 3: KOT2_OPA: Sipariş türleri listesinde yeni Z400 türü

  

  Ekran 4: Z400 sipariş türünün ayrıntı ekranı

  Ekrandaki alanların SMUH'deki değerleri ve anlamları:
  

  Alan	Değer	Ne işe yarar
  Sipariş tipi	1 İç sipariş (CO)	Siparişin hangi uygulamaya ait olduğunu gösterir. Üretim ve bakım siparişleri başka tiplerdedir.
  Numara alanı aralığı	400000 – 499999	0400'den devralındı. Üçüncü bölümde SMUH'ye ait bir aralıkla değiştireceğiz.
  Msf.yükleme profili	20	Siparişte toplanan masrafın dönem sonunda hangi alıcılara yüklenebileceğini belirler.
  Plan profili	000001	Sipariş planlamasının ayarları.
  Bütçe profili	Z00001	Bütçeleme ve kullanılabilirlik kontrolü. Bütçeleme yazısının konusu.
  Nesne sınıfı	GNMSF Genel masraflar	Siparişi amacına göre sınıflandırır. Zorunlu alandır.
  CO mhtp.güncellemesi	Etkin	Masraf yükleme ve dağıtımlarda gönderen ile alıcının birlikte izlenmesini sağlar.
  Açık kalem yönetimi	Seçili	Bu türdeki siparişlerde satınalma yükümlülükleri izlenir.
  Gelir kayıtları	Boş	Pazarlama siparişi gelir almaz.
  Hemen onayla	Boş	Sipariş yaratıldığında onaylanmamış durumda açılır. Dördüncü bölümde bunun etkisini göreceğiz.
  Sipariş düzeni	Z1	Sipariş ekranının sekme yapısı. İkinci bölümde yaratıyoruz.

  İşlev alanı, Yürütme profili ve Örnek sipariş alanlarını boş bıraktık. Kaydetmeden önce nesne sınıfını doldurmayı unutmayın; boşsa sistem kaydetmez.
• 2. Sipariş Düzeni: Sipariş Ekranının Sekmeleri
• Sipariş düzeni, iç sipariş ana veri ekranının (KO01, KO02, KO03) iskeletidir: ekranda hangi sekmelerin bulunacağını, sıralarını, adlarını ve hangi veri bloğunun hangi sekmede duracağını belirler. Bir alanın zorunlu ya da gizli olması ise sipariş düzeninin değil, alan seçiminin işidir. IMG'de ikisi Ekran düzeni klasörünün altında iki ayrı adımdır: Alan seçimini yürüt ve Sipariş düzenlerinin belirlenmesi.
  
  Sipariş düzenlerinin belirlenmesi adımında standart düzen SAP0 görünür.
  

  

  Ekran 5: Sipariş düzenleri: standart SAP0 düzeni

  SAP0'ı seçip Farklı kopyala ile Z1 adını verdik. Sistem düzenle birlikte ona bağlı bütün girişleri de kopyalar.
  

  

  Ekran 6: SAP0'dan kopyalanan Z1 düzeni

  

  Ekran 7: Kopyalanan bağlı girişlerin sayısı: 663

  "Sicil kartı" ne demek?
  Sol taraftaki klasörlerin adı ilk bakışta şaşırtıcıdır: Sicil kartı başlığı ve Sicil kartları grup çerçevesi satır kalemi. SAP'nin Türkçe arayüzünde sicil kartı, bildiğimiz sekme demektir; Almanca "Registerkarte" kelimesinin birebir çevirisidir. Bu yazıda sekme diyoruz, ekran adlarını ise sistemde göründüğü gibi yazıyoruz.
  
  Sicil kartı başlığı klasöründe her sekmenin numarası ve adı tutulur. Adlar dile bağlıdır; her sekme için her dilde ayrı bir satır vardır.
  

  

  Ekran 8: Sicil kartı başlığı: sekme adları dil bazında tutulur

  Yatırımlar sekmesini kaldırmak
  Standart düzende beş sekme var: Tayinler, Denetim, Dönem sonu kapanışı, Genel veriler ve Yatırımlar. Pazarlama kampanyası bir yatırım olmadığı için son sekmeye ihtiyacımız yok. Z1'de önce Yatırımlar sekmesine ait grup çerçevesi satırlarını, ardından bu sekmenin Sicil kartı başlığı satırlarını sildik ve kaydettik. Değişiklik yalnızca Z1'i etkiler; SAP0 olduğu gibi kalır.
  

  

  Ekran 9: Z1 düzeninde Türkçe sekmeler: Yatırımlar sekmesi kaldırıldı

  Son olarak düzeni sipariş türüne bağlamak gerekir: KOT2_OPA'da Z400'ün Sipariş düzeni alanına Z1 yazdık (Ekran 4'te görünüyor). Sipariş düzeni yalnızca ekranın görünümünü değiştirir; kayıt mantığına ve raporlara etkisi yoktur.
• 3. Numara Aralıkları: SMUH'ye Ait Bir Seri
• Her iç sipariş bir numara alır. Hangi numarayı alacağını numara aralıkları belirler. IMG adımı Siparişlere ilişkin numara alanları bakımı. Ekranda "numara alanı" yazar; günlük dilde numara aralığı dediğimiz şeydir. Siparişlerin numara alanı nesnesi AUFTRAG'dır.
  

  

  Ekran 10: Numara alanı bakımı: AUFTRAG nesnesi

  İki Aralıklar düğmesinden gözlük simgeli olan görüntüler, kalem simgeli olan değiştirir.
  

  

  Ekran 11: AUFTRAG nesnesinin aralıkları

  Listeyi okurken üç şeye bakın. Harici kutusu boşsa numarayı sistem verir (dahili numaralandırma), seçiliyse kullanıcı kendisi girer. Numara drm. sütunu o aralıktan verilmiş son numarayı gösterir; 0 ise aralık hiç kullanılmamıştır. Üçüncüsü: bu aralıklar yalnızca iç siparişlere ait değildir. Üretim siparişleri, proses siparişleri ve ağ planları da aynı nesneden numara alır.
  
  Gruplar: sipariş türü ile aralığın bağlantısı
  Sipariş türleri aralıklara gruplar üzerinden bağlanır. Git ▸ Gruplar ▸ Değiştir yoluyla açılan ekranda her grubun altında o gruba atanmış sipariş türleri listelenir. Z400, 0400'den kopyalandığı için onun grubunda, 08'de duruyor.
  

  

  Ekran 12: Gruplar: Z400, 0400 ile birlikte 08 grubunda

  Grup metnine güvenmeyin
  08 grubunun metninde "300000 – 399999" yazıyor. Oysa Z400'ün ayrıntı ekranında (Ekran 4) ve aralık listesinde 08'in gerçek aralığı 400000 – 499999. Aynı kayma 09'da da var: metinde 400000 – 499999 yazıyor, gerçek aralık 500000 – 599999. Grup metni serbest bir açıklamadır; aralık değişince kendiliğinden güncellenmez. Yalnızca metne bakıp Z400'ü "pazarlama" yazan 09 grubuna taşısaydık, siparişlerimiz üçüncü taraf hizmetleri türüyle aynı seriden numara alacaktı.
  

  

  Ekran 13: Grup seçimi: grup metinleri gerçek aralıklarla uyuşmuyor

  SMUH grubunu yaratmak
  SMUH siparişlerinin numarasından tanınabilmesi için ayrı bir seri açtık. Önce aralık listesinde boş bir blok aradık; 7 milyonluk blok boştu. Grup ekranında Grup yarat ile yeni grubu açıp şu değerleri girdik: grup metni SMUH İç siparişler 7000000-7099999 (dahili), ilk numara 000007000000, son numara 000007099999, Harici kutusu boş. Metne gerçek aralığı yazdık ki az önce eleştirdiğimiz duruma kendimiz düşmeyelim.
  

  

  Ekran 14: SMUH numara aralığı grubu: 7000000–7099999

  Beklenmedik bir durum: grup başka bir adla kaydedildi
  Kaydettikten sonra grup listesinde SMUH adını bulamadık. Sistem yeni aralığa boştaki ilk numarayı, 19'u vermişti. Listede ise 19 numaralı, içi boş bir grup zaten vardı: "Veri devralımı" (Ekran 13'ün son satırı). Aralık bu gruba bağlanmış, grubun eski metni yerinde kalmıştı. Sistem hata da vermedi. Çözüm basit: 19 numaralı grubu açıp metnini düzelttik. Çıkarılacak ders: yeni grup yarattıktan sonra listede hem aralığı hem de metni kontrol edin.
  
  Z400'ü yeni gruba taşımak
  Grup ekranında Z400 satırını seçip Öğe/grup düğmesine bastık, açılan listeden SMUH grubunu seçtik ve kaydettik.
  

  

  Ekran 15: Grup seçiminde SMUH grubu

  

  Ekran 16: Z400 artık SMUH grubunda

• 4. İlk İç Sipariş: KO01 ve Sipariş Durumları
• Uyarlama tamam; şimdi çalıştığını görelim. İç sipariş, uygulama menüsünden yaratılan bir ana veridir: Mali işler ▸ Maliyet muhasebesi ve kontrol ▸ İç siparişler ▸ Ana veriler ▸ Özel işlevler ▸ Sipariş ▸ KO01 – Yarat.
  

  

  Ekran 17: SAP Easy Access: KO01 – Yarat

  Başlangıç ekranında Kontrol Kodu ve sipariş türü girilir. Referans alanına mevcut bir siparişin numarasını yazarsanız yeni sipariş onun verileriyle açılır.
  

  

  Ekran 18: KO01 başlangıç ekranı

  Tayinler
  Siparişe "Yeni İlaç Pazarlama Kampanyası" adını verdik. Ekranda dört sekme var; Yatırımlar sekmesi yok. Z1 düzeni çalışıyor. Bu sekmede siparişin organizasyondaki yeri belirlenir: şirket kodu SMUH, kâr merkezi 10. Nesne sınıfı sipariş türünden hazır geldi. Bu atamalar önemlidir, çünkü siparişe yapılan her kayıt bu bilgileri taşır.
  

  

  Ekran 19: Tayinler sekmesi

  Denetim
  Sistem durumu YRTD (Yaratıldı). Gri görünen Gelir kayıtları ve Açık kalem güncellemesi kutuları sipariş türünden gelir, siparişte değiştirilemez. Para birimi TRY. SMUH'de Kontrol Kodu para birimi USD, şirket kodu para birimi TRY'dir; sipariş kendi para birimini şirket kodundan alır.
  

  

  Ekran 20: Denetim sekmesi: sistem durumu YRTD

  Dönem sonu kapanışı ve Genel veriler
  Dönem sonu sekmesindeki alanları bilerek boş bıraktık. Buradaki Sonuç analizi anahtarı, siparişte biriken masrafın dönem sonunda yarı mamul olarak bilançoya alınmasına yol açar. Bir tanıtım kampanyasının masrafı dönem gideridir; bu alanın dolu olması yanlış sonuç üretir. Maliyet hesaplama şeması da siparişe genel gider payı yüklemek içindir ve SMUH'de böyle bir kurgu yok.
  

  

  Ekran 21: Dönem sonu kapanışı sekmesi: pazarlama siparişinde boş

  Genel veriler sekmesindeki alanlar yalnızca bilgi amaçlıdır: talepte bulunan, departman, başvuru tarihi.
  

  

  Ekran 22: Genel veriler sekmesi

  Kaydettiğimizde sipariş 7000000 numarasını aldı. SMUH grubu ve aralığı çalışıyor.
  

  

  Ekran 23: Sipariş 7000000 numarasıyla yaratıldı

  YRTD durumunda siparişe kayıt yapılabilir mi?
  Yaygın bilgi, onaylanmamış bir siparişe kayıt yapılamayacağıdır. Sistemde denedik ve sonuç farklı çıktı. Hangi durumda hangi işleme izin verildiği BS23 işleminde görülebilir. Yaratıldı durumunun kodu I0001'dir.
  

  

  Ekran 24: BS23: YRTD (I0001) durumunda işlem denetimi

  Klnb. sütunu işlemin serbest, Olnksz. sütunu yasak olduğunu gösterir. YRTD durumunda Ana hesap kaydı (RFBU) serbesttir. Fiili dönemsel transfer, fiili aktivite mahsuplaşması ve fiili genel masraf dağıtımı gibi CO içi işlemler ise yasaktır. Bunu sınamak için YRTD durumundaki 7000000 siparişine FB50 ile bir deneme kaydı girdik; kayıt geçti.
  

  

  Ekran 25: YRTD durumundaki siparişe yapılan deneme kaydı (FB03)

  Yani bu sistemde onay, FI'dan gelen masraf kaydını değil, masraf muhasebesinin kendi içindeki fiili işlemleri açıyor.
  
  Onay
  KO02 ile siparişi açıp Denetim sekmesindeki Onayla düğmesine bastık. Sistem durumu ONAY oldu, düğme bir sonraki adım olan Teknik kapan olarak değişti. Yanındaki aşağı ok bir önceki duruma döndürür.
  

  

  Ekran 26: Onaydan sonra Denetim sekmesi: sistem durumu ONAY

  Onaylandı durumunun kodu I0002'dir. BS23'te aynı satırlara baktığımızda hepsinin serbest olduğunu görüyoruz.
  

  

  Ekran 27: BS23: ONAY (I0002) durumunda işlem denetimi

  İşlem	YRTD	ONAY
  RFBU Ana hesap kaydı	Serbest	Serbest
  RFIG FI not kayıtları	Yasak	Serbest
  RKIB Fiili dönemsel transfer kaydı	Yasak	Serbest
  RKIL Fiili dolaylı aktivite mahsuplaşması	Yasak	Serbest
  RKIU, RKIV Fiili genel masraf dağıtımları	Yasak	Serbest
  RKL Fiili aktivite mahsuplaşması	Yasak	Serbest

  BS23 SAP'nin standart durum tanımlarını gösterir ve üretim, proje gibi bütün nesneleri etkiler. Yalnızca bakın, değişiklik yapmayın.

• [message]
• Sık Yapılan Hatalar
• 1. Grup metnine bakıp atama yapmak. Numara aralığı gruplarının metni gerçek aralığı göstermeyebilir. Atamadan önce aralık listesine bakın.
  2. Yeni grubu kontrol etmeden bırakmak. Sistem yeni aralığa verdiği numara mevcut boş bir grubun numarasıyla aynıysa, aralık o grubun eski metniyle kaydedilir. Kayıttan sonra grup listesinde metni kontrol edin.
  3. Dolu bir aralık seçmek. Mevcut bir aralıkla çakışan değer girerseniz sistem "Örtüşmeyen aralıklar girin" hatası verir. Önce aralık listesinin tamamına bakın.
  4. Örnek değerleri düşünmeden girmek. Bir kaynakta gördüğünüz sonuç analizi anahtarı ya da yatırım profili, sizin siparişinizin amacına uymayabilir. Pazarlama siparişinde ikisi de boş kalmalıdır.
  5. "Onaylanmamış siparişe kayıt yapılamaz" diye varsaymak. Sistemimizde YRTD durumundaki siparişe FI kaydı geçti. Varsaymak yerine BS23'te bakın.

ECC'ye Göre Ne Değişti?

İç siparişlerin uyarlaması ve işlem kodları (KOT2_OPA, KO01, KO02, KO03) ECC ile büyük ölçüde aynıdır. Değişen, verinin nereye yazıldığıdır:

• Sipariş ana verisi ECC'de olduğu gibi AUFK tablosunda tutulur.
• Siparişe yapılan fiili kayıtlar ECC'de CO'nun kendi tablolarına (COEP ve toplam tabloları) yazılırdı. S/4HANA'da tek bir yere, Evrensel Kayıt tablosu ACDOCA'ya yazılır; sipariş numarası kaydın bir alanıdır.
• Kâr merkezi ECC'de ayrı bir deftere aktarılırdı. S/4HANA'da aynı kayıt satırının bir alanıdır; bu yüzden siparişte kâr merkezini doldurmak daha da önemlidir. Kâr merkezinin belge satırlarına nasıl dağıldığını belge ayrıştırma yazısında anlatmıştık.

Özet

SMUH için iç sipariş ana verilerini dört adımda kurduk: OKKP'de sipariş yönetiminin etkin olduğunu doğruladık, 0400'den Z400 sipariş türünü türettik, Z1 sipariş düzeniyle gereksiz Yatırımlar sekmesini kaldırdık ve 7000000 ile başlayan, SMUH'ye ait bir numara serisi açtık. İlk siparişimiz 7000000 numarasıyla yaratıldı ve onaylandı. Bir sonraki adım, bu siparişe bütçe vermek ve bütçe aşımını sistemin nasıl denetlediğini görmek. Devamı: S/4HANA’da İç Sipariş Bütçesi ve Kullanılabilirlik Kontrolü. Masraf muhasebesi serisinin önceki yazısı için: S/4HANA'da Masraf Yeri Raporları ve Report Painter.

Kaynakça

• Stoil Jotev, Configuring SAP S/4HANA Finance, 3. baskı, SAP PRESS, 2025. Bölüm 12.1. Konuyu derinlemesine çalışmak isteyenlere öneririz.
• SMUH sandbox sistemi (SAP S/4HANA 2025) üzerindeki kendi uygulamamız.

SAP ve SAP S/4HANA, SAP SE'nin ticari markalarıdır. Bu yazıdaki ekranlar bir sandbox sistemden alınmıştır, gerçek şirket verisi içermez.