İade ve geri ödeme işlemleri için Veri Templateiniz
İade ve geri ödeme işlemleri için Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma yönergeleri
İade ve geri ödeme işlemleri öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | İade ve geri ödeme sürecinde gerçekleşen belirli bir iş etkinliğinin veya olayın adı. | ||
| Açıklama Bu öznitelik, iade sürecindeki tek bir adımı veya dönüm noktasını tanımlar. Etkinlikler, İade siparişi onaylandı veya Ürün incelemesi tamamlandı gibi yapılan işleri gösterir. SAP S/4HANA’da kaydedilen durum değişikliklerinden, belge oluşturma işlemlerinden veya belirli kullanıcı eylemlerinden elde edilir. Bu etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining çalışmalarının temelini oluşturur. Süreç haritasını görselleştirmeye, yaygın ve nadir süreç yollarını belirlemeye ve yeniden çalışma ya da verimsizliğe işaret eden sık tekrarlanan etkinlikleri bulmaya yardımcı olur. Neden önemli? Etkinlikler süreç haritasının temelini oluşturur; süreç akışını, darboğazları ve farklılıkları görselleştirip analiz etmenizi sağlar. Nereden alınır? Etkinlik adları genellikle çeşitli verilerden elde edilir. Bunlar arasında VBUK/VBUP gibi tablolardaki belge durumu değişiklikleri, VBAK (satış belgeleri) ve BKPF (muhasebe belgeleri) gibi başlık tablolarındaki oluşturma olayları ve MSEG’deki mal hareketi durumları bulunur. Örnekler İade talebi oluşturulduÜrünler depoda teslim alındıAlacak dekontu oluşturulduGeri ödeme işlendi | |||
| İade vaka kimliği ReturnCaseId | Tek bir müşteri iade sürecini tanımlayan ve başlangıçtan kapanışa kadar ilgili tüm etkinlikleri birbirine bağlayan benzersiz kimlik. | ||
| Açıklama İade vaka kimliği, tek bir iade sürecine ait tüm olayları ve etkinlikleri bir araya getiren temel tanımlayıcıdır. Her müşteri iade talebine benzersiz bir kimlik atanır. Bu kimlik, sürecin tamamının uçtan uca izlenmesini sağlar. Process Mining çalışmalarında bu öznitelik, süreç akışını yeniden oluşturmak için temel niteliktedir. İade vakalarının her biri için İade talebi oluşturuldu, Ürünler depoda teslim alındı ve Geri ödeme işlendi gibi farklı olayları tutarlı bir zaman çizelgesinde birleştirerek vaka sürelerinin, süreç varyantlarının ve darboğazların analiz edilmesini sağlar. Neden önemli? İadeyi başlangıçtan sona kadar izlemek için gereken temel anahtardır. Çevrim süresi ve süreç varyantlarının keşfi dâhil, vaka düzeyindeki tüm analizleri mümkün kılar. Nereden alınır? Genellikle VBAK iade siparişi başlık tablosundaki satış belgesi numarasıdır (VBELN). Belge kategorisi (VBTYP), belgenin iade olduğunu gösterir. Örnekler 600001896000019060000191 | |||
| Olay zamanı EventTime | Belirli bir etkinliğin ne zaman gerçekleştiğini gösteren kesin zaman damgası. | ||
| Açıklama Olay zamanı, bir iş olayının sistemde kaydedildiği tarih ve saati gösterir. Etkinlikleri kronolojik sıraya koymak ve zamana dayalı tüm analizleri yapmak için bu zaman damgası gereklidir. Process Mining çalışmalarında bu öznitelik, etkinlikler arasındaki çevrim sürelerini hesaplamak, her adımın ne kadar sürdüğünü belirlemek ve süreç performansını zaman içinde analiz etmek için kullanılır. Darboğazları keşfetmenin, SLA uyumunu izlemenin ve iade sürecinin zaman içindeki işleyişini anlamanın temelini oluşturur. Neden önemli? Olayları sıralamak, süreleri ve çevrim zamanlarını hesaplamak, süreçteki gecikmeleri belirlemek için bu zaman damgası gereklidir. Nereden alınır? Genellikle VBAK, LIKP ve BKPF gibi tablolardaki ERDAT (Oluşturma tarihi) ve ERZET (Oluşturma saati) alanları veya muhasebe belgelerindeki kayıt tarihi (BUDAT) gibi belge oluşturma ya da durum değişikliğiyle ilişkili tarih ve saat alanlarından alınır. Örnekler 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Kaynak sistem kimliği SourceSystemId | Verilerin çıkarıldığı kaynak sistemi tanımlayan kimlik. | ||
| Açıklama Bu öznitelik, olay verilerinin hangi kayıt sisteminden geldiğini belirtir. Bu süreçte genellikle SAP S/4HANA örneğinin kimliğidir. Birden fazla sistemin kullanıldığı ortamlarda bu alan, veri kökenini izlemek, sorunları gidermek ve veri bütünlüğünü sağlamak için önemlidir. İadeler farklı ERP örneklerinde işleniyorsa veya depo yönetim sistemi gibi harici sistemlerle entegre ediliyorsa verileri birbirinden ayırmaya yardımcı olur. Neden önemli? Özellikle birden fazla sistemin kullanıldığı ortamlarda verinin kaynağını ve izlenebilirliğini göstererek verilerin izlenmesini ve güvenilirliğini sağlar. Nereden alınır? Bu değer genellikle sabittir ve veri çıkarma sırasında yapılandırılır. Sistem kimliği (SID) gibi SAP sisteminin yönetim bilgilerinden alınabilir. Örnekler S4H_PROD_100S4Q_DEV_200 | |||
| Son veri güncellemesi LastDataUpdateTimestamp | Bu olaya ait verilerin en son yenilendiği veya çıkarıldığı zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, verilerin en son çıkarıldığı veya güncellendiği tarih ve saati kaydeder. Analiz edilen veri setinin güncelliği hakkında bilgi verir. Process Mining analizinin ne kadar güncel olduğunu anlamak için önemlidir. Kullanıcılar verilerin ne zaman güncellendiğini görebilir. Bu bilgi, özellikle devam eden vakaları izleyen operasyonel takip ve Dashboardlar için önem taşır. Neden önemli? Verilerin güncelliğini gösterir. Analizlerin ve Dashboardların güncel bilgilere dayanmasını sağlamak için bu önemlidir. Nereden alınır? Bu değer genellikle ETL veya veri hattı aracı tarafından veri çıkarma sırasında oluşturulur ve veri setine zaman damgası olarak eklenir. Örnekler 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Geri ödeme tutarı RefundAmount | Müşteriye yapılan geri ödemenin kesin tutarı. | ||
| Açıklama Bu öznitelik, iade süreci tamamlandığında müşteriye alacak kaydedilen veya geri ödenen gerçek tutarı gösterir. Bu değer, alacak dekontu gibi finansal belgelerde kaydedilir. Çeşitli analizlerde kullanılan önemli bir finansal metriktir. Geri ödeme tutarı farkı analizi Dashboardunda talep edilen tutarla karşılaştırma yapmak için gereklidir. Ayrıca iadeleri tutara göre gruplandırarak yüksek tutarlı iadelerin farklı bir süreç izleyip izlemediğini veya daha uzun sürede sonuçlanıp sonuçlanmadığını belirlemeyi sağlar. Neden önemli? İadelerin finansal etkisini izler; geri ödeme doğruluğunu analiz etmek, yüksek tutarlı vakaları belirlemek ve toplam maliyetleri anlamak için gereklidir. Nereden alınır? Alacak dekontu belgesindeki net değer alanından (NETWR) alınır. Bu alan VBRK (Fatura belgesi başlığı) veya BSEG (Muhasebe belgesi kalemi) gibi tablolarda bulunur. Örnekler 125.50999.0049.99 | |||
| İade nedeni ReturnReason | Müşterinin ürünü iade etmek için belirttiği neden. | ||
| Açıklama Bu öznitelik, müşterinin iade için belirttiği nedeni kaydeder. Örneğin ürün kusurlu olabilir, bedeni yanlış olabilir veya müşteri artık ürüne ihtiyaç duymuyor olabilir. İade talebi oluşturulurken genellikle önceden tanımlanmış neden kodlarından biri seçilir. İade nedenlerini analiz etmek; ürün kalitesi sorunlarını belirlemek, ürün açıklamalarını iyileştirmek veya satış süreçlerini geliştirmek için önemlidir. Müşteri memnuniyetsizliğini doğrudan gösterir ve toplam iade oranını düşürmek için iyileştirme alanlarına öncelik vermeye yardımcı olur. Neden önemli? İadelerin neden gerçekleştiğini göstererek ürün kalitesi, sipariş karşılama hataları veya müşteri beklentileri arasındaki farklarla ilgili temel neden analizini mümkün kılar. Nereden alınır? Genellikle iade satış siparişi kalem tablosu VBAP’te, satış belgelerinin ret nedeni olan ABGRU alanında tutulur. Örnekler 001 - Düşük kalite002 - Taşıma sırasında hasar gördü005 - Yanlış ürün gönderildi | |||
| Kullanıcı adı UserName | Etkinliği gerçekleştiren çalışanın kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, iade onayı verme veya alacak dekontu oluşturma gibi bir görevi tamamlamaktan sorumlu kullanıcıyı ya da sistem aracısını tanımlar. SAP’de bu bilgi genellikle belgeyi oluşturan veya değiştiren kullanıcıyı kaydeden alanlarda tutulur. Kullanıcıya göre yapılan analizler, yüksek performans gösteren kişileri veya ekipleri, eğitim ihtiyaçlarını ve iş yükü dağılımını belirlemeye yardımcı olur. Ayrıca sapmaları incelerken süreç eylemlerini belirli kişilerle ilişkilendirerek uyumluluk ve denetim çalışmalarını destekler. Neden önemli? Süreç etkinliklerini belirli kullanıcılarla ilişkilendirerek ekip performansını, iş yükünü ve uyumluluğu analiz etmenizi sağlar. Nereden alınır? Genellikle VBAK (Satış siparişleri), LIKP (Teslimatlar) ve BKPF (Muhasebe belgeleri) gibi belge başlık tablolarında ERNAM (Oluşturan) alanında bulunur. Kullanıcı ana verisi tablosu USR21’den kullanıcı bilgileri eklenebilir. Örnekler CBROWNASMITHWF_BATCH | |||
| Müşteri kimliği CustomerId | İade talebini oluşturan müşteriyi tanımlayan benzersiz kimlik. | ||
| Açıklama Bu öznitelik, iade talebinde bulunan müşteriyi tanımlar. Süreç örneğini müşteri ana verilerindeki belirli bir tarafla ilişkilendirir. İadeleri müşteriye göre analiz etmek, olağan dışı yüksek iade oranına sahip müşteriler gibi örüntüleri belirlemeye yardımcı olur. Bu durum dolandırıcılık şüphesine veya memnuniyetsizliğe işaret edebilir. Ayrıca müşteri türüne, değerine veya geçmişine göre iade sürecini gruplandırarak farklı hizmet düzeyleri sunmayı sağlar. Neden önemli? İadeleri belirli müşterilerle ilişkilendirerek müşteri davranışını ve segmentleri analiz etmenizi, sık iade yapan müşterileri belirlemenizi sağlar. Nereden alınır? İade siparişi başlık tablosu VBAK’teki müşteri numarası alanında (KUNNR) bulunur. Örnekler CUST-001234CUST-005678CUST-009012 | |||
| Olay bitiş zamanı EventEndTime | Bir etkinliğin tamamlandığı zamanı gösteren ve süresini hesaplamak için kullanılan zaman damgası. | ||
| Açıklama StartTime (EventTime) bir etkinliğin başlangıcını, EventEndTime ise bitişini gösterir. Sistem tarafından oluşturulan birçok olayda başlangıç ve bitiş zamanları aynıdır; çünkü olay anlık gerçekleşir. Ancak Ürün incelemesi gibi ölçülebilir süresi olan etkinliklerde bu öznitelik önemlidir. Bu öznitelik, etkinliğin işlem süresini doğrudan hesaplamanızı sağlar. Performans analizinin temelini oluşturur ve yalnızca etkinlikler arasındaki bekleme sürelerini değil, hangi adımların en çok zaman aldığını da belirlemeye yardımcı olur. Neden önemli? Tek tek etkinliklerin süresini kesin olarak hesaplamanızı sağlar. Belirli süreç adımlarındaki verimsizlikleri saptamak için önemlidir. Nereden alınır? Bu değer çoğu zaman türetilir. Bazı etkinlikler için ayrı bir alan olabilir. Daha yaygın olarak, vakadaki sonraki etkinliğin StartTime değeridir. Örnekler 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Ürün kimliği ProductId | İade edilen ürünü tanımlayan benzersiz kimlik. | ||
| Açıklama Bu öznitelik, iade edilen malzemeyi veya ürünü belirtir. İade sürecini ürün kataloğundaki belirli bir ürünle ilişkilendirir. Ürün bazında iadeleri analiz etmek, iade oranı yüksek ürünleri belirlemek için önemlidir. Yüksek oranlar kalite kusurlarına, yetersiz ürün açıklamalarına veya üretim sorunlarına işaret edebilir. Bu veriler, ürün tasarımı, tedarikçi yönetimi ve stok stratejisi hakkında bilinçli kararlar alınmasına yardımcı olur. Neden önemli? İade sürecini belirli ürünlerle ilişkilendirerek ürün bazındaki iade oranlarını analiz etmenizi ve kalite ya da ürün açıklaması sorunlarını belirlemenizi sağlar. Nereden alınır? İade siparişi kalem tablosu VBAP’te veya iade teslimatı kalem tablosu LIPS’te bulunan malzeme numarası alanında (MATNR) yer alır. Örnekler FG-10023HW-45981SW-LICENSE-PREM | |||
| Alacak dekontu numarası CreditMemoNumber | Geri ödemeye izin veren alacak dekontu belgesini tanımlayan benzersiz numara. | ||
| Açıklama Alacak dekontu, iade edilen ürünler için müşterinin hesabına resmî olarak alacak kaydeden fatura belgesidir. Bu öznitelik, söz konusu finansal belgenin benzersiz numarasıdır. Alacak dekontu numarasını izlemek, iade sürecinin finansal mutabakat aşamasını analiz etmek için gereklidir. Bu numara, çoğu zaman gerçek geri ödeme ödemesini başlatan önemli bir dönüm noktasını gösterir; finansal mutabakat ve denetim için de gereklidir. Neden önemli? Geri ödemenin resmî finansal işlemini gösterir. Sürecin son aşamalarını izlemek ve finansal denetim yapmak için önemlidir. Nereden alınır? VBRK fatura belgesi başlık tablosundaki fatura belgesi numarasıdır (VBELN). Belge kategorisi, bunun bir alacak dekontu olduğunu gösterir. Örnekler 900003459000034690000347 | |||
| Geri ödeme SLA hedef tarihi RefundSlaTargetDate | İade vakasına ait geri ödemenin tamamlanması gereken hedef tarih. | ||
| Açıklama Bu öznitelik, geri ödemenin işlenmesi için geçerli Hizmet Seviyesi Anlaşması (SLA) son tarihini belirtir. Bu tarih genellikle iş kurallarına göre hesaplanır; örneğin iadenin onaylanmasından veya ürünlerin teslim alınmasından sonraki belirli bir gün sayısı esas alınabilir. Bu alan, Geri ödeme SLA uyumluluğu izleme Dashboardunun ve ilgili KPI’ın temelini oluşturur. SLA süresini aşma riski taşıyan vakaların önceden izlenmesini ve gecikmelerin temel nedenlerinin analiz edilmesini sağlar. Böylece müşteri memnuniyetinin artırılmasına yardımcı olur. Neden önemli? SLA uyumluluğunu ölçmek için temel oluşturur; performansı izlemeye, bekleyen eski vakalara öncelik vermeye ve müşteri memnuniyetini artırmaya yardımcı olur. Nereden alınır? Bu alan neredeyse her zaman türetilir. Hesaplama, iade talebinin oluşturulma tarihi gibi bir başlangıç tarihine iş kurallarında belirlenen sürenin eklenmesine dayanır. Süre, müşteri türü veya iade nedeni gibi etkenlere göre değişebilir. Örnekler 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Geri ödeme SLA uyumluluğu RefundSlaAdherence | Geri ödemenin Hizmet Seviyesi Anlaşması (SLA) hedef süresi içinde işlenip işlenmediğini gösteren işaret. | ||
| Açıklama Bu hesaplanan öznitelik, Geri ödeme işlendi etkinliğinin Geri ödeme SLA hedef tarihinde veya bu tarihten önce gerçekleşip gerçekleşmediğini denetler. Her vaka için SLA uyumluluğunu doğru veya yanlış olarak gösterir. Geri ödeme SLA uyumluluğu izleme Dashboardunun ve Geri ödeme SLA uyumluluk oranı KPI’ının temel metriğidir. Müşterilere verilen taahhütlere göre performansı ölçmeye ve beklentilerin karşılanmadığı vakaları belirlemeye yardımcı olur. Böylece gecikmelerin temel nedenleri analiz edilebilir. Neden önemli? Müşterilere verilen taahhütlere göre performansı doğrudan ölçer; hizmet kalitesi ve müşteri memnuniyeti için önemli bir göstergedir. Nereden alınır? Her vaka için Geri ödeme işlendi etkinliğinin EventTime değeri, RefundSlaTargetDate ile karşılaştırılarak hesaplanır. Örnekler truefalse | |||
| İade politikası kimliği ReturnPolicyId | Bu iade işlemi için geçerli olan iade politikasının tanımlayıcısı. | ||
| Açıklama Bu öznitelik, işlem için hangi iade politikasının veya kural kümesinin geçerli olduğunu gösterir. Politikalar ürün türüne, müşteri segmentine veya satın alma tarihinden bu yana geçen süreye göre değişebilir. Bu veri, İade politikası uyumluluğu genel görünümü için gereklidir. Sistem, her vakayı bir politikayla ilişkilendirerek iade süresi veya ürünün durumu gibi kurallara uyulup uyulmadığını otomatik olarak denetleyebilir ve analiz için sapmaları işaretleyebilir. Neden önemli? İş kurallarına göre uyumluluğun otomatik olarak denetlenmesini sağlar; iadelerin tutarlı biçimde ve politikaya uygun işlenmesine yardımcı olur. Nereden alınır? Bu alan genellikle standart bir SAP alanı değildir. Ürün türü, müşteri ve satış tarihi gibi veriler kullanılarak iş mantığına göre türetilmesi gerekebilir. Uygulanmışsa özel bir alanda saklanabilir. Örnekler STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| İade politikasına uyum ReturnPolicyAdherence | İade vakasının tanımlı iade politikasına uyup uymadığını gösteren işaret. | ||
| Açıklama Bu hesaplanan mantıksal öznitelik, iadenin geçerli iade politikasındaki ölçütleri karşılayıp karşılamadığını gösterir. Örneğin, iade talebinin izin verilen süre içinde oluşturulup oluşturulmadığı veya iade nedeninin ürün için geçerli olup olmadığı denetlenebilir. Bu öznitelik, İade politikası uyumluluğu genel görünümü Dashboardunu doğrudan destekler. Uyumluluk oranlarını ölçer ve kurallara uymayan vakaların ayrıntılarına inerek sapmaların nedenlerini anlamayı sağlar. Böylece politikaların daha etkili uygulanmasına yardımcı olur. Neden önemli? İş kurallarına uyumu ölçer; kârlılığı etkileyebilecek veya süreçte istisnalara yol açabilecek politika ihlallerini belirlemeye ve azaltmaya yardımcı olur. Nereden alınır? İş kurallarına göre hesaplanır. Örneğin: (İade başlatma tarihi - ilk satın alma tarihi) <= [İzin verilen iade günü sayısı]. Bunun için ilk satın alma tarihi ve politika kuralları gerekir. Örnekler truefalse | |||
| İade siparişi durumu ReturnOrderStatus | İade vakasının mevcut genel durumu. | ||
| Açıklama Bu öznitelik, iade vakasının herhangi bir andaki genel durumunu Açık, İşlemde veya Kapalı gibi değerlerle gösterir. Bu durum genellikle tamamlanan son önemli aşamadan türetilir. Mevcut iade vakası durumu Dashboardu için gereklidir. Bu Dashboard, mevcut iş yükünü ve vakaların dağılımını gösterir. Yöneticilerin sürecin her aşamasında kaç vaka bulunduğunu anlamasına, kaynakları ve iş yükünü daha iyi yönetmesine yardımcı olur. Neden önemli? Her vakanın süreçte hangi aşamada olduğunu gösterir. Mevcut iş yükünü ve durumu izleyen operasyonel Dashboardlar için gereklidir. Nereden alınır? İlgili belgelerdeki durum alanlarından türetilir. Örneğin, ilişkili satış siparişi (VBUK/VBUP) veya teslimat belgelerindeki başlık durumu (GBSTK) ya da kalem durumu (LFSTK) kullanılabilir. Örnekler Ürünlerin teslim alınması bekleniyorİnceleme bekleniyorGeri ödeme bekleniyorKapalı | |||
| İade teslimat numarası ReturnDeliveryNumber | İade teslimat belgesini tanımlayan benzersiz numara. | ||
| Açıklama Müşteri ürünleri fiziksel olarak iade ettiğinde, giriş lojistiğini yönetmek için SAP’de bir iade teslimat belgesi oluşturulur. Bu öznitelik, söz konusu belgenin benzersiz numarasıdır. Bu kimlik, iade edilen ürünlerin fiziksel hareketini izlemek için önemlidir. İadenin finansal ve lojistik yönlerini birbirine bağlayarak süreçteki mal kabul ve inceleme aşamalarının ayrıntılı analizini sağlar. Neden önemli? İade siparişiyle ürünlerin fiziksel olarak teslim alınması arasında önemli bir bağlantı kurar. Lojistik ve depodaki işlem sürelerini analiz etmek için gereklidir. Nereden alınır? LIKP teslimat başlık tablosundaki teslimat belgesi numarasıdır (VBELN). Belge kategorisi, bunun bir iade teslimatı olduğunu gösterir. Örnekler 840000128400001384000014 | |||
| İşlem sorumlusu ProcessingAgent | Elle gerçekleştirilen bir etkinliği yürütmekten sorumlu belirli kişi veya kaynak grubu. | ||
| Açıklama Bu öznitelik, belirli bir görevi yerine getiren kişiyi veya ekibi tanımlar. Özellikle paylaşımlı hizmet ortamlarında bir role ya da ekibe işaret ederek Kullanıcı adı alanından daha ayrıntılı bilgi verebilir. Farklı kişilerin veya ekiplerin performansını analiz etmek için Geri ödeme onay verimliliği Dashboardunda kullanılır. İş yükünün nasıl dağıldığını anlamaya, eğitim ihtiyaçlarını belirlemeye ve iyi uygulamalarını paylaşabilecek başarılı çalışanları veya ekipleri öne çıkarmaya yardımcı olur. Neden önemli? Kişi veya ekip düzeyinde performans analizi yapılmasını sağlar; iş yükünü yönetmeye, eğitim fırsatlarını belirlemeye ve verimliliği artırmaya yardımcı olur. Nereden alınır? Kişilere sorumluluk atandıysa bu bilgi SAP Business Partner işlevlerinde bulunabilir. Kullanıcının İK organizasyon yapısındaki departmanından veya rolünden de türetilebilir. Örnekler 1. seviye destekDepo denetim ekibiFinans departmanı - borçlar muhasebesi | |||
| Otomatik mi IsAutomated | Bir etkinliğin sistem tarafından mı yoksa bir kişi tarafından mı gerçekleştirildiğini gösteren işaret. | ||
| Açıklama Bu mantıksal öznitelik, iş akışı veya arka plan işi gibi sistemlerin otomatik olarak yürüttüğü etkinliklerle kullanıcıların elle gerçekleştirdiği etkinlikleri birbirinden ayırır. Otomatik geri ödeme onay oranı KPI’ını hesaplamak ve otomasyonu artırma fırsatlarını belirlemek için gereklidir. İşletmeler, elle gerçekleştirilen görevleri filtreleyerek otomasyonun hız, maliyet ve doğruluk açısından en fazla fayda sağlayacağı alanlara odaklanabilir. Neden önemli? Elle gerçekleştirilen ve otomatik görevleri birbirinden ayırır. Otomasyon fırsatlarını belirlemek ve dijital dönüşümün etkisini ölçmek için önemlidir. Nereden alınır? Bu değer genellikle Kullanıcı adı alanından türetilir. Örneğin kullanıcı WF_BATCH veya başka bir sistem kimliğiyse etkinlik otomatik olarak işaretlenir. Örnekler truefalse | |||
| Satış organizasyonu SalesOrganization | İlk satıştan ve iadeden sorumlu kuruluş birimi. | ||
| Açıklama Satış organizasyonu, SAP’de ürün ve hizmetlerin satışından ve dağıtımından sorumlu birimi temsil eden temel bir kuruluş yapısı öğesidir. İade işlemine atanır. Bu öznitelik, farklı iş birimleri, bölgeler veya bölümler arasındaki iade süreçlerini filtreleyip karşılaştırmanızı sağlar. Belirli satış organizasyonlarının daha yüksek iade oranlarına veya daha verimsiz iade süreçlerine sahip olup olmadığını belirlemeye yardımcı olur ve kuruluş performansını analiz etmek için temel oluşturur. Neden önemli? Farklı iş birimleri, bölgeler veya satış kanalları arasındaki iade süreci performansını ve oranlarını karşılaştırmanızı sağlar. Nereden alınır? İade siparişi başlık tablosu VBAK’teki satış organizasyonu alanında (VKORG) bulunur. Örnekler 10002100US01 | |||
| Talep edilen geri ödeme tutarı RequestedRefundAmount | Sürecin başlangıcında talep edilen veya beklenen geri ödeme tutarı. | ||
| Açıklama Bu öznitelik, ilk iade talebinde belirtilen iade edilecek ürünlerin değerini kaydeder. Son geri ödeme tutarını karşılaştırmak için başlangıç değeri olarak kullanılır. Bu alan, geri ödeme tutarı farkı analizi Dashboardu için gereklidir. Talep edilen tutarı gerçek geri ödeme tutarıyla karşılaştırmak; ürün hasarı, yeniden stoklama ücretleri veya başka düzeltmeler nedeniyle yapılan kısmi geri ödemeler gibi sorunları belirlemeye, finansal doğruluğu ve şeffaflığı sağlamaya yardımcı olur. Neden önemli? Geri ödeme tutarlarının doğruluğunu ölçmek için temel oluşturur; beklenen ve gerçekleşen tutarlar arasındaki farkları belirleyip analiz etmeye yardımcı olur. Nereden alınır? Genellikle ilk iade satış siparişindeki kalemlerin net değerinden alınır. Bu değer, VBAP tablosundaki ilgili kalemlerin net değeri (NETWR) olur. Örnekler 125.501050.0049.99 | |||
| Ürün inceleme sonucu ItemInspectionOutcome | İade edilen ürünün fiziksel incelemesinin sonucu. | ||
| Açıklama Bu öznitelik, ürünler depoya ulaştıktan sonra yapılan incelemenin sonucunu kaydeder. Yaygın sonuçlar arasında Kabul edildi - yeniden satılabilir, Reddedildi - hasarlı veya Kabul edildi - yenilenmesi gerekiyor bulunur. Bu veri, sonraki süreç adımlarını anlamak için önemli bir bağlam sağlar. Tam, kısmi veya hiç geri ödeme yapılmayacağını belirler. Sonuçların analizi, iadelerin reddedilme nedenlerini ortaya çıkarır. Ürünler taşıma sırasında sık sık hasar görüyorsa ambalaj veya nakliye iş ortakları hakkında geri bildirim sağlayabilir. Neden önemli? Geri ödeme onaylarının veya retlerinin ardındaki karar sürecini açıklar; ürünün durumu ve geri ödeme tutarındaki değişikliklerin nedenleri hakkında değerli veri sağlar. Nereden alınır? Bu bilgi, kalite yönetimi modülündeki (QM) inceleme partisinde ya da iade teslimatının kalemindeki (LIPS) durum veya neden kodu olarak kaydedilebilir. Özel bir alanda da bulunabilir. Örnekler Kabul edildi - yeniden satılabilirKabul edildi - yenilenmesi gerekiyorReddedildi - müşteri kaynaklı hasarReddedildi - yanlış ürün iade edildi | |||
| Yeniden çalışma mı IsRework | Bir vakadaki etkinliğin önceki bir etkinliğin tekrarı olup olmadığını gösteren işaret. | ||
| Açıklama Bu hesaplanan mantıksal öznitelik, aynı vaka içinde bir etkinliğin birden fazla kez gerçekleştirildiği yeniden çalışma durumlarını belirler. Örneğin, ürün incelemesinin tekrarlanması veya bir alacak dekontunun oluşturulup iptal edildikten sonra yeniden oluşturulması. Bu öznitelik, Geri ödeme işlemlerinde yeniden çalışma analizi Dashboardu ve Geri ödeme yeniden çalışma oranı KPI’ı için gereklidir. Hatalara açık veya birden fazla deneme gerektiren etkinlikleri göstererek süreç verimsizliğini ölçer. Daha iyi kontrollerin veya eğitimin gerektiği alanları belirlemeye yardımcı olur. Neden önemli? Tekrarlanan işleri işaretleyerek süreçteki verimsizlikleri ve hataları ortaya çıkarır; israfı ve gecikmeleri azaltmaya yönelik iyileştirmeleri hedeflemeyi sağlar. Nereden alınır? Bu işaret genellikle Process Mining aracı tarafından hesaplanır veya veri dönüşümü sırasında önceden hesaplanabilir. Aynı etkinlik adının aynı vakada daha önce yer alıp almadığını denetler. Örnekler truefalse | |||
İade ve geri ödeme işlemleri etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Alacak dekontu oluşturuldu | Bu, iade edilen ürün için müşterinin hesabına alacak kaydeden resmî fatura belgesinin oluşturulmasıdır. Alacak dekontu talebinden alacak dekontu oluşturulduğunda bu olay açıkça kaydedilir. | ||
| Neden önemli? Alacak dekontunun oluşturulması, finansal süreçte önemli bir dönüm noktasıdır. İade edilecek tutarı kesinleştirir ve ödeme sürecinin başlamasına izin verir. Nereden alınır? VBRK tablosunda belge kategorisi alacak dekontu olduğunu gösteren bir fatura belgesi oluşturulduğunda kaydedilir. Bu belge, VBFA tablosunda alacak dekontu talebiyle ilişkilendirilir. Kaydedin Yeni bir alacak dekontu fatura belgesi kaydedildiğinde olay kaydedilir (ör. VF01 işlemiyle). Olay türü explicit | |||
| Alacak dekontu talebi oluşturuldu | Başarılı bir incelemenin ardından bu etkinlik, müşteriye alacak kaydı oluşturma talebinin hazırlanmasını gösterir. Bu işlem, ilk iade siparişine referans veren yeni bir satış belgesi, yani alacak dekontu talebi oluşturularak kaydedilir. | ||
| Neden önemli? Bu adım, iade sürecinin finansal mutabakat aşamasını başlatır. İnceleme ile bu adım arasında geçen süreyi analiz etmek, lojistikten finansa devir teslimin verimliliğini gösterir. Nereden alınır? VBAK tablosunda Alacak Dekontu Talebi belge kategorisiyle bir satış belgesi oluşturulduğunda kaydedilir. İade bağlantısı, VBFA belge akış tablosunda tutulur. Kaydedin Yeni bir alacak dekontu talebi belgesi kaydedildiğinde olay kaydedilir. Olay türü explicit | |||
| Geri ödeme işlendi | Bu etkinlik, geri ödeme sürecinin son adımını gösterir. Finansal alacak kapatılır ve ödemenin müşteriye gönderildiği anlaşılır. Finans modülünde, müşterinin hesabındaki açık alacağı kapatan bir mahsup belgesi oluşturulmasından çıkarılır. | ||
| Neden önemli? Müşteriye ödemenin gerçekten yapıldığı an budur. İade talebinin başlatılmasından bu adıma kadar geçen süre, müşteri memnuniyetini önemli ölçüde etkiler ve SLA uyumunu ölçmek için temel bir göstergedir. Nereden alınır? Finans muhasebesi kalem tablosu BSEG’deki mahsup belgesi bilgilerinden anlaşılır. Alacak dekontuyla ilişkili müşteri kalemindeki mahsup tarihi (BSEG-AUGDT), geri ödemenin ne zaman işlendiğini gösterir. Kaydedin Alacak dekontuyla ilişkili muhasebe belgesinin mahsup tarihi alanının doldurulmasından anlaşılır. Olay türü inferred | |||
| İade talebi oluşturuldu | İade sürecinin başlangıç noktasıdır. Bu aşamada sistemde resmî bir iade siparişi oluşturulur. SAP S/4HANA’da iade siparişi türünde yeni bir satış belgesi kaydedildiğinde bu olay açıkça kaydedilir. | ||
| Neden önemli? Bu etkinlik, iade vakasının resmen başladığını gösterir. Toplam iade çevrim süresini ve müşteri deneyimini ölçmek için bu olaydan kapanışa kadar geçen süreyi analiz etmek önemlidir. Nereden alınır? Bu olay, VBAK tablosunda bir satış belgesi oluşturulduğunda açıkça kaydedilir. Belge kategorisi (VBAK-VBTYP), belgenin iade siparişi olduğunu gösterir. Oluşturulma zaman damgası VBAK-ERDAT alanında tutulur. Kaydedin Yeni bir iade satış siparişi kaydedildiğinde olay kaydedilir (ör. VA01 işlemiyle). Olay türü explicit | |||
| İade vakası kapatıldı | Bu son etkinlik, iade sürecinin tamamlandığını ve vakayla ilgili başka bir işlem beklenmediğini gösterir. Genellikle iade siparişi belgesi sistemde son, yani kapalı durumuna ulaştığında anlaşılır. | ||
| Neden önemli? Bu olay, süreç yaşam döngüsünün sonunu belirler ve toplam uçtan uca çevrim süresinin hesaplanmasını sağlar. Vakanın tamamen sonuçlandığını doğrular. Nereden alınır? VBAK tablosundaki iade siparişinin genel durumu veya VBAP tablosundaki kalemlerinin durumu Tamamlandı ya da Kapalı olduğunda anlaşılır. Bu durum, sistemin durum yönetimi yapılandırmasına göre belirlenir. Kaydedin İade siparişi belgesinin durumu Tamamlandı olarak değiştiğinde anlaşılır. Olay türü inferred | |||
| Ürün incelemesi tamamlandı | İade edilen ürünlerin kalite ve durum değerlendirmesinin tamamlandığını gösterir. Advanced Returns Management kapsamında bu adım genellikle inceleme sonucunu kaydeder ve geri ödeme ya da hurdaya ayırma gibi sonraki işlemi belirler. | ||
| Neden önemli? İncelemenin süresi ve sonucu, geri ödeme işlem süresini ve stok yönetimini doğrudan etkiler. Bu etkinlik, inceleme verimliliğini ve yeniden çalışmayı analiz etmek için önemlidir. Nereden alınır? SAP Advanced Returns Management (ARM) kapsamında inceleme işleminden açık bir olay olarak alınabilir. İnceleme sonucunu gösteren iade siparişi kalem durumu değişikliğinden de anlaşılabilir. Kaydedin ARM’de lojistik takip etkinlikleriyle ilgili işlem günlüklerinden veya durum değişikliklerinden alınır. Olay türü explicit | |||
| Ürünler depoda teslim alındı | Bu olay, iade edilen ürünün depoda veya işleme merkezinde fiziksel olarak teslim alınmasını gösterir. İade teslimatı için Mal Girişi Kaydı (PGR) yapıldığında ve bir malzeme belgesi oluşturulduğunda açıkça kaydedilir. | ||
| Neden önemli? Bu önemli dönüm noktası, inceleme ve değerlendirme süresinin başlangıcını belirler. Bu aşamadan önceki gecikmeler müşteriden, sonraki gecikmeler ise kurum içi süreçlerden kaynaklanır. Nereden alınır? İadelerle ilişkili mal girişi hareket türüne ait MSEG ve MKPF malzeme belgesi tablolarından alınır. Kayıt tarihi (MKPF-BUDAT), olay zamanını gösterir. Kaydedin Olay, iade teslimatı için mal girişi kaydedildiğinde oluşur. Olay türü explicit | |||
| Değişim siparişi oluşturuldu | Bu etkinlik, geri ödeme yerine müşteriye yedek ürün göndermek için yeni bir satış siparişi oluşturulan alternatif çözümü gösterir. İlk iadeye referans veren yeni bir satış siparişi oluşturulduğunda kaydedilir. | ||
| Neden önemli? Bu etkinlik, geri ödeme için yapılan iadelerle ürün değişimi için yapılan iadeleri birbirinden ayırmaya yardımcı olur. Bu iadelerin süreç akışları ve müşteri sonuçları farklıdır. Varyant analizinde önemli bir rol oynar. Nereden alınır? VBAK tablosunda oluşturulan ve belge akış tablosu VBFA üzerinden iade siparişiyle ilişkilendirilen yeni bir satış belgesinden alınır. Kaydedin Yedek ürün olarak belirlenen yeni bir satış siparişi belgesi kaydedildiğinde olay kaydedilir. Olay türü explicit | |||
| İade reddedildi | İade edilen ürünün iade politikası koşullarını karşılamadığını ve geri ödeme ya da alacak talebinin reddedildiğini gösterir. Genellikle incelemenin ardından iade siparişi kalemine belirli bir durum veya neden kodu atanmasıyla kaydedilir. | ||
| Neden önemli? Retleri izlemek, iade politikalarına uyumu analiz etmeye ve yaygın ret nedenlerini belirlemeye yardımcı olur. Bu, süreçteki önemli bir istisna yoludur. Nereden alınır? İade siparişi kalemine ret nedeni (VBAP-ABGRU) girilmesinden veya Advanced Returns Management inceleme sürecinde belirli bir durum atanmasından anlaşılır. Kaydedin İade belgesi kalemine ret nedeni girilmesinden veya belirli bir ret durumu atanmasından anlaşılır. Olay türü inferred | |||
| İade siparişi onaylandı | İade siparişinin resmen onaylandığını veya serbest bırakıldığını ve sonraki aşamaya geçebileceğini gösterir. Genellikle satış belgesinin başlık ya da kalem durumundaki değişiklikten anlaşılır; bu değişiklik, belgedeki blokların kaldırıldığını gösterir. | ||
| Neden önemli? Onay adımları önemli gecikmelere yol açabilir. Bu etkinliği izlemek, iade sürecinin ilk yetkilendirme aşamasındaki darboğazları belirlemeye yardımcı olur. Nereden alınır? Durum yönetimi tablolarından veya doğrudan VBAK ya da VBAP tablolarındaki durum alanlarından anlaşılır. Serbest bırakma durumundaki değişiklik veya teslimat blokajının (VBAP-LIFSP) kaldırılması onayı gösterebilir. Kaydedin İade siparişinin başlık ya da kalem durum alanlarında serbest bırakıldığını veya onaylandığını gösteren değişiklikten anlaşılır. Olay türü inferred | |||
| İade teslimatı oluşturuldu | Bu etkinlik, iade edilen ürünlerin fiziksel teslim alınmasını yönetmek için kullanılan bir giriş teslimat belgesinin oluşturulduğunu gösterir. Sistem, iade siparişine referans veren teslimat belgesi oluşturulduğunda bu olayı açıkça kaydeder. | ||
| Neden önemli? Bu adım, lojistik süreçte önemli bir dönüm noktasıdır. İade onayı ile teslimatın oluşturulması arasında geçen süre, iade bilgilerinin depoya veya teslim alma birimine ne kadar verimli iletildiğini gösterir. Nereden alınır? LIKP tablosunda bir teslimat başlığı oluşturulduğunda kaydedilir. Belge akış tablosu VBFA üzerinden önceki iade siparişiyle ilişkilendirilir. Kaydedin Yeni bir iade teslimat belgesi kaydedildiğinde olay kaydedilir (ör. VL01N işlemiyle). Olay türü explicit | |||
| Muhasebe belgesi oluşturuldu | Bu olay, alacak dekontu finans muhasebesi modülüne başarıyla kaydedildiğinde gerçekleşir. Büyük defterde ilgili kayıtları oluşturur ve alacağı muhasebe açısından resmîleştirir. | ||
| Neden önemli? Bu etkinlik, alacağın finans sistemine işlendiğini doğrular. Alacak dekontunun oluşturulmasıyla muhasebe kaydı arasındaki süre, faturalama ve finans sistemleri arasındaki arayüz sorunlarını ortaya çıkarabilir. Nereden alınır? BKPF muhasebe tablosunda bir belge başlığı oluşturulduğunda kaydedilir. Bu başlık, VBRK tablosundaki alacak dekontuyla (VBRK-BELNR) ilişkilendirilir. Kaydedin Fatura belgesi Finans Muhasebesine başarıyla kaydedildiğinde olay kaydedilir. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşulları doğrulayın: Veri çıkarma işlemini yürütecek kullanıcı hesabının, gerekli Core Data Services (CDS) View’larına erişmek için SAP S/4HANA’da gereken yetkilere sahip olduğundan emin olun. Önemli görünümler arasında I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry ve I_ClearedItem bulunur.
- Sorgu aracına erişin: SAP S/4HANA veritabanına bağlantısı olan tercih ettiğiniz SQL istemcisinde veya veri entegrasyonu aracında oturum açın. Bu araç, SAP Analytics Cloud gibi SAP araçlarından biri ya da üçüncü taraf bir ETL platformu olabilir.
- Sorgu parametrelerini ayarlayın: Sorguyu çalıştırmadan önce verilen SQL sorgusunu düzenleyin. Yer tutucu değerleri bulun ve ortamınıza uygun değerlerle değiştirin.
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]alanlarını ve diğer belge türü ya da şirket kodu filtrelerini ayarlayın. - Veri çıkarma sorgusunu çalıştırın: SQL sorgusunun tamamını kopyalayıp aracınızda çalıştırın. Sorgu, birden fazla SELECT ifadesinin sonuçlarını birleştirerek belirtilen tüm etkinlikleri tek bir veri setinde toplar.
- Sorgu mantığını anlayın:
UNION ALLyapısındaki herSELECTbloğu belirli bir etkinliğin verilerini çıkarır. Gerekli öznitelikleri toplamak için birden fazla CDS View’u birleştirir,ActivityNamealanına sabit bir metin atar veEventTimeiçin ilgili zaman damgasını seçer. - Ham verileri inceleyin: Sorgu tamamlandıktan sonra çıktıyı kısaca gözden geçirin. Satır sayısının makul olup olmadığını ve
ReturnCaseId,ActivityNameveEventTimegibi temel sütunların beklendiği gibi doldurulduğunu kontrol edin. - Veri dönüşümü: Sorgu, düz bir olay günlüğü biçiminde çıktı üretir. Genellikle önemli bir yapısal dönüşüm gerekmez. Ancak hedef sisteminizin gereksinimlerine göre zaman damgası biçimlerini veya veri türlerini ayarlamanız gerekebilir.
- Olay günlüğünü dışa aktarın: Sorgu sonuçlarını CSV dosyası olarak dışa aktarın. Özellikle kullanıcı adları veya ürün açıklamalarında karakter sorunlarını önlemek için dosyanın UTF-8 kodlamasını kullandığından emin olun.
- Process Mining aracına yükleyin: Oluşturulan CSV dosyası artık ProcessMind gibi Process Mining platformunuza yüklenmeye hazırdır. Dosyadaki sütunları araçtaki ilgili alanlarla eşleyin. Örneğin,
ReturnCaseIdalanını Vaka kimliğiyle,ActivityNamealanını Aktiviteyle veEventTimealanını zaman damgasıyla eşleyin.
Yapılandırma
- Ön koşullar: İşlemi yürüten kullanıcının satış belgeleri (VBAK), teslimatlar (LIKP), faturalama (VBRK) ve muhasebe (BSEG, BKPF) nesneleri için görüntüleme yetkisi olmalıdır. Temel CDS View’larına erişim de gereklidir.
- Veri kapsamı filtreleri: İade sürecini ayrı olarak incelemek için sorguyu belirli belge türlerine göre filtreleyin. İade siparişi türleri (ör. 'RE'), alacak dekontu talebi türleri (ör. 'G2') ve değişim siparişi türleri (ör. 'SO') için yer tutucuları ayarlayın. Veri kapsamını sınırlamak için
CompanyCodeveyaSalesOrganizationalanına göre filtreleme de önerilir. - Tarih aralığı filtresi: Performansı ve veri hacmini yönetmek için her zaman tarih aralığı filtresi uygulayın. Önce son 3 ila 6 aylık verilerle başlayın. Sorgu, temel filtre koşulu olarak ilk iade siparişinin oluşturulma tarihini (
I_SalesDocument.CreationDate) kullanır. - Performansla ilgili noktalar: Bu kapsamlı sorgu, büyük boyutlu birden fazla CDS View’u birleştirir. Kaynak S/4HANA sisteminde çalıştırılması yoğun kaynak kullanabilir. Etkiyi en aza indirmek için veri çıkarmayı iş yoğunluğunun düşük olduğu saatlerde planlayın. Çok büyük veri setlerinde artımlı yükleme yöntemlerini değerlendirin.
Örnek sorgu sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Adımlar
- İlgili satış, teslimat, faturalama, malzeme belgesi, inceleme, durum ve muhasebe verilerini içeren SAP HANA şemasına doğrudan okuma erişiminiz olduğunu doğrulayın. Şema, görünüm ve alan adları SAP S/4HANA kurulumuna göre değişir. Bu nedenle köşeli parantez içindeki her yer tutucuyu sisteminizde yapılandırılmış nesne ve alanlarla değiştirin.
- Veri çıkarma kapsamını [Start date], [End date], [Company Code filter] ve [Return document type filter] değerleriyle belirleyin. İlk veri çıkarma işleminde üç ila altı aylık bir dönem kullanın. Dönemi ancak performansı ve veri bütünlüğünü doğruladıktan sonra genişletin.
- İade siparişlerini [Your sales document header table] ve [Your sales document item table] tablolarından belirleyin. Kapsamı, [Your return order document type configuration] içinde tanımlı iade siparişi belge türleriyle sınırlayın. Sonraki belgelere bağlantı kurmak için iade siparişi numarasını ve kalem numarasını koruyun.
- [Your document flow table or view] üzerinden iade siparişlerinden gelen iade teslimatlarına, alacak dekontu taleplerine, değişim siparişlerine ve alacak dekontlarına belge akışını izleyin. Belge akışının VBAK veya VBAP içinde tutulduğunu varsaymayın. İlişki alanlarını sistemde kullanılan belge akışı modeline göre ayarlayın.
- İlgili belge başlığı ve kalem kayıtlarından açık oluşturma etkinliklerini çıkarın. Onay, ret, inceleme, kapatma, mal kabulü, muhasebe ve mahsuplaşma etkinliklerini yapılandırılmış durum, inceleme, malzeme belgesi, muhasebe ve mahsuplaşma kaynaklarından çıkarın. ProcessMind etkinlikleri kendiliğinden belirlemediği için her etkinliği ayrı bir olay satırı olarak kaydedin.
- Zaman damgalarını tutarlı bir veritabanı zaman damgası türüne ve saat dilimine dönüştürün. Her etkinlik için yapılandırılmış zaman damgası önceliğini kullanın. Yalnızca tarih ve saat bilgisi varsa bunları [Your system time zone] içinde yapılandırılmış sistem saat dilimini kullanarak birleştirin.
- Her etkinlik için ReturnCaseId alanını doldurun. Kaynak iade siparişi numarasını veya Advanced Returns Management ayrı bir vaka anahtarı tutuyorsa yapılandırılmış vaka kimliğini kullanın. Bir iade vakasıyla ilişkilendirilemeyen etkinlikleri hariç tutun veya düzeltme için ayrı bir istisna çıktısına ekleyin.
- ReturnCaseId, ActivityName, EventTime, SourceSystemId ve LastDataUpdateTimestamp zorunlu sütunlarını doldurun. Varsa EventEndTime, UserName, ReturnReason, RefundAmount, ProductId ve CustomerId gibi önerilen sütunları da ekleyin. Her etkinlik oluşumu için bir satır tutun, etkinlikleri tek bir vaka satırında toplamayın.
- Sonucu validationSteps içindeki kontrollerle doğrulayın. On iki etkinlik adının tümünün bulunduğunu, her vakadaki zaman damgalarının makul bir sırada olduğunu ve belge referanslarının kaynak tablolarla eşleştiğini kontrol edin.
- Sonucu UTF-8 kodlamalı CSV veya ProcessMind’in desteklediği başka bir tablo biçiminde dışa aktarın. Sütun adlarını aynen koruyun, tek bir başlık satırı kullanın, zaman damgalarını açık ve belirsizliğe yer bırakmayan ISO biçiminde tutun. Olay günlüğünü yüklerken vaka tanımlayıcısı olarak ReturnCaseId, etkinlik sütunu olarak ActivityName alanını ayarlayın.
Yapılandırma
- Tarih aralığı: Önce üç ila altı aylık bir dönemle başlayın. [Start date] ve [End date] parametrelerini kullanın. Seçilen dönemden önce açılıp dönem içinde tamamlanan vakaları da kapsayacak kadar geçmiş veri ekleyin.
- İade kapsamı: [Your return order document type configuration] içinde tanımlı iade siparişi belge türlerine göre filtreleyin. Hedef sistemde doğrulamadan belge türünü sabit bir değere bağlamayın.
- Kuruluş filtreleri: [Company Code filter], satış organizasyonu, dağıtım kanalı, bölüm, tesis veya müşteri filtrelerini yalnızca gerektiğinde uygulayın. Filtrelerin şirketler arası veya şirket içi devam belgelerini kapsam dışında bırakmadığını doğrulayın.
- Kaynak nesneler: [Your table name] ve [Your view name] yer tutucularını onaylanmış SAP S/4HANA tabloları veya CDS View’larıyla değiştirin. Kurulumda VBAK, VBAP, VBRK ve VBRP kullanılabilir; ancak çalıştırmadan önce kullanımlarını ve uzantılarını doğrulayın.
- Zaman damgalarını işleme: Her etkinlik için kaynak zaman damgası alanlarını ve saat dilimini ayarlayın. EventTime ve EventEndTime değerlerini tutarlı biçimde, tercihen UTC veya üzerinde anlaşılmış ProcessMind saat diliminde saklayın.
- Durumları yorumlama: Sistemde onay, ret, incelemenin tamamlanması ve vakanın kapanması anlamına gelen kesin durum değerlerini, neden kodlarını, inceleme sonuçlarını ve kapatma göstergelerini yapılandırın.
- Kaynak sistem tanımlayıcısı: [Source system identifier] değerini, veri çıkarma platformunun kullandığı SAP sistem tanımlayıcısı gibi sabit bir değerle değiştirin.
- Yenileme zaman damgası: [Extraction timestamp] değerini sorgunun başladığı veya kaynak anlık görüntüsünün oluşturulduğu zaman damgasıyla değiştirin. Satır düzeyinde yenileme zaman damgası gerekmiyorsa tek bir veri çıkarma çalıştırmasındaki tüm satırlarda aynı değeri kullanın.
- Performans: Büyük belge akışı, muhasebe, malzeme belgesi ve durum kaynaklarını birleştirmeden önce ilk iade siparişi kapsamını daraltın. Dizinli veya bölüm budamayı destekleyen alanları kullanın, sınırsız taramalardan kaçının ve ara sonuçları yalnızca veritabanı yöneticisi onayladığında kalıcı hale getirin.
- Artımlı veri çıkarma: Düzenli çalıştırmalarda geç gelen güncellemeleri yakalamak için [Last successful extraction timestamp] değerini ve kontrollü bir örtüşme aralığını kullanın. ReturnCaseId, ActivityName, kaynak belge anahtarı ve EventTime alanlarına göre yinelenen kayıtları ayıklayın.
- Yetkiler ve ön koşullar: Yapılandırılmış tüm kaynak nesne ve alanları için okuma yetkisi alın, doğrudan veritabanı erişimi için onay alın ve gerektiğinde gerekli SAP bileşenlerinin ve Advanced Returns Management işlevlerinin etkin olduğunu doğrulayın.
- Veri koruma: Müşteri ve finans alanlarını gereken en düşük düzeyle sınırlayın, kuruluşunuzun gizlilik kontrollerine uyun ve dışa aktarılan dosyaları güvenli biçimde saklayın.
Örnek sorgu sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; Başlamaya hazır mısınız?
Bu Template ile iade ve geri ödeme işlemleri verilerinizi çıkarmak ve analiz etmek için gereken temel bilgilere sahip olursunuz. Süreçlerinizi bugün iyileştirmeye başlayın.
SAP S/4HANA’da iade ve geri ödeme işlemlerini şimdi iyileştirin
Verimsizlikleri belirleyin, çevrim süresini %30 azaltın ve memnuniyeti artırın.
Kredi kartı gerekmez. İyileştirmeye bugün başlayın.