Satın Almadan Ödemeye - Fatura İşleme Veri Template'iniz
Satın Almadan Ödemeye - Fatura İşleme Veri Template'iniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- `SAP S/4HANA` için Veri Çıkarma Kılavuzu
Satın Almadan Ödemeye - Fatura İşleme Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Fatura Numarası InvoiceNumber | Tedarikçi fatura belgesi için benzersiz tanımlayıcı, süreç için birincil vaka tanımlayıcısı olarak hizmet eder. | ||
| Açıklama Fatura Numarası, SAP S/4HANA'daki her tedarikçi faturasına atanan benzersiz tanımlayıcıdır. Oluşturma, park etme, onaylama ve ödeme gibi tüm ilgili faaliyetleri tek, tutarlı bir süreç örneğine bağlar. Process Mining'de, bu öznitelik her faturanın uçtan uca yolculuğunu izlemek için temeldir. Alımdan nihai ödemeye kadar tüm süreç akışının yeniden yapılandırılmasına olanak tanır, bireysel fatura düzeyinde döngü süreleri, darboğazlar ve süreç varyasyonlarının analizini sağlar. Neden önemli Tüm ilgili olayları bağlamak için temel anahtardır; bir faturanın sistemdeki yaşam döngüsünün tam bir izini sürmeyi mümkün kılar. Nereden alınır Bu, BKPF tablosundaki BELNR alanında bulunan Muhasebe Belge Numarasıdır. Örnekler 190000000119000000451900000132 | |||
| Faaliyet Adı ActivityName | Bir fatura için belirli bir zamanda gerçekleşen iş faaliyetinin veya olayın adı. | ||
| Açıklama Faaliyet Adı, fatura işleme yaşam döngüsü içindeki belirli bir adımı veya durum değişikliğini tanımlar. Örnekler arasında 'Fatura Belgesi Oluşturuldu', 'Fatura Onaya Gönderildi', 'Ödeme Blokesi Konuldu' ve 'Ödeme Gerçekleşti' yer alır. Bu öznitelik, faaliyet akışını görsel olarak temsil eden süreç haritasını oluşturmak için çok önemlidir. Bu faaliyetler arasındaki sırayı, sıklığı ve süreyi analiz etmek, darboğazları, yeniden işleme döngülerini ve uyumsuz süreç varyasyonlarını belirlemeye yardımcı olur. Herhangi bir Process Mining analizinin omurgasını oluşturur. Neden önemli Süreçteki adımları tanımlar; süreç haritalarının görselleştirilmesini ve süreç akışlarının ve varyasyonlarının analizini sağlar. Nereden alınır SAP işlem kodları (SY-TCODE), değişiklik belgesi nesne durumları (CDHDR/CDPOS) ve durum değişikliklerini gösteren belirli alan değerlerinin birleşiminden türetilir. Örnekler Fatura Park EdildiFatura OnaylandıÖdeme Gerçekleştirildi | |||
| Olay Zamanı EventTime | Aktivitenin meydana geldiği kesin tarih ve saat. | ||
| Açıklama Event Time, belirli bir etkinliğin tam olarak ne zaman gerçekleştiğini kaydeden zaman damgasıdır. Bu veri, süreçteki farklı adımlar arasındaki süreleri, döngü sürelerini ve bekleme sürelerini hesaplamak için elzemdir. Process Mining analizinde, doğru zaman damgaları 'Ortalama Fatura Döngü Süresi' ve 'Fatura Onay Döngü Süresi' gibi performans KPI'larını ölçmek için kullanılır. Etkinlikler arasında geçen süreyi analiz ederek, kuruluşlar faturaların geciktiği bottleneck'leri tespit edebilir ve süreç hızlandırma fırsatlarını belirleyebilir. Neden önemli Bu zaman damgası, performans izleme, darboğaz belirleme ve SLA takibi dahil olmak üzere tüm zaman tabanlı analizlerin temelidir. Nereden alınır Genellikle değişiklik belge tabloları CDHDR (Başlık) ve CDPOS'tan (Kalem), UDATE ve UTIME alanları kullanılarak elde edilir. Bazı olaylar için BKPF (CPUDT, CPUTM) gibi tablolardaki oluşturma veya giriş tarihlerinden gelebilir. Örnekler 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Belge Türü DocumentType | Satıcı faturaları veya alacak notları gibi farklı muhasebe belgesi türlerini sınıflandıran bir kod. | ||
| Açıklama Belge Tipi, SAP'de farklı iş işlemlerini ayırt etmek için kullanılır. Örneğin, 'KR' genellikle standart bir tedarikçi faturasını temsil ederken, 'KG' bir tedarikçi alacak dekontu olabilir. Belge tipine göre analiz yapmak, farklı işlem türlerinin nasıl ele alındığını anlamak için süreci bölümlere ayırmaya olanak tanır. Örneğin, bir alacak dekontunun süreci, standart bir faturanınkinden önemli ölçüde farklı olabilir. Bu bölümlendirme, daha doğru ve ilgili süreç içgörüleri sağlar. Neden önemli Standart faturalar ve alacak notları gibi, genellikle farklı süreç yollarını izleyen çeşitli finansal işlem türleri arasında ayrım yapmaya yardımcı olur. Nereden alınır Found in the document header table BKPF, field BLART. Örnekler KRREKG | |||
| Fatura Tutarı AmountInCompanyCodeCurrency | Faturanın şirket kodunun yerel para birimindeki toplam brüt tutarı. | ||
| Açıklama Bu öznitelik, faturanın toplam değerini temsil eder. Fatura işleme operasyonunun finansal etkisini ve ölçeğini anlamak için önemli bir ölçüttür. Fatura tutarlarını analiz etmek, yüksek değerli faturaları daha hızlı işlemek için önceliklendirmeye, harcama eğilimlerini belirlemeye ve süreç sorunlarını finansal değerle ilişkilendirmeye yardımcı olur. Örneğin, yüksek değerli faturaların engellenme olasılığının veya daha uzun onay sürelerinin olup olmadığını araştırmak için kullanılabilir. Neden önemli Sürece finansal bağlam sağlar; bu sayede yüksek değerli faturaların farklı işlenip işlenmediğini belirlemek gibi parasal değere dayalı analiz yapılmasına olanak tanır. Nereden alınır Bu değer, genellikle BSEG tablosundaki ilgili kalemlerin toplamından, WRBTR alanından (Yerel para birimindeki tutar) türetilir. Örnekler 1500.75125000.00850.20 | |||
| Kullanıcı Adı UserName | Faaliyeti gerçekleştiren kişi veya sistemin SAP kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, belirli bir işlemi gerçekleştiren veya belge oluşturan kullanıcıyı tanımlar. Bu, bir bireyin kullanıcı kimliği veya otomatik toplu işler için bir sistem kimliği olabilir. Kullanıcıya göre analiz yapmak, iş yükü dağılımını anlamaya, eğitim ihtiyaçlarını belirlemeye ve olağandışı kullanıcı davranışlarını tespit etmeye yardımcı olur. Örneğin, hangi kullanıcıların sık sık istisnaları işlediğini veya hangi faturaların otomatik olarak işlendiğini (örneğin, 'BATCHUSER' kullanıcısı) vurgulayabilir, bu da 'Fatura Otomasyon Oranı' KPI'ını hesaplamak için anahtardır. Neden önemli Süreç etkinliklerini belirli kullanıcılara veya sistem hesaplarına atar; iş yükü analizini, performans karşılaştırmasını ve otomasyon tespitini mümkün kılar. Nereden alınır BKPF-USNAM (Giren) veya CDHDR-USERNAME (Değiştiren) gibi alanlardan alınır. Örnekler SMITHJMUELLERTWF-BATCH | |||
| Ödeme Engeli Nedeni PaymentBlockReason | Bir faturanın neden ödeme blokajına alındığını gösteren bir kod. | ||
| Açıklama Bir fatura ödeme için bloke edildiğinde, bu öznitelik 'Miktar Tutarsızlığı' veya 'Fiyat Uyumsuzluğu' gibi bloke için belirli nedeni sağlar. Bu nedenler, istisna yönetimini standartlaştırmak için SAP'de yapılandırılmıştır. Bu öznitelik, 'Ödeme Blokesi Oluşumu ve Süresi' dashboard'u için çok önemlidir. Farklı bloke nedenlerinin sıklığını analiz etmek, belirli tedarikçiler, malzemeler veya iç süreçlerle ilgili sorunlar gibi ödeme gecikmelerinin temel nedenlerini belirlemeye yardımcı olur ve hedeflenen düzeltici eylemlere olanak tanır. Neden önemli Ödeme blokeleri için belirli temel nedeni sağlar, gecikmeleri azaltmak ve ilk seferde doğru işleme oranını iyileştirmek için hedeflenen analiz yapılmasını mümkün kılar. Nereden alınır BSEG tablosunun satıcı kaleminde, ZLSPR (Ödeme Blokaj Anahtarı) alanında bulunur. Örnekler RIA | |||
| Satın Alma Siparişi PurchasingDocument | Faturanın ilgili olduğu satın alma sipariş numarası. | ||
| Açıklama Satın Alma Belge numarası, tedarikçi faturasını orijinal satın alma siparişi (PO) ile ilişkilendirir. Bu bağlantı, faturayı PO ve mal alımı ile doğrulayan üç yönlü eşleştirme süreci için temeldir. Bu özniteliğe göre analiz yapmak, PO destekli ve PO'suz faturalarla ilgili sorunları anlamaya yardımcı olur. Eşleştirme tutarsızlıklarını araştırmak ve sürecin tedarik kısmının verimliliğini anlamak için anahtardır. Neden önemli Faturayı tedarik sürecine bağlar; bu da eşleşme tutarsızlıklarını ve Satın Alma Siparişi (PO) uyumluluğunu analiz etmek için elzemdir. Nereden alınır Bu bilgi genellikle belge segment tablosu BSEG'de, EBELN alanında (Satın Alma Belgesi Numarası) bulunur. Örnekler 450000123445000056784500009012 | |||
| Şirket Kodu CompanyCode | Finansal tabloların oluşturulduğu, yasal olarak bağımsız bir şirketi temsil eden organizasyonel birim. | ||
| Açıklama Şirket Kodu, SAP Finans'ta temel bir organizasyonel birimdir. Her fatura, işlemden sorumlu tüzel kişiliği belirleyen belirli bir şirket koduna atanır. Process Mining'de, Şirket Kodu'na göre filtreleme veya karşılaştırma, farklı iş birimleri, tüzel kişilikler veya ülkeler genelinde süreç performansını analiz etmek için temeldir. Verimlilik, uyumluluk ve otomasyon seviyelerindeki bölgesel farklılıkları belirlemeye yardımcı olur ve hedeflenen iyileştirme girişimlerini destekler. Neden önemli Kuruluş içindeki farklı tüzel kişilikler veya coğrafi konumlar arasında fatura işleme performansını segmentlere ayırmaya ve karşılaştırmaya olanak tanır. Nereden alınır Bu, belge başlık tablosu BKPF'deki standart bir alan, BUKRS alanıdır. Örnekler 1000US01DE01 | |||
| Son Ödeme Tarihi PaymentDueDate | Faturanın vadesi geçmeden ödenmesi gereken tarih. | ||
| Açıklama Ödeme Vade Tarihi, fatura tarihi ve anlaşılan ödeme koşullarına göre tedarikçiye ödemenin vadesinin geldiği hesaplanan tarihtir. Süreçte kritik bir son tarih olarak işlev görür. Bu öznitelik, 'Zamanında Ödeme Oranı' KPI'ı ve 'Tedarikçi Ödeme Performansı' dashboard'u için temeldir. Gerçek ödeme tarihini vade tarihiyle karşılaştırarak, bir şirket ödeme yükümlülüklerini karşılama yeteneğini ölçebilir, bu da tedarikçi ilişkilerini ve finansal itibarı etkiler. Neden önemli Zamanında ödeme performansını ölçmek için birincil ölçüttür; bu da iyi tedarikçi ilişkilerini sürdürmek ve gecikme ücretlerinden kaçınmak için hayati öneme sahiptir. Nereden alınır Bu tarih genellikle BSEG tablosundaki tedarikçi satır öğesinde, ZFBDT alanında (vade tarihi hesaplaması için temel tarih) doğrudan bulunur. Net vade tarihi, bu temel tarihten ve ödeme koşullarından hesaplanır. Örnekler 2023-05-302023-06-152023-07-01 | |||
| Tedarikçi Numarası VendorNumber | Faturayı gönderen tedarikçi için benzersiz tanımlayıcı. | ||
| Açıklama Tedarikçi Numarası, fatura ile ilişkili tedarikçiyi veya alacaklıyı tanımlar. Fatura işlemini tedarikçi ana verilerine bağlar. Bu öznitelik, 'Tedarikçi Ödeme Performansı'nı değerlendirmek veya istisnalara veya ödeme blokelerine yol açan sorunlu faturaları sık sık gönderen tedarikçileri belirlemek gibi tedarikçi merkezli analizler için kritik öneme sahiptir. Tedarikçi ilişkilerini yönetmeye ve tedarikçi güvenilirliğini değerlendirmeye yardımcı olur. Neden önemli Tedarikçiye göre süreç performansı analizini sağlar; modelleri belirlemeye, ilişkileri yönetmeye ve tedarikçiyle ilgili sorunları değerlendirmeye yardımcı olur. Nereden alınır Genellikle muhasebe belge segment tablosu BSEG'de, LIFNR alanında bulunur. Örnekler 100345700012V9832 | |||
| Çıkarma Zaman Damgası ExtractionTimestamp | Verinin kaynak sistemden çıkarıldığı tarih ve saat. | ||
| Açıklama Bu öznitelik, veri çıkarma olayının zaman damgasını kaydeder. Process Mining aracında analiz edilen verinin güncelliğini yansıtır. Analizde, üretilen içgörülerin güncelliğini anlamak için kullanılır. Kararların güncel bilgilere dayanmasını sağlamak ve veri yenileme döngülerini etkin bir şekilde yönetmek için operasyonel izleme dashboard'ları için kritiktir. Neden önemli Verinin güncelliğini gösterir; analiz ve raporlamanın mevcut en güncel bilgilere dayanmasını sağlar. Nereden alınır Bu bir SAP alanı değildir. Veri çekimi sırasında veri çıkarma aracı veya ETL süreci tarafından oluşturulur ve eklenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Fatura İşlem Süresi InvoiceProcessingTime | Bir fatura için ilk faaliyetten son faaliyete kadar geçen toplam süre. | ||
| Açıklama Bu metrik, genellikle fatura oluşturma veya alımından nihai ödemeye kadar tek bir faturayı işlemek için geçen toplam süreyi hesaplar. Uçtan uca döngü süresinin vaka düzeyinde bir özetini sunar. Bu hesaplanmış öznitelik, 'Ortalama Fatura Döngü Süresi' KPI'ı ve 'Uçtan Uca Fatura Döngü Süresi' dashboard'u için temeldir. En uzun süren vakaların hızlı bir şekilde belirlenmesine ve uzayan işleme sürelerine katkıda bulunan faktörlerin analizine olanak tanır. Neden önemli Her fatura için sürecin uçtan uca verimliliğini ölçer, özellikle uzun süren ve incelenmesi gereken vakaları öne çıkarır. Nereden alınır Her benzersiz Fatura Numarası için son etkinliğin zaman damgası ile ilk etkinliğin zaman damgası arasındaki fark alınarak hesaplanır. Örnekler 10 gün 4 saat25 gün 1 saat5 gün 8 saat | |||
| Fatura Tarihi InvoiceDate | Tedarikçinin fatura belgesini düzenlediği tarih. | ||
| Açıklama Fatura Tarihi, aynı zamanda belge tarihi olarak da bilinir, tedarikçi tarafından faturada belirtilen tarihtir. Anlaşılan ödeme koşullarına göre ödeme vade tarihini hesaplamak için başlangıç noktası olarak kullanılır. Analizde bu tarih, fatura yaşlandırmasını ve erken ödeme indirimleri için uygunluğu belirlemek gibi finansal hesaplamalar için temeldir. 'Erken Ödeme İskontosu Yakalama Oranı' KPI'ı için önemli bir girdidir. Neden önemli Ödeme koşulları ve vade tarihlerini hesaplamak için temel oluşturur; bu, işletme sermayesini yönetmek ve indirimleri yakalamak için hayati öneme sahiptir. Nereden alınır BKPF belge başlığı tablosunda, BLDAT (Belge Tarihi) alanında bulunur. Örnekler 2023-04-122023-05-152023-06-20 | |||
| Kaynak Sistem Kimliği SourceSystemId | Verinin çıkarıldığı kaynak SAP S/4HANA sisteminin tanımlayıcısı. | ||
| Açıklama Bu öznitelik, kaynak sistemi belirtir; örneğin, 'S4H_PROD' veya 'ERP_EU'. Birden fazla ERP örneği veya eski ve modern sistemlerin karışımı olan ortamlarda özellikle önemlidir. Analiz için, farklı sistemler veya bölgeler genelinde süreç performansını karşılaştırmaya olanak tanır. Veri kaynağını sağlar ve birden fazla kaynaktan gelen verilerin merkezi bir Process Mining platformunda birleştirildiğinde veri yönetişimi ve sorun giderme için çok önemlidir. Neden önemli Verinin kaynağı hakkında bağlam sağlar; bu da veri yönetişimi için ve farklı sistemler veya şirket lokasyonları arasındaki süreçleri karşılaştırmak için elzemdir. Nereden alınır Bu değer, genellikle veri çıkarma sırasında SAP sistem kimliğinden (sy-sysid) türetilir veya ETL hattında statik bir değer olarak yapılandırılır. Örnekler S4PS4H_PROD_100ECC_EU | |||
| Mahsup Belgesi No. ClearingDocumentNumber | Faturayı mahsup eden belge numarası, genellikle ödeme belgesini temsil eder. | ||
| Açıklama Mahsup Belge Numarası, açık bir fatura kalemini onu mahsup eden işlemle, yani neredeyse her zaman ödeme belgesiyle ilişkilendirir. Bu, faturanın ödendiğini doğrular. Bu öznitelik, bir fatura ile ödemesi arasındaki kesin bağlantıdır. 'Ödeme Gerçekleşti' faaliyetini ve buna karşılık gelen zaman damgasını belirlemek için kullanılır, bu da uçtan uca döngü süresini ve zamanında ödeme oranını hesaplamak için temeldir. Neden önemli Bir faturanın ödendiğini doğrular ve onu belirli ödeme işlemine bağlar; bu da döngü süresi ve ödeme performansı analizi için kritiktir. Nereden alınır BSEG belge kalemi tablosunda, AUGBL (Denkleştirme Belge Numarası) alanında bulunur. Örnekler 150000000115000000231500000088 | |||
| Ödeme Vadeleri PaymentTerms | Tedarikçiyle üzerinde anlaşılan ödeme koşullarını (vade tarihleri ve indirim dönemleri gibi) tanımlayan kod. | ||
| Açıklama Ödeme Koşulları, erken ödeme için mevcut indirimler de dahil olmak üzere bir faturanın ödenmesi için kuralları tanımlar. Örneğin, 'Z030' '30 gün içinde net ödenebilir' anlamına gelebilir. Bu öznitelik, finansal planlama ve işletme sermayesi optimizasyonu için hayati öneme sahiptir. Process Mining'de, 'Ödeme Vadesi Tarihi'ni hesaplamak ve erken ödeme indirimleri için uygunluğu belirlemek, doğrudan 'Erken Ödeme İskontosu Yakalama Oranı' KPI'ını desteklemek için kullanılır. Neden önemli Ödeme vadeleri ve indirimleri için kuralları tanımlar, zamanında ödeme KPI'larını ve işletme sermayesi yönetimini doğrudan etkiler. Nereden alınır BSEG tablosundaki satıcı kaleminde, ZTERM (Ödeme Koşulları Anahtarı) alanında bulunur. Örnekler 0001Z030NT60 | |||
| Onay Döngüsü Sayısı ApprovalCycleCount | Bir faturanın onay için kaç kez gönderildiğinin sayımı. | ||
| Açıklama Bu metrik, tek bir fatura için 'Fatura Onaya Gönderildi' faaliyetinin gerçekleşme sayısını sayar. Birden büyük bir sayı, faturanın en az bir kez reddedildiğini veya geri gönderildiğini, yeni bir onay döngüsü gerektirdiğini gösterir. Bu öznitelik, 'İlk Geçiş Onay Oranı' KPI'ını doğrudan destekler. Yüksek onay döngüsü sayısına sahip faturaları analiz ederek, kurumlar yetersiz bilgi veya yanlış kodlama gibi başarısız onayların nedenlerini belirleyebilir ve süreci iyileştirmek için adımlar atabilir. Neden önemli Onay alt sürecindeki yeniden işleme miktarını belirler, ilk seferde doğru oranını ölçmeye ve onay retlerinin nedenlerini belirlemeye yardımcı olur. Nereden alınır Her benzersiz Fatura Numarası için 'Onay İçin Fatura Gönderildi' etkinliğinin gerçekleşme sayıları sayılarak hesaplanır. Örnekler 123 | |||
| Otomatikleştirildi mi? IsAutomated | Bir etkinliğin otomatik bir sistem kullanıcısı tarafından gerçekleştirilip gerçekleştirilmediğini gösteren bir işaret. | ||
| Açıklama Bu boolean öznitelik, bir faaliyetle ilişkili kullanıcının 'WF-BATCH' veya 'SAP_SYSTEM' gibi bilinen bir sistem veya toplu iş hesabı olması durumunda doğrudur. Manuel ve otomatik süreç adımlarını ayırt etmeye yardımcı olur. Bu öznitelik, 'Fatura Otomasyon Oranı' KPI'ını hesaplamak için temeldir. Sürecin hangi bölümlerinin otomatikleştirildiğini analiz ederek, kurumlar otomasyon girişimlerinin başarısını ölçebilir ve manuel çabayı azaltmak ve verimliliği artırmak için daha fazla fırsat belirleyebilir. Neden önemli Manuel ve sistem odaklı etkinlikler arasında ayrım yapar; bu da otomasyon oranlarını ölçmek ve daha fazla otomasyon için fırsatları belirlemek açısından temeldir. Nereden alınır UserName niteliğinden türetilir. Belirli kullanıcı kimliklerini 'otomatik' olarak sınıflandırmak için bir eşleme veya kural oluşturulur. Örnekler truefalse | |||
| Ters Kayıt Nedeni ReversalReason | Bir fatura belgesinin neden iptal edildiğini gösteren bir kod. | ||
| Açıklama Bir fatura yanlış kaydedilirse, genellikle iptal edilir. İptal Nedeni kodu, bu eylemin neden yapıldığını açıklar; örneğin, 'Yanlış kayıt tarihi' veya 'Veri girişi hatası'. İptal nedenlerini analiz etmek, fatura kayıt sürecindeki hata modellerini belirlemeye yardımcı olur. Bu içgörü, eğitimi iyileştirmek, sistem kontrollerini güçlendirmek veya finansal yeniden işleme ve idari yüklemeye yol açan tekrar eden sorunları ve idari yüklemeye yol açan tekrar eden sorunları ele almak için kullanılabilir. Neden önemli Faturaların neden iptal edildiğini açıklar; kayıt sürecindeki hata ve yeniden işleme kaynaklarına doğrudan içgörü sağlar. Nereden alınır BKPF tablosundaki orijinal belgenin başlığında, STGRD (Ters Kayıt Nedeni) alanında bulunur. Örnekler 010205 | |||
| Yeniden İşleme mi? IsRework | Reddedilen bir onay veya kaldırılan bir ödeme engeli gibi yeniden işleme faaliyetlerine tabi tutulup tutulmadığını gösteren bir işaret. | ||
| Açıklama Bu öznitelik, bir veya daha fazla yeniden işleme döngüsü yaşamış faturaları işaretler. Yeniden işleme, belirli faaliyet dizileriyle tanımlanır; örneğin, 'Fatura Reddedildi' sonrası 'Fatura Onaylandı' veya 'Ödeme Blokesi Konuldu' sonrası 'Ödeme Blokesi Kaldırıldı'. Bu öznitelik, 'Fatura Yeniden İşleme Oranı' KPI'ının hesaplanmasını basitleştirir. Analistlerin, verimsizliğin ve tekrarlanan manuel çabanın temel nedenlerini anlamak için yeniden işleme olan vakaları kolayca izole etmesine ve incelemesine olanak tanır. Neden önemli İşin tekrarlanması gereken verimsiz süreç akışlarını belirler; israfı nicelleştirmeye ve süreç istisnalarının temel nedenlerini tespit etmeye yardımcı olur. Nereden alınır Event log'daki etkinliklerin sırasına göre hesaplanır. Örneğin, bir fatura izinde 'Fatura Reddedildi' etkinliği gerçekleşirse, bu işaret doğru olarak ayarlanır. Örnekler truefalse | |||
| Zamanında Ödendi mi IsPaidOnTime | Fatura ödeme vadesinde veya öncesinde ödendiyse doğru olan bir işaret. | ||
| Açıklama Bu boolean öznitelik, gerçek ödeme tarihi ('Ödeme Gerçekleşti' faaliyetinin zaman damgası) ile 'Ödeme Vade Tarihi'nin karşılaştırılmasının sonucudur. Her faturanın ödeme durumu için net, ikili bir sonuç sağlar. Bu, 'Zamanında Ödeme Oranı' KPI'ı için temel hesaplamadır. Gecikmelerle ilişkili yaygın tedarikçiler, şirket kodları veya fatura tutarları gibi geç ödemelerin özelliklerini anlamak için kolay filtreleme ve analiz yapılmasını sağlar. Neden önemli Ödeme şartlarına uyumu doğrudan ölçer; bu da tedarikçi ilişkileri yönetimi ve finansal operasyonlar için kritik bir KPI'dır. Nereden alınır 'Ödeme Gerçekleştirildi' etkinliğinin EventTime'ı ile PaymentDueDate özniteliği karşılaştırılarak hesaplanır. (Ödeme Tarihi <= Ödeme Vadesi). Örnekler truefalse | |||
Satın Almadan Ödemeye - Fatura İşleme Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura Belgesi Oluşturuldu | Bu, SAP'de bir fatura belgesinin oluşturulmasını işaret eden ilk olaydır. Bir kullanıcı, park edilmiş veya önceden kaydedilmiş bir durumda olabilecek yeni bir fatura belgesini kaydettiğinde yakalanabilir. | ||
| Neden önemli Bu faaliyet, fatura işleme yaşam döngüsünün başlangıcını işaret eder. Bu olaydan diğerlerine kadar geçen süreyi analiz etmek, genel işleme teslim süresini ölçmek için çok önemlidir. Nereden alınır Bu olay, belge başlık tablosundaki (genellikle lojistik faturalar için BKPF veya RBKP) oluşturma tarih ve saatinden (CPUDT, CPUTM) yakalanır. FB60, MIRO veya MIR7 gibi işlem kodu (BKPF-TCODE), oluşturma yöntemini gösterir. Yakala Fatura belgesi için BKPF-CPUDT ve BKPF-CPUTM'den oluşturma zaman damgasını kullanın. Event tipi explicit | |||
| Fatura Muhasebeleştirildi | Bu, park edilmiş veya onaylanmış faturanın Resmi Muhasebeye (Deftere) resmi olarak kaydedildiği önemli bir finansal olaydır. Bu eylem, tedarikçiye olan borcu tanır. | ||
| Neden önemli Deftere kaydetme, veri girişi ve onayı, finansal uzlaşma aşamasından ayıran önemli bir dönüm noktasıdır. Fatura oluşturmadan deftere kayda kadar geçen süre, dahili işleme verimliliğinin temel bir ölçütüdür. Nereden alınır Bu olay, belge başlığındaki Kayıt Tarihi (BKPF-BUDAT) ile belirlenir. Önce park edilen belgeler için, kaydedilen duruma geçiş olay zaman damgasını sağlar. Yakala Kayıt tarihini (BKPF-BUDAT) olay zaman damgası olarak kullanın. Event tipi explicit | |||
| Fatura Onaylandı | Bu faaliyet, faturanın belirlenen yetkili tarafından onaylandığını gösterir. Bu, onay iş akışı başarıyla tamamlandığında veya bir serbest bırakma göstergesi ayarlandığında kaydedilir. | ||
| Neden önemli Bu, faturayı ödeme için engelini kaldıran kritik bir dönüm noktasıdır. Onaylardaki gecikmeler yaygın bir darboğazdır ve bu faaliyeti takip etmek, yavaş onaycıları veya süreç adımlarını belirlemeye yardımcı olur. Nereden alınır Bu, bir SAP iş akışındaki son serbest bırakma adımından veya faturayla veya satın alma belgesiyle ilişkili tablolardaki serbest bırakma durumu alanlarındaki değişikliklerin izlenmesinden çıkarılabilir. Yakala Workflow tamamlanma olaylarından veya bir belgenin serbest bırakma durumu alanındaki değişikliklerden çıkarım yapın. Event tipi inferred | |||
| Fatura Ters Kaydedildi | Daha önce kaydedilmiş bir fatura belgesinin iptalini temsil eden bir etkinlik. Bu, hatalı bir fatura için son bir olaydır ve genellikle daha sonra doğru bir şekilde yeniden girilir. | ||
| Neden önemli Ters kayıtlar, sürecin erken aşamalarında yakalanmayan kritik hataları gösterir. Bunların sıklığını ve temel nedenlerini takip etmek, süreç iyileştirme ve finansal yanlışlıkları azaltma için temeldir. Nereden alınır Bir iptal belgesi oluşturulduğunda bir iptal işlemi belirlenir. Orijinal belge başlığı (BKPF), iptal belgesi numarasını (BKPF-STBLG) içerecektir ve bunun tersi de geçerlidir. İptal belgesinin kayıt tarihi etkinlik zamanıdır. Yakala BKPF-STBLG alanında değer olan belgeleri tanımlayın ve ters kayıt belgesinin kayıt tarihini kullanın. Event tipi explicit | |||
| Ödeme Gerçekleştirildi | Bu, standart süreçteki son faaliyettir; ödemenin yapıldığı ve faturanın mahsup edildiği aşamadır. Bu, fonların tedarikçiye ödendiğini gösterir. | ||
| Neden önemli Bu, Satın Almadan Ödemeye fatura yaşam döngüsünün sonunu işaret eder. Toplam uçtan uca döngü süresini hesaplamak ve vade tarihine göre zamanında ödeme performansını ölçmek için temeldir. Nereden alınır Bu olay, tedarikçi satır öğesindeki mahsup belge bilgilerinden yakalanır. Mahsup Tarihi (BSEG-AUGDT) ve Mahsup Belgesi (BSEG-AUGBL), ödemenin yapıldığını gösterir. Yakala Mahsup edilmiş tedarikçi satır öğesinden mahsup tarihini (BSEG-AUGDT) kullanın. Event tipi explicit | |||
| Fatura Park Edildi | Sisteme girilmiş ancak henüz genel muhasebeye kaydedilmemiş bir faturayı temsil eder. Park etme, eksik faturaları kaydetmek veya deftere kaydetmeden önce daha sonra incelemek için kullanılır. | ||
| Neden önemli Park etme, süreçte kasıtlı bir duraklamayı ifade eder. Park edilmiş faturaların süresini ve sıklığını takip etmek, resmi deftere işleme ve onay döngüsü başlamadan önce gecikmelerin nedenlerini belirlemeye yardımcı olur. Nereden alınır Bu, park etme işlemleri (örneğin, MIR7, FV60) aracılığıyla oluşturulan belgeler veya BKPF tablosundaki belirli durum alanları veya VBKPF gibi ayrılmış park edilmiş belge tabloları kontrol edilerek belirlenebilir. Yakala Park etme işlemleri aracılığıyla oluşturulan belgeleri belirleyin veya park edilmiş bir belge durumunu kontrol edin. Event tipi explicit | |||
| Fatura Reddedildi | Onay süreci sırasında bir faturanın reddedilmesini temsil eder. Bu olay yeniden işlemeyi tetikler, düzeltme ve yeniden gönderme gerektirir. | ||
| Neden önemli Fatura retleri, süreç verimsizliğinin ve veri kalitesi sorunlarının temel bir göstergesidir. Ret sıklığını ve nedenlerini analiz etmek, iyileştirme ve eğitim fırsatlarını belirlemeye yardımcı olur. Nereden alınır Bu, bir SAP iş akışındaki 'reddedildi' durumu gibi belirli durum güncellemelerinden veya mevcut onay iş akışını iptal eden, onu işlemciye geri gönderen olaylardan çıkarılır. Yakala Reddedilmeyi gösteren workflow durum değişikliklerinden çıkarım yapın. Event tipi inferred | |||
| Fatura Verisi Güncellendi | Bu faaliyet, fatura belgesinde ilk oluşturulduktan sonra yapılan bir değişikliği yansıtır. Bu durum, bir ret sonrasında yeniden işleme döngülerinde veya hataları düzeltmek için yaygındır. | ||
| Neden önemli Sık güncellemeler, yeniden işlemeyi ve giriş noktasında potansiyel veri kalitesi sorunlarını işaret eder. Bu değişiklikleri takip etmek, düzeltmeler için harcanan çabayı nicelleştirmeye ve yaygın hataları belirlemeye yardımcı olur. Nereden alınır Anahtar alanlardaki değişiklikler SAP'nin değişiklik belgesi tablolarında, CDHDR (başlık) ve CDPOS (kalem) olarak kaydedilir. İlgili fatura nesnesindeki değişiklikler filtrelenerek etkinlikler oluşturulabilir. Yakala CDHDR ve CDPOS tablolarından fatura nesnesi için değişiklik olaylarını çıkarın. Event tipi explicit | |||
| Geç Ödeme Gerçekleştirildi | Bu, bir faturanın ödemesi hesaplanan vade tarihinden sonra gerçekleştiğinde meydana gelen hesaplanmış bir olaydır. İki tarih alanının karşılaştırılmasıyla elde edilir. | ||
| Neden önemli Bu faaliyet, zamanında ödeme KPI'larını doğrudan destekler ve sık sık geç ödeme yapan tedarikçileri veya iş birimlerini belirlemeye yardımcı olur; bu da tedarikçi ilişkilerine zarar verebilir ve cezalara yol açabilir. Nereden alınır Bu, Mahsup Tarihi (BSEG-AUGDT) ile Net Vade Tarihi karşılaştırılarak hesaplanır. Vade tarihi ise Temel Tarih (BSEG-ZFBDT) ve ödeme koşullarından (BSEG-ZTERM) hesaplanır. Yakala Derive by comparing BSEG-AUGDT > (BSEG-ZFBDT + payment term days). Event tipi calculated | |||
| Ödeme Engeli Kaldırıldı | Bu, daha önce konulmuş bir ödeme blokesinin kaldırılmasıyla bir sorunun çözülmesini temsil eder. Böylece fatura tekrar ödeme için uygun hale gelir. | ||
| Neden önemli Bir blokenin konulması ile kaldırılması arasındaki süre, bir süreç istisnasının çözüm süresini temsil eder. Bu süreyi kısaltmak, verimliliği ve tedarikçi ilişkilerini iyileştirmek için anahtardır. Nereden alınır Bu olay, Ödeme Engelleme Anahtarı alanı (BSEG-ZLSPR) temizlendiğinde yakalanır. Bu değişiklik, CDHDR ve CDPOS tablolarına kaydedilir ve kaldırılma için bir zaman damgası sağlar. Yakala BSEG-ZLSPR alanının değişiklik belgeleri (CDHDR/CDPOS) aracılığıyla ne zaman temizlendiğini belirleyin. Event tipi explicit | |||
| Ödeme Engeli Konuldu | Bir faturaya kasıtlı olarak ödenmesini engellemek için engel konulan bir etkinlik. Bu genellikle fiyat veya miktar farklılıklarından veya bekleyen bir alacak notundan kaynaklanır. | ||
| Neden önemli Ödeme blokeleri, geç ödemelerin ve tedarikçi anlaşmazlıklarının temel nedenidir. Blokelerin sıklığını, süresini ve nedenlerini analiz etmek, zamanında ödeme oranlarını iyileştirmek için kritik öneme sahiptir. Nereden alınır Bu olay, fatura satır öğesindeki Ödeme Engelleme Anahtarı alanı (BSEG-ZLSPR) değişikliklerinin izlenmesiyle yakalanır. CDHDR ve CDPOS'taki değişiklik günlükleri, engellemenin ne zaman konulduğuna dair zaman damgası ve kullanıcı bilgisini sağlar. Yakala BSEG-ZLSPR alanının değişiklik belgeleri (CDHDR/CDPOS) aracılığıyla ne zaman doldurulduğunu belirleyin. Event tipi explicit | |||
| Ödeme Teklifi Oluşturuldu | Fatura, bir ödeme çalıştırmasının parçası olarak bir ödeme teklifine dahil edilir ve seçilir. Bu, otomatik ödeme sürecindeki ilk adımdır. | ||
| Neden önemli Bu faaliyet, ödeme niyetini gösterir. Bu adım ile nihai ödeme gerçekleştirme arasındaki gecikmeler, ödeme çalıştırma süreci, onaylar veya banka iletişimi ile ilgili sorunları ortaya çıkarabilir. Nereden alınır Bu, ödeme çalıştırma tablolarında, özellikle bir ödeme teklifine dahil edilen kalemleri içeren REGUP tablosunda bulunabilir. Karşılık gelen REGUH tablosundaki çalıştırma tarihi zaman damgasını sağlar. Yakala Faturanın bir ödeme önerisi çalışmasından sonra ne zaman REGUP tablosunda göründüğünü belirleyin. Event tipi explicit | |||
| Onay İçin Fatura Gönderildi | Bu faaliyet, fatura için resmi bir onay iş akışının başlatıldığını işaret eder. Bu durum genellikle faturanın durumu 'onay bekliyor' olarak değiştiğinde veya bir iş akışı öğesi oluşturulduğunda anlaşılır. | ||
| Neden önemli Bu, onay döngüsü süresini ölçmek için başlangıç noktasıdır. Onayların ne zaman başladığını anlamak, onay iş akışının kendisindeki darboğazları belirlemek için temeldir. Nereden alınır Bu, genellikle fatura nesnesine (örneğin, BUS2081) bağlı bir SAP İş Akışının (SWW_WI2OBJ tablosu) başlangıcından veya belge başlığındaki özel bir durum alanındaki değişiklikten çıkarılır. Yakala Fatura belgesiyle ilgili bir workflow öğesinin oluşturulmasından çıkarım yapın. Event tipi inferred | |||
Veri Çekim Kılavuzları
Adımlar
- Ön Koşullar ve Yetkilendirme: Dışa aktarımı gerçekleştiren kullanıcının, SAP S/4HANA'da gerekli Core Data Services (CDS) view'larına erişmek için gerekli yetkilere sahip olduğundan emin olun. Başlıca view'lar:
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemveI_PaymentProposalItem. Ayrıca kullanıcının, OData servisi veya doğrudan SQL bağlantısı gibi seçilen arayüz üzerinden sorgu yürütme izinlerine ihtiyacı olacaktır. - Bağlantı Yönteminizi Belirleyin: SQL sorgusunu yürütmek için SAP S/4HANA sistemine nasıl bağlanacağınızı belirleyin. Yaygın yöntemler arasında SAP Data Services, SAP Data Intelligence, SAP konektörü olan üçüncü taraf bir ETL aracı veya kuruluşunuzun güvenlik politikaları izin veriyorsa SAP HANA veritabanına doğrudan SQL bağlantısı yer alır.
- Dışa Aktarım Parametrelerini Tanımlayın: Sorguyu yürütmeden önce temel parametreleri belirleyin. Dışa aktarım için tarih aralığını belirtin (örneğin,
'YYYY-MM-DD've'YYYY-MM-DD'arasındakiCreationDate). Ayrıca veri kapsamını sınırlamak için dahil etmek istediğiniz belirliCompanyCodedeğerlerini tanımlayın. - SQL Sorgusunu Özelleştirin: Sağlanan SQL sorgusunu seçtiğiniz SQL istemcisine veya veri çıkarma aracına kopyalayın.
'{StartDate}','{EndDate}'ve('{CompanyCode1}', '{CompanyCode2}')gibi yer tutucuları dikkatlice inceleyin. Bu yer tutucuları önceki adımda tanımladığınız gerçek değerlerle değiştirin. Özel SAP yapılandırmanıza bağlı olarak workflow durumu için alan adlarını da ayarlamanız gerekebilir. - Sorguyu Yürütün: SQL sorgusunun tamamını SAP S/4HANA veritabanına karşı veya uygun servis katmanı üzerinden çalıştırın. Sorgu kapsamlı olacak şekilde tasarlanmıştır ve veri hacmine veya seçilen tarih aralığına bağlı olarak çalışması önemli bir zaman alabilir. Olası hatalar veya zaman aşımları için yürütme sürecini izleyin.
- İlk Sonuçları İnceleyin: Sorgu tamamlandığında çıktıya hızlıca göz atın.
InvoiceNumber,ActivityNameveEventTimesütunlarının dolu olduğunu kontrol edin.ActivityNamesütununda sadece 'Fatura Belgesi Oluşturuldu' değil, çeşitli aktiviteler gördüğünüzden emin olun. - Veri Dönüştürme İşlemleri: Sorgu, temiz bir event log formatı üretecek şekilde yapılandırılmıştır. Ancak
EventTimesütunununYYYY-MM-DDTHH:MM:SSgibi tutarlı bir zaman damgası formatında olduğundan emin olun. Sağlanan sorgu, gerektiğinde tarih ve saat alanlarını tek bir zaman damgasında birleştirir. - Veriyi Dışa Aktarın: Nihai sonuç kümesini aracınızdan bir CSV (Virgülle Ayrılmış Değerler) dosyasına aktarın. Bu format, ProcessMind dahil tüm Process Mining araçlarıyla evrensel olarak uyumludur.
- Yükleme Hazırlığı: Yüklemeden önce, karakter sorunlarını önlemek için CSV dosyasının UTF-8 kodlaması kullandığını onaylayın. Dosyadaki sütun başlıklarının gerekli niteliklerle tam olarak eşleştiğinden emin olun:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, vb. - ProcessMind'a Yükleyin: Hazırlanan CSV dosyasını Process Mining projenize yükleyin. Dosyanızdaki sütunları, aracın veri modeli yapılandırmasındaki ilgili case ID, aktivite adı ve zaman damgası alanlarıyla eşleştirin.
Konfigürasyon
- Kullanılan CDS View'lar: Birincil veri kaynakları standart SAP CDS view'larıdır. Ana view'lar şunlardır: Başlık verileri için
I_InvoiceDocument, mali kayıt ve denkleştirme detayları içinI_OperationalAcctgDocItem, ödeme blokajları ve workflow durumu gibi fatura niteliklerindeki geçmiş değişiklikleri takip etmek için iseI_ChangeDocumentveI_ChangeDocumentItem. - Tarih Aralığı Filtreleme: Performansı yönetmek için verileri belirli bir tarih aralığına göre filtrelemek kritik önem taşır. Sağlanan sorgu,
I_InvoiceDocumentview'ındakiCreationDatealanı için bir yer tutucu kullanır. Başlangıç noktası olarak 3 ila 6 aylık bir veri dönemi önerilir. - Şirket Kodu Filtresi: Veri çıkarımının ilgili ve yönetilebilir olmasını sağlamak için her zaman bir veya daha fazla
CompanyCode(Şirket Kodu) ile filtreleme yapın. Sorgu, bu amaçla kullanılan birWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')yer tutucusu içerir. - Belge Türü Filtresi:
InvoiceDocumentType(Fatura Belge Türü) üzerinden filtreleme yaparak kapsamı daha da daraltabilirsiniz. Örneğin, standart satıcı faturalarını (RE) dahil edip alacak dekontlarını hariç tutmak isteyebilirsiniz. Bu filtre, başlangıç CTE'sininWHEREyan tümcesine eklenebilir. - Ön Koşullar: Sorguyu çalıştıran kullanıcının, belirtilen şirket kodları içindeki mali ve satın alma belgeleri için uygun görüntüleme yetkilerine sahip olması gerekir. Temeldeki HANA veritabanına bir SQL istemcisi üzerinden erişim standart bir işlem değildir ve özel izinler gerektirir.
- Performans Değerlendirmeleri: Değişiklik belgesi tablolarından (
I_ChangeDocument,I_ChangeDocumentItem) veri çekmek performans açısından yoğun olabilir. Uzun işlem sürelerini önlemek için tarih, şirket kodu ve nesne sınıfı (INCOMINGINVOICE) üzerinde katı filtreler uygulamak esastır.
a Örnek Sorgu sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Adımlar
- Ön Koşullar ve Yetkilendirme: Dışa aktarımı gerçekleştiren kullanıcının, SAP S/4HANA'da gerekli Core Data Services (CDS) view'larına erişmek için gerekli yetkilere sahip olduğundan emin olun. Başlıca view'lar:
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemveI_PaymentProposalItem. Ayrıca kullanıcının, OData servisi veya doğrudan SQL bağlantısı gibi seçilen arayüz üzerinden sorgu yürütme izinlerine ihtiyacı olacaktır. - Bağlantı Yönteminizi Belirleyin: SQL sorgusunu yürütmek için SAP S/4HANA sistemine nasıl bağlanacağınızı belirleyin. Yaygın yöntemler arasında SAP Data Services, SAP Data Intelligence, SAP konektörü olan üçüncü taraf bir ETL aracı veya kuruluşunuzun güvenlik politikaları izin veriyorsa SAP HANA veritabanına doğrudan SQL bağlantısı yer alır.
- Dışa Aktarım Parametrelerini Tanımlayın: Sorguyu yürütmeden önce temel parametreleri belirleyin. Dışa aktarım için tarih aralığını belirtin (örneğin,
'YYYY-MM-DD've'YYYY-MM-DD'arasındakiCreationDate). Ayrıca veri kapsamını sınırlamak için dahil etmek istediğiniz belirliCompanyCodedeğerlerini tanımlayın. - SQL Sorgusunu Özelleştirin: Sağlanan SQL sorgusunu seçtiğiniz SQL istemcisine veya veri çıkarma aracına kopyalayın.
'{StartDate}','{EndDate}'ve('{CompanyCode1}', '{CompanyCode2}')gibi yer tutucuları dikkatlice inceleyin. Bu yer tutucuları önceki adımda tanımladığınız gerçek değerlerle değiştirin. Özel SAP yapılandırmanıza bağlı olarak workflow durumu için alan adlarını da ayarlamanız gerekebilir. - Sorguyu Yürütün: SQL sorgusunun tamamını SAP S/4HANA veritabanına karşı veya uygun servis katmanı üzerinden çalıştırın. Sorgu kapsamlı olacak şekilde tasarlanmıştır ve veri hacmine veya seçilen tarih aralığına bağlı olarak çalışması önemli bir zaman alabilir. Olası hatalar veya zaman aşımları için yürütme sürecini izleyin.
- İlk Sonuçları İnceleyin: Sorgu tamamlandığında çıktıya hızlıca göz atın.
InvoiceNumber,ActivityNameveEventTimesütunlarının dolu olduğunu kontrol edin.ActivityNamesütununda sadece 'Fatura Belgesi Oluşturuldu' değil, çeşitli aktiviteler gördüğünüzden emin olun. - Veri Dönüştürme İşlemleri: Sorgu, temiz bir event log formatı üretecek şekilde yapılandırılmıştır. Ancak
EventTimesütunununYYYY-MM-DDTHH:MM:SSgibi tutarlı bir zaman damgası formatında olduğundan emin olun. Sağlanan sorgu, gerektiğinde tarih ve saat alanlarını tek bir zaman damgasında birleştirir. - Veriyi Dışa Aktarın: Nihai sonuç kümesini aracınızdan bir CSV (Virgülle Ayrılmış Değerler) dosyasına aktarın. Bu format, ProcessMind dahil tüm Process Mining araçlarıyla evrensel olarak uyumludur.
- Yükleme Hazırlığı: Yüklemeden önce, karakter sorunlarını önlemek için CSV dosyasının UTF-8 kodlaması kullandığını onaylayın. Dosyadaki sütun başlıklarının gerekli niteliklerle tam olarak eşleştiğinden emin olun:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, vb. - ProcessMind'a Yükleyin: Hazırlanan CSV dosyasını Process Mining projenize yükleyin. Dosyanızdaki sütunları, aracın veri modeli yapılandırmasındaki ilgili case ID, aktivite adı ve zaman damgası alanlarıyla eşleştirin.
Konfigürasyon
- Kullanılan CDS View'lar: Birincil veri kaynakları standart SAP CDS view'larıdır. Ana view'lar şunlardır: Başlık verileri için
I_InvoiceDocument, mali kayıt ve denkleştirme detayları içinI_OperationalAcctgDocItem, ödeme blokajları ve workflow durumu gibi fatura niteliklerindeki geçmiş değişiklikleri takip etmek için iseI_ChangeDocumentveI_ChangeDocumentItem. - Tarih Aralığı Filtreleme: Performansı yönetmek için verileri belirli bir tarih aralığına göre filtrelemek kritik önem taşır. Sağlanan sorgu,
I_InvoiceDocumentview'ındakiCreationDatealanı için bir yer tutucu kullanır. Başlangıç noktası olarak 3 ila 6 aylık bir veri dönemi önerilir. - Şirket Kodu Filtresi: Veri çıkarımının ilgili ve yönetilebilir olmasını sağlamak için her zaman bir veya daha fazla
CompanyCode(Şirket Kodu) ile filtreleme yapın. Sorgu, bu amaçla kullanılan birWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')yer tutucusu içerir. - Belge Türü Filtresi:
InvoiceDocumentType(Fatura Belge Türü) üzerinden filtreleme yaparak kapsamı daha da daraltabilirsiniz. Örneğin, standart satıcı faturalarını (RE) dahil edip alacak dekontlarını hariç tutmak isteyebilirsiniz. Bu filtre, başlangıç CTE'sininWHEREyan tümcesine eklenebilir. - Ön Koşullar: Sorguyu çalıştıran kullanıcının, belirtilen şirket kodları içindeki mali ve satın alma belgeleri için uygun görüntüleme yetkilerine sahip olması gerekir. Temeldeki HANA veritabanına bir SQL istemcisi üzerinden erişim standart bir işlem değildir ve özel izinler gerektirir.
- Performans Değerlendirmeleri: Değişiklik belgesi tablolarından (
I_ChangeDocument,I_ChangeDocumentItem) veri çekmek performans açısından yoğun olabilir. Uzun işlem sürelerini önlemek için tarih, şirket kodu ve nesne sınıfı (INCOMINGINVOICE) üzerinde katı filtreler uygulamak esastır.
a Örnek Sorgu sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Adımlar
- ABAP Editörüne Erişin: SAP S/4HANA sisteminize giriş yapın.
SE38(ABAP Editor) işlemini açın. - Programı Oluşturun: Program alanına yeni programınız için bir isim girin (örneğin
Z_PM_INVOICE_EXTRACT) ve 'Oluştur' düğmesine tıklayın. Bir başlık belirleyin, türü 'Yürütülebilir Program' olarak ayarlayın ve uygun bir pakete kaydedin. - Program Yapısını ve Seçim Ekranını Tanımlayın: Editörde, nihai event log çıktısı için veri yapılarını tanımlayın. Ardından, kullanıcıların fatura giriş tarihi aralığı, şirket kodları ve belge türleri gibi parametreleri girmesine olanak tanıyan bir seçim ekranı oluşturun. Bu, programı yeniden kullanılabilir ve esnek kılar.
- Veri Seçim Mantığını Uygulayın: Çeşitli SAP tablolarından veri seçmek için temel ABAP SQL ifadelerini yazın. Program, gerekli 13 aktivitenin her biri için sırayla sorgulama yapacaktır.
- Başlık ve Kalem Verilerini Çıkarın: 'Fatura Belgesi Oluşturuldu' ve 'Fatura Kaydedildi' gibi temel olaylar için
RBKP(Lojistik Fatura Başlığı) veBKPF(Muhasebe Belgesi Başlığı) gibi ana tablolardan veri seçin. - Değişiklik Belgesi Verilerini Çıkarın: 'Ödeme Blokajı Konuldu' ve 'Ödeme Blokajı Kaldırıldı' gibi aktiviteler için
CDHDR(Değişiklik belgesi başlığı) veCDPOS(Değişiklik belgesi kalemleri) tablolarını sorgulayın. ÖrneğinBSEGtablosundakiZLSPRgibi belirli alanlardaki değişiklikleri tanımlamanız gerekecektir. - Ödeme Verilerini Çıkarın: Ödemeyle ilgili aktiviteleri yakalamak için ödeme önerileri için
REGUP(Ödeme programından işlenen kalemler) ve gerçekleşen ödemeler içinBSAK(Münferit Satıcı Kalemleri) gibi tabloları sorgulayın. Denkleştirme tarihini (AUGDT) net vade tarihiyle (ZFBDT) karşılaştırarak 'Gecikmiş Ödeme Gerçekleştirildi' durumunu ayırt edin. - Workflow Verilerini Çıkarın: Onay aktiviteleri için, workflow öğelerini fatura nesnelerine bağlamak amacıyla
SWW_WI2OBJgibi SAP Business Workflow tablolarını sorgulayın. Bu bölüm, özel workflow yapılandırmanıza bağlıdır ve önemli ölçüde uyarlama gerektirebilir. - Verileri Event Log Formatında Birleştirin: Seçilen her aktivite için verileri ortak bir dahili tablo yapısında formatlayın. Bu tablodaki her satır tek bir olayı temsil eder ve case ID (
InvoiceNumber),ActivityNameveEventTimeile diğer önerilen nitelikleri içermelidir. - Çıktı Dosyasını Oluşturun: Dahili tablonun içeriğini SAP uygulama sunucusundaki düz bir dosyaya yazmak için
OPEN DATASET,TRANSFERveCLOSE DATASETABAP ifadelerini kullanın. CSV formatı önerilir. - Zamanlayın ve Çalıştırın: Test için programı ön planda çalıştırın (
F8). Canlı sistemlerde, sistem performansını etkilememek içinSM36işlemini kullanarak yoğun olmayan saatlerde çalışacak bir arka plan işi olarak zamanlayın. - Alın ve Yükleyin: Dosyanın kaydedildiği uygulama sunucusu dizinine gitmek için
AL11işlemini kullanın. Dosyayı yerel sisteminize indirin. Process Mining aracına yüklemeden önce dosyanın UTF-8 kodlu ve doğru formatta olduğundan emin olun.
Konfigürasyon
- Tarih Aralığı: Fatura giriş tarihi (
RBKP-CPUDT) veya kayıt tarihini (BKPF-BUDAT) baz alarak dışa aktarım için belirli bir tarih aralığı tanımlayın. Başlangıç analizi için, yönetilebilir bir veri hacmi sağlamak adına 3 ila 6 aylık bir dönem önerilir. - Şirket Kodu (BUKRS): Bir veya daha fazla şirket koduna göre filtreleme yapmak kritiktir. Büyük bir organizasyonda tüm şirket kodları için veri çekmek, aşırı uzun çalışma sürelerine ve devasa dosya boyutlarına yol açabilir.
- Belge Türü (BLART): Satıcı faturalarını ayrıştırmak için ilgili belge türlerini filtreleyin. Yaygın türler arasında 'RE' (Lojistik Fatura) ve 'KR' (Satıcı Faturası) bulunur. Bu, analiz dışı kalması gereken belgelerin elenmesine yardımcı olur.
- Satıcı Hesabı (LIFNR): Program, hedeflenmiş analizler veya testler için yararlı olan belirli satıcı numaralarına yönelik isteğe bağlı bir filtre içerebilir.
- Çıktı Dosyası Yapılandırması: Programın, uygulama sunucusundaki çıktı dosyası yolunu ve alan ayırıcıyı (örneğin virgül veya noktalı virgül) tanımlayacak parametreleri olmalıdır.
- Ön Koşullar: Bu programı yürüten kullanıcı veya sistem hesabının, ABAP programları oluşturmak ve çalıştırmak için geliştirici erişimine (
SE38üzerinden) veBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSile workflow tabloları dahil olmak üzere FI, MM ve Basis tabloları için kapsamlı okuma yetkilerine sahip olması gerekir.
a Örnek Sorgu abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path.