Siparişten Tahsilata - Faturalandırma ve Fatura Veri Şablonunuz
Siparişten Tahsilata - Faturalandırma ve Fatura Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- `SAP S/4HANA` için Veri Çıkarma Kılavuzu
Siparişten Nakde (Order to Cash) - Faturalama ve Muhasebeleştirme Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Fatura Numarası InvoiceNumber | Bir faturalama belgesi için benzersiz tanımlayıcı, faturalama süreci için birincil case tanımlayıcısı olarak hizmet eder. | ||
| Açıklama SAP'de Faturalama Belgesi Numarası olarak bilinen Fatura Numarası, her faturalama işlemini benzersiz bir şekilde tanımlar. Fatura oluşturma ve muhasebeleştirmeden ödeme alma ve mutabakata kadar ilgili tüm aktiviteleri birbirine bağlayan merkezi anahtar görevi görür. Process mining'de bu öznitelik, case korelasyonu için esastır. Aynı Fatura Numarasını paylaşan tüm event'ler tek bir süreç örneğinde gruplandırılır, bu da her bir fatura için faturalama yaşam döngüsünün eksiksiz, uçtan uca analizini sağlar. Bu, döngü sürelerini takip etmeyi, sapmaları belirlemeyi ve her faturanın yolculuğunu analiz etmeyi mümkün kılar. Neden önemli Tüm ilgili faturalama faaliyetlerini tek bir vakada birleştiren temel tanımlayıcıdır, böylece uçtan uca süreç analizi mümkün olur. Nereden alınır SAP Tablosu: VBRK, Alan: VBELN Örnekler 900012349000567890009012 | |||
| Faaliyet Adı ActivityName | Faturalama süreci içinde gerçekleşen iş aktivitesinin veya event'inin adı, örneğin 'Fatura Oluşturuldu' veya 'Ödeme Alındı'. | ||
| Açıklama Aktivite Adı, faturalama yaşam döngüsündeki belirli bir adımı veya kilometre taşını tanımlar. Bu aktiviteler, sıralı bir süreç akışı oluşturmak için işlem kodları, belge durumu değişiklikleri veya belirli log girişleri gibi SAP'deki çeşitli veri noktalarından türetilir. Bu aktivitelerin sırasını ve sıklığını analiz etmek, process mining'in özüdür. Süreç haritasını görselleştirmeye, yaygın ve nadir süreç varyantlarını keşfetmeye, adımlar arasındaki darboğazları belirlemeye ve yeniden çalışma veya iptaller gibi katma değersiz aktivitelerin sıklığını ölçmeye yardımcı olur. Neden önemli Bu öznitelik, süreçteki adımları tanımlar, süreç haritalarının görselleştirilmesini ve süreç akışı, varyasyonlar ve darboğazların analizini mümkün kılar. Nereden alınır İşlem kodları (SY-TCODE), değişiklik belgesi durumları (CDHDR/CDPOS tabloları) veya iş akışı günlükleri (örn. SWW_WI2OBJ) dahil olmak üzere çeşitli kaynaklardan türetilir. Örnekler Fatura OluşturulduFatura MuhasebeleştirildiMüşteri Ödemesi AlındıFatura İptal Edildi | |||
| Olay Zamanı EventTime | Bir aktivite veya event'in ne zaman gerçekleştiğini gösteren kesin timestamp. | ||
| Açıklama Olay Zamanı, her faaliyet için tarih ve saati sağlar, sürecin kronolojik omurgasını oluşturur. Bu zaman damgası, faturalama sürecindeki farklı adımlar arasındaki süreleri, döngü sürelerini ve bekleme sürelerini hesaplamak için çok önemlidir. Analizde, Olay Zamanı faaliyetleri sıralamak, Tahsil Edilmeyi Bekleyen Gün Sayısı ve Fatura Oluşturma Döngü Süresi gibi temel performans göstergelerini hesaplamak ve zaman bazlı darboğazları belirlemek için kullanılır. Sürecin dinamik bir görünümünü sağlar, performansın zaman içinde nasıl değiştiğini ve faturalama döngüsünün her aşamasının ne kadar sürdüğünü gösterir. Neden önemli Olayların kronolojik sırasını sağlar, bu da döngü süreleri ve süreler gibi tüm zaman bazlı metrikleri hesaplamak için esastır. Nereden alınır Faaliyete bağlı olarak çeşitli tarih ve saat alanlarından alınır; örneğin oluşturma tarihi ve saati (VBRK-ERDAT, VBRK-ERZET), değişiklik zaman damgaları (CDHDR-UDATE, CDHDR-UTIME) veya kayıt tarihi (BKPF-BUDAT). Örnekler 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Bitiş Saati EndTime | Bir aktivite veya event'in ne zaman tamamlandığını gösteren kesin timestamp. | ||
| Açıklama Bitiş Zamanı, bir aktivitenin tamamlanmasını işaret eder. Process mining'de bu genellikle case'deki sonraki aktivitenin Başlangıç Zamanı olarak çıkarılır veya sistem hem başlangıç hem de bitiş event'lerini kaydederse doğrudan kaynaklanabilir. Bu öznitelik, bireysel aktivitelerin İşlem Süresini hesaplamak için esastır. Bitiş Zamanından Başlangıç Zamanını çıkararak, her adımın süresini ölçebiliriz, bu da fatura onay aşamasındaki gecikmeleri belirlemek gibi darboğaz analizi için çok önemlidir. Neden önemli Her faaliyetin kesin süresinin (işlem süresi) hesaplanmasını sağlayarak darboğaz analizi için temel oluşturur. Nereden alınır Bu, process mining için türetilmiş bir özniteliktir. Genellikle case dizisindeki bir sonraki event'in Başlangıç Zamanı olarak hesaplanır. Bazı senaryolarda, belirli tablolar tamamlama sürelerini kaydedebilir. Örnekler 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Bölge Region | Müşterinin coğrafi bölgesi. | ||
| Açıklama Bölge özniteliği, müşterinin adresiyle ilişkili coğrafi alanı (eyalet veya il gibi) gösterir. Bu veri genellikle müşteri ana kaydının bir parçasıdır. Bu öznitelik, Bölgesel Faturalama Performansı dashboard'u için anahtardır. Farklı bölgelerdeki döngü süreleri, hata oranları ve DSO gibi temel metriklerin kıyaslanmasına olanak tanır. Bu karşılaştırma, süreç yürütme, uyumluluk veya verimlilikteki bölgesel farklılıkları vurgulayabilir, hedeflenmiş iyileştirmelerin ve en iyi uygulamaların standardizasyonunun önünü açar. Neden önemli Farklı coğrafi alanlarda faturalama performansının karşılaştırılmasını sağlayarak bölgesel farklılıkları belirlemeye ve süreçleri standartlaştırmaya yardımcı olur. Nereden alınır Müşteri ana veri tablosu KNA1'den (Alan: REGIO) alınır, fatura başlığındaki Ödeyen Kimliği (VBRK-KUNRG) aracılığıyla bağlanır. Örnekler CANYTXBA | |||
| Fatura Tarihi InvoiceDate | Faturanın müşteriye düzenlendiği resmi tarih. | ||
| Açıklama SAP'de faturalama tarihi olarak da bilinen Fatura Tarihi, birçok finansal hesaplama için başlangıç noktası olarak hizmet eder. Ödeme koşulları, vade tarihleri ve alacağın yaşı bu tarihten itibaren belirlenir. Bu tarih, finansal analiz için kritik bir case seviyesi özniteliğidir. Günlük Satış Bekletme Süresi (DSO) KPI'sını hesaplamak ve nakit akışını ve tahsilatları yönetmek için temel araçlar olan bekleyen fatura yaşlandırma raporları oluşturmak için temeldir. Neden önemli Finansal hesaplamalar için birincil tarihtir, DSO, ödeme vadeleri ve fatura yaşlandırma analizi için başlangıç noktası olarak işlev görür. Nereden alınır SAP Tablosu: VBRK, Alan: FKDAT Örnekler 2023-03-202023-04-012023-05-18 | |||
| Fatura Tutarı InvoiceAmount | Faturanın toplam net değeri. | ||
| Açıklama Bu öznitelik, faturalanan mal veya hizmetlerin vergiler hariç toplam parasal değerini temsil eder. Her fatura case'i için temel bir finansal veri noktasıdır. Fatura Tutarı, geniş bir analiz yelpazesinde kullanılır. Sürecin değere göre segmentlere ayrılmasına olanak tanır; örneğin, yüksek değerli faturaların farklı şekilde işlenip işlenmediğini veya daha fazla gecikme yaşayıp yaşamadığını görmek için. Aynı zamanda finansal raporlama ve bekleyen alacakların toplam değerini hesaplamak için temeldir. Neden önemli Her faturanın finansal değerini nicelikselleştirir, değere dayalı analizi, tahsilatların önceliklendirilmesini ve finansal etki değerlendirmesini mümkün kılar. Nereden alınır SAP Tablosu: VBRK, Alan: NETWR Örnekler 1500.0025000.50125.75 | |||
| Kullanıcı Adı UserName | Aktiviteyi yürüten çalışanın kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, fatura oluşturma, belge muhasebeleştirme veya ödeme clear etme gibi belirli bir event'ten sorumlu SAP kullanıcı kimliğini yakalar. Süreç adımları ile bunları gerçekleştiren kişiler veya ekipler arasında bir bağlantı sağlar. Kullanıcı Adına göre analiz yapmak, yüksek performanslı kişileri, eğitim ihtiyaçlarını veya iş yükü dağıtım dengesizliklerini belirlemeye yardımcı olur. Aynı zamanda uyumluluk analizi için de kritik öneme sahiptir, kritik aktiviteleri kimin gerçekleştirdiğini gösterir ve farklı kullanıcıların aynı süreci nasıl yürüttüğündeki varyasyonları anlamak için kullanılır. Neden önemli Süreç faaliyetlerini belirli kullanıcılara bağlar, bireysel veya ekip düzeyinde iş yükü, performans ve uyumluluk analizini mümkün kılar. Nereden alınır Oluşturma olayları için bu VBRK-ERNAM'dadır. Sonraki değişiklikler için CDHDR-USERNAME gibi değişiklik geçmişi tablolarında veya workflow günlüklerinde bulunur. Örnekler CBURNSHSIMPSONLLEONARD | |||
| Müşteri Adı CustomerName | Faturanın düzenlendiği müşterinin adı. | ||
| Açıklama Bu öznitelik, faturalanan müşterinin yasal adını tanımlar. SAP'deki merkezi müşteri ana verilerinden alınır. Süreci müşteriye göre analiz etmek, belirli hesaplara özgü kalıpların belirlenmesine olanak tanır. Örneğin, hangi müşterilerin sürekli geç ödeme yaptığını, hangilerinin en çok itirazda bulunduğunu veya faturalama sürecinin kimler için en verimsiz olduğunu ortaya çıkarabilir. Bu durum, hedeflenmiş müşteri ilişkileri yönetimi ve özel tahsilat stratejileri sağlar. Neden önemli Müşteri odaklı analizi mümkün kılar, belirli hesaplar için ödeme davranışlarını, anlaşmazlık sıklıklarını ve süreç verimsizliklerini belirlemeye yardımcı olur. Nereden alınır Müşteri ana veri tablosu KNA1'den (Alan: NAME1) alınır, fatura başlığındaki Ödeyen Kimliği (VBRK-KUNRG) aracılığıyla bağlanır. Örnekler Springfield Güç SantraliKwik-E-MartCyberdyne Systems | |||
| Son Ödeme Tarihi PaymentDueDate | Müşterinin faturayı ödemesi beklenen tarih. | ||
| Açıklama Ödeme Vadesi, fatura tarihi ve üzerinde anlaşılan ödeme koşullarına göre hesaplanır. Faturanın vadesi geçmeden ödemenin alınması için son tarihi temsil eder. Bu öznitelik, tahsilat etkinliğini ve nakit akışı tahminini izlemek için esastır. Zamanında Ödeme Oranı KPI'sını hesaplamakta ve yaşlandırma raporlarında faturaları segmentlere ayırmakta doğrudan kullanılır. Vade tarihi ile fiili ödeme tarihi arasındaki sapmaları analiz etmek, farklı ödeme koşullarının etkinliğini değerlendirmeye yardımcı olur. Neden önemli Müşteri ödemesi için son tarihi belirler, bu da zamanında ödeme oranlarını hesaplamak ve alacakları yönetmek için çok önemlidir. Nereden alınır Bu tarih doğrudan saklanmaz ancak Fatura Tarihi (VBRK-FKDAT) ve Ödeme Koşulları anahtarı (VBRK-ZTERM) kullanılarak SAP'nin standart tarih belirleme fonksiyonları ile hesaplanır. Örnekler 2023-04-192023-05-012023-06-17 | |||
| Faturalama Belgesi Türü BillingDocumentType | Fatura, kredi notu veya iptal gibi faturalama belgesini sınıflandıran bir kod. | ||
| Açıklama Faturalama Belgesi Türü, faturalama sürecindeki işlemleri kategorize eden önemli bir alandır. Belgenin numara aralığı ve muhasebe kayıt kuralları dahil olmak üzere nasıl işleneceğini kontrol eder. Bu öznitelik, belirli işlem türlerini analiz etmek için süreci filtrelemeye olanak tanır. Örneğin, finansal düzeltmelerin nedenlerini ve süreç akışını anlamak için sadece alacak dekontları için ayrı bir süreç görünümü oluşturulabilir veya birincil faturalama sürecinin daha net bir resmini elde etmek için standart faturalar iptallerden ayrı ayrı analiz edilebilir. Neden önemli İşlemleri sınıflandırır, standart faturalar, kredi notları veya iptaller gibi belirli belge akışları üzerinde odaklanmış analiz yapılmasını sağlar. Nereden alınır SAP Tablosu: VBRK, Alan: FKART Örnekler F2G2S1L2 | |||
| İşlem Süresi ProcessingTime | Bir aktivitenin süresi, başlangıcından bitiş zamanına kadar hesaplanır. | ||
| Açıklama İşlem Süresi, bir görev üzerinde aktif olarak çalışılan süreyi ölçer, görevler arasındaki bekleme süresinin aksine. Bir aktivitenin Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark olarak hesaplanır. Bu hesaplanmış metrik, performans analizinin temel taşıdır. Fatura Onay Darboğaz Analizi gibi dashboard'larda belirli adımların ne kadar sürdüğünü niceliksel olarak belirlemek için kullanılır. Belirli aktiviteler için yüksek işlem süreleri, verimsizlikleri, karmaşıklığı veya otomasyon ihtiyacını gösterebilir. Neden önemli Süreç adımlarının aktif süresini ölçer, optimizasyon veya otomasyon için öncelikli aday olan verimsiz faaliyetleri belirlemeye yardımcı olur. Nereden alınır Veri dönüştürme süreci sırasında 'Başlangıç Zamanı'nın 'Bitiş Zamanı'ndan çıkarılmasıyla türetilen hesaplanmış bir metrik. Örnekler PT30M5DPT1H15M | |||
| Kaynak Sistem SourceSystem | Verinin çıkarıldığı belirli kaynak sistemi tanımlar. | ||
| Açıklama Bu öznitelik, verinin kaynağını belirtir; bu da birden fazla SAP örneği veya diğer entegre sistemlerin bulunduğu ortamlarda özellikle faydalıdır. Genellikle sistem kimliğini ve istemci numarasını içerir. Analizde, farklı sistemler veya organizasyonel varlıklar arasındaki süreçleri ve performansı ayırt etmeye yardımcı olur. Veri soy ağacını sağlar ve özellikle birden çok kaynaktan gelen veriler bütünsel bir süreç görünümü için birleştirildiğinde bağlam sunar. Neden önemli Verinin kökeni hakkında kritik bağlam sağlar, çoklu sistem ortamlarında netliği ve veri yönetişimini destekler. Nereden alınır Bu genellikle veri çıkarma sırasında tanımlanan statik bir değerdir, genellikle sistem kimliği (SY-SYSID) ve istemci (SY-MANDT) birleşiminden oluşur. Örnekler S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Kredi Notu Nedeni CreditMemoReason | Bir alacak dekontunun neden düzenlendiğini gösteren neden kodu. | ||
| Açıklama Bir fatura yanlış olduğunda ve alacak dekontu gerektirdiğinde, alacak dekontu belgesine genellikle bir neden atanır. Bu, faturalama hatalarının kaynaklarını kategorize etmek için yapılandırılmış bir yol sağlar. Bu öznitelik, Faturalama Hata Oranı KPI'sını doğrudan destekler. Alacak dekontlarının nedenlerini toplayarak ve analiz ederek, bir şirket fiyatlandırma hataları veya ürün iadeleri gibi en yaygın hata türlerini belirleyebilir. Bu analiz, finansal düzeltme ve yeniden işleme ihtiyacını azaltmayı amaçlayan süreç iyileştirmelerini yönlendirir. Neden önemli Kredi düzenleme nedenlerini kategorize eder, bu da faturalama hatalarının en sık görülen kaynaklarını belirlemeye ve kalite iyileştirmelerini sağlamaya yardımcı olur. Nereden alınır SAP Tablosu: VBRK, Alan: AUGRU (Sipariş Nedeni). Bu alan, daha sonra faturalandırılan alacak/borç dekontu taleplerinde kullanılır. Örnekler 001 - Fiyat Farkı002 - Kötü Kalite005 - Müşteri İadesi | |||
| Ödeme Durumu PaymentStatus | Fatura ödemesinin Açık, Ödendi veya Vadesi Geçmiş gibi mevcut durumu. | ||
| Açıklama Ödeme Durumu, bir faturanın tahsilat yaşam döngüsünde nerede olduğunu gösteren anlık bir görüntüdür. Bu, SAP'de tek bir alan değildir, ancak ilgili muhasebe belgesinin temizleme durumu kontrol edilerek elde edilir. Bu öznitelik, Bekleyen Fatura Yaşlandırma dashboard'u için çok önemlidir. Tüm açık faturaların durumlarına ve yaşlarına göre segmentlere ayrılmasını sağlayarak, tahsilat ekibinin çabalarını etkili bir şekilde önceliklendirmesine yardımcı olur. Durumlar arasındaki geçişleri takip etmek, tahsilat sürecini izlemenin de bir yoludur. Neden önemli Bir faturanın tahsilat durumuna dair net, tek bakışta bir görünüm sunar, bu da alacakları yönetmek ve tahsilat çabalarını önceliklendirmek için hayati önem taşır. Nereden alınır Muhasebe belgesinin (VBRK-BELNR) açık kalemler (BSID) ve kapatılan kalemler (BSAD) gibi finansal tablolardaki mahsuplaşma durumu kontrol edilerek türetilir. Örnekler AçıkÖdendiVadesi GeçmişKısmen Ödendi | |||
| Ödeme Vadeleri PaymentTerms | Ödeme için izin verilen süre gibi, ödeme koşullarını tanımlayan kod. | ||
| Açıklama Ödeme Koşulları, bir fatura ödemesinin ne zaman vadesi geleceğini belirleyen, müşteriyle üzerinde anlaşmaya varılmış önceden tanımlanmış koşullardır. Örnekler arasında 'Net 30' (ödeme 30 gün içinde vadesi gelir) veya '2/10 Net 30' (10 gün içinde ödenirse %2 indirim, aksi takdirde 30 gün içinde vadesi gelir) bulunur. Ödeme koşullarına göre analiz yapmak, bunların etkinliğini değerlendirmeye yardımcı olur. Farklı ödeme koşullarını ödemenin alınması için geçen fiili süre ile ilişkilendirerek, bir işletme hangi koşulların hızlı ödemeyi teşvik etmede en başarılı olduğunu belirleyebilir ve nakit akışını iyileştirmek için koşullarını optimize edebilir. Neden önemli Mutabakatlı ödeme takvimini tanımlar, bu da hangi koşulların müşterilerden zamanında ödeme sağlamada en etkili olduğunu analiz etmeye olanak tanır. Nereden alınır SAP Tablosu: VBRK, Alan: ZTERM Örnekler Z030Z060ZB60 | |||
| Para Birimi Currency | Fatura tutarı için para birimi kodu. | ||
| Açıklama Bu öznitelik, fatura tutarlarının hangi para biriminde (USD, EUR veya JPY gibi) ifade edildiğini belirtir. Tüm parasal değerler için gerekli bağlamı sağlar. Küresel bir kuruluşta, para birimi doğru finansal analiz ve raporlama için esastır. Tüm tutarları ortak bir raporlama para birimine dönüştürerek finansal verilerin doğru şekilde toplanmasına olanak tanır ve farklı yerel para birimlerine sahip bölgeler arasında faturalama performansının karşılaştırılmasını sağlar. Neden önemli Tüm parasal değerler için temel bağlam sağlar, özellikle çok uluslu operasyonlarda doğru finansal analiz ve raporlama sağlar. Nereden alınır SAP Tablosu: VBRK, Alan: WAERK Örnekler USDEURGBP | |||
| Satış Siparişi Numarası SalesOrderNumber | Faturaya yol açan orijinal satış siparişinin tanımlayıcısı. | ||
| Açıklama Satış Sipariş Numarası, faturalama belgesini önceki satış aktivitelerine bağlar. Tek bir satış siparişi bir veya daha fazla fatura ile sonuçlanabilir ve bu bağlantı eksiksiz belge akışını sağlar. Bu öznitelik, gerçek bir uçtan uca Siparişten Tahsilata analizi için kritiktir. Süreç görünümünün yukarı doğru genişletilmesine, faturalama sorunlarını satış siparişi oluşturma veya yerine getirme aşamalarındaki potansiyel temel nedenleriyle ilişkilendirmeye olanak tanır. Örneğin, siparişin yerine getirildiği andan itibaren genel Fatura Oluşturma Döngü Süresini hesaplamaya yardımcı olur. Neden önemli Faturayı orijinal satış siparişine bağlar, böylece sadece faturalamanın ötesinde Siparişten Nakde sürecine daha geniş, uçtan uca bir bakış açısı sağlar. Nereden alınır SAP Tablosu: VBRP (Faturalama Belgesi Kalem Verileri), Alan: AUBEL Örnekler 100001231000045610000789 | |||
| Şirket Kodu CompanyCode | Finansal işlemin kaydedildiği organizasyonel birim. | ||
| Açıklama Şirket Kodu, SAP Finansalları'nda finansal tabloların oluşturulduğu yasal olarak bağımsız bir şirketi temsil eden temel bir organizasyonel varlıktır. Her faturalama belgesi belirli bir şirket koduna atanır. Çok şirketli kuruluşlarda Şirket Koduna göre analiz yapmak, farklı tüzel kişilikler arasında süreç performansını, DSO gibi finansal metrikleri ve uyumluluğu karşılaştırmak için esastır. Tüm süreç dashboard'ları için üst düzey bir organizasyonel filtre sağlar. Neden önemli Süreç analizinin tüzel kişilik bazında segmentlere ayrılmasına olanak tanıyarak kuruluş genelinde performans karşılaştırması ve finansal konsolidasyon sağlar. Nereden alınır SAP Tablosu: VBRK, Alan: BUKRS Örnekler 10002000US01 | |||
| Son Veri Güncellemesi LastDataUpdate | Bu event için verinin en son ne zaman çıkarıldığını veya yenilendiğini gösteren timestamp. | ||
| Açıklama Bu öznitelik, kaynak sistemden son veri çekme tarihini ve saatini kaydeder. Analiz edilen verilerin güncelliğini anlamak için kritik olan bir metadata alanıdır. Bu bilgi, analizin güncelliğini doğrulamak ve veri yenileme programlarını yönetmek için kullanılır. Paydaşların process mining dashboard'ları ve içgörülerine dayanarak karar verirken verilerin güncelliğinden haberdar olmalarını sağlar. Neden önemli Verilerin güncelliğini gösterir, bu da analize güvenmek ve mevcut operasyon durumuna uygunluğunu anlamak için hayati önem taşır. Nereden alınır Bu timestamp, veri çıkarma ve yükleme (ETL) süreci sırasında her kayda oluşturulur ve damgalanır. Örnekler 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Uyuşmazlık Nedeni CustomerDisputeReason | Bir müşterinin bir faturaya itiraz etmesi için verdiği neden. | ||
| Açıklama Bir müşteri bir faturaya itiraz ettiğinde, anlaşmazlığın nedeni genellikle kaydedilir. Bu, fiyatlandırma hatalarından, yanlış miktarlardan veya hasarlı mallardan kaynaklanabilir. Bu bilgi, SAP Anlaşmazlık Yönetimi modülünde veya metin notları olarak saklanabilir. Anlaşmazlık nedenlerini analiz etmek, Faturalama Hata Oranı KPI'sı ve ilgili hata analizi için temeldir. Faturalama hatalarının temel nedenlerini belirlemeye yardımcı olur, işletmenin yukarı akış süreçlerindeki sistemik sorunları ele almasına, fatura kalitesini iyileştirmesine ve müşteri memnuniyetini artırmasına olanak tanır. Neden önemli Faturaların neden itiraz edildiğini açıklayarak, faturalama hatalarının ve müşteri memnuniyetsizliğinin temel nedenlerine doğrudan içgörü sağlar. Nereden alınır SAP Anlaşmazlık Yönetimi kullanılıyorsa, bu bilgi UDM_DISPUTE gibi tablolarda bulunabilir. Aksi takdirde, ilgili belgelerdeki neden kodlarından veya metin alanlarından türetilebilir. Örnekler Yanlış FiyatMiktar UyuşmazlığıHasarlı Mal Teslim Alındı | |||
| Zamanında Ödendi mi IsPaidOnTime | Faturanın vadesinde veya vadesinden önce ödenip ödenmediğini gösteren bir boolean bayrak. | ||
| Açıklama Bu, fiili ödeme tarihini planlanan ödeme vade tarihiyle karşılaştıran hesaplanmış bir özniteliktir. Ödeme zamanında yapıldıysa 'doğru', geç yapıldıysa 'yanlış' olarak sonuçlanır. Bu işaret, Zamanında Ödeme Oranı KPI'sının hesaplanmasını ve görselleştirilmesini basitleştirir. Geç ödenen faturaların özellikleri ile zamanında ödenen faturaların özelliklerini analiz etmek için kolay filtreleme ve segmentasyona olanak tanır. Bu, geç ödemelere yol açan belirli müşteriler, bölgeler veya ödeme koşullarıyla ilgili kalıpları ortaya çıkarmaya yardımcı olabilir. Neden önemli Her faturayı 'zamanında' veya 'gecikmiş' olarak açıkça işaretleyerek performans ölçümünü basitleştirir, Zamanında Ödeme Oranı KPI'sını doğrudan destekler. Nereden alınır Bu hesaplanmış bir alandır. Mantık, 'Müşteri Ödemesi Alındı' aktivitesinin timestamp'ini 'PaymentDueDate' özniteliğindeki değere karşılaştırır. Örnekler truefalse | |||
Siparişten Nakde (Order to Cash) - Faturalama ve Muhasebeleştirme Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura Kapatıldı | Bu aktivite, başarıyla ödenmiş bir faturanın nihai durumunu gösterir. Fonksiyonel olarak 'Nakit Uygulandı/Mutabakatı Yapıldı' ile aynıdır ve bu fatura için sürecin tamamlandığını belirtir. | ||
| Neden önemli Süreç için birincil 'mutlu yol' bitiş event'i olarak hizmet eder. Bu noktaya kadar olan toplam döngü süresini ölçmek, uçtan uca faturalama ve tahsilat yaşam döngüsüne eksiksiz bir görünüm sağlar. Nereden alınır Muhasebe belgesindeki müşteri kaleminin durumundan çıkarılır. Mahsuplaşma tarihi (BSEG-AUGDT) ve mahsuplaşma belgesi (BSEG-AUGBL) alanları doldurulduğunda bir kalem kapatılır veya 'mahsuplaşılır'. Yakala Fatura kalemi için BSEG/ACDOCA tablosundaki mahsuplaşma tarihi (AUGDT) doldurularak çıkarılır. Event tipi inferred | |||
| Fatura Muhasebeleştirildi | Faturalama belgesinin finansal muhasebe modülüne başarılı bir şekilde muhasebeleştirilmesini temsil eder. Bu, faturanın resmi bir alacak kalemi haline geldiği ve genel deftere kayıtlar oluşturduğu kritik bir dönüm noktasıdır. | ||
| Neden önemli Bu aktivite, faturanın yasal bir finansal belge olduğunu doğrular. Oluşturma ve muhasebeleştirme arasındaki süre, iç işlem verimliliğini vurgulayan önemli bir performans göstergesidir. Nereden alınır Bu event, ilgili muhasebe belgesi oluşturulduğunda yakalanır. Faturalama belgesi (VBRK-VBELN), VBRK-BELNR aracılığıyla muhasebe belgesine (BKPF-BELNR) bağlanır ve muhasebeleştirme tarihi BKPF-BUDAT'tır. Yakala Faturalama belgesine bağlı BKPF tablosundaki muhasebe belgesinin kayıt tarihinden (BUDAT) alınır. Event tipi explicit | |||
| Fatura Oluşturuldu | Bu aktivite, sistemde faturalama belgesinin oluşturulmasını işaret eder. Bu, bir kullanıcının VF01 gibi bir işlem gerçekleştirmesi veya bir arka plan görevinin faturayı oluşturması durumunda yakalanan açık bir event'tir, bu da faturalama belgesi başlık tablosunda yeni bir girişle sonuçlanır. | ||
| Neden önemli Bu, faturalama süreci için birincil başlangıç event'idir. Siparişin yerine getirilmesinden bu aktiviteye kadar geçen süreyi analiz etmek, Fatura Oluşturma Döngü Süresini ölçmek ve ilk süreç gecikmelerini belirlemek için çok önemlidir. Nereden alınır Oluşturulduğunda SAP S/4HANA VBRK tablosuna (Faturalama Belgesi: Başlık Verileri) kaydedilir. Oluşturma tarihi (VBRK-ERDAT) ve saati (VBRK-ERZET) timestamp olarak hizmet eder. Yakala Olay, VBRK tablosundaki faturalama belgesi kaydının oluşturulma zaman damgasından alınır. Event tipi explicit | |||
| Müşteri Ödemesi Alındı | Bu aktivite, bir müşteriden gelen ödemenin finansal sisteme muhasebeleştirilmesini işaret eder. Bu aşamada ödeme belirli bir faturaya henüz uygulanmamış olabilir, ancak fonlar kaydedilmiştir. | ||
| Neden önemli Tahsil Edilmeyi Bekleyen Gün Sayısı (DSO) hesaplaması için kritik bir kilometre taşıdır. Mutabakat hala bekliyor olsa bile nakitin alındığını gösterir. Nereden alınır Müşteri ödeme belgesinin (genellikle BKPF tablosunda 'DZ' belge tipi) kayıt tarihinden (BKPF-BUDAT) alınır. Yakala Olay, BKPF/BSEG'de ödeme belgesinin oluşturulmasına dayanmaktadır. Event tipi explicit | |||
| Nakit Uygulandı/Mutabakatı Yapıldı | Gelen müşteri ödemesinin eşleştirildiği ve açık fatura kaleminin alacak alt defterinden temizlemek için kullanıldığı anı temsil eder. Bu aktivite, işlemi finansal açıdan tamamlar. | ||
| Neden önemli Nakit uygulama sürecinin verimliliğini ölçer. Buradaki gecikmeler, müşteri hesaplarının gerçek durumunu yanlış gösterebilir ve tahsilat ekipleri için gereksiz iş yükü yaratabilir. Nereden alınır Bu event, orijinal faturanın muhasebe belgesi kalemindeki clear etme tarihi (BSEG-AUGDT) ile yakalanır. Bu tarih, bir clear etme belgesi kalemi clear ettiğinde doldurulur. Yakala Fatura kalemleri için BSEG/ACDOCA tablosundaki mahsuplaşma tarihi (AUGDT) alanından alınır. Event tipi explicit | |||
| Alacak Dekontu Oluşturuldu | Bu aktivite, bir alacak dekontunun oluşturulmasını temsil eder; bu dekont, fazla ücreti düzeltmek veya iade edilen mallar için kredi sağlamak amacıyla müşteriye düzenlenir. Genellikle orijinal bir faturaya bağlıdır. | ||
| Neden önemli Faturalama sonrası finansal düzeltmelerle sonuçlanan sorunları vurgular. Kredi notlarını analiz etmek, fiyatlandırma hatalarını, ürün sorunlarını veya gelir kaybının diğer temel nedenlerini ortaya çıkarabilir. Nereden alınır Kredi notları için belirli bir faturalama tipiyle (örn. 'G2') yeni bir faturalama belgesi (VBRK'da) olarak açıkça oluşturulur. Genellikle orijinal satış siparişini veya faturayı referans alır. Yakala VBRK'da bir kredi notu faturalama tipi ile bir faturalama belgesinin oluşturulmasından alınır. Event tipi explicit | |||
| Fatura İptal Edildi | Daha önce oluşturulmuş bir faturanın iptal edilmesiyle gerçekleşir, bu genellikle ilgili bir iptal belgesinin oluşturulmasını içerir. Bu, orijinal faturayı ve muhasebe etkisini etkili bir şekilde tersine çevirir. | ||
| Neden önemli Yeniden işleme, düzeltmeler veya faturalama hatalarını gösterir. Yüksek iptal sıklığı, satış siparişi girişi veya faturalama yapılandırmasındaki önemli üst akış sorunlarına işaret eder. Nereden alınır Bir iptal faturalama belgesi oluşturulduğunda (örn. 'S1' belge tipi) alınır. VBRK'daki bu yeni belge, VBRK-SFAKN alanında orijinal fatura numarasını referans alacaktır. Yakala Olay, VBRK'da orijinal faturayı referans alan iptal belgesinin oluşturulma tarihinden alınır. Event tipi explicit | |||
| Fatura Kaydı Engellendi | Bu event, bir fatura oluşturulur ancak kredi kontrolleri veya veri tutarsızlıkları gibi çeşitli nedenlerle finansal muhasebeye muhasebeleştirilmesi otomatik olarak engellenirse gerçekleşir. Bu durum, faturalama belgesindeki muhasebeleştirme durumu alanından çıkarılır. | ||
| Neden önemli Faturaların oluşturulduğu ancak hemen finansa serbest bırakılmadığı darboğazları belirler, bu da tüm nakit tahsilat döngüsünü geciktirir. Veri kalitesi sorunlarının veya kredi yönetimi problemlerinin önemli bir göstergesidir. Nereden alınır Faturalama belgesi başlık tablosundaki (VBRK-RFBSK) kayıt durumu alanından çıkarılır. 'A' gibi bir durum (Faturalama belgesi FI'ye iletilmek üzere engellendi) bir engeli işaret eder. Yakala Fatura oluşturulduktan hemen sonra kayıt durumu alanının (VBRK-RFBSK) değeri kontrol edilerek çıkarılır. Event tipi inferred | |||
| Faturalama Yeniden İşleme Tanımlandı | Bir faturanın iptal edildiği ve ardından aynı satış siparişi için yeni bir fatura oluşturulduğu bir yeniden işleme döngüsünü tanımlayan hesaplanmış bir olay. Tek bir işlem değil, bir olay desenidir. | ||
| Neden önemli Düzeltme örneklerini nicelikselleştirerek Faturalama Yeniden İşleme Oranı KPI'sını doğrudan destekler. Bu, verimsizlikleri belirlemeye ve faturalama sürecindeki düşük kalitenin maliyetini ölçmeye yardımcı olur. Nereden alınır Bu kalıp, 'Fatura İptal Edildi' event'inin ardından aynı kaynak belgeye (bir satış sipariş numarası gibi) dayanan yeni bir 'Fatura Oluşturuldu' event'inin tanımlanmasıyla hesaplanır. Yakala Aynı satış siparişi referansı için 'Fatura İptal Edildi' ve 'Fatura Oluşturuldu' dizisi tespit edilerek türetilir. Event tipi calculated | |||
| Müşteri Anlaşmazlığı Açıldı | Bu aktivite, bir müşteri bir faturaya karşı itirazda bulunduğunda gerçekleşir, bu da daha sonra sistemde resmi olarak kaydedilir. Bu, SAP Anlaşmazlık Yönetimi modülünün kullanılmasını gerektirir. | ||
| Neden önemli Faturalama doğruluğu, ürün kalitesi veya hizmet teslimatıyla ilgili, ödeme gecikmelerine yol açan sorunları vurgular. İtiraz nedenlerini analiz etmek, temel nedenleri ele almaya ve müşteri memnuniyetini artırmaya yardımcı olabilir. Nereden alınır Muhasebe belgesi kalemine bağlı Anlaşmazlık Yönetimi tablolarında (örn. UDM_CASE) bir anlaşmazlık vakasının oluşturulması üzerine kaydedilir. Yakala Faturaya bağlı itiraz vakası kaydının oluşturulma zaman damgasından alınır. Event tipi explicit | |||
| Müşteriye Fatura Gönderildi | Bu aktivite, faturanın müşteriye ne zaman iletildiğini (örneğin baskı, e-posta veya EDI yoluyla) işaret eder. Yakalanma mekanizması, SAP'deki çıktı yönetimi konfigürasyonuna bağlıdır. | ||
| Neden önemli Müşterinin bakış açısından ödeme süresinin resmi başlangıcı. Faturanın gönderilmesindeki gecikmeler, Günlük Satış Bekletme Süresini (DSO) ve nakit akışını doğrudan etkiler. Nereden alınır Çıktı kontrol tablolarına (eski yöntemler için NAST veya S/4HANA eşdeğeri gibi) açıkça kaydedilebilir. Açıkça kaydedilmemişse, genellikle 'Fatura Muhasebeleştirildi' ile aynı anda gerçekleştiği varsayılır. Yakala Fatura çıktı tipiyle ilişkili bir zaman damgası için çıktı yönetimi tablolarındaki işlem günlüklerini kontrol edin. Event tipi explicit | |||
| Ödeme Hatırlatıcısı Gönderildi | Vadesi geçmiş bir fatura için müşteriye bir ödeme hatırlatıcısı veya borç hatırlatma bildirimi gönderilmesini temsil eder. Bu, otomatik borç hatırlatma prosedürü tarafından oluşturulan açık bir event'tir. | ||
| Neden önemli Tahsilat sürecinin etkinliğini analiz etmeye olanak tanır. Hatırlatıcıların ödemeleri hızlandırıp hızlandırmadığını ve hangi tahsilat seviyelerinin en etkili olduğunu belirlemeye yardımcı olur. Nereden alınır Faturanın açık kalemi için borç hatırlatma işlemi (İşlem F150) çalıştırıldığında, borç hatırlatma geçmişi tablolarında (MAHNV, MHND) kaydedilir. Yakala Tahsilat geçmişi tablolarında kaydedilen tahsilat bildiriminin çalışma tarihinden alınır. Event tipi explicit | |||
| Ödeme Vadesi Geldi | Fatura için ödemenin, üzerinde anlaşılan ödeme koşullarına göre resmi olarak vadesi dolduğu tarihi temsil eden hesaplanmış bir olay. Bu bir işlem olayı değil, fatura verilerinden türetilmiştir. | ||
| Neden önemli Bu, zamanında ödeme performansını ölçmek ve müşteri ödeme davranışını analiz etmek için kritik bir temel sağlar. Zamanında yapılan ve vadesi geçmiş ödemeleri ayırt etmeye yardımcı olur. Nereden alınır Ödeme için temel tarihe (BSEG-ZFBDT) ve muhasebe belgesinin müşteri kaleminde saklanan ödeme koşullarına göre hesaplanır. Yakala Muhasebe belgesi kaleminde (BSEG) bulunan temel ödeme tarihine ödeme vadesi günlerinin eklenmesiyle türetilir. Event tipi calculated | |||
Veri Çekim Kılavuzları
Adımlar
- Ön Koşullar: SAP S/4HANA'da Çekirdek Veri Hizmetleri (CDS) görünümlerini sorgulamak için gerekli yetkilere sahip bir kullanıcı hesabınız olduğundan emin olun. Özellikle, I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase ve I_DunningHistory gibi görünümler için okuma erişimine ihtiyacınız vardır.
- Veri Çıkarma Aracına Erişim: SAP S/4HANA sisteminize giriş yapın. SQL sorgularını CDS görünümlerine karşı yürütmek için SAP HANA Studio, SAP HANA istemcisi aracılığıyla bağlanan DBeaver veya SAP Analysis for Microsoft Excel eklentisi gibi çeşitli araçları kullanabilirsiniz. Bu kılavuz için standart bir SQL istemcisi varsayacağız.
- Sistem Parametrelerini Belirleme: Sorguyu çalıştırmadan önce, analiziniz için belirli Şirket Kodlarını ve ilgili tarih aralığını belirleyin. Yönetilebilir sorgu yürütme süreleri sağlamak için başlangıçta sınırlı bir kapsamla, örneğin son 3 ila 6 aylık verilerle başlamanız önerilir.
- SQL Sorgusunu Hazırlama: Bu belgenin 'sorgu' bölümünde verilen SQL sorgusunun tamamını seçtiğiniz SQL istemcisine kopyalayın.
- Yer Tutucuları Özelleştirme: Sorgudaki yer tutucu değerlerini değiştirin. 'YYYY-MM-DD' ifadesini istediğiniz başlangıç ve bitiş tarihleriyle değiştirin. 'XXXX' ifadesini hedef Şirket Kodu(ları) ile değiştirin. Ayrıca, sistem yapılandırmanıza bağlı olarak kredi notu belge türleri için yer tutucuyu, örneğin 'G2', ayarlamanız gerekebilir.
- Sorguyu Yürütme: Değiştirilen SQL sorgusunu SAP S/4HANA veritabanına karşı çalıştırın. Yürütme süresi, seçtiğiniz tarih aralığındaki veri hacmine bağlı olarak değişecektir.
- Sonuçları Gözden Geçirme: Sorgu tamamlandıktan sonra çıktıyı gözden geçirin. Sonuç kümesi, her satırın faturalama sürecindeki tek bir faaliyeti temsil ettiği düz bir tablo olmalıdır. Bu sizin olay günlüğünüzdür.
- Veri Dönüşümü (gerekliyse): Sorgu, temiz bir olay günlüğü biçimi üretmek üzere tasarlanmıştır. Ancak, zaman damgası biçiminin süreç madenciliği aracınızla uyumlu olduğundan emin olmak için kontrol edin. Sorgu, geniş ölçüde uyumlu olması gereken standart bir UTC zaman damgasına dönüştürmek için
ABAP_SYSTEM_UTCL_TO_TIMESTAMPkullanır. - Olay Günlüğünü Dışa Aktarma: SQL istemcinizden tam sonuç kümesini bir CSV dosyasına dışa aktarın. Karakter sorunlarını önlemek için dosyanın UTF-8 kodlamasıyla kaydedildiğinden emin olun.
- ProcessMind'e Yükleme: Oluşturulan CSV dosyasını ProcessMind platformuna yükleyin, dosyadaki InvoiceNumber, ActivityName ve EventTime gibi sütunları araçtaki ilgili alanlarla eşleştirin.
Konfigürasyon
- Tarih Aralığı: İlk Ortak Tablo İfadesinin (CTE)
WHEREcümlesinde başlangıç ve bitiş tarihlerini ayarlayın. Veri hacmi ve performansı dengelemek için ilk analiz için 3 ila 6 aylık bir aralık önerilir. FiltrelemeBillingDocumentDateüzerinedir. - Şirket Kodu: Çıkarma işlemini ilgili tüzel kişiliklerle sınırlamak için bir veya daha fazla
CompanyCodedeğerine göre filtreleyin. Bu, veri kapsamını yönetmek için kritik bir filtredir. - Belge Türleri: Sorgu,
BillingDocumentTypetemel alınarak kredi notlarını tanımlamak için mantık içerir. Örneğin,('G2', 'CR')gibi yer tutucuyu kuruluşunuzda kredi notları için kullanılan belirli belge türleriyle yapılandırmanız gerekir. - Ön Koşullar: Temel CDS görünümlerine erişim zorunludur. Bu, SAP güvenlik ekibiniz tarafından atanan belirli roller ve yetkilendirmeler gerektirir. Ayrıca, 'Müşteri Anlaşmazlığı Açıldı' veya 'Ödeme Hatırlatıcısı Gönderildi' gibi faaliyetler için ilgili SAP modülleri olan SAP Anlaşmazlık Yönetimi ve SAP Finansal Tahsilat modülleri sisteminizde aktif olarak kullanılmalıdır.
- Performans: Sorgu birden fazla birleştirme ve birleştirme (join ve union) kullanır. Örneğin, birkaç yıllık veri gibi çok büyük veri kümeleri için, sorguyu yoğun olmayan saatlerde çalıştırmayı veya ilk veri çekimini sınırlamak için daha kısıtlayıcı filtreler uygulamayı düşünün.
a Örnek Sorgu sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Adımlar
- Ön Koşullar: SAP S/4HANA'da Çekirdek Veri Hizmetleri (CDS) görünümlerini sorgulamak için gerekli yetkilere sahip bir kullanıcı hesabınız olduğundan emin olun. Özellikle, I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase ve I_DunningHistory gibi görünümler için okuma erişimine ihtiyacınız vardır.
- Veri Çıkarma Aracına Erişim: SAP S/4HANA sisteminize giriş yapın. SQL sorgularını CDS görünümlerine karşı yürütmek için SAP HANA Studio, SAP HANA istemcisi aracılığıyla bağlanan DBeaver veya SAP Analysis for Microsoft Excel eklentisi gibi çeşitli araçları kullanabilirsiniz. Bu kılavuz için standart bir SQL istemcisi varsayacağız.
- Sistem Parametrelerini Belirleme: Sorguyu çalıştırmadan önce, analiziniz için belirli Şirket Kodlarını ve ilgili tarih aralığını belirleyin. Yönetilebilir sorgu yürütme süreleri sağlamak için başlangıçta sınırlı bir kapsamla, örneğin son 3 ila 6 aylık verilerle başlamanız önerilir.
- SQL Sorgusunu Hazırlama: Bu belgenin 'sorgu' bölümünde verilen SQL sorgusunun tamamını seçtiğiniz SQL istemcisine kopyalayın.
- Yer Tutucuları Özelleştirme: Sorgudaki yer tutucu değerlerini değiştirin. 'YYYY-MM-DD' ifadesini istediğiniz başlangıç ve bitiş tarihleriyle değiştirin. 'XXXX' ifadesini hedef Şirket Kodu(ları) ile değiştirin. Ayrıca, sistem yapılandırmanıza bağlı olarak kredi notu belge türleri için yer tutucuyu, örneğin 'G2', ayarlamanız gerekebilir.
- Sorguyu Yürütme: Değiştirilen SQL sorgusunu SAP S/4HANA veritabanına karşı çalıştırın. Yürütme süresi, seçtiğiniz tarih aralığındaki veri hacmine bağlı olarak değişecektir.
- Sonuçları Gözden Geçirme: Sorgu tamamlandıktan sonra çıktıyı gözden geçirin. Sonuç kümesi, her satırın faturalama sürecindeki tek bir faaliyeti temsil ettiği düz bir tablo olmalıdır. Bu sizin olay günlüğünüzdür.
- Veri Dönüşümü (gerekliyse): Sorgu, temiz bir olay günlüğü biçimi üretmek üzere tasarlanmıştır. Ancak, zaman damgası biçiminin süreç madenciliği aracınızla uyumlu olduğundan emin olmak için kontrol edin. Sorgu, geniş ölçüde uyumlu olması gereken standart bir UTC zaman damgasına dönüştürmek için
ABAP_SYSTEM_UTCL_TO_TIMESTAMPkullanır. - Olay Günlüğünü Dışa Aktarma: SQL istemcinizden tam sonuç kümesini bir CSV dosyasına dışa aktarın. Karakter sorunlarını önlemek için dosyanın UTF-8 kodlamasıyla kaydedildiğinden emin olun.
- ProcessMind'e Yükleme: Oluşturulan CSV dosyasını ProcessMind platformuna yükleyin, dosyadaki InvoiceNumber, ActivityName ve EventTime gibi sütunları araçtaki ilgili alanlarla eşleştirin.
Konfigürasyon
- Tarih Aralığı: İlk Ortak Tablo İfadesinin (CTE)
WHEREcümlesinde başlangıç ve bitiş tarihlerini ayarlayın. Veri hacmi ve performansı dengelemek için ilk analiz için 3 ila 6 aylık bir aralık önerilir. FiltrelemeBillingDocumentDateüzerinedir. - Şirket Kodu: Çıkarma işlemini ilgili tüzel kişiliklerle sınırlamak için bir veya daha fazla
CompanyCodedeğerine göre filtreleyin. Bu, veri kapsamını yönetmek için kritik bir filtredir. - Belge Türleri: Sorgu,
BillingDocumentTypetemel alınarak kredi notlarını tanımlamak için mantık içerir. Örneğin,('G2', 'CR')gibi yer tutucuyu kuruluşunuzda kredi notları için kullanılan belirli belge türleriyle yapılandırmanız gerekir. - Ön Koşullar: Temel CDS görünümlerine erişim zorunludur. Bu, SAP güvenlik ekibiniz tarafından atanan belirli roller ve yetkilendirmeler gerektirir. Ayrıca, 'Müşteri Anlaşmazlığı Açıldı' veya 'Ödeme Hatırlatıcısı Gönderildi' gibi faaliyetler için ilgili SAP modülleri olan SAP Anlaşmazlık Yönetimi ve SAP Finansal Tahsilat modülleri sisteminizde aktif olarak kullanılmalıdır.
- Performans: Sorgu birden fazla birleştirme ve birleştirme (join ve union) kullanır. Örneğin, birkaç yıllık veri gibi çok büyük veri kümeleri için, sorguyu yoğun olmayan saatlerde çalıştırmayı veya ilk veri çekimini sınırlamak için daha kısıtlayıcı filtreler uygulamayı düşünün.
a Örnek Sorgu sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;