İade ve Geri Ödeme Süreci Veri Template'i
İade ve Geri Ödeme Süreci Veri Template'i
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Veri Çekim Kılavuzu
İade ve Geri Ödeme Süreçleri Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite Adı ActivityName | İade ve geri ödeme süreci içinde meydana gelen belirli bir iş aktivitesinin veya olayının adı. | ||
| Açıklama Bu nitelik, iade süreç döngüsündeki tek bir adımı veya kilometre taşını tanımlar. Aktiviteler, 'İade Siparişi Onaylandı' veya 'Ürün İncelemesi Tamamlandı' gibi yapılan işi temsil eder. Bunlar, SAP S/4HANA'da kaydedilen durum değişikliklerinden, belge oluşturmadan veya belirli kullanıcı eylemlerinden türetilir. Bu aktivitelerin sırasını ve sıklığını analiz etmek, Process Mining'in özüdür. Süreç haritasını görselleştirmeye, yaygın ve nadir süreç yollarını belirlemeye ve sıkça tekrarlanan, yeniden işleme veya verimsizlikleri gösteren aktiviteleri tespit etmeye yardımcı olur. Neden Önemli?dir? Aktiviteler, süreç haritasının omurgasını oluşturarak süreç akışının, darboğazların ve varyasyonların görselleştirilmesini ve analizini sunar. Nereden Alınır?? Aktivite adları tipik olarak, VBUK/VBUP gibi tablolardaki belge durum 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 birleşiminden türetilir. Örnekler::::::: İade Talebi BaşlatıldıMallar Depoya Kabul EdildiAlacak Dekontu Oluşturulduİade İşlendi | |||
| İade Vaka ID'si ReturnCaseId | Tek bir müşteri iade süreci için benzersiz tanımlayıcı; başlatmadan kapanışa kadar tüm ilgili aktiviteleri birbirine bağlar. | ||
| Açıklama İade Vaka Kimliği, tek bir iade örneğine ait tüm olayları ve aktiviteleri gruplayan birincil tanımlayıcı olarak olarak kullanılır. Her müşteri iade talebine benzersiz bir kimlik atanır ve bu, tüm sürecin uçtan uca takibini sunar. Process Mining'de bu nitelik, süreç akışını yeniden yapılandırmak için büyük önem taşır. 'İade Talebi Başlatıldı', 'Ürünler Teslim Alındı' ve 'Geri Ödeme İşlendi' gibi farklı olayları her özel iade için tutarlı bir zaman çizelgesine bağlayarak vaka sürelerinin, süreç varyantlarının ve darboğazların analizini sunar. Neden Önemli?dir? Bu, bir iadeyi baştan sona takip etmek için temel büyük önem taşır; döngü süresi ve süreç varyantı keşfi dahil tüm vaka düzeyindeki analizleri sunar. Nereden Alınır?? Bu, genellikle iade siparişi başlığı tablosundaki VBAK'tan, belge kategorisinin (VBTYP) bir iadeyi gösterdiği satış belgesi numarasıdır (VBELN). Örnekler::::::: 600001896000019060000191 | |||
| Olay Zamanı EventTime | Belirli bir aktivitenin ne zaman gerçekleştiğini gösteren kesin zaman damgası (zaman damgası)dır. | ||
| Açıklama Event Time, bir iş olayının sisteme kaydedildiği tarihi ve saati yakalar. Bu zaman damgası (zaman damgası), aktiviteleri kronolojik olarak sıralamak ve tüm zamana dayalı analizler için büyük önem taşır. Proses madenciliğinde bu öznitelik, aktiviteler arasındaki döngü sürelerini hesaplamak, her adımın süresini belirlemek ve zaman içindeki süreç performansını analiz etmek için kullanılır. Darboğazları keşfetmek, SLA uyumunu izlemek ve iade sürecinin zamansal dinamiklerini anlamak için temel oluşturur. Neden Önemli?dir? Bu zaman damgası (zaman damgası), olayları sıralamak, tüm süreleri ve döngü sürelerini hesaplamak ve süreç gecikmelerini belirlemek için büyük önem taşır. Nereden Alınır?? Genellikle belge oluşturma veya durum değişiklikleriyle ilişkili tarih ve saat alanlarından alınır; VBAK, LIKP ve BKPF gibi tablolardaki ERDAT (Oluşturma Tarihi) ve ERZET (Oluşturma Saati) veya muhasebe belgelerindeki kayıt tarihi (BUDAT) gibi. Örnekler::::::: 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Kaynak Sistem Kimliği SourceSystemId | Verinin çekildiği kaynak sistemi tanımlayıcısı. | ||
| Açıklama Bu nitelik, olay verilerinin kaynaklandığı kayıt sistemini belirtir. Bu süreç için tipik olarak SAP S/4HANA örnek kimliği olacaktır. Çoklu sistem ortamlarında, bu alan veri soyu, sorun giderme ve veri bütünlüğünü güçlüak için büyük önem taşır. İadeler farklı ERP örnekleri arasında işleniyorsa veya bir depo yönetim sistemi gibi harici sistemlerle entegre ediliyorsa verileri ayırt etmeye yardımcı olur. Neden Önemli?dir? Veri kaynağı ve soyu için çok önemli bir bağlam sunar; özellikle çoklu sistem ortamlarında veri izlenebilirliği ve güvenini temin eder. Nereden Alınır?? Bu değer genellikle statiktir ve veri çekme sırasında yapılandırılır. SAP sisteminin Sistem Kimliği (SID) gibi idari bilgilerinden alınabilir. Örnekler::::::: S4H_PROD_100S4Q_DEV_200 | |||
| Son Veri Güncellemesi LastDataUpdateTimestamp | Bu olaya ilişkin verilerin en son ne zaman yenilendiğini veya çıkarıldığını gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Bu nitelik, son veri çekme veya güncellemenin tarih ve saatini kaydeder. Analiz edilen veri kümesinin güncelliği hakkında meta veri sunar. Process Mining analizinin güncelliğini anlamak için önemlidir. Kullanıcılar verilerin ne kadar güncel olduğunu görebilir, bu özellikle operasyonel izleme ve devam eden vakaları takip eden kontrol paneli'lar için önemlidir. Neden Önemli?dir? Verilerin güncelliğini gösterir; bu, analizlerin ve Nereden Alınır?? Bu, genellikle ETL veya veri boru hattı aracı tarafından veri çekme sırasında veri kümesine oluşturulur ve damgalanır. Örnekler::::::: 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Geri Ödeme Tutarı RefundAmount | Müşteriye yapılan geri ödemenin nihai parasal değeri. | ||
| Açıklama Bu nitelik, iade sürecinin tamamlanmasının ardından müşteriye gerçekten alacaklandırılan veya geri ödenen tutarı temsil eder. Bu değer, kredi notları gibi finansal belgelerde kaydedilir. Bu, çeşitli analizlerde kullanılan anahtar bir finansal metriktir. Talep edilen tutarla karşılaştırmak için 'Geri Ödeme Tutarı Fark Analizi' kontrol paneli'u için büyük önem taşır. Ayrıca, yüksek değerli iadelerin farklı bir süreci takip edip etmediğini veya çözülmesinin daha uzun sürüp sürmediğini belirlemek için iadeleri değere göre segmentlere ayırmaya sunar. Neden Önemli?dir? İadelerin finansal etkisini takip eder ve geri ödeme doğruluğunu analiz etmek, yüksek değerli vakaları belirlemek ve genel maliyetleri anlamak için büyük önem taşır. Nereden Alınır?? Kredi notu belgesinin net değer alanından (NETWR) alınmıştır; VBRK (Fatura Belgesi Başlığı) veya BSEG (Muhasebe Belgesi Segmenti) 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 nitelik, müşterinin 'Kusurlu Ürün', 'Yanlış Beden' veya 'Artık İhtiyaç Duyulmuyor' gibi iade için belirttiği nedeni yakalar. Bu genellikle iade başlatma süreci sırasında önceden tanımlanmış bir 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 iyileştirmek için büyük önem taşır. Müşteri memnuniyetsizliğine doğrudan bir önemli bilgi sunar ve genel iade oranını azaltmak için iş iyileştirme alanlarını önceliklendirmeye yardımcı olur. Neden Önemli?dir? İadelerin neden gerçekleştiğine dair kritik bilgiler sunarak, ürün kalitesi, sipariş karşılama hataları veya müşteri beklentisi boşluklarını gidermek için kök neden analizini sunar. Nereden Alınır?? Genellikle iade satış siparişi kalem tablosunda (VBAP) ABGRU (Satış belgelerinin reddedilme nedeni) alanında saklanır. Örnekler::::::: 001 - Düşük Kalite002 - Taşıma Sırasında Hasar Görmüş005 - Yanlış Ürün Gönderildi | |||
| Kullanıcı Adı UserName | Aktiviteyi yürüten çalışanın kullanıcı kimliği. | ||
| Açıklama Bu nitelik, bir iadeyi onaylama veya bir kredi notu oluşturma gibi bir görevi tamamlamaktan sorumlu belirli kullanıcıyı veya sistem temsilcisini tanımlar. SAP'de bu, genellikle bir belgeyi oluşturan veya değiştiren kullanıcıyı kaydeden alanlarda yakalanır. Kullanıcıya göre analiz, yüksek performans gösteren bireyleri veya ekipleri, eğitim ihtiyaçlarını ve iş yükü dağılımını belirlemeye yardımcı olur. Ayrıca, süreç eylemlerini belirli bireylere bağladığı için sapmaları araştırmak için de önemlidir, uyumluluk ve denetim çabalarını destekler. Neden Önemli?dir? Süreç aktivitelerini belirli kullanıcılara atayarak ekip performansının, iş yükünün ve uyumluluğun analizini sunar. 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ı detayları USR21 kullanıcı ana tablosundan zenginleştirilebilir. Örnekler::::::: CBROWNASMITHWF_BATCH | |||
| Müşteri Kimliği CustomerId | İadeyi başlatan müşteri için benzersiz tanımlayıcı. | ||
| Açıklama Bu nitelik, iadeyi talep eden müşteriyi tanımlar. Süreç örneğini müşteri ana verilerindeki belirli bir tarafa bağlar. Müşteriye göre iadeleri analiz etmek, olağandışı yüksek iade oranlarına sahip müşteriler gibi kalıpları belirlemeye yardımcı olur, bu da dolandırıcılık veya memnuniyetsizlik davranışını gösterebilir. Ayrıca, müşteri türü, değeri veya geçmişine göre iade sürecinin segmentasyonunu sağlayarak, özel hizmet seviyelerine sunar. Neden Önemli?dir? İadeleri belirli müşterilere bağlar, müşteri davranışının, segmentasyonun ve sık iade yapanların belirlenmesinin analizini sunar. Nereden Alınır?? İade siparişi başlık tablosunda (VBAK) müşteri numarası (KUNNR) alanında bulunur. Örnekler::::::: CUST-001, 2, 3, 4CUST-005678CUST-009012 | |||
| Olay Bitiş Zamanı EventEndTime | Bir faaliyetin tamamlanmasını işaretleyen zaman damgası (zaman damgası), süresini hesaplamak için kullanılır. | ||
| Açıklama
Bu öznitelik, aktivite işlem süresinin doğrudan hesaplanmasına sunar. Bu durum, yalnızca aralarındaki boşlukları değil, aynı zamanda hangi belirli adımların en çok zamanı tükettiğini belirlemeye yardımcı olan performans analizi için temel bir unsurdur. Neden Önemli?dir? Bireysel aktivite sürelerinin doğru hesaplanmasını sunar, bu da belirli süreç adımlarındaki verimsizlikleri belirlemek için temel rol oynar. Nereden Alınır?? Bu genellikle türetilmiştir. Bazı aktiviteler için ayrı bir alan olabilir. Daha yaygın olarak, vakanın sonraki aktivitesinin Başlangıç Zamanıdır. Örnekler::::::: 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Ürün ID ProductId | İade edilen öğenin benzersiz tanımlayıcısı. | ||
| Açıklama Bu nitelik, iadenin konusu olan malzemeyi veya ürünü belirtir. İade sürecini ürün kataloğundaki belirli bir öğeye bağlar. Ürüne göre iadeleri analiz etmek, yüksek iade oranlarına sahip öğeleri belirlemek için temeldir, bu da kalite kusurlarını, kötü ürün açıklamalarını veya üretim sorunlarını gösterebilir. Bu veri, işletmelerin ürün tasarımı, tedarikçi yönetimi ve envanter stratejisi hakkında bilinçli kararlar almasına yardımcı olur. Neden Önemli?dir? İade sürecini belirli ürünlere bağlar, ürün düzeyinde iade oranlarının analizini ve kalite veya açıklama sorunlarının belirlenmesini sunar. Nereden Alınır?? İade siparişi kalem tablosunda (VBAP) veya iade teslimat kalemi tablosunda (LIPS) malzeme numarası (MATNR) alanında bulunur. Örnekler::::::: FG-10023HW-45981SW-LICENSE-PREM | |||
| Alacak Notu Numarası CreditMemoNumber | Geri ödemeyi yetkilendiren kredi notu belgesinin benzersiz tanımlayıcısı. | ||
| Açıklama Bir iade faturası, iade edilen ürünler için müşterinin hesabına resmi olarak alacak kaydeden faturalama belgesidir. Bu öznitelik, o finansal belgenin benzersiz numarasıdır. İade Faturası Numarasını takip etmek, iade sürecinin finansal mutabakat kısmını analiz etmek için büyük önem taşır. Genellikle gerçek geri ödeme ödemesini tetikleyen kritik bir kilometre taşıdır ve finansal mutabakat ve denetim için gereklidir. Neden Önemli?dir? Geri ödeme için resmi finansal işlemi temsil eder; sürecin son aşamalarını takip etmek ve finansal denetim için büyük önem taşır. Nereden Alınır?? Bu, fatura belgesi başlığı tablosundaki (VBRK) belge kategorisinin bir kredi notu olduğunu gösterdiği fatura belgesi numarasıdır (VBELN). Örnekler::::::: 900003459000034690000347 | |||
| Geri Ödeme SLA Hedef Tarihi RefundSlaTargetDate | İade vakası için geri ödemenin işlenmesi gereken hedef tarih. | ||
| Açıklama Bu nitelik, geri ödemenin işlenmesi için Hizmet Seviyesi Anlaşması (SLA) son tarihini tanımlar. Bu tarih genellikle iş kurallarına göre, örneğin iade onaylandıktan veya ürünler teslim alındıktan sonra belirli bir gün sayısı olarak hesaplanır. Bu alan, 'Geri Ödeme SLA Uyumu İzleme' kontrol paneli'u ve ilişkili KPI için büyük önem taşır. SLA'larını ihlal etme riski taşıyan vakaların proaktif takibine ve gecikmelerin kök nedenlerinin analizine sunar, nihayetinde müşteri memnuniyetini artırmaya yardımcı olur. Neden Önemli?dir? SLA uyumluluğunu ölçmek için temel sunar, performansı izlemeye, eskiyen vakaları önceliklendirmeye ve müşteri memnuniyetini artırmaya yardımcı olur. Nereden Alınır?? Bu neredeyse her zaman türetilmiş bir alandır. Mantık, bir anahtar tarihe (örn. iade talebi oluşturma tarihi) artı iş kurallarıyla tanımlanan bir süreye 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 | |||
| Geri Ödeme SLA Uyumu RefundSlaAdherence | Geri ödemenin Hizmet Seviyesi Anlaşması (SLA) hedefi dahilinde işlenip işlenmediğini gösteren bir işaretleyici. | ||
| Açıklama Bu hesaplanmış nitelik, 'Geri Ödeme İşlendi' aktivitesinin 'Geri Ödeme SLA Hedef Tarihi'nde veya öncesinde gerçekleşip gerçekleşmediğini kontrol eder. Her vaka için SLA uyumluluğunun basit bir doğru veya yanlış göstergesini sunar. Bu, 'Geri Ödeme SLA Uyumu İzleme' kontrol paneli'u ve 'Geri Ödeme SLA Uyumu Oranı' KPI'ı için temel metriktir. Müşteri taahhütlerine karşı performansı ölçmeye ve beklentileri karşılayamayan vakaları belirlemeye yardımcı olarak gecikmelerin kök neden analizine sunar. Neden Önemli?dir? Doğrudan müşteri odaklı taahhütlere karşı performansı ölçer, bu da hizmet kalitesi ve müşteri memnuniyetinin kritik bir göstergesi olmasını sunar. Nereden Alınır?? Her vaka için 'Geri Ödeme İşlendi' aktivitesinin (EventTime)'ının 'RefundSlaTargetDate' ile karşılaştırılmasıyla hesaplanır. Örnekler::::::: truefalse | |||
| İade Politikası Kimliği ReturnPolicyId | Bu belirli iade vakasına uygulanan iade politikasının tanımlayıcısı. | ||
| Açıklama Bu nitelik, işleme hangi belirli iade politikasının veya kural kümesinin somut olduğunu gösterir. Politikalar ürün türüne, müşteri segmentine veya satın alma süresine göre değişebilir. Bu veri, 'İade Politikası Uyumluluk Genel Bakışı' için büyük önem taşır. Her bir vakayı bir politikayla ilişkilendirerek, sistem iade son teslim tarihleri veya ürün koşulu gereksinimleri gibi kurallara uyumu otomatik olarak kontrol edebilir ve analiz için sapmaları işaretleyebilir. Neden Önemli?dir? İş kurallarına karşı otomatik uyumluluk kontrolü sunar, iadelerin tutarlı ve 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 verileri kullanarak iş mantığına göre türetilmesi gerekebilir. Uygulanırsa özel bir alanda saklanabilir. Örnekler::::::: STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| İade Politikası Uyumluluğu ReturnPolicyAdherence | İade vakasının tanımlanan iade politikasına uygun olup olmadığını gösteren bir işaretleyici. | ||
| Açıklama Bu hesaplanmış boolean nitelik, bir iadenin geçerli iade politikasında belirtilen kriterleri karşılayıp karşılamadığını gösterir. Mantık, örneğin iadenin izin verilen zaman dilimi 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 nitelik, 'İade Politikası Uyumluluk Genel Bakışı' kontrol paneli'unu doğrudan destekler. Uyumluluk oranlarını ölçülmesini sunar ve sapmaların nedenlerini anlamak için uyumsuz vakalara derinlemesine inmeyi sunar, politikaları daha etkili bir şekilde uygulamaya yardımcı olur. Neden Önemli?dir? İş kurallarına uyumu nicelleştirerek, karlılığı etkileyebilecek veya süreç istisnaları oluşturabilecek politika ihlallerini belirlemeye ve azaltmaya yardımcı olur. Nereden Alınır?? İş kurallarına göre hesaplanır. Örneğin, (İade Başlatma Tarihi - Orijinal Satın Alma Tarihi) <= [İzin Verilen İade Günleri]. Bu, Orijinal Satın Alma Tarihi ve politika kurallarını gerektirir. Örnekler::::::: truefalse | |||
| İade Sipariş Durumu ReturnOrderStatus | İade vakasının mevcut genel durumu. | ||
| Açıklama Bu nitelik, herhangi bir zamanda iade vakasının 'Açık', 'İşlemde' veya 'Kapalı' gibi üst düzey bir durumunu sunar. Bu genellikle son tamamlanan ana kilometre taşından türetilen toplu bir durumdur. Bu, mevcut iş yükü ve vaka dağılımının operasyonel bir görünümünü sağlayan 'Mevcut İade Vaka Durumu Dashboard'u' için büyük önem taşır. Yöneticilerin sürecin her aşamasında kaç vaka olduğunu anlamalarına yardımcı olarak, daha iyi kaynak tahsisi ve iş yükü yönetimi sunar. Neden Önemli?dir? Her bir vakanın süreçteki konumunun anlık bir görüntüsünü sunar; bu, mevcut iş yükünü ve durumunu takip eden operasyonel kontrol paneli'lar için büyük önem taşır. Nereden Alınır?? İlgili belgelerdeki durum alanlarından türetilir. Örneğin, ilgili satış siparişindeki (VBUK/VBUP) veya teslimat belgelerindeki başlık durumu (GBSTK) veya kalem durumu (LFSTK) alanlarından. Örnekler::::::: Mal Kabulü Bekleniyorİnceleme BekliyorGeri Ödeme BekleniyorKapalı | |||
| İade Teslimat Numarası ReturnDeliveryNumber | İade teslimat belgesinin benzersiz tanımlayıcısı. | ||
| Açıklama Bir müşteri fiziksel olarak ürün iade ettiğinde, gelen lojistiği yönetmek için SAP'de bir iade teslimat belgesi oluşturulur. Bu nitelik, o belgenin benzersiz numarasıdır. Bu kimlik, iade edilen ürünlerin fiziksel hareketini takip etmek için önemlidir. İadenin finansal ve lojistik yönlerini birbirine bağlayarak, sürecin ürün teslim alma ve inceleme aşamalarının detaylı analizine sunar. Neden Önemli?dir? İade siparişi ile ürünlerin fiziksel olarak teslim alınması arasında anahtar bir bağlantı sunar; lojistik ve depo işlem sürelerini analiz etmek için büyük önem taşır. Nereden Alınır?? Bu, teslimat başlığı tablosundaki (LIKP) belge kategorisinin bir iade teslimatını gösterdiği teslimat belgesi numarasıdır (VBELN). Örnekler::::::: 840000128400001384000014 | |||
| İşlem Yapan Temsilci ProcessingAgent | Manuel bir aktiviteyi yürütmekten sorumlu belirli temsilci veya kaynak grubu. | ||
| Açıklama Bu nitelik, belirli bir görevi gerçekleştiren kişiyi veya ekibi tanımlar. Özellikle paylaşımlı hizmet ortamında bir rolü veya ekibi referans alarak 'Kullanıcı Adı'ndan daha spesifik olabilir. Bu, farklı temsilciler veya ekipler arasındaki performansı analiz etmek için 'Geri Ödeme Onay Verimliliği' kontrol paneli'u için değerlidir. İş yükü dağılımını anlamaya, eğitim ihtiyaçlarını belirlemeye ve en iyi uygulamaları paylaşabilecek en iyi performans gösterenleri veya ekipleri tanımaya yardımcı olur. Neden Önemli?dir? Temsilci veya ekip düzeyinde performans analizi sağlayarak iş yükünü yönetmeye, eğitim fırsatlarını belirlemeye ve verimliliği artırmaya yardımcı olur. Nereden Alınır?? Bu bilgi, temsilciler atanmışsa SAP İş Ortağı fonksiyonları aracılığıyla mevcut olabilir veya kullanıcının İK organizasyon yapısındaki departmanından veya rolünden türetilebilir. Örnekler::::::: 1. Kademe DestekDepo İnceleme EkibiFinans Departmanı - Borçlar | |||
| Otomatikleştirildi mi? IsAutomated | Bir aktivitenin bir sistem tarafından mı yoksa bir insan tarafından mı gerçekleştirildiğini gösteren bir işaretleyici. | ||
| Açıklama Bu boolean nitelik, bir iş akışı veya arka plan işi gibi bir sistem tarafından otomatik olarak yürütülen aktiviteler ile bir kullanıcı tarafından manuel olarak gerçekleştirilen aktiviteler arasında ayrım yapar. 'Otomatik Geri Ödeme Onay Oranı' KPI'ını hesaplamak ve otomasyonu artırma fırsatlarını belirlemek için büyük önem taşır. Manuel görevleri filtreleyerek, işletmeler süreç iyileştirme çabalarını otomasyonun hız, maliyet ve doğruluk açısından en önemli faydaları sağlayabileceği alanlara odaklayabilir. Neden Önemli?dir? Manuel ve otomatik görevler arasında ayrım yapar, bu da otomasyon fırsatlarını belirlemek ve dijital dönüşümün etkisini ölçmek için büyük önem taşır. Nereden Alınır?? Bu genellikle Kullanıcı Adı'na göre türetilir. Örneğin, kullanıcı 'WF_BATCH' veya başka bir sistem kimliği ise, aktivite otomatik olarak işaretlenir. Örnekler::::::: truefalse | |||
| Satış Organizasyonu SalesOrganization | Orijinal satıştan ve iadeden sorumlu organizasyonel birim. | ||
| Açıklama Satış Organizasyonu, SAP'de ürün ve hizmetlerin satışından ve dağıtımından sorumlu bir birimi temsil eden anahtar bir organizasyonel yapı unsurudur. İade işlemine atanır. Bu nitelik, iade sürecinin farklı iş birimleri, bölgeler veya bölümler arasında filtrelenmesini ve karşılaştırılmasını sunar. Belirli satış organizasyonlarının daha yüksek iade oranlarına veya daha az verimli iade işleme süreçlerine sahip olup olmadığını belirlemeye yardımcı olur ve organizasyonel performans analizi için bir temel sunar. Neden Önemli?dir? Farklı iş birimleri, bölgeler veya satış kanalları arasında iade süreci performansının ve oranlarının karşılaştırılmasını sunar. Nereden Alınır?? İade siparişi başlık tablosunda (VBAK) satış organizasyonu (VKORG) alanında bulunur. Örnekler::::::: 10002100US01 | |||
| Talep Edilen Geri Ödeme Tutarı RequestedRefundAmount | Sürecin başlangıcında başlangıçta talep edilen veya beklenen geri ödeme tutarı. | ||
| Açıklama Bu nitelik, ilk iade talebine göre iade edilen ürünlerin değerini yakalar. Nihai geri ödenen tutarın karşılaştırılabileceği bir temel olarak olarak kullanılır. Bu alan özellikle 'Geri Ödeme Tutarı Fark Analizi' kontrol paneli'u için gereklidir. Talep edilen tutarı gerçek geri ödeme tutarıyla karşılaştırmak, ürün hasarı nedeniyle kısmi geri ödemeler, stok yenileme ücretleri veya diğer ayarlamalar gibi sorunları belirlemeye yardımcı olur, finansal doğruluğu ve şeffaflığı sunar. Neden Önemli?dir? Geri ödeme doğruluğunu ölçmek için bir temel görevi görür; beklenen ve gerçek geri ödeme değerleri arasındaki tutarsızlıkları belirlemeye ve analiz etmeye 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ğeri (NETWR) olacaktır. Örnekler::::::: 125.501050.0049.99 | |||
| Ürün İnceleme Sonucu ItemInspectionOutcome | İade edilen ürünün fiziksel incelemesinin sonucu. | ||
| Açıklama Bu nitelik, ürünler depoda 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 bir bağlam sunar. Tam geri ödeme, kısmi geri ödeme veya hiç geri ödeme yapılıp yapılmadığını belirler. Bu sonucu analiz etmek, ret nedenlerini belirlemeye yardımcı olur ve ürünler transit sırasında sıkça hasar görürse ürün ambalajı veya nakliye ortakları hakkında geri bildirim sağlayabilir. Neden Önemli?dir? Geri ödeme onayları veya retlerinin arkasındaki karar alma sürecini açıklar, ürün durumu ve geri ödeme ayarlamalarının nedenleri hakkında değerli veriler sunar. Nereden Alınır?? Bu bilgi, bir kalite yönetimi modülü (QM) inceleme partisinde veya iade teslimat kaleminde (LIPS) bir durum veya neden kodu olarak kaydedilebilir. Özel bir alanda da mevcut olabilir. Örnekler::::::: Kabul Edildi - Yeniden SatılabilirKabul Edildi - YenilenmeliReddedildi - Müşteri kaynaklı hasarReddedildi - Yanlış ürün iade edildi | |||
| Yeniden İşleme mi? IsRework | Bir vaka içindeki bir aktivitenin önceki bir aktivitenin tekrarı olup olmadığını gösteren bir işaretleyici. | ||
| Açıklama Bu hesaplanmış boolean nitelik, aynı vaka içinde bir aktivitenin birden fazla kez gerçekleştirildiği yeniden işleme durumlarını tanımlar. Örneğin, bir ürün incelemesinin tekrarlanması veya bir kredi notunun oluşturulması, iptal edilmesi ve ardından yeniden oluşturulması gibi. Bu nitelik, 'Geri Ödeme Süreci Yeniden İşleme Analizi' kontrol paneli'u ve 'Geri Ödeme Yeniden İşleme Oranı' KPI'ı için büyük önem taşır. Hatalara eğilimli veya birden fazla deneme gerektiren aktiviteleri vurgulayarak süreç verimsizliğini nicelleştirmeye yardımcı olur, daha iyi kontrollere veya eğitime ihtiyaç duyan alanları gösterir. Neden Önemli?dir? Tekrarlanan işleri işaretleyerek süreç verimsizliklerini ve hatalarını vurgular, israfı ve gecikmeleri azaltmak için hedeflenen iyileştirmelere sunar. Nereden Alınır?? Bu işaret genellikle process mining aracı tarafından hesaplanır veya veri dönüşümünde önceden hesaplanabilir. Aynı aktivite adının aynı vakada daha önce görünüp görünmediğini kontrol eder. Örnekler::::::: truefalse | |||
İade ve Geri Ödeme Süreçleri Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Alacak Dekontu Oluşturuldu | Bu, iade edilen ürün için müşterinin hesabını alacaklandıran resmi fatura belgesinin oluşturulmasıdır. Bu, kredi notu talebinden kredi notu oluşturulduğunda yakalanan açık bir olaydır. | ||
| Neden Önemli?dir? İade faturasının oluşturulması kritik bir finansal kilometre taşıdır. İade edilecek tutarı onaylar ve ödeme sürecinin başlamasına yetki verir. Nereden Alınır?? VBRK tablosunda bir iade faturası gösteren belge kategorisine sahip bir faturalama belgesinin oluşturulmasından yakalanır. Bu, VBFA tablosundaki iade faturası talebine bağlıdır. Yakala Yeni bir iade faturası faturalama belgesi kaydedildiğinde (örneğin, VF01 işlemi kullanılarak) olay kaydedilir. Event tipi explicit | |||
| İade İşlendi | Bu aktivite, geri ödeme sürecinin son adımını işaret eder; finansal kredinin kapatıldığı ve ödemenin müşteriye gönderildiği anlamına gelir. Bu, finans modülünde müşterinin hesabındaki açık krediyi kapatan bir ödeme belgesinin oluşturulmasıyla çıkarılır. | ||
| Neden Önemli?dir? Bu, müşteriye gerçekten ödeme yapıldığı andır. İade başlatılmasından bu adıma ulaşmak için geçen süre, müşteri memnuniyetinin önemli bir belirleyicisidir ve SLA uyumluluğunu ölçmek için temel rol oynar. Nereden Alınır?? Finansal muhasebe kalem tablosu BSEG'deki mahsuplaşma belge bilgilerinden çıkarılır. İade faturasıyla ilişkili müşteri kalemindeki mahsuplaşma tarihi (BSEG-AUGDT), geri ödemenin ne zaman işlendiğini gösterir. Yakala İade faturasıyla ilişkili muhasebe belgesi için mahsuplaşma tarihi alanının doldurulmasından çıkarılır. Event tipi inferred | |||
| İade Talebi Başlatıldı | Bu, sistemde resmi olarak bir iade siparişi oluşturulduğu iade sürecinin başlangıç noktasıdır. Bu olay, iade siparişi türünde yeni bir satış belgesi SAP S/4HANA'da kaydedildiğinde açıkça yakalanır. | ||
| Neden Önemli?dir? Bu aktivite, iade vaka süreç döngüsünün resmi başlangıcını işaret eder. Bu olaydan kapanışa kadar geçen süreyi analiz etmek, genel iade döngü süresini ve müşteri deneyimini ölçmek için büyük önem taşır. Nereden Alınır?? Bu, VBAK tablosunda belge kategorisinin (VBAK-VBTYP) bir iade siparişi olduğunu gösterdiği bir satış belgesinin oluşturulmasından yakalanan açık bir olaydır. Oluşturma zaman damgası (zaman damgası) VBAK-ERDAT'tır. Yakala Yeni bir iade satış siparişi kaydedildiğinde (örneğin, VA01 işlemi kullanılarak) olay kaydedilir. Event tipi 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 aktivitedir. Bu genellikle iade siparişi belgesi sistemde nihai, kapalı bir duruma ulaştığında çıkarılır. | ||
| Neden Önemli?dir? Bu olay, süreç süreç döngüsünün sonunu tanımlar ve toplam uçtan uca döngü süresinin hesaplanmasını sunar. Vakanın tamamen çözüldüğünü doğrular. Nereden Alınır?? VBAK tablosundaki iade siparişinin veya VBAP'taki kalemlerinin genel durumunun 'Tamamlandı' veya 'Kapalı' durumuna ulaşmasından çıkarılır. Bu, sistemin durum yönetimi konfigürasyonu tarafından belirlenir. Yakala İade siparişi belge durumunun 'Tamamlandı' olarak değişmesinden çıkarılır. Event tipi inferred | |||
| Kredi Notu Talebi Oluşturuldu | Başarılı bir incelemenin ardından, bu aktivite müşteriye bir iade faturası düzenleme talebinin oluşturulmasını işaretler. Bu, orijinal iade siparişine referans veren yeni bir satış belgesi, bir iade faturası talebi olarak yakalanır. | ||
| Neden Önemli?dir? Bu, iade sürecinin finansal mutabakat kısmı için tetikleyicidir. İncelemeden bu adıma kadar geçen süreyi analiz etmek, lojistikten finansa devirdeki verimliliği ortaya çıkarır. Nereden Alınır?? VBAK tablosunda İade Faturası Talebi için bir belge kategorisine sahip bir satış belgesinin oluşturulmasından yakalanır. İadeye olan bağlantı, belge akış tablosu VBFA'da tutulur. Yakala Yeni bir iade faturası talep belgesi kaydedildiğinde olay kaydedilir. Event tipi explicit | |||
| Mallar Depoya Kabul Edildi | Bu olay, iade edilen ürünün depoda veya işleme merkezinde fiziksel olarak teslim alınmasını işaret eder. İade teslimatına karşı bir Mal Girişi Kaydı (PGR) yürütüldüğünde açıkça yakalanır ve bir malzeme belgesi oluşturulur. | ||
| Neden Önemli?dir? Bu, inceleme ve elden çıkarma için süreyi başlatan kritik bir kilometre taşıdır. Bu noktadan önceki gecikmeler müşteri kaynaklıyken, sonrakiler dahili gecikmelerdir. Nereden Alınır?? MSEG ve MKPF malzeme belge tablolarından, iadelerle ilişkili mal girişi hareket türü için yakalanır. Kayıt tarihi (MKPF-BUDAT) olay zamanını gösterir. Yakala Olay, iade teslimatı için bir mal girişi kaydına karşılık gelir. Event tipi explicit | |||
| Ürün İncelemesi Tamamlandı | İade edilen ürünlerin kalite ve durum değerlendirmesinin tamamlanmasını temsil eder. Gelişmiş İade Yönetimi'nde, bu genellikle inceleme sonucunu kaydeden ve geri ödeme veya hurdaya çıkarma gibi sonraki eylemi belirleyen açık bir adımdır. | ||
| Neden Önemli?dir? İncelemenin süresi ve sonucu, geri ödeme işlem süresini ve envanter yönetimini doğrudan etkiler. Bu aktivite, inceleme verimliliğini ve yeniden işlemeyi analiz etmek için büyük önem taşır. Nereden Alınır?? SAP Gelişmiş İade Yönetimi'nde (ARM), bu, inceleme işleminden açık bir olay olabilir. Ayrıca, iade siparişi kaleminde inceleme sonucunu gösteren bir durum değişikliğinden de çıkarılabilir. Yakala İşlem log'larından veya ARM'deki lojistik takip aktiviteleriyle ilgili durum değişikliklerinden yakalanır. Event tipi explicit | |||
| Değişim Siparişi Oluşturuldu | Bu aktivite, geri ödeme yerine müşteriye bir yedek ürün göndermek için yeni bir satış siparişinin oluşturulduğu alternatif bir çözümü temsil eder. Bu, orijinal iadeye referansla yeni bir satış siparişi oluşturulduğunda kaydedilir. | ||
| Neden Önemli?dir? Bu aktivite, farklı süreç yolları ve müşteri sonuçları olan geri ödeme için iadeler ile takas için iadeler arasında ayrım yapmaya yardımcı olur. Varyant analizi için temel rol oynar. Nereden Alınır?? VBAK'ta, belge akış tablosunda (VBFA) iade siparişine bağlı yeni bir satış belgesinin oluşturulmasından yakalanır. Yakala Yeni bir satış siparişi belgesi, değişim olarak belirlendiğinde kaydedilir. Event tipi 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, tipik olarak incelemeden sonra iade siparişi kalemine uygulanan belirli bir durum veya neden koduyla yakalanır. | ||
| Neden Önemli?dir? Reddetmeleri takip etmek, iade politikalarına uyumu analiz etmeye ve reddetme için yaygın nedenleri belirlemeye yardımcı olur. Süreçteki ana bir istisna yoludur. Nereden Alınır?? İade siparişi kaleminde bir ret nedeni (VBAP-ABGRU) ayarlanmasından veya Gelişmiş İade Yönetimi'ndeki inceleme sürecinde belirli bir durumun atanmasından çıkarılır. Yakala İade belge kaleminde bir ret nedeni veya belirli bir 'reddedildi' durumunun ayarlanmasından çıkarılır. Event tipi inferred | |||
| İade Siparişi Onaylandı | İade siparişinin resmi onayını veya serbest bırakılmasını temsil eder, bir sonraki aşamaya geçmesini sunar. Bu genellikle satış belgesi başlığındaki veya kalemindeki bir durum değişikliğinden çıkarılır ve herhangi bir engelden serbest bırakıldığını gösterir. | ||
| Neden Önemli?dir? Onay adımları önemli bir gecikme kaynağı olabilir. Bu aktiviteyi takip etmek, 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 veya VBAP tablolarındaki durum alanlarından çıkarılır. Bir serbest bırakma durumundaki değişiklik veya bir teslimat bloğunun (VBAP-LIFSP) kaldırılması onay anlamına gelebilir. Yakala İade siparişinin başlık veya kalem durum alanlarındaki, serbest bırakma veya onayı gösteren bir değişiklikten çıkarılır. Event tipi inferred | |||
| İade Teslimatı Oluşturuldu | Bu aktivite, iade edilen ürünlerin fiziksel olarak teslim alınmasını yönetmek için kullanılan bir gelen teslimat belgesinin oluşturulmasını ifade eder. Sistem, bunu iade siparişine atıfta bulunan bir teslimat belgesi için açık bir oluşturma olayı olarak yakalar. | ||
| Neden Önemli?dir? Bu adım, önemli bir lojistik kilometre taşıdır. İade onayı ile teslimat oluşturma arasındaki süre, iade bilgisinin depoya veya alıcı departmana iletilmesindeki verimliliği vurgular. Nereden Alınır?? LIKP tablosundaki bir teslimat başlığının oluşturulmasından yakalanır, belge akış tablosu VBFA aracılığıyla önceki iade siparişine bağlıdır. Yakala Yeni bir iade teslimat belgesi kaydedildiğinde (örneğin, VL01N işlemi kullanılarak) olay kaydedilir. Event tipi explicit | |||
| Muhasebe Belgesi Oluşturuldu | Bu olay, kredi notunun finansal muhasebe modülüne başarıyla kaydedilmesiyle gerçekleşir. Genel defterde ilgili girişleri oluşturarak, krediyi muhasebe açısından resmi hale getirir. | ||
| Neden Önemli?dir? Bu aktivite, kredinin finansal sisteme entegre edildiğini doğrular. Kredi notu oluşturma ile muhasebe kaydı arasındaki süre, faturalama-finans arayüzündeki sorunları vurgulayabilir. Nereden Alınır?? Muhasebe tablosu BKPF'de, VBRK'daki iade faturasına (VBRK-BELNR) bağlı bir belge başlığının oluşturulmasından yakalanır. Yakala Faturalama belgesinin Finansal Muhasebeye başarılı bir şekilde kaydedilmesiyle olay kaydedilir. Event tipi explicit | |||
Veri Çıkarma Kılavuzları
Adımlar
- Önkoşulların Doğrulanması: Veri çekimini yürüten kullanıcı hesabının, gerekli Temel Veri Enerji ve Altyapıi (CDS) Görünümlerine erişmek için SAP S/4HANA'da gerekli yetkilere sahip olduğundan emin olun. Anahtar 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şim: SAP S/4HANA veritabanına bağlantısı olan tercih ettiğiniz SQL istemcisine veya veri entegrasyon aracına giriş yapın. Bu, SAP'nin SAP Analytics Cloud gibi kendi araçları veya üçüncü taraf bir ETL platformu olabilir.
- Sorgu Parametrelerini Ayarlayın: Yürütmeden önce, sağlanan SQL sorgusunu değiştirmeniz gerekir. Yer tutucu değerlerini bulun ve bunları ortamınız için doğru parametrelerle değiştirin. Bu,
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]ve diğer belge türü veya şirket kodu filtrelerini ayarlamayı içerir. - Veri Çekim Sorgusunu Yürütün: Tam SQL sorgusunu kopyalayın ve aracınızda yürütün. Sorgu, birden fazla seçme ifadesinden elde edilen sonuçları birleştirerek belirtilen tüm aktiviteleri tek bir veri kümesinde toplamak için optimize edilmiştir.
- Sorgu Mantığını Anlayın:
UNION ALLyapısındaki herSELECTbloğu, belirli bir aktiviteyi çekmekten sorumludur. Gerekli nitelikleri toplamak için birden fazla CDS görünümünü birleştirir,(ActivityName)olarak sabit bir dize atar ve(EventTime)için ilgili zaman damgası (zaman damgası)nı seçer. - Ham Veriyi İnceleyin: Sorgu tamamlandıktan sonra çıktıyı kısa bir gözden geçirin. Makul sayıda satır olup olmadığını kontrol edin ve
ReturnCaseId,(ActivityName)ve(EventTime)gibi anahtar sütunların beklendiği gibi doldurulduğundan emin olun. - Veri Dönüşümü: Sorgu, düz bir event log formatı üretmek için yapılandırılmıştır. Genellikle önemli yapısal dönüşümlere ihtiyaç duyulmaz. Ancak, hedef sisteminizin gereksinimlerine bağlı olarak zaman damgası (zaman damgası) formatlarını veya veri türlerini ayarlamanız gerekebilir.
- Event Log'u Dışa Aktarın: Sorgu sonuç kümesini CSV dosyası olarak dışa aktarın. Özellikle kullanıcı adları veya ürün açıklamalarıyla ilgili karakter sorunlarını önlemek için dosyanın UTF-8 kodlaması kullandığından emin olun.
- Süreç Madenciliği Aracına Yükle: Ortaya çıkan CSV dosyası şimdi ProcessMind gibi proses madenciliği platformunuza yüklenmeye hazırdır. Dosyadaki sütunları araçtaki ilgili alanlara eşleştirin, örneğin
ReturnCaseId'i Vaka Kimliğine,(ActivityName)'i Aktiviteye ve(EventTime)'ı Zaman Damgasına.
Konfigürasyon
- Önkoşullar: Sorguyu yürüten kullanıcının satış belgeleri (VBAK), teslimatlar (LIKP), faturalandırma (VBRK) ve muhasebe (BSEG, BKPF) ile ilgili nesneler için görüntüleme yetkilerine ihtiyacı vardır. Temel CDS görünümlerine erişim gereklidir.
- Veri Kapsamı Filtreleri: İade sürecini izole etmek için sorguyu belirli belge türleri için filtrelemek büyük önem taşır. İade sipariş türleri (örneğin, 'RE'), iade faturası talep türleri (örneğin, 'G2') ve değişim sipariş türleri (örneğin, 'SO') için yer tutucuları yapılandırın. Veri kapsamını sınırlamak için
CompanyCodeveyaSalesOrganization'a göre filtreleme de şiddetle tavsiye edilir. - Tarih Aralığı Filtreleme: Performansı ve veri hacmini yönetmek için her zaman bir tarih aralığı filtresi uygulayın. Son 3 ila 6 aylık verilerle başlayın. Sorgu, başlangıç iade siparişinin oluşturulma tarihini (
I_SalesDocument.CreationDate) birincil filtre koşulu olarak kullanır. - Performans Hususları: Bu, birden fazla büyük CDS görünümünü birleştiren detaylı bir sorgudur. Kaynak S/4HANA sistemi üzerinde yürütme kaynak yoğun olabilir. Etkiyi en aza indirmek için veri çekimini yoğun olmayan iş saatlerinde planlayın. Çok büyük veri kümeleri için artımlı yükleme stratejilerini düşünün.
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
- Önkoşulların Doğrulanması: Veri çekimini yürüten kullanıcı hesabının, gerekli Temel Veri Enerji ve Altyapıi (CDS) Görünümlerine erişmek için SAP S/4HANA'da gerekli yetkilere sahip olduğundan emin olun. Anahtar 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şim: SAP S/4HANA veritabanına bağlantısı olan tercih ettiğiniz SQL istemcisine veya veri entegrasyon aracına giriş yapın. Bu, SAP'nin SAP Analytics Cloud gibi kendi araçları veya üçüncü taraf bir ETL platformu olabilir.
- Sorgu Parametrelerini Ayarlayın: Yürütmeden önce, sağlanan SQL sorgusunu değiştirmeniz gerekir. Yer tutucu değerlerini bulun ve bunları ortamınız için doğru parametrelerle değiştirin. Bu,
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]ve diğer belge türü veya şirket kodu filtrelerini ayarlamayı içerir. - Veri Çekim Sorgusunu Yürütün: Tam SQL sorgusunu kopyalayın ve aracınızda yürütün. Sorgu, birden fazla seçme ifadesinden elde edilen sonuçları birleştirerek belirtilen tüm aktiviteleri tek bir veri kümesinde toplamak için optimize edilmiştir.
- Sorgu Mantığını Anlayın:
UNION ALLyapısındaki herSELECTbloğu, belirli bir aktiviteyi çekmekten sorumludur. Gerekli nitelikleri toplamak için birden fazla CDS görünümünü birleştirir,(ActivityName)olarak sabit bir dize atar ve(EventTime)için ilgili zaman damgası (zaman damgası)nı seçer. - Ham Veriyi İnceleyin: Sorgu tamamlandıktan sonra çıktıyı kısa bir gözden geçirin. Makul sayıda satır olup olmadığını kontrol edin ve
ReturnCaseId,(ActivityName)ve(EventTime)gibi anahtar sütunların beklendiği gibi doldurulduğundan emin olun. - Veri Dönüşümü: Sorgu, düz bir event log formatı üretmek için yapılandırılmıştır. Genellikle önemli yapısal dönüşümlere ihtiyaç duyulmaz. Ancak, hedef sisteminizin gereksinimlerine bağlı olarak zaman damgası (zaman damgası) formatlarını veya veri türlerini ayarlamanız gerekebilir.
- Event Log'u Dışa Aktarın: Sorgu sonuç kümesini CSV dosyası olarak dışa aktarın. Özellikle kullanıcı adları veya ürün açıklamalarıyla ilgili karakter sorunlarını önlemek için dosyanın UTF-8 kodlaması kullandığından emin olun.
- Süreç Madenciliği Aracına Yükle: Ortaya çıkan CSV dosyası şimdi ProcessMind gibi proses madenciliği platformunuza yüklenmeye hazırdır. Dosyadaki sütunları araçtaki ilgili alanlara eşleştirin, örneğin
ReturnCaseId'i Vaka Kimliğine,(ActivityName)'i Aktiviteye ve(EventTime)'ı Zaman Damgasına.
Konfigürasyon
- Önkoşullar: Sorguyu yürüten kullanıcının satış belgeleri (VBAK), teslimatlar (LIKP), faturalandırma (VBRK) ve muhasebe (BSEG, BKPF) ile ilgili nesneler için görüntüleme yetkilerine ihtiyacı vardır. Temel CDS görünümlerine erişim gereklidir.
- Veri Kapsamı Filtreleri: İade sürecini izole etmek için sorguyu belirli belge türleri için filtrelemek büyük önem taşır. İade sipariş türleri (örneğin, 'RE'), iade faturası talep türleri (örneğin, 'G2') ve değişim sipariş türleri (örneğin, 'SO') için yer tutucuları yapılandırın. Veri kapsamını sınırlamak için
CompanyCodeveyaSalesOrganization'a göre filtreleme de şiddetle tavsiye edilir. - Tarih Aralığı Filtreleme: Performansı ve veri hacmini yönetmek için her zaman bir tarih aralığı filtresi uygulayın. Son 3 ila 6 aylık verilerle başlayın. Sorgu, başlangıç iade siparişinin oluşturulma tarihini (
I_SalesDocument.CreationDate) birincil filtre koşulu olarak kullanır. - Performans Hususları: Bu, birden fazla büyük CDS görünümünü birleştiren detaylı bir sorgudur. Kaynak S/4HANA sistemi üzerinde yürütme kaynak yoğun olabilir. Etkiyi en aza indirmek için veri çekimini yoğun olmayan iş saatlerinde planlayın. Çok büyük veri kümeleri için artımlı yükleme stratejilerini düşünün.
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'