Borçlar Muhasebesi Fatura İşleme veri şablonunuz
Borçlar Muhasebesi Fatura İşleme veri şablonunuz
- Ayrıntılı analiz için önerilen nitelikler
- Etkili biçimde izlenecek temel süreç faaliyetleri
- Adım adım veri çıkarma rehberi
Borçlar Muhasebesi Fatura İşleme Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet ActivityName | Fatura işleme yaşam döngüsünde gerçekleşen belirli bir iş olayının veya adımının adıdır. | ||
| Açıklama Faaliyet, Borçlar Muhasebesi sürecindeki 'Fatura Alındı', 'Fatura Kaydedildi' veya 'Ödeme Gerçekleştirildi' gibi belirli bir aşamayı ya da eylemi temsil eder. Bunlar süreç haritasının yapı taşlarıdır. Faaliyetleri analiz etmek, Process Mining'in temelini oluşturur. Süreç akışını görselleştirmeye, yaygın yolları belirlemeye, standart süreçten sapmaları tespit etmeye ve her adımın sıklığını ve süresini ölçmeye yardımcı olur. Belirli bir faturaya ait bu faaliyetlerin sırası, faturanın süreçteki yolculuğunu oluşturur. Neden önemli? Sürecin adımlarını tanımlar; süreç akışını görselleştirmenize ve analiz etmenize, darboğazları ve yeniden işleme döngülerini belirlemenize olanak tanır. Nereden alınır? Belge durumu değişiklikleri (ör. BKPF-BSTAT), değişiklik belgeleri (CDHDR/CDPOS tabloları) veya Workflow günlükleri gibi çeşitli kaynaklardan türetilir. Bu işlem genellikle özel bir veri çıkarma mantığı gerektirir. Örnekler Fatura alındıFatura onaylandıÖdeme gerçekleştirildiFaturanın ödemesi bloke edildi | |||
| Fatura Invoice | Fatura belgesinin benzersiz tanımlayıcısıdır ve Borçlar Muhasebesi sürecindeki birincil vaka kimliği olarak kullanılır. | ||
| Açıklama Fatura, alındığı andan ödendiği ana kadar ilgili tüm faaliyetleri birbirine bağlayan merkezi nesnedir. SAP S/4HANA'da bu genellikle Şirket Kodu (BUKRS), benzersiz Belge Numarası (BELNR) ve Mali Yıl'dan (GJAHR) oluşan bileşik bir anahtardır. Faturaya göre analiz yapmak, fatura yaşam döngüsünü uçtan uca görmenizi sağlar. Bu, toplam çevrim süresi gibi temel metrikleri hesaplamak, tek tek faturalardaki darboğazları belirlemek ve bir faturanın süreçte izleyebileceği farklı yolları anlamak için temel oluşturur. Neden önemli? Her faturanın yolculuğunu benzersiz biçimde tanımlar; böylece tüm yaşam döngüsünü izlemek ve süreç performansını vaka bazında analiz etmek mümkün olur. 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 | Faaliyetin gerçekleştiği kesin tarih ve saattir. | ||
| Açıklama Olay zamanı, her faaliyetle ilişkilendirilmiş zaman damgasıdır ve bir faturadaki olayların kronolojik sırasını sağlar. Bu veri, süreç akışını anlamak ve zamana dayalı analizler yapmak için gereklidir. Analizde Olay zamanı, faaliyetleri doğru sıraya koymak, farklı adımlar arasındaki çevrim sürelerini hesaplamak, bekleme sürelerini belirlemek ve süreç performansını farklı dönemlerde (ör. aydan aya) analiz etmek için 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ı tüm metrikleri hesaplamak için gereklidir. Bunlar Process Mining'in temel unsurlarıdır. Nereden alınır? SAP tablolarındaki Oluşturma Tarihi (BKPF-CPUDT), Kayıt Tarihi (BKPF-BUDAT), Kapatma Tarihi (BSAK-AUGDT) veya değişiklik günlüğü zaman damgaları (CDHDR-UDATE/UTIME) gibi çeşitli tarih ve saat alanlarından alınır. Örnekler 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Kaynak sistem SourceSystem | Verilerin çıkarıldığı sistemdir. | ||
| Açıklama Bu öznitelik, süreç verilerinin kaynağını tanımlar. Bu görünümde değer genellikle 'SAP S/4HANA' olur. Birden fazla ERP veya entegre sistemin bulunduğu ortamlarda bu alan, veri kökeni ve ayrıştırma için gereklidir. Analizin doğru veri seti üzerinde yapılmasını sağlar ve veri kalitesi sorunlarını kaynağa kadar izleyerek teşhis etmeye yardımcı olur. Neden önemli? Verilerin kaynağını tanımlar. Veri yönetişimi, sorun giderme ve çok sistemli ortamlar için önemlidir. Nereden alınır? Genellikle veri çıkarma işlemi sırasında veri setinin kaynağını etiketlemek için eklenen statik bir değerdir. Örnekler SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Son veri güncellemesi LastDataUpdate | Bu kayda ait verilerin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgasıdır. | ||
| Açıklama Bu öznitelik, SAP S/4HANA'dan en son veri çıkarma veya güncelleme işleminin tarihini ve saatini gösterir. Analiz edilen verilerin güncelliğini 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 bilmesi açısından önemlidir. Veri gecikmesiyle ilgili beklentileri yönetmeye, veri yenilemelerini planlamaya ve veri bütünlüğünü korumaya yardımcı olur. Neden önemli? Verilerin güncelliğini göstererek kullanıcıların süreç analizlerinin ne kadar güncel olduğunu anlamasını sağlar. Nereden alınır? Bu değer, kaynak sistemden veri çıkarıldığı sırada her kayda oluşturulur ve zaman damgasıyla işlenir. Örnekler 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Fatura tutarı InvoiceAmount | Faturanın orijinal belge para birimindeki toplam brüt tutarıdır. | ||
| Açıklama Bu, satıcının sunduğu faturanın toplam değeridir. Herhangi bir kesinti veya indirim uygulanmadan önce mal veya hizmet bedelini, vergileri ve diğer ücretleri içerir. Fatura tutarı, çok çeşitli analizlerde kullanılan önemli bir mali özniteliktir. Yüksek tutarlı faturaları önceliklendirmeye, süreç gecikmelerinin mali etkisini anlamaya (ör. yüksek tutarlı faturalardaki gecikme ücretleri) ve süreci bölümlere ayırmaya yardımcı olur. Örneğin, 'Yüksek tutarlı faturalar farklı bir onay yolunu mu izliyor?' sorusu yanıtlanabilir. Olası yinelenen ödemeleri belirlemek için de gereklidir. Neden önemli? Sürece mali bağlam kazandırarak değer bazlı analiz, yüksek tutarlı faturaların önceliklendirilmesi ve mali etkilerin ölçülmesini sağlar. Nereden alınır? MM faturaları için RBKP-RMWWR (Brüt fatura tutarı) gibi tablolarda bulunur veya FI faturaları için BSEG'deki kalemlerden (WRBTR alanı) hesaplanır. Örnekler 1500.00250.7512345.50 | |||
| Fatura vade tarihi InvoiceDueDate | Fatura ödemesinin satıcıya yapılması gereken tarihtir. | ||
| Açıklama Fatura Vade Tarihi, geç ödeme ücretlerinden kaçınmak ve iyi bir tedarikçi ilişkisini korumak için tedarikçiye ödeme yapılması gereken son gündür. Bu tarih, faturanın temel tarihi ve tedarikçiyle üzerinde anlaşılan ödeme koşullarına göre hesaplanır. Bu tarih, 'Payment Compliance & Aging' Dashboardı ve 'On-Time Payment Rate' temel performans göstergesi (KPI) için gereklidir. Vade tarihini gerçek ödeme tarihiyle karşılaştırarak ödemelerin zamanında, erken veya geç yapılıp yapılmadığını analiz edebilirsiniz. Bu durumun finansal ve ilişkisel sonuçları doğrudan görülür. Neden önemli? Zamanında ödeme analizinin temel belirleyicisidir; ödeme performansını, bunun tedarikçi ilişkilerine etkisini ve gecikme ücretlerini ölçmenizi sağlar. Nereden alınır? Bu tarih genellikle hesaplanır. Net vade tarihi BSEG-NETDT alanında bulunur. Ayrıca ödeme için temel tarih (BSEG-ZFBDT) ve ödeme koşullarından (BSEG-ZTERM) türetilebilir. Örnekler 2023-10-312023-11-152024-01-10 | |||
| Kullanıcı adı UserName | Faaliyeti gerçekleştiren kişinin kullanıcı kimliğidir. | ||
| Açıklama Bu öznitelik, kayıt oluşturma, onaylama veya fatura kapatma gibi belirli bir etkinliği gerçekleştiren SAP kullanıcı kimliğini kaydeder. Süreç adımlarını tek tek kullanıcılarla ilişkilendirir. Kullanıcı Adına göre analiz yapmak, iş yükünün nasıl dağıldığını anlamak, en başarılı çalışanları belirlemek ve ek eğitim gerektirebilecek kullanıcıları tespit etmek için önemlidir. Ayrıca Dashboardlarda onay darboğazlarını analiz etmek açısından da önem taşır. Hangi onaylayanların süreçte gecikmeye neden olduğunu belirlemenize yardımcı olur. Neden önemli? Faaliyetleri belirli kişilerle ilişkilendirerek 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ıcı adı VendorName | Faturayı gönderen satıcının adıdır. | ||
| Açıklama Bu öznitelik, tedarikçinin veya satıcının resmi adını içerir. Fatura belgesinde saklanan Satıcı Numarası üzerinden ilişkilendirilir. Satıcı analizi, tedarikçi ilişkilerini yönetmek ve belirli satıcılara özgü süreç sorunlarını belirlemek için önemlidir. 'Hangi satıcılar en fazla uyuşmazlık içeren faturayı gönderiyor?' veya 'Belirli stratejik satıcılara sürekli zamanında ödeme yapıyor muyuz?' gibi soruları yanıtlamaya yardımcı olur. Fatura numarası ve tutarıyla birlikte olası yinelenen ödemeleri tespit etmek için de önemli bir alandır. Neden önemli? Süreç performansını tedarikçi bazında analiz etmenizi, sorunlu satıcıları belirlemenizi ve stratejik tedarikçi ilişkilerini etkili biçimde yönetmenizi sağlar. Nereden alınır? BKPF veya RBKP'de bulunan Satıcı Numarası (LIFNR) üzerinden LFA1 satıcı ana verisi tablosundan (NAME1 alanı) alınır. Örnekler Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
| Satın alma siparişi numarası PurchaseOrderNumber | Varsa, faturayla ilişkili satın alma siparişinin benzersiz tanımlayıcısıdır. | ||
| Açıklama Bu öznitelik, faturayı önceden onaylanmış bir satın alma siparişiyle (PO) ilişkilendirir. PO numarasının bulunması, 3'lü eşleştirme sürecinin (PO-Fatura-Mal Kabulü) temelidir. Bu öznitelik, uyumluluk ve verimlilik analizi için büyük önem taşır. Tedarik politikalarına uyumu ölçen 'PO-Less Invoice Percentage' temel performans göstergesini (KPI) hesaplamak için kullanılır. Ayrıca PO ile desteklenen faturalar için eşleştirme sürecini analiz etmenizi sağlayan '3-Way Matching Performance' Dashboardının temelini oluşturur. Neden önemli? 3'lü eşleştirme verimliliğini analiz etmek ve satın alma siparişi olmadan işlenen faturaları belirleyerek satın alma politikalarına uyumu ölçmek için gereklidir. Nereden alınır? Fatura kalem tablolarında bulunur. MM faturaları için RSEG-EBELN, FI faturaları için BSEG-EBELN kullanılır. Örnekler 45000012344500005678 | |||
| Şirket kodu CompanyCode | Faturanın işlendiği organizasyon birimidir. | ||
| 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 satıcıya borcu olan tüzel kişiyi temsil eder. Şirket koduna göre analiz yapmak, kuruluş içindeki farklı tüzel kişilerin süreç performansını karşılaştırmanızı sağlar. Böylece işletmenin hangi bölümlerinin standart süreçleri izlediğini, hangilerinde verimliliğin daha düşük, çevrim sürelerinin daha uzun veya yeniden işleme oranlarının daha yüksek olduğunu belirleyebilirsiniz. Neden önemli? Farklı tüzel kişiler arasındaki süreç performansını karşılaştırmanızı sağlar; bölgesel veya iş birimine özgü sorunları ve iyi uygulamaları belirlemeye yardımcı olur. Nereden alınır? Belge başlık tablolarında bulunur. FI faturaları için öncelikle BKPF-BUKRS, MM faturaları için RBKP-BUKRS kullanılır. Örnekler 10001710US01DE01 | |||
| Bloke nedeni BlockingReason | Bir faturanın neden ödeme için bloke edildiğini gösteren ve uyuşmazlığa işaret eden nedendir. | ||
| Açıklama Bir fatura, 3'lü eşleştirme veya başka doğrulama adımları sırasında yapılan kontrolden geçemezse ödeme için bloke edilir. Bloke Nedeni, miktar tutarsızlığı, fiyat farkı veya mal kabulünün eksik olması gibi sorunun niteliğini belirtir. Bu öznitelik, 'Invoice Discrepancy Rework Analysis' Dashboardı için büyük önem taşır. Farklı bloke nedenlerinin sıklığını analiz etmek, süreç verimsizliklerinin temel nedenlerini belirlemenize yardımcı olur. Örneğin 'Price variance' sık görülen bir nedense satın alma sistemindeki ana veri sorunlarına işaret edebilir. Neden önemli? Fatura uyuşmazlıklarının ve yeniden işlemenin temel nedenleri hakkında doğrudan bilgi sağlayarak hedefli süreç iyileştirmeleri yapmanıza olanak tanır. Nereden alınır? RSEG gibi fatura kalemi tablolarında, SPGR* ile başlayan alanlarda (örneğin SPGRP, SPGRQ, SPGRT) saklanır. RBKP_BLOCKED tablosunda da bulunabilir. Örnekler Fiyat UyumsuzluğuMiktar UyumsuzluğuMal Kabulü Eksik | |||
| Fatura belge türü InvoiceDocumentType | Fatura belgesinin SAP'de nasıl işleneceğini belirleyen sınıflandırmadır. | ||
| Açıklama Belge Türü, SAP içindeki muhasebe belgelerini kategorilere ayıran temel bir yapılandırma öğesidir. Örneğin 'KR' genellikle tedarikçi faturaları, 'RE' MM faturaları ve 'KG' tedarikçi alacak dekontları için kullanılır. Bu tür, numara aralığı ve hangi alanların zorunlu olduğu gibi unsurları belirler. Süreç analizinde Belge Türüne göre filtreleme, farklı fatura türlerinin süreç akışlarını karşılaştırmanıza olanak tanır. Örneğin bir alacak dekontunun onay süreci standart bir faturanınkinden farklı olabilir. Bu özellik, 'Invoice Approval Routing Variants' Dashboardı için kullanışlı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ı ortaya çıkarmanızı 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, örneğin USD veya EUR. | ||
| Açıklama Bu öznitelik, Fatura Tutarının hangi para biriminde ifade edildiğini belirtir. Finansal değerlerin doğru yorumlanması için gerekli bağlamı sağlar. Çok uluslu bir kuruluşta faturaları para birimini dikkate almadan analiz etmek yanıltıcı olabilir. Bu alan, tüm tutarları tek bir raporlama para birimine dönüştürerek veya bölgesel finansal faaliyetleri anlamak için analizi para birimine göre ayırarak finansal verilerin doğru şekilde işlenmesini sağlar. Neden önemli? Fatura Tutarı için gerekli bağlamı sağlar ve özellikle çok uluslu yapılarda doğru finansal analiz ve raporlamaya imkan verir. Nereden alınır? Belge başlığı tablolarında, özellikle BKPF-WAERS veya RBKP-WAERS alanlarında bulunur. Örnekler USDEURGBPJPY | |||
| Geç ödeme mi? IsLatePayment | Faturanın vade tarihinden sonra ödenip ödenmediğini gösteren boolean işareti. | ||
| Açıklama Bu hesaplanan öznitelik, bir faturanın ödemesinin resmi vade tarihinden sonra yapılıp yapılmadığını gösteren basit bir doğru/yanlış işaretidir. 'Clearing Date' ile 'Invoice Due Date' karşılaştırılarak elde edilir. Bu işaret, 'Payment Compliance & Aging' Dashboardı ve 'On-Time Payment Rate' temel performans göstergesi (KPI) için analizi kolaylaştırır. Geç ödemelerin sayısını belirlemek, zamanında yapılan ödemelerin yüzdesini hesaplamak ve geç ödeme oranı yüksek tedarikçileri veya şirket kodlarını tespit etmek için kolay filtreleme ve toplama yapılmasını sağlar. Neden önemli? Ödeme koşullarına uyumluluğu doğrudan ölçer, zamanında ödeme KPI'ının 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 şöyledir: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Örnekler truefalse | |||
| İndirimden yararlanıldı mı? DiscountTaken | Erken ödeme indiriminin başarıyla uygulanıp uygulanmadığını gösteren boolean işareti. | ||
| Açıklama Bu öznitelik, fatura ödenirken nakit indiriminden gerçekten yararlanılıp yararlanılmadığını gösterir. Borçlar Muhasebesi sürecindeki finansal verimliliği ölçmenin temel unsurlarından biridir. Bu işaret, 'Erken Ödeme İndiriminden Yararlanma Oranı' KPI'ının temelini oluşturur. Ödeme Koşullarına göre indirimden yararlanmanın mümkün olduğu faturaları filtreleyip bu alanı analiz ederek ne kadar tasarruf edildiğini ve kaç tasarruf fırsatının kaçırıldığını kesin biçimde hesaplayabilirsiniz. Böylece Borçlar Muhasebesi performansını ölçmek için net ve sayısal bir gösterge elde edersiniz. Neden önemli? Mevcut erken ödeme indirimlerinden yararlanma başarısını doğrudan ölçer ve ş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 türetilir. Örnekler truefalse | |||
| Mahsup tarihi ClearingDate | Ödemenin yapıldığı ve faturanın açık kalemlerden mahsup edildiği tarih. | ||
| Açıklama Mahsup tarihi, faturanın finansal olarak kapatıldığını gösterir. Çoğu başarılı fatura sürecinde son adım olan 'Payment Cleared' aktivitesinin gerçekleştiği tarihtir. Bu tarih, gerçek ödeme tarihini hesaplamak ve bunu Fatura Vade Tarihi ile karşılaştırmak için kullanılır. Bu nedenle 'Zamanında Ödeme Oranı' KPI'ının hesaplanması ve ödeme performansıyla ilgili analizler için gereklidir. Ayrıca uçtan uca fatura döngü süresinin hesaplandığı bitiş noktasını gösterir. Neden önemli? Faturanın nihai olarak kapatıldığını gösterir; döngü süresi hesaplamalarının bitiş noktası ve zamanında ödeme analizinin temelidir. Nereden alınır? Tedarikçilere ait BSAK-AUGDT gibi mahsup edilmiş kalem tablolarında bulunur. Örnekler 2023-10-282023-11-142024-01-09 | |||
| Ödeme koşulları PaymentTerms | Faturanın ödenmesi için satıcıyla kararlaştırılan ve genellikle indirim fırsatlarını da içeren koşullardır. | ||
| Açıklama Ödeme Koşulları, ödeme vade tarihlerini ve olası erken ödeme indirimlerini belirleyen kurallardır. Örneğin 'Z001' gibi bir koşul, '30 gün içinde ödenir, 10 gün içinde ödenirse %2 indirim uygulanır' anlamına gelebilir. Bu öznitelik, 'Early Payment Discount Capture Rate' Dashboardının temelini oluşturur. Ödeme koşullarını analiz ederek indirimden yararlanma hakkı bulunan tüm faturaları belirleyebilirsiniz. Bu sonucu alınan gerçek indirimlerle karşılaştırmak, kaçırılan tasarruf fırsatlarını ortaya çıkarır ve ödeme sürecinin verimliliğini ölçer. Neden önemli? Erken ödeme indirimi fırsatlarını analiz etmek, ödeme sürecinin mali performansını ölçmek ve kaçırılan tasarrufları belirlemek için gereklidir. Nereden alınır? Satıcı kalemlerinde BSEG-ZTERM tablosunda veya fatura başlığında RBKP-ZTERM alanında bulunur. Örnekler Z0010001NT30 | |||
| Otomatik mi IsAutomated | Faaliyetin bir insan kullanıcı yerine sistem tarafından otomatik olarak gerçekleştirilip gerçekleştirilmediğini gösteren bir işarettir. | ||
| Açıklama Bu doğru/yanlış özniteliği, insanlar tarafından başlatılan etkinliklerle sistem işleri, iş akışları veya botlar tarafından yürütülen etkinlikleri birbirinden ayırır. Örneğin otomatik bir ödeme çalıştırması veya sistem tarafından oluşturulan bir fatura kaydı otomatik olarak işaretlenir. Bu özniteliği analiz etmek, Borçlar Muhasebesi sürecindeki otomasyon düzeyini anlamanıza yardımcı olur. 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 etkililiğini analiz etmeye ve yeni 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şkilendirilmiş belirli işlem kodlarına göre türetilir. Örnekler truefalse | |||
| Tedarikçi fatura numarası VendorInvoiceNumber | Tedarikçinin belgesinde yer alan fatura numarası. | ||
| Açıklama Bu, tedarikçinin kendi muhasebe sistemindeki referans numarasıdır ve fiziksel veya elektronik fatura belgesinde yazılıdır. Fatura teslim alınırken manuel olarak girilir veya OCR ile yakalanır. Bu alan, operasyonel amaçlar ve özellikle 'Potential Duplicate Invoice Payments' Dashboardı için son derece önemlidir. Yinelenen faturaları tespit etmek için kullanılan yaygın yöntemlerden 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 tespit etmek için temel bir alandır ve tedarikçilerle iletişimde kullanılan başlıca harici referans görevi görür. Nereden alınır? Belge başlığındaki 'Reference' alanında, genellikle BKPF-XBLNR olarak saklanır. Örnekler INV-2023-9876733401120231015-001 | |||
Borçlar Muhasebesi Fatura İşleme Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura alındı | Bu faaliyet, manuel olarak veya OCR/VIM gibi otomatik bir arayüz aracılığıyla SAP'de fatura belgesinin oluşturulmasını gösterir. Bu olay genellikle muhasebe belgesi başlığındaki oluşturma tarihinden ve saatinden alınır. | ||
| Neden önemli? Sürecin başlangıç noktası olan bu faaliyet, uçtan uca fatura çevrim süresini hesaplamak ve tüm AP sürecinin işlem hacmini ölçmek için gereklidir. Nereden alınır? Bu olay, muhasebe belgesi başlık tablosundan (BKPF), belge oluşturma tarihi (CPUDT) ve saati (CPUTM) kullanılarak alınır. Yakalayın Fatura belgesi için oluşturma zaman damgasını (BKPF-CPUDT, BKPF-CPUTM) kullanın. Olay türü explicit | |||
| Fatura iptal edildi | Fatura belgesi ters kayıtla iptal edilerek mali etkisi ortadan kaldırılmıştır. Bu, genellikle hatalı girişler veya tedarikçi anlaşmazlıkları nedeniyle sürecin alternatif son durumudur. | ||
| Neden önemli? İptalleri izlemek, yinelenen gönderimler veya hatalı fatura verileri gibi süreç başarısızlıklarının nedenlerini belirlemeye yardımcı olur ve üst süreçlerdeki sorunlara işaret edebilir. Nereden alınır? Bir ters kayıt belgesi oluşturulduğunda açıkça kaydedilir. Orijinal belge başlığında (BKPF) ters kayıt belgesi numarası (STBLG) ve ters kayıt nedeni bulunur. Yakalayın Orijinal belgenin başlığında (BKPF-STBLG) ilişkilendirilen ters kayıt belgesinin kayıt tarihini belirleyin. Olay türü explicit | |||
| Fatura kaydedildi | Fatura Genel Defter'e resmi olarak kaydedilerek mali bir yükümlülük oluşturulur. Park edilen belge kaydedilmiş belgeye dönüştürülür veya doğrudan kayıt yapılır. | ||
| Neden önemli? Bu, önemli bir mali kilometre taşıdır. Şirketin ödeme yükümlülüğünü doğrular ve genellikle ödemenin planlanması için ön koşuldur. Nereden alınır? Bu olay, belge başlığındaki Kayıt Tarihi (BUDAT) ile belirlenir. Kaydedilmiş bir belgenin belge durumu (BKPF-BSTAT) boştur. Yakalayın Park edilmemiş belgeler için (BKPF-BSTAT boş olduğunda) kayıt zaman damgasını (BKPF-BUDAT) kullanın. Olay türü explicit | |||
| Fatura onaylandı | Fatura, Workflow sistemi içindeki gerekli tüm onayları almıştır. Bu genellikle fatura kaydedilmeden veya ödeme için blokesi kaldırılmadan önceki son adımdır. | ||
| Neden önemli? Bu önemli kilometre taşı, onay döngüsünün sonunu gösterir. Yönlendirme ile onay arasındaki süre, verimliliğin önemli bir metriğidir. Nereden alınır? SAP Business Workflow günlüklerinden tamamlama veya son serbest bırakma adımı olarak alınır. Alternatif olarak, yönlendirme sonrasında ödeme blokesi kaldırıldığında da çıkarılabilir. Yakalayın SAP Workflow günlüklerinden Workflow tamamlama olaylarını çıkarın veya son 'serbest bırakma' olayını belirleyin. Olay türü explicit | |||
| Faturanın ödemesi bloke edildi | Sistem, faturaya otomatik veya manuel olarak ödeme blokesi koyarak faturanın ödenmesini engellemiştir. Bunun nedeni genellikle fiyat veya miktar uyuşmazlıkları ya da eksik onaylardır. | ||
| Neden önemli? Bu durum, sorunların ve yeniden işlemenin önemli bir göstergesidir. Bloke nedenlerini ve sürelerini analiz etmek, ödeme gecikmelerinin ve süreç verimsizliklerinin temel nedenlerini belirlemeye yardımcı olur. Nereden alınır? Bu, muhasebe belgesinin satıcı kalemindeki (BSEG tablosu) Ödeme Blokesi Anahtarı alanında (ZLSPR) kaydedilen açık bir durumdur. Yakalayın BSEG-ZLSPR alanına bir 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. Bu durum, ödeme çalışması tamamlandığında ve bir ödeme belgesi oluşturulup kaydedildiğinde alınır. | ||
| Neden önemli? Bu faaliyet, nakit akışı analizi ve 'Zamanında Ödeme Oranı' KPI'ını ölçmek için gereklidir. Ölçüm, bu tarihin fatura vade tarihiyle karşılaştırılmasıyla yapılır. Nereden alınır? Faturayı kapatan ödeme belgesinin kayıt tarihinden alınır. Ödeme belgesi numarası, fatura kalemindeki (BSEG) kapatma belgesi alanında (AUGBL) ilişkilendirilir. Yakalayın Fatura kalemini kapatan ödeme belgesinin kayıt tarihini (BUDAT) belirleyin. Olay türü explicit | |||
| Ödeme kapatıldı | Bu faaliyet, ödemenin ve faturanın alt defterde birbirine karşı mahsuplaştırıldığı fatura sürecinin nihai kapanışını gösterir. Sürecin tamamlandığı anlamına gelir. | ||
| Neden önemli? Sürecin kesin sonu olan bu faaliyet, uçtan uca çevrim süresini doğru hesaplamak için gereklidir. Yükümlülüğün kapatıldığını doğrular. Nereden alınır? Fatura belgesinin satıcı kalemindeki (BSEG tablosu) Kapatma Tarihi (AUGDT) alanına değer girildiğinde açıkça kaydedilen bir olaydır. Yakalayın Fatura kalemindeki kapatma tarihini (BSEG-AUGDT) kullanın. Olay türü explicit | |||
| Fatura onaya yönlendirildi | Fatura, iş kurallarına göre gerekli onaylar için bir iş akışına gönderilmiştir. Bu adım, onay alt sürecinin başlangıcını gösterir. | ||
| Neden önemli? Bu faaliyet, 'Ortalama Fatura Onay Süresi' KPI'ını ölçmenin ve onay darboğazlarını analiz etmenin başlangıç noktasıdır. Nereden alınır? Fatura nesnesiyle (ör. BUS2081) ilişkilendirilmiş bir Workflow örneğinin başlangıcını kaydeden SAP Business Workflow günlüklerinden (SWW* tabloları) alınabilir. Yakalayın Fatura belgesiyle ilişkilendirilmiş SAP Workflow günlüklerinden (ör. SWW_WIHEAD tablosu) Workflow başlangıç olaylarını çıkarın. Olay türü explicit | |||
| Fatura park edildi | Faturanın sisteme girildiğini, ancak henüz genel deftere kaydedilmediğini gösterir. Bu adım genellikle tamamlanmamış bir belgeyi daha sonra işlemek veya onaylamak üzere kaydetmek için bilinçli olarak kullanılır. | ||
| Neden önemli? Park edilen faturaları izlemek, resmi kayıt işlemi başlamadan önceki gecikmeleri belirlemeye yardımcı olur ve veri eksiksizliği veya ilk doğrulamayla ilgili sorunları ortaya çıkarabilir. Nereden alınır? Bu durum, muhasebe belgesi başlığındaki durum alanından (BKPF-BSTAT = 'V', Parked) çıkarılır. Olay, durum ayarlandığında gerçekleşir. Yakalayın BSTAT alanının 'V' (Vor-erfasst/Önceden girilmiş) olarak ayarlandığı BKPF tablosundaki değişiklik belgelerini belirleyin. Olay türü inferred | |||
| Fatura reddedildi | Bir onaylayan, onay iş akışı sırasında faturayı reddetmiştir. Bu işlem genellikle faturanın düzeltilmesi veya açıklama eklenmesi için işlem sorumlusuna geri gönderilmesini sağlar. | ||
| Neden önemli? Reddetmeleri izlemek, onay sürecindeki yeniden işleme döngülerini ortaya çıkarır ve politika uyumluluğu ya da hatalı fatura kodlamasıyla ilgili sorunlara işaret edebilir. Nereden alınır? Faturayla ilişkili SAP Business Workflow günlüklerinde belirli bir sonuç olayı olarak kaydedilir. Yakalayın SAP Workflow günlüklerinden Workflow 'reddedildi' durum olaylarını çıkarın. Olay türü explicit | |||
| Fatura vade tarihi geçti | Faturanın net vade tarihinin, faturaya karşılık bir ödeme kapatılmadan geçtiğini gösteren hesaplanmış bir olaydır. Bu durum, ödemenin geciktiğini veya vadesinin geçtiğini gösterir. | ||
| Neden önemli? 'Payment Compliance & Aging' Dashboardı için gerekli olan bu etkinlik, vadesi geçen faturaları proaktif biçimde belirleyip yönetmenize ve geç ödemelerin temel nedenlerini analiz etmenize yardımcı olur. Nereden alınır? SAP'de açıkça kaydedilen bir olay değildir. Sistemin geçerli tarihinin Net Vade Tarihiyle karşılaştırılmasıyla hesaplanır. Net Vade Tarihi, BSEG-ZFBDT veya temel tarih ve ödeme koşullarından hesaplanır. Yakalayın Olay zaman damgası fatura net vade tarihinden büyük olduğunda tetiklenen hesaplanmış olaydır. Olay türü calculated | |||
| Mal girişiyle eşleştirildi | Bu faaliyet, fatura miktarlarının ve tutarlarının ilgili bir mal girişi belgesiyle başarıyla eşleştirildiğini gösterir. 3'lü eşleştirme senaryosundaki son doğrulama adımıdır. | ||
| Neden önemli? Bunu izlemek, 3'lü eşleştirme sürecindeki verimsizlikleri belirlemeye ve alınan mallarla tedarikçinin faturalandırdığı mallar arasındaki uyuşmazlıkları ortaya çıkarmaya yardımcı olur. Nereden alınır? Fatura kaleminde bir malzeme belgesi referansının (mal girişi) bulunmasından çıkarılır. Bu referans genellikle satın alma siparişi kalem geçmişi üzerinden ilişkilendirilir. Yakalayın Fatura kaleminde bir Mal Girişi belgesi referansının bulunmasından çıkarılır. Örneğin MIRO faturaları için RSEG tablosu kullanılabilir. Olay türü inferred | |||
| Ödeme teklifi oluşturuldu | Fatura, bir ödeme çalışmasının (ör. F110) parçası olarak ödeme teklifine dahil edilmiştir. Çalışmanın son yürütülmesi beklenirken ödeme için sıraya alınmıştır. | ||
| Neden önemli? Bu faaliyet, açık bir yükümlülüğün ödeme için aktif olarak hazırlanan bir kaleme dönüşümünü gösterir ve ödeme operasyonlarının verimliliğini analiz etmeye yardımcı olur. Nereden alınır? Bu olay, özellikle REGUP (Ödeme Programından İşlenen Kalemler) ve REGUH (Başlık) olmak üzere ödeme çalışması veri tablolarında açıkça kaydedilir. Yakalayın Bir faturanın REGUH'da tanımlanan bir ödeme çalışması için REGUP tablosunda göründüğü zamanı belirleyin. Olay türü explicit | |||
| Satın alma siparişiyle eşleştirildi | Bu faaliyet, faturanın ilgili bir satın alma siparişiyle başarıyla eşleştirildiğini gösterir. Satın alma tabanlı faturalar için 3'lü eşleştirme sürecinin önemli bir adımıdır. | ||
| Neden önemli? Bu faaliyeti analiz etmek, eşleştirme sürecinin verimliliğini ölçmeye yardımcı olur ve '3'lü Eşleştirme Performansı' ile 'Satın Alma Siparişi Olmayan Fatura Yüzdesi' KPI'ları için temel oluşturur. Nereden alınır? Bu durum, BSEG veya ACDOCA tablosundaki bir fatura kaleminde geçerli bir Satın Alma Siparişi numarası (EBELN) ve kalem numarası (EBELP) bulunduğunda çıkarılır. Yakalayın Fatura belgesi oluşturulurken Satın Alma Siparişi referansının (BSEG-EBELN) bulunmasından çıkarılır. Olay türü inferred | |||
| Uyuşmazlık çözüldü | Bu faaliyet, daha önce belirlenen ve muhtemelen ödeme blokesi oluşturan bir sorunun incelenip çözüldüğünü gösterir. Ödeme blokesi faturadan kaldırıldığında kaydedilir. | ||
| Neden önemli? Bu yeniden çalışma döngüsünü izlemek, 'Invoice Discrepancy Rework Analysis' Dashboardı için büyük önem taşır. Hataları düzeltmek için harcanan zamanı ve emeği ölçmenize 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ına ilişkin değişiklik günlüğü temel kaynaktır. Yakalayın ZLSPR alanının bir değerden boş değere değiştirildiği BSEG tablosundaki değişiklik belgelerini belirleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşullar ve erişim: CDS görünümlerinin bulunduğu SAP S/4HANA veritabanı şemasına, genellikle SAPABAP1 veya benzerine, okuma erişimi olan bir kullanıcıya sahip olduğunuzdan emin olun. SAP HANA veritabanına bağlanabilen SAP HANA Studio, DBeaver veya benzeri bir SQL istemci aracına ihtiyacınız olacaktır.
- Temel CDS görünümlerini belirleyin: Bu aktarım için temel CDS görünümleri I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails ve I_PaymentProposalItem görünümleridir. Bu görünümlerdeki temel alanları öğrenin.
- Sorgu kapsamını belirleyin: SQL istemcinizi açın ve SAP HANA veritabanına bağlanın. Tam sorguyu çalıştırmadan önce aktarım 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 eksiksiz SQL sorgusunu SQL istemcinize kopyalayın. Sorgu, önce temel bir fatura kümesi seçmek, ardından 15 farklı etkinliğe ait verileri birleştirerek bir 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]' ifadesini analiz döneminizin başlangıç ve bitiş tarihleriyle değiştirin. '[Your Company Code 1]' ve '[Your Company Code 2]' ifadelerini analiz etmek istediğiniz SAP Şirket Kodları listesiyle değiştirin.
- Aktarım sorgusunu çalıştırın: Eksiksiz SQL sorgusunu ç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ı inceleyin. Veri tutarlılığını kontrol edin, tüm sütunların beklendiği gibi doldurulduğundan emin olun ve farklı ActivityName değerlerinin bulunduğunu doğrulayın.
- Event Logu dışa aktarın: SQL istemcinizdeki sonuç kümesinin tamamını bir CSV dosyasına aktarın. Karakter sorunlarını önlemek için dosyanın UTF-8 kodlamasına sahip olduğundan emin olun. Dosyayı örneğin sap_s4hana_ap_event_log.csv gibi açıklayıcı bir adla kaydedin.
- Yüklemeye 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şturulan CSV dosyasını Process Mining platformunuza yükleyin ve sütunları ilgili vaka kimliği, etkinlik ve zaman damgası alanlarıyla eşleştirin.
Yapılandırma
- Temel CDS görünümleri: Aktarım, standart S/4HANA CDS görünümlerinin birleşimine 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 kapatma bilgileri için.
- I_SupplierInvoiceAPI01: PO referansları ve ödeme blokları dahil MM (Lojistik) faturalarına özgü ayrıntılar için.
- I_ChangeDocument: Ödeme bloğunun ayarlanması veya kaldırılması gibi değişikliklerin kesin 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ırması önerisine ne zaman dahil edildiğini belirlemek için.
- I_Supplier: Verileri VendorName gibi tedarikçi ana verileriyle zenginleştirmek için.
- Tarih aralığı filtreleme: Veri hacmini sınırlamak için tarih aralığı filtresi uygulamak büyük önem taşır. Verilen sorgu, Invoices_Base CTE içinde CreationDateTime alanına göre filtreleme yapar. Yönetilebilir bir performans sağlamak için ilk analizde 3-6 aylık bir aralık önerilir.
- Zorunlu filtreler: Her zaman CompanyCode alanına göre filtreleme yapın. Tüm şirket kodlarındaki verileri aynı anda analiz etmek son derece yavaş olabilir ve iş açısından anlamlı olmayabilir. Ayrıca yalnızca tedarikçiyle ilgili belgeleri seçmek için JournalEntryType alanına göre de filtreleyin, örneğin 'KR' ve 'RE'.
- Ön koşullar: Sorguyu çalıştıran veritabanı kullanıcısının, sorguda kullanılan tüm CDS görünümleri ve temel HANA şeması üzerinde SELECT yetkisi olmalıdır. SAP GUI düzeyindeki uygulama erişimi yeterli değildir.
- Performans değerlendirmeleri: I_ChangeDocument üzerinde doğrudan sorgular kaynak tüketebilir. Verilen sorgu, önce faturaları filtreleyerek bu etkiyi azaltmaya çalışır. Çok büyük veri setlerinde aktarımı yoğun olmayan saatlerde veya daha küçük tarih aralıklarına bölerek çalıştırmayı değerlendirin.
a Ö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şiminizin bulunduğunu doğrulayın. BKPF, ACDOCA ve bekletilen belgeler, iş akışı, satın alma, mal kabulü, ödeme önerileri, kapatma ve ters kayıt verileri için yapılandırılmış ek tabloları okumak üzere gereken bağlantı dizesini, kimlik bilgilerini, şema adını ve yetkileri edinin.
- Çalıştırmadan önce hedef sistemdeki teknik veri modelini doğrulayın. Sistemin kullandığı fiziksel adları, anahtar alanlarını, zaman damgası alanlarını, ters kayıt ilişkilerini, ödeme ilişkilerini ve iş akışı kalıcılığını kontrol edin. Sorgudaki köşeli parantez içindeki her yer tutucuyu sistemdeki ilgili nesne veya alanla değiştirin. İş akışı veya bekletilen belge verilerinin tek bir evrensel tabloda tutulduğunu varsaymayın.
- Aktarım parametrelerini yapılandırın. [Start date], [End date], [Company code filter], [Document type filter] ve [Schema name] değerlerini ayarlayın. Başlangıçta üç ila altı aylık bir tarih aralığı kullanın, ardından performans ve eksiksizlik doğrulandı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 ve olayları çıkarmak için ProcessMind’in çıkarım yapmasına dayanmaz.
- Sonuç kümesini doğrulayın. Invoice alanının vaka tanımlayıcısı olduğunu, ActivityName alanının gerekli 15 etkinlik adının tamamını içerdiğini, 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 aktarım yenileme zaman damgasını içerdiğini doğrulayın. Verileri yüklemeden önce yinelenen olayları, ters kayıt ilişkilerini ve belge birleştirmelerini inceleyin.
- Sistem gerektiren eşleştirmeleri 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şleştirin. Denetim izlenebilirliği gerekiyorsa kaynak tanımlayıcılarını ek sütunlarda koruyun.
- Sonucu, her satırda bir olay olacak şekilde ayrı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, Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber ve InvoiceDueDate sütun adlarını aynen koruyun ve etkinlikleri fatura bazında toplamayın.
- Event Logu ProcessMind’e yükleyin ve Invoice alanını vaka tanımlayıcısı, ActivityName alanını etkinlik sütunu, EventTime alanını olay zamanı sütunu olarak yapılandırın. İsteğe bağlı özniteliklerin ilgili alanlarla eşleştirildiğini doğrulayın. ProcessMind Event Logu olduğu gibi okuduğu için görselleştirilmesini istediğiniz her etkinliğin yüklemeden önce bir satır olarak mevcut olduğundan emin olun.
Yapılandırma
- Tarih aralığı: Üç ila altı ayla başlayın. Çıkarılan faaliyete göre kayıt tarihi, belge oluşturma tarihi veya ilgili kaynak olay tarihini kullanın. Aralığı yalnızca sorgu çalışma süresini ve kaynak saklama süresini doğruladıktan sonra genişletin.
- Company filtreleme: Çıkarma işlemini gerekli Company Code değerleriyle sınırlamak için [Company code filter] alanını yapılandırın. Herhangi bir sınırlama gerekmiyorsa, kısıtlanmamış bir üretim sorgusu yerine kontrollü bir tüm şirketler seçimi kullanın.
- Belge filtreleme: [Document type filter] alanını yalnızca hedef sistemde satıcı faturaları, alacak dekontları, park edilmiş belgeler, ödeme belgeleri ve ters kayıtlar için kullanılan belge türlerini doğruladıktan sonra yapılandırın.
- Şema ve nesne eşleştirmesi: [Schema name] ile köşeli parantez içindeki tüm kaynak nesne veya alanları hedef SAP S/4HANA sisteminde doğrulanmış değerlerle değiştirin. Doğrudan HANA sorgusu, sistemde etkinleştirilen uygulamalara, eklentilere, Workflow tasarımına ve veri modeline göre uyarlanmalıdır.
- Zaman damgası işleme: Tüm kaynak zaman damgalarını tek bir saat diliminde normalleştirin. Yalnızca tarih mevcutsa belgelenmiş bir varsayılan saat bileşeni kullanın ve bu sınırlamayı veri sözlüğüne kaydedin.
- Olay anlamı: Her faaliyeti ayrı bir satır olarak çıkarın. Birden fazla faaliyeti tek bir fatura kaydında birleştirmeyin ve ProcessMind'ın eşleştirme, onay, vade tarihi veya mahsup olaylarını kendiliğinden oluşturmasını beklemeyin.
- Vade tarihi olayı: Invoice Due Date Passed olayını yalnızca vade tarihi yapılandırılmış değerlendirme zaman damgasından önce olan ve bu zaman damgasına kadar mahsup olayı bulunmayan faturalar için oluşturun. Sorgu bu hesaplama için [Evaluation timestamp] değerini kullanır.
- Performans: İlk dönemi ve şirket kapsamını sınırlayın, dizinlenmiş veya bölümlendirmeyle ilgili alanlara filtre uygulayın, gereksiz geniş projeksiyonlardan kaçının ve işlemi onaylı bir raporlama zaman aralığında çalıştırın. Üretim sorgusu üzerinde anlaşılan çalışma süresini aşarsa kaynak alt kümelerini hazırlamayı değerlendirin.
- Yenileme stratejisi: LastDataUpdate alanını çıkarma işleminin yürütülme zaman damgasına ayarlayın. Artımlı yüklemelerde, ilgili kaynak değişiklik zaman damgasına dayalı bir watermark tutun ve geç güncellemeleri ve ters kayıtları yakalamak için geriye dönük bir dönem ekleyin.
- Ön koşullar: Gerekli veritabanı yetkileri, onaylı üretim erişimi, sistemin Universal Journal yapılandırması hakkında bilgi, yapılandırılmış park edilmiş belge, satın alma, mal kabulü, Workflow, ödeme, mahsup ve ters kayıt kaynaklarına erişim ve geçerli SAP lisans veya yönetişim onayları.
a Ö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
- Belirtim ve tasarım: Kodlamaya başlamadan önce iş analistleriyle birlikte çalışarak gerekli 15 faaliyetin her biri için kesin tetikleme koşullarını ve veri alanlarını doğrulayın. İlgili SAP tablolarını, belge türlerini, örneğin 'KR' ve 'RE', ve kapsama dahil edilecek Company Code değerlerini 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 girin ve uygulamayı 'Financial Accounting' olarak ayarlayın.
- Seçim ekranını tanımlayın: Programda, kullanıcıların çıkarma tarih aralığını, hedef Company Code değerlerini (BUKRS) ve ilgili fatura Document Type değerlerini (BLART) belirlemesine olanak tanımak 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 bildirimleri: Gerekli ve önerilen tüm öznitelikleri içeren, son Event Log biçimiyle eşleşen bir dahili tablo yapısı, örneğin TY_EVENT_LOG, 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çimi: Çıkarma mantığını, kullanıcının seçim ekranı ölçütlerine göre RBKP'den (Lojistik Faturalar) ve BKPF'den (Finansal Faturalar) birincil fatura kümesini seçerek başlatın. Sonraki veri aramalarını yönlendirmek üzere bu birincil fatura anahtarlarını bir dahili tabloda saklayın.
- Faaliyetleri sırayla çıkarın: Ana kümedeki her fatura için her iş faaliyetinin zaman damgalarını ve ayrıntılarını bulmak üzere bir dizi seçim gerçekleştirin. Örneğin ödeme bloğu değişiklikleri için CDHDR ve CDPOS'u, ödeme çalıştırması verileri için REGUH ve REGUP'u, ters kayıt belgesi ayrıntıları için BKPF'yi sorgulayın. Bulduğunuz her faaliyet için son Event Log tablosuna yeni bir kayıt ekleyin.
- Hesaplanan olayların mantığı: Bir tablo alanında doğrudan saklanmayan faaliyetler 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 ayarlayarak yeni bir olay kaydı oluşturun.
- Veri dönüştürme ve zenginleştirme: Her faaliyet için veri toplarken gerekli tüm öznitelikleri doldurun. Bunun için LFA1'den satıcı adlarını arayın, tarih ve saatleri tek bir zaman damgası dizesine 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 faaliyetler işlenip son dahili tabloda toplandıktan sonra, seçim ekranında belirtilen uygulama sunucusu yolundaki dosyaya veri yazmak için OPEN DATASET, LOOP AT ... TRANSFER ve CLOSE DATASET ifadelerini kullanın.
- İndirin ve yüklemeye hazırlayın: Oluşturulan dosyayı uygulama sunucusundan yerel makinenize 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, örneğin Invoice, ActivityName ve EventTime, eşleştiğini doğrulayın.
Yapılandırma
- Tarih aralığı: Fatura oluşturma tarihi (BKPF-CPUDT veya RBKP-CPUDT) için P_CPUDT seçim seçeneğini tanımlayın. İlk analiz için 6-12 aylık veri aralığı önerilir.
- Company Code (P_BUKRS): Belirli Company Code değerlerine göre filtreleme yapmak için zorunlu bir SELECT-OPTIONS parametresidir. Kesinlikle gerekli olmadıkça tüm Company Code değerlerinin aynı anda işlenmesi önerilmez.
- Fatura Document Type (P_BLART): İlgili fatura belge türlerine göre filtreleme yapmak için bir SELECT-OPTIONS parametresidir. Yaygın türler arasında 'KR' (Satıcı Faturası), 'KG' (Satıcı Alacak Dekontu) ve 'RE' (Lojistik Fatura Doğrulaması) bulunur.
- Çalıştırma modu: Büyük veri hacimlerinde zaman aşımını önlemek için program ön plan iletişim süreci yerine arka plan işi (SM36/SM37) olarak çalıştırılmalıdır. Çalışmayı yoğun olmayan saatlerde planlayın.
- Çıktı dosyası yolu: SAP uygulama sunucusundaki dosya yolunu ve adını belirtmek için bir PARAMETER kullanın, örneğin /tmp/ dizini. Dosya indirilmeden önce buraya 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 Workflow tablolarını okuma yetkisi olmalıdır. Ayrıca uygulama sunucusuna dosya yazmak için S_DATASET yetki nesnesi gereklidir.
a Ö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 şablondan yararlanın. Daha optimize ve akıcı bir sürece giden yolculuğunuza bugün başlayın.
Geç ödeme ücretlerini durdurun: AP fatura işleme sürecinizi bugün optimize edin
İşleme maliyetlerini %60 azaltın ve yinelenen ödemeleri kolayca ortadan kaldırın.
Kredi kartı gerekmez, dakikalar içinde başlayın.