İade ve geri ödeme işleme Veri Şablonunuz
İade ve geri ödeme işleme Veri Şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Çıkarma yönlendirmeleri
İade ve Geri Ödeme İşleme Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | İade ve para iadesi sürecinde gerçekleşen belirli bir iş etkinliğinin veya olayın adıdır. | ||
| Açıklama Bu öznitelik, iade yaşam döngüsündeki tek bir adımı veya aşamayı tanımlar. Etkinlikler, "İade siparişi onaylandı" veya "Ürün incelemesi tamamlandı" gibi yapılan işleri temsil eder. Bunlar, SAP S/4HANA'da kaydedilen durum değişikliklerinden, belge oluşturma işlemlerinden veya belirli kullanıcı eylemlerinden türetilir. Bu etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining'in temelini oluşturur. Süreç haritasını görselleştirmenize, yaygın ve nadir süreç yollarını belirlemenize ve yeniden işleme ya da verimsizliğe işaret eden sık tekrarlanan etkinlikleri tespit etmenize yardımcı olur. Neden önemli? Etkinlikler, süreç haritasının temelini oluşturur ve süreç akışını, darboğazları ve varyasyonları görselleştirip analiz etmenizi sağlar. Nereden alınır? Etkinlik adları genellikle 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ı gibi verilerin bir araya getirilmesiyle türetilir. Örnekler İade talebi başlatıldıÜrünler depoya ulaştıAlacak dekontu oluşturulduPara iadesi işlendi | |||
| İade vakası kimliği ReturnCaseId | Tek bir müşteri iade sürecinin benzersiz tanımlayıcısıdır ve başlatmadan kapatmaya kadar ilgili tüm etkinlikleri birbirine bağlar. | ||
| Açıklama İade Vakası Kimliği, tek bir iade örneğine ait tüm olayları ve etkinlikleri gruplayan birincil tanımlayıcıdır. Her müşteri iade talebine benzersiz bir kimlik atanır. Bu sayede sürecin tamamını uçtan uca izleyebilirsiniz. Process Mining'de bu öznitelik, süreç akışını yeniden oluşturmak için temel niteliktedir. Her bir iadeye ait "İade talebi başlatıldı", "Ürünler teslim alındı" ve "Para iadesi işlendi" gibi farklı olayları tutarlı bir zaman çizelgesinde birleştirerek vaka sürelerini, süreç varyantlarını ve darboğazları analiz etmenizi sağlar. Neden önemli? İadeyi baştan sona izlemek için gereken temel anahtardır. Çevrim süresi ve süreç varyantlarının keşfi dahil olmak üzere vaka düzeyindeki tüm analizleri mümkün kılar. Nereden alınır? Genellikle, belge kategorisinin (VBTYP) iadeyi gösterdiği iade siparişi başlık tablosu VBAK'teki satış belgesi numarasıdır (VBELN). Örnekler 600001896000019060000191 | |||
| Olay zamanı EventTime | Belirli bir etkinliğin gerçekleştiği anı gösteren kesin zaman damgasıdır. | ||
| Açıklama Olay Zamanı, bir iş olayının sisteme kaydedildiği tarih ve saati içerir. Bu zaman damgası, etkinlikleri kronolojik olarak sıralamak ve zamana dayalı tüm analizleri yapmak için gereklidir. Process Mining'de bu öznitelik, etkinlikler arasındaki çevrim sürelerini hesaplamak, her adımın süresini belirlemek ve süreç performansını zaman içinde analiz etmek için kullanılır. Darboğazları keşfetmenin, SLA uyumluluğunu izlemenin ve iade sürecinin zamansal dinamiklerini anlamanın temelini oluşturur. Neden önemli? Bu zaman damgası, olayları sıralamak, tüm süreleri ve çevrim sürelerini hesaplamak ve süreç gecikmelerini belirlemek için gereklidir. Nereden alınır? Genellikle VBAK, LIKP ve BKPF gibi tablolarda belge oluşturma veya durum değişiklikleriyle ilişkili tarih ve saat alanlarından, örneğin ERDAT (Oluşturma Tarihi) ve ERZET (Oluşturma Saati) alanlarından ya da muhasebe belgelerindeki kayıt tarihinden (BUDAT) 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 sistemin tanımlayıcısıdır. | ||
| Açıklama Bu öznitelik, olay verilerinin geldiği kayıt sistemini belirtir. Bu süreç için genellikle SAP S/4HANA örnek kimliğidir. Birden fazla sistemin bulunduğu ortamlarda bu alan, veri soyunu izlemek, sorun gidermek ve veri bütünlüğünü sağlamak için büyük önem taşır. İadelerin farklı ERP örneklerinde işlenmesi veya bir depo yönetim sistemi gibi harici sistemlerle entegre edilmesi durumunda verileri ayırt etmenize yardımcı olur. Neden önemli? Özellikle birden fazla sistemin bulunduğu ortamlarda veri kaynağı ve veri soyu hakkında önemli bağlam sağlar; verilerin izlenebilirliğini ve güvenilirliğini destekler. 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ıdır. | ||
| Açıklama Bu öznitelik, son veri çıkarma veya güncelleme işleminin tarihini ve saatini kaydeder. Analiz edilen veri setinin güncelliği hakkında meta veriler sunar. Process Mining analizinin ne kadar güncel olduğunu anlamak için önemlidir. Kullanıcılar verilerin ne kadar güncel olduğunu görebilir. Bu bilgi, devam eden vakaları izleyen operasyonel takip ve Dashboardlar için özellikle önemlidir. Neden önemli? Verilerin güncelliğini gösterir. Analizlerin ve Dashboardların güncel bilgilere dayanmasını sağlamak için önemlidir. Nereden alınır? Genellikle veri çıkarma sırasında ETL veya veri hattı aracı tarafından veri setine oluşturulup eklenir. Örnekler 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| İade nedeni ReturnReason | Müşterinin ürünü iade etme nedenidir. | ||
| Açıklama Bu öznitelik, müşterinin iade için belirttiği "Kusurlu ürün", "Yanlış beden" veya "Artık ihtiyaç yok" gibi nedeni kaydeder. Genellikle iade başlatma sırasında önceden tanımlanmış neden kodları listesinden 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ği hakkında doğrudan içgörü sağlar ve toplam iade oranını azaltmak için iyileştirme alanlarına öncelik vermenize yardımcı olur. Neden önemli? İadelerin neden gerçekleştiği hakkında önemli içgörüler sağlar. Ürün kalitesi, sipariş karşılama hataları veya müşteri beklentilerindeki boşlukları ele almak için kök neden analizi yapmanıza imkan verir. Nereden alınır? Genellikle iade satış siparişi kalem tablosundaki (VBAP) ABGRU alanında (satış belgeleri için ret nedeni) saklanır. Ö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ğidir. | ||
| Açıklama Bu öznitelik, iade onaylama veya alacak dekontu oluşturma gibi bir görevi tamamlamaktan sorumlu belirli kullanıcıyı ya da sistem aracısını tanımlar. SAP'de bu bilgi genellikle bir belgeyi oluşturan veya değiştiren kullanıcıyı kaydeden alanlarda tutulur. Kullanıcı bazında analiz yapmak, yüksek performans gösteren kişileri veya ekipleri, eğitim ihtiyaçlarını ve iş yükü dağılımını belirlemenize yardımcı olur. Ayrıca sapmaları araştırmak için de gereklidir; süreç eylemlerini belirli kişilere bağlayarak uyumluluk ve denetim çalışmalarını destekler. Neden önemli? Süreç etkinliklerini belirli kullanıcılara bağlar ve 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ığı tablolarında ERNAM (Oluşturan) alanında bulunur. Kullanıcı bilgileri, USR21 kullanıcı ana verisi tablosundan zenginleştirilebilir. Örnekler CBROWNASMITHWF_BATCH | |||
| Müşteri kimliği CustomerId | İadeyi başlatan müşterinin benzersiz tanımlayıcısıdır. | ||
| 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üşteri bazında analiz etmek, olağandışı yüksek iade oranına sahip müşteriler gibi kalıpları belirlemenize yardımcı olur. Bu durum sahte davranışlara veya memnuniyetsizliğe işaret edebilir. Ayrıca iade sürecini müşteri türüne, değerine veya geçmişine göre segmentlere ayırmanızı ve buna göre hizmet seviyeleri belirlemenizi sağlar. Neden önemli? İadeleri belirli müşterilere bağlar; 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 tablosundaki (VBAK) müşteri numarası alanında (KUNNR) bulunur. Örnekler CUST-001234CUST-005678CUST-009012 | |||
| Olay bitiş zamanı EventEndTime | Bir etkinliğin tamamlandığı anı gösteren ve süresini hesaplamak için kullanılan zaman damgasıdır. | ||
| 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; bu, olayın anlık gerçekleştiği anlamına gelir. Ancak "Ürün incelemesi" gibi ölçülebilir süresi olan etkinliklerde bu öznitelik büyük önem taşır. Bu öznitelik, etkinlik işleme süresini doğrudan hesaplamanızı sağlar. Performans analizi için temel niteliktedir ve yalnızca etkinlikler arasındaki boşlukları değil, hangi adımların en fazla zamanı tükettiğini belirlemenize yardımcı olur. Neden önemli? Tek tek etkinliklerin sürelerini kesin biçimde hesaplamanızı sağlar. Belirli süreç adımlarındaki verimsizlikleri tespit etmek için önemlidir. Nereden alınır? Genellikle 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 | |||
| Para iadesi tutarı RefundAmount | Müşteriye yapılan para iadesinin nihai parasal değeridir. | ||
| Açıklama Bu öznitelik, iade süreci tamamlandığında müşteriye gerçekten alacak kaydedilen veya geri ödenen tutarı temsil eder. Bu değer, alacak dekontu gibi finansal belgelerde kaydedilir. Çeşitli analizlerde kullanılan önemli bir finansal metriktir. Talep edilen tutarla karşılaştırma yapmak için Geri Ödeme Tutarı Farkı Analizi Dashboardunda gereklidir. Ayrıca iadeleri değerlerine göre bölümlere ayırarak yüksek değerli iadelerin farklı bir süreç izleyip izlemediğini veya sonuçlanmasının daha uzun sürüp sürmediğini belirlemenizi sağlar. Neden önemli? İadelerin finansal etkisini izler; iade doğruluğunu analiz etmek, yüksek değerli vakaları belirlemek ve toplam maliyetleri anlamak için gereklidir. Nereden alınır? VBRK (Faturalama Belgesi Başlığı) veya BSEG (Muhasebe Belgesi Segmenti) gibi tablolarda bulunan alacak dekontu belgesinin net değer alanından (NETWR) alınır. Örnekler 125.50999.0049.99 | |||
| Ürün kimliği ProductId | İade edilen ürünün benzersiz tanımlayıcısıdır. | ||
| Açıklama Bu öznitelik, iadeye konu olan malzemeyi veya ürünü belirtir. İade sürecini ürün kataloğundaki belirli bir ürüne bağlar. İadeleri ürün bazında analiz etmek, yüksek iade oranına sahip ürünleri belirlemek için temel niteliktedir. Bu oranlar kalite kusurlarına, yetersiz ürün açıklamalarına veya üretim sorunlarına işaret edebilir. Bu veriler, işletmelerin ürün tasarımı, tedarikçi yönetimi ve stok stratejisi hakkında bilinçli kararlar almasına yardımcı olur. Neden önemli? İade sürecini belirli ürünlere bağlar; ürün düzeyindeki iade oranlarını analiz etmenizi ve kalite ya da açıklama sorunlarını belirlemenizi sağlar. Nereden alınır? İade siparişi kalem tablosundaki (VBAP) veya iade teslimatı kalem tablosundaki (LIPS) malzeme numarası alanında (MATNR) bulunur. Örnekler FG-10023HW-45981SW-LICENSE-PREM | |||
| Alacak dekontu numarası CreditMemoNumber | Para iadesini yetkilendiren alacak dekontu belgesinin benzersiz tanımlayıcısıdır. | ||
| Açıklama Alacak dekontu, iade edilen ürünler için müşterinin hesabına resmi olarak alacak kaydeden faturalama 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. Genellikle gerçek para iadesini başlatan önemli bir aşamayı gösterir ve finansal mutabakat ile denetim için gereklidir. Neden önemli? Para iadesine ilişkin resmi finansal işlemi temsil eder. Sürecin son aşamalarını izlemek ve finansal denetim yapmak için gereklidir. Nereden alınır? Belge kategorisinin alacak dekontunu gösterdiği faturalama belgesi başlık tablosundaki (VBRK) faturalama belgesi numarasıdır (VBELN). Örnekler 900003459000034690000347 | |||
| İade politikası kimliği ReturnPolicyId | Bu özel iade vakası için geçerli olan iade politikasının tanımlayıcısıdır. | ||
| Açıklama Bu öznitelik, işleme hangi özel iade politikasının veya kural grubunun uygulandığını gösterir. Politikalar ürün türüne, müşteri segmentine veya satın alma üzerinden 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 kontrol edebilir ve sapmaları analiz için işaretleyebilir. Neden önemli? İş kurallarına göre otomatik uyumluluk kontrolü yapmanızı sağlar ve iadelerin tutarlı biçimde, politikaya uygun olarak işlenmesine yardımcı olur. Nereden alınır? Bu genellikle standart bir SAP alanı değildir ve ü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ımlanan iade politikasına uyup uymadığını gösteren işarettir. | ||
| Açıklama Bu hesaplanmış boolean öznitelik, bir iadenin geçerli iade politikasında belirtilen kriterleri karşılayıp karşılamadığını gösterir. Mantık, örneğin iadenin izin verilen süre içinde başlatılıp başlatılmadığını veya iade nedeninin ürün için geçerli olup olmadığını kontrol edebilir. Bu öznitelik, "İade politikası uyumluluğu genel görünümü" Dashboardını doğrudan destekler. Uyumluluk oranlarını ölçer ve uyumsuz vakaların nedenlerini anlamak için ayrıntıya inmenizi sağlar. Böylece politikaları daha etkili uygulamanıza yardımcı olur. Neden önemli? İş kurallarına uyumluluğu ölçer ve kârlılığı etkileyebilecek ya da süreç istisnaları oluşturabilecek politika ihlallerini belirleyip azaltmanıza yardımcı olur. Nereden alınır? İş kurallarına göre hesaplanır. Örneğin, (İade Başlatma Tarihi - İlk Satın Alma Tarihi) <= [İzin Verilen İade Gün Sayısı]. Bunun için İlk Satın Alma Tarihi ve politika kuralları gerekir. Örnekler truefalse | |||
| İade siparişi durumu ReturnOrderStatus | İade vakasının mevcut genel durumudur. | ||
| Açıklama Bu öznitelik, belirli bir andaki iade vakasının Açık, İşlemde veya Kapalı gibi genel durumunu gösterir. Genellikle tamamlanan son önemli aşamadan türetilen toplu bir durumdur. Mevcut iş yükünü ve vaka dağılımını operasyonel açıdan gösteren Mevcut İade Vaka Durumu Dashboardu için gereklidir. Yöneticilerin sürecin her aşamasında kaç vaka bulunduğunu anlamasına yardımcı olur ve daha iyi kaynak dağılımı ile iş yükü yönetimi sağlar. Neden önemli? Her vakanın süreçte hangi aşamada olduğunu gösteren anlık bir görünüm sunar. 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, ilgili satış siparişindeki (VBUK/VBUP) başlık durumu (GBSTK) veya kalem durumu (LFSTK) ya da teslimat belgelerindeki durum alanları kullanılır. Örnekler Mal Kabulü BekleniyorDenetim BekleniyorGeri Ödeme BekleniyorKapatıldı | |||
| İade SLA Uyumu RefundSlaAdherence | İadenin Hizmet Seviyesi Anlaşması (SLA) hedefi içinde işlenip işlenmediğini gösteren bir işarettir. | ||
| Açıklama Bu hesaplanmış öznitelik, "İade işlendi" etkinliğinin "İade SLA hedef tarihi" tarihinde veya bu tarihten önce gerçekleşip gerçekleşmediğini kontrol eder. Her vaka için SLA uyumluluğunu gösteren basit bir doğru veya yanlış göstergesi sunar. Bu, "İade SLA uyum izleme" Dashboardının ve "İade SLA uyum oranı" KPI’ının temel metriğidir. Müşteri taahhütlerine göre performansı ölçmenize ve beklentileri karşılamayan vakaları belirlemenize yardımcı olur. Böylece gecikmelerin kök nedenlerini analiz edebilirsiniz. Neden önemli? Müşterilere verilen taahhütlere göre performansı doğrudan ölçer. Bu nedenle hizmet kalitesi ve müşteri memnuniyeti için önemli bir göstergedir. Nereden alınır? Her vaka için 'İade İşlendi' etkinliğinin EventTime değeri, 'RefundSlaTargetDate' ile karşılaştırılarak hesaplanır. Örnekler truefalse | |||
| İade teslimatı numarası ReturnDeliveryNumber | İade teslimatı belgesinin benzersiz tanımlayıcısıdır. | ||
| Açıklama Müşteri ürünleri fiziksel olarak iade ettiğinde, gelen lojistiği 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 boyutlarını birbirine bağlayarak mal kabulü ve süreçteki inceleme aşamalarını ayrıntılı biçimde analiz etmenizi sağlar. Neden önemli? İade siparişi ile ürünlerin fiziksel olarak teslim alınması arasında önemli bir bağlantı sağlar. Lojistik ve depo işleme sürelerini analiz etmek için gereklidir. Nereden alınır? Belge kategorisinin iade teslimatını gösterdiği teslimat başlık tablosundaki (LIKP) teslimat belgesi numarasıdır (VBELN). Örnekler 840000128400001384000014 | |||
| İşleme aracısı ProcessingAgent | Manuel bir etkinliği yürütmekten sorumlu belirli aracı veya kaynak grubudur. | ||
| Açıklama Bu öznitelik, belirli bir görevi gerçekleştiren kişiyi veya ekibi tanımlar. Özellikle paylaşımlı hizmet ortamlarında bir role veya ekibe atıfta bulunduğu için Kullanıcı Adından daha ayrıntılı olabilir. Farklı temsilcilerin veya ekiplerin performansını analiz etmek için Geri Ödeme Onay Verimliliği Dashboardunda değerlidir. İş yükü dağılımını anlamanıza, eğitim ihtiyaçlarını belirlemenize ve en iyi performans gösteren kişileri veya paylaşılabilecek iyi uygulamalara sahip ekipleri tanımanıza yardımcı olur. Neden önemli? Aracı veya ekip düzeyinde performans analizi yapmanızı sağlar; iş yükünü yönetmenize, eğitim fırsatlarını belirlemenize ve verimliliği artırmanıza yardımcı olur. Nereden alınır? Aracılar atanmışsa SAP Business Partner işlevleri üzerinden alınabilir veya kullanıcının İK organizasyon yapısındaki departmanı ya da rolünden türetilebilir. Örnekler 1. Kademe DestekDepo Denetim EkibiFinans Departmanı - AP | |||
| Otomatik mi IsAutomated | Bir etkinliğin sistem veya insan tarafından gerçekleştirilip gerçekleştirilmediğini gösteren işarettir. | ||
| Açıklama Bu boolean öznitelik, Workflow veya arka plan işi gibi bir sistem tarafından otomatik yürütülen etkinliklerle kullanıcıların manuel olarak gerçekleştirdiği etkinlikleri birbirinden ayırır. "Otomatik Para İadesi Onay Oranı" KPI'ını hesaplamak ve otomasyonu artırma fırsatlarını belirlemek için gereklidir. İşletmeler, manuel görevleri filtreleyerek hız, maliyet ve doğruluk açısından otomasyonun en fazla faydayı sağlayabileceği alanlara odaklanabilir. Neden önemli? Manuel ve otomatik görevleri birbirinden ayırır. Otomasyon fırsatlarını belirlemek ve dijital dönüşümün etkisini ölçmek için gereklidir. Nereden alınır? Genellikle Kullanıcı Adına göre türetilir. Örneğin kullanıcı "WF_BATCH" veya başka bir sistem kimliğiyse etkinlik otomatik olarak işaretlenir. Örnekler truefalse | |||
| Para iadesi SLA hedef tarihi RefundSlaTargetDate | İade vakasına ilişkin para iadesinin işlenmesi gereken hedef tarihtir. | ||
| Açıklama Bu öznitelik, geri ödemenin işlenmesi için Hizmet Düzeyi Anlaşmasında, yani SLA’da, belirlenen son tarihi tanımlar. Bu tarih genellikle iadenin onaylanmasından veya ürünlerin teslim alınmasından sonra belirli sayıda gün gibi iş kurallarına göre hesaplanır. Bu alan, Geri Ödeme SLA Uyum İzleme Dashboardunun ve ilgili temel performans göstergesinin temelidir. SLA ihlali riski taşıyan vakaları proaktif biçimde izlemenize ve gecikmelerin kök nedenlerini analiz etmenize yardımcı olur. Böylece müşteri memnuniyetini artırabilirsiniz. Neden önemli? SLA uyumluluğunu ölçmek için temel oluşturur; performansı izlemenize, bekleyen vakalara öncelik vermenize ve müşteri memnuniyetini artırmanıza yardımcı olur. Nereden alınır? Neredeyse her zaman türetilmiş bir alandır. Mantık, temel bir tarihe, örneğin iade talebinin oluşturulma tarihine, iş kurallarıyla belirlenen bir sürenin eklenmesine dayanır. Bu süre müşteri türü veya iade nedeni gibi faktörlere bağlı olabilir. Örnekler 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Satış organizasyonu SalesOrganization | İlk satıştan ve iadeden sorumlu organizasyon birimidir. | ||
| Açıklama Satış Organizasyonu, SAP'de ürün ve hizmetlerin satışından ve dağıtımından sorumlu birimi temsil eden önemli bir organizasyon yapısı unsurudur. İade işlemine atanır. Bu öznitelik, iade sürecini farklı iş birimleri, bölgeler veya bölümler arasında filtreleyip karşılaştırmanızı sağlar. Belirli satış organizasyonlarında iade oranlarının daha yüksek veya iade işlemlerinin daha verimsiz olup olmadığını belirlemenize ve organizasyon performansını analiz etmenize yardımcı olur. 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 tablosundaki (VBAK) satış organizasyonu alanında (VKORG) bulunur. Örnekler 10002100US01 | |||
| Talep edilen para iadesi tutarı RequestedRefundAmount | Sürecin başında başlangıçta talep edilen veya beklenen para iadesi tutarıdır. | ||
| Açıklama Bu öznitelik, ilk iade talebine göre iade edilen ürünlerin değerini içerir. Nihai geri ödeme tutarının karşılaştırılacağı temel değeri oluşturur. Bu alan, Geri Ödeme Tutarı Farkı Analizi Dashboardu için özellikle gereklidir. Talep edilen tutarı gerçek geri ödeme tutarıyla karşılaştırarak ürün hasarı, yeniden stoklama ücretleri veya diğer düzeltmeler nedeniyle oluşan kısmi geri ödemeler gibi sorunları belirleyebilir, finansal doğruluğu ve şeffaflığı sağlayabilirsiniz. Neden önemli? İade doğruluğunu ölçmek için temel değer sağlar ve beklenen iade tutarıyla gerçek tutar arasındaki farkları belirleyip analiz etmenize yardımcı olur. Nereden alınır? Genellikle ilk iade satış siparişindeki ürünlerin net değerinden alınır. Bu, VBAP tablosundaki ilgili kalemlerin net değeridir (NETWR). Örnekler 125.501050.0049.99 | |||
| Ürün inceleme sonucu ItemInspectionOutcome | İade edilen ürünün fiziksel incelemesinin sonucudur. | ||
| Açıklama Bu öznitelik, ürünler depoya teslim alındıktan sonra gerçekleştirilen inceleme sürecinin sonucunu kaydeder. Yaygın sonuçlar arasında "Kabul edildi", "Reddedildi - Hasarlı" veya "Kabul edildi - Yeniden satılabilir" bulunur. Bu veri, sonraki süreç adımları için önemli bağlam sağlar. Tam iade, kısmi iade veya hiç iade yapılmamasına karar verilmesini etkiler. Bu sonucu analiz etmek, ret nedenlerini belirlemenize yardımcı olur. Ürünler taşıma sırasında sık sık hasar görüyorsa ürün ambalajı veya kargo iş ortakları hakkında geri bildirim sağlayabilir. Neden önemli? Para iadesinin onaylanması veya reddedilmesinin ardındaki karar sürecini açıklar; ürünün durumu ve iade tutarındaki düzeltmeler hakkında değerli veriler sağlar. Nereden alınır? Bu bilgi, kalite yönetimi modülündeki (QM) inceleme partisinde veya iade teslimatı kalemindeki (LIPS) durum ya da neden kodu olarak kaydedilebilir. Özel bir alanda da bulunabilir. Örnekler Kabul edildi - Yeniden satılabilirKabul edildi - Yenileme bekliyorReddedildi - Müşteri kaynaklı hasarReddedildi - Yanlış ürün iade edildi | |||
| Yeniden İşleme Var IsRework | Bir vakadaki etkinliğin önceki bir etkinliğin tekrarı olup olmadığını gösteren bir işarettir. | ||
| Açıklama Bu hesaplanmış boolean öznitelik, aynı vaka içinde bir etkinliğin birden fazla kez gerçekleştirilmesiyle oluşan yeniden çalışmayı belirler. Örneğin bir ürün incelemesinin tekrarlanması veya bir alacak dekontunun oluşturulup iptal edildikten sonra yeniden oluşturulması bu duruma örnektir. Bu öznitelik, "İade işleme yeniden işleme analizi" Dashboardı ve "İade yeniden işleme oranı" KPI’ı için gereklidir. Hatalara açık olan veya birden fazla deneme gerektiren etkinlikleri görünür kılarak süreç verimsizliğini ölçmenize yardımcı olur. Böylece daha iyi kontroller ya da eğitim gerektiren alanları belirleyebilirsiniz. Neden önemli? Tekrarlanan işleri işaretleyerek süreç verimsizliklerini ve hataları görünür kılar. Böylece israfı ve gecikmeleri azaltmak için hedefli iyileştirmeler yapabilirsiniz. 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 görünüp görünmediğini kontrol eder. Örnekler truefalse | |||
İade ve Geri Ödeme İşleme Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Alacak dekontu oluşturuldu | Bu etkinlik, iade edilen ürün için müşterinin hesabına alacak kaydeden resmi faturalama belgesinin oluşturulmasını gösterir. Alacak dekontu, alacak dekontu talebinden oluşturulduğunda açıkça kaydedilir. | ||
| Neden önemli? Alacak dekontunun oluşturulması önemli bir finansal aşamadır. İade edilecek tutarı doğrular ve ödeme sürecinin başlamasına izin verir. Nereden alınır? Alacak dekontunu belirten belge kategorisine sahip bir faturalama belgesinin VBRK tablosunda oluşturulmasından alınır. Bu belge, VBFA tablosunda alacak dekontu talebine bağlanır. Yakalayın Yeni bir alacak dekontu faturalama belgesi kaydedildiğinde, örneğin VF01 işlemi kullanılarak, olay kaydedilir. Olay türü explicit | |||
| Alacak dekontu talebi oluşturuldu | Başarılı bir incelemenin ardından bu etkinlik, müşteriye alacak dekontu düzenleme talebinin oluşturulmasını gösterir. Bu işlem, özgün iade siparişine referans veren yeni bir satış belgesi, yani alacak dekontu talebi olarak kaydedilir. | ||
| Neden önemli? Bu, iade sürecinin finansal mutabakat aşamasını başlatır. İncelemeden bu adıma kadar geçen süreyi analiz etmek, lojistikten finansa yapılan devrin verimliliğini ortaya koyar. Nereden alınır? Alacak dekontu talebi belge kategorisine sahip bir satış belgesinin VBAK tablosunda oluşturulmasından alınır. İadeyle bağlantı, VBFA belge akışı tablosunda korunur. Yakalayın Yeni bir alacak dekontu talebi belgesi kaydedildiğinde olay kaydedilir. Olay türü explicit | |||
| İade talebi başlatıldı | Bu, sistemde bir iade siparişinin resmî olarak oluşturulduğu iade sürecinin başlangıç noktasıdır. Bu olay, SAP S/4HANA'da iade siparişi türünde yeni bir satış belgesi kaydedildiğinde açıkça yakalanır. | ||
| Neden önemli? Bu faaliyet, iade vakası yaşam döngüsünün resmî başlangıcını gösterir. Bu olaydan kapanışa kadar geçen süreyi analiz etmek, toplam iade çevrim süresini ve müşteri deneyimini ölçmek için önemlidir. Nereden alınır? Bu, VBAK tablosunda bir satış belgesi oluşturulduğunda yakalanan açık bir olaydır. Belge kategorisi (VBAK-VBTYP), belgenin bir iade siparişi olduğunu gösterir. Oluşturma zaman damgası VBAK-ERDAT alanıdır. Yakalayın Olay, yeni bir iade satış siparişi kaydedildiğinde, örneğin VA01 işlemi kullanıldığında kaydedilir. Olay türü explicit | |||
| İade vakası kapatıldı | Bu, iade sürecinin tamamlandığını ve vaka için başka bir işlem beklenmediğini gösteren son etkinliktir. Genellikle iade siparişi belgesi sistemde son, kapalı duruma ulaştığında çıkarılır. | ||
| Neden önemli? Bu olay, süreç yaşam döngüsünün sonunu tanımlar ve uçtan uca toplam çevrim süresinin hesaplanmasını sağlar. Vakanın tamamen çözüldüğünü doğrular. Nereden alınır? VBAK tablosundaki iade siparişinin genel durumunun veya VBAP'teki kalemlerinin "Tamamlandı" ya da "Kapalı" durumuna ulaşması üzerinden çıkarılır. Bu durum, sistemin durum yönetimi yapılandırmasına göre belirlenir. Yakalayın İade siparişi belgesinin durumunun "Tamamlandı" olarak değişmesi üzerinden çıkarılır. Olay türü inferred | |||
| Para iadesi işlendi | Bu etkinlik, finansal alacağın kapatıldığı ve ödemenin müşteriye gönderildiği para iadesi sürecinin son adımını gösterir. Finans modülünde, müşterinin hesabındaki açık alacağı kapatan bir mahsup belgesi oluşturulması üzerinden çıkarılır. | ||
| Neden önemli? Müşteriye ödemenin gerçekten yapıldığı an budur. İadenin başlatılmasından bu adıma kadar geçen süre, müşteri memnuniyetini büyük ölçüde etkiler ve SLA uyumluluğunu ölçmek için önemlidir. Nereden alınır? Finansal muhasebe kalem tablosu BSEG'deki mahsup belgesi bilgilerinden çıkarılır. Alacak dekontuyla ilişkili müşteri kalemindeki mahsup tarihi (BSEG-AUGDT), para iadesinin ne zaman işlendiğini gösterir. Yakalayın Alacak dekontuyla ilişkili muhasebe belgesinin mahsup tarihi alanının doldurulması üzerinden çıkarı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 içinde bu, inceleme sonucunu kaydeden ve geri ödeme veya hurdaya ayırma gibi sonraki işlemi belirleyen açık bir adım olabilir. | ||
| Neden önemli? İncelemenin süresi ve sonucu, geri ödeme işlem süresini ve stok yönetimini doğrudan etkiler. Bu faaliyet, inceleme verimliliğini ve tekrarları analiz etmek için önemlidir. Nereden alınır? SAP Advanced Returns Management (ARM) içinde bu, inceleme işleminden alınan açık bir olay olabilir. Ayrıca inceleme sonucunu gösteren iade siparişi kalemi durumundaki bir değişiklikten de anlaşılabilir. Yakalayın ARM içindeki lojistik takip faaliyetleriyle ilgili işlem günlüklerinden veya durum değişikliklerinden alınır. Olay türü explicit | |||
| Ürünler depoya ulaştı | Bu olay, iade edilen ürünün depoya veya işleme merkezine fiziksel olarak ulaştığını gösterir. İade teslimatına ilişkin Mal Girişi Kaydı (PGR) yürütülüp bir malzeme belgesi oluşturulduğunda açıkça yakalanır. | ||
| Neden önemli? Bu önemli kilometre taşı, inceleme ve nihai karar sürecinin süresini başlatır. Bu noktadan önceki gecikmeler müşteriden kaynaklanırken sonraki gecikmeler iç süreçlerle ilgilidir. Nereden alınır? İadelerle ilişkili mal girişi hareket türü için MSEG ve MKPF malzeme belgesi tablolarından alınır. Kayıt tarihi (MKPF-BUDAT) olay zamanını gösterir. Yakalayın Olay, iade teslimatı için mal girişinin kaydedilmesine karşılık gelir. Olay türü explicit | |||
| Değişim siparişi oluşturuldu | Bu etkinlik, para iadesi yerine müşteriye değişim ürününü göndermek üzere yeni bir satış siparişi oluşturulan alternatif çözümü gösterir. Özgün iadeye referans veren yeni bir satış siparişi oluşturulduğunda kaydedilir. | ||
| Neden önemli? Bu etkinlik, farklı süreç yollarına ve müşteri sonuçlarına sahip para iadeli iadeler ile değişim iadelerini ayırt etmenize yardımcı olur. Varyant analizi için önemlidir. Nereden alınır? İade siparişine VBFA belge akışı tablosunda bağlı olan yeni bir satış belgesinin VBAK tablosunda oluşturulmasından alınır. Yakalayın Değişim ürünü olarak tanımlanan yeni bir satış siparişi belgesi kaydedildiğinde olay kaydedilir. Olay türü explicit | |||
| İade reddedildi | İade edilen ürünün iade politikası kriterlerini karşılamadığını ve geri ödeme veya alacak talebinin reddedildiğini gösterir. Bu durum genellikle incelemeden sonra iade siparişi kalemine belirli bir durum veya neden kodu uygulandığında kaydedilir. | ||
| Neden önemli? Ret retlerini izlemek, iade politikalarına uyumluluğu analiz etmenize ve retlerin yaygın nedenlerini belirlemenize yardımcı olur. Bu, süreçteki önemli istisna yollarından biridir. Nereden alınır? İade siparişi kaleminde bir ret nedeni (VBAP-ABGRU) belirlenmesi veya Advanced Returns Management içindeki inceleme sürecinde belirli bir durumun atanması üzerinden çıkarılır. Yakalayın İade belgesi kaleminde bir ret nedeni ya da belirli bir "reddedildi" durumu belirlenmesi üzerinden çıkarılır. Olay türü inferred | |||
| İade siparişi onaylandı | İade siparişinin resmî olarak onaylandığını veya serbest bırakıldığını ve bir sonraki aşamaya geçebileceğini gösterir. Bu durum genellikle satış belgesi başlığındaki veya kalemindeki durum değişikliğinden anlaşılır ve belgenin tüm bloklardan kaldırıldığını belirtir. | ||
| Neden önemli? Onay adımları önemli bir gecikme kaynağı olabilir. Bu faaliyeti 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 bloğunun kaldırılması (VBAP-LIFSP) onayı gösterebilir. Yakalayın İade siparişinin başlık veya kalem durum alanlarında serbest bırakma ya da onayı gösteren bir değişiklikten anlaşılır. Olay türü inferred | |||
| İade teslimatı oluşturuldu | Bu faaliyet, 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 bunu, iade siparişine referans veren bir teslimat belgesi için açık bir oluşturma olayı olarak kaydeder. | ||
| Neden önemli? Bu adım önemli bir lojistik kilometre taşıdır. İade onayı ile teslimatın oluşturulması arasındaki süre, iade bilgilerinin depoya veya teslim alma departmanına iletilmesindeki verimliliği gösterir. Nereden alınır? LIKP tablosunda bir teslimat başlığının oluşturulmasından alınır ve önceki iade siparişine belge akışı tablosu VBFA üzerinden bağlanır. Yakalayın Olay, yeni bir iade teslimatı belgesi kaydedildiğinde, örneğin VL01N işlemi kullanıldığında kaydedilir. Olay türü explicit | |||
| Muhasebe belgesi oluşturuldu | Bu olay, alacak dekontu finansal muhasebe modülüne başarıyla kaydedildiğinde gerçekleşir. Büyük defterde karşılık gelen kayıtları oluşturur ve alacağı muhasebe açısından resmileştirir. | ||
| Neden önemli? Bu etkinlik, alacağın finansal sisteme aktarıldığını doğrular. Alacak dekontunun oluşturulması ile muhasebe kaydının yapılması arasındaki süre, faturalamadan finansa uzanan arayüzdeki sorunları ortaya çıkarabilir. Nereden alınır? Alacak dekontuna VBRK (VBRK-BELNR) üzerinden bağlı olan BKPF muhasebe tablosundaki belge başlığının oluşturulmasından alınır. Yakalayın Faturalama belgesi Finansal Muhasebeye başarıyla kaydedildiğinde olay kaydedilir. Olay türü explicit | |||
Çıkarma Rehberleri
Adımlar
- Ön koşulları doğrulayın: Çıkarma işlemini gerçekleştiren kullanıcı hesabının, gerekli Core Data Services (CDS) görünümlerine erişmek için SAP S/4HANA üzerinde gerekli yetkilere sahip olduğundan emin olun. Temel 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ı bulunan tercih ettiğiniz SQL istemcisine veya veri entegrasyonu aracına giriş yapın. Bu araç, SAP Analytics Cloud gibi SAP araçlarından biri ya da üçüncü taraf bir ETL platformu olabilir.
- Sorgu parametrelerini ayarlayın: Çalıştırmadan önce sağlanan SQL sorgusunu değiştirin. Yer tutucu değerleri bulun ve bunları ortamınız için doğru parametrelerle değiştirin. Buna
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]ve diğer belge türü ya da şirket kodu filtrelerinin ayarlanması dahildir. - Çıkarma sorgusunu çalıştırın: SQL sorgusunun tamamını kopyalayın ve aracınızda çalıştırın. Sorgu, birden fazla select ifadesinden elde edilen sonuçları 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ği çıkarmaktan sorumludur. Gerekli öznitelikleri toplamak için birden fazla CDS görünümünü 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 inceleyin. Satır sayısının makul olduğunu ve
ReturnCaseId,ActivityNameileEventTimegibi temel sütunların beklendiği şekilde doldurulduğunu kontrol edin. - Veri dönüşümünü gerçekleştirin: Sorgu, düz bir Event Log biçimi oluşturacak şekilde yapılandırılmıştır. Genellikle önemli bir yapısal dönüşüm gerekmez. Ancak hedef sisteminizin gereksinimlerine bağlı olarak zaman damgası biçimlerini veya veri türlerini ayarlamanız gerekebilir.
- Event Logu dışa aktarın: Sorgu sonuç kümesini CSV dosyası olarak dışa aktarın. Özellikle kullanıcı adlarında 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: Ortaya çıkan CSV dosyası artık ProcessMind gibi process mining platformunuza yüklenmeye hazırdır. Dosyadaki sütunları araçtaki karşılık gelen alanlarla eşleyin. Örneğin
ReturnCaseIdalanını Case ID,ActivityNamealanını Activity veEventTimealanını Timestamp ile eşleyin.
Yapılandırma
- Ön koşullar: İşlemi gerçekleştiren kullanıcının satış belgeleri (VBAK), teslimatlar (LIKP), faturalama (VBRK) ve muhasebe (BSEG, BKPF) ile ilgili nesneler için görüntüleme yetkileri olmalıdır. Temel CDS View'larına erişim gereklidir.
- Veri kapsamı filtreleri: İade sürecini izole etmek için sorguyu belirli belge türlerine göre filtrelemek önemlidir. İade siparişi türleri (ör. 'RE'), alacak dekontu talep türleri (ör. 'G2') ve değişim siparişi türleri (ör. 'SO') için yer tutucuları yapılandırı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 bir tarih aralığı filtresi uygulayın. 3 ila 6 aylık yakın bir dönemle başlayın. Sorgu, birincil filtre koşulu olarak ilk iade siparişinin oluşturma tarihini (
I_SalesDocument.CreationDate) kullanır. - Performans değerlendirmeleri: Bu kapsamlı sorgu, birden fazla büyük CDS View'u birleştirir. Çalıştırılması kaynak S/4HANA sistemi için yoğun kaynak kullanımı gerektirebilir. Etkiyi azaltmak için çıkarmayı yoğun olmayan iş saatlerine planlayın. Çok büyük veri setlerinde artımlı yükleme stratejilerini değerlendirin.
a Ö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şiminin bulunduğunu doğrulayın. Kesin şema, görünüm ve alan adları SAP S/4HANA dağıtımına 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.
- Çıkarma kapsamını [Start date], [End date], [Company Code filter] ve [Return document type filter] kullanarak tanımlayın. İlk çıkarma için üç ila altı aylık hareketli bir dönem kullanın. Dönemi yalnızca performans ve eksiksizlik doğrulandıktan sonra genişletin.
- İade siparişi kümesini [Your sales document header table] ve [Your sales document item table] üzerinden belirleyin. Kümeyi [Your return order document type configuration] içinde yapılandırılmış iade siparişi belge türleriyle sınırlandırın. İade siparişi numarasını ve kalem numarasını sonraki belgelere bağlantı sağlayan temel bilgiler olarak koruyun.
- [Your document flow table or view] kullanarak iade siparişlerinden gelen iade teslimatlarına, alacak dekontu taleplerine, değişim siparişlerine ve alacak dekontlarına belge akışını çözümleyin. 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 yapılandırın.
- İlgili belge başlığı ve kalem kayıtlarından açık oluşturma olaylarını çıkarın. Onay, ret, inceleme, kapatma, mal kabulü, muhasebe ve mahsup olaylarını yapılandırılmış durum, inceleme, malzeme belgesi, muhasebe ve mahsup kaynaklarından çıkarın. ProcessMind olayları kendiliğinden çıkaramadığı için her etkinlik ayrı bir olay satırı olarak oluşturulmalıdır.
- 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ış olay zaman damgası önceliğini kullanın. Yalnızca tarih ve saat mevcutsa bunları [Your system time zone] içinde yapılandırılmış sistem saat dilimini kullanarak birleştirin.
- Her olay 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ış iade vaka tanımlayıcısını kullanın. Bir iade vakasına bağlanamayan olayları hariç tutun veya düzeltme için istisna çıktısına aktarın.
- ReturnCaseId, ActivityName, EventTime, SourceSystemId ve LastDataUpdateTimestamp zorunlu sütunlarını doldurun. Kullanılabildiğinde EventEndTime, UserName, ReturnReason, RefundAmount, ProductId ve CustomerId gibi önerilen sütunları da doldurun. Her etkinlik oluşumu için bir satır tutun ve etkinlikleri tek bir vaka satırında toplamayın.
- Sonucu validationSteps içindeki kontrolleri kullanarak doğrulayın. On iki etkinlik adının tamamının bulunduğunu, zaman damgalarının her vaka içinde makul bir sırada olduğunu ve belge referanslarının kaynak tablolarla uyuştuğunu doğrulayın.
- Sonucu UTF-8 CSV veya ProcessMind tarafından desteklenen başka bir tablo biçiminde dışa aktarın. Sütun adlarını tam olarak koruyun, tek bir başlık satırı kullanın, zaman damgalarını belirsizliğe yer bırakmayan ISO biçiminde tutun ve Event Logu ReturnCaseId vaka tanımlayıcısı, ActivityName ise etkinlik sütunu olacak şekilde yükleyin.
Yapılandırma
- Tarih aralığı: Üç ila altı ayla başlayın. [Start date] ve [End date] parametrelerini kullanın. Seçilen dönemden önce başlatılıp bu dönem içinde tamamlanan vakaları yakalayacak kadar geçmiş veriyi dahil edin.
- İade kümesi: [Your return order document type configuration] içinde yapılandırılmış iade siparişi belge türlerine göre filtreleyin. Hedef sistemde doğrulanmadıkça bir belge türünü sabit olarak kodlamayın.
- Organizasyon 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 takip belgelerini dışlamadığını doğrulayın.
- Kaynak nesneleri: [Your table name] ve [Your view name] yer tutucularını onaylanmış SAP S/4HANA tabloları veya CDS View'ları ile değiştirin. VBAK, VBAP, VBRK ve VBRP dağıtımınızda mevcut olabilir, ancak kullanımları ve uzantıları çalıştırmadan önce doğrulanmalıdır.
- Zaman damgası işleme: Her etkinlik için kaynak zaman damgası alanlarını ve saat dilimini yapılandırın. EventTime ve EventEndTime alanlarını tutarlı biçimde, tercihen UTC veya üzerinde anlaşılmış ProcessMind saat diliminde saklayın.
- Durum yorumlama: Sistemde onay, ret, inceleme tamamlanması ve vaka kapanışını temsil eden 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 çıkarma platformunun kullandığı SAP sistem tanımlayıcısı gibi sabit bir değerle değiştirin.
- Yenileme zaman damgası: [Extraction timestamp] değerini sorgu çalışmasının 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 damgaları gerekmedikçe tek bir çıkarma çalışması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 kümesini sınırlandırın. İndeksli 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 somutlaştırın.
- Artımlı çıkarma: Tekrarlanan çalıştırmalarda, geç güncellemeleri yakalamak için [Last successful extraction timestamp] ve kontrollü bir örtüşme aralığı kullanın. ReturnCaseId, ActivityName, kaynak belge anahtarı ve EventTime alanlarını kullanarak yinelenen kayıtları kaldırın.
- Yetkilendirmeler ve ön koşullar: Yapılandırılmış tüm kaynak nesneleri ve alanları için okuma yetkisi, doğrudan veritabanı erişimi için onay ve uygun olduğu durumlarda gerekli SAP bileşenleri ile Advanced Returns Management işlevlerinin etkin olduğuna dair doğrulama alın.
- Veri koruma: Müşteri ve finans alanlarını gereken asgari düzeyle sınırlayın, kurumunuzun gizlilik kontrollerine uyun ve dışa aktarılan dosyaları güvenli biçimde koruyun.
a Ö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 İade ve Geri Ödeme İşleme verilerinizi çıkarmak ve analiz etmek için gereken temel bilgilere sahipsiniz. Süreç mükemmelliğine giden yolculuğunuza bugün başlayın.
SAP S/4HANA'da İade ve Geri Ödeme İşlemenizi Şimdi Optimize Edin
Verimsizlikleri belirleyin, çevrim süresini %30 azaltın ve memnuniyeti artırın.
Kredi kartı gerekmez. Optimizasyona bugün başlayın.