Siparişten Tahsilata - faturalama ve fatura kesme Veri Templateiniz
Siparişten Tahsilata - faturalama ve fatura kesme Veri Templateiniz
- Toplanması önerilen öznitelikler
- Takip edilecek temel etkinlikler
- SAP S/4HANA için veri çıkarma yönergeleri
Siparişten Tahsilata - faturalama ve fatura kesme öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Fatura numarası InvoiceNumber | Fatura belgesinin benzersiz tanımlayıcısıdır ve faturalandırma sürecindeki temel vaka kimliği olarak kullanılır. | ||
| Açıklama SAP’de Fatura Belgesi Numarası olarak bilinen fatura numarası, her faturalandırma işlemini benzersiz biçimde tanımlar. Faturanın oluşturulması ve kaydedilmesinden ödemenin alınması ve mutabakata kadar ilgili tüm etkinlikleri birbirine bağlayan temel anahtardır. Process Mining analizinde bu öznitelik, vakaları ilişkilendirmek için gereklidir. Aynı fatura numarasını taşıyan tüm olaylar tek bir süreç örneğinde gruplanır. Böylece her faturanın yaşam döngüsünü uçtan uca analiz edebilir, çevrim sürelerini izleyebilir, sapmaları belirleyebilir ve her faturanın süreçteki ilerleyişini inceleyebilirsiniz. Neden önemli? İlgili tüm faturalandırma etkinliklerini tek bir vakada birleştiren temel tanımlayıcıdır ve uçtan uca süreç analizini mümkün kılar. Nereden alınır? SAP tablosu: VBRK, alan: VBELN Örnekler 900012349000567890009012 | |||
| Etkinlik adı ActivityName | Faturalandırma sürecinde gerçekleşen iş etkinliğinin veya olayın adı; örneğin 'Fatura oluşturuldu' ya da 'Ödeme alındı'. | ||
| Açıklama Etkinlik adı, faturalandırma yaşam döngüsündeki belirli bir adımı veya aşamayı tanımlar. Bu etkinlikler, sıralı bir süreç akışı oluşturmak için SAP’deki işlem kodları, belge durumu değişiklikleri veya belirli günlük kayıtları gibi çeşitli veri noktalarından türetilir. Bu etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining çalışmalarının temelini oluşturur. Süreç haritasını görselleştirmenize, yaygın ve nadir süreç varyantlarını keşfetmenize, adımlar arasındaki darboğazları belirlemenize ve yeniden çalışma ya da iptal gibi değer katmayan etkinliklerin sıklığını ölçmenize yardımcı olur. Neden önemli? Bu öznitelik süreç adımlarını tanımlar; süreç haritalarını görselleştirmenizi, süreç akışını ve farklılıklarını incelemenizi, darboğazları belirlemenizi sağlar. Nereden alınır? İşlem kodları (SY-TCODE), değişiklik belgesi durumları (CDHDR/CDPOS tabloları) veya iş akışı günlükleri (ör. SWW_WI2OBJ) gibi çeşitli kaynaklardan türetilir. Örnekler Fatura oluşturulduFatura muhasebeye kaydedildiMüşteri ödemesi alındıFatura iptal edildi | |||
| Olay zamanı EventTime | Bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren kesin zaman damgası. | ||
| Açıklama Olay zamanı, her etkinliğin tarih ve saatini sağlayarak sürecin kronolojik temelini oluşturur. Bu zaman damgası, faturalandırma sürecindeki farklı adımların sürelerini, çevrim sürelerini ve bekleme sürelerini hesaplamak için gereklidir. Analizde etkinlikleri sıraya koymak, satışların tahsilat süresi ve fatura oluşturma çevrim süresi gibi temel performans göstergelerini hesaplamak ve zamana bağlı darboğazları belirlemek için kullanılır. Sürecin zaman içindeki performans değişimini ve faturalandırma döngüsünün her aşamasının ne kadar sürdüğünü gösterir. Neden önemli? Çevrim süreleri ve süreler gibi zamana dayalı tüm metrikleri hesaplamak için gerekli olan olayların kronolojik sırasını sağlar. Nereden alınır? Etkinliğe bağlı olarak oluşturulma tarihi ve saati (VBRK-ERDAT, VBRK-ERZET), değişiklik zaman damgaları (CDHDR-UDATE, CDHDR-UTIME) veya kayıt tarihi (BKPF-BUDAT) gibi çeşitli tarih ve saat alanlarından alınır. Örnekler 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Bitiş zamanı EndTime | Bir etkinliğin veya olayın tamamlandığı anı gösteren kesin zaman damgası. | ||
| Açıklama Bitiş zamanı, bir etkinliğin tamamlandığı anı belirtir. Process Mining çalışmalarında bu değer çoğunlukla vakadaki sonraki etkinliğin başlangıç zamanı olarak belirlenir. Sistem başlangıç ve bitiş olaylarını ayrı ayrı kaydediyorsa doğrudan bu kayıtlardan da alınabilir. Bu öznitelik, tek tek etkinliklerin işlem süresini hesaplamak için gereklidir. Bitiş zamanından başlangıç zamanını çıkararak her adımın ne kadar sürdüğünü ölçebilirsiniz. Bu ölçüm, fatura onay aşamasındaki gecikmeler gibi darboğazları belirlemek için önemlidir. Neden önemli? Her etkinliğin kesin süresini (işlem süresini) hesaplamanızı sağlar ve darboğaz analizinin temelini oluşturur. Nereden alınır? Process Mining için türetilen bir özniteliktir. Genellikle vaka sırasındaki bir sonraki olayın StartTime değeri olarak hesaplanır. Bazı senaryolarda tamamlanma zamanları belirli tablolarda kaydedilebilir. Ö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 eyalet veya il gibi coğrafi alanı belirtir. Bu veri genellikle müşteri ana kaydında bulunur. Bu öznitelik, bölgesel faturalandırma performansı Dashboardu için temel verilerden biridir. Çevrim süreleri, hata oranları ve DSO gibi temel metrikleri farklı bölgelerde karşılaştırmanızı sağlar. Bu karşılaştırma, süreçlerin yürütülmesi, uyumluluk veya verimlilik açısından bölgesel farklılıkları ortaya çıkarabilir; hedefli iyileştirmelere ve iyi uygulamaların standartlaştırılmasına zemin hazırlar. Neden önemli? Faturalandırma performansını farklı coğrafi bölgelerde karşılaştırmanızı, bölgesel farklılıkları belirlemenizi ve süreçleri standartlaştırmanızı sağlar. Nereden alınır? Müşteri ana verileri tablosu KNA1’den (alan: REGIO) alınır ve fatura başlığındaki ödeyen kimliği (VBRK-KUNRG) üzerinden ilişkilendirilir. Örnekler CANYTXBA | |||
| Fatura tarihi InvoiceDate | Faturanın müşteriye düzenlendiği resmi tarih. | ||
| Açıklama SAP’de faturalandırma tarihi olarak da bilinen fatura tarihi, birçok finansal hesaplamanın başlangıç noktasıdır. Ödeme koşulları, vade tarihleri ve alacağın ne kadar süredir açık olduğu bu tarihe göre belirlenir. Bu tarih, finansal analizlerde vaka düzeyinde önemli bir özniteliktir. Satışların tahsilat süresi (DSO) KPI’ını hesaplamak ve nakit akışını ve tahsilatları yönetmek için gerekli olan açık fatura yaşlandırma raporlarını hazırlamak üzere referans alınır. Neden önemli? DSO, ödeme vadeleri ve fatura yaşlandırma analizinin başlangıç noktası olarak finansal hesaplamalarda temel tarihtir. 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, vergiler hariç faturaya konu olan mal veya hizmetlerin toplam parasal değerini gösterir. Her fatura vakası için temel bir finansal veri noktasıdır. Fatura tutarı pek çok analizde kullanılır. Örneğin süreci tutara göre gruplandırarak yüksek tutarlı faturaların farklı işlenip işlenmediğini veya daha fazla gecikme yaşayıp yaşamadığını görebilirsiniz. Ayrıca finansal raporlamanın ve açık alacakların toplam değerini hesaplamanın temelini oluşturur. Neden önemli? Her faturanın finansal değerini göstererek tutara dayalı analiz, tahsilat önceliklendirmesi ve finansal etki değerlendirmesi yapmanızı sağlar. Nereden alınır? SAP tablosu: VBRK, alan: NETWR Örnekler 1500.0025000.50125.75 | |||
| Kullanıcı adı UserName | Etkinliği gerçekleştiren çalışanın kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, fatura oluşturma, belge kaydetme veya ödeme kapatma gibi belirli bir olaydan sorumlu SAP kullanıcı kimliğini kaydeder. Süreç adımlarıyla bu adımları gerçekleştiren kişi veya ekipler arasında bağlantı kurar. Kullanıcı adına göre analiz yapmak, yüksek performans gösteren çalışanları, eğitim ihtiyaçlarını veya iş yükü dağılımındaki dengesizlikleri belirlemeye yardımcı olur. Ayrıca kritik etkinlikleri kimin gerçekleştirdiğini göstererek uyumluluk analizini destekler ve farklı kullanıcıların aynı süreci nasıl yürüttüğündeki farklılıkları anlamanızı sağlar. Neden önemli? Süreç etkinliklerini belirli kullanıcılarla ilişkilendirerek kişi veya ekip düzeyinde iş yükü, performans ve uyumluluk analizi yapmanızı sağlar. Nereden alınır? Oluşturma olaylarında VBRK-ERNAM alanında bulunur. Sonraki değişikliklerde CDHDR-USERNAME gibi değişiklik geçmişi tablolarında veya iş akışı günlüklerinde yer alır. Örnekler CBURNSHSIMPSONLLEONARD | |||
| Müşteri adı CustomerName | Faturanın düzenlendiği müşterinin adı. | ||
| Açıklama Bu öznitelik, fatura düzenlenen müşterinin yasal adını belirtir. SAP’deki merkezi müşteri ana verilerinden alınır. Süreci müşteriye göre analiz ederek belirli hesaplara özgü örüntüleri bulabilirsiniz. Örneğin hangi müşterilerin sürekli geç ödeme yaptığını, en çok itirazı kimin ilettiğini veya faturalandırma sürecinin hangi müşteriler için en verimsiz olduğunu görebilirsiniz. Bu bilgiler, müşteri ilişkilerini yönetmek ve tahsilat stratejilerini müşteriye göre uyarlamak için kullanılabilir. Neden önemli? Müşteri odaklı analiz yapmanızı sağlayarak belirli hesapların ödeme davranışlarını, itiraz sıklığını ve süreç verimsizliklerini belirlemenize yardımcı olur. Nereden alınır? Müşteri ana verileri tablosu KNA1’den (alan: NAME1) alınır ve fatura başlığındaki ödeyen kimliği (VBRK-KUNRG) üzerinden ilişkilendirilir. Örnekler Springfield Enerji SantraliKwik-E-MarketCyberdyne Systems | |||
| Ödeme vadesi PaymentDueDate | Müşterinin faturayı ödemesinin beklendiği tarih. | ||
| Açıklama Ödeme vadesi, fatura tarihine ve üzerinde anlaşılan ödeme koşullarına göre hesaplanır. Faturanın vadesi geçmeden ödemenin alınması gereken son tarihi gösterir. Bu öznitelik, tahsilat etkinliğini izlemek ve nakit akışını tahmin etmek için gereklidir. Zamanında ödeme oranı KPI’ının hesaplanmasında ve faturaların yaşlandırma raporlarında gruplandırılmasında doğrudan kullanılır. Vade tarihiyle gerçek ödeme tarihi arasındaki farkları analiz ederek farklı ödeme koşullarının ne kadar etkili olduğunu değerlendirebilirsiniz. Neden önemli? Müşterinin ödeme son tarihini belirler; zamanında ödeme oranını hesaplamak ve alacakları yönetmek için önemlidir. Nereden alınır? Bu tarih doğrudan saklanmaz. SAP’nin standart tarih belirleme işlevleri kullanılarak fatura tarihi (VBRK-FKDAT) ve ödeme koşulları anahtarı (VBRK-ZTERM) üzerinden hesaplanır. Örnekler 2023-04-192023-05-012023-06-17 | |||
| Alacak dekontu nedeni CreditMemoReason | Alacak dekontunun neden düzenlendiğini belirten neden kodu. | ||
| Açıklama Bir faturada hata olduğunda ve alacak kaydıyla düzeltilmesi gerektiğinde, alacak dekontu belgesine genellikle bir neden atanır. Böylece faturalama hatalarının kaynakları belirli kategoriler altında sınıflandırılır. Bu öznitelik, faturalama hata oranı KPI’ını doğrudan destekler. Şirket, alacak dekontu nedenlerini bir araya getirip analiz ederek fiyatlandırma hataları veya ürün iadeleri gibi en sık karşılaşılan hata türlerini belirleyebilir. Bu analiz, finansal düzeltme ve yeniden çalışma ihtiyacını azaltmaya yönelik süreç iyileştirmelerine yön verir. Neden önemli? Alacak kaydı düzenleme nedenlerini sınıflandırarak faturalama hatalarının en sık görülen kaynaklarını belirlemenize ve kaliteyi artırmanıza yardımcı olur. Nereden alınır? SAP tablosu: VBRK, alan: AUGRU (sipariş nedeni). Bu alan, daha sonra faturalandırılan alacak veya borç dekontu taleplerinde kullanılır. Örnekler 001 - Fiyat farkı002 - Düşük kalite005 - Müşteri iadesi | |||
| Fatura belgesi türü BillingDocumentType | Fatura, alacak dekontu veya iptal gibi fatura belgelerini sınıflandıran kod. | ||
| Açıklama Fatura belgesi türü, faturalama sürecindeki işlemleri sınıflandıran önemli bir alandır. Belgenin numara aralığı ve muhasebe kayıt kuralları dahil nasıl işleneceğini belirler. Bu öznitelik, belirli işlem türlerini analiz etmek için süreci filtrelemenizi sağlar. Örneğin, finansal düzeltmelerin nedenlerini ve akışını anlamak için yalnızca alacak dekontlarını gösteren ayrı bir süreç görünümü oluşturabilir veya temel faturalama sürecini daha net incelemek için standart faturaları iptallerden ayrı analiz edebilirsiniz. Neden önemli? İşlemleri sınıflandırarak standart faturalar, alacak dekontları veya iptaller gibi belirli belge akışlarına odaklanmanızı sağlar. Nereden alınır? SAP tablosu: VBRK, alan: FKART Örnekler F2G2S1L2 | |||
| İtiraz nedeni CustomerDisputeReason | Müşterinin faturaya itiraz ederken belirttiği neden. | ||
| Açıklama Müşteri faturaya itiraz ettiğinde, itiraz nedeni genellikle kaydedilir. Bunun nedeni fiyatlandırma hataları, yanlış miktarlar veya hasarlı ürünler olabilir. Bu bilgi SAP Dispute Management modülünde ya da metin notları olarak saklanabilir. İtiraz nedenlerini analiz etmek, faturalama hata oranı KPI’ı ve ilgili hata analizi için temel oluşturur. Faturalama hatalarının kök nedenlerini belirlemeye yardımcı olur. Böylece işletme, önceki süreçlerdeki sistematik sorunları giderebilir, fatura kalitesini artırabilir ve müşteri memnuniyetini yükseltebilir. Neden önemli? Faturalara neden itiraz edildiğini açıklayarak faturalama hatalarının ve müşteri memnuniyetsizliğinin kök nedenlerini doğrudan görmenizi sağlar. Nereden alınır? SAP Dispute Management kullanılıyorsa bu bilgi UDM_DISPUTE gibi tablolarda bulunabilir. Aksi durumda, ilgili belgelerdeki neden kodlarından veya metin alanlarından elde edilebilir. Örnekler Yanlış fiyatMiktar uyuşmazlığıTeslim alınan ürün hasarlı | |||
| Kaynak sistem SourceSystem | Verinin hangi kaynak sistemden çıkarıldığını belirtir. | ||
| Açıklama Bu öznitelik, verinin kaynağını belirtir. Birden fazla SAP örneğinin veya başka entegre sistemlerin bulunduğu ortamlarda özellikle yararlıdır. Genellikle sistem kimliğini ve istemci numarasını içerir. Analizde farklı sistemler veya kuruluş birimleri arasındaki süreçleri ve performansı ayırt etmeye yardımcı olur. Veri kökenini izlemeyi sağlar ve birden fazla kaynaktan gelen veriler birleştirilerek bütünsel bir süreç görünümü oluşturulduğunda bağlam sunar. Neden önemli? Verinin kaynağı hakkında önemli bağlam sağlar, çok sistemli ortamlarda açıklık sunar ve veri yönetişimini destekler. Nereden alınır? Genellikle veri çıkarma sırasında tanımlanan sabit bir değerdir; çoğu zaman sistem kimliği (SY-SYSID) ile istemciyi (SY-MANDT) birleştirir. Örnekler S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Ödeme durumu PaymentStatus | Fatura ödemesinin mevcut durumu; örneğin açık, ödendi veya vadesi geçti. | ||
| Açıklama Ödeme durumu, tahsilat sürecinde faturanın hangi aşamada olduğunu gösterir. SAP’de bu bilgi tek bir alanda tutulmaz; ilgili muhasebe belgesinin kapatma durumu kontrol edilerek elde edilir. Bu öznitelik, vadesi geçmemiş faturaların yaşlandırma Dashboardu için gereklidir. Açık faturaları durumlarına ve yaşlarına göre gruplandırarak tahsilat ekibinin çalışmalarını önceliklendirmesine yardımcı olur. Durumlar arasındaki geçişleri izlemek, tahsilat sürecinin kendisini takip etmenin de bir yoludur. Neden önemli? Faturanın tahsilat durumunu bir bakışta göstererek alacakları yönetmenize ve tahsilat çalışmalarını önceliklendirmenize yardımcı olur. Nereden alınır? BSID (açık kalemler) ve BSAD (kapatılmış kalemler) gibi finans tablolarında muhasebe belgesinin (VBRK-BELNR) kapatma durumu kontrol edilerek elde edilir. Örnekler AçıkÖdendiVadesi geçtiKısmen ödendi | |||
| Ödeme koşulları PaymentTerms | Ödeme için tanınan süre gibi ödeme koşullarını belirten kod. | ||
| Açıklama Ödeme koşulları, müşterilerle önceden kararlaştırılan ve faturanın ne zaman ödenmesi gerektiğini belirleyen şartlardır. Örneğin, Net 30 faturanın 30 gün içinde ödenmesi gerektiğini, 2/10 Net 30 ise 10 gün içinde ödeme yapılırsa %2 indirim uygulanacağını, aksi durumda ödemenin 30 gün içinde yapılması gerektiğini belirtir. Ödeme koşullarına göre yapılan analiz, bu koşulların ne kadar etkili olduğunu değerlendirmeye yardımcı olur. İşletme, farklı ödeme koşullarını tahsilat için geçen gerçek süreyle karşılaştırarak müşterileri zamanında ödeme yapmaya en çok hangi koşulların teşvik ettiğini belirleyebilir ve nakit akışını iyileştirmek için koşullarını düzenleyebilir. Neden önemli? Kararlaştırılan ödeme takvimini tanımlar ve müşterilerin zamanında ödeme yapmasını sağlamada hangi koşulların daha etkili olduğunu analiz etmenize olanak tanır. Nereden alınır? SAP tablosu: VBRK, alan: ZTERM Örnekler Z030Z060ZB60 | |||
| Para birimi Currency | Fatura tutarının para birimi kodu. | ||
| Açıklama Bu öznitelik, fatura tutarlarının USD, EUR veya JPY gibi hangi para biriminde olduğunu belirtir. Tüm parasal değerlerin doğru yorumlanması için gerekli bağlamı sağlar. Küresel ölçekte faaliyet gösteren bir kuruluşta doğru finansal analiz ve raporlama için para birimi bilgisi gereklidir. Tüm tutarları ortak bir raporlama para birimine dönüştürerek finansal verilerin doğru biçimde toplanmasını ve farklı yerel para birimleri kullanan bölgelerdeki faturalandırma performansının karşılaştırılmasını sağlar. Neden önemli? Tüm parasal değerler için gerekli bağlamı sağlayarak, özellikle birden fazla ülkede faaliyet gösteren kuruluşlarda doğru finansal analiz ve raporlamayı destekler. Nereden alınır? SAP tablosu: VBRK, alan: WAERK Örnekler USDEURGBP | |||
| Satış siparişi numarası SalesOrderNumber | Faturaya kaynak olan ilk satış siparişinin tanımlayıcısı. | ||
| Açıklama Satış siparişi numarası, fatura belgesini önceki satış faaliyetlerine bağlar. Tek bir satış siparişi bir veya daha fazla faturayla sonuçlanabilir. Bu bağlantı, belge akışının tamamını gösterir. Bu öznitelik, Siparişten Tahsilata sürecini uçtan uca analiz etmek için gereklidir. Süreç görünümünü önceki aşamalara genişleterek faturalama sorunlarını, satış siparişinin oluşturulması veya karşılanması aşamalarındaki olası kök nedenlerle ilişkilendirmenizi sağlar. Örneğin, siparişin karşılandığı andan itibaren toplam fatura oluşturma çevrim süresini hesaplamaya yardımcı olur. Neden önemli? Faturayı ilk satış siparişine bağlayarak yalnızca faturalamayı değil, Siparişten Tahsilata sürecinin tamamını görmenizi sağlar. Nereden alınır? SAP tablosu: VBRP (fatura belgesi kalem verileri), alan: AUBEL Örnekler 100001231000045610000789 | |||
| Şirket kodu CompanyCode | Finansal işlemin kaydedildiği organizasyon birimi. | ||
| Açıklama Şirket kodu, SAP Financials içindeki temel organizasyon birimlerinden biridir. Mali tabloların hazırlandığı, hukuken bağımsız şirketi temsil eder. Her fatura belgesi belirli bir şirket koduna atanır. Birden fazla şirketi olan kuruluşlarda şirket koduna göre analiz yapmak; süreç performansını, DSO gibi finansal metrikleri ve farklı tüzel kişilikler arasındaki uyumluluğu karşılaştırmak için önemlidir. Tüm süreç Dashboardları için üst düzey bir organizasyon filtresi sunar. Neden önemli? Süreç analizini tüzel kişiliğe göre gruplandırmanıza, kuruluş genelinde performansı karşılaştırmanıza ve finansal konsolidasyon yapmanıza olanak tanır. Nereden alınır? SAP tablosu: VBRK, alan: BUKRS Örnekler 10002000US01 | |||
| Son veri güncellemesi LastDataUpdate | Bu olaya ait verinin en son ne zaman çıkarıldığını veya yenilendiğini gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, kaynak sistemden en son veri alımının tarih ve saatini kaydeder. Analiz edilen verinin ne kadar güncel olduğunu anlamak için önemli bir meta veri alanıdır. Bu bilgi, analizin güncelliğini doğrulamak ve veri yenileme takvimlerini yönetmek için kullanılır. Süreç Mining Dashboardları ve içgörülerine dayanarak karar verirken paydaşların verinin ne kadar güncel olduğunu bilmesini sağlar. Neden önemli? Verinin güncelliğini gösterir. Analize güvenmek ve sonuçların mevcut operasyonlarla ne kadar ilgili olduğunu anlamak için bu bilgi önemlidir. Nereden alınır? Bu zaman damgası, veri çıkarma ve yükleme (ETL) işlemi sırasında oluşturulur ve her kayda eklenir. Örnekler 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Zamanında ödendi mi IsPaidOnTime | Faturanın vade tarihinde veya daha önce ödenip ödenmediğini belirten mantıksal değer. | ||
| Açıklama Bu hesaplanan öznitelik, gerçek ödeme tarihini planlanan vade tarihiyle karşılaştırır. Ödeme zamanında yapıldıysa true, geç yapıldıysa false değerini alır. Bu gösterge, zamanında ödeme oranı KPI’ının hesaplanmasını ve görselleştirilmesini kolaylaştırır. Geç ödenen faturaları zamanında ödenenlerden ayırarak filtreleyebilir ve özelliklerini inceleyebilirsiniz. Böylece geç ödemelere yol açan belirli müşteriler, bölgeler veya ödeme koşullarıyla ilgili örüntüleri ortaya çıkarabilirsiniz. Neden önemli? Her faturayı zamanında veya geç ödenmiş olarak açıkça işaretleyerek performans ölçümünü kolaylaştırır ve zamanında ödeme oranı KPI’ını doğrudan destekler. Nereden alınır? Hesaplanan bir alandır. Mantık, Customer Payment Received etkinliğinin zaman damgasını PaymentDueDate özniteliğindeki değerle karşılaştırır. Örnekler truefalse | |||
Siparişten Tahsilata - faturalama ve fatura kesme etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura kapatıldı | Bu etkinlik, ödemesi başarıyla alınmış faturanın son durumunu gösterir. İşlevsel olarak 'Nakit faturaya eşleştirildi / mutabakat yapıldı' etkinliğiyle aynıdır ve bu faturaya ait sürecin tamamlandığını belirtir. | ||
| Neden önemli? Sürecin ideal yolundaki temel bitiş olayıdır. Bu noktaya kadar geçen toplam çevrim süresini ölçmek, faturalandırma yaşam döngüsünün uçtan uca görünümünü sağlar. Nereden alınır? Muhasebe belgesindeki müşteri kaleminin durumundan çıkarılır. Kapatma tarihi (BSEG-AUGDT) ve kapatma belgesi (BSEG-AUGBL) alanları doldurulduğunda kalem kapanmış, yani kapatılmış olur. Kaydedin Fatura kalemi için BSEG/ACDOCA tablosundaki kapatma tarihinin (AUGDT) doldurulmasından çıkarılır. Olay türü inferred | |||
| Fatura muhasebeye kaydedildi | Fatura belgesinin finansal muhasebe modülüne başarıyla kaydedildiğini gösterir. Bu önemli aşamada fatura, resmi bir alacak kalemine dönüşür ve büyük deftere kayıtlar eklenir. | ||
| Neden önemli? Bu etkinlik, faturanın yasal bir finansal belge olduğunu doğrular. Faturanın oluşturulmasıyla muhasebeye kaydedilmesi arasındaki süre, kurum içi işlem verimliliğini gösteren önemli bir performans göstergesidir. Nereden alınır? İlgili muhasebe belgesi oluşturulduğunda bu olay kaydedilir. Fatura belgesi (VBRK-VBELN), VBRK-BELNR aracılığıyla muhasebe belgesine (BKPF-BELNR) bağlanır; kayıt tarihi ise BKPF-BUDAT alanında tutulur. Kaydedin Fatura belgesine bağlı BKPF tablosundaki muhasebe belgesinin kayıt tarihinden (BUDAT) alınır. Olay türü explicit | |||
| Fatura oluşturuldu | Bu etkinlik, fatura belgesinin sistemde oluşturulduğunu gösterir. Kullanıcı VF01 gibi bir işlem gerçekleştirdiğinde veya arka plan işi faturayı oluşturduğunda açık bir olay olarak kaydedilir ve fatura belgesi başlık tablosuna yeni bir kayıt eklenir. | ||
| Neden önemli? Bu, faturalandırma sürecinin temel başlangıç olayıdır. Siparişin karşılanmasıyla bu etkinlik arasındaki süreyi analiz etmek, fatura oluşturma çevrim süresini ölçmek ve sürecin ilk aşamalarındaki gecikmeleri belirlemek için önemlidir. Nereden alınır? Oluşturulduğunda SAP S/4HANA VBRK tablosuna (Fatura Belgesi: Başlık Verileri) kaydedilir. Oluşturulma tarihi (VBRK-ERDAT) ve saati (VBRK-ERZET), zaman damgası olarak kullanılır. Kaydedin Olay, VBRK tablosundaki fatura belgesi kaydının oluşturulma zaman damgasından alınır. Olay türü explicit | |||
| Müşteri ödemesi alındı | Bu etkinlik, müşteriden gelen ödemenin finans sistemine kaydedildiğini gösterir. Bu aşamada ödeme henüz belirli bir faturayla eşleştirilmemiş olabilir, ancak alınan tutar kayda geçmiştir. | ||
| Neden önemli? Satışların tahsilat süresini (DSO) hesaplamak için önemli bir aşamadır. Mutabakat henüz tamamlanmamış olsa bile nakdin alındığını gösterir. Nereden alınır? Müşteri ödeme belgesinin (genellikle BKPF tablosunda 'DZ' belge türü) kayıt tarihinden (BKPF-BUDAT) alınır. Kaydedin Olay, BKPF/BSEG tablolarında ödeme belgesinin oluşturulmasına dayanır. Olay türü explicit | |||
| Nakit faturaya eşleştirildi / mutabakat yapıldı | Müşteriden gelen ödemenin eşleştirilerek alacak alt defterindeki açık fatura kalemini kapatmak için kullanıldığı anı gösterir. Bu etkinlikle işlem finansal açıdan tamamlanır. | ||
| Neden önemli? Nakit tahsilat 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ş yaratabilir. Nereden alınır? Bu olay, asıl faturanın muhasebe belgesi kalemindeki kapatma tarihinden (BSEG-AUGDT) alınır. Kapatma belgesi kalemi kapattığında bu tarih doldurulur. Kaydedin Fatura kalemi için BSEG/ACDOCA tablosundaki kapatma tarihi (AUGDT) alanından alınır. Olay türü explicit | |||
| Alacak dekontu oluşturuldu | Bu etkinlik, fazla ücret alınmasını düzeltmek veya iade edilen ürünler için alacak sağlamak üzere müşteriye düzenlenen alacak dekontunun oluşturulmasını gösterir. Genellikle asıl faturaya bağlıdır. | ||
| Neden önemli? Faturalandırma sonrasında finansal düzeltme gerektiren sorunları ortaya çıkarır. Alacak dekontlarını analiz ederek fiyatlandırma hatalarını, ürün sorunlarını veya gelir kaybına yol açan diğer temel nedenleri bulabilirsiniz. Nereden alınır? Alacak dekontlarına özgü bir fatura türüyle (ör. 'G2') VBRK tablosunda yeni bir fatura belgesi olarak açıkça oluşturulur. Genellikle asıl satış siparişine veya faturaya referans verir. Kaydedin VBRK tablosunda alacak dekontu türünde bir fatura belgesi oluşturulduğunda kaydedilir. Olay türü explicit | |||
| Fatura iptal edildi | Daha önce oluşturulmuş bir fatura iptal edildiğinde bu olay gerçekleşir. Genellikle buna karşılık gelen bir iptal belgesi oluşturulur. Böylece asıl fatura ve muhasebe etkisi ters kayıtla geri alınır. | ||
| Neden önemli? Yeniden çalışma, düzeltme veya faturalandırma hatalarına işaret eder. İptallerin sık yaşanması, satış siparişi girişinde veya faturalandırma yapılandırmasında önemli sorunlar olduğunu gösterir. Nereden alınır? Bir iptal fatura belgesi (ör. 'S1' belge türü) oluşturulduğunda kaydedilir. VBRK tablosundaki bu yeni belge, VBRK-SFAKN alanında asıl fatura numarasına referans verir. Kaydedin Olay, asıl faturaya referans veren iptal belgesinin VBRK tablosundaki oluşturulma tarihinden alınır. Olay türü explicit | |||
| Fatura müşteriye gönderildi | Bu etkinlik, faturanın müşteriye yazdırma, e-posta veya EDI gibi bir yöntemle iletildiği zamanı gösterir. Kaydın nasıl tutulacağı, SAP’deki çıktı yönetimi yapılandırmasına bağlıdır. | ||
| Neden önemli? Müşteri açısından ödeme süresinin resmen başladığı noktadır. Faturanın gönderilmesindeki gecikmeler, satışların tahsilat süresini (DSO) ve nakit akışını doğrudan etkiler. Nereden alınır? NAST gibi çıktı kontrol tablolarında (eski yöntemlerde) veya S/4HANA’daki karşılığında açıkça kaydedilebilir. Açık bir kayıt yoksa genellikle 'Fatura muhasebeye kaydedildi' etkinliğiyle aynı zamanda gerçekleştiği varsayılır. Kaydedin Fatura çıktı türüyle ilişkili zaman damgasını bulmak için çıktı yönetimi tablolarındaki işlem günlüklerini kontrol edin. Olay türü explicit | |||
| Faturalandırmada yeniden çalışma belirlendi | Bir faturanın iptal edilip aynı satış siparişi için yenisinin oluşturulduğu yeniden çalışma döngüsünü belirleyen hesaplanmış bir olaydır. Tek bir işlem değil, bir olay örüntüsüdür. | ||
| Neden önemli? Düzeltme durumlarını sayısal olarak ortaya koyarak faturalandırmada yeniden çalışma oranı KPI’ını doğrudan destekler. Verimsizlikleri belirlemeye ve faturalandırma sürecindeki düşük kalitenin maliyetini ölçmeye yardımcı olur. Nereden alınır? Bu örüntü, 'Fatura iptal edildi' olayının ardından aynı kaynak belgeye, örneğin satış siparişi numarasına, bağlı yeni bir 'Fatura oluşturuldu' olayının belirlenmesiyle hesaplanır. Kaydedin Aynı satış siparişi referansı için 'Fatura iptal edildi' ve 'Fatura oluşturuldu' olaylarının sırası belirlenerek türetilir. Olay türü calculated | |||
| Faturanın muhasebeye kaydı engellendi | Fatura oluşturulduğu halde kredi kontrolleri veya veri tutarsızlıkları gibi nedenlerle finansal muhasebeye kaydı otomatik olarak engellendiğinde bu olay gerçekleşir. Durum, fatura belgesindeki kayıt durumu alanından çıkarılır. | ||
| Neden önemli? Faturaların oluşturulduğu ancak finans birimine hemen aktarılmadığı ve tüm tahsilat döngüsünün geciktiği darboğazları belirler. Veri kalitesi sorunlarının veya kredi yönetimi problemlerinin önemli bir göstergesidir. Nereden alınır? Fatura belgesi başlık tablosundaki kayıt durumu alanından (VBRK-RFBSK) çıkarılır. 'A' gibi bir durum (Fatura belgesinin FI’ye aktarılması engellendi) bu engeli gösterir. Kaydedin Fatura oluşturulduktan hemen sonra kayıt durumu alanının (VBRK-RFBSK) değeri kontrol edilerek belirlenir. Olay türü inferred | |||
| Müşteri itirazı açıldı | Müşteri faturaya itiraz ettiğinde ve bu itiraz sistemde resmi olarak kaydedildiğinde bu etkinlik gerçekleşir. Bunun için SAP Dispute Management modülünün kullanılması gerekir. | ||
| Neden önemli? Ödeme gecikmelerine yol açan faturalandırma doğruluğu, ürün kalitesi veya hizmet sunumuyla ilgili sorunları ortaya çıkarır. İtiraz nedenlerini analiz etmek, temel sorunları gidermeye ve müşteri memnuniyetini artırmaya yardımcı olabilir. Nereden alınır? Muhasebe belgesi kalemine bağlı bir itiraz vakası Dispute Management tablolarında (ör. UDM_CASE) oluşturulduğunda kaydedilir. Kaydedin Faturaya bağlı itiraz vakası kaydının oluşturulma zaman damgasından alınır. Olay türü explicit | |||
| Ödeme hatırlatması gönderildi | Vadesi geçmiş bir fatura için müşteriye ödeme hatırlatması veya tahsilat bildirimi gönderildiğini gösterir. Otomatik tahsilat prosedürünün oluşturduğu açık bir olaydır. | ||
| Neden önemli? Tahsilat sürecinin ne kadar etkili olduğunu analiz etmenizi sağlar. Hatırlatmaların ödemeleri hızlandırıp hızlandırmadığını ve hangi tahsilat düzeylerinin daha etkili olduğunu belirlemeye yardımcı olur. Nereden alınır? Faturanın açık kalemi için tahsilat çalıştırması (F150 işlemi) yürütüldüğünde tahsilat geçmişi tablolarına (MAHNV, MHND) kaydedilir. Kaydedin Tahsilat geçmişi tablolarında kayıtlı tahsilat bildiriminin çalıştırılma tarihinden alınır. Olay türü explicit | |||
| Ödeme vadesi geldi | Üzerinde anlaşılan ödeme koşullarına göre fatura ödemesinin resmen vadesinin geldiği tarihi gösteren hesaplanmış bir olaydır. İşlem sırasında gerçekleşen bir olay değildir, fatura verilerinden türetilir. | ||
| Neden önemli? Zamanında ödeme performansını ölçmek ve müşteri ödeme davranışını analiz etmek için önemli bir referans noktası sağlar. Ödemelerin zamanında mı yoksa gecikmiş mi olduğunu ayırt etmeye yardımcı olur. Nereden alınır? Ödeme için esas alınan tarih (BSEG-ZFBDT) ve muhasebe belgesindeki müşteri kaleminde kayıtlı ödeme koşullarına göre hesaplanır. Kaydedin Muhasebe belgesindeki kalemden (BSEG) alınan esas ödeme tarihine ödeme koşullarındaki gün sayısı eklenerek belirlenir. Olay türü calculated | |||
Veri çıkarma kılavuzları
Adımlar
- Ön koşullar: SAP S/4HANA’da Core Data Services (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ümlere okuma erişiminiz olmalıdır.
- Veri çıkarma aracına erişin: SAP S/4HANA sisteminizde oturum açın. CDS görünümlerine yönelik SQL sorgularını çalıştırmak için SAP HANA Studio, SAP HANA istemcisi üzerinden bağlanan DBeaver veya SAP Analysis for Microsoft Excel eklentisi gibi çeşitli araçları kullanabilirsiniz. Bu kılavuzda standart bir SQL istemcisi kullandığınızı varsayıyoruz.
- Sistem parametrelerini belirleyin: Sorguyu çalıştırmadan önce analiziniz için ilgili şirket kodlarını ve tarih aralığını belirleyin. Sorgunun makul sürede çalışmasını sağlamak için başlangıçta son 3 ila 6 aylık veri gibi sınırlı bir kapsamla başlamanız önerilir.
- SQL sorgusunu hazırlayın: Bu belgenin 'query' bölümünde verilen SQL sorgusunun tamamını kopyalayıp seçtiğiniz SQL istemcisine yapıştırın.
- Yer tutucuları özelleştirin: Sorgudaki yer tutucu değerleri değiştirin.
'YYYY-MM-DD'değerlerini istediğiniz başlangıç ve bitiş tarihleriyle değiştirin.'XXXX'yerine hedef şirket kodlarınızı yazın. Sistem yapılandırmanıza bağlı olarak kredi notu belge türü için kullanılan'G2'gibi yer tutucuyu da değiştirmeniz gerekebilir. - Sorguyu çalıştırın: Düzenlediğiniz SQL sorgusunu SAP S/4HANA veritabanında çalıştırın. Çalışma süresi, seçtiğiniz tarih aralığındaki veri miktarına göre değişir.
- Sonuçları inceleyin: Sorgu tamamlandığında çıktıyı inceleyin. Sonuç kümesi, her satırın faturalama sürecindeki tek bir etkinliği temsil ettiği düz bir tablo olmalıdır. Bu, olay günlüğünüzdür.
- Veri dönüşümü (gerekirse): Sorgu, temiz bir olay günlüğü biçimi oluşturacak şekilde tasarlanmıştır. Yine de zaman damgası biçiminin Process Mining aracınızla uyumlu olduğunu kontrol edin. Sorgu, yaygın olarak desteklenen standart UTC zaman damgasına dönüştürmek için
ABAP_SYSTEM_UTCL_TO_TIMESTAMPkullanır. - Event Logu dışa aktarın: Sonuç kümesinin tamamını SQL istemcinizden CSV dosyasına aktarın. Karakter sorunlarını önlemek için dosyanın UTF-8 kodlamalı olduğundan emin olun.
- ProcessMind’e yükleyin: Oluşturduğunuz CSV dosyasını ProcessMind platformuna yükleyin. Dosyadaki InvoiceNumber, ActivityName ve EventTime gibi sütunları araçtaki karşılık gelen alanlarla eşleyin.
Yapılandırma
- Tarih aralığı: Başlangıç ve bitiş tarihlerini ilk Common Table Expression (CTE) içindeki
WHEREkoşulunda belirleyin. Veri miktarı ile performans arasında denge kurmak için ilk analizde 3 ila 6 aylık bir aralık önerilir. Filtre,BillingDocumentDatealanına uygulanır. - Şirket kodu: Çıkarımı ilgili tüzel kişilerle sınırlamak için bir veya daha fazla
CompanyCodedeğeriyle filtreleyin. Veri kapsamını yönetmek için bu filtre büyük önem taşır. - Belge türleri: Sorguda,
BillingDocumentTypealanına göre kredi notlarını belirleyen bir mantık bulunur. Yer tutucuyu kuruluşunuzda kredi notları için kullanılan belge türleriyle, örneğin('G2', 'CR'), yapılandırmanız gerekir. - Ön koşullar: Altta yatan CDS görünümlerine erişim zorunludur. Bunun için SAP güvenlik ekibinizin atadığı belirli roller ve yetkiler gerekir. Ayrıca 'Customer Dispute Opened' veya 'Payment Reminder Issued' gibi etkinlikler için SAP Dispute Management ve SAP Financials Dunning modüllerinin sisteminizde etkin olarak kullanılması gerekir.
- Performans: Sorguda birden fazla birleştirme ve UNION işlemi kullanılır. Birkaç yıllık veri gibi çok büyük veri setlerinde sorguyu yoğun olmayan saatlerde çalıştırmayı veya ilk veri çekimini sınırlamak için daha dar filtreler uygulamayı değerlendirin.
Ö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
- Faturalama ve ilgili finans tablolarını içeren SAP HANA şemasına doğrudan okuma erişiminiz olduğunu doğrulayın. Şema adını, bağlantı bilgilerini, yetkili tarih aralığını, şirket kodu kapsamını, faturalama belge türlerini ve varsa müşteri ya da bölge filtrelerini sistem sahibinden alın. Sorguda yalnızca bağlantı ve filtre yer tutucularını değiştirin.
- Hedef sistemde ilgili SAP S/4HANA veri kaynaklarını ve alan eşlemelerini doğrulayın. Sorgu, faturalama verileri için VBRK ve VBRP tablolarını kullanır; ayrıca muhasebe, çıktı yönetimi, ihtilaf yönetimi, ödeme hatırlatma, gelen ödemeler, mahsuplaştırma ve belge ilişkileri için yapılandırılmış kaynaklar gerektirir. Köşeli parantez içindeki kaynak ve alan yer tutucularını yalnızca sistem veri sözlüğünde doğruladıktan sonra değiştirin.
- Çıkarım dönemini, başlangıç zaman damgası dahil ve bitiş zaman damgası hariç olacak şekilde ayarlayın. İlk çalıştırma için üç ila altı aylık bir dönem önerilir. Hacmi kontrol etmek ve ilgisiz faturalama süreçlerinin verilerini karıştırmamak için çıkarımı şirket koduyla ve uygun olduğunda faturalama türüyle sınırlayın.
- Sorguyu yalnızca okuma yetkisi olan bir HANA veritabanı kullanıcısıyla çalıştırın. Sorgu, açıkça çıkarılan her etkinlik için bir olay satırı oluşturur. Olayları çıkarsamak için ProcessMind’e dayanmaz. Ödeme vadesine ulaşılması ve faturalama için yeniden çalışma tespiti gibi hesaplanan etkinlikler SQL mantığıyla oluşturulur ve satır olarak döndürülür.
- Döndürülen şemayı doğrulayın. Olay günlüğünde InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region ve EndTime alanları bulunmalıdır. Her satırda InvoiceNumber, ActivityName ve EventTime alanlarının dolu olduğunu kontrol edin.
- Olayların anlamını ve ilişkilerini doğrulayın. Invoice Generated satırlarını fatura başlığı oluşturma verileriyle, Invoice Posted To Accounting satırlarını muhasebe kayıt durumuyla, Invoice Sent To Customer satırlarını çıktı kayıtlarıyla, ödeme satırlarını muhasebe belgeleriyle ve mahsuplaştırma satırlarını kapatılmış fatura kalemleriyle karşılaştırın. Üretimde kullanmadan önce yer tutuculara bağlı tüm bölümleri inceleyin.
- Sonucu ProcessMind için standartlaştırın. Her olay için tek satır kullanın, tutarlı bir zaman damgası veri türü ve saat dilimi belirleyin, baştaki sıfırları korumak için InvoiceNumber değerini metin olarak saklayın ve ActivityName değerlerinin gerekli etkinlik adlarıyla birebir eşleştiğinden emin olun. InvoiceNumber ve EventTime alanlarına göre sıralayın; birden fazla olay aynı zaman damgasına sahipse belirleyici bir ikincil sıralama kullanın.
- Sonucu UTF-8 CSV veya ProcessMind’in desteklediği başka bir tablo biçiminde dışa aktarın. InvoiceNumber alanını vaka tanımlayıcısı, ActivityName alanını etkinlik sütunu ve EventTime alanını olay zaman damgası olarak eşleyin. Varsa önerilen öznitelikleri de ekleyin, ardından dosyayı yapılandırılmış ProcessMind içe aktarma süreciyle yükleyip son satır ve etkinlik sayısı kontrollerini yapın.
Yapılandırma
- Tarih aralığı: Üç ila altı aylık bir dönemle başlayın. Artımlı çalıştırmalarda yinelenen olayları önlemek için başlangıç zaman damgasını dahil, bitiş zaman damgasını hariç tutun.
- Vaka tanımlayıcısı: Faturalama belgesi başlığındaki InvoiceNumber alanını kullanın. SAP belge numaralarının başında sıfır bulunabileceğinden bu alanı metin olarak saklayın.
- Gerekli etkinlikler: Çıkarımda Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created ve Billing Rework Identified etkinlikleri için açık satırlar bulunmalıdır.
- Filtreler: Şirket kodu, faturalama belge türü, satış organizasyonu, müşteri, bölge ve tarih filtrelerini yalnızca hedef sistemde ilgili alanları ve iş kapsamını doğruladıktan sonra uygulayın. Her faturalama belge türünün aynı muhasebe veya çıktı sürecini izlediğini varsaymayın.
- Kaynak yapılandırması: VBRK ve VBRP, temel faturalama kaynaklarıdır. Muhasebe, çıktı, ihtilaf, ödeme hatırlatma, ödeme, mahsuplaştırma ve belge akışı kaynakları, dağıtılan SAP S/4HANA sürümüne ve etkin modüllere göre yapılandırılmalıdır. Köşeli parantez içindeki kaynak başvurularını doğrulanmış nesne ve alanlarla değiştirin.
- Hesaplanan olaylar: Payment Due Date Reached, ödeme koşullarından ve vade tarihi verilerinden hesaplanır. Billing Rework Identified ise iptal ve ardından yeni fatura oluşturulması örüntülerinden çıkarılır. Bunlar yerel işlem kayıtları değil, SQL tarafından oluşturulan olay satırlarıdır.
- Performans: Tarih, şirket kodu, faturalama türü ve belge numarası filtrelerini her kaynak sorgusuna uygulayın. Yalnızca gerekli sütunları seçin, büyük muhasebe tablolarını sınırsız biçimde birleştirmekten kaçının, dönemi aylık veya haftalık gruplar hâlinde işleyin ve maliyetli birleştirmeleri belirlemek için veritabanı yürütme planlarını kullanın.
- Artımlı çıkarım: Kaynak oluşturma veya kayıt zaman damgalarına dayalı, değişmeyen bir watermark kullanın. Sonradan gelen çıktı, ödeme, ihtilaf ve mahsuplaştırma kayıtlarını yakalamak için kısa bir örtüşme aralığını yeniden işleyin; ardından InvoiceNumber, ActivityName ve EventTime ile ilgili kaynak belge anahtarını kullanarak yinelenen kayıtları ayıklayın.
- Yetkiler: Çıkarım kullanıcısının seçilen HANA şema nesneleri ve alanları için okuma yetkisi olmalıdır. Doğrudan veritabanı erişimine kuruluşunuzun güvenlik politikasının izin verdiğini ve kişisel ya da müşteri verilerinin işlenmesine ilişkin gerekliliklerin karşılandığını doğrulayın.
- İşlevsel ön koşullar: Çıktı yönetimi, muhasebe entegrasyonu, ihtilaf yönetimi, ödeme hatırlatma, gelen ödeme ve mahsuplaştırma verileri yalnızca sistemde yapılandırılmış ve kullanılıyorlarsa bulunur. Eksik modüller veya kaynak kayıtları, etkinliklerin çıkarımla oluşturulmasına değil, eksik kalmasına yol açar.
- Saat dilimi: Zaman damgalarını ProcessMind’in gerektirdiği saat dilimine göre standartlaştırın. Kaynak zaman damgalarının UTC, yerel sistem saati veya başka bir yapılandırılmış saat diliminde saklandığını belgeleyin.
Örnek sorgu sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Başlamaya hazır mısınız?
Veri hazırlığını hızlandırmak ve Siparişten Tahsilata - Faturalama ve Fatura İşleme sürecinizi iyileştirmeye başlamak için bu Templateten yararlanın. SAP S/4HANA verilerinizi bugün uygulanabilir içgörülere dönüştürmeye başlayın.
Siparişten Tahsilata faturalama sürecini iyileştirerek nakit akışını %30 hızlandırın
Verimsizlikleri ortadan kaldırın ve faturalama çevrim sürenizi bugünden başlayarak %30 kısaltın.
Kredi kartı gerekmez. Dakikalar içinde başlayın.