Satın Almadan Ödemeye - Borçlar Muhasebesi Fatura İşleme Veri Şablonunuz
Satın Almadan Ödemeye - Borçlar Muhasebesi Fatura İşleme Veri Şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek önemli etkinlikler
- SAP S/4HANA için çıkarma rehberi
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 ana vaka tanımlayıcısı olarak kullanılır. | ||
| Açıklama Fatura Numarası, SAP S/4HANA içindeki her tedarikçi faturasına atanan benzersiz tanımlayıcıdır. Oluşturma, park etme, onay ve ödeme gibi ilgili tüm faaliyetleri tek bir tutarlı süreç örneğinde birleştirir. Process Mining kapsamında bu öznitelik, her faturanın uçtan uca yolculuğunu izlemek için temel niteliktedir. Faturanın alınmasından nihai ödemeye kadar tüm süreç akışının yeniden oluşturulmasını sağlar; böylece çevrim süreleri, darboğazlar ve süreç farklılıkları fatura bazında analiz edilebilir. Neden önemli? İlgili tüm olayları birbirine bağlayan temel anahtardır ve faturanın sistemdeki yaşam döngüsünün eksiksiz biçimde izlenmesini sağlar. Nereden alınır? Bu, BKPF tablosunda BELNR alanında bulunan Accounting Document Number bilgisidir. Örnekler 190000000119000000451900000132 | |||
| Faaliyet adı ActivityName | Bir fatura için belirli bir zamanda gerçekleşen iş faaliyetinin veya olayın adıdır. | ||
| Açıklama Faaliyet Adı, fatura işleme yaşam döngüsündeki belirli bir adımı veya durum değişikliğini tanımlar. Örnekler arasında 'Invoice Document Created', 'Invoice Sent For Approval', 'Payment Block Set' ve 'Payment Executed' bulunur. Bu öznitelik, faaliyet akışını görsel olarak gösteren süreç haritasını oluşturmak için gereklidir. Bu faaliyetler arasındaki sıra, sıklık ve süre analiz edilerek darboğazlar, yeniden işleme döngüleri ve uyumlu olmayan süreç farklılıkları belirlenebilir. Her Process Mining analizinin temelini oluşturur. Neden önemli? Süreçteki adımları tanımlar; süreç haritalarının görselleştirilmesini, süreç akışlarının ve farklılıklarının analiz edilmesini sağlar. Nereden alınır? SAP işlem kodları (SY-TCODE), değişiklik belgesi nesnesi 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 | Faaliyetin gerçekleştiği kesin tarih ve saattir. | ||
| Açıklama Olay Zamanı, belirli bir faaliyetin 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, çevrim sürelerini ve bekleme sürelerini hesaplamak için gereklidir. Process Mining analizinde doğru zaman damgaları, 'Average Invoice Cycle Time' ve 'Invoice Approval Cycle Time' gibi performans KPI'larını ölçmek için kullanılır. Faaliyetler arasında geçen süre analiz edilerek faturaların geciktiği darboğazlar belirlenebilir ve süreci hızlandırma fırsatları ortaya çıkarılabilir. Neden önemli? Bu zaman damgası, performans izleme, darboğaz belirleme ve SLA takibi dahil olmak üzere zamana dayalı tüm analizlerin temelini oluşturur. Nereden alınır? Genellikle UDATE ve UTIME alanları kullanılarak CDHDR (Header) ve CDPOS (Item) değişiklik belgesi tablolarından alınır. Bazı olaylarda BKPF gibi tablolardaki oluşturma veya giriş tarihleri (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 belgesi türlerini sınıflandıran koddur. | ||
| Açıklama Belge Türü, SAP'de 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 ifade edebilir. Belge türüne göre analiz yapmak, farklı işlem türlerinin nasıl ele alındığını anlamak için sürecin bölümlere ayrılmasını sağlar. Örneğin alacak dekontu süreci, standart fatura sürecinden önemli ölçüde farklı olabilir. Bu bölümlendirme, daha doğru ve ilgili süreç içgörüleri sunar. 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ığı tablosunda BLART alanında bulunur. Örnekler KRREKG | |||
| Fatura tutarı AmountInCompanyCodeCurrency | Faturanın şirket kodunun yerel para birimindeki toplam brüt tutarıdır. | ||
| Açıklama Bu öznitelik, faturanın toplam değerini gösterir. Fatura işleme operasyonunun finansal etkisini ve ölçeğini anlamak için önemli bir metriktir. Fatura tutarlarının analiz edilmesi, yüksek değerli faturaların daha hızlı işlenmek üzere önceliklendirilmesine, harcama eğilimlerinin belirlenmesine ve süreç sorunlarının finansal değerle ilişkilendirilmesine yardımcı olur. Örneğin yüksek değerli faturaların bloke edilme veya daha uzun onay sürelerine sahip olma olasılığının daha yüksek olup olmadığı incelenebilir. Neden önemli? Sürece finansal bağlam kazandırır ve yüksek değerli faturaların farklı işlenip işlenmediği gibi parasal değere dayalı analizler yapılmasını sağlar. Nereden alınır? Genellikle BSEG tablosundaki ilgili kalemlerin, WRBTR alanının (yerel para birimindeki tutar) toplamından türetilir. Örnekler 1500.75125000.00850.20 | |||
| Kullanıcı adı UserName | Faaliyeti gerçekleştiren kişi veya sistemin SAP kullanıcı kimliğidir. | ||
| 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 olabileceği gibi otomatik toplu işler için bir sistem kimliği de olabilir. Kullanıcı bazında 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 istisnaları sıkça ele aldığını veya hangi faturaların otomatik işlendiğini, örneğin 'BATCHUSER' kullanıcısını, gösterebilir. Bu bilgi, 'Invoice Automation Rate' KPI'ını hesaplamak için önemlidir. Neden önemli? Süreç faaliyetlerini belirli kullanıcılara veya sistem hesaplarına bağlar; iş yükü analizini, performans karşılaştırmasını ve otomasyon tespitini mümkün kılar. Nereden alınır? BKPF-USNAM (Entered by) veya CDHDR-USERNAME (Changed by) gibi alanlardan alınır. Örnekler SMITHJMUELLERTWF-BATCH | |||
| Ödeme blokesi nedeni PaymentBlockReason | Bir faturanın neden ödemeye kapatıldığını gösteren koddur. | ||
| Açıklama Bir fatura ödeme için bloke edildiğinde bu öznitelik, 'Miktar uyuşmazlığı' veya 'Fiyat uyuşmazlığı' gibi blokajın özel nedenini gösterir. Bu nedenler, istisna yönetimini standartlaştırmak için SAP içinde yapılandırılır. Bu öznitelik, 'Ödeme blokajı oluşumu ve süresi' Dashboardı için büyük önem taşır. Farklı blokaj 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. Böylece hedefli düzeltici işlemler yapılabilir. Neden önemli? Ödeme blokelerinin belirli temel nedenini gösterir; gecikmeleri azaltmak ve ilk seferde doğru işlem oranını iyileştirmek için hedefli analiz yapılmasını sağlar. Nereden alınır? BSEG tablosundaki tedarikçi kaleminde, ZLSPR alanında (Payment Block Key) bulunur. Örnekler RIA | |||
| Ödeme vade tarihi PaymentDueDate | Faturanın vadesi geçmeden ödenmesi gereken tarihtir. | ||
| Açıklama Ödeme vadesi, fatura tarihine ve üzerinde anlaşılmış ödeme koşullarına göre tedarikçiye ödemenin yapılması gereken hesaplanmış tarihtir. Süreçte önemli bir son tarih olarak kullanılır. Bu öznitelik, 'Zamanında ödeme oranı' temel performans göstergesi 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 becerisini ölçebilir. Bu da tedarikçi ilişkilerini ve finansal itibarı etkiler. Neden önemli? Vadesinde ödeme performansını ölçmek için temel kıstastı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 ZFBDT alanında (vade tarihi hesaplaması için başlangıç tarihi) doğrudan bulunur. Net vade tarihi, bu başlangıç tarihi ve ödeme koşullarından 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ıdır. | ||
| Açıklama Purchasing Document 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üyle doğrulandığı üçlü eşleştirme süreci için temel niteliktedir. Bu özniteliğe göre analiz yapmak, satın alma siparişine dayalı ve siparişe dayalı olmayan faturalarla ilgili sorunların anlaşılmasına yardımcı olur. Eşleştirme uyumsuzluklarını incelemek ve sürecin satın alma bölümünün verimliliğini anlamak için önemlidir. Neden önemli? Faturayı satın alma sürecine bağlar; eşleştirme uyumsuzluklarını ve satın alma siparişi uyumluluğunu analiz etmek için gereklidir. Nereden alınır? Bu bilgi genellikle BSEG belge segment tablosunda, EBELN alanında (Purchase Document Number) bulunur. Örnekler 450000123445000056784500009012 | |||
| Şirket kodu CompanyCode | Mali tabloların hazırlandığı, hukuken bağımsız bir şirketi temsil eden organizasyon birimidir. | ||
| Açıklama Şirket Kodu, SAP Finance içindeki temel organizasyon birimlerinden biridir. Her fatura, işlemden sorumlu tüzel kişiyi belirleyen belirli bir şirket koduna atanır. Process Mining kapsamında Şirket Kodu'na göre filtreleme yapmak veya karşılaştırma yapmak, farklı iş birimleri, tüzel kişiler ya da ülkeler arasındaki süreç performansını analiz etmek için gereklidir. Bölgesel verimlilik, uyumluluk ve otomasyon düzeyi farklılıklarını belirlemeye yardımcı olur ve hedefli iyileştirme çalışmalarını destekler. Neden önemli? Kurum içindeki farklı tüzel kişiler veya coğrafi lokasyonlar arasında fatura işleme performansını bölümlere ayırmayı ve karşılaştırmayı sağlar. Nereden alınır? BKPF belge başlığı tablosunda BUKRS alanında bulunan standart bir alandır. Örnekler 1000US01DE01 | |||
| Tedarikçi numarası VendorNumber | Faturayı gönderen tedarikçinin benzersiz tanımlayıcısıdır. | ||
| 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, 'Vendor Payment Performance' değerlendirmesi veya istisnalara ya da ödeme bloklarına yol açan sorunlu faturaları sıkça gönderen tedarikçilerin belirlenmesi gibi tedarikçi odaklı analizler için önemlidir. Tedarikçi ilişkilerinin yönetilmesine ve tedarikçi güvenilirliğinin değerlendirilmesine yardımcı olur. Neden önemli? Süreç performansının tedarikçi bazında analiz edilmesini sağlar; kalıpları belirlemeye, ilişkileri yönetmeye ve tedarikçi kaynaklı sorunları değerlendirmeye yardımcı olur. Nereden alınır? Genellikle BSEG muhasebe belgesi segment tablosunda, LIFNR alanında bulunur. Örnekler 100345700012V9832 | |||
| Çıkarma zaman damgası ExtractionTimestamp | Verilerin kaynak sistemden çıkarıldığı tarih ve saattir. | ||
| Açıklama Bu öznitelik, veri çıkarma olayının zaman damgasını kaydeder. Process Mining aracında analiz edilen verilerin güncelliğini gösterir. Analizde, oluşturulan içgörülerin ne kadar güncel olduğunu anlamak için kullanılır. Operasyonel izleme Dashboardlarında kararların güncel bilgilere dayanmasını ve veri yenileme döngülerinin etkili biçimde yönetilmesini sağlamak açısından büyük önem taşır. Neden önemli? Verilerin güncelliğini gösterir ve analiz ile raporlamanın mevcut en güncel bilgilere dayanmasını sağlar. Nereden alınır? Bu, SAP alanı değildir. Veri çekme 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 tarihi InvoiceDate | Tedarikçinin fatura belgesini düzenlediği tarihtir. | ||
| Açıklama Fatura Tarihi veya belge tarihi, tedarikçinin fatura üzerinde belirttiği tarihtir. Üzerinde anlaşılan ödeme koşullarına göre ödeme vade tarihinin hesaplanmasında başlangıç noktası olarak kullanılır. Analizde bu tarih, fatura yaşını ve erken ödeme indirimlerinden yararlanma durumunu belirlemek gibi finansal hesaplamalar için temel niteliktedir. 'Early Payment Discount Capture Rate' KPI'ı için önemli bir girdidir. Neden önemli? Ödeme koşullarını ve vade tarihlerini hesaplamak için temel alınır. İşletme sermayesini yönetmek ve indirimlerden yararlanmak açısından önemlidir. Nereden alınır? BKPF belge başlığı tablosunda BLDAT alanında (Document Date) bulunur. Örnekler 2023-04-122023-05-152023-06-20 | |||
| Kapatma belgesi no. ClearingDocumentNumber | Faturayı kapatan ve genellikle ödeme belgesini ifade eden belgenin numarasıdır. | ||
| Açıklama Kapatma Belgesi Numarası, açık bir fatura kalemini kapatan işleme, neredeyse her zaman ödeme belgesine bağlar. Bu bağlantı, faturanın ödendiğini doğrular. Bu öznitelik, fatura ile ödeme arasındaki kesin bağlantıdır. 'Payment Executed' faaliyetini ve buna karşılık gelen 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ı belirli ödeme işlemine bağlar. Bu bilgi, çevrim süresi ve ödeme performansı analizleri için önemlidir. Nereden alınır? BSEG belge segment tablosunda, AUGBL alanında (Clearing Document Number) bulunur. Örnekler 150000000115000000231500000088 | |||
| Kaynak sistem kimliği SourceSystemId | Verilerin çıkarıldığı kaynak SAP S/4HANA sisteminin tanımlayıcısıdır. | ||
| Açıklama Bu öznitelik, örneğin 'S4H_PROD' veya 'ERP_EU' gibi kaynak sistemi belirtir. Birden fazla ERP örneğinin veya eski ve modern sistemlerin birlikte kullanıldığı ortamlarda özellikle önemlidir. Analiz sırasında farklı sistemler ya da bölgeler arasındaki süreç performansının karşılaştırılmasını sağlar. Veri kaynağının izlenebilirliğini güvence altına alır ve birden fazla kaynaktan gelen veriler merkezi bir Process Mining platformunda birleştirildiğinde veri yönetişimi ve sorun giderme için önem taşır. Neden önemli? Verilerin kaynağı hakkında bilgi sağlar. Bu bilgi, veri yönetişimi ve farklı sistemler ya da şirket lokasyonları arasındaki süreçleri karşılaştırmak için gereklidir. Nereden alınır? Genellikle veri çıkarma sırasında SAP sistem kimliğinden (sy-sysid) türetilir veya ETL pipeline'ında statik bir değer olarak yapılandırılır. Örnekler S4PS4H_PROD_100ECC_EU | |||
| Ödeme koşulları PaymentTerms | Tedarikçiyle üzerinde anlaşılan vade tarihleri ve indirim dönemleri gibi ödeme koşullarını tanımlayan koddur. | ||
| Açıklama Ödeme Koşulları, erken ödeme indirimleri dahil olmak üzere bir faturanın nasıl ödeneceğine ilişkin kuralları tanımlar. Örneğin 'Z030', '30 gün içinde net ödenir' anlamına gelebilir. Bu öznitelik, finansal planlama ve işletme sermayesinin optimize edilmesi için gereklidir. Process Mining kapsamında 'Payment Due Date' hesaplamak ve erken ödeme indirimlerinden yararlanma durumunu belirlemek için kullanılır; böylece 'Early Payment Discount Capture Rate' KPI'ını doğrudan destekler. Neden önemli? Ödeme vade tarihleri ve indirim kurallarını 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 alanında (Terms of Payment Key) bulunur. Örnekler 0001Z030NT60 | |||
| Onay döngüsü sayısı ApprovalCycleCount | Bir faturanın kaç kez onaya gönderildiğini gösteren sayıdır. | ||
| Açıklama Bu metrik, tek bir fatura için 'Invoice Sent For Approval' faaliyetinin gerçekleşme sayısını hesaplar. Birden büyük değer, faturanın en az bir kez reddedildiğini veya geri gönderildiğini ve yeni bir onay döngüsü gerektiğini gösterir. Bu öznitelik, 'First-Pass Approval Rate' KPI'ını doğrudan destekler. Onay döngüsü sayısı yüksek faturalar analiz edilerek yetersiz bilgi veya hatalı kodlama gibi başarısız onay nedenleri belirlenebilir ve süreci iyileştirmek için adımlar atılabilir. Neden önemli? Onay alt sürecindeki yeniden işlemeyi ölçer; ilk seferde doğru işlem oranının değerlendirilmesine ve onay retlerinin nedenlerinin belirlenmesine yardımcı olur. Nereden alınır? Her benzersiz InvoiceNumber için 'Invoice Sent For Approval' faaliyetinin gerçekleşme sayısı hesaplanarak bulunur. Örnekler 123 | |||
| Otomatik mi IsAutomated | Bir faaliyetin otomatik bir sistem kullanıcısı tarafından gerçekleştirilip gerçekleştirilmediğini gösteren işarettir. | ||
| Açıklama Bu Boolean öznitelik, bir faaliyetle ilişkilendirilen kullanıcı 'WF-BATCH' veya 'SAP_SYSTEM' gibi bilinen bir sistem ya da toplu iş hesabıysa true değerini alır. Manuel ve otomatik süreç adımlarını ayırt etmeye yardımcı olur. Bu öznitelik, 'Invoice Automation Rate' KPI'ını hesaplamak için gereklidir. Sürecin hangi bölümlerinin otomatik olduğunu analiz ederek otomasyon çalışmalarının başarısı ölçülebilir, manuel iş yükünü azaltmak ve verimliliği artırmak için yeni fırsatlar belirlenebilir. Neden önemli? Manuel ve sistem tarafından yürütülen faaliyetleri ayırt eder. Otomasyon oranlarını ölçmek ve daha fazla otomasyon fırsatlarını belirlemek için temel niteliktedir. Nereden alınır? UserName özniteliğinden türetilir. Belirli kullanıcı kimliklerini 'automated' olarak sınıflandırmak için bir eşleştirme veya kural oluşturulur. Örnekler truefalse | |||
| Ters kayıt nedeni ReversalReason | Bir fatura belgesinin neden ters kaydedildiğini gösteren koddur. | ||
| Açıklama Bir fatura yanlış kaydedildiyse çoğu zaman ters kaydedilir. Ters Kayıt Nedeni kodu, örneğin 'Incorrect posting date' veya 'Data entry error' gibi bu işlemin nedenini açıklar. Ters kayıt nedenlerini analiz etmek, fatura kaydetme sürecindeki hata kalıplarını belirlemeye yardımcı olur. Bu içgörü, eğitimleri iyileştirmek, sistem kontrollerini geliştirmek veya finansal yeniden işleme ve idari yük oluşturan tekrarlayan sorunları gidermek için kullanılabilir. Neden önemli? Faturaların neden iptal edildiğini açıklar ve kaydetme sürecindeki hata ve yeniden işleme kaynakları hakkında doğrudan bilgi sağlar. Nereden alınır? Orijinal belgenin BKPF tablosundaki başlığında, STGRD alanında (Reversal reason) bulunur. Örnekler 010205 | |||
| Vadesinde ödendi mi IsPaidOnTime | Faturanın ödeme vade tarihinde veya bu tarihten önce ödenmesi durumunda true değerini alan işarettir. | ||
| Açıklama Bu Boolean öznitelik, gerçek ödeme tarihiyle ('Payment Executed' faaliyetinin zaman damgası) 'Payment Due Date' karşılaştırılarak elde edilir. Her faturanın ödeme durumu için net ve ikili bir sonuç sağlar. 'On-Time Payment Rate' KPI'ının temel hesaplamasıdır. Gecikmiş ödemelerin ortak tedarikçiler, şirket kodları veya gecikmeyle ilişkili fatura tutarları gibi özelliklerini anlamak için kolay filtreleme ve analiz yapılmasını sağlar. Neden önemli? Ödeme koşullarına uyumu doğrudan ölçer. Tedarikçi ilişkileri yönetimi ve finansal operasyonlar için önemli bir KPI'dır. Nereden alınır? 'Payment Executed' faaliyetinin EventTime değeri ile PaymentDueDate özniteliği karşılaştırılarak hesaplanır. (Payment Date <= PaymentDueDate). Örnekler truefalse | |||
| Yeniden işleme var mı IsRework | Bir faturanın reddedilen onay veya kaldırılan ödeme bloğu gibi yeniden işleme faaliyetlerinden geçip geçmediğini gösteren işarettir. | ||
| Açıklama Bu öznitelik, bir veya daha fazla yeniden işleme döngüsü yaşayan faturaları işaretler. Yeniden işleme, örneğin 'Invoice Rejected' sonrasında 'Invoice Approved' veya 'Payment Block Set' sonrasında 'Payment Block Removed' gibi belirli faaliyet dizileriyle belirlenir. Bu öznitelik, 'Invoice Rework Rate' KPI'ının hesaplanmasını kolaylaştırır. Analistler, yeniden işleme içeren vakaları kolayca ayırıp inceleyerek verimsizliğin ve tekrarlanan manuel iş yükünün temel nedenlerini anlayabilir. Neden önemli? İşin tekrarlanmasını gerektiren verimsiz süreç akışlarını belirler; israfın ölçülmesine ve süreç istisnalarının temel nedenlerinin bulunmasına yardımcı olur. Nereden alınır? Olay günlüğündeki faaliyet dizisine göre hesaplanır. Örneğin bir faturanın izinde 'Invoice Rejected' gerçekleşirse bu işaret true olarak ayarlanır. Örnekler truefalse | |||
Satın Almadan Ödemeye - Fatura işleme faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura belgesi oluşturuldu | Bu, SAP'de bir fatura belgesinin oluşturulmasını gösteren ilk olaydır. Kullanıcı yeni bir fatura belgesini kaydettiğinde yakalanabilir. Belge park edilmiş veya ön muhasebeleştirilmiş durumda olabilir. | ||
| Neden önemli? Bu faaliyet, fatura işleme yaşam döngüsünün başlangıcını gösterir. Bu olay ile diğer olaylar arasındaki süreyi analiz etmek, genel işleme teslim süresini ölçmek için önemlidir. Nereden alınır? Bu olay, belge başlığı tablosundaki, genellikle lojistik faturalar için BKPF veya RBKP'deki oluşturma tarihi ve saatinden (CPUDT, CPUTM) alınır. FB60, MIRO veya MIR7 gibi işlem kodu (BKPF-TCODE), oluşturma yöntemini gösterir. Yakalayın Fatura belgesi için BKPF-CPUDT ve BKPF-CPUTM alanlarındaki oluşturma zaman damgasını kullanın. Olay türü explicit | |||
| Fatura kaydedildi | Bu, park edilen veya onaylanan faturanın General Ledger'a resmen kaydedildiği önemli bir finansal olaydır. Bu işlem, tedarikçiye olan borcu muhasebeleştirir. | ||
| Neden önemli? Kaydetme işlemi, veri girişi ve onay aşamalarını finansal mutabakat aşamasından ayıran önemli bir dönüm noktasıdır. Faturanın oluşturulmasından kaydedilmesine kadar geçen süre, kurum içi işlem verimliliğinin önemli bir ölçüsüdür. Nereden alınır? Bu olay, belge başlığındaki Posting Date (BKPF-BUDAT) alanıyla belirlenir. Önce park edilen belgelerde, posted durumuna geçiş olayın zaman damgasını sağlar. Yakalayın Olay zaman damgası olarak posting date (BKPF-BUDAT) alanını kullanın. Olay türü explicit | |||
| Fatura onaylandı | Bu etkinlik, faturanın yetkili sorumlu tarafından onaylandığını gösterir. Onay iş akışı başarıyla tamamlandığında veya bir serbest bırakma göstergesi ayarlandığında kaydedilir. | ||
| Neden önemli? Bu, faturanın ödeme için serbest bırakılmasını sağlayan önemli bir kilometre taşıdır. Onaylardaki gecikmeler yaygın bir darboğazdır. Bu faaliyetin izlenmesi, yavaş onay veren kişilerin veya süreç adımlarının belirlenmesine 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ında yapılan değişikliklerin izlenmesinden anlaşılabilir. Yakalayın İş akışının tamamlanma olaylarından veya bir belgenin serbest bırakma durumu alanındaki değişikliklerden anlaşılır. Olay türü inferred | |||
| Fatura ters kaydedildi | Daha önce kaydedilmiş bir fatura belgesinin ters kaydını temsil eden faaliyettir. Bu, hatalı bir fatura için son olaydır; fatura çoğu zaman doğru bilgilerle yeniden girilir. | ||
| Neden önemli? Ters kayıtlar, sürecin önceki aşamalarında fark edilmeyen önemli hatalara işaret eder. Bunların sıklığını ve temel nedenlerini izlemek, süreci iyileştirmek ve finansal hataları azaltmak için gereklidir. Nereden alınır? Ters kayıt, bir ters kayıt belgesi oluşturulduğunda belirlenir. Orijinal belge başlığında (BKPF) ters kayıt belgesi numarası (BKPF-STBLG) bulunur ve bunun tersi de geçerlidir. Ters kayıt belgesinin posting date alanı olay zamanıdır. Yakalayın BKPF-STBLG alanında değer bulunan belgeleri belirleyin ve ters kayıt belgesinin posting date alanını kullanın. Olay türü explicit | |||
| Ödeme gerçekleştirildi | Bu, standart süreçte ödemenin yapıldığı ve faturanın kapatıldığı son faaliyettir. Bu işlem, tutarın tedarikçiye ödendiğini gösterir. | ||
| Neden önemli? Bu olay, P2P fatura yaşam döngüsünün sonunu gösterir. Uçtan uca toplam çevrim süresini hesaplamak ve vadesinde ödeme performansını vade tarihiyle karşılaştırarak ölçmek için gereklidir. Nereden alınır? Bu olay, tedarikçi kalemindeki kapatma belgesi bilgilerinden alınır. Clearing Date (BSEG-AUGDT) ve Clearing Document (BSEG-AUGBL), ödemenin yapıldığını gösterir. Yakalayın Kapatılmış tedarikçi kalemindeki clearing date (BSEG-AUGDT) alanını kullanın. Olay türü explicit | |||
| Fatura onaya gönderildi | Bu etkinlik, fatura için resmi bir onay iş akışının başlatıldığını gösterir. Genellikle faturanın durumunun 'onay bekliyor' olarak değişmesi veya bir iş akışı öğesinin oluşturulmasıyla anlaşılır. | ||
| Neden önemli? Onay çevrim süresini ölçmek için başlangıç noktası budur. Onayların ne zaman başladığını anlamak, onay iş akışındaki darboğazları belirlemek için gereklidir. Nereden alınır? Bu durum genellikle fatura nesnesiyle (ör. BUS2081) ilişkilendirilmiş bir SAP Business Workflow başlangıcından (SWW_WI2OBJ tablosu) veya belge başlığındaki özel bir durum alanında yapılan değişiklikten anlaşılır. Yakalayın Fatura belgesiyle ilişkili bir Workflow öğesinin oluşturulmasından çıkarım yapın. Olay türü inferred | |||
| Fatura park edildi | Sisteme girilmiş ancak henüz genel muhasebeye kaydedilmemiş bir faturayı ifade eder. Park etme işlemi, eksik faturaları kaydetmek veya muhasebeleştirme öncesinde daha sonra incelemek için 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, resmi muhasebeleştirme ve onay döngüsü başlamadan önceki gecikme nedenlerini belirlemeye yardımcı olur. Nereden alınır? Bu durum, park etme işlemleriyle oluşturulan belgelerden (ör. MIR7, FV60) veya BKPF tablosundaki belirli durum alanlarının ya da VBKPF gibi park edilmiş belgelere ayrılmış tabloların kontrol edilmesiyle belirlenebilir. Yakalayın Park etme işlemleriyle oluşturulan belgeleri belirleyin veya park edilmiş belge durumunu kontrol edin. Olay türü explicit | |||
| Fatura reddedildi | Onay süreci sırasında bir faturanın reddedilmesini ifade eder. Bu olay yeniden işlemeyi tetikler ve düzeltme ile yeniden gönderim gerektirir. | ||
| Neden önemli? Fatura retleri, 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 ederek belgeyi işlem sorumlusuna geri gönderen olaylardan anlaşılır. Yakalayın Reddedilmeyi gösteren Workflow durumu değişikliklerinden çıkarım yapın. Olay türü inferred | |||
| Fatura verileri güncellendi | Bu faaliyet, fatura belgesinin ilk oluşturulmasından sonra yapılan bir değişikliği gösterir. Ret sonrasındaki yeniden işleme döngülerinde veya hataların düzeltilmesi sırasında sık görülür. | ||
| Neden önemli? Sık yapılan güncellemeler, yeniden işlemeye ve veri giriş noktasındaki olası veri kalitesi sorunlarına işaret eder. Bu değişiklikleri izlemek, düzeltmeler için harcanan çabayı ölçmeye ve yaygın hataları belirlemeye yardımcı olur. Nereden alınır? Temel alanlardaki değişiklikler SAP'nin değişiklik belgesi tabloları CDHDR (başlık) ve CDPOS (kalem) içinde günlüğe kaydedilir. İlgili fatura nesnesindeki değişiklikler filtrelenerek olaylar oluşturulabilir. Yakalayın Fatura nesnesi için CDHDR ve CDPOS tablolarından değişiklik olaylarını çıkarın. Olay türü explicit | |||
| Geç ödeme gerçekleştirildi | Bu, bir faturanın ödemesi hesaplanan vade tarihinden sonra gerçekleştirildiğinde oluşan hesaplanmış bir olaydır. İki tarih alanı karşılaştırılarak türetilir. | ||
| Neden önemli? Bu faaliyet, vadesinde ödeme KPI'larını doğrudan destekler ve tedarikçi ilişkilerine zarar verebilecek, cezalara yol açabilecek sık gecikmiş ödemeleri yapan tedarikçileri veya iş birimlerini belirlemeye yardımcı olur. Nereden alınır? Bu değer, Clearing Date (BSEG-AUGDT) ile Net Due Date karşılaştırılarak hesaplanır. Vade tarihi ise Baseline Date (BSEG-ZFBDT) ve ödeme koşullarından (BSEG-ZTERM) hesaplanır. Yakalayın BSEG-AUGDT > (BSEG-ZFBDT + ödeme koşulundaki gün sayısı) karşılaştırmasıyla türetin. Olay türü calculated | |||
| Ödeme blokesi ayarlandı | Bir faturanın ödenmesini engellemek amacıyla üzerine bilerek bloke konulmasını ifade eden faaliyettir. Bunun nedeni çoğunlukla fiyat veya miktar tutarsızlıkları ya da bekleyen bir alacak dekontudur. | ||
| Neden önemli? Ödeme blokeleri, geç ödemelerin ve tedarikçi anlaşmazlıklarının başlıca nedenlerindendir. Blokelerin sıklığını, süresini ve nedenlerini analiz etmek, zamanında ödeme oranlarını iyileştirmek için önemlidir. Nereden alınır? Bu olay, fatura kalemindeki Payment Block Key alanında (BSEG-ZLSPR) yapılan değişikliklerin izlenmesiyle yakalanır. CDHDR ve CDPOS içindeki değişiklik günlükleri, blokenin ne zaman ve hangi kullanıcı tarafından konulduğuna ilişkin zaman damgasını ve kullanıcı bilgisini sağlar. Yakalayın BSEG-ZLSPR alanının değişiklik belgeleri (CDHDR/CDPOS) üzerinden doldurulduğu zamanı belirleyin. Olay türü explicit | |||
| Ödeme blokesi kaldırıldı | Daha önce konulmuş bir ödeme blokesinin kaldırıldığı ve sorunun çözüldüğü durumu ifade eder. Böylece fatura yeniden ödeme için uygun hale gelir. | ||
| Neden önemli? Bir bloğun konulması ile kaldırılması arasındaki süre, süreç istisnasının çözüm süresini ifade eder. Bu süreyi kısaltmak, verimliliği ve tedarikçi ilişkilerini iyileştirmek için önemlidir. Nereden alınır? Bu olay, Payment Block Key alanı (BSEG-ZLSPR) temizlendiğinde kaydedilir. Bu değişiklik CDHDR ve CDPOS tablolarına yazılır ve bloğun kaldırıldığı zaman damgasını sağlar. Yakalayın BSEG-ZLSPR alanının değişiklik belgeleri (CDHDR/CDPOS) üzerinden ne zaman temizlendiğini belirleyin. Olay türü explicit | |||
| Ödeme teklifi oluşturuldu | Fatura, bir ödeme çalışmasının parçası olarak seçilir ve ödeme teklifine dahil edilir. Bu, otomatik ödeme sürecinin ilk adımıdır. | ||
| Neden önemli? Bu faaliyet, ödeme niyetini gösterir. Bu adım ile nihai ödeme işlemi arasındaki gecikmeler, ödeme çalışması sürecindeki, onaylardaki veya banka iletişimindeki sorunları ortaya çıkarabilir. Nereden alınır? Bu bilgi, özellikle ödeme teklifine dahil edilen kalemleri içeren REGUP olmak üzere ödeme çalışması tablolarında bulunabilir. İlgili REGUH tablosundaki çalışma tarihi zaman damgasını sağlar. Yakalayın Bir ödeme teklifi çalışmasından sonra faturanın REGUP tablosunda göründüğü zamanı belirleyin. Olay türü explicit | |||
Çıkarma rehberleri
Adımlar
- Ön koşullar ve yetkilendirme: Çıkarma işlemini gerçekleştiren kullanıcının, gerekli Core Data Services (CDS) View'larına erişmek için SAP S/4HANA'da gerekli yetkilere sahip olduğundan emin olun. Temel View'lar arasında
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemveI_PaymentProposalItembulunur. Kullanıcının ayrıca OData servisi veya doğrudan SQL bağlantısı gibi seçilen arayüz üzerinden sorgu çalıştırma izinleri olmalıdır. - Bağlantı yönteminizi 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 connector kullanan üçüncü taraf bir ETL aracı veya kuruluşunuzun güvenlik politikaları izin veriyorsa SAP HANA veritabanına doğrudan SQL bağlantısı bulunur.
- Çıkarma parametrelerini tanımlayın: Sorguyu çalıştırmadan önce temel parametreleri belirleyin. Çıkarma için tarih aralığını, örneğin
CreationDatedeğerinin'YYYY-MM-DD'ile'YYYY-MM-DD'arasında olacağını belirtin. Ayrıca veri çıkarma kapsamını sınırlamak için dahil etmek istediğiniz belirliCompanyCodedeğ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. Belirli SAP yapılandırmanıza göre Workflow durumu için alan adlarını da uyarlamanız gerekebilir. - Sorguyu çalıştırın: Tam SQL sorgusunu SAP S/4HANA veritabanında veya uygun servis 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ı etkinlikler de bulunduğunu doğrulayın. - Veri dönüşümünü kontrol edin: Sorgu, temiz bir Event Log biçimi oluşturacak şekilde yapılandırılmıştır. Bununla birlikte
EventTimesütunununYYYY-MM-DDTHH:MM:SSgibi tutarlı bir zaman damgası biçiminde olduğundan emin olun. Sağlanan sorgu, gerektiğinde 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ı 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şleyin.
Yapılandırma
- Kullanılan CDS View'ları: Temel veri kaynakları standart SAP CDS View'larıdır. Başlıca View'lar, başlık verileri için
I_InvoiceDocument, finansal kayıt ve mahsup ayrıntıları içinI_OperationalAcctgDocItem, ödeme blokeleri ve Workflow durumu gibi fatura özniteliklerindeki geçmiş değişiklikleri izlemek içinI_ChangeDocumentileI_ChangeDocumentItem'dır. - Tarih aralığı filtresi: Performansı yönetmek için verileri belirli bir tarih aralığına göre filtrelemek önemlidir. Sağlanan sorgu,
I_InvoiceDocumentView'ındakiCreationDateiçin bir yer tutucu kullanır. Başlangıç için 3 ila 6 aylık veri önerilir. - Şirket kodu filtresi: Çıkarma işleminin ilgili ve yönetilebilir olması için her zaman bir veya daha fazla
CompanyCodeile filtreleyin. Sorgu, bu amaçlaWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')yer tutucusunu içerir. - Belge türü filtresi:
InvoiceDocumentTypealanına göre filtreleyerek çıkarmayı daha da daraltabilirsiniz. Örneğin standart tedarikçi faturalarını (RE) dahil edip alacak dekontlarını hariç tutmak isteyebilirsiniz. Bu filtre, başlangıç CTE'sininWHEREkoşuluna eklenebilir. - Ön koşullar: Sorguyu çalıştıran kullanıcının, belirtilen şirket kodlarındaki finans ve satın alma belgeleri için uygun görüntüleme yetkilerine sahip olması gerekir. Temel HANA veritabanına SQL istemcisi üzerinden erişim standart değildir ve özel izinler gerektirir.
- Performans hususları: Değişiklik belgesi tablolarından (
I_ChangeDocument,I_ChangeDocumentItem) veri çıkarmak yoğun kaynak kullanabilir. Uzun çalışma sürelerini önlemek için tarih, şirket kodu ve nesne sınıfı (INCOMINGINVOICE) üzerinde sıkı filtreler uygulamak gerekir.
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
- SAP HANA kiracısına veya veritabanı şemasına doğrudan okuma erişiminin onaylandığını doğrulayın ve gerekli SAP tabloları ile onaylanmış değişiklik geçmişi veya iş akışı tabloları için yetkili, salt okunur bir veritabanı kullanıcısı edinin. SAP HANA Database Explorer, SAP HANA Studio veya onaylanmış 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ışı, park etme, ödeme önerisi, ödeme yürütme, değişiklik geçmişi ve ödeme blokajı geçmişi sürüme veya müşteriye özel nesneler kullanabilir. Sorgudaki köşeli parantez içindeki her yer tutucuyu sistem kataloğunda doğrulanmış nesnelerle ve ilgili iş anlamlarıyla değiştirin.
- Veri çıkarma dönemini [Start timestamp] ve [End timestamp] kullanarak tanımlayın. Yeterince geniş bir belge ve olay dönemi çıkarın, normalde üç ila altı ay kullanın. Ödeme vade tarihleri veya geç ödemeler fatura oluşturma döneminin dışına çıkabiliyorsa dönemi genişletin.
- Yapılandırılmış fatura anahtarını kullanarak fatura vakalarını 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 birleştirir. İş tanımını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 üzerinden eşleyin. Fatura başlık bilgileri için RBKP, muhasebe belgesi zaman damgaları ve kullanıcılar için BKPF, mevcut olduğunda tedarikçi, tutar, satın alma belgesi, mahsup ve ödemeyle ilgili muhasebe bilgileri için ACDOCA kullanın. Her alanın her kayıt senaryosunda dolu olduğunu varsaymayın.
- Park etme, onay, ret, güncelleme, ödeme blokajı, ters kayıt, öneri ve ödeme yürütme olaylarını doğrulanmış sisteme özel kaynaklardan eşleyin. Yer tutucu kaynak görünümlerini olay zaman damgalarını, fatura referanslarını, kullanıcıları, durumları ve eski ve yeni değerleri sunan onaylanmış görünümler veya tablolarla değiştirin. ProcessMind olayları kendiliğinden çıkarmaz, bu nedenle her etkinlik açık bir olay satırı olarak oluşturulmalıdır.
- SQL sorgusunun tamamını üretim dışı veya salt okunur bir oturumda çalıştırın. Yürütme planlarını inceleyin ve uygun olduğunda sorguyu şirket kodu, belge türü, mali yıl ve olay zaman damgasına göre sınırlandırın. Büyük yevmiye ve geçmiş tabloları arasında sınırsız birleştirmeler yapmaktan kaçının.
- Sonucu aşağıda açıklanan kontrollerle doğrulayın. Gerekli her sütunun bulunduğunu, her olay için EventTime alanının dolu olduğunu, her vaka için InvoiceNumber alanının dolu olduğunu ve ilgili kaynak verileri mevcut olduğunda 13 etkinlik adının tamamının oluştuğunu doğrulayın.
- Sonucu ProcessMind tarafından desteklenen, tercihen UTF-8 CSV biçiminde, sınırlandırılmış bir dosya olarak dışa aktarın. Her olay için bir satır ve InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason ve PurchasingDocument sütunlarını kullanın. Zaman damgalarını tutarlı bir saat diliminde koruyun ve tanımlayıcılardaki baştaki sıfırları saklayın.
- Event Logu ProcessMind’e yükleyin ve InvoiceNumber alanını vaka tanımlayıcısı, ActivityName alanını etkinlik sütunu, EventTime alanını da zaman damgası sütunu olarak yapılandırın. ProcessMind yapılandırması ek vaka anahtarlarını destekliyorsa veri çıkarma sırasında uygulanan bileşik anahtar politikasının aynısını kullanın.
Yapılandırma
- Tarih aralığı: İlk çıkarma için üç ila altı aylık kayan bir dönem kullanın. Onay, ödeme, mahsup, ters kayıt veya gecikmiş ödeme etkinlikleri fatura oluşturma döneminden sonra gerçekleşebiliyorsa ek geçmiş verileri dahil edin.
- Şirket kapsamı: [Şirket kodu filtresi] ile filtreleyin ve seçilen şirket kodlarının çıkarma için yetkili olduğunu doğrulayın.
- Belge kapsamı: [Belge türü filtresi] ile filtreleyin ve hedef süreçte tedarikçi faturalarını, alacak dekontlarını, park edilmiş faturaları ve ters kayıtları temsil eden belge türlerini dahil edin.
- Vaka tanımlayıcısı: Süreç tanımının gerektirdiği şekilde InvoiceNumber kullanın. Fatura numaraları genel olarak benzersiz değilse şirket kodunu ve mali yılı kaynak sonucunda koruyun veya ProcessMind modeline göre bileşik vaka anahtarı yapılandırın.
- Etkinlik kaynakları: Workflow durumu değişiklikleri, onay kararları, park etme, değişiklik geçmişi, ödeme blokeleri, ödeme önerileri ve ödeme yürütme için fiziksel kaynakları doğrulayın. Bu kaynaklar S/4HANA sürümüne, etkinleştirilen kapsama, Workflow tasarımına ve müşteri uzantılarına göre değişir.
- Zaman damgası politikası: Çıkarma zaman damgası yerine iş etkinliğinin zaman damgasını 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 saklayıp saklamadığını doğrulayın. Toplama kuralı fatura vakası için doğrulanmadıkça yevmiye satırlarını toplamayın.
- Ödeme politikası: Payment Executed etkinliğinin mahsup, ödeme belgesi kaydı, banka üzerinden yürütme veya başka bir iş kilometre taşı anlamına gelip gelmediğini tanımlayın. Kararlaştırılan süreç tanımına uyan kaynağı kullanın.
- Gecikmiş ödeme: Payment Executed, PaymentDueDate sonrasında gerçekleştiğinde Late Payment Executed etkinliğini üretin. Sorgu bu etkinliği açıkça hesaplar ve ProcessMind çıkarımına dayanmaz.
- Performans: Kaynak okumalarını tarih, şirket kodu, belge türü ve ilgili mali yıla göre sınırlayın. Yalnızca gerekli sütunları seçin, sorgu planlarını inceleyin ve kaynak geçmişi büyükse onaylanmış ara View'ları 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 Borçlar Muhasebesi, Genel Muhasebe, satın alma, Workflow ve ödeme verilerine erişim gereklidir. Gerekli SAP lisanslarının, veritabanı erişim politikalarının ve veri koruma onaylarının mevcut olduğ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.
a Ö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 Editor'e erişin: SAP S/4HANA sisteminize giriş yapın.
SE38işlem kodunu (ABAP Editor) açın. - Programı oluşturun: Program alanına yeni programınız için bir ad girin, örneğin
Z_PM_INVOICE_EXTRACT, ardından 'Create' düğmesine tıklayın. Bir başlık girin, Type değerini 'Executable Program' olarak ayarlayın ve programı uygun bir pakete kaydedin. - Program yapısını ve seçim ekranını tanımlayın: Editörde son Event Log çıktısı için veri yapılarını tanımlayın. Ardından kullanıcıların fatura giriş tarihi için tarih aralığı, şirket kodları ve belge türleri gibi parametreleri girebilmesini sağlayan bir seçim ekranı oluşturun. Bu, programı yeniden kullanılabilir ve esnek hale getirir.
- 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: 'Invoice Document Created' ve 'Invoice Posted' gibi temel etkinlikler için
RBKP(Logistics Invoice Header) veBKPF(Accounting Document Header) gibi birincil tablolardan veri seçin. - Değişiklik belgesi verilerini çıkarın: 'Payment Block Set' ve 'Payment Block Removed' gibi etkinlikler için
CDHDR(Change document header) veCDPOS(Change document items) değişiklik belgesi tablolarını sorgulayın. ÖrneğinBSEGtablosundakiZLSPRgibi belirli alanlardaki değişiklikleri belirlemeniz gerekir. - Ödeme verilerini çıkarın: Ödemeyle ilgili etkinlikleri yakalamak için ödeme önerilerinde
REGUP(Processed items from payment program), gerçekleşen ödemelerde iseBSAK(Cleared Vendor Items) gibi tabloları sorgulayın.AUGDTmahsup tarihiniZFBDTnet vade tarihiyle karşılaştırarak 'Late Payment Executed' etkinliğini ayırt edin. - Workflow verilerini çıkarın: Onay etkinlikleri için Workflow öğelerini fatura nesnelerine bağlamak üzere
SWW_WI2OBJgibi SAP Business Workflow tablolarını sorgulayın. Bu bölüm, Workflow yapılandırmanıza büyük ölçüde bağlıdır ve önemli uyarlamalar gerektirebilir. - Verileri Event Log biçiminde birleştirin: Seçilen her etkinlik için verileri 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),ActivityNameveEventTimeiçermelidir. - Çıktı dosyasını oluşturun: Son dahili tablonun içeriğini SAP uygulama sunucusundaki düz dosyaya yazmak için
OPEN DATASET,TRANSFERveCLOSE DATASETABAP ifadelerini kullanın. Virgülle ayrılmış değerler (CSV) biçimi önerilir. - Planlayın ve çalıştırın: Test için programı ön planda çalıştırın (
F8). Üretim çalıştırmaları için sistem performansını etkilememek üzere programıSM36işlem kodunu kullanarak yoğun olmayan saatlerde çalışacak bir arka plan işi olarak planlayın. - Alın ve yükleyin: Dosyanın kaydedildiği uygulama sunucusu dizinine gitmek için
AL11işlem kodunu kullanın. Dosyayı yerel sisteminize indirin. Process Mining aracına yüklemeden önce dosyanın UTF-8 kodlamasına sahip olduğunu ve doğru biçimlendirildiğini doğrulayın.
Yapılandırma
- Tarih aralığı: Çıkarma için fatura giriş tarihine (
RBKP-CPUDT) veya kayıt tarihine (BKPF-BUDAT) göre belirli bir tarih aralığı tanımlayın. İlk analiz için yönetilebilir bir veri hacmi sağlamak üzere 3 ila 6 aylık bir dönem önerilir. - Şirket kodu (BUKRS): Bir veya daha fazla şirket koduna göre filtrelemek önemlidir. Büyük bir kuruluşta tüm şirket kodlarına ait verileri çıkarmak, son derece uzun çalışma sürelerine ve büyük dosyalara yol açabilir.
- Belge türü (BLART): Tedarikçi faturalarını ayırmak için ilgili belge türlerine göre filtreleyin. Yaygın türler arasında 'RE' (Invoice - Gross) ve 'KR' (Vendor Invoice) bulunur. Bu, analizle ilgisiz belgelerin hariç tutulmasına yardımcı olur.
- Tedarikçi hesabı (LIFNR): Program, belirli tedarikçi numaraları için isteğe bağlı bir filtre içerebilir. Bu özellik hedefli analiz veya test için kullanışlıdır.
- Çıktı dosyası yapılandırması: Programda uygulama sunucusundaki çıktı dosyası yolunu ve alan ayırıcısını, örneğin virgül veya noktalı virgül, tanımlayacak parametreler bulunmalıdır.
- Ön koşullar: Bu programı çalıştıran kullanıcı veya sistem hesabının ABAP programları oluşturmak ve çalıştırmak için (
SE38üzerinden) geliştirici erişimine veBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSile Workflow tabloları dahil 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. Başlamaya hazır mısınız?
Fatura işleme sürecinizi bugün optimize etmeye başlayın. Bu Template, operasyonel iyileştirmeler ve daha yüksek verimlilik elde etmenin ilk adımıdır.
SAP S/4HANA'da P2P Fatura İşleme sürecini şimdi optimize edin
Darboğazları belirleyin ve fatura çevrim süresini %30 veya daha fazla azaltın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.