Siparişten Tahsilata - Faturalandırma ve Fatura Veri Template'inuz
Siparişten Tahsilata - Faturalandırma ve Fatura Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- `SAP S/4HANA` için Veri Çıkarma Kılavuzu
Siparişten Nakde - Faturalama ve Muhasebe Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Fatura Numarası InvoiceNumber | Bir faturalama belgesi için benzersiz tanımlayıcı, faturalama süreci için birincil vaka tanımlayıcısı olarak olarak kullanılır. | ||
| 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, vaka korelasyonu için gereklidir. 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 süreç döngüsünün eksiksiz, uçtan uca analizini sunar. Bu, döngü sürelerini takip etmeyi, sapmaları belirlemeyi ve her faturanın yolculuğunu analiz etmeyi sunar. Neden Önemli?dir? Tüm ilgili faturalama faaliyetlerini tek bir vakada birleştiren temel tanımlayıcıdır; bu sayede uçtan uca süreç analizi yapılabilir. Nereden Alınır?? SAP Tablosu: VBRK, Alan: VBELN Örnekler::::::: 900012349000567890009012 | |||
| Aktivite Adı ActivityName | Faturalama süreci içinde gerçekleşen iş aktivitesinin veya olayınin adı, örneğin 'Fatura Oluşturuldu' veya 'Ödeme Alındı'. | ||
| Açıklama Aktivite Adı, faturalama süreç 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?dir? 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 sunar. 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 olayın ne zaman gerçekleştiğini gösteren kesin zaman damgası (zaman damgası)dır. | ||
| Açıklama Olay Zamanı, her faaliyet için tarih ve saati sunar, sürecin kronolojik temelini oluşturur. Bu zaman damgası (zaman damgası), faturalama sürecindeki farklı adımlar arasındaki süreleri, döngü sürelerini ve bekleme sürelerini hesaplamak için büyük önem taşır. 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ü sunar, 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?dir? Olayların kronolojik sırasını sunar, bu da döngü süreleri ve süreler gibi tüm zaman bazlı metrikleri hesaplamak için gereklidir. 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ş Zamanı EndTime | Bir aktivite veya olayın ne zaman tamamlandığını gösteren kesin zaman damgası (zaman damgası)dır. | ||
| 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ş olaylarıni kaydederse doğrudan kaynaklanabilir. Bu öznitelik, bireysel aktivitelerin İşlem Süresini hesaplamak için gereklidir. 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 büyük önem taşır. Neden Önemli?dir? 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 olayın 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ı kontrol paneli'u için temel rol oynar. Farklı bölgelerdeki döngü süreleri, hata oranları ve DSO gibi temel metriklerin kıyaslanmasına sunar. Bu karşılaştırma, süreç yürütme, uyumluluk veya verimlilikteki bölgesel farklılıkları vurgulayabilir. Bu veriler; hedeflenmiş iyileştirmelerin ve en iyi uygulamaların standardizasyonunun önünü açar. Neden Önemli?dir? 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 olarak kullanılır. Ö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 büyük önem taşır. Neden Önemli?dir? 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 sunar; ö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 hesaplanmasında temel rol oynar. Neden Önemli?dir? Her faturanın finansal değerini nicelikselleştirir, değere dayalı analizi, tahsilatların önceliklendirilmesini ve finansal etki değerlendirmesini sunar. 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ı sunar. 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 büyük önem taşır, 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?dir? Süreç faaliyetlerini belirli kullanıcılara bağlar, bireysel veya ekip düzeyinde iş yükü, performans ve uyumluluk analizini sunar. 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 kesildiğ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 sunar. Ö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 sunar. Neden Önemli?dir? Müşteri odaklı analizi sunar, 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 gereklidir. 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?dir? Müşteri ödemesi için son tarihi belirler, bu da zamanında ödeme oranlarını hesaplamak ve alacakları yönetmek için büyük önem taşır. 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 | |||
| Fatura Belge 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 sunar. Ö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?dir? İşlemleri sınıflandırır, standart faturalar, kredi notları veya iptaller gibi belirli belge akışları üzerinde odaklanmış analiz yapılmasını sunar. Nereden Alınır?? SAP Tablosu: VBRK, Alan: FKART Örnekler::::::: F2G2S1L2 | |||
| 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 veri izlenebilirliğini sunar ve özellikle birden çok kaynaktan gelen veriler uçtan uca bir süreç görünümü için birleştirildiğinde bağlam sunar. Neden Önemli?dir? Verinin kökeni hakkında önemli bilgiler sunar, ç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 sunar. 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 destekler. Neden Önemli?dir? 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 güçlüaya 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 süreç 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 kontrol paneli'u için büyük önem taşır. 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?dir? 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 önemlidir. 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 Koşulları 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?dir? Mutabakatlı ödeme takvimini tanımlar, bu da hangi koşulların müşterilerden zamanında ödeme güçlüada en etkili olduğunu analiz etmeye sunar. 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ı sunar. Küresel bir kuruluşta, para birimi doğru finansal analiz ve raporlama için gereklidir. Tüm tutarları ortak bir raporlama para birimine dönüştürerek finansal verilerin doğru şekilde toplanmasına sunar ve farklı yerel para birimlerine sahip bölgeler arasında faturalama performansının karşılaştırılmasını sunar. Neden Önemli?dir? Tüm parasal değerler için temel bağlam sunar, özellikle çok uluslu operasyonlarda doğru finansal analiz ve raporlama sunar. 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ı sunar. Bu öznitelik, gerçek bir uçtan uca Siparişten Tahsilata analizi için büyük önem taşır. 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 sunar. Örneğin, siparişin yerine getirildiği andan itibaren genel Fatura Oluşturma Döngü Süresini hesaplamaya yardımcı olur. Neden Önemli?dir? 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ı sunar. 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 gereklidir. Tüm süreç panelleri için üst düzey bir organizasyonel filtre sunar. Neden Önemli?dir? 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 sunar. 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 zaman damgası (zaman damgası)dır. | ||
| 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 panelleri ve stratejik bilgilerine dayanarak karar verirken verilerin güncelliğinden haberdar olmalarını sunar. Neden Önemli?dir? Verilerin güncelliğini gösterir, bu da analize güvenmek ve mevcut operasyon durumuna uygunluğunu anlamak için önemlidir. Nereden Alınır?? Bu zaman damgası (zaman damgası), 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 büyük önem taşır. 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 sunar. Neden Önemli?dir? Faturaların neden itiraz edildiğini açıklayarak, faturalama hatalarının ve müşteri memnuniyetsizliğinin temel nedenlerine doğrudan önemli bilgi sunar. 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 sunar. 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?dir? 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 zaman damgası (zaman damgası)'ini 'PaymentDueDate' özniteliğindeki değere karşılaştırır. Örnekler::::::: truefalse | |||
Siparişten Nakde - Faturalama ve Muhasebe 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?dir? Süreç için birincil 'ideal süreç akışı' bitiş event'i olarak olarak kullanılır. Bu noktaya kadar olan toplam döngü süresini ölçmek, uçtan uca faturalama ve tahsilat süreç döngüsüne eksiksiz bir görünüm sunar. 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?dir? 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?dir? 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 büyük önem taşır. 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) zaman damgası (zaman damgası) olarak olarak kullanılır. Yakala Olay, VBRK tablosundaki faturalama belgesi kaydının oluşturulma zaman damgası (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?dir? 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?dir? 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 güçlüak amacıyla müşteriye düzenlenir. Genellikle orijinal bir faturaya bağlıdır. | ||
| Neden Önemli?dir? 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?dir? 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?dir? 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?dir? 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' olayınin ardından aynı kaynak belgeye (bir satış sipariş numarası gibi) dayanan yeni bir 'Fatura Oluşturuldu' olayınin 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?dir? 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ı (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?dir? 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ı (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?dir? Tahsilat sürecinin etkinliğini analiz etmeye sunar. 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?dir? Bu, zamanında ödeme performansını ölçmek ve müşteri ödeme davranışını analiz etmek için kritik bir temel sunar. 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 Çıkarma Kılavuzları
Adımlar
- Ön Koşullar: SAP S/4HANA'da Çekirdek Veri Enerji ve Altyapıi (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 güçlüak 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 event lognüzdür.
- Veri Dönüşümü (gerekliyse): Sorgu, temiz bir event log biçimi üretmek üzere tasarlanmıştır. Ancak, zaman damgası (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ı (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 Enerji ve Altyapıi (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 güçlüak 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 event lognüzdür.
- Veri Dönüşümü (gerekliyse): Sorgu, temiz bir event log biçimi üretmek üzere tasarlanmıştır. Ancak, zaman damgası (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ı (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;