İade ve Geri Ödeme İşleme Veri Şablonunuz
İade ve Geri Ödeme İşleme Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
İade ve Geri Ödeme Süreçleri Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet 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 yaşam 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 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 sağlar. 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ıÜrün Depoda Teslim AlındıAlacak Dekontu Oluşturulduİade İşlendi | |||
| İade Vaka Kimliği 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 hizmet eder. Her müşteri iade talebine benzersiz bir kimlik atanır ve bu, tüm sürecin uçtan uca takibini sağlar. Process mining'de bu nitelik, süreç akışını yeniden yapılandırmak için temeldir. 'İ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 sağlar. Neden önemli Bu, bir iadeyi baştan sona takip etmek için temel anahtardır; döngü süresi ve süreç varyantı keşfi dahil tüm vaka düzeyindeki analizleri mümkün kılar. 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ı. | ||
| Açıklama Event Time, bir iş olayının sisteme kaydedildiği tarihi ve saati yakalar. Bu zaman damgası, aktiviteleri kronolojik olarak sıralamak ve tüm zamana dayalı analizler için çok önemlidir. 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 Bu zaman damgası, olayları sıralamak, tüm süreleri ve döngü sürelerini hesaplamak ve süreç gecikmelerini belirlemek için hayati öneme sahiptir. 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ü sağlamak için kritik öneme sahiptir. İ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 Veri kaynağı ve soyu için çok önemli bir bağlam sağlar; ö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ı. | ||
| Açıklama Bu nitelik, son veri çekme veya güncellemenin tarih ve saatini kaydeder. Analiz edilen veri kümesinin güncelliği hakkında metadata sağlar. 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 dashboard'lar için önemlidir. Neden önemli 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' dashboard'u için hayati öneme sahiptir. 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 olanak tanır. Neden önemli İ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 hayati öneme sahiptir. 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üşteri tarafından ürünün iade edilmesi için belirtilen 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 kritik öneme sahiptir. Müşteri memnuniyetsizliğine doğrudan bir içgörü sağlar ve genel iade oranını azaltmak için iş iyileştirme alanlarını önceliklendirmeye yardımcı olur. Neden önemli İ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 mümkün kılar. 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 Süreç aktivitelerini belirli kullanıcılara atayarak ekip performansının, iş yükünün ve uyumluluğun analizini sağlar. Nereden alınır Genellikle VBAK (Satış Siparişleri), LIKP (Teslimatlar) ve BKPF (Muhasebe Belgeleri) gibi belge başlık tablolarında ERNAM (Oluşturan) alanında bulunur. Kullanıcı detayları USR21 kullanıcı ana tablosundan zenginleştirilebilir. Örnekler CBROWNASMITHWF_BATCH | |||
| Müşteri Kimliği CustomerId | İadeyi başlatan müşterinin benzersiz tanımlayıcısı. | ||
| 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 mümkün kılarak, özel hizmet seviyelerine olanak tanır. Neden önemli İadeleri belirli müşterilere bağlar, müşteri davranışının, segmentasyonun ve sık iade yapanların belirlenmesinin analizini sağlar. Nereden alınır İade siparişi başlık tablosunda (VBAK) müşteri numarası (KUNNR) alanında bulunur. Örnekler CUST-001234CUST-005678CUST-009012 | |||
| Olay Bitiş Zamanı EventEndTime | Bir faaliyetin tamamlanmasını işaretleyen Timestamp, süresini hesaplamak için kullanılır. | ||
| Açıklama
Bu öznitelik, aktivite işlem süresinin doğrudan hesaplanmasına olanak tanır. 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 Bireysel aktivite sürelerinin hassas hesaplanmasını sağlar, bu da belirli süreç adımlarındaki verimsizlikleri belirlemek için anahtardır. 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 İ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 sağlar. 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 | |||
| 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' dashboard'u ve ilişkili KPI için temeldir. SLA'larını ihlal etme riski taşıyan vakaların proaktif takibine ve gecikmelerin kök nedenlerinin analizine olanak tanır, nihayetinde müşteri memnuniyetini artırmaya yardımcı olur. Neden önemli SLA uyumluluğunu ölçmek için temel sağlar, 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 sağlar. Bu, 'Geri Ödeme SLA Uyumu İzleme' dashboard'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 olanak tanır. Neden önemli 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ı sağlar. 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 Faturası 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 çok önemlidir. Genellikle gerçek geri ödeme ödemesini tetikleyen kritik bir kilometre taşıdır ve finansal mutabakat ve denetim için gereklidir. Neden önemli Geri ödeme için resmi finansal işlemi temsil eder; sürecin son aşamalarını takip etmek ve finansal denetim için kritik öneme sahiptir. 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 | |||
| İ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 uygulanabilir 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 hayati öneme sahiptir. 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 İş kurallarına karşı otomatik uyumluluk kontrolü sağlar, 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ı Uyumu 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ışı' dashboard'unu doğrudan destekler. Uyumluluk oranlarını nicelleştirir ve sapmaların nedenlerini anlamak için uyumsuz vakalara derinlemesine inmeyi sağlar, politikaları daha etkili bir şekilde uygulamaya yardımcı olur. Neden önemli İş 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 sağlar. 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 hayati öneme sahiptir. 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 sağlar. Neden önemli 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 dashboard'lar için hayati öneme sahiptir. 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 olanak tanır. Neden önemli İade siparişi ile ürünlerin fiziksel olarak teslim alınması arasında anahtar bir bağlantı sağlar; lojistik ve depo işlem sürelerini analiz etmek için kritik öneme sahiptir. 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 Temsilcisi 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' dashboard'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 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 hayati öneme sahiptir. 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 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 çok önemlidir. 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ı sağlar. 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 sağlar. Neden önemli 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ı sağlar. 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 hizmet eder. Bu alan özellikle 'Geri Ödeme Tutarı Fark Analizi' dashboard'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ığı sağlar. Neden önemli 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 kritik bir bağlam sağlar. 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 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 sağlar. 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 | |||
| Vaka Cycle Time CycleTime | Bir iade vakasının başlatılmasından kapanmasına kadar geçen toplam süre. | ||
| Açıklama Bu hesaplanmış metrik, tek bir vaka için tüm iade sürecinin uçtan uca süresini ölçer. Genellikle 'İade Talebi Başlatıldı'dan 'İade Vakası Kapandı'ya kadar ilk ve son olay arasındaki zaman farkı olarak hesaplanır. Döngü Süresi, süreç verimliliği için birincil bir KPI'dır. Performansı izlemek, karşılaştırmalar yapmak ve eğilimleri belirlemek için 'Genel İade Döngü Süresi' dashboard'unda kullanılır. Ürün tipi veya iade nedeni gibi daha uzun döngü süreleriyle ilişkili faktörleri analiz etmek, sistemik verimsizlikleri ortaya çıkarabilir. Neden önemli Bu, genel süreç verimliliğini ölçmek için temel bir KPI'dır ve müşteri memnuniyetini ve operasyonel maliyetleri doğrudan etkiler. Nereden alınır Bu hesaplanmış bir alandır. Her benzersiz ReturnCaseId için maksimum ve minimum EventTime arasındaki fark alınarak hesaplanır. Örnekler 5d 4h 30m12d 2h 15m2d 8h 0m | |||
| 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' dashboard'u ve 'Geri Ödeme Yeniden İşleme Oranı' KPI'ı için hayati öneme sahiptir. 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 Tekrarlanan işleri işaretleyerek süreç verimsizliklerini ve hatalarını vurgular, israfı ve gecikmeleri azaltmak için hedeflenen iyileştirmelere olanak tanır. 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 Aktiviteleri
| 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 İ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 Faturası 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 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 | |||
| İ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 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 anahtardır. 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 Bu aktivite, iade vaka yaşam 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 kritik öneme sahiptir. 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ı 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ı Kapandı | 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 Bu olay, süreç yaşam döngüsünün sonunu tanımlar ve toplam uçtan uca döngü süresinin hesaplanmasını sağlar. 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 | |||
| Ürün Depoda Teslim Alındı | 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 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 İ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 hayati öneme sahiptir. 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 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 anahtardır. 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 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 sağlar. 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 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 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 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 Çekim Kılavuzları
Adımlar
- Önkoşulların Doğrulanması: Veri çekimini yürüten kullanıcı hesabının, gerekli Temel Veri Hizmetleri (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 tasarlanmıştır.
- Sorgu Mantığını Anlayın:
UNION ALLyapısındaki herSELECTbloğu, belirli bir aktiviteyi çekmekten sorumludur. Gerekli öznitelikleri toplamak için birden fazla CDS görünümünü birleştirir,ActivityNameolarak sabit bir dize atar veEventTimeiçin ilgili 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,ActivityNameveEventTimegibi 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ı 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.
- Proses 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 veEventTime'ı 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 esastır.
- Veri Kapsamı Filtreleri: İade sürecini izole etmek için sorguyu belirli belge türleri için filtrelemek çok önemlidir. İ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 kapsamlı 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 Hizmetleri (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 tasarlanmıştır.
- Sorgu Mantığını Anlayın:
UNION ALLyapısındaki herSELECTbloğu, belirli bir aktiviteyi çekmekten sorumludur. Gerekli öznitelikleri toplamak için birden fazla CDS görünümünü birleştirir,ActivityNameolarak sabit bir dize atar veEventTimeiçin ilgili 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,ActivityNameveEventTimegibi 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ı 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.
- Proses 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 veEventTime'ı 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 esastır.
- Veri Kapsamı Filtreleri: İade sürecini izole etmek için sorguyu belirli belge türleri için filtrelemek çok önemlidir. İ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 kapsamlı 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'