Satın Almadan Ödemeye fatura işleme Veri Templateiniz
Satın Almadan Ödemeye fatura işleme Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- SAP S/4HANA için veri çıkarma yönergeleri
Satın Almadan Ödemeye fatura işleme öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Fatura numarası InvoiceNumber | Tedarikçi fatura belgesinin benzersiz tanımlayıcısıdır ve süreçteki temel vaka kimliği olarak kullanılır. | ||
| Açıklama Fatura numarası, SAP S/4HANA’da her tedarikçi faturasına atanan benzersiz tanımlayıcıdır. Faturanın oluşturulması, beklemeye alınması, onaylanması ve ödenmesi gibi ilgili tüm etkinlikleri tek bir süreç örneğinde bir araya getirir. Process Mining analizinde bu öznitelik, her faturanın uçtan uca yolculuğunu izlemek için temel niteliktedir. Faturanın alınmasından son ödemenin yapılmasına kadar tüm süreç akışını yeniden oluşturmayı sağlar. Böylece çevrim sürelerini, darboğazları ve süreç farklılıklarını fatura bazında inceleyebilirsiniz. Neden önemli? İlgili tüm olayları birbirine bağlayan temel anahtardır; faturanın sistemdeki yaşam döngüsünü baştan sona izlemenizi sağlar. Nereden alınır? Bu, BKPF tablosundaki BELNR alanında bulunan muhasebe belge numarasıdır. Örnekler 190000000119000000451900000132 | |||
| Etkinlik adı ActivityName | Faturayla ilgili olarak belirli bir zamanda gerçekleşen iş etkinliğinin veya olayın adı. | ||
| Açıklama Etkinlik adı, fatura işleme sürecindeki 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 kondu' ve 'Ödeme gerçekleştirildi' yer alır. Bu öznitelik, etkinliklerin akışını görsel olarak gösteren süreç haritasını oluşturmak için önemlidir. Etkinliklerin sırasını, sıklığını ve aralarındaki süreyi inceleyerek darboğazları, yeniden çalışma döngülerini ve uyumluluk dışı süreç farklılıklarını belirleyebilirsiniz. Her Process Mining analizinin temelini oluşturur. Neden önemli? Süreçteki adımları tanımlar; süreç haritalarını görselleştirmenizi, süreç akışlarını ve farklılıklarını incelemenizi 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 bir araya getirilmesiyle elde edilir. Örnekler Fatura park edildiFatura onaylandıÖdeme gerçekleştirildi | |||
| Olay zamanı EventTime | Etkinliğin gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Olay zamanı, belirli bir etkinliğin tam olarak ne zaman gerçekleştiğini kaydeden zaman damgasıdır. Süreçteki farklı adımlar arasındaki süreleri, çevrim sürelerini ve bekleme sürelerini hesaplamak için bu veri gereklidir. Process Mining analizinde doğru zaman damgaları, 'Ortalama fatura çevrim süresi' ve 'Fatura onay çevrim süresi' gibi performans KPI’larını ölçmek için kullanılır. Kuruluşlar, etkinlikler arasında geçen süreyi inceleyerek faturaların geciktiği darboğazları bulabilir ve süreci hızlandırma fırsatlarını belirleyebilir. Neden önemli? Bu zaman damgası, performans izleme, darboğaz belirleme ve SLA takibi dâhil zamana dayalı tüm analizlerin temelidir. Nereden alınır? Genellikle CDHDR (başlık) ve CDPOS (kalem) değişiklik belgesi tablolarındaki UDATE ve UTIME alanlarından alınır. Bazı olaylarda BKPF gibi tablolardaki oluşturma veya giriş tarihleri ve saatleri (CPUDT, CPUTM) kullanılabilir. Örnekler 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Belge türü DocumentType | Tedarikçi faturaları veya alacak dekontları gibi farklı muhasebe belgelerini sınıflandıran kod. | ||
| Açıklama SAP’de belge türü, farklı iş işlemlerini birbirinden ayırmak için kullanılır. Örneğin 'KR' genellikle standart bir tedarikçi faturasını, 'KG' ise tedarikçi alacak dekontunu belirtir. Belge türüne göre analiz yapmak, farklı işlem türlerinin nasıl yürütüldüğünü anlamak için süreci gruplandırmanızı sağlar. Örneğin, alacak dekontu süreci standart fatura sürecinden önemli ölçüde farklı olabilir. Bu gruplandırma, daha doğru ve ilgili süreç içgörüleri sağlar. Neden önemli? Standart faturalar ve alacak dekontları gibi farklı finansal işlem türlerini ayırt etmeye yardımcı olur; bu işlemler çoğu zaman farklı süreç yollarını izler. Nereden alınır? BKPF belge başlığı tablosundaki BLART alanında bulunur. Örnekler KRREKG | |||
| Fatura tutarı AmountInCompanyCodeCurrency | Şirket kodunun yerel para birimindeki toplam brüt fatura tutarı. | ||
| Açıklama Bu öznitelik, faturanın toplam değerini gösterir. Fatura işleme operasyonunun finansal etkisini ve ölçeğini anlamak için temel bir metriktir. Fatura tutarlarını inceleyerek yüksek tutarlı faturalara öncelik verebilir, harcama eğilimlerini belirleyebilir ve süreç sorunlarını finansal değerle ilişkilendirebilirsiniz. Örneğin, yüksek tutarlı faturaların bloke edilme veya daha uzun onay sürelerine sahip olma olasılığını inceleyebilirsiniz. Neden önemli? Sürece finansal bağlam kazandırır ve yüksek tutarlı faturaların farklı işlenip işlenmediği gibi parasal değere dayalı analizler yapmanızı sağlar. Nereden alınır? Bu değer genellikle BSEG tablosundaki ilgili kalemlerin WRBTR alanında (yerel para birimindeki tutar) bulunan değerlerinin toplamından elde edilir. Örnekler 1500.75125000.00850.20 | |||
| Kullanıcı adı UserName | Etkinliği 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. Bir kişinin kullanıcı kimliği ya da otomatik toplu işler için bir sistem kimliği olabilir. Kullanıcı bazında analiz, iş yükü dağılımını anlamaya, eğitim ihtiyaçlarını belirlemeye ve olağan dışı kullanıcı davranışlarını fark etmeye yardımcı olur. Örneğin, hangi kullanıcıların istisnai durumlarla sık ilgilendiğini veya hangi faturaların otomatik işlendiğini (ör. 'BATCHUSER' kullanıcısı) gösterebilir. Bu bilgi, 'Fatura otomasyon oranı' KPI’ını hesaplamak için önemlidir. Neden önemli? Süreç etkinliklerini belirli kullanıcılara veya sistem hesaplarına bağlar; iş yükü analizi, performans karşılaştırması ve otomasyon tespiti sağlar. Nereden alınır? BKPF-USNAM (Giren) veya CDHDR-USERNAME (Değiştiren) gibi alanlardan alınır. Örnekler SMITHJMUELLERTWF-BATCH | |||
| Ödeme blokesi nedeni PaymentBlockReason | Faturanın neden ödemeye kapatıldığını belirten kod. | ||
| Açıklama Faturaya ödeme blokesi konduğunda bu öznitelik, 'Miktar uyuşmazlığı' veya 'Fiyat uyuşmazlığı' gibi blokajın nedenini belirtir. İstisnaların ele alınmasını standartlaştırmak için bu nedenler SAP’de yapılandırılır. Bu öznitelik, 'Ödeme blokesi sıklığı ve süresi' Dashboardı için önemlidir. Farklı bloke nedenlerinin sıklığını incelemek; belirli tedarikçiler, malzemeler veya iç süreçlerle ilgili sorunlar gibi ödeme gecikmelerinin temel nedenlerini belirlemeye ve hedefli düzeltici adımlar atmaya yardımcı olur. Neden önemli? Ödeme blokelerinin temel nedenini gösterir; gecikmeleri azaltmak ve işlemlerin ilk seferde doğru yapılmasını iyileştirmek için hedefli analiz olanağı sağlar. Nereden alınır? BSEG tablosundaki tedarikçi kaleminde, ZLSPR (Ödeme blokesi anahtarı) alanında bulunur. Örnekler RIA | |||
| Ödeme vade tarihi PaymentDueDate | Faturanın vadesi geçmeden ödenmesi gereken tarih. | ||
| Açıklama Ödeme vade tarihi, kararlaştırılan ödeme koşullarına ve fatura tarihine göre hesaplanan ödeme tarihidir. Süreçte önemli bir son tarihi belirtir. Bu öznitelik, 'Vadesinde ödeme oranı' KPI’ı ve 'Tedarikçi ödeme performansı' Dashboardı için gereklidir. Şirket, gerçek ödeme tarihini vade tarihiyle karşılaştırarak ödeme yükümlülüklerini yerine getirme performansını ölçebilir. Bu performans tedarikçi ilişkilerini ve finansal itibarı etkiler. Neden önemli? Vadesinde ödeme performansını ölçmek için temel ölçüttür. İyi tedarikçi ilişkilerini sürdürmek ve gecikme ücretlerinden kaçınmak açısından önemlidir. Nereden alınır? Bu tarih genellikle BSEG tablosundaki tedarikçi kaleminde, vade tarihi hesaplamasının başlangıç tarihi olan ZFBDT alanında bulunur. Net vade tarihi, bu başlangıç tarihi ve ödeme koşullarına göre hesaplanır. Örnekler 2023-05-302023-06-152023-07-01 | |||
| Satın alma siparişi PurchasingDocument | Faturanın ilişkili olduğu satın alma siparişinin numarası. | ||
| Açıklama Satın alma belgesi numarası, tedarikçi faturasını orijinal satın alma siparişine (PO) bağlar. Bu bağlantı, faturanın satın alma siparişi ve mal kabul belgesiyle karşılaştırıldığı üçlü eşleştirme sürecinin temelidir. Bu özniteliğe göre analiz yapmak, satın alma siparişine bağlı faturalarla bu siparişe bağlı olmayan faturalar arasındaki sorunları anlamaya yardımcı olur. Eşleştirme uyuşmazlıklarını incelemek ve sürecin satın alma bölümünün verimliliğini değerlendirmek için önemlidir. Neden önemli? Faturayı satın alma sürecine bağlar; eşleştirme uyuşmazlıklarını ve satın alma siparişi uyumluluğunu incelemek için gereklidir. Nereden alınır? Bu bilgi genellikle BSEG belge kalemi tablosundaki EBELN (Satın alma belgesi numarası) alanında bulunur. Örnekler 450000123445000056784500009012 | |||
| Şirket kodu CompanyCode | Mali tabloların hazırlandığı, hukuken bağımsız bir şirketi temsil eden organizasyon birimi. | ||
| Açıklama Şirket kodu, SAP Finance içindeki temel organizasyon birimlerinden biridir. Her fatura, işlemden sorumlu tüzel kişiyi belirleyen bir şirket koduna atanır. Process Mining analizinde şirket koduna göre filtreleme veya karşılaştırma yapmak, farklı iş birimlerinde, tüzel kişilerde ya da ülkelerde süreç performansını incelemek için önemlidir. Verimlilik, uyumluluk ve otomasyon düzeylerindeki bölgesel farklılıkları belirlemeye yardımcı olur ve hedefli iyileştirme çalışmalarını destekler. Neden önemli? Kuruluş içindeki farklı tüzel kişiler veya coğrafi konumlar arasında fatura işleme performansını gruplandırıp karşılaştırmanızı sağlar. Nereden alınır? BKPF belge başlığı tablosundaki standart BUKRS alanıdır. Örnekler 1000US01DE01 | |||
| Tedarikçi numarası VendorNumber | Faturayı gönderen tedarikçinin benzersiz tanımlayıcısı. | ||
| Açıklama Tedarikçi numarası, faturayla 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 ya da ödeme blokelerine yol açan sorunlu faturaları sık gönderen tedarikçileri belirlemek gibi tedarikçi odaklı analizlerde önemlidir. Tedarikçi ilişkilerini yönetmeye ve tedarikçilerin güvenilirliğini değerlendirmeye yardımcı olur. Neden önemli? Süreç performansını tedarikçi bazında incelemenizi sağlar; örüntüleri belirlemeye, ilişkileri yönetmeye ve tedarikçi kaynaklı sorunları değerlendirmeye yardımcı olur. Nereden alınır? Genellikle BSEG muhasebe belge kalemi tablosundaki LIFNR alanında bulunur. Örnekler 100345700012V9832 | |||
| Fatura tarihi InvoiceDate | Tedarikçinin fatura belgesini düzenlediği tarih. | ||
| Açıklama Belge tarihi olarak da bilinen fatura tarihi, tedarikçinin faturada belirttiği tarihtir. Kararlaştırılan ödeme koşullarına göre ödeme vadesini hesaplamak için başlangıç noktası olarak kullanılır. Analizde bu tarih, faturanın yaşını ve erken ödeme indiriminden yararlanma koşullarını belirlemek gibi finansal hesaplamalar için temel niteliktedir. 'Erken ödeme indirimi kullanım oranı' KPI’ının hesaplanmasında önemli bir girdidir. Neden önemli? Ödeme koşullarını ve vade tarihlerini hesaplamak için başlangıç noktasıdır; işletme sermayesini yönetmek ve indirimlerden yararlanmak açısından önemlidir. Nereden alınır? BKPF belge başlığı tablosundaki BLDAT (Belge tarihi) alanında bulunur. Örnekler 2023-04-122023-05-152023-06-20 | |||
| Kapatma belgesi numarası. ClearingDocumentNumber | Faturayı kapatan belge numarasıdır; genellikle ödeme belgesini belirtir. | ||
| Açıklama Kapatma belgesi numarası, açık fatura kalemini kapatan işleme, çoğunlukla da ödeme belgesine bağlar. Böylece faturanın ödendiği doğrulanır. Bu öznitelik, fatura ile ödeme arasındaki kesin bağlantıyı kurar. 'Ödeme gerçekleştirildi' etkinliğini ve ilgili zaman damgasını belirlemek için kullanılır. Uçtan uca çevrim süresini ve vadesinde ödeme oranını hesaplamak açısından gereklidir. Neden önemli? Faturanın ödendiğini doğrular ve faturayı ilgili ödeme işlemine bağlar. Çevrim süresi ile ödeme performansını analiz etmek için önemlidir. Nereden alınır? BSEG belge kalemi tablosundaki AUGBL (Kapatma belgesi numarası) alanında bulunur. Örnekler 150000000115000000231500000088 | |||
| Kaynak sistem kimliği SourceSystemId | Verilerin alındığı kaynak SAP S/4HANA sisteminin tanımlayıcısı. | ||
| Açıklama Bu öznitelik, verinin geldiği sistemi belirtir. Örneğin 'S4H_PROD' veya 'ERP_EU' değerlerini alabilir. Birden fazla ERP örneğinin ya da eski ve yeni sistemlerin birlikte kullanıldığı ortamlarda özellikle önemlidir. Analiz sırasında farklı sistemlerin veya bölgelerin süreç performansını karşılaştırmanızı sağlar. Veri kökenini izlemeye yardımcı olur; birden fazla kaynaktan gelen veriler merkezi bir Process Mining platformunda birleştirildiğinde veri yönetişimi ve sorun giderme açısından önem taşır. Neden önemli? Verinin kaynağı hakkında bilgi verir. Bu bilgi, veri yönetişimi ve farklı sistemlerdeki ya da şirket konumlarındaki süreçleri karşılaştırmak için gereklidir. Nereden alınır? Bu değer genellikle veri çıkarımı sırasında SAP sistem kimliğinden (sy-sysid) alınır veya ETL sürecinde sabit bir değer olarak yapılandırılır. Örnekler S4PS4H_PROD_100ECC_EU | |||
| Ödeme koşulları PaymentTerms | Tedarikçiyle kararlaştırılan vade tarihleri ve indirim dönemleri gibi ödeme koşullarını tanımlayan kod. | ||
| Açıklama Ödeme koşulları, erken ödeme indirimleri dâhil olmak üzere faturanın ödeme kurallarını tanımlar. Örneğin 'Z030', '30 gün içinde net ödenir' anlamına gelebilir. Bu öznitelik, finansal planlama ve işletme sermayesini iyileştirme açısından önemlidir. Process Mining analizinde 'Ödeme vade tarihi’ni hesaplamak ve erken ödeme indirimlerinden yararlanma koşullarını belirlemek için kullanılır; böylece 'Erken ödeme indirimi kullanım oranı' KPI’ını doğrudan destekler. Neden önemli? Ödeme vade tarihlerini ve indirimleri belirleyen kuralları tanımlar; vadesinde ödeme KPI’larını ve işletme sermayesi yönetimini doğrudan etkiler. Nereden alınır? BSEG tablosundaki tedarikçi kaleminde, ZTERM (Ödeme koşulları anahtarı) alanında bulunur. Örnekler 0001Z030NT60 | |||
| Onay döngüsü sayısı ApprovalCycleCount | Faturanın kaç kez onaya gönderildiğini gösteren sayı. | ||
| Açıklama Bu metrik, tek bir faturada 'Fatura onaya gönderildi' etkinliğinin kaç kez gerçekleştiğini sayar. Sayının birden fazla olması, faturanın en az bir kez reddedildiğini veya geri gönderildiğini ve yeni bir onay döngüsünden geçtiğini gösterir. Bu öznitelik, 'İlk seferde onay oranı' KPI’ını doğrudan destekler. Onay döngüsü sayısı yüksek faturaları inceleyerek yetersiz bilgi veya yanlış kodlama gibi ret nedenlerini belirleyebilir ve süreci iyileştirmek için adım atabilirsiniz. Neden önemli? Onay alt sürecindeki yeniden çalışmayı ölçer; ilk seferde doğru işlem oranını hesaplamaya ve onay retlerinin nedenlerini belirlemeye yardımcı olur. Nereden alınır? Her benzersiz InvoiceNumber için 'Fatura onaya gönderildi' etkinliğinin kaç kez gerçekleştiği sayılarak hesaplanır. Örnekler 123 | |||
| Otomatik mi IsAutomated | Bir etkinliğin otomatik bir sistem kullanıcısı tarafından gerçekleştirilip gerçekleştirilmediğini belirten işaret. | ||
| Açıklama Bu boole özniteliği, etkinlikle ilişkili kullanıcı 'WF-BATCH' veya 'SAP_SYSTEM' gibi bilinen bir sistem ya da toplu iş hesabıysa doğru değerini alır. Sürecin elle yürütülen adımlarıyla otomatik adımlarını ayırt etmeye yardımcı olur. Bu öznitelik, 'Fatura otomasyon oranı' KPI’ını hesaplamak için gereklidir. Kuruluşlar, sürecin hangi bölümlerinin otomatik olduğunu inceleyerek otomasyon çalışmalarının başarısını ölçebilir, elle yapılan işi azaltma ve verimliliği artırma fırsatlarını belirleyebilir. Neden önemli? Elle yürütülen etkinliklerle sistem tarafından gerçekleştirilenleri ayırt eder. Otomasyon oranlarını ölçmek ve daha fazla otomasyon fırsatını belirlemek için temel niteliktedir. Nereden alınır? UserName özniteliğinden elde edilir. 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 | Fatura belgesinin neden ters kaydedildiğini belirten kod. | ||
| Açıklama Bir fatura yanlış muhasebeleştirildiğinde çoğunlukla ters kaydı yapılır. Ters kayıt nedeni kodu, 'Yanlış muhasebeleştirme tarihi' veya 'Veri giriş hatası' gibi işlem nedenini açıklar. Ters kayıt nedenlerini incelemek, fatura muhasebeleştirme sürecindeki hata örüntülerini belirlemeye yardımcı olur. Bu içgörü; eğitimleri iyileştirmek, sistem kontrollerini geliştirmek veya finansal işlemlerin tekrarlanmasına ve idari iş yüküne yol açan yinelenen sorunları gidermek için kullanılabilir. Neden önemli? Faturaların neden iptal edildiğini açıklar; muhasebeleştirme sürecindeki hata ve yeniden çalışma kaynaklarını doğrudan görmenizi sağlar. Nereden alınır? Orijinal belgenin BKPF tablosundaki başlık bölümünde, STGRD (Ters kayıt nedeni) alanında bulunur. Örnekler 010205 | |||
| Veri çıkarma zaman damgası ExtractionTimestamp | Verilerin 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 verilerin ne kadar güncel olduğunu gösterir. Analizde, oluşturulan içgörülerin ne kadar güncel olduğunu anlamak için kullanılır. Operasyonel izleme panolarında kararların güncel bilgilere dayanmasını ve veri yenileme döngülerinin etkili biçimde yönetilmesini sağlar. 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, SAP alanı değildir. Veri çekildiği sırada veri çıkarma aracı veya ETL süreci tarafından oluşturulup eklenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Yeniden çalışma var mı IsRework | Faturanın reddedilen onay veya kaldırılan ödeme blokesi gibi yeniden çalışma etkinliklerinden geçip geçmediğini belirten işaret. | ||
| Açıklama Bu öznitelik, bir veya daha fazla yeniden çalışma döngüsünden geçen faturaları işaretler. Yeniden çalışma, örneğin 'Fatura reddedildi' etkinliğinin ardından 'Fatura onaylandı' ya da 'Ödeme blokesi kondu' etkinliğinin ardından 'Ödeme blokesi kaldırıldı' gibi belirli etkinlik dizileriyle belirlenir. Bu öznitelik, 'Faturada yeniden çalışma oranı' KPI’ının hesaplanmasını kolaylaştırır. Analistler, verimsizliğin ve yinelenen elle çalışmanın temel nedenlerini anlamak için yeniden çalışma içeren vakaları kolayca ayırıp inceleyebilir. Neden önemli? İşin tekrarlanmasını gerektiren verimsiz süreç akışlarını belirler; israfı ölçmeye ve süreç istisnalarının temel nedenlerini bulmaya yardımcı olur. Nereden alınır? Olay günlüğündeki etkinlik dizisine göre hesaplanır. Örneğin, bir faturanın izinde 'Fatura reddedildi' etkinliği varsa bu işaret doğru değerini alır. Örnekler truefalse | |||
| Zamanında mı ödendi IsPaidOnTime | Fatura vade tarihinde veya daha önce ödendiyse doğru değerini alan işaret. | ||
| Açıklama Bu boole özniteliği, gerçek ödeme tarihinin ('Ödeme gerçekleştirildi' etkinliğinin zaman damgası) 'Ödeme vade tarihi' ile karşılaştırılması sonucunda elde edilir. Her faturanın ödeme durumunu açık ve ikili bir değerle gösterir. 'Vadesinde ödeme oranı' KPI’ının temel hesabıdır. Gecikmelerle ilişkili tedarikçileri, şirket kodlarını veya fatura tutarlarını belirlemek için geç ödemeleri kolayca filtreleyip incelemenizi sağlar. Neden önemli? Ödeme koşullarına uyumu doğrudan ölçer. Tedarikçi ilişkilerini yönetmek ve finansal operasyonları izlemek için önemli bir KPI’dır. Nereden alınır? 'Ödeme gerçekleştirildi' etkinliğinin EventTime değeri PaymentDueDate özniteliğiyle karşılaştırılarak hesaplanır. (Ödeme tarihi <= PaymentDueDate). Örnekler truefalse | |||
Satın Almadan Ödemeye fatura işleme etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura belgesi oluşturuldu | Bu, SAP’de fatura belgesinin oluşturulmasını gösteren ilk olaydır. Kullanıcı yeni bir fatura belgesini kaydettiğinde kaydedilebilir. Belge park edilmiş veya henüz kaydedilmemiş durumda olabilir. | ||
| Neden önemli? Bu etkinlik, fatura işleme yaşam döngüsünün başlangıcını gösterir. Genel işlem süresini ölçmek için bu olaydan diğer olaylara kadar geçen süreyi analiz etmek önemlidir. Nereden alınır? Bu olay, belge başlığı tablosundaki oluşturulma tarihi ve saatinden (CPUDT, CPUTM) alınır. Lojistik faturalarında bu tablo genellikle BKPF veya RBKP olur. FB60, MIRO veya MIR7 gibi işlem kodları (BKPF-TCODE), belgenin nasıl oluşturulduğunu gösterir. Kaydedin Fatura belgesinin oluşturulma zaman damgası için BKPF-CPUDT ve BKPF-CPUTM alanlarını kullanın. Olay türü explicit | |||
| Fatura kaydedildi | Bu önemli finansal olayda park edilmiş veya onaylanmış fatura resmî olarak büyük deftere kaydedilir. Bu işlem, tedarikçiye olan borcun muhasebeleştirilmesini sağlar. | ||
| Neden önemli? Muhasebeleştirme, veri girişi ve onay aşamalarını finansal ödeme aşamasından ayıran önemli bir dönüm noktasıdır. Faturanın oluşturulmasından muhasebeleştirilmesine kadar geçen süre, iç süreçlerin verimliliğini ölçmek için temel göstergelerden biridir. Nereden alınır? Bu olay, belge başlığındaki Muhasebeleştirme Tarihi (BKPF-BUDAT) alanından belirlenir. Önce beklemeye alınan belgelerde, belgenin muhasebeleştirilmiş duruma geçtiği an olayın zaman damgasını verir. Kaydedin Olayın zaman damgası olarak muhasebeleştirme tarihini (BKPF-BUDAT) kullanın. Olay türü explicit | |||
| Fatura onaylandı | Bu etkinlik, faturanın yetkili kişi tarafından onaylandığını gösterir. Onay iş akışı başarıyla tamamlandığında veya serbest bırakma göstergesi ayarlandığında kaydedilir. | ||
| Neden önemli? Bu önemli aşama, faturanın ödeme için serbest bırakıldığını gösterir. Onay gecikmeleri yaygın bir darboğazdır. Bu etkinliği izlemek, yavaş onay mercilerini veya süreç adımlarını belirlemeye yardımcı olur. Nereden alınır? Bu durum, SAP iş akışındaki son serbest bırakma adımından veya faturayla ya da satın alma belgesiyle ilişkili tablolardaki serbest bırakma durumu alanlarının değişikliklerinden anlaşılabilir. Kaydedin İş akışının tamamlandığını gösteren olaylardan veya belgenin serbest bırakma durumu alanındaki değişikliklerden çıkarım yapın. Olay türü inferred | |||
| Fatura ters kaydedildi | Daha önce muhasebeleştirilmiş bir fatura belgesinin ters kaydını ifade eden etkinliktir. Hatalı bir fatura için bu, sürecin son olayıdır; fatura çoğunlukla doğru bilgilerle yeniden kaydedilir. | ||
| Neden önemli? Ters kayıtlar, sürecin önceki aşamalarında fark edilmeyen ciddi hatalara işaret eder. Süreci iyileştirmek ve finansal kayıt hatalarını azaltmak için bu kayıtların sıklığını ve temel nedenlerini izlemek önemlidir. Nereden alınır? Ters kayıt belgesi oluşturulduğunda bu işlem belirlenebilir. Orijinal belgenin başlığında (BKPF) ters kayıt belge numarası (BKPF-STBLG) bulunur; ters kayıt belgesinde de orijinal belge numarası yer alır. Olay zamanı, ters kayıt belgesinin muhasebeleştirme tarihidir. Kaydedin BKPF-STBLG alanında değer bulunan belgeleri belirleyin ve ters kayıt belgesinin muhasebeleştirme tarihini kullanın. Olay türü explicit | |||
| Ödeme gerçekleştirildi | Standart sürecin son etkinliğinde ödeme yapılır ve fatura kapatılır. Bu, tutarın tedarikçiye aktarıldığını gösterir. | ||
| Neden önemli? Bu olay, Satın Almadan Ödemeye fatura sürecinin sonunu gösterir. Uçtan uca toplam çevrim süresini hesaplamak ve vadesinde ödeme performansını ölçmek için gereklidir. Nereden alınır? Bu olay, tedarikçi kalemindeki kapatma belgesi bilgilerinden alınır. Kapatma Tarihi (BSEG-AUGDT) ve Kapatma Belgesi (BSEG-AUGBL), ödemenin yapıldığını gösterir. Kaydedin Kapatılmış tedarikçi kalemindeki kapatma tarihini (BSEG-AUGDT) kullanın. Olay türü explicit | |||
| Fatura onaya gönderildi | Bu etkinlik, fatura için resmî onay iş akışının başlatıldığını gösterir. Genellikle faturanın durumu 'onay bekliyor' olarak değiştiğinde veya bir iş akışı öğesi oluşturulduğunda anlaşılır. | ||
| Neden önemli? Onay çevrim süresini ölçmeye başlamak için bu nokta esas alınır. Onayların ne zaman başladığını anlamak, onay iş akışındaki darboğazları belirlemek açısından önemlidir. Nereden alınır? Bu durum genellikle fatura nesnesine (ör. BUS2081) bağlı bir SAP Business Workflowun (SWW_WI2OBJ tablosu) başlamasından veya belge başlığındaki özel bir durum alanının değişmesinden anlaşılır. Kaydedin Fatura belgesiyle ilişkili bir iş akışı öğesinin oluşturulmasından çıkarım yapın. Olay türü inferred | |||
| Fatura park edildi | Sisteme girilmiş ancak henüz büyük deftere kaydedilmemiş faturayı ifade eder. Eksik faturaları kaydetmek veya kayıt öncesinde incelemek için park etme işlemi kullanılır. | ||
| Neden önemli? Park etme, süreçte bilinçli bir duraklamaya işaret eder. Park edilmiş faturaların süresini ve sıklığını izlemek, resmî kayıt ve onay döngüsü başlamadan önceki gecikme nedenlerini belirlemeye yardımcı olur. Nereden alınır? Bu durum, park etme işlemleriyle (ör. MIR7, FV60) oluşturulan belgelerden veya BKPF tablosundaki belirli durum alanlarından ya da VBKPF gibi park edilmiş belgelere ayrılmış tablolardan belirlenebilir. Kaydedin Park etme işlemleriyle oluşturulan belgeleri belirleyin veya belgenin park edilmiş durumunu kontrol edin. Olay türü explicit | |||
| Fatura reddedildi | Onay sürecinde faturanın reddedilmesini ifade eder. Bu olay, faturanın düzeltilip yeniden gönderilmesini gerektiren yeniden çalışmayı başlatır. | ||
| Neden önemli? Faturaların reddedilmesi, süreç verimsizliğinin ve veri kalitesi sorunlarının önemli 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 durum, SAP iş akışındaki 'reddedildi' gibi belirli durum güncellemelerinden veya mevcut onay iş akışını iptal edip faturayı işleme sorumlusuna geri gönderen olaylardan anlaşılır. Kaydedin Reddedildiğini gösteren iş akışı durumu değişikliklerinden çıkarım yapın. Olay türü inferred | |||
| Fatura verileri güncellendi | Bu etkinlik, fatura belgesinin ilk oluşturulmasından sonra yapılan değişiklikleri gösterir. Ret sonrasındaki yeniden çalışma döngülerinde veya hataları düzeltmek için bu tür değişiklikler sıkça yapılır. | ||
| Neden önemli? Sık güncellemeler, yeniden çalışmaya ve veri girişindeki olası veri kalitesi sorunlarına işaret eder. Bu değişiklikleri izlemek, düzeltmelere harcanan emeği ölçmeye ve yaygın hataları belirlemeye yardımcı olur. Nereden alınır? Önemli alanlardaki değişiklikler SAP’nin CDHDR (başlık) ve CDPOS (kalem) değişiklik belgesi tablolarına kaydedilir. İlgili fatura nesnesindeki değişiklikleri filtreleyerek olaylar oluşturabilirsiniz. Kaydedin Fatura nesnesine ait değişiklik olaylarını CDHDR ve CDPOS tablolarından çıkarın. Olay türü explicit | |||
| Ödeme blokesi kaldırıldı | Daha önce konmuş bir ödeme blokesinin kaldırılarak sorunun çözüldüğünü ifade eder. Böylece fatura yeniden ödeme için uygun hâle gelir. | ||
| Neden önemli? Blokenin konmasıyla kaldırılması arasında geçen süre, süreç istisnasının çözüm süresini gösterir. Verimliliği ve tedarikçi ilişkilerini iyileştirmek için bu süreyi kısaltmak önemlidir. Nereden alınır? Bu olay, Payment Block Key alanındaki (BSEG-ZLSPR) değer silindiğinde kaydedilir. Değişiklik CDHDR ve CDPOS tablolarına yazılır ve blokenin kaldırıldığı zaman damgasını gösterir. Kaydedin Değişiklik belgelerini (CDHDR/CDPOS) kullanarak BSEG-ZLSPR alanındaki değerin silindiği zamanı belirleyin. Olay türü explicit | |||
| Ödeme blokesi kondu | Faturanın ödenmesini önlemek için bilerek bloke edildiği etkinliktir. Bu durum genellikle fiyat veya miktar tutarsızlıklarından ya da bekleyen bir alacak dekontundan kaynaklanır. | ||
| Neden önemli? Ödeme blokeleri, geç ödemelerin ve tedarikçi anlaşmazlıklarının başlıca nedenlerindendir. Zamanında ödeme oranını artırmak için blokelerin sıklığını, süresini ve nedenlerini analiz etmek önemlidir. Nereden alınır? Bu olay, fatura kalemindeki Payment Block Key alanındaki (BSEG-ZLSPR) değişiklikler izlenerek kaydedilir. CDHDR ve CDPOS değişiklik günlükleri, blokenin konduğu zaman damgasını ve işlemi yapan kullanıcıyı gösterir. Kaydedin Değişiklik belgelerini (CDHDR/CDPOS) kullanarak BSEG-ZLSPR alanına değer girildiği zamanı belirleyin. Olay türü explicit | |||
| Ödeme geç yapıldı | Bu hesaplanan olay, fatura ödemesi hesaplanan vade tarihinden sonra gerçekleştirildiğinde oluşur. İki tarih alanı karşılaştırılarak belirlenir. | ||
| Neden önemli? Bu etkinlik, vadesinde ödeme KPI’larını doğrudan destekler. Sık sık geç ödeme yapılan tedarikçileri veya iş birimlerini belirlemeye yardımcı olur. Geç ödemeler tedarikçi ilişkilerine zarar verebilir ve cezalara yol açabilir. Nereden alınır? Bu değer, Kapatma Tarihi (BSEG-AUGDT) ile Net Vade Tarihi karşılaştırılarak hesaplanır. Vade tarihi de Başlangıç Tarihi (BSEG-ZFBDT) ve ödeme koşullarına (BSEG-ZTERM) göre hesaplanır. Kaydedin BSEG-AUGDT > (BSEG-ZFBDT + ödeme vadesi gün sayısı) karşılaştırmasıyla belirleyin. Olay türü calculated | |||
| Ödeme teklifi oluşturuldu | Ödeme çalıştırmasının bir parçası olarak fatura seçilir ve ödeme teklifine eklenir. Bu, otomatik ödeme sürecinin ilk adımıdır. | ||
| Neden önemli? Bu etkinlik, ödeme niyetini gösterir. Bu adımla ödemenin gerçekleştirilmesi arasındaki gecikmeler, ödeme çalıştırma süreci, onaylar veya banka iletişimiyle ilgili sorunlara işaret edebilir. Nereden alınır? Bu bilgi, ödeme çalıştırma tablolarında, özellikle de ödeme teklifine eklenen kalemleri içeren REGUP tablosunda bulunabilir. İlgili REGUH tablosundaki çalıştırma tarihi zaman damgasını verir. Kaydedin Bir ödeme teklifi çalıştırmasında faturanın REGUP tablosunda göründüğü zamanı belirleyin. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşullar ve yetkilendirme: Veri çıkarma işlemini gerçekleştirecek kullanıcının, gerekli Core Data Services (CDS) görünümlerine erişmek için SAP S/4HANA’da gereken yetkilere sahip olduğundan emin olun. Önemli görünümler arasında
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemveI_PaymentProposalItembulunur. Kullanıcının ayrıca OData hizmeti veya doğrudan SQL bağlantısı gibi seçilen arayüz üzerinden sorgu çalıştırma izni olmalıdır. - Bağlantı yöntemini belirleyin: SQL sorgusunu çalıştırmak 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 bağlayıcısı olan üçüncü taraf bir ETL aracı veya kuruluşunuzun güvenlik politikaları izin veriyorsa SAP HANA veritabanına doğrudan SQL bağlantısı bulunur.
- Veri çıkarma parametrelerini tanımlayın: Sorguyu çalıştırmadan önce temel parametreleri belirleyin. Örneğin, veri çıkarma için
CreationDatetarih aralığını'YYYY-MM-DD'ile'YYYY-MM-DD'arasında tanımlayın. Ayrıca veri çıkarma kapsamını sınırlamak için dahil etmek istediğinizCompanyCodedeğerlerini belirleyin. - 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ı dikkatle inceleyin. Bunları önceki adımda belirlediğiniz gerçek değerlerle değiştirin. SAP yapılandırmanıza bağlı olarak iş akışı durumuna ilişkin alan adlarını da düzenlemeniz gerekebilir. - Sorguyu çalıştırın: SQL sorgusunun tamamını SAP S/4HANA veritabanında veya uygun hizmet katmanı üzerinden çalıştırın. Sorgu kapsamlı olacak şekilde tasarlanmıştır. Veri hacmine ve seçilen tarih aralığına bağlı olarak çalışması uzun sürebilir. Olası hataları veya zaman aşımını izleyin.
- İlk sonuçları inceleyin: Sorgu tamamlandığında çıktıyı hızlıca gözden geçirin.
InvoiceNumber,ActivityNameveEventTimesütunlarının dolu olduğunu kontrol edin.ActivityNamesütununda yalnızca 'Invoice Document Created' değil, farklı etkinliklerin de bulunduğunu doğrulayın. - Veri dönüşümünü kontrol edin: Sorgu, Event Log biçiminde düzenli bir çıktı oluşturacak şekilde hazırlanmıştır. Yine de
EventTimesütunununYYYY-MM-DDTHH:MM:SSgibi tutarlı bir zaman damgası biçiminde olduğundan emin olun. Gerekli durumlarda sağlanan sorgu, tarih ve saat alanlarını tek bir zaman damgasında birleştirir. - Verileri dışa aktarın: Sonuç kümesini aracınızdan CSV (virgülle ayrılmış değerler) dosyası olarak dışa aktarın. Bu biçim, ProcessMind dahil Process Mining araçlarıyla uyumludur.
- Yüklemeye hazırlanın: Yüklemeden önce karakter sorunlarını önlemek için CSV dosyasının UTF-8 kodlamasını kullandığını doğrulayın. Dosyadaki sütun başlıklarının gerekli özniteliklerle tam olarak eşleştiğinden emin olun:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCodevb. - ProcessMind’e yükleyin: Hazırladığınız CSV dosyasını Process Mining projenize yükleyin. Dosyanızdaki sütunları, aracın veri modeli yapılandırmasındaki ilgili vaka kimliği, etkinlik adı ve zaman damgası alanlarıyla eşleştirin.
Yapılandırma
- Kullanılan CDS görünümleri: Temel veri kaynakları standart SAP CDS görünümleridir. Başlık verileri için
I_InvoiceDocument, finansal kayıt ve mahsup ayrıntıları içinI_OperationalAcctgDocItem, ödeme blokesi ve iş akışı durumu gibi fatura özniteliklerindeki geçmiş değişiklikleri izlemek içinseI_ChangeDocumentveI_ChangeDocumentItemkullanılır. - Tarih aralığı filtresi: Performansı korumak için verileri belirli bir tarih aralığına göre filtrelemek önemlidir. Sağlanan sorguda
I_InvoiceDocumentgörünümündekiCreationDateiçin bir yer tutucu kullanılır. Başlangıç için 3 ila 6 aylık bir veri aralığı önerilir. - Şirket kodu filtresi: Veri çıkarmanın ilgili ve yönetilebilir kapsamda kalması için her zaman bir veya daha fazla
CompanyCodedeğerine göre filtre uygulayın. Sorguda bu amaçlaWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')yer tutucusu bulunur. - Belge türü filtresi:
InvoiceDocumentTypealanına göre filtre uygulayarak veri çıkarma kapsamını daraltabilirsiniz. Örneğin, standart tedarikçi faturalarını (RE) dahil edip alacak dekontlarını hariç tutabilirsiniz. Bu filtre ilk CTE’ninWHEREkoşuluna eklenebilir. - Ön koşullar: Sorguyu çalıştıran kullanıcının, belirtilen şirket kodlarındaki finans ve satın alma belgelerini görüntülemek için uygun yetkilere sahip olması gerekir. Temel HANA veritabanına SQL istemcisi üzerinden erişim standart değildir ve özel izin gerektirir.
- Performansla ilgili noktalar: Değişiklik belgesi tablolarından (
I_ChangeDocument,I_ChangeDocumentItem) veri çıkarmak performansı zorlayabilir. Sorgunun uzun sürmesini önlemek için tarih, şirket kodu ve nesne sınıfı (INCOMINGINVOICE) filtrelerini dar tutmak önemlidir.
Ö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
- SAP HANA kiracısına veya veritabanı şemasına doğrudan okuma erişiminin onaylandığını doğrulayın. Gerekli SAP tabloları ile onaylı değişiklik geçmişi veya iş akışı tablolarına erişim yetkisi olan, salt okunur bir veritabanı kullanıcısı edinin. SAP HANA Database Explorer, SAP HANA Studio veya onaylı bir SQL istemcisi kullanın. Üretim ortamında yazma erişimi kullanmayın.
- Hedef S/4HANA sistemindeki fiziksel tablo ve sütun adlarını doğrulayın. ACDOCA, BKPF ve RBKP standart başlangıç noktalarıdır; ancak iş akışı, bekletme, ödeme teklifi, ödeme yürütme, değişiklik geçmişi ve ödeme blokesi geçmişi sürüme veya müşteriye özgü nesnelerde tutulabilir. Sorgudaki köşeli parantezli her yer tutucuyu, sistem kataloğunda doğruladığınız nesnelerle ve ilgili iş anlamlarıyla değiştirin.
- Veri çıkarma dönemini [Başlangıç zaman damgası] ve [Bitiş zaman damgası] ile tanımlayın. Genellikle üç ila altı aylık, belge ve etkinlikleri kapsayacak kadar geniş bir dönem seçin. Ödeme vadeleri veya gecikmiş ödemeler fatura oluşturma döneminin dışına taşabiliyorsa aralığı genişletin.
- Yapılandırılmış fatura anahtarını kullanarak faturaları vaka olarak belirleyin. Sorgu, vaka tanımlayıcısı olarak InvoiceNumber kullanır ve çakışmaları önlemek için gerektiğinde şirket kodu ile mali yılı dahili olarak bu numaraya ekler. İş tanımınızın ProcessMind vaka tanımlayıcısında ek bir mali yıl veya şirket kodu anahtarı gerektirip gerektirmediğini doğrulayın.
- Kaydedilmiş fatura verilerini RBKP, BKPF ve ACDOCA tablolarından eşleyin. Fatura başlık bilgileri için RBKP’yi, muhasebe belgesi zaman damgaları ve kullanıcıları için BKPF’yi, mevcut olduğunda tedarikçi, tutar, satın alma belgesi, mahsup ve ödemeyle ilgili muhasebe bilgileri için ACDOCA’yı kullanın. Her alanın her kayıt senaryosunda dolu olacağını varsaymayın.
- Bekletme, onay, ret, güncelleme, ödeme blokesi, ters kayıt, ödeme teklifi ve ödeme yürütme etkinliklerini doğrulanmış, sisteme özgü kaynaklardan eşleyin. Yer tutucu kaynak görünümlerini; etkinlik zaman damgalarını, fatura referanslarını, kullanıcıları, durumları ve eski-yeni değerleri sunan onaylı görünümler veya tablolarla değiştirin. ProcessMind etkinlikleri kendiliğinden çıkarmaz; her etkinliği açık bir olay satırı olarak eklemeniz gerekir.
- SQL sorgusunun tamamını üretim dışı veya salt okunur bir oturumda çalıştırın. Çalıştırma planlarını inceleyin ve uygun olduğunda sorguyu şirket kodu, belge türü, mali yıl ve etkinlik zaman damgasına göre sınırlayın. Büyük yevmiye ve geçmiş tablolarını sınırsız biçimde birleştirmekten kaçının.
- Sonucu aşağıdaki kontrollerle doğrulayın. Gerekli tüm sütunların bulunduğunu, her etkinlik için EventTime ve her vaka için InvoiceNumber alanlarının dolu olduğunu, ilgili kaynak veriler mevcutsa 13 etkinlik adının tamamının sonuçlarda yer aldığını kontrol edin.
- Sonucu ProcessMind’in desteklediği, sınırlandırılmış bir dosya biçiminde dışa aktarın. UTF-8 CSV tercih edilir. Her satır bir etkinliği temsil etmeli ve dosyada InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason ve PurchasingDocument sütunları bulunmalıdır. Zaman damgalarını tutarlı bir saat diliminde saklayın ve tanımlayıcıların başındaki sıfırları koruyun.
- Event Logu ProcessMind’e yükleyin; InvoiceNumber alanını vaka tanımlayıcısı, ActivityName alanını etkinlik sütunu, EventTime alanını zaman damgası sütunu olarak yapılandırın. ProcessMind yapılandırması ek vaka anahtarlarını destekliyorsa veri çıkarma sırasında kullandığınız bileşik anahtar politikasını uygulayın.
Yapılandırma
- Tarih aralığı: İlk veri çıkarma için geriye dönük üç ila altı aylık bir dönem kullanın. Onay, ödeme, mahsup, ters kayıt veya gecikmiş ödeme etkinlikleri fatura oluşturma döneminden sonra gerçekleşebiliyorsa geçmiş verileri de dahil edin.
- Şirket kapsamı: [Şirket kodu filtresi] ile filtre uygulayın ve seçilen şirket kodlarının veri çıkarma için yetkili olduğunu doğrulayın.
- Belge kapsamı: [Belge türü filtresi] ile filtre uygulayın. Hedef süreçteki tedarikçi faturalarını, alacak dekontlarını, bekletilen faturaları ve ters kayıtları temsil eden belge türlerini dahil edin.
- Vaka tanımlayıcısı: Süreç tanımında gerektiği gibi InvoiceNumber kullanın. Fatura numaraları genelinde benzersiz değilse kaynak sonuçta şirket kodunu ve mali yılı koruyun veya ProcessMind modeline göre bileşik vaka anahtarı yapılandırın.
- Etkinlik kaynakları: İş akışı durumu değişiklikleri, onay kararları, bekletme, değişiklik geçmişi, ödeme blokeleri, ödeme teklifleri ve ödeme yürütme için kullanılan fiziksel kaynakları doğrulayın. Bu kaynaklar S/4HANA sürümüne, etkinleştirilen kapsama, iş akışı tasarımına ve müşteri uzantılarına göre değişir.
- Zaman damgası politikası: Veri çıkarma zaman damgası yerine iş etkinliğinin gerçekleştiği zamanı seçin. Saat dilimini belgeleyin ve yüklemeden önce tüm etkinlik zaman damgalarını tutarlı biçimde dönüştürün.
- Tutar politikası: Şirket kodu para birimindeki tutarı kullanın ve seçilen kaynağın borç ve alacak işaretlerini tutarlı biçimde sakladığını doğrulayın. Fatura vakası için toplama kuralını doğrulamadan yevmiye satırlarını toplamayın.
- Ödeme politikası: Ödeme Gerçekleşti etkinliğinin mahsup, ödeme belgesi kaydı, banka ödemesi veya başka bir iş kilometre taşı anlamına gelip gelmediğini tanımlayın. Üzerinde uzlaşılan süreç tanımına uygun kaynağı kullanın.
- Gecikmiş ödeme: Gecikmiş Ödeme Gerçekleşti etkinliğini yalnızca Ödeme Gerçekleşti etkinliği PaymentDueDate sonrasında gerçekleştiğinde oluşturun. Sorgu bu etkinliği açıkça hesaplar; ProcessMind’in kendiliğinden çıkarım yapmasına dayanmaz.
- Performans: Kaynak okumalarını tarih, şirket kodu, belge türü ve ilgili mali yılla sınırlayın. Yalnızca gerekli sütunları seçin, sorgu planlarını inceleyin ve kaynak geçmişi büyükse onaylı ara görünümleri somutlaştırın.
- Ön koşullar: Doğrudan SAP HANA bağlantısı, seçilen tüm nesneler için okuma yetkisi, meta verileri inceleme izni ve ilgili Borçlar Muhasebesi, Büyük Defter, satın alma, iş akışı ve ödeme verilerine erişim gerekir. Gerekli SAP lisanslarının, veritabanı erişim politikalarının ve veri koruma onaylarının bulunduğunu doğrulayın.
- Güvenlik: Salt okunur bir teknik kullanıcı kullanın, tedarikçi ve ödeme verilerini koruyun; kuruluşunuzun taşıma, denetim, maskeleme ve kimlik bilgisi yönetimi politikalarına uyun.
Örnek sorgu sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Adımlar
- ABAP düzenleyicisine erişin: SAP S/4HANA sisteminize giriş yapın.
SE38işlemini (ABAP Editor) açın. - Programı oluşturun: Program alanına yeni programınız için
Z_PM_INVOICE_EXTRACTgibi bir ad girin ve 'Oluştur' düğmesine tıklayın. Bir başlık girin, Tür alanında 'Yürütülebilir Program' seçin ve programı uygun bir pakete kaydedin. - Program yapısını ve seçim ekranını tanımlayın: Düzenleyicide son Event Log çıktısının veri yapılarını tanımlayın. Ardından kullanıcıların fatura kayıt tarihi için tarih aralığı, şirket kodları ve belge türleri gibi parametreleri girebileceği bir seçim ekranı oluşturun. Böylece programı yeniden kullanabilir ve esnek hale getirebilirsiniz.
- Veri seçme mantığını uygulayın: Çeşitli SAP tablolarından veri seçmek için temel ABAP SQL ifadelerini yazın. Program, gerekli 13 etkinliğin her biri için sırayla sorgu çalıştırır.
- Başlık ve kalem verilerini çıkarın: 'Fatura Belgesi Oluşturuldu' ve 'Fatura Kaydedildi' gibi temel etkinlikler 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 Blokesi Eklendi' ve 'Ödeme Blokesi Kaldırıldı' gibi etkinlikler için
CDHDR(Değişiklik belgesi başlığı) veCDPOS(Değişiklik belgesi kalemleri) tablolarını sorgulayın. Örneğin,BSEGtablosundakiZLSPRgibi belirli alanlardaki değişiklikleri belirlemeniz gerekir. - Ödeme verilerini çıkarın: Ödemeyle ilgili etkinlikleri kaydetmek için ödeme tekliflerinde
REGUP(ödeme programında işlenen kalemler), gerçekleşen ödemelerde iseBSAK(mahsup edilmiş tedarikçi kalemleri) gibi tabloları sorgulayın. 'Gecikmiş Ödeme Gerçekleşti' etkinliğini, mahsup tarihi (AUGDT) ile net vade tarihini (ZFBDT) karşılaştırarak belirleyin. - İş akışı verilerini çıkarın: Onay etkinlikleri için iş akışı kalemlerini fatura nesnelerine bağlayan
SWW_WI2OBJgibi SAP Business Workflow tablolarını sorgulayın. Bu adım, kullandığınız iş akışı yapılandırmasına büyük ölçüde bağlıdır ve önemli uyarlamalar gerektirebilir. - Verileri Event Log biçiminde birleştirin: Seçilen her etkinliğin verilerini ortak bir dahili tablo yapısında biçimlendirin. Bu tablodaki her satır tek bir etkinliği temsil etmeli ve diğer önerilen özniteliklerin yanı sıra vaka tanımlayıcısı (
InvoiceNumber),ActivityNameveEventTimealanlarını içermelidir. - Çıktı dosyasını oluşturun: Son dahili tablonun içeriğini SAP uygulama sunucusunda düz bir dosyaya yazmak için ABAP ifadeleri
OPEN DATASET,TRANSFERveCLOSE DATASETkullanın. Virgülle ayrılmış değerler (CSV) biçimi önerilir. - Zamanlayın ve çalıştırın: Test için programı ön planda (
F8kullanarak) çalıştırın. Üretim çalıştırmalarında sistem performansını etkilememek için programı yoğun olmayan saatlerdeSM36işlemiyle arka plan işi olarak zamanlayın. - Dosyayı 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 kodlamalı ve doğru biçimlendirilmiş olduğundan emin olun.
Yapılandırma
- Tarih aralığı: Veri çıkarma için fatura giriş tarihine (
RBKP-CPUDT) veya kayıt tarihine (BKPF-BUDAT) göre belirli bir tarih aralığı tanımlayın. İlk analizde veri hacmini yönetilebilir tutmak için 3 ila 6 aylık bir dönem önerilir. - Şirket kodu (BUKRS): Bir veya daha fazla şirket koduna göre filtre uygulamak önemlidir. Büyük bir kuruluştaki tüm şirket kodlarının verilerini çıkarmak, işlemin çok uzun sürmesine ve büyük dosyalar oluşmasına yol açabilir.
- Belge türü (BLART): Tedarikçi faturalarını ayırmak için ilgili belge türlerine göre filtre uygulayın. Yaygın türler arasında 'RE' (Fatura - Brüt) ve 'KR' (Tedarikçi faturası) bulunur. Böylece analizle ilgisi olmayan belgeler kapsam dışında kalır.
- Tedarikçi hesabı (LIFNR): Programda belirli tedarikçi numaraları için isteğe bağlı bir filtre bulunabilir. Bu filtre, hedefli analiz veya test için kullanışlıdır.
- Çıktı dosyası yapılandırması: Programda uygulama sunucusundaki çıktı dosyası yolunu ve virgül ya da noktalı virgül gibi alan ayırıcılarını tanımlayan parametreler bulunmalıdır.
- Ön koşullar: Programı çalıştıran kullanıcı veya sistem hesabının ABAP programları oluşturup çalıştırmak için (
SE38üzerinden) geliştirici erişimine veBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSile iş akışı tabloları dahil FI, MM ve Basis tabloları için kapsamlı okuma yetkilerine sahip olması gerekir.
Ö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. Başlamaya hazır mısınız?
Fatura işleme sürecinizi iyileştirmeye bugün başlayın. Bu Template, operasyonlarınızı önemli ölçüde iyileştirmek ve verimliliği artırmak için atacağınız ilk adımdır.
SAP S/4HANA’da Satın Almadan Ödemeye fatura işleme sürecinizi şimdi iyileştirin
Darboğazları belirleyin, fatura çevrim süresini %30 veya daha fazla azaltın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.