Borçlar Muhasebesi fatura işleme için Veri Templateiniz
Borçlar Muhasebesi fatura işleme için Veri Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- Etkili biçimde izlenecek temel süreç etkinlikleri
- Veri çıkarma için adım adım rehber
Borçlar Muhasebesi fatura işleme öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik ActivityName | Fatura işleme yaşam döngüsünde gerçekleşen belirli bir iş olayının veya adımın adı. | ||
| Açıklama Etkinlik, borçlar muhasebesi sürecindeki 'Fatura alındı', 'Fatura kaydedildi' veya 'Ödeme gerçekleştirildi' gibi belirli bir aşamayı ya da eylemi ifade eder. Süreç haritasını oluşturan temel adımlardır. Etkinlikleri analiz etmek, Process Mining çalışmalarının temelini oluşturur. Süreç akışını görselleştirmenize, yaygın yolları belirlemenize, standart süreçten sapmaları saptamanıza ve her adımın sıklığını ve süresini ölçmenize yardımcı olur. Belirli bir faturaya ait etkinliklerin sıralaması, o faturanın süreç yolculuğunu oluşturur. Neden önemli? Sürecin adımlarını tanımlar; süreç akışını görselleştirmenizi ve analiz etmenizi, darboğazları belirlemenizi ve yeniden çalışma döngülerini saptamanızı sağlar. Nereden alınır? Belge durumu değişiklikleri (ör. BKPF-BSTAT), değişiklik belgeleri (CDHDR/CDPOS tabloları) veya iş akışı günlükleri gibi çeşitli kaynaklardan elde edilir. Genellikle özel bir veri çıkarma mantığı gerektirir. Örnekler Fatura alındıFatura onaylandıÖdeme gerçekleştirildiFaturaya ödeme blokesi kondu | |||
| Fatura Invoice | Fatura belgesinin benzersiz tanımlayıcısıdır ve borçlar muhasebesi sürecindeki temel vaka kimliği olarak kullanılır. | ||
| Açıklama Fatura, teslim alınmasından ödenmesine kadar ilgili tüm etkinlikleri birbirine bağlayan temel nesnedir. SAP S/4HANA’da bu genellikle şirket kodu (BUKRS), benzersiz belge numarası (BELNR) ve mali yıldan (GJAHR) oluşan bileşik bir anahtardır. Faturaya göre analiz, fatura yaşam döngüsünü baştan sona görmenizi sağlar. Toplam çevrim süresi gibi temel metrikleri hesaplamak, tek tek faturalardaki darboğazları belirlemek ve faturaların süreçte izleyebileceği farklı yolları anlamak için bu analiz gereklidir. Neden önemli? Her faturanın yolculuğunu benzersiz biçimde tanımlar; böylece faturanın tüm yaşam döngüsünü izleyebilir ve süreç performansını vaka bazında analiz edebilirsiniz. Nereden alınır? BKPF (Muhasebe Belgesi Başlığı) veya RBKP (Belge Başlığı: Fatura Alımı) tablolarındaki BUKRS, BELNR ve GJAHR alanlarından türetilen bileşik bir anahtardır. Örnekler 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Olay zamanı EventTime | Etkinliğin gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Olay zamanı, her etkinlikle ilişkili zaman damgasıdır ve faturaya ait olayların kronolojik sıralamasını sağlar. Süreç akışını anlamak ve zamana dayalı analizler yapmak için bu veri gereklidir. Analiz sırasında etkinlikleri doğru sıraya koymak, adımlar arasındaki çevrim sürelerini hesaplamak, bekleme sürelerini belirlemek ve süreç performansını farklı dönemlerde (ör. aydan aya) incelemek için olay zamanı kullanılır. Süreye dayalı tüm KPI’ların temelini oluşturur. Neden önemli? Bu zaman damgası, olayları kronolojik sıraya koymak ve çevrim süreleri ile süreler gibi zamana dayalı metrikleri hesaplamak için önemlidir. Bunlar Process Mining çalışmalarının temelini oluşturur. Nereden alınır? SAP tablolarındaki çeşitli tarih ve saat alanlarından alınır. Bunlar arasında oluşturma tarihi (BKPF-CPUDT), kayıt tarihi (BKPF-BUDAT), kapatma tarihi (BSAK-AUGDT) ve değişiklik günlüğü zaman damgaları (CDHDR-UDATE/UTIME) bulunur. Örnekler 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Kaynak sistem SourceSystem | Verinin çıkarıldığı sistem. | ||
| Açıklama Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu görünümde değer genellikle 'SAP S/4HANA' olur. Birden fazla ERP’nin veya entegre sistemin bulunduğu ortamlarda bu alan, veri kökenini izlemek ve verileri ayırmak için önemlidir. Analizin doğru veri seti üzerinde yapılmasını sağlar ve veri kalitesi sorunlarının kaynağa kadar izlenmesine yardımcı olur. Neden önemli? Verinin kaynağını belirtir. Veri yönetişimi, sorun giderme ve birden fazla sistemin kullanıldığı ortamlar için önemlidir. Nereden alınır? Genellikle veri çıkarma sırasında veri setinin kaynağını belirtmek için eklenen sabit bir değerdir. Örnekler SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Son veri güncellemesi LastDataUpdate | Bu kaydın verilerinin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, SAP S/4HANA’dan yapılan en son veri çıkarma veya güncellemenin tarih ve saatini gösterir. Analiz edilen verilerin ne kadar güncel olduğunu anlamak için önemli bir meta veri alanıdır. Bu bilgi, kullanıcıların süreç analizinin ne kadar güncel olduğunu görmesini sağlar. Veri gecikmesine ilişkin beklentileri yönetmeye, veri yenilemelerini planlamaya ve veri bütünlüğünü korumaya yardımcı olur. Neden önemli? Verinin güncelliğini göstererek kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasını sağlar. Nereden alınır? Bu değer, kaynak sistemden veri çıkarıldığı sırada oluşturulur ve her kayda eklenir. Örnekler 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Fatura tutarı InvoiceAmount | Belgenin özgün para birimindeki toplam brüt fatura tutarı. | ||
| Açıklama Bu, tedarikçinin gönderdiği faturanın toplam değeridir. Herhangi bir kesinti veya indirim uygulanmadan önce mal ya da hizmet bedelini, vergileri ve diğer masrafları içerir. Fatura tutarı, çok çeşitli analizlerde kullanılan önemli bir finansal özniteliktir. Yüksek tutarlı faturaları önceliklendirmenize, süreç gecikmelerinin mali etkisini (ör. yüksek tutarlı faturalardaki gecikme ücretleri) anlamanıza ve süreci bölümlere ayırmanıza (ör. 'Yüksek tutarlı faturalar farklı bir onay yolundan mı geçiyor?') yardımcı olur. Olası yinelenen ödemeleri belirlemek için de gereklidir. Neden önemli? Sürece finansal bağlam kazandırır; değere dayalı analiz yapmanızı, yüksek tutarlı faturaları önceliklendirmenizi ve mali etkileri ölçmenizi sağlar. Nereden alınır? MM faturalarında RBKP-RMWWR (brüt fatura tutarı) gibi tablolarda bulunur. FI faturalarında ise BSEG tablosundaki kalemlerden (WRBTR alanı) hesaplanır. Örnekler 1500.00250.7512345.50 | |||
| Fatura vade tarihi InvoiceDueDate | Fatura ödemesinin tedarikçiye yapılması gereken tarih. | ||
| Açıklama Fatura vade tarihi, gecikme ücretlerinden kaçınmak ve tedarikçiyle iyi ilişkileri sürdürmek için ödemenin yapılması gereken son tarihtir. Bu tarih, faturanın temel tarihi ve tedarikçiyle üzerinde anlaşılan ödeme koşulları kullanılarak hesaplanır. Bu tarih, 'Ödeme uyumluluğu ve vade analizi' Dashboardı ile 'Zamanında ödeme oranı' KPI’ı için gereklidir. Vade tarihiyle gerçek ödeme tarihini karşılaştırarak ödemelerin zamanında, erken veya geç yapıldığını ve bunun mali ve ticari ilişkiler üzerindeki etkisini görebilirsiniz. Neden önemli? Zamanında ödeme analizinin temelini oluşturur; ödeme performansını ve bunun tedarikçi ilişkileri ile gecikme ücretleri üzerindeki etkisini ölçmenizi sağlar. Nereden alınır? Bu tarih genellikle hesaplanır. Net vade tarihi BSEG-NETDT alanında bulunur. Ödeme için temel tarih (BSEG-ZFBDT) ve ödeme koşulları (BSEG-ZTERM) kullanılarak da hesaplanabilir. Örnekler 2023-10-312023-11-152024-01-10 | |||
| Kullanıcı adı UserName | Etkinliği gerçekleştiren kişinin kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, fatura kaydetme, onaylama veya kapatma gibi belirli bir etkinliği gerçekleştiren SAP kullanıcı kimliğini kaydeder. Süreç adımlarını ilgili kullanıcılara bağlar. Kullanıcı adına göre analiz yapmak, iş yükünün nasıl dağıldığını anlamak, yüksek performans gösterenleri belirlemek ve ek eğitime ihtiyaç duyabilecek kullanıcıları saptamak için önemlidir. Ayrıca Dashboardlarda onay darboğazlarını analiz etmeye yardımcı olur ve süreçte gecikmeye neden olan onaylayanları belirlemenizi sağlar. Neden önemli? Etkinlikleri belirli kişilere bağlayarak kullanıcı performansını, iş yükünü ve görevlerin ayrılığı politikalarına uyumluluğu analiz etmenizi sağlar. Nereden alınır? Genellikle BKPF-USNAM (Giren) gibi başlık tablolarında veya CDHDR-USERNAME (Değiştiren) gibi değişiklik belgesi tablolarında bulunur. Örnekler ABROWNJSMITHAP_AUTOMATION | |||
| Satın alma siparişi numarası PurchaseOrderNumber | Varsa, faturayla ilişkili satın alma siparişinin benzersiz tanımlayıcısı. | ||
| Açıklama Bu öznitelik, faturayı önceden onaylanmış bir satın alma siparişine (PO) bağlar. PO numarasının bulunması, üçlü eşleştirme sürecinin (PO-fatura-mal girişi) temelini oluşturur. Bu alan, uyumluluk ve verimlilik analizleri için önemlidir. Satın alma politikalarına uyumu ölçen 'Satın alma siparişi olmayan fatura oranı' KPI’ını hesaplamak için kullanılır. Ayrıca PO içeren faturaların eşleştirme sürecini analiz etmeyi sağlayan 'Üçlü eşleştirme performansı' Dashboardının temel alanıdır. Neden önemli? Üçlü eşleştirme verimliliğini analiz etmek ve PO olmadan işlenen faturaları belirleyerek satın alma politikalarına uyumu ölçmek için önemlidir. Nereden alınır? Fatura kalem tablolarında bulunur. MM faturaları için RSEG-EBELN, FI faturaları için BSEG-EBELN alanındadır. Örnekler 45000012344500005678 | |||
| Şirket kodu CompanyCode | Faturanın işlendiği organizasyon birimi. | ||
| Açıklama Şirket kodu, dış raporlama için eksiksiz ve bağımsız bir hesap kümesinin hazırlanabildiği en küçük organizasyon birimidir. Borçlar muhasebesi bağlamında, tedarikçiye borcu olan tüzel kişiliği ifade eder. Şirket koduna göre analiz, kuruluş içindeki farklı tüzel kişiliklerin süreç performansını karşılaştırmanızı sağlar. Böylece hangi birimlerin standart süreçleri izlediğini, hangilerinde verimliliğin daha düşük, çevrim sürelerinin daha uzun veya yeniden çalışma oranlarının daha yüksek olduğunu belirleyebilirsiniz. Neden önemli? Farklı tüzel kişiliklerin süreç performansını karşılaştırmanızı, bölgesel veya iş birimine özgü sorunları ve iyi uygulamaları belirlemenizi sağlar. Nereden alınır? Belge başlık tablolarında bulunur. FI faturaları için genellikle BKPF-BUKRS, MM faturaları için RBKP-BUKRS alanındadır. Örnekler 10001710US01DE01 | |||
| Tedarikçi adı VendorName | Faturayı gönderen tedarikçinin adı. | ||
| Açıklama Bu öznitelik, tedarikçinin resmi adını içerir. Fatura belgesinde kayıtlı tedarikçi numarası üzerinden bağlantı kurulur. Tedarikçi analizi, tedarikçi ilişkilerini yönetmek ve belirli tedarikçilerle ilgili süreç sorunlarını belirlemek için önemlidir. 'Hangi tedarikçiler en çok uyuşmazlık içeren faturayı gönderiyor?' veya 'Belirli stratejik tedarikçilere ödemeleri düzenli olarak zamanında yapıyor muyuz?' gibi soruları yanıtlamaya yardımcı olur. Ayrıca olası yinelenen ödemeleri belirlemek için fatura numarası ve tutarıyla birlikte kullanılan temel alanlardan biridir. Neden önemli? Süreç performansını tedarikçiye göre analiz etmenizi, sorunlu tedarikçileri belirlemenizi ve stratejik tedarikçi ilişkilerini etkili biçimde yönetmenizi sağlar. Nereden alınır? BKPF veya RBKP’de bulunan tedarikçi numarası (LIFNR) üzerinden bağlantı kurularak tedarikçi ana veri tablosu LFA1'den (NAME1 alanı) alınır. Örnekler Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
| Bloke nedeni BlockingReason | Faturanın ödemeye neden bloke edildiğini ve hangi tutarsızlığın bulunduğunu belirtir. | ||
| Açıklama Fatura, üçlü eşleştirme veya diğer doğrulama adımlarında kontrolden geçemezse ödemeye bloke edilir. Bloke nedeni; miktar tutarsızlığı, fiyat farkı veya mal girişinin kaydedilmemesi gibi sorunun niteliğini belirtir. Bu öznitelik, 'Fatura tutarsızlıkları ve yeniden işleme analizi' Dashboardu için önemlidir. Farklı bloke nedenlerinin ne sıklıkta görüldüğünü inceleyerek süreç verimsizliklerinin temel nedenlerini belirleyebilirsiniz. Örneğin, 'Fiyat farkı' sık karşılaşılan bir nedense satın alma sistemindeki ana verilerle ilgili sorunlara işaret edebilir. Neden önemli? Fatura tutarsızlıklarının ve yeniden çalışmanın temel nedenlerini doğrudan göstererek süreç iyileştirme çalışmalarını doğru noktalara yönlendirmenizi sağlar. Nereden alınır? RSEG gibi fatura kalemi tablolarında, SPGR* ile başlayan alanlarda (ör. SPGRP, SPGRQ, SPGRT) saklanır. RBKP_BLOCKED alanında da bulunabilir. Örnekler Fiyat tutarsızlığıMiktar tutarsızlığıMal girişi kaydı eksik | |||
| Fatura belge türü InvoiceDocumentType | Fatura belgesinin SAP’de nasıl işleneceğini belirleyen sınıflandırma. | ||
| Açıklama Belge türü, muhasebe belgelerini sınıflandıran önemli bir SAP yapılandırma öğesidir. Örneğin, tedarikçi faturalarında genellikle 'KR', MM faturalarında 'RE', tedarikçi alacak dekontlarında ise 'KG' kullanılır. Bu tür; numara aralığı ve hangi alanların zorunlu olduğu gibi özellikleri belirler. Süreç analizinde belge türüne göre filtreleme yaparak farklı fatura türlerinin süreç akışlarını karşılaştırabilirsiniz. Örneğin, alacak dekontunun onay süreci standart bir faturanınkinden farklı olabilir. Bu bilgi, 'Fatura onay yönlendirme çeşitleri' Dashboardı için yararlıdır. Neden önemli? Farklı fatura türlerinin nasıl işlendiğine göre süreci bölümlere ayırmanızı, işlem yollarındaki ve çevrim sürelerindeki farklılıkları görmenizi sağlar. Nereden alınır? Doğrudan belge başlık tablosundaki BKPF-BLART alanından alınır. Örnekler KRREKG | |||
| Fatura para birimi InvoiceCurrency | Fatura tutarının para birimi kodu (ör. USD, EUR). | ||
| Açıklama Bu öznitelik, fatura tutarının hangi para biriminde olduğunu belirtir ve finansal değerleri doğru yorumlamak için gerekli bağlamı sağlar. Çok uluslu kuruluşlarda faturaları para birimini dikkate almadan incelemek yanıltıcı olabilir. Bu alan, tüm tutarları tek bir raporlama para birimine dönüştürmenize veya bölgesel finansal faaliyetleri anlamak için analizi para birimine göre ayırmanıza olanak tanır. Neden önemli? Fatura tutarını doğru yorumlamak ve özellikle çok uluslu kuruluşlarda finansal analiz ve raporlama yapmak için gerekli bağlamı sağlar. Nereden alınır? Genellikle BKPF-WAERS veya RBKP-WAERS alanlarında, belge başlığı tablolarında bulunur. Örnekler USDEURGBPJPY | |||
| Geç ödeme mi IsLatePayment | Faturanın vade tarihinden sonra ödenip ödenmediğini belirten bir mantıksal değer. | ||
| Açıklama Hesaplanan bu öznitelik, faturanın resmi vade tarihinden sonra ödenip ödenmediğini doğru/yanlış değeriyle gösterir. 'Mahsup tarihi' ile 'Fatura vadesi' karşılaştırılarak hesaplanır. Bu değer, 'Ödeme uyumluluğu ve vade analizi' Dashboardunda ve 'Zamanında ödeme oranı' temel performans göstergesinde (KPI) analizi kolaylaştırır. Geç ödemeleri saymak, zamanında ödenen faturaların oranını hesaplamak ve geç ödeme oranı yüksek tedarikçileri ya da şirket kodlarını belirlemek için kolayca filtreleme ve toplama yapabilirsiniz. Neden önemli? Ödeme koşullarına uyumu doğrudan ölçer, zamanında ödeme temel performans göstergesinin (KPI) hesaplanmasını kolaylaştırır ve ödeme performansının düşük olduğu alanları belirlemeye yardımcı olur. Nereden alınır? Hesaplanan öznitelik. Mantık: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Örnekler truefalse | |||
| İndirimden yararlanıldı mı DiscountTaken | Erken ödeme indiriminin başarıyla uygulanıp uygulanmadığını belirten bir mantıksal değer. | ||
| Açıklama Bu öznitelik, fatura ödenirken nakit indiriminin gerçekten uygulanıp uygulanmadığını gösterir. Borçlar Muhasebesi sürecinin finansal verimliliğini ölçmek için temel bir bileşendir. Bu değer, 'Erken ödeme indirimi yakalama oranı' temel performans göstergesinin (KPI) merkezindedir. Ödeme koşullarına göre indirimden yararlanma hakkı olan faturaları filtreleyip bu değeri inceleyerek ne kadar tasarruf edildiğini ve kaç fırsatın kaçırıldığını hesaplayabilirsiniz. Böylece Borçlar Muhasebesi performansını açık ve ölçülebilir biçimde değerlendirebilirsiniz. Neden önemli? Kullanılabilir erken ödeme indirimlerinden ne ölçüde yararlanıldığını doğrudan ölçer. Bu da şirketin kârlılığını doğrudan etkiler. Nereden alınır? Ödeme belgesindeki indirim tutarı alanının (BSEG-SKNTO) sıfırdan büyük olup olmadığı kontrol edilerek hesaplanır. Örnekler truefalse | |||
| Mahsup tarihi ClearingDate | Ödemenin yapıldığı ve faturanın açık kalemlerden kapatıldığı tarih. | ||
| Açıklama Mahsup tarihi, faturanın finansal olarak kapatıldığı tarihi gösterir. 'Ödeme kapatıldı' etkinliğinin gerçekleştiği tarihtir ve başarılı fatura süreçlerinin çoğunda son adımı belirtir. Bu tarih, gerçek ödeme tarihini hesaplamak ve fatura vadesiyle karşılaştırmak için kullanılır. Bu nedenle 'Zamanında ödeme oranı' temel performans göstergesini (KPI) ve ödeme performansıyla ilgili analizleri hesaplamak için gereklidir. Ayrıca faturanın uçtan uca çevrim süresini hesaplarken bitiş noktasını belirler. Neden önemli? Faturanın nihai olarak kapatıldığını gösterir; çevrim süresi hesaplamalarında bitiş noktası, zamanında ödeme analizinde ise temel alınan tarihtir. Nereden alınır? Tedarikçiler için BSAK-AUGDT gibi kapatılmış kalem tablolarında bulunur. Örnekler 2023-10-282023-11-142024-01-09 | |||
| Ödeme koşulları PaymentTerms | Faturanın ödenmesi için tedarikçiyle üzerinde anlaşılan koşullar; bu koşullar genellikle indirim fırsatlarını da içerir. | ||
| Açıklama Ödeme koşulları, ödeme vadesini ve erken ödeme indirimlerinden yararlanma olasılığını belirler. Örneğin, 'Z001' koşulu '30 gün içinde ödenir, 10 gün içinde ödenirse %2 indirim' anlamına gelebilir. Bu öznitelik, 'Erken ödeme indirimi yakalama oranı' Dashboardunun temelini oluşturur. Ödeme koşullarını inceleyerek indirimden yararlanma hakkı olan tüm faturaları belirleyebilirsiniz. Bu faturaları fiilen indirim uygulananlarla karşılaştırmak, kaçırılan tasarruf fırsatlarını ortaya çıkarır ve ödeme sürecinin verimliliğini ölçmenizi sağlar. Neden önemli? Erken ödeme indirimi fırsatlarını incelemek, ödeme sürecinin finansal performansını ölçmek ve kaçırılan tasarruf fırsatlarını belirlemek için gereklidir. Nereden alınır? Tedarikçi kalemlerinde, BSEG-ZTERM tablosunda veya RBKP-ZTERM alanındaki fatura başlığında bulunur. Örnekler Z0010001NT30 | |||
| Otomatik mi IsAutomated | Etkinliğin bir kullanıcı yerine sistem tarafından otomatik olarak gerçekleştirilip gerçekleştirilmediğini belirten bir işaret. | ||
| Açıklama Bu Boole özniteliği, kullanıcıların başlattığı etkinliklerle sistem işleri, iş akışları veya botlar tarafından yürütülenleri birbirinden ayırır. Örneğin, otomatik bir ödeme çalıştırması veya sistem tarafından oluşturulan fatura kaydı otomatik olarak işaretlenir. Bu özniteliği analiz ederek borçlar muhasebesi sürecindeki otomasyon düzeyini anlayabilirsiniz. Otomasyon girişimlerinin başarısını ölçmek, otomatik ve manuel adımların verimliliğini karşılaştırmak ve otomasyon için yeni fırsatları belirlemek amacıyla kullanılabilir. Neden önemli? Süreçteki otomasyon düzeyini ölçmeye, otomasyonun etkisini analiz etmeye ve daha fazla iyileştirme fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Kullanıcı adına (ör. 'SAP_SYSTEM' veya 'BATCHUSER' gibi sistem kullanıcı kimlikleri) ya da otomatik işlerle ilişkili belirli işlem kodlarına göre belirlenir. Örnekler truefalse | |||
| Tedarikçi fatura numarası VendorInvoiceNumber | Tedarikçinin kendi belgesinde belirttiği fatura numarası. | ||
| Açıklama Bu, tedarikçinin kendi muhasebe sistemindeki referans numarasıdır ve basılı ya da elektronik fatura belgesinde yer alır. Fatura sisteme alınırken elle girilir veya OCR ile kaydedilir. Bu alan, operasyonel işler ve özellikle 'Olası mükerrer fatura ödemeleri' Dashboardu için büyük önem taşır. Mükerrer faturaları bulmanın yaygın yollarından biri, tedarikçi adı, tedarikçi fatura numarası ve fatura tutarı aynı olan birden fazla iç fatura belgesini aramaktır. Bu numara, faturanın temel dış referansıdır. Neden önemli? Olası mükerrer ödemeleri belirlemeye yardımcı olan temel bir alandır ve tedarikçilerle iletişimde kullanılan başlıca dış referanstır. Nereden alınır? Belge başlığındaki 'Referans' alanında, genellikle BKPF-XBLNR olarak saklanır. Örnekler INV-2023-9876733401120231015-001 | |||
Borçlar Muhasebesi fatura işleme etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura alındı | Bu etkinlik, faturanın SAP’de manuel olarak veya OCR/VIM gibi otomatik bir arayüz aracılığıyla oluşturulduğunu gösterir. Olay genellikle muhasebe belgesi başlığındaki oluşturma tarihi ve saati kullanılarak kaydedilir. | ||
| Neden önemli? Sürecin başlangıç noktası olan bu etkinlik, faturanın uçtan uca çevrim süresini hesaplamak ve tüm borçlar muhasebesi sürecinin işlem hacmini ölçmek için gereklidir. Nereden alınır? Bu olay, muhasebe belgesi başlık tablosu BKPF’den belge oluşturma tarihi (CPUDT) ve saati (CPUTM) kullanılarak kaydedilir. Kaydedin Fatura belgesinin oluşturulma zaman damgasını (BKPF-CPUDT, BKPF-CPUTM) kullanın. Olay türü explicit | |||
| Fatura iptal edildi | Fatura belgesi ters kaydedilerek mali etkisi ortadan kaldırılmıştır. Bu, genellikle hatalı girişler veya tedarikçi anlaşmazlıkları nedeniyle sürecin alternatif bitiş durumudur. | ||
| Neden önemli? İptalleri izlemek, yinelenen gönderimler veya yanlış fatura verileri gibi süreç hatalarının nedenlerini belirlemeye ve önceki aşamalardaki sorunları ortaya çıkarmaya yardımcı olur. Nereden alınır? Ters kayıt belgesi oluşturulduğunda açıkça kaydedilir. Orijinal belgenin başlığında (BKPF) ters kayıt belge numarası (STBLG) ve ters kayıt nedeni yer alır. Kaydedin Orijinal belgenin başlığında (BKPF-STBLG) bağlantısı bulunan ters kayıt belgesinin kayıt tarihini belirleyin. Olay türü explicit | |||
| Fatura kaydedildi | Fatura, mali yükümlülük oluşturacak şekilde büyük deftere resmi olarak kaydedilir. Beklemeye alınmış bir belge kaydedilmiş belgeye dönüşür veya doğrudan kayıt yapılır. | ||
| Neden önemli? Bu, önemli bir finansal aşamadır. Şirketin ödeme yükümlülüğünü doğrular ve çoğu zaman ödemenin planlanması için ön koşuldur. Nereden alınır? Bu olay, belge başlığındaki kayıt tarihi (BUDAT) kullanılarak belirlenir (BKPF). Kaydedilmiş bir belgenin belge durumu (BKPF-BSTAT) boştur. Kaydedin Beklemeye alınmamış belgeler için kayıt zaman damgasını (BKPF-BUDAT) kullanın (BKPF-BSTAT boştur). Olay türü explicit | |||
| Fatura onaylandı | Fatura, iş akışı sisteminde gerekli tüm onayları almıştır. Bu, fatura kaydedilmeden veya ödeme blokesi kaldırılmadan önceki son adım olabilir. | ||
| Neden önemli? Bu önemli aşama, onay döngüsünün sona erdiğini gösterir. Onaya yönlendirme ile onay arasındaki süre, verimliliği ölçen önemli bir metriktir. Nereden alınır? SAP Business Workflow günlüklerinde tamamlanma veya son serbest bırakma adımı olarak kaydedilir. Alternatif olarak, yönlendirme sonrasında ödeme blokesi kaldırıldığında da çıkarılabilir. Kaydedin SAP iş akışı günlüklerinden iş akışı tamamlanma olaylarını çıkarın veya son 'serbest bırakma' olayını belirleyin. Olay türü explicit | |||
| Faturaya ödeme blokesi kondu | Sistem faturaya otomatik veya manuel olarak bloke koymuştur; bu nedenle fatura ödenemez. Bloke genellikle fiyat veya miktar uyuşmazlıklarından ya da eksik onaylardan kaynaklanır. | ||
| Neden önemli? Bu, sorunların ve yeniden çalışmanın önemli bir göstergesidir. Bloke nedenlerini ve sürelerini analiz ederek ödeme gecikmelerinin ve süreç verimsizliklerinin temel nedenlerini belirleyebilirsiniz. Nereden alınır? Bu durum, muhasebe belgesinin tedarikçi kalemindeki Ödeme blokesi anahtarı alanında (ZLSPR) açıkça kaydedilir (BSEG tablosu). Kaydedin BSEG-ZLSPR alanına bloke nedeni girildiğinde değişiklik belgeleri aracılığıyla kaydedilir. Olay türü explicit | |||
| Ödeme gerçekleştirildi | Fatura için ödeme yapılmıştır. Ödeme çalıştırması tamamlandığında ve ödeme belgesi oluşturulup kaydedildiğinde bu olay kaydedilir. | ||
| Neden önemli? Bu etkinlik, nakit akışı analizi ve bu tarihin faturanın vade tarihiyle karşılaştırılması yoluyla 'Zamanında ödeme oranı' KPI’ının ölçülmesi için önemlidir. Nereden alınır? Faturayı kapatan ödeme belgesinin kayıt tarihinden alınır. Ödeme belgesi numarası, fatura kalemindeki kapatma belgesi alanında (AUGBL) yer alır (BSEG). Kaydedin Fatura kalemini kapatan ödeme belgesinin kayıt tarihini (BUDAT) belirleyin. Olay türü explicit | |||
| Ödeme kapatıldı | Bu etkinlik, alt defterde ödeme ile faturanın karşılıklı olarak kapatıldığı ve faturanın tamamen sonuçlandığı aşamayı gösterir. Sürecin tamamlandığı anlamına gelir. | ||
| Neden önemli? Sürecin kesin bitiş noktası olan bu etkinlik, uçtan uca çevrim süresini doğru hesaplamak için gereklidir. Yükümlülüğün yerine getirildiğini doğrular. Nereden alınır? Fatura belgesinin tedarikçi kalemindeki Kapatma tarihi (AUGDT) alanı doldurulduğunda açıkça kaydedilen bir olaydır (BSEG tablosu). Kaydedin Fatura kalemindeki kapatma tarihini (BSEG-AUGDT) kullanın. Olay türü explicit | |||
| Fatura beklemeye alındı | Faturanın sisteme girildiğini ancak henüz büyük deftere kaydedilmediğini gösterir. Bu adım genellikle eksik bir belgeyi daha sonra işlemek veya onaylatmak üzere kaydetmek için kullanılır. | ||
| Neden önemli? Beklemeye alınan faturaları izlemek, resmi kayıt süreci başlamadan önceki gecikmeleri belirlemeye yardımcı olur; veri eksikliği veya ilk doğrulama aşamasındaki sorunları da ortaya çıkarabilir. Nereden alınır? Bu durum, muhasebe belgesi başlığındaki durum alanından çıkarılır (BKPF-BSTAT = 'V', beklemeye alınmış). Olay, durum ayarlandığında gerçekleşir. Kaydedin BSTAT alanının 'V' (Vor-erfasst/önceden girilmiş) olarak ayarlandığı BKPF tablosuna ait değişiklik belgelerini belirleyin. Olay türü inferred | |||
| Fatura onaya yönlendirildi | Fatura, iş kurallarına göre gerekli onayların alınması için bir iş akışına gönderilmiştir. Bu, onay alt sürecinin başlangıcını gösterir. | ||
| Neden önemli? Bu etkinlik, 'Ortalama fatura onay süresi' KPI’ını ölçmek ve onay darboğazlarını analiz etmek için başlangıç noktasıdır. Nereden alınır? Fatura nesnesine (ör. BUS2081) bağlı bir iş akışı örneğinin başlangıcını kaydeden SAP Business Workflow günlüklerinden (SWW* tabloları) alınabilir. Kaydedin Fatura belgesine bağlı SAP iş akışı günlüklerinden (ör. SWW_WIHEAD tablosu) iş akışı başlangıç olaylarını çıkarın. Olay türü explicit | |||
| Fatura reddedildi | Onaylayan kişi, onay iş akışı sırasında faturayı reddetmiştir. Bu işlem genellikle faturanın düzeltilmesi veya açıklığa kavuşturulması için işleyene geri gönderilmesini sağlar. | ||
| Neden önemli? Retleri izlemek, onay sürecindeki yeniden çalışma döngülerini ortaya çıkarır ve politika uyumluluğuyla ilgili sorunlara ya da faturaların yanlış kodlanmasına işaret edebilir. Nereden alınır? Faturayla ilişkili SAP Business Workflow günlüklerinde belirli bir sonuç olayı olarak kaydedilir. Kaydedin SAP iş akışı günlüklerinden 'reddedildi' durumundaki iş akışı olaylarını çıkarın. Olay türü explicit | |||
| Faturanın vade tarihi geçti | Faturanın net vade tarihinin geçtiğini ve faturaya karşılık bir ödemenin kapatılmadığını gösteren hesaplanmış bir olaydır. Ödemenin geciktiği veya vadesinin geçtiği anlamına gelir. | ||
| Neden önemli? 'Ödeme uyumluluğu ve vade analizi' Dashboardı için gerekli olan bu etkinlik, vadesi geçmiş faturaları önceden belirleyip yönetmeye ve geç ödemelerin temel nedenlerini analiz etmeye yardımcı olur. Nereden alınır? SAP’de açıkça kaydedilen bir olay değildir. Sistemin geçerli tarihi, net vade tarihiyle karşılaştırılarak hesaplanır (BSEG-ZFBDT veya temel tarih ve ödeme koşullarından hesaplanır). Kaydedin Olayın zaman damgası faturanın net vade tarihinden sonraysa tetiklenen hesaplanmış olay. Olay türü calculated | |||
| Mal girişiyle eşleştirildi | Bu etkinlik, fatura miktarlarının ve tutarlarının ilgili mal girişi belgesiyle başarıyla eşleştirildiğini gösterir. Üçlü eşleştirme senaryosundaki son doğrulama adımıdır. | ||
| Neden önemli? Bu etkinliği izlemek, üçlü eşleştirme sürecindeki verimsizlikleri belirlemeye ve teslim alınan mallarla tedarikçinin faturalandırdığı miktarlar arasındaki uyuşmazlıkları ortaya çıkarmaya yardımcı olur. Nereden alınır? Fatura kaleminde malzeme belgesi (mal girişi) referansı bulunmasından çıkarılır. Bu referans genellikle satın alma siparişi kalem geçmişi üzerinden bağlantılıdır. Kaydedin Fatura kaleminde mal girişi belgesi referansı bulunmasından çıkarılır (ör. MIRO faturalarında RSEG tablosunda). Olay türü inferred | |||
| Ödeme önerisi oluşturuldu | Fatura, bir ödeme çalıştırmasının (ör. F110) parçası olarak ödeme önerisine eklenmiştir. Çalıştırma tamamlandığında ödenmek üzere sıraya alınmıştır. | ||
| Neden önemli? Bu etkinlik, açık bir yükümlülüğün ödeme için hazırlanan bir kaleme dönüşmesini gösterir ve ödeme operasyonlarının verimliliğini analiz etmeye yardımcı olur. Nereden alınır? Bu olay, ödeme çalıştırması veri tablolarında açıkça kaydedilir. Özellikle REGUP (ödeme programında işlenen kalemler) ve REGUH (başlık) tablolarında yer alır. Kaydedin Bir faturanın, REGUH tablosunda tanımlanan ödeme çalıştırması için REGUP tablosunda göründüğü zamanı belirleyin. Olay türü explicit | |||
| Satın alma siparişiyle eşleştirildi | Bu etkinlik, faturanın ilgili satın alma siparişiyle başarıyla eşleştirildiğini gösterir. Satın almaya dayalı faturalar için üçlü eşleştirme sürecinin önemli bir adımıdır. | ||
| Neden önemli? Bu etkinliği analiz ederek eşleştirme sürecinin verimliliğini ölçebilir, 'Üçlü eşleştirme performansı' ve 'Satın alma siparişi olmayan fatura oranı' KPI’ları için gerekli verileri elde edebilirsiniz. Nereden alınır? BSEG veya ACDOCA tablosundaki bir fatura kaleminde geçerli bir satın alma siparişi numarası (EBELN) ve kalem numarası (EBELP) bulunduğunda bu durum çıkarılır. Kaydedin Fatura belgesi oluşturulurken faturada satın alma siparişi referansı (BSEG-EBELN) bulunmasından çıkarılır. Olay türü inferred | |||
| Uyuşmazlık çözüldü | Bu etkinlik, daha önce belirlenen ve muhtemelen ödeme blokesi oluşturan bir sorunun incelenip çözüldüğünü gösterir. Faturadaki ödeme blokesi kaldırıldığında kaydedilir. | ||
| Neden önemli? Bu yeniden çalışma döngüsünü izlemek, 'Fatura uyuşmazlıklarında yeniden çalışma analizi' Dashboardı için önemlidir. Hataları düzeltmek için harcanan zamanı ve emeği ölçmeye yardımcı olur. Nereden alınır? Ödeme blokesi kaldırıldığını gösteren değişiklik belgelerinden çıkarılır. BSEG-ZLSPR alanının değişiklik günlüğü temel kaynaktır. Kaydedin ZLSPR alanının bir değerden boş değere dönüştüğü BSEG tablosuna ait değişiklik belgelerini belirleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşullar ve erişim: SAP S/4HANA veritabanı şemasına (genellikle SAPABAP1 veya benzeri) okuma erişimi olan bir kullanıcıya sahip olduğunuzdan emin olun. CDS görünümlerinin bulunduğu bu şemaya bağlanabilen bir SQL istemcisine ihtiyacınız olacak. SAP HANA Studio, DBeaver veya benzeri veritabanı sorgulama araçlarını kullanabilirsiniz.
- Temel CDS görünümlerini belirleyin: Bu veri çıkarma işlemi için temel CDS görünümleri I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails ve I_PaymentProposalItem’dır. Bu görünümlerdeki önemli alanları inceleyin.
- Sorgu kapsamını belirleyin: SQL istemcinizi açıp SAP HANA veritabanına bağlanın. Tam sorguyu çalıştırmadan önce veri çıkarma kapsamını belirleyin. Bunun için doğru kaynak sistem tanımlayıcısını, faturaların tarih aralığını (CreationDateTime) ve ilgili şirket kodlarını ayarlayın.
- Ana sorguyu hazırlayın: Sorgu bölümünde verilen SQL sorgusunun tamamını SQL istemcinize kopyalayın. Sorgu, önce temel fatura kümesini seçmek, ardından 15 farklı etkinliğe ait verileri birleştirerek olay günlüğü oluşturmak için Common Table Expressions (CTE) kullanır.
- Sorgu parametrelerini ayarlayın: Kopyaladığınız SQL sorgusunda yer tutucu değişkenleri bulun. '[YYYY-MM-DD]' değerini analiz döneminizin başlangıç ve bitiş tarihleriyle değiştirin. '[Your Company Code 1]' ve '[Your Company Code 2]' değerlerini, analiz etmek istediğiniz SAP şirket kodlarıyla değiştirin.
- Veri çıkarma sorgusunu çalıştırın: SQL sorgusunun tamamını çalıştırın. Veri hacmine ve seçilen tarih aralığına bağlı olarak işlem birkaç dakika ile birkaç saat arasında sürebilir.
- İlk sonuçları inceleyin: Sorgu tamamlandığında, çıktının ilk birkaç yüz satırını gözden geçirin. Verilerin tutarlı olduğunu, tüm sütunların beklendiği gibi doldurulduğunu ve farklı ActivityName değerlerinin bulunduğunu kontrol edin.
- Olay günlüğünü dışa aktarın: Sonuç kümesinin tamamını SQL istemcinizden CSV dosyasına aktarın. Karakter sorunlarını önlemek için dosyanın UTF-8 kodlamalı olduğundan emin olun. Dosyaya sap_s4hana_ap_event_log.csv gibi açıklayıcı bir ad verin.
- Yükleme için hazırlanın: Bir Process Mining aracına yüklemeden önce CSV dosyasındaki sütun başlıklarının gerekli öznitelik adlarıyla tam olarak eşleştiğini doğrulayın: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName vb.
- Process Mining aracına yükleyin: Oluşturduğunuz CSV dosyasını Process Mining platformunuza yükleyin. Sütunları ilgili vaka kimliği, etkinlik ve zaman damgası alanlarıyla eşleştirin.
Yapılandırma
- Temel CDS görünümleri: Veri çıkarma işlemi, standart S/4HANA CDS görünümlerinin bir arada kullanılmasına dayanır. Temel görünümler şunlardır:
- I_JournalEntry ve I_JournalEntryItem: Temel finansal belge başlıkları, kalemler, kayıt ayrıntıları ve mahsup bilgileri için.
- I_SupplierInvoiceAPI01: Satın alma siparişi referansları ve ödeme blokları dâhil, MM (Lojistik) faturalarına özgü ayrıntılar için.
- I_ChangeDocument: Ödeme bloğunun eklenmesi veya kaldırılması gibi değişikliklerin tam zaman damgasını izlemek için.
- I_WorkflowStatusDetails: Fatura onay iş akışıyla ilgili olayları çıkarmak için.
- I_PaymentProposalItem: Bir faturanın ödeme çalıştırma önerisine ne zaman eklendiğini belirlemek için.
- I_Supplier: Verileri VendorName gibi tedarikçi ana verileriyle zenginleştirmek için.
- Tarih aralığı filtresi: Veri hacmini sınırlamak için tarih aralığı filtresi uygulamanız önemlidir. Verilen sorgu, Invoices_Base CTE’sinde CreationDateTime alanına göre filtreleme yapar. İlk analizde performansı yönetilebilir düzeyde tutmak için 3-6 aylık bir aralık önerilir.
- Zorunlu filtreler: Her zaman CompanyCode alanına göre filtreleme yapın. Tüm şirket kodlarını aynı anda analiz etmek çok yavaş olabilir ve iş açısından anlamlı sonuç vermeyebilir. Ayrıca yalnızca tedarikçiyle ilgili belgeleri seçmek için JournalEntryType alanına göre de filtreleme yapın (ör. 'KR', 'RE').
- Ön koşullar: Sorguyu çalıştıran veritabanı kullanıcısının, sorguda kullanılan tüm CDS görünümlerinde ve temel HANA şemasında SELECT yetkisi olmalıdır. SAP GUI’deki uygulama düzeyindeki erişim tek başına yeterli değildir.
- Performansla ilgili noktalar: I_ChangeDocument üzerinde doğrudan sorgu çalıştırmak yoğun kaynak kullanabilir. Verilen sorgu, önce faturaları filtreleyerek bu yükü azaltmaya çalışır. Çok büyük veri setlerinde veri çıkarma işlemini yoğun olmayan saatlerde veya daha küçük tarih aralıklarıyla gerçekleştirin.
Örnek sorgu sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X'; Adımlar
- İlgili SAP S/4HANA tablolarını içeren SAP HANA şemasına doğrudan okuma erişiminiz olduğunu doğrulayın. BKPF, ACDOCA ve bekletilen belgeler, iş akışı, satın alma, mal girişi, ödeme önerileri, mahsup ve ters kayıt verileri için yapılandırılmış ek tabloları okumak üzere bağlantı dizesini, kimlik bilgilerini, şema adını ve gerekli yetkileri edinin.
- Sorguyu çalıştırmadan önce hedef sistemdeki teknik veri modelini doğrulayın. Sistemde kullanılan fiziksel adları, anahtar alanları, zaman damgası alanlarını, ters kayıt ilişkilerini, ödeme ilişkilerini ve iş akışı verilerinin saklandığı yapıyı kontrol edin. Sorgudaki köşeli parantez içindeki her yer tutucuyu sistemdeki ilgili nesne veya alanla değiştirin. İş akışı ya da bekletilen belge verilerinin tek bir evrensel tabloda saklandığını varsaymayın.
- Veri çıkarma parametrelerini ayarlayın. [Start date], [End date], [Company code filter], [Document type filter] ve [Schema name] değerlerini belirleyin. Başlangıçta üç ila altı aylık bir tarih aralığı kullanın; performansı ve veri bütünlüğünü doğruladıktan sonra aralığı genişletin.
- SQL sorgusunu SAP HANA Database Explorer veya yetkili başka bir SQL çalıştırma aracı gibi onaylı bir SAP HANA SQL istemcisinde çalıştırın. Sorgu, açıkça çıkarılan her etkinlik için bir satır üretir; olayları çıkarsaması için ProcessMind’e dayanmaz.
- Sonuç kümesini doğrulayın. Invoice alanının vaka tanımlayıcısı olduğunu, ActivityName alanında gerekli 15 etkinlik adının tamamının bulunduğunu, EventTime alanının dolu ve kronolojik açıdan makul olduğunu, SourceSystem alanının SAP S/4HANA’yı tanımladığını ve LastDataUpdate alanının veri çıkarma yenileme zaman damgasını içerdiğini kontrol edin. Verileri yüklemeden önce yinelenen olayları, ters kayıt ilişkilerini ve belge birleştirmelerini inceleyin.
- Sisteme özgü gerekli eşlemeleri uygulayın. Örneğin, yapılandırılmış bekletilen belge kaynağını Invoice Parked ile; yapılandırılmış iş akışı kaynağını Invoice Routed For Approval, Invoice Approved ve Invoice Rejected ile; yapılandırılmış ödeme kaynağını ise Payment Proposal Created ve Payment Executed ile eşleyin. Denetlenebilirlik gerekiyorsa kaynak tanımlayıcılarını ek sütunlarda koruyun.
- Sonucu, her satırda bir olay olacak şekilde, sınırlandırılmış bir dosya veya veritabanı sonuç kümesi olarak dışa aktarın. UTF-8 kodlaması kullanın, zaman damgalarını tutarlı bir saat diliminde koruyun ve Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber ve InvoiceDueDate sütun adlarını aynen koruyun. Etkinlikleri faturaya göre toplulaştırmayın.
- Olay günlüğünü ProcessMind’e yükleyin ve Invoice alanını vaka tanımlayıcısı, ActivityName alanını etkinlik sütunu, EventTime alanını ise olay zamanı sütunu olarak yapılandırın. İsteğe bağlı özniteliklerin ilgili alanlarla eşlendiğini doğrulayın. ProcessMind olay günlüğünü olduğu gibi okuduğundan, görselleştirmek istediğiniz her etkinliğin yüklemeden önce bir satır olarak bulunduğundan emin olun.
Yapılandırma
- Tarih aralığı: Üç ila altı ayla başlayın. Çıkarılan etkinliğe göre kayıt tarihini, belge oluşturma tarihini veya ilgili kaynak olay tarihini kullanın. Aralığı yalnızca sorgu süresini ve kaynak sistemdeki veri saklama durumunu doğruladıktan sonra genişletin.
- Şirket filtresi: Veri çıkarmayı gerekli şirket kodlarıyla sınırlamak için [Company code filter] değerini ayarlayın. Kısıtlama gerekmiyorsa, üretim ortamında sınırsız sorgu çalıştırmak yerine tüm şirketleri kapsayan kontrollü bir seçim kullanın.
- Belge filtresi: [Document type filter] değerini yalnızca hedef sistemde tedarikçi faturaları, alacak dekontları, bekletilen belgeler, ödeme belgeleri ve ters kayıtlar için kullanılan belge türlerini doğruladıktan sonra ayarlayın.
- Şema ve nesne eşlemesi: [Schema name] değerini ve köşeli parantez içindeki tüm kaynak nesne veya alanları, hedef SAP S/4HANA sisteminde doğruladığınız değerlerle değiştirin. Doğrudan HANA sorgusunu sistemde etkinleştirilmiş uygulamalara, eklentilere, iş akışı tasarımına ve veri modeline göre uyarlamanız gerekir.
- Zaman damgalarını işleme: Tüm kaynak zaman damgalarını tek bir saat dilimine dönüştürün. Yalnızca tarih bilgisi varsa belgelenmiş bir varsayılan saat bileşeni kullanın ve bu kısıtlamayı veri sözlüğüne kaydedin.
- Olayların anlamı: Her etkinliği ayrı bir satır olarak çıkarın. Birden fazla etkinliği tek bir fatura kaydında birleştirmeyin; eşleştirme, onay, vade tarihi veya mahsup olaylarını ProcessMind’in türetmesini beklemeyin.
- Vade tarihi olayı: Invoice Due Date Passed olayını yalnızca faturanın vade tarihi yapılandırılmış değerlendirme zaman damgasından önceyse ve bu zaman damgasına kadar mahsup olayı gerçekleşmemişse oluşturun. Sorgu bu hesaplama için [Evaluation timestamp] değerini kullanır.
- Performans: İlk aşamada tarih aralığını ve şirket kapsamını sınırlayın, dizinlenmiş veya bölümlendirmeyle ilgili alanlara göre filtreleme yapın, gereksiz geniş sütun seçimlerinden kaçının ve sorguyu onaylı raporlama saatlerinde çalıştırın. Üretim sorgusu üzerinde anlaşılan çalışma süresini aşarsa kaynak veri alt kümelerini hazırlamayı değerlendirin.
- Yenileme stratejisi: LastDataUpdate alanına veri çıkarma işleminin çalıştırıldığı zaman damgasını yazın. Artımlı yüklemelerde, ilgili kaynak değişiklik zaman damgasına dayalı bir watermark tutun ve geç gelen güncellemeleri ve ters kayıtları yakalamak için geriye dönük bir zaman aralığı ekleyin.
- Ön koşullar: Gerekli veritabanı yetkileri, üretim ortamına onaylı erişim, sistemin Universal Journal yapılandırması hakkında bilgi, yapılandırılmış bekletilen belge, satın alma, mal girişi, iş akışı, ödeme, mahsup ve ters kayıt kaynaklarına erişim ve geçerli SAP lisans veya yönetişim onayları.
Örnek sorgu sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Adımlar
- Gereksinim ve tasarım: Kodlamaya başlamadan önce iş analistleriyle birlikte gerekli 15 etkinliğin her biri için tetikleme koşullarını ve veri alanlarını netleştirin. Kapsama alınacak SAP tablolarını, belge türlerini (ör. 'KR', 'RE') ve şirket kodlarını belirleyin.
- ABAP programı oluşturun: SE38 işlem kodunu kullanarak ABAP Editor’ü açın. Örneğin Z_PM_AP_INVOICE_EXTRACT adında yeni bir çalıştırılabilir program oluşturun. Açıklayıcı bir başlık verin ve uygulamayı 'Financial Accounting' olarak ayarlayın.
- Seçim ekranını tanımlayın: Programda, kullanıcıların veri çıkarma tarih aralığını (fatura oluşturma tarihi), hedef şirket kodlarını (BUKRS) ve ilgili fatura belge türlerini (BLART) belirleyebilmesi için PARAMETERS ve SELECT-OPTIONS anahtar sözcüklerini kullanarak bir seçim ekranı tanımlayın. Uygulama sunucusundaki çıktı dosyası yolu için de bir parametre ekleyin.
- Veri tanımlarını yapın: Gerekli ve önerilen tüm öznitelikleri içeren, nihai olay günlüğü biçimiyle (ör. TY_EVENT_LOG) eşleşen bir dahili tablo yapısı tanımlayın. BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS ve REGUH gibi çeşitli SAP kaynak tablolarından seçilen verileri tutacak dahili tabloları bildirin.
- Ana veri seçimini yapın: Veri çıkarma mantığını, kullanıcının seçim ekranındaki ölçütlere göre RBKP (Lojistik faturalar) ve BKPF (Finansal faturalar) tablolarından temel fatura kümesini seçerek başlatın. Sonraki veri aramalarında kullanmak üzere bu faturaların anahtarlarını bir dahili tabloda saklayın.
- Etkinlikleri sırayla çıkarın: Ana kümedeki her fatura için, her iş etkinliğinin zaman damgalarını ve ayrıntılarını bulmak üzere bir dizi seçim işlemi gerçekleştirin. Örneğin, ödeme bloğu değişiklikleri için CDHDR ve CDPOS tablolarını, ödeme çalıştırma verileri için REGUH ve REGUP tablolarını, ters kayıt belgesi ayrıntıları için BKPF tablosunu sorgulayın. Bulduğunuz her etkinlik için nihai olay günlüğü tablosuna yeni bir kayıt ekleyin.
- Hesaplanan olayların mantığını oluşturun: Doğrudan bir tablo alanında saklanmayan etkinlikler için ABAP mantığı uygulayın. 'Invoice Due Date Passed' olayı için fatura vade tarihini (BSEG-ZFBDT + ödeme koşulları) ve mahsup tarihini (BSEG-AUGDT) kullanın. Mahsup tarihi vade tarihinden sonraysa vade tarihini zaman damgası olarak kullanan yeni bir olay kaydı oluşturun.
- Verileri dönüştürüp zenginleştirin: Her etkinliğin verilerini toplarken gerekli tüm öznitelikleri doldurun. Bunun için LFA1 tablosundan tedarikçi adlarını arayın, tarih ve saatleri tek bir zaman damgası metnine dönüştürün (CONCATENATE...INTO...) ve SourceSystem değerini ayarlayın.
- Çıktı dosyasını oluşturun: Tüm faturalar ve bunlara karşılık gelen etkinlikler işlenip nihai dahili tabloda toplandıktan sonra OPEN DATASET, LOOP AT ... TRANSFER ve CLOSE DATASET ifadelerini kullanarak verileri seçim ekranında belirtilen uygulama sunucusu yolundaki bir dosyaya yazın.
- Dosyayı indirip yüklemeye hazırlayın: Oluşturulan dosyayı uygulama sunucusundan yerel bilgisayarınıza indirmek için CG3Y işlem kodunu kullanın. Dosyanın UTF-8 kodlamalı CSV biçiminde kaydedildiğinden emin olun. Process Mining aracına yüklemeden önce sütun başlıklarının gerekli özniteliklerle (Invoice, ActivityName, EventTime vb.) eşleştiğini doğrulayın.
Yapılandırma
- Tarih aralığı: Fatura oluşturma tarihi için P_CPUDT seçim seçeneğini (BKPF-CPUDT veya RBKP-CPUDT) tanımlayın. İlk analiz için 6-12 aylık veri önerilir.
- Şirket kodu (P_BUKRS): Belirli şirket kodlarına göre filtreleme yapmak için zorunlu bir SELECT-OPTIONS parametresidir. Kesinlikle gerekmedikçe tüm şirket kodlarını aynı anda işlemek önerilmez.
- Fatura belge türü (P_BLART): İlgili fatura belge türlerine göre filtreleme yapmak için bir SELECT-OPTIONS parametresidir. Yaygın türler arasında 'KR' (Tedarikçi faturası), 'KG' (Tedarikçi alacak dekontu) ve 'RE' (Lojistik fatura doğrulaması) bulunur.
- Çalıştırma modu: Büyük veri hacimlerinde ön plan iletişim sürecinde zaman aşımını önlemek için program arka plan işi olarak (SM36/SM37) çalıştırılmalıdır. İşlemi yoğun olmayan saatlerde planlayın.
- Çıktı dosyası yolu: SAP uygulama sunucusundaki dosya yolunu ve adını belirtmek için bir PARAMETER kullanın (ör. /tmp/ dizininde). Dosya indirilmeden önce bu konuma yazılır.
- Ön koşullar: Raporu çalıştıran kullanıcının FI, CO ve MM tablolarını (BKPF, BSEG, RBKP, RSEG, LFA1), değişiklik belgesi tablolarını (CDHDR, CDPOS) ve iş akışı tablolarını okuma yetkisi olmalıdır. Ayrıca uygulama sunucusuna dosya yazmak için S_DATASET yetki nesnesi gerekir.
Örnek sorgu abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM. Başlamaya hazır mısınız?
Process Mining girişiminizi başlatmak ve Borçlar Muhasebesi operasyonlarınızda önemli verimlilik artışları sağlamak için bu Templateten yararlanın. Sürecinizi bugün daha verimli ve akıcı hâle getirmek için ilk adımı atın.
Gecikme faizlerini önleyin: Borçlar Muhasebesi fatura işlemenizi bugün iyileştirin
İşleme maliyetlerini %60 azaltın ve yinelenen ödemeleri kolayca önleyin.
Kredi kartı gerekmez, birkaç dakika içinde başlayabilirsiniz.