İade ve geri ödeme süreçleri için Veri Templateiniz
İade ve geri ödeme süreçleri için Veri Templateiniz
- Toplanması önerilen veri alanları
- İzlenecek temel süreç adımları
- Veri çıkarma yönergeleri
İade ve geri ödeme süreçlerinin öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| İade vaka kimliği ReturnCaseId | Müşterinin iade ve geri ödeme vakasına ait, ilgili tüm etkinlikleri birbirine bağlayan benzersiz tanımlayıcı. | ||
| Açıklama İade Vaka Kimliği, her bir iade süreci örneğini tanımlayan temel kimliktir. İade siparişinin oluşturulmasından son aşamada kapatılmasına kadar, belirli bir müşteri iadesi veya geri ödeme talebiyle ilişkili tüm etkinlikleri birbirine bağlar. Süreç analizinde bu kimlik, her iadenin uçtan uca yolculuğunu yeniden oluşturmak için gereklidir. Tüm yaşam döngüsünü izlemeyi, toplam çevrim sürelerini ölçmeyi ve vakalar arasındaki farklılıkları incelemeyi sağlar. Tüm olaylar, veriler ve metrikler bu kimlik kullanılarak bir araya getirilir ve ilişkilendirilir. Neden önemli? Bu temel vaka kimliği, tüm süreç adımlarını birbirine bağlar ve her iadeyi başlangıçtan sona kadar izleyip analiz etmenizi sağlar. Nereden alınır? Bu genellikle İade Malzeme Yetkilendirmesi (RMA) numarası veya 'Sales and marketing' modülündeki 'Returned Order' türündeki satış siparişi numarasıdır. 'SalesType' değeri 'Returned Order' olan 'SalesTable' gibi tablolarda bulunur. Örnekler RMA-001234RMA-001235RMA-001236 | |||
| Olay zamanı EventTime | Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
| Açıklama Olay zamanı, yani zaman damgası, bir etkinliğin gerçekleştiği kesin tarih ve saati kaydeder. Event Log içindeki her etkinliğin, olayların kronolojik sırasını gösteren bir zaman damgası vardır. Bu öznitelik, zamana dayalı tüm Process Mining analizleri için gereklidir. Etkinlikler arasındaki çevrim sürelerini hesaplamak, bekleme sürelerini ve darboğazları belirlemek, toplam vaka süresini ölçmek ve hizmet seviyesi anlaşmalarına (SLA) uyumu kontrol etmek için kullanılır. Zaman damgalarının doğruluğu, performans analizinin güvenilirliğini doğrudan etkiler. Neden önemli? Bu zaman damgası, performans analizinin temelini oluşturan çevrim süreleri ve bekleme süreleri gibi süreye dayalı tüm metrikleri hesaplamak için gereklidir. Nereden alınır? Sipariş oluşturma için 'SalesTable.createdDateTime' veya depo günlükleri için 'WMSJournalTrans.createdDateTime' gibi çeşitli tablolardaki oluşturulma ya da değiştirilme tarihi alanlarına karşılık gelir. Örnekler 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| Etkinlik adı ActivityName | İade ve geri ödeme sürecinde gerçekleşen belirli bir iş olayının veya görevin adı. | ||
| Açıklama Bu öznitelik, 'İade siparişi oluşturuldu', 'Ürün teslim alındı' veya 'Alacak dekontu kaydedildi' gibi iade ve geri ödeme yaşam döngüsündeki belirli bir adımı veya olayı tanımlar. Her etkinlik, sistemde kaydedilen ayrı bir süreç noktasını temsil eder. Bu etkinliklerin sırasını ve sıklığını incelemek, Process Mining’in temelini oluşturur. Süreç haritalarını görselleştirmeyi, adımlar arasındaki darboğazları belirlemeyi ve yaygın ya da seyrek görülen süreç akışlarını keşfetmeyi sağlar. Etkinlik kümesi, analiz edilen sürecin kapsamını belirler. Neden önemli? Süreç adımlarını tanımlar; süreç akışını görselleştirmenizi, darboğazları, yeniden çalışmayı ve sapmaları belirlemenizi sağlar. Nereden alınır? Bu, sistem olaylarından türetilen kavramsal bir özniteliktir. 'SalesTable' ve 'WMSJournalTable' gibi tablolardaki durum değişiklikleri veya belirli olay günlükleri, kullanıcıların kolayca anlayacağı adlarla eşleştirilerek oluşturulabilir. Örnekler İade siparişi oluşturulduÜrün teslim alındıSonuç kodu uygulandıAlacak dekontu kaydedildi | |||
| İade kanalı ReturnChannel | Müşterinin iade talebini başlatmak için kullandığı yöntem veya kanaldır. | ||
| Açıklama Bu öznitelik, müşterinin iade sürecini başlatmak için kullandığı kanalı belirtir. Örneğin 'Çevrimiçi portal', 'Mağaza', 'Müşteri hizmetleri araması' veya 'Posta'. Süreç analizini iade kanalına göre gruplamak, her kanalın performansını ve verimliliğini değerlendirmeye yardımcı olur. İşletmeler en iyi uygulamaları ve yatırım ya da iyileştirme alanlarını belirlemek için kanalların çevrim sürelerini, maliyetlerini ve müşteri memnuniyetini karşılaştırabilir. Bu bilgi, 'İade kanalı kullanım performansı' Dashboardu için temel oluşturur. Neden önemli? Farklı iade kanallarının performansını karşılaştırmaya ve en verimli, uygun maliyetli kanalları belirlemeye yardımcı olur. Nereden alınır? Bu bilgi, iade siparişinin başlık bölümünde ('SalesTable') tutuluyor veya siparişi oluşturan kullanıcıdan elde ediliyor olabilir. Özel bir mantık ya da ayrı bir alan gerekebilir. Örnekler Web portalıMağaza kioskuMüşteri desteği | |||
| İade nedeni kodu ReturnReasonCode | Müşterinin ürünü iade etme nedenidir. | ||
| Açıklama İade nedeni kodu, müşterinin belirttiği iade nedenini kaydeder. Örneğin 'Ürün kusurlu', 'Yanlış beden', 'Açıklamadaki gibi değil' veya 'Artık gerekmiyor'. Bu bilgi genellikle iade talebi oluşturulurken alınır. İade nedenlerini analiz etmek, temel nedenleri belirlemek açısından önemlidir. İşletmeler bu sayede ürün kalitesi sorunlarını, ürün açıklamalarındaki eksiklikleri veya lojistik hatalarını tespit edebilir. Bu verilerden elde edilen içgörüler, gelecekteki iadeleri azaltmak için ürün tasarımında, pazarlamada ve tedarik zinciri operasyonlarında iyileştirmeler yapılmasına yardımcı olur. Neden önemli? İadelerin neden gerçekleştiğini anlamaya yardımcı olur. Böylece temel nedenleri analiz ederek iade oranlarını azaltabilir ve müşteri memnuniyetini artırabilirsiniz. Nereden alınır? Bu bilgi genellikle iade siparişinin satır düzeyinde tutulur. İade siparişlerine ait 'SalesLine' tablosunda neden kodu alanlarını arayın. Örnekler DEFECTWRONG_ITEMNO_LONGER_WANTEDDAMAGED_IN_TRANSIT | |||
| Sonuç kodu DispositionCode | Ürün incelemesinin sonucunu ve yapılacak sonraki işlemi belirten kod. | ||
| Açıklama Sonuç kodu, iade edilen ürünün kalite incelemesi sırasında atanır. 'Credit', 'Replace', 'Scrap' veya 'Return to Customer' gibi sonraki adımı belirler. Bu öznitelik, iade sürecinde önemli bir karar noktasıdır. Sonuç koduna göre yapılan analiz, işletmelerin iadelerin sonuçlarını anlamasına, ürünleri hurdaya ayırmanın mali etkisini izlemesine ve ürün değişimiyle geri ödeme gibi farklı çözüm yollarının verimliliğini değerlendirmesine yardımcı olur. Neden önemli? Bu kod, incelemenin ardından bir iade vakasının izleyeceği yolu belirler. Süreç varyantlarını ve bunların iş sonuçlarını analiz etmek için önemli bir alandır. Nereden alınır? Kalite yönetimi modülündeki temel alanlardan biridir. Kalite Siparişi veya Muayene Siparişi işlemleriyle ilişkilidir. Örnekler CRDTREPL-DSCRAPRTV | |||
| Sorumlu kullanıcı ResponsibleUser | Belirli bir etkinliği gerçekleştiren veya bu etkinlikten sorumlu olan kullanıcı ya da çalışan. | ||
| Açıklama Bu öznitelik, süreç adımını gerçekleştirmekten sorumlu kişiyi tanımlar. Bu kişi ürünü teslim alan depo çalışanı, kalite denetçisi veya alacak dekontunu kaydeden finans görevlisi olabilir. Süreci kullanıcı bazında incelemek, iş yükünün nasıl dağıldığını anlamaya, yüksek performans gösterenleri belirlemeye ve olası eğitim ihtiyaçlarını saptamaya yardımcı olur. Ayrıca belirli kişiler veya ekipler tarafından yürütülen vakaları incelemek ve görevlerin uygun şekilde ayrılmasını sağlamak için kullanılabilir. Neden önemli? İş yükünün dağılımını ve kişi ya da ekip performansını incelemenizi, eğitim veya kaynak tahsisi fırsatlarını belirlemenizi sağlar. Nereden alınır? İşlem kayıtlarındaki 'created by' veya 'modified by' alanlarında bulunur. Örneğin, 'SalesTable.createdBy' alanında veya günlük tablolarına bağlı kullanıcı kimliklerinde yer alabilir. Örnekler Alice.WBob.JChris.P | |||
| Ürün kimliği ProductId | İade edilen ürünü tanımlayan benzersiz kimliktir. | ||
| Açıklama Ürün kimliği, genellikle Stok Tutma Birimi (SKU), müşterinin iade ettiği ürünü belirtir. Her iade siparişi satırı bir ürün kimliğiyle ilişkilendirilir. İade oranı yüksek ürünleri belirlemek için iadeleri ürün bazında analiz etmek gerekir. Yüksek oranlar kalite kontrol sorunlarına, hatalı ürün açıklamalarına veya üretim kusurlarına işaret edebilir. Bu analiz, ürünlerle ilgili inceleme ve iyileştirmelere öncelik vermeye yardımcı olur. Neden önemli? İadeleri ürün bazında analiz etmenizi ve kalite sorunu ya da yüksek iade hacmi olan ürünleri belirlemenizi sağlar. Nereden alınır? İade siparişinin 'SalesLine' tablosundaki 'ItemId' alanına karşılık gelir. Örnekler SKU-A-123SKU-B-456SKU-C-789 | |||
| Alacak dekontu kimliği CreditNoteId | İade için oluşturulan alacak dekontu belgesinin benzersiz kimliğidir. | ||
| Açıklama İade işlemi yapıldığında alacak dekontu veya alacak notu olarak bilinen bir mali belge oluşturulur. Bu öznitelik, belgenin benzersiz kimliğini saklar. Bu kimlik, operasyonel iade sürecini muhasebe sistemindeki mali kayıtlara doğrudan bağlar. Denetim ve mali farkların ayrıntılı incelenmesi için kullanışlıdır. Analist, iade vakasını sonuçlandıran belirli mali işleme kadar izleyebilir. Neden önemli? Operasyonel iade sürecini ilgili mali işlemle ilişkilendirir. Denetim ve mali mutabakat için önemlidir. Nereden alınır? Alacak dekontu numarası genellikle 'CustInvoiceJour' tablosundaki 'InvoiceId' alanında bulunur. İşlem türü 'Credit note' olan kayıt, iade siparişiyle ilişkilendirilebilir. Örnekler CN-10056CN-10057CN-10058 | |||
| Bitiş zamanı EndTime | Belirli bir etkinliğin ne zaman tamamlandığını gösteren zaman damgası. | ||
| Açıklama Bitiş zamanı, bir etkinliğin tamamlandığı zaman damgasını gösterir. StartTime başlangıcı, EndTime ise bitişi belirtir. Böylece ilgili görevin işlem süresi hesaplanabilir. Bu öznitelik, özellikle 'Ürün incelemesi' gibi süresi ölçülebilen görevlerin ayrıntılı performans analizinde önemlidir. Analistler StartTime ve EndTime değerlerini karşılaştırarak görevlerin etkin işlem süresini hassas biçimde ölçebilir ve bunu görevler arasındaki bekleme süresinden ayırabilir. Böylece yalnızca görevler arasındaki değil, belirli etkinliklerin içindeki verimsizlikler de belirlenebilir. Neden önemli? Her bir etkinliğin etkin işlem süresini hesaplamayı sağlar. Böylece bekleme süresiyle fiilî çalışma süresini birbirinden ayırabilirsiniz. Nereden alınır? Bu değerin çoğu zaman türetilmesi gerekir. Örneğin, etkinliği tamamlayan durum değişikliğinin 'modifiedDateTime' değeri veya sonraki etkinliğin StartTime değeri kullanılabilir. Örnekler 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| Depo kimliği WarehouseId | İade edilen ürünün teslim alındığı depo veya konumun kimliğidir. | ||
| Açıklama Bu öznitelik, iade edilen ürünü işleyen fiziksel depoyu veya iade merkezini belirtir. Farklı konumlarda farklı süreçler, kaynaklar veya performans düzeyleri olabilir. Süreci depo bazında analiz etmek, konumların performansını karşılaştırmaya yardımcı olur. Hangi tesislerin iadeleri daha verimli işlediğini belirleyebilir, bölgesel darboğazları ortaya çıkarabilir ve lojistik ağı genelinde kaynak dağılımı ile süreç standardizasyonuna ilişkin kararları destekleyebilir. Neden önemli? Depoların veya iade merkezlerinin performansını karşılaştırarak bölgesel darboğazları ve iyi uygulamaları belirlemenizi sağlar. Nereden alınır? Bu bilgi, Varış Günlüğü ('WMSJournalTable') gibi envanterle ilgili işlemlerdeki 'InventLocationId' alanında veya 'SalesLine' tablosunda tutulur. Örnekler WH-EASTWH-WESTCENTRAL-DC | |||
| Fiilî iade tutarı ActualRefundAmount | Müşteriye ödenen nihai iade tutarıdır. | ||
| Açıklama Bu öznitelik, müşteriye iade edilen kesinleşmiş nihai tutarı gösterir. Değer, alacak dekontu oluşturulup kaydedildiğinde sisteme işlenir. Bu öznitelik mali analizler için önemlidir; 'İade tutarı farkı analizi' Dashboardunda ve 'İade tutarı doğruluk oranı' KPI’ında doğrudan kullanılır. Verilerin analizi, iadelerin mali etkisini ve süreç sırasında yapılan düzeltmeleri anlamaya yardımcı olur. Neden önemli? İadenin fiilî mali etkisini gösterir. İade tutarının doğruluğunu hesaplamak ve mali sonuçları anlamak için gereklidir. Nereden alınır? Bu değer, kaydedilmiş alacak dekontu işlem ayrıntılarında bulunabilir. Alacak dekontuna ait 'CustTrans' ve 'CustInvoiceJour' tablolarıyla ilişkilidir. Örnekler 99.99135.000.00 | |||
| İade siparişi durumu ReturnOrderStatus | Olay gerçekleştiği sırada iade siparişinin genel durumudur. | ||
| Açıklama Bu öznitelik, iade siparişi başlığının mevcut durumunu belirtir. Örneğin 'Açık', 'Faturalandı' veya 'İptal edildi'. Vakanın yaşam döngüsündeki konumunu genel hatlarıyla gösterir. Etkinlikler süreç adımlarını ayrıntılı biçimde gösterirken genel durum, vakaları filtrelemek ve gruplandırmak için kullanışlıdır. Örneğin bir analist mevcut iş yükünü anlamak için yalnızca 'Açık' vakalara odaklanabilir veya sonunda 'İptal edilen' vakaların süreç akışını inceleyebilir. Neden önemli? Vakanın durumunu genel hatlarıyla özetler. Vakaları filtrelemeyi ve iptal gibi sonuçları anlamayı kolaylaştırır. Nereden alınır? Bu bilgi, 'SalesTable' tablosundaki 'SalesStatus' veya 'DocumentStatus' alanında bulunur. Örnekler Açık siparişTeslim edildiFaturalandıİptal edildi | |||
| İade SLA hedef tarihi RefundSlaTargetDate | İade vakasının tamamen çözüme kavuşturulması gereken hedef tarihtir. | ||
| Açıklama Bu öznitelik, iade vakasının çözüme kavuşturulması için geçerli Hizmet Seviyesi Anlaşması (SLA) son tarihini belirtir. Müşterinin, örneğin iadenin kaydedilmesi veya yeni ürünün gönderilmesi gibi nihai bir çözüm almasının beklendiği tarihtir. Hizmet taahhütlerine göre performansı izlemek için bu hedef tarih önemlidir. 'Çözüm SLA uyum oranı' KPI’ını hesaplamak ve 'İade çözüm SLA performansı' Dashboardunu oluşturmak için kullanılır. İşletme, bu tarihi sürecin fiilî tamamlanma tarihiyle karşılaştırarak SLA ihlallerini belirleyebilir ve bekleyen vakaları zamanında yönetebilir. Neden önemli? Süreç performansını ölçmek için bir referans noktası sağlar. Böylece SLA uyumunu izleyebilir ve geciken vakaları belirleyebilirsiniz. Nereden alınır? Bu, standart bir alan olmayabilir. Genellikle iadenin oluşturulma tarihine önceden belirlenmiş SLA süresi eklenerek hesaplanır (ör. 14 gün). Özel bir alanda tutuluyor olabilir. Örnekler 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
| İade türü ReturnType | İadeyi, beklenen sonuca göre sınıflandırır. Örneğin para iadesi veya ürün değişimi. | ||
| Açıklama Bu öznitelik, iade vakasını müşterinin talep ettiği veya işletmenin sunduğu çözüm türüne göre sınıflandırır. Yaygın türler arasında para iadesi, ürün değişimi veya onarım bulunur. Bu sınıflandırma, farklı süreç yollarını analiz etmeye yardımcı olur. Para iadesi süreci, yeni bir ürünün gönderilmesi sürecinden oldukça farklıdır. İade türüne göre gruplandırma, her çözüm yolunun çevrim sürelerini ve darboğazlarını daha doğru analiz etmenizi sağlar. Neden önemli? Para iadesi ve ürün değişimi süreçlerinin adımları ile çevrim süreleri farklı olduğundan, analizi hedeflenen sonuca göre gruplandırmanızı sağlar. Nereden alınır? Bu, iade siparişi başlığındaki özel bir alan olabilir veya tasfiye koduna ya da yeni bir satış siparişi oluşturulması gibi sonraki işlemlere göre belirlenebilir. Örnekler Para iadesiÜrün değişimiMağaza kredisi | |||
| Kaynak sistem SourceSystem | Olay verilerinin çıkarıldığı bilgi sistemi. | ||
| Açıklama Bu öznitelik, verilerin geldiği kaynak bilgi sistemini tanımlar. Bu süreçte kaynak sistem çoğunlukla 'Microsoft Dynamics 365' olacaktır. Büyük kuruluşlarda bir süreç birden fazla sistemi kapsayabilir. Her olay için kaynak sistemi belirtmek; veri yönetişimi, veri çıkarma sorunlarını giderme ve sürecin kullandığı teknolojileri anlama açısından önemlidir. Ayrıca analiz edilen verilerin nereden geldiğini doğrular. Neden önemli? Verilerin kaynağı hakkında önemli bağlam bilgisi sunar. Bu bilgi, veri yönetişimi ve doğrulama için, ayrıca sürecin kullandığı sistemleri anlamak için gereklidir. Nereden alınır? Bu genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde Veri Setinin kaynağını belirtmek için eklenen sabit bir değerdir. Örnekler Microsoft Dynamics 365 F&OD365-PROD | |||
| Müşteri kimliği CustomerId | İade talebini başlatan müşteriyi tanımlayan benzersiz kimliktir. | ||
| Açıklama Müşteri kimliği, iadeyle ilişkili müşteri hesabını tanımlayan benzersiz kimliktir. İade işlemini CRM veya müşteri veri tabanındaki belirli bir müşteriyle ilişkilendirir. İadeleri müşteri bazında analiz etmek, olağandışı sıklıkta iade yapan müşterileri belirlemeye yardımcı olur. Bu durum dolandırıcılığa veya sürekli memnuniyetsizliğe işaret edebilir. Ayrıca müşterileri gruplandırmak ve örneğin yüksek değerli müşterilere ayrıcalıklı iade hizmetleri sunmak için de kullanılabilir. Neden önemli? İade sürecini belirli bir müşteriyle ilişkilendirerek müşteri bazında analiz yapmanızı, iade örüntülerini ve olası dolandırıcılıkları belirlemenizi sağlar. Nereden alınır? İade siparişinin 'SalesTable' tablosundaki 'CustAccount' alanıdır. Örnekler CUST-00045CUST-00192CUST-00315 | |||
| Politikaya uygun mu IsPolicyAdherent | İade onayının belirlenen iade politikalarına uygun olup olmadığını gösteren bir işarettir. | ||
| Açıklama Bu, iadenin şirket politikasında tanımlanan tüm ölçütleri karşılayıp karşılamadığını gösteren hesaplanmış bir mantıksal özniteliktir. İade süresi, ürünün durumu veya iade nedeni gibi etkenlere dayanabilir. Bu öznitelik, 'İade onayı uyumluluk özeti' Dashboardunu ve 'Uyumlu iade onayı oranı' KPI’ını doğrudan destekler. İşletmenin politika uyumunu ölçmesine, istisna olarak onaylanan vakaları belirlemesine ve bu istisnaların nedenlerini ve sıklığını analiz etmesine yardımcı olur. Yönetişim ve maliyet kontrolü açısından önemlidir. Neden önemli? İş kurallarına uyumu doğrudan ölçer. Gelir kaybına yol açabilecek, kurallara uymayan iade onaylarını belirlemeye ve azaltmaya yardımcı olur. Nereden alınır? Bu, türetilmiş bir özniteliktir. İade bilgileri (ör. iade tarihi ile satın alma tarihi, iade nedeni) önceden tanımlanmış iş kurallarıyla karşılaştırılarak hesaplanması gerekir. Örnekler truefalse | |||
| SLA durumu SlaStatus | Vakanın Hizmet Seviyesi Anlaşması hedef süresi içinde çözüme kavuşturulup kavuşturulmadığını gösterir. | ||
| Açıklama Bu hesaplanmış öznitelik, SLA uyumunu genellikle 'Zamanında' veya 'Gecikti' olarak gösterir. Son etkinliğin (ör. 'İade siparişi kapatıldı') zaman damgası, 'RefundSlaTargetDate' ile karşılaştırılarak belirlenir. Bu öznitelik, 'İade çözüm SLA performansı' gibi Dashboardlarda performans raporlamasını kolaylaştırır. Kullanıcıların tarihleri karşılaştırması gerekmez; durum doğrudan ve kolay anlaşılır biçimde gösterilir. Böylece 'Çözüm SLA uyum oranı' hızlıca filtrelenip hesaplanabilir. Neden önemli? SLA uyumunu tek bakışta gösterir. Geciken vakaları filtrelemeyi ve gecikmelerin temel nedenlerini analiz etmeyi kolaylaştırır. Nereden alınır? Bu, son çözüm etkinliğinin zaman damgası 'RefundSlaTargetDate' özniteliğiyle karşılaştırılarak hesaplanan türetilmiş bir özniteliktir. Örnekler ZamanındaGecikti | |||
| Son veri güncellemesi LastDataUpdate | Süreç verilerinin en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, verilerin kaynak sistemden en son çıkarıldığı ve Process Mining aracında güncellendiği tarih ve saati kaydeder. Analiz edilen verilerin ne kadar güncel olduğunu gösterir. Son veri güncellemesinin zamanını bilmek, analizin güncelliğini anlamak açısından önemlidir. Kullanıcıların Dashboardları ve temel performans göstergelerini (KPI) doğru yorumlamasına yardımcı olur; böylece gerçek zamanlı verilere mi yoksa belirli bir andaki görüntüye mi baktıklarını bilirler. Bu bilgi, operasyonel izleme için önemlidir. Neden önemli? Verilerin güncelliğini göstererek analistlerin süreç içgörülerinin ne kadar güncel olduğunu anlamasını sağlar. Nereden alınır? Bu, veri alım hattında oluşturulup saklanan bir meta veri özniteliğidir ve genellikle ETL işinin tamamlandığı zaman damgasını gösterir. Örnekler 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Talep edilen iade tutarı RequestedRefundAmount | Müşterinin talep ettiği toplam iade tutarıdır. | ||
| Açıklama Bu öznitelik, iade sürecinin başında talep edilen veya beklenen ilk iade tutarını gösterir. Genellikle iade edilen ürünlerin ilk satın alma fiyatına dayanır. Bu değer, 'İade tutarı farkı analizi' için başlangıç noktasıdır. İşletme, talep edilen tutarı fiilen iade edilen tutarla karşılaştırarak yeniden stoklama ücretlerinden, hasarlı ürünler için yapılan kısmi iadelerden veya diğer düzeltmelerden kaynaklanan farkları belirleyebilir. Böylece mali kayıtların doğruluğu ve politikalara uyum izlenebilir. Neden önemli? Fiilen işlenen iade tutarıyla karşılaştırma yapmak ve mali kayıtların doğruluğunu ölçmek için başlangıç noktası sağlar. Nereden alınır? Bu değer genellikle iade edilen ürünün ilk satış siparişi satırındaki satır tutarı veya toplam tutardır. 'SalesLine.LineAmount' alanında bulunur. Örnekler 99.99150.0024.50 | |||
İade ve geri ödeme süreçlerindeki etkinlikler
| Aktivite | Açıklama | ||
|---|---|---|---|
| Alacak dekontu kaydedildi | Alacak dekontu mali defterlere resmen kaydedilir ve kredi müşterinin kullanımına açılır. Bu, şirket açısından geri ödeme işleminin tamamlandığını gösterir. | ||
| Neden önemli? Bu önemli mali aşama, geri ödemenin sistemde işlendiğini doğrular. Geri ödeme SLA uyumluluğunu ölçerken genellikle temel etkinliklerden biridir. Nereden alınır? Alacak dekontunu kesinleştiren iade siparişi fatura günlüğünün kayıt zaman damgası. İade siparişinin durumu 'Invoiced' olarak değişir. Kaydedin İade siparişinin fatura günlüğünün kaydedilmesi. Olay türü explicit | |||
| İade siparişi kapatıldı | İade siparişi son durumuna ulaşmıştır; fiziksel ve mali işlemlerin tümü tamamlanmıştır. Bu genellikle alacak dekontu kaydedildikten veya yedek ürün gönderildikten sonra gerçekleşir. | ||
| Neden önemli? Bu, başarıyla tamamlanan iade sürecinin temel bitiş olayıdır. Siparişin oluşturulmasından bu noktaya kadar geçen süre, toplam vaka çevrim süresini gösterir. Nereden alınır? ReturnOrder durum alanının 'Invoiced' veya 'Closed' gibi son bir değere değişmesinden anlaşılır. Bu, başka bir işlem beklenmediğini gösterir. Kaydedin SalesTable.Status veya SalesTable.DocumentStatus alanının son duruma geçmesi. Olay türü inferred | |||
| İade siparişi oluşturuldu | Bu etkinlik, iade sürecinin başladığını gösterir. Sistemde bir İade Malzeme Yetkilendirmesi (RMA) veya iade siparişi oluşturulur. Dynamics 365’te yeni bir ReturnOrder kaydı oluşturulduğunda bu olay açıkça kaydedilir. | ||
| Neden önemli? Bu, tüm iade sürecinin temel başlangıç olayıdır. Bu etkinlikten diğerlerine kadar geçen süreyi incelemek, toplam süreç süresini görmenize ve ilk aşamalardaki darboğazları belirlemenize yardımcı olur. Nereden alınır? Bu olay, ReturnOrder başlığının oluşturulma zaman damgasından alınır. Genellikle SalesType alanının 'Returned Order' olduğu SalesTable tablosunda bulunur. Kaydedin SalesType = 'Returned Order' olan SalesTable kaydının oluşturulma olayı. Olay türü explicit | |||
| Sonuç kodu uygulandı | Bu etkinlik, incelemenin tamamlandığını ve iade edilen ürün hakkında karar verildiğini gösterir. İade satırına 'Credit', 'Scrap' veya 'Replace' gibi bir sonuç kodu atanır. | ||
| Neden önemli? Bu önemli karar noktası, sonraki süreç yolunu belirler: geri ödeme, değişim veya talebin reddedilmesi. Buradaki gecikmeler, çözüm için gereken toplam süreyi önemli ölçüde etkileyebilir. Nereden alınır? Bu olay, iade siparişi satırının stok hareketinde veya ilişkili günlüğünde DispositionCode alanı doldurulduğunda kaydedilir. Kaydedin İade siparişi satırına DispositionCode atandığında gerçekleşen güncelleme olayı. Olay türü explicit | |||
| Ürün teslim alındı | İade edilen ürünün depoda veya belirlenen iade merkezinde fiziksel olarak teslim alındığını gösterir. İade siparişiyle ilişkili varış günlüğü kaydedildiğinde bu olay oluşur. | ||
| Neden önemli? Bu önemli aşama, süreci müşteri eyleminden kurum içi işleme geçirir. İnceleme ve sonuç belirleme gibi tüm kurum içi işlem sürelerinin hesaplanması bu noktada başlar. Nereden alınır? ReturnOrder satırıyla ilişkili WMS Journal veya Item Arrival Journal kaydının zaman damgası. Bu işlem, stok hareketlerinin durumunu 'Registered' veya 'Received' olarak günceller. Kaydedin İade siparişi satırına bağlı Item Arrival Journal kaydının işlenmesi. Olay türü explicit | |||
| Alacak dekontu oluşturuldu | 'Credit' sonuç kodu verildiğinde alacak dekontu oluşturulur ve müşteriye geri ödeme yapılmasına onay verilir. Bu, sürecin mali mutabakat aşamasının resmen başladığını gösterir. | ||
| Neden önemli? Bu etkinlik, mali geri ödemenin onaylandığını gösterir. Sonuç kodunun belirlenmesiyle alacak dekontunun oluşturulması arasındaki süre, geri ödemenin başlatılmasındaki idari gecikmeleri ortaya çıkarır. Nereden alınır? Bu olay, özgün iade siparişine bağlı, negatif değerli yeni bir SalesTable kaydının oluşturulmasından veya 'Create credit note' toplu işinin çalıştırılmasından anlaşılabilir. Kaydedin Genellikle iade siparişi faturasının kaydedilmesiyle alacak dekontunun oluşturulması. Olay türü explicit | |||
| İade siparişi iptal edildi | İade siparişi tamamlanmadan önce iptal edilir. Müşteri talebi veya ürünün hiç iade edilmemiş olması iptal nedeni olabilir. | ||
| Neden önemli? Bu, sürecin alternatif ve başarısız bir şekilde sona erdiğini gösterir. İadelerin neden iptal edildiğini incelemek, müşteri davranışları veya süreçteki aksaklıklar hakkında bilgi sağlayabilir. Nereden alınır? ReturnOrder durum alanının 'Cancelled' olarak değişmesinden anlaşılır. Bu, başarıyla kapatılan siparişten farklı bir son durumdur. Kaydedin SalesTable.Status alanının 'Cancelled' olarak değişmesi. Olay türü inferred | |||
| İade siparişi onaylandı | İade siparişinin sistemde resmen onaylandığını ve çoğu zaman sonraki işlemleri başlattığını gösterir. Genellikle ReturnOrder başlığında açık bir işlem veya durum değişikliği olarak kaydedilir. | ||
| Neden önemli? Lojistik işlemler başlamadan önce onay verilmesi gerekir. Siparişin oluşturulmasıyla onaylanması arasındaki gecikmeler, idari veya sistem kaynaklı birikmelere işaret edebilir. Nereden alınır? Bu olay, iade siparişi için 'Confirmation' günlüğü kaydedildiğinde veya SalesTable tablosundaki DocumentStatus alanı değiştiğinde belirlenebilir. Kaydedin İade siparişi için 'Confirm sales order' işlevinin çalıştırılması. Olay türü explicit | |||
| Kalite siparişi oluşturuldu | İade edilen ürünün planlı bir inceleme sürecinden geçmesi gerektiğini gösteren resmî bir kalite siparişi oluşturulur. Bu işlem, iadelerin ayrıntılı test veya kalite standardı kontrolleri gerektirdiği durumlarda yaygındır. | ||
| Neden önemli? Bu etkinlik, resmî inceleme sürecinin başladığını gösterir. Bu noktadan itibaren geçen süreyi izlemek, kalite kontrol iş akışının verimliliğini ve süresini ölçmeye yardımcı olur. Nereden alınır? İade siparişine bağlı InventQualityOrderTable kaydının oluşturulma zaman damgası. Kaydedin InventQualityOrderTable kaydının oluşturulması. Olay türü explicit | |||
| Varış günlüğü oluşturuldu | Bu etkinlik, deponun iade edilen ürünün gelişini beklediğini gösterir. Varış günlüğü oluşturularak malların fiziksel teslim alınması için sistem hazırlanır. | ||
| Neden önemli? Bu adım, lojistik hazırlığı ürünün fiziksel olarak teslim alınmasından ayırır. Depo hazırlığını ve gelecek iadelerin planlanmasını incelemeye yardımcı olur. Nereden alınır? JournalType değeri 'Arrival' olan bir WMSJournalTable kaydı oluşturulur. Günlük, iade siparişi satırına bağlanır. Kaydedin İadeye ait WMSJournalTable kaydının oluşturulma zaman damgası. Olay türü explicit | |||
| Yedek ürün gönderildi | Yedek ürünün sevk irsaliyesi kaydedilir ve ürünün müşteriye gönderildiği belirtilir. Bu, değişim siparişinin yerine getirilmesinin tamamlandığını gösterir. | ||
| Neden önemli? Bu, değişim akışındaki önemli bir aşamadır ve şirketin müşteriye karşı yükümlülüğünü yerine getirdiğini gösterir. Değişim çevrim sürelerini izlemek için bu aşama önemlidir. Nereden alınır? Yedek ürün satış siparişine ait sevk irsaliyesi günlüğünün kayıt tarihi. Bu işlem, sipariş durumunu 'Delivered' olarak günceller. Kaydedin Yedek ürün satış siparişinin sevk irsaliyesinin kaydedilmesi. Olay türü explicit | |||
| Yeni ürün siparişi oluşturuldu | Müşteriye yedek ürün göndermek için yeni bir satış siparişi oluşturulur. Bu etkinlik, sonuç kodu 'Replace and Credit' veya 'Replace and Scrap' olduğunda gerçekleşir. | ||
| Neden önemli? Bu etkinlik, değişim sürecinin ilgili akışını başlatır. Değişimlerin karmaşıklığını ve maliyetini anlamak için bu yolu geri ödeme akışından ayrı izlemek gerekir. Nereden alınır? Yedek ürün için yeni bir SalesTable kaydı oluşturulur. Bu kayıt genellikle otomatik oluşturulur ve özgün iade siparişine bağlanır. Kaydedin Sonuç kodu işlemi aracılığıyla iade siparişine bağlanan yeni bir satış siparişinin oluşturulması. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşul: Azure Active Directory’de uygulama kaydı oluşturun. Dynamics 365 API’sine bağlanmadan önce Azure AD kiracınızda bir uygulama kaydetmeniz gerekir. Bu uygulamaya Dynamics 365 Finance & Operations verilerine erişmek için devredilmiş izinler verin; örneğin
Financials.ReadWrite.Allveya özel bir izin. - Dynamics 365’te uygulama kimliğini yapılandırın. Dynamics 365’te System administration > Setup > Azure Active Directory applications bölümüne gidin. Azure AD’de kaydettiğiniz uygulamanın Application (client) ID değerini ekleyin ve gerekli veri varlıklarını okuyabilecek güvenlik rollerine sahip bir kullanıcı hesabıyla ilişkilendirin.
- OAuth 2.0 erişim belirteci alın. Microsoft kimlik platformu uç noktasında kimlik doğrulaması yapmak için PowerShell veya Python gibi bir dilde betik yazın. Dynamics 365 kaynak URL’si için erişim belirteci istemek üzere uygulama kimlik bilgilerini (client ID ve secret) kullanın.
- Dynamics 365 ortamınızın URL’sini bulun. Dynamics 365 ortamınızın temel URL’sini belirleyin. Web API uç noktası genellikle şu biçimdedir:
https://[YourD365FinanceAndOpsURL].dynamics.com/data. - OData API isteklerini oluşturup çalıştırın. Gerekli 12 etkinliğin her biri için ayrı bir OData GET isteği URL’si oluşturun. Yalnızca gerekli sütunları almak için
$select, tarih aralığını ve durum koşullarını belirtmek için$filterkullanın. 3. adımda aldığınız kimlik doğrulama belirtecini her isteğin yetkilendirme başlığına Bearer token olarak ekleyin. - Veri çıkarma betiği geliştirin. OData istekleri listesini sırayla çalıştıran bir betik oluşturun. Betik kimlik doğrulamayı yönetmeli, her GET isteğini göndermeli ve dönen JSON verilerini kaydetmelidir. API sınırlarını göz önünde bulundurun ve gerekirse istekler arasında bekleme ekleyin.
- API sayfalandırmasını yönetin. Dynamics 365, büyük sonuçları sayfalara böler. Betiğiniz yanıtta
@odata.nextLinközelliğini kontrol etmelidir. Bu özellik varsa, sonraki veri sayfasını almak için belirtilen URL’ye yeni bir istek gönderin.nextLinkdönmeyene kadar devam edin. - Verileri dönüştürüp birleştirin. 12 API çağrısının her birinden gelen JSON yanıtını işleyin. Her etkinlik için
ReturnCaseId,ActivityName,EventTimeve diğer öznitelikleri içeren standart bir kayıt oluşturun. Örneğin, 'İade Siparişi Oluşturuldu' olayı içinReturnOrderNumberdeğeriniReturnCaseIdalanına, 'İade Siparişi Oluşturuldu' değeriniActivityNamealanına,createdDateTimedeğerini deEventTimealanına eşleyin. Dönüştürülen kayıtları tek bir liste veya tabloda birleştirin. - Zaman damgalarını temizleyip standartlaştırın. Tüm
EventTimedeğerlerinin tutarlı bir biçimde, tercihenYYYY-MM-DDTHH:MM:SSZgibi UTC formatında olduğundan emin olun. Eksik veya geçersiz zaman damgaları içeren kayıtları gerektiği gibi işleyin. - Son Event Logu dışa aktarın. Tüm verileri toplayıp tek bir veri setinde birleştirdikten sonra CSV dosyasına aktarın. Sütun başlıklarının ProcessMind gereksinimleriyle eşleştiğinden emin olun:
ReturnCaseId,ActivityName,EventTime,ResponsibleUser,DispositionCodevb. Dosyanız artık yüklemeye hazır.
Yapılandırma
- API uç noktasının URL’si: Dynamics 365 Finance & Operations örneğinizin temel URL’si. Biçimi şöyledir:
https://[YourEnvironmentName].dynamics.com/data. - Azure AD uygulaması: Azure AD’de client ID ve secret değerlerine sahip bir uygulama kaydedilmelidir. Uygulamanın Dynamics 365 veri varlıklarına erişmek için API izinleri olmalıdır.
- Tarih aralığı filtresi: İlgili bir tarih alanında, örneğin
createdDateTimeveyamodifiedDateTimealanında OData$filterparametresini kullanarak her API çağrısına tarih aralığı filtresi ekleyin. Veri çıkarmayı yönetilebilir tutmak için genellikle son 3 ila 6 aylık verilerle başlamak uygundur. - Şirket filtresi: Belirli bir tüzel kişiliğe ait verileri çıkarmak için
cross-company=truesorgu parametresini ekleyin, ardındandataAreaIdalanında$filterkullanın. Örneğin:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'. - Sayfalandırma tercihi: Her sayfada döndürülen kayıt sayısını belirlemek için isteklerde
Prefer: odata.maxpagesize=[value]başlığını kullanın. Genellikle1000ile5000arasında bir değer seçilir. Böylece büyük veri varlıklarında API zaman aşımı riski azalır. - API istek sınırları: Dynamics 365 API hizmet koruma sınırlarını göz önünde bulundurun. Veri çıkarma betiği,
429 (Too Many Requests)yanıtlarını yönetmek için genellikle üstel bekleme veya bekleyip yeniden deneme mekanizması içermelidir.
Örnek sorgu graphql
/*
This is a conceptual guide representing multiple, distinct OData API calls.
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially,
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/
// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";
// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode
// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId
// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId
// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser
// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser
// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser Adımlar
- TDS uç noktasını etkinleştirin: Dynamics 365 Dataverse ortamınızda Tabular Data Stream (TDS) uç noktasının etkin olduğundan emin olun. Sistem yöneticisi bu özelliği Power Platform yönetim merkezinde Environment > Settings > Features bölümünden etkinleştirebilir.
- Ortam URL’sini bulun: Ortamınızın URL’sini bulun. Genellikle
yourorg.crm.dynamics.combiçimindedir. TDS uç noktasının sunucu adı, bu URL’ye 5558 bağlantı noktası eklenerek oluşturulur; örneğinyourorg.crm.dynamics.com,5558. - SQL istemcisiyle bağlanın: SQL Server Management Studio (SSMS) veya Azure Data Studio gibi TDS destekleyen bir SQL istemcisi kullanın.
- Kimlik doğrulama: Dataverse ortamında gerekli izinlere, genellikle System Administrator veya System Customizer rolüne sahip Azure Active Directory hesabınızla sunucuya bağlanın.
- Sorguyu hazırlayın: Bu belgenin
querybölümünde verilen SQL sorgusunun tamamını kopyalayıp SQL istemcinizde yeni bir sorgu penceresine yapıştırın. - Parametreleri ayarlayın: Sorgudaki yer tutucuları bulun. Veri çıkarma için istediğiniz tarih aralığıyla
'{StartDate}'ve'{EndDate}'değerlerini değiştirin; örneğin'2023-01-01've'2023-12-31'. Ayrıca durum kodları veya işlem kodları için yer tutucu değerleri Dynamics 365 yapılandırmanıza göre güncelleyin. - Sorguyu çalıştırın: Düzenlediğiniz sorguyu Dataverse veritabanında çalıştırın. Çalışma süresi, veri hacmine ve seçilen tarih aralığına göre değişir.
- Sonuçları inceleyin: Sorgu tamamlandığında dönen veri setinde beklenen sütunların bulunduğunu kontrol edin:
ReturnCaseId,ActivityName,EventTimeve önerilen öznitelikler. - Event Logu dışa aktarın: Sorgu sonuçlarını CSV dosyasına aktarın. Çoğu SQL istemcisinde sonuçları doğrudan dosyaya kaydetme özelliği bulunur. Dosyayı UTF-8 kodlamasıyla kaydedin.
- ProcessMind’e yükleyin: Dışa aktardığınız CSV dosyası artık ProcessMind’e yeni bir Event Log olarak yüklenip süreç analizi için kullanılabilir.
Yapılandırma
- Ön koşullar: İlgili Dataverse tablolarına (ör. SalesTable, SalesLine, CustInvoiceJour) en azından okuma erişimi olan bir kullanıcı hesabınız olmalıdır. İzinler genellikle System Administrator gibi güvenlik rolleriyle veya yeterli tablo izinlerine sahip özel bir rolle yönetilir.
- TDS uç noktası: Ortamda Dataverse TDS uç noktası etkin olmalıdır. Bu özellik, Dataverse veritabanında doğrudan salt okunur SQL sorguları çalıştırmanızı sağlar.
- Tarih aralığı: Sorguda
'{StartDate}'ve'{EndDate}'yer tutucuları bulunur. İlk analiz için, performans sorunlarına yol açmadan temsil edici bir veri seti elde etmek üzere 3 ila 6 aylık bir tarih aralığı önerilir. - Şirket filtresi: Sorgu, kullanıcının erişebildiği tüm tüzel kişiliklerde (şirketlerde) çalışır. Tek bir şirketi analiz etmek için
UNION ALLifadesinin her bölümündeDATAAREAIDalanına göre filtreleme yapan birWHEREkoşulunun açıklama işaretlerini kaldırıp koşulu ekleyin. Örneğin:AND st.DATAAREAID = '[YourCompanyID]'. - Özel mantık yer tutucuları: Sorguda işlem kodları için
[YourReplaceCode1]gibi yer tutucular ve değiştirme siparişlerini ilişkilendirmeye yönelik notlar bulunur. Bunları iş sürecinize ve Dynamics 365 kurulumunuza göre yapılandırmanız gerekir. - Performans: Büyük veri setlerinde TDS uç noktasına doğrudan gönderilen sorgular yavaş çalışabilir. Bağlantı analitik sorgular için optimize edilmiştir, ancak milyonlarca satırı kapsayan karmaşık birleştirmelerde zaman aşımı yaşanabilir. Dar bir tarih aralığı filtresi uygulamanız önerilir.
Örnek sorgu sql
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Created' AS ActivityName,
st.CREATEDDATETIME AS EventTime,
st.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Confirmed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Arrival Journal Created' AS ActivityName,
wjt.CREATEDDATETIME AS EventTime,
wjt.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Item Received' AS ActivityName,
wjt.POSTEDDATETIME AS EventTime,
wjt.POSTEDUSERID AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Quality Order Generated' AS ActivityName,
iqot.CREATEDDATETIME AS EventTime,
iqot.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Disposition Code Applied' AS ActivityName,
iqot.VALIDATEDDATETIME AS EventTime,
iqot.VALIDATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Created' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Posted' AS ActivityName,
cij.CREATEDDATETIME AS EventTime,
cij.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Order Created' AS ActivityName,
replacement_so.CREATEDDATETIME AS EventTime,
replacement_so.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Item Shipped' AS ActivityName,
cpsj.CREATEDDATETIME AS EventTime,
cpsj.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Closed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Cancelled' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'; Başlamaya hazır mısınız?
Veri toplama sürecinizi kolaylaştırmak ve iade ile geri ödeme sürecinizi iyileştirecek içgörüleri keşfetmeye başlamak için bu Templateten yararlanın. Daha hızlı işlem ve daha yüksek müşteri memnuniyeti için bugün ilk adımı atın.
İade ve geri ödeme gecikmelerini sona erdirin: Sürecinizi bugün iyileştirin
Çevrim süresini %30 azaltın, müşteri memnuniyetini artırın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.