Kayıttan Raporlamaya - Yevmiye kaydı Veri Templateiniz
Kayıttan Raporlamaya - Yevmiye kaydı Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma için pratik yönergeler
Kayıttan Raporlamaya - Yevmiye kaydı öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite ActivityName | Yevmiye kaydı sürecinin belirli bir noktasında gerçekleşen iş etkinliğinin adı. | ||
| Açıklama Aktivite, yevmiye kaydının yaşam döngüsündeki belirli bir adımı veya olayı ifade eder. Örneğin 'Yevmiye kaydı oluşturuldu', 'Yevmiye kaydı incelemeye gönderildi' veya 'Yevmiye kaydı sisteme işlendi'. Bu etkinlikler genellikle sistemde kaydedilen değişiklik günlüklerinden, durum güncellemelerinden veya işlem kodlarından elde edilir. Etkinlikleri analiz ederek süreç akışını görselleştirebilir, yaygın yolları belirleyebilir ve standart prosedürden sapmaları keşfedebilirsiniz. Etkinlik sıklığı, adımlar arasındaki bekleme süreleri ve uyum oranları gibi metrikleri hesaplamak için temel oluşturur. Neden önemli? Süreç adımlarını tanımlar; süreç haritalarını görselleştirmenizi ve iş akışı örüntülerini analiz etmenizi sağlar. Nereden alınır? Başlık ve kalem tablolarındaki durum alanları (ör. BKPF-BSTAT), değişiklik belgesi günlükleri (CDHDR/CDPOS) ve iş akışı günlükleri dahil olmak üzere çeşitli kaynaklardan elde edilir. Örnekler Yevmiye kaydı oluşturulduYevmiye kaydı beklemeye alındıYevmiye kaydı incelemeye gönderildiYevmiye kaydı onaylandıYevmiye kaydı sisteme işlendi | |||
| Olay zamanı EventTime | Yevmiye kaydı için belirli bir etkinliğin ne zaman gerçekleştiğini gösteren zaman damgası. | ||
| Açıklama Olay zamanı, bir iş etkinliğinin gerçekleştirildiği ve sisteme kaydedildiği kesin tarih ve saattir. Bir vakadaki her etkinliğin kendine ait bir zaman damgası vardır; böylece olaylar kronolojik sıraya dizilir. Bu öznitelik, zamana dayalı tüm süreç analizlerinin temelini oluşturur. Çevrim sürelerini, etkinlikler arasındaki süreleri ve bekleme zamanlarını hesaplamak, işlerin zamana göre dağılımını anlamak için kullanılır. Güvenilir bir süreç modeli oluşturmak ve Onay Döngüsü Süresi gibi temel performans göstergelerini hesaplamak için zaman damgalarının doğru olması gerekir. Neden önemli? Olayların kronolojik sırasını gösterir. Bu sıra, süreye dayalı tüm metrikleri hesaplamak ve süreç zaman çizelgesini anlamak için gereklidir. Nereden alınır? Değişiklik belgesi günlüklerinden (CDHDR-UDATE, CDHDR-UTIME), iş akışı günlüklerinden veya BKPF gibi tablolardaki oluşturma/giriş zaman damgalarından (CPUDT, CPUTM) alınır. Örnekler 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Yevmiye kaydı kimliği JournalEntryId | Finansal bir yevmiye kaydının benzersiz tanımlayıcısıdır ve süreçteki temel vaka kimliği olarak kullanılır. | ||
| Açıklama Yevmiye kaydı kimliği, SAP S/4HANA’da her muhasebe belgesi oluşturulduğunda belgeye atanan benzersiz numaradır. Bu kimlik, yevmiye kaydının oluşturulması veya beklemeye alınmasından onay iş akışlarına, son kayıt işlemine ve olası ters kayıt ya da kapatma adımlarına kadar tüm yaşam döngüsünü izlemek için gereklidir. Process Mining analizinde bu kimlik, ilgili tüm etkinlikleri tek bir vakayla ilişkilendirmek için kullanılır. Analistler, olayları ortak bir yevmiye kaydı kimliği altında gruplayarak uçtan uca süreç akışını yeniden oluşturabilir, çevrim sürelerini ölçebilir ve her finansal işlemdeki farklılıkları ya da darboğazları belirleyebilir. Sürecin bütününü görüntülemek için gereken temel özniteliktir. Neden önemli? Bu kimlik, ilgili tüm süreç adımlarını birbirine bağlayarak her yevmiye kaydının uçtan uca yolculuğunu analiz etmenizi sağlar. Nereden alınır? Bu bileşik anahtar genellikle Şirket Kodu (BKPF-BUKRS), Belge Numarası (BKPF-BELNR) ve Mali Yıl (BKPF-GJAHR) birleştirilerek oluşturulur. Örnekler 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Kaydı oluşturan kullanıcı CreatedByUser | Yevmiye kaydını oluşturan kişinin kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, ilk belgeyi oluşturarak yevmiye kaydı sürecini başlatan kullanıcının benzersiz kimliğini saklar. Bu kişi bir muhasebeci, iş kullanıcısı veya otomatik kayıtlar için bir sistem kimliği olabilir. Süreci kaydı oluşturan kişiye göre analiz etmek, belirli kullanıcılar veya ekiplerle ilişkili örüntüleri ortaya çıkarır. Bazı kullanıcıların ret oranları yüksekse eğitim ihtiyacını gösterebilir veya yüksek performans gösteren kişileri belirlemeye yardımcı olabilir. Kullanıcı etkinliği ve işlem hacmi Dashboardu için temel bir veridir. Neden önemli? Süreç etkinliklerini belirli kullanıcılara bağlar; performans analizini, iş yükü dengesini ve eğitim fırsatlarının belirlenmesini sağlar. Nereden alınır? SAP S/4HANA tablosu BKPF, USNAM alanı (Kullanıcı adı). Örnekler ABROWNCJONESBATCH_USER | |||
| Kayıt tarihi PostingDate | Yevmiye kaydının büyük deftere işlendiği ve mali dönemi etkileyen tarih. | ||
| Açıklama Kayıt tarihi, işlemin mali tablolarda hangi mali dönemde yer alacağını belirler. Muhasebe açısından önemli olan bu tarih, belgenin oluşturulduğu veya sisteme girildiği tarihten farklı olabilir. Process Mining analizinde kayıt tarihi, ay sonu kapanış süreçlerini karşılaştırmak veya farklı mali dönemlerdeki performans eğilimlerini incelemek gibi zamana dayalı kohort analizlerinde kullanılır. Ayrıca kaydın oluşturulmasıyla mali kaydın fiilen yapılması arasındaki gecikmeyi ölçmeye de yardımcı olur. Neden önemli? Ay sonu veya yıl sonu gibi belirli muhasebe dönemlerinde süreç performansını analiz etmeyi sağlar ve finansal bağlamı anlamak açısından önemlidir. Nereden alınır? SAP S/4HANA tablosu BKPF, BUDAT alanı (Belgedeki kayıt tarihi). Örnekler 2023-10-312023-11-012024-02-29 | |||
| Şirket kodu CompanyCode | Yevmiye kaydının işlendiği şirketi veya tüzel kişiliği tanımlayan benzersiz kod. | ||
| Açıklama Şirket kodu, SAP Financials içindeki temel organizasyon birimlerinden biridir. Mali tabloların hazırlandığı bağımsız bir tüzel kişiliği temsil eder. Her yevmiye kaydı belirli bir şirket koduna atanır. Bu öznitelik, kuruluşun farklı bölümlerindeki süreç performansını ayırmak ve karşılaştırmak için önemlidir. Analistler belirli bir tüzel kişiliğe ait süreç görünümünü filtreleyebilir, şirket kodları arasındaki ret oranlarını karşılaştırabilir veya bölgelere özgü süreç farklılıklarını belirleyebilir. Neden önemli? Kuruluş içindeki farklı tüzel kişilikler veya iş birimleri için yevmiye kaydı sürecini filtrelemeyi ve karşılaştırmayı sağlar. Nereden alınır? SAP S/4HANA tablosu BKPF, BUKRS alanı (Şirket kodu). Örnekler 10001710US01 | |||
| Yerel para birimindeki tutar AmountInLocalCurrency | Şirket kodunun yerel para birimiyle ifade edilen toplam yevmiye kaydı tutarı. | ||
| Açıklama Bu öznitelik, yevmiye kaydının finansal büyüklüğünü gösterir. Genellikle belgedeki tüm borç veya alacak kalemlerinin mutlak değerleri toplanıp şirket kodunun yerel para birimine çevrilerek hesaplanır. Tutar üzerinden yapılan analiz, sürecin finansal etkisine göre ayrıştırılmasını sağlar. Örneğin, yüksek tutarlı kayıtlar düşük tutarlı kayıtlara kıyasla daha sıkı bir onay sürecinden geçebilir. Finansal riski en yüksek işlemlere öncelik vererek süreç iyileştirme çalışmalarına yön vermeye yardımcı olur. Neden önemli? Kaydın finansal değerini gösterir ve işlem tutarına göre süreç davranışının nasıl değiştiğini analiz etmeyi sağlar. Nereden alınır? Belirli bir yevmiye kaydı (BELNR) için kalem tablosu BSEG’deki tutarlar (DMBTR alanı) toplanıp pozitif değere çevrilerek hesaplanır. Örnekler 1500.75125000.0050.20 | |||
| Yevmiye kaydı türü JournalEntryType | Yevmiye kaydını varlık kaydı, tedarikçi faturası veya büyük defter kaydı gibi iş amacına göre sınıflandırır. | ||
| Açıklama SAP terminolojisinde Belge Türü olarak da adlandırılan yevmiye kaydı türü, muhasebe belgelerini kategorilere ayıran bir anahtardır. Belgeye atanacak numara aralığını ve hangi hesap türlerinin kaydedilebileceğini belirler. Süreci yevmiye kaydı türüne göre analiz etmek, türe özgü davranışları anlamak açısından önemlidir. Örneğin, basit bir tahakkuk kaydının (SA türü) onay süreci, karmaşık bir varlık ediniminin (AA türü) onay sürecinden çok daha basit olabilir. Bu boyut, Kayıt türüne göre uyumluluk Dashboardu için temel bir veridir. Neden önemli? Kayıtları iş bağlamına göre sınıflandırır; farklı finansal işlem türlerindeki süreç farklılıklarını ve performansı analiz etmeyi sağlar. Nereden alınır? SAP S/4HANA tablosu BKPF, BLART alanı (Belge türü). Örnekler SAKRAA | |||
| Belge durumu DocumentStatus | Yevmiye kaydının mevcut işlenme durumu; örneğin beklemede, kaydedildi veya kapatıldı. | ||
| Açıklama Belge durumu, yevmiye kaydının yaşam döngüsündeki aşamasını gösterir. Örneğin, bekletilen bir belge kaydedilmiştir ancak henüz büyük deftere işlenmemiştir; kaydedilmiş bir belge ise son hâlini almıştır. Durumu analiz etmek, iş akışını anlamaya ve darboğazları belirlemeye yardımcı olur. Uzun süre beklemede veya onay bekliyor durumunda kalan çok sayıda belge, süreçteki verimsizliklere işaret edebilir. Süreç etkinliklerini türetmek için de önemli bir kaynaktır. Neden önemli? Yevmiye kaydının yaşam döngüsündeki mevcut aşamasını göstererek kuyrukları ve darboğazları belirlemeye yardımcı olur. Nereden alınır? SAP S/4HANA tablosu BKPF, BSTAT alanı (Belge durumu). Örnekler VAB | |||
| Bitiş zamanı EndTime | Etkinliğin tamamlandığı zamanı gösteren zaman damgası. | ||
| Açıklama Bitiş zamanı, bir etkinliğin tamamlandığı anı belirtir. Birçok Event Logda etkinliğin başlangıç ve bitiş zamanları aynıdır; bu da etkinliğin anlık gerçekleştiğini gösterir. Ancak kullanıcının bir belgeyi incelemesi gibi süresi ölçülebilen etkinliklerde bu öznitelik, etkinliğin ne kadar sürdüğünü kaydedebilir. Ayrı bir bitiş zamanı, etkinliklerin işlem süresini bekleme süresinden daha doğru biçimde ayırmayı sağlar. Bir görevin üzerinde fiilen çalışılan süreyle kuyrukta beklediği süreyi birbirinden ayırmaya yardımcı olur. Neden önemli? Etkinliklerin işlem süresini hassas biçimde hesaplamayı, aktif çalışma süresini bekleme süresinden ayırmayı sağlar. Nereden alınır? Atomik olaylarda genellikle StartTime ile aynıdır. Süreye yayılan etkinliklerde iş akışı günlüklerinden alınabilir veya sonraki olaylara göre hesaplanabilir. Örnekler 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| İşlem kodu TransactionCode | Yevmiye kaydını oluşturmak veya değiştirmek için kullanılan SAP işlem kodu. | ||
| Açıklama İşlem kodu (T-Code), SAP’de belirli bir işlevi veya programı tanımlayan kısayoldur. Yevmiye kayıtlarında farklı T-Code değerleri, kaydın nasıl oluşturulduğunu gösterebilir. Örneğin FB01 manuel büyük defter kaydı, FV50 bekletme veya sistem tarafından oluşturulan kayıtlar için otomatik bir kod kullanılır. Bu öznitelik, etkinliğin kullanıcı tarafından manuel mi yoksa sistem tarafından otomatik mi gerçekleştirildiğini gösterir. Manuel kayıt oranı KPI’ını hesaplamak ve otomasyon fırsatlarını belirlemek için temel bir veridir. Neden önemli? Kaydın nasıl işlendiğini (ör. manuel veya otomatik) gösterir; otomasyon analizine ve süreç farklılıklarını anlamaya yardımcı olur. Nereden alınır? SAP S/4HANA tablosu BKPF, TCODE alanı (İşlem kodu). Örnekler FB01FV50F-02 | |||
| Kaynak sistem SourceSystem | Yevmiye kaydı verilerinin hangi kaynak sistemden çıkarıldığını belirtir. | ||
| Açıklama Bu öznitelik, yevmiye kaydı verilerinin geldiği kayıt sistemini belirtir. Birden fazla ERP örneği veya eski ve modern sistemlerin bir arada kullanıldığı şirketlerde veri kaynaklarını ayırt etmeye yardımcı olur. Analiz sırasında farklı sistemlerdeki süreç performansını karşılaştırmak veya belirli bir kaynaktan gelen verileri filtrelemek için kullanılabilir. Veri yönetişimi ve verilerin bağlamının doğru anlaşılması açısından önemlidir. Neden önemli? Verilerin kaynağı hakkında bilgi verir. Doğru süreç analizi ve karşılaştırması için birden fazla sistemin kullanıldığı ortamlarda bu bilgi büyük önem taşır. Nereden alınır? Bu değer genellikle veri çıkarımı sırasında eklenir ve ilgili SAP S/4HANA örneğini (ör. SID veya mantıksal sistem adı) belirtir. Örnekler S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Mali yıl FiscalYear | Yevmiye kaydının ait olduğu mali yıl. | ||
| Açıklama Mali yıl, şirket kodu ve belge numarasıyla birlikte yevmiye kaydının benzersiz anahtarını oluşturur. Belgenin geçerli olduğu mali yılı belirtir. Analizde mali yıl, uzun vadeli eğilimleri incelemek ve vaka kimliğinin benzersiz olmasını sağlamak için kullanılır. Farklı mali yıllardaki süreç metriklerini karşılaştırmak, performansın zaman içinde iyileşip iyileşmediğini veya gerileyip gerilemediğini gösterebilir. Neden önemli? Belgeleri benzersiz biçimde tanımlamak için gereken temel bilgiyi sağlar ve süreç performansını yıllar arasında analiz etmeyi mümkün kılar. Nereden alınır? SAP S/4HANA tablosu BKPF, GJAHR alanı (Mali yıl). Örnekler 202320242022 | |||
| Manuel kayıt mı IsManualPosting | Yevmiye kaydının kullanıcı tarafından manuel olarak yapılıp yapılmadığını belirten bir boole işareti. | ||
| Açıklama Bu öznitelik, sistem işi veya arayüz tarafından otomatik olarak değil, kullanıcının müdahalesiyle yapılan yevmiye kayıtlarını belirler. Genellikle belgeyi kaydetmek için kullanılan işlem kodundan türetilir. Bu işaret, manuel kayıt oranı KPI’ını hesaplamak ve kuruluşların Kayıttan Raporlamaya sürecini otomatikleştirme ilerlemesini izlemek için kullanılır. Analistler manuel kayıtları filtreleyerek hâlâ insan müdahalesi gerektiren senaryoları belirleyebilir ve otomasyon potansiyellerini değerlendirebilir. Neden önemli? İnsan müdahalesiyle yapılan kayıtları sistem tarafından yapılanlardan ayırır; otomasyon düzeyini ölçmeye ve otomasyon fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Bu, TransactionCode değerinden türetilen hesaplanmış bir özniteliktir. İşaretin true olarak ayarlanması için önceden tanımlanmış manuel işlem kodları listesi (ör. FB01, F-02) kullanılır. Örnekler truefalse | |||
| Onay çevrim süresi ApprovalCycleTime | Yevmiye kaydının onaya gönderilmesiyle onaylanması veya reddedilmesi arasında geçen süre. | ||
| Açıklama Bu hesaplanan metrik, özellikle onay aşamasının süresini ölçer. Yevmiye kaydı incelemeye gönderildi etkinliği ile ardından gelen Yevmiye kaydı onaylandı veya Yevmiye kaydı reddedildi etkinliği arasındaki süreyi hesaplar. Bu KPI, onay iş akışındaki darboğazları belirlemek açısından önemlidir. Onay çevrim süresinin uzun olması, genel süreci önemli ölçüde geciktirebilir. Bu metriği onaylayan kişiye, şirket koduna veya yevmiye kaydı türüne göre analiz etmek, iyileştirme gereken alanları ortaya çıkarabilir. Neden önemli? Onay adımının süresini ayrı olarak ölçerek inceleme ve onay iş akışındaki darboğazları belirlemeye ve gidermeye yardımcı olur. Nereden alınır? Yevmiye kaydı incelemeye gönderildi olayı ile Yevmiye kaydı onaylandı veya Yevmiye kaydı reddedildi olayı arasındaki zaman farkı hesaplanarak bulunur. Örnekler 1 gün 2 saat4 saat 25 dakika5 gün 0 saat | |||
| Onaylayan kullanıcı ApproverUser | Yevmiye kaydını onaylayan veya reddeden kişinin kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, gönderilen bir yevmiye kaydını incelemekten ve karar vermekten sorumlu kullanıcıyı tanımlar. Birden fazla düzeyden oluşan onay iş akışında tek bir yevmiye kaydını birden çok kişi onaylayabilir. Bu bilgi, onay sürecini ayrıntılı biçimde analiz etmek için gereklidir. Farklı onaylayanların iş yükünü ölçmeye, bireysel onay sürelerini hesaplamaya ve onay zincirindeki darboğazları belirlemeye yardımcı olur. Kullanıcı etkinliği ve işlem hacmi Dashboardunu doğrudan destekler. Neden önemli? Onaydan sorumlu kişiyi belirleyerek onay iş yükünü, performansı ve darboğazları analiz etmeyi sağlar. Nereden alınır? Onay adımını kimin gerçekleştirdiği izlenerek iş akışı günlüklerinden (ör. SWW_WI2OBJ, SWWLOG) veya değişiklik belgesi tablolarından (CDHDR/CDPOS) alınır. Örnekler DMILLERFWHITEKCHEN | |||
| Son veri güncellemesi LastDataUpdate | Bu kayıt için verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, kaynak sistemden yapılan en son veri çıkarımının veya güncellemesinin tarih ve saatini kaydeder. Analiz edilen verilerin ne kadar güncel olduğunu gösterir. Son güncelleme zamanını bilmek, süreç analizinin güncelliğini anlamak açısından önemlidir. Kullanıcıların Dashboardları ve KPI’ları doğru yorumlamasına yardımcı olur; böylece verilerin neredeyse gerçek zamanlı mı yoksa önceki bir döneme ait anlık görüntü mü olduğunu görebilirler. Neden önemli? Verilerin güncelliğini göstererek kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasını sağlar. Nereden alınır? Bu bir meta veri özniteliğidir. Genellikle veri alım hattı sırasında oluşturulur ve her kayda eklenir. Örnekler 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Ters kayıt nedeni ReversalReason | Kaydedilmiş bir yevmiye kaydının neden ters kaydedildiğini belirten kod. | ||
| Açıklama Kaydedilmiş bir yevmiye kaydı hatalıysa silinemez; yeni bir belgeyle ters kayıt yapılması gerekir. Ters kayıt nedeni kodu, yanlış kayıt tarihi veya tutar gibi bu işlemin nedenini açıklar. Ters kayıt nedenlerini analiz etmek, Kayıttan Raporlamaya sürecindeki hataların temel nedenlerini belirlemeye yardımcı olur. Belirli bir nedenin sık görülmesi, ilk seferde doğru sonuç alma oranını artırmak için ele alınması gereken yetersiz eğitim veya kontrol eksiklikleri gibi sistemik sorunlara işaret edebilir. Neden önemli? Ters kayıtlara yol açan hataların temel nedenini bulmaya yardımcı olur; yeniden çalışmayı azaltmak ve süreç kalitesini artırmak için gereken içgörüleri sağlar. Nereden alınır? SAP S/4HANA tablosu BKPF, STGRD alanı (Ters kayıt nedeni). Örnekler 010205 | |||
| Yeniden çalışma yapıldı mı IsRework | Yevmiye kaydının reddedildikten sonra düzeltilmesi gibi yeniden çalışma gerektirip gerektirmediğini belirten bir boole işareti. | ||
| Açıklama Bu hesaplanan öznitelik, ideal süreç yolundan sapan yevmiye kayıtlarını işaretler. Vaka içinde Yevmiye kaydı reddedildi veya Yevmiye kaydı düzeltildi gibi bir etkinlik gerçekleştiğinde genellikle true olarak ayarlanır. Bu işaret, süreç verimliliğini analiz etmeyi kolaylaştırır. Yeniden çalışma oranı KPI’ının hızlıca hesaplanmasını ve yeniden çalışma yapılan vakalarla yapılmayan vakaların çevrim süreleri ve maliyetlerinin doğrudan karşılaştırılmasını sağlar. Yeniden çalışmaya yol açan etkenleri belirlemek, birçok süreç iyileştirme çalışmasının temel hedefidir. Neden önemli? Düzeltme veya ek işlem döngüsü gerektiren vakaları işaretleyerek süreç verimsizliklerini kolayca ölçmeyi ve temel nedenlerini analiz etmeyi sağlar. Nereden alınır? Bu, vakadaki etkinlik sırasından türetilen hesaplanmış bir özniteliktir. Yevmiye kaydı reddedildi gibi bir etkinlik varsa true olarak işaretlenir. Örnekler truefalse | |||
Kayıttan Raporlamaya - Yevmiye kaydı etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Yevmiye kaydı incelemeye gönderildi | Yevmiye kaydını oluşturan kişi, belgeyi inceleme ve onay iş akışına resmen gönderir. Bu etkinlik, veri girişinden resmi kontrol sürecine devir teslimi gösterir ve onay döngüsünü başlatır. | ||
| Neden önemli? Bu, onay döngüsü süresinin başlangıcıdır. Bu noktadan son onay veya ret kararına kadar geçen süreyi ölçmek, özellikle inceleme ve onay aşamalarındaki darboğazları belirlemeye yardımcı olur. Nereden alınır? Bu bilgi genellikle iş nesnesine bağlı iş akışı günlüklerinden (SWW_WIHEAD, SWWLOG) alınır. Belge başlığındaki (BKPF) özel bir alanın durum değişikliğinden de çıkarılabilir. Kaydedin İş akışı öğesinin oluşturulma zaman damgasını veya durum alanının 'Gönderildi' ya da 'İnceleniyor' olarak değiştiği zamanı kullanın. Olay türü inferred | |||
| Yevmiye kaydı kapatıldı | Yevmiye kaydındaki açık bir kalem, faturayı kapatan ödeme gibi başka bir kayıtla mahsuplaştırılır. Bu etkinlik, belirli kalemlerin mutabakatını ve kapatılmasını gösterir. | ||
| Neden önemli? Bu etkinlik, özellikle geçici hesapları veya açık kalem yönetimli hesapları içeren birçok yevmiye kaydı için son mutabakat adımını gösterir. Kayıt işleminden kapatmaya kadar geçen süreyi analiz etmek, mutabakat verimliliğini ölçmeye yardımcı olur. Nereden alınır? Bu olay, kalem tablosundaki (BSEG veya ACDOCA görünümü) verilerden çıkarılır. Bir kalem kapatıldığında, o kaleme ait Kapatma Tarihi (AUGDT) ve Kapatma Belgesi (AUGBL) alanları doldurulur. Kaydedin Olayın zaman damgası olarak kalem için kapatma tarihini (BSEG-AUGDT) kullanın. Olay türü inferred | |||
| Yevmiye kaydı oluşturuldu | Bu etkinlik, sistemde yevmiye kaydı belgesinin ilk kez oluşturulduğunu gösterir. Kayıt başlık tablosuna (BKPF) eklenmiştir ancak henüz ana deftere işlenmemiştir. Yevmiye kaydı yaşam döngüsü bu noktada başlar. | ||
| Neden önemli? Bu, sürecin temel başlangıç olayıdır. Genel çevrim süresini ölçmek ve ilk veri girişi gecikmelerini belirlemek için bu olaydan kaydın sisteme işlenmesine kadar geçen süreyi analiz etmek önemlidir. Nereden alınır? Bu olay, belirli bir belge numarası (BELNR) için oluşturma tarihi (CPUDT) ve oluşturma saati (CPUTM) alanları kullanılarak SAP BKPF tablosundan doğrudan alınabilir. Kaydedin Olayın zaman damgası için BKPF-CPUDT ve BKPF-CPUTM alanlarını kullanın. Olay türü explicit | |||
| Yevmiye kaydı onaylandı | Yetkili bir yönetici yevmiye kaydına son onayı vererek kaydın geçerliliğini ve doğruluğunu teyit eder. Bu etkinlik, belgenin ana deftere işlenmesinden önceki son kontrol adımıdır. | ||
| Neden önemli? Bu önemli kilometre taşı, onay döngüsünü tamamlar. Bu adıma ulaşmak için geçen süre, genel süreç süresinin önemli bir bölümünü oluşturur ve onaylayanların verimliliğini gösterir. Nereden alınır? Bu olay, son onay adımını gösteren iş akışı günlüğünden veya belgedeki durum değişikliğinden çıkarılır. Onaylayanın kullanıcı kimliği ve zaman damgası, iş akışı verilerinden ya da değişiklik günlüklerinden alınabilir. Kaydedin İş akışı günlüklerindeki son onay adımının zaman damgasını veya değişiklik belgelerinde durumun 'Onaylandı' olarak değiştiği zamanı belirleyin. Olay türü inferred | |||
| Yevmiye kaydı sisteme işlendi | Yevmiye kaydı ana deftere resmen kaydedilir ve şirketin finansal tablolarını etkiler. Bu noktada belge kalıcı bir finansal kayıt haline gelir. | ||
| Neden önemli? Bu, temel başarı kilometre taşıdır ve ana işlem döngüsünün sona erdiğini gösterir. Sisteme işlenen kayıtların işlem hacmini ve bu aşamaya ulaşma süresini analiz etmek, Process Mining metriklerinin temelini oluşturur. Nereden alınır? Bu, BKPF tablosundaki Kayıt Tarihi (BUDAT) ile işaretlenen açık bir olaydır. Sisteme işlenmiş bir belgenin belge durumu (BSTAT) boştur; bu sayede belge, beklemeye alınmış ('V') veya bekletilen ('D') belgelerden ayırt edilir. Kaydedin Olayın zaman damgası için Kayıt Tarihi (BKPF-BUDAT) ve Giriş Tarihi (BKPF-CPUDT) alanlarını kullanın. BKPF-BSTAT alanının boş olması, belgenin sisteme işlendiğini gösterir. Olay türü explicit | |||
| Yevmiye kaydının ters kaydı işlendi | Daha önce sisteme işlenmiş bir yevmiye kaydı, ters kayıtlar içeren yeni bir belge oluşturularak iptal edilir. Bu işlem, sisteme işlenmiş belgelerdeki hataları düzeltmek için yapılır ve açıkça izlenebilir. | ||
| Neden önemli? Ters kayıtlar, sisteme işlenmiş bir belgede hata yapıldığını gösterir. Ters kayıt oranının yüksek olması, onay sürecinde veya veri giriş kalitesinde altta yatan sorunlara işaret eder. Bu oranı izlemek, kayıtların ilk seferde doğru olmasını sağlamaya yardımcı olur. Nereden alınır? Ters kayıt açık bir olaydır. Ters kayıt belgesinin başlığında (BKPF), Ters Kaydı Alınan Belge No. (STBLG) alanında özgün belgeye referans bulunur. Olay zamanı, yeni belgenin kayıt tarihidir. Kaydedin BKPF-STBLG alanı dolu olan belgeleri belirleyin. Olayın zaman damgası, ters kayıt belgesinin kayıt tarihidir. Olay türü explicit | |||
| Destekleyici belgeler eklendi | Kullanıcı, yevmiye kaydına fatura veya elektronik tablo gibi bir ya da daha fazla destekleyici belge ekler. Bu belgeler genellikle inceleme ve denetim sırasında finansal işleme ilişkin kanıt ve bağlam sunmak için eklenir. | ||
| Neden önemli? İnceleme başlamadan önce belgelerin eklenmesini sağlamak, uyumluluk ve onay sürecinin verimliliği açısından önemlidir. Bu etkinlik, belge politikalarına uyumu ve belgelerin onay döngüsü sürelerine etkisini ölçmeye yardımcı olur. Nereden alınır? Bu etkinlik genellikle Generic Object Services (GOS) üzerinden bağlanan eklerin oluşturulma zaman damgası kontrol edilerek belirlenir. SRGBTBREL tablosu, iş nesnesini (ör. BKPF belgesi) eke bağlar. Kaydedin BKPF nesnesine bağlantıları bulmak için GOS ek tablolarını (ör. SRGBTBREL) sorgulayın ve ekin oluşturulma zaman damgasını kullanın. Olay türü inferred | |||
| Manuel kayıt işlemi belirlendi | Yevmiye kaydı, otomatik bir arayüz veya toplu iş yerine manuel işlem kodu kullanılarak sisteme işlenmiştir. Bu, zamana bağlı bir olay değil, kayıt işleminin sınıflandırmasıdır. | ||
| Neden önemli? Manuel kayıt işlemlerini belirlemek, otomasyon çalışmaları açısından önemlidir. Manuel kayıt oranının yüksek olması, alt sistemleri entegre ederek veya otomatik kayıt programları kullanarak süreçleri kolaylaştırma fırsatlarına işaret eder. Nereden alınır? Bu sınıflandırma, belge başlık tablosundaki (BKPF) işlem kodu (TCODE) alanı analiz edilerek yapılır. Kaydı sınıflandırmak için bilinen manuel işlem kodlarının (ör. FB01, F-02, FB50) listesi kullanılır. Kaydedin Olayı, kayıt işlemi sırasında BKPF-TCODE değerini önceden tanımlanmış manuel işlem kodları listesiyle karşılaştırarak sınıflandırın. Olay türü calculated | |||
| Yevmiye kaydı beklemeye alındı | Kullanıcı, eksik bir yevmiye kaydını sisteme işlemeden kaydeder; böylece kayıt daha sonra tamamlanabilir veya incelenebilir. Bu açık bir işlemdir: belge başlık kaydı oluşturulur ve belge sisteme işlenmemiş durumda tutulur. | ||
| Neden önemli? Beklemeye alma, gönderim öncesinde sık kullanılan bir adımdır. Bekleme süresini izlemek, resmi inceleme ve onay süreci başlamadan önce verilerin tamamlanması ve hazırlanmasındaki gecikmeleri belirlemeye yardımcı olur. Nereden alınır? BKPF tablosunda beklemeye alınmış bir belge, belge durumu alanındaki (BSTAT) 'V' değeriyle belirlenir. Olayın zaman damgası oluşturma tarihidir (CPUDT). Kaydedin Oluşturulma anında BKPF-BSTAT = 'V' olan belgeleri filtreleyin. Olay türü explicit | |||
| Yevmiye kaydı düzeltildi | Kullanıcı, yevmiye kaydı reddedildikten veya değişiklik için geri gönderildikten sonra kaydı düzenler. Bu etkinlik, yeniden gönderimden önce inceleme sırasında belirlenen sorunları gidermek için gereken yeniden çalışma çabasını gösterir. | ||
| Neden önemli? Bu etkinlik, yeniden çalışma döngülerini ölçer. Düzeltmelerin sıklığını ve süresini analiz etmek, verimsizlik kaynaklarını belirlemeye ve eğitim ya da süreç açıklığı için fırsatları ortaya çıkarmaya yardımcı olur. Nereden alınır? Bu bilgi, daha önce 'Reddedildi' durumunda olan bir belgenin BKPF tablosundaki 'Son Değişiklik Tarihi' (AEDAT) izlenerek çıkarılabilir. Değişiklik belgeleri, nelerin değiştirildiğine ilişkin daha ayrıntılı bilgi sunar. Kaydedin Ret olayından sonra yapılan değişiklikler için değişiklik belgesi başlıklarındaki (CDHDR-UDATE) zaman damgasını kullanın. Olay türü inferred | |||
| Yevmiye kaydı reddedildi | İncelemeyi yapan veya onaylayan kişi yevmiye kaydını reddeder ve kaydın sisteme işlenmesini engeller. Belge genellikle düzeltme için kaydı oluşturan kişiye geri gönderilir ve yeniden çalışma döngüsü başlar. | ||
| Neden önemli? Retleri izlemek, süreç kalitesini anlamak ve yaygın hataları belirlemek açısından önemlidir. Yüksek ret oranları; veri doğruluğu, politikaların anlaşılması veya destekleyici belgelerin yeterliliğiyle ilgili sorunlara işaret eder. Nereden alınır? Bu olay, iş akışı günlüğündeki veya yevmiye kaydı belgesinin özel durum alanındaki değişiklikten çıkarılır. İlgili durum alanına ait değişiklik belgeleri (CDHDR/CDPOS) zaman damgasını sağlayabilir. Kaydedin Değişiklik belgeleri (CDHDR/CDPOS) veya iş akışı günlükleri üzerinden durum alanının 'Reddedildi' olarak değiştiği zamanı belirleyin. Olay türü inferred | |||
| Yevmiye kaydı sisteme işlendikten sonra değiştirildi | Kullanıcı, yevmiye kaydı ana deftere işlendikten sonra sınırlı sayıdaki alanı değiştirir. Finansal verilerin çoğu kayıt işleminden sonra değiştirilemese de metin veya atama gibi bazı alanlar düzenlenebilir. | ||
| Neden önemli? Bu etkinlik, uyumluluk açısından önemli bir uyarıdır. Kayıt işleminden sonra yapılan değişiklikler, kayıtları değiştirme girişimlerine işaret edebilir. Dolandırıcılığı önlemek ve veri bütünlüğünü korumak için yakından izlenmelidir. Nereden alınır? Bu durum, değişiklik belgesi tablolarından (CDHDR ve CDPOS) güvenilir biçimde çıkarılabilir. Belge numarasına ait CDHDR kaydındaki değişiklik tarihi, kayıt tarihinden sonraysa belge sisteme işlendikten sonra değiştirilmiştir. Kaydedin Değişiklik zaman damgasının (UDATE/UTIME) belgenin kayıt tarihinden (BKPF-BUDAT) sonra olduğu CDHDR kayıtlarını bulun. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşullar ve erişim: SAP S/4HANA’nın temel veritabanını sorgulamak veya ABAP raporları çalıştırmak için gerekli yetkilere sahip bir kullanıcı bulunduğundan emin olun. I_JournalEntry ve I_JournalEntryItem CDS View’ları ile CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ ve SWWLOGHIST tablolarına okuma erişiminiz olmalıdır. Erişim genellikle SAP HANA Studio veya DBeaver gibi bir veritabanı istemcisi ya da Eclipse için SAP ABAP Development Tools (ADT) üzerinden sağlanır.
- Sisteme özgü yapılandırmaları belirleyin: Sorguyu çalıştırmadan önce yevmiye kaydı onay iş akışınızda kullanılan görev kodlarını belirleyin. Gönderim, ret ve onay etkinliklerine karşılık gelen görev kimliklerini (ör. TS12345678) öğrenmek için SAP iş akışı yöneticinize danışın. Son sorgudaki yer tutucuları doldurmak için bu kimlikler gerekir.
- SQL sorgusunu hazırlayın:
querybölümünde verilen SQL sorgusunun tamamını seçtiğiniz SQL istemcisine veya geliştirme aracına kopyalayın. - Sorgu parametrelerini ayarlayın: Sorgudaki yer tutucuları bulun ve kendi değerlerinizle değiştirin.
[YourCompanyCode],[StartDate]ve[EndDate]parametrelerini ayarlayın. Ayrıca iş akışı görev kimliği yer tutucularını ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) önceki adımda belirlediğiniz değerlerle değiştirin. - Veri çıkarma sorgusunu çalıştırın: Düzenlediğiniz SQL sorgusunu SAP S/4HANA veritabanında çalıştırın. Tarih aralığına ve veri hacmine bağlı olarak sorgunun tamamlanması uzun sürebilir. Sorguyu yoğun olmayan saatlerde çalıştırmanız önerilir.
- İlk sonuçları inceleyin: Sorgu tamamlandığında JournalEntryId, ActivityName ve EventTime gibi sütunların beklendiği gibi dolu olduğunu doğrulamak için çıktının ilk birkaç satırını inceleyin. Sonuç kümesinde, yevmiye kaydının yaşam döngüsündeki her farklı iş olayı için bir satır bulunmalıdır.
- Verileri CSV olarak dışa aktarın: Sonuç kümesinin tamamını SQL aracınızdan tek bir CSV dosyasına aktarın. Özel karakterlerle ilgili sorun yaşamamak için dosyanın UTF-8 kodlamasını kullandığından emin olun.
- Yüklemeye hazırlanın: Dosyayı bir Process Mining aracına yüklemeden önce CSV dosyasında gerekli başlıkların bulunduğunu doğrulayın. Veriler zaten Event Log biçiminde düzenlenmiştir; bu nedenle başka bir dönüştürme veya pivot işlemi gerekmemelidir.
Yapılandırma
- Core Data Services (CDS) View’ları: Veri çıkarma işlemi, başlık verileri için çoğunlukla
I_JournalEntry, kalem ve tutar ayrıntıları içinI_JournalEntryItemkullanır. Bu View’lar, evrensel yevmiye defterine (ACDOCA) sadeleştirilmiş ve anlamsal açıdan zengin bir arayüz sunar. - Destekleyici tablolar: Sürecin tamamını görebilmek için sorgu, standart SAP tablolarından birkaçını daha birleştirir:
- Belgelerdeki değişiklikleri izlemek için
CDHDRveCDPOS. - Generic Object Services (GOS) üzerinden eklerin ne zaman bağlandığını belirlemek için
SRGBRELveSOOD. - Onay iş akışındaki önemli olayları çıkarmak için
SWW_WI2OBJveSWWLOGHIST.
- Belgelerdeki değişiklikleri izlemek için
- Tarih aralığı filtresi: Performansı yönetmek için verileri belirli bir tarih aralığıyla filtrelemek önemlidir.
WHEREkoşulundaI_JournalEntry.CreationDateTimealanını kullanın. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Kuruluş filtresi: Veri çıkarmayı ilgili tüzel kişilerle sınırlamak için her zaman
CompanyCodefiltresini kullanın. Büyük bir sistemde tüm şirket kodlarını tek seferde sorgulamak, işlemin çok uzun sürmesine neden olabilir. - İş akışı görev kimlikleri: Sorguda iş akışı görev kimlikleri için yer tutucular bulunur (ör.
[Workflow Approved Task ID]). Bunlar her SAP kurulumunda farklıdır ve iş akışı etkinliklerinin çıkarılması için doğru şekilde yapılandırılmalıdır. Bu kimlikler olmadan gönderim, onay veya ret olayları kaydedilmez. - Ön koşullar: Sorguyu çalıştıran kullanıcının finans, sistem ve iş akışı tabloları için kapsamlı okuma yetkileri olmalıdır. Bu izinler standart olarak verilmez, ayrıca tanımlanmaları gerekir.
Örnek sorgu sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Adımlar
- SAP HANA veritabanına doğrudan SQL erişiminin onaylandığını ve veri çıkarma kullanıcısının BKPF ile ACDOCA tablolarını, ayrıca sisteminizin gerektirdiği yapılandırılmış iş akışı, ek, değişiklik geçmişi, mahsuplaşma veya ters kayıt kaynaklarını okuma yetkisi bulunduğunu doğrulayın. Veritabanına doğrudan erişim genellikle SAP HANA Database Explorer, SAP HANA Studio veya onaylı bir SQL istemcisiyle sağlanır. Sisteminiz bu erişimi açıkça desteklemiyorsa, veri çıkarma sorgularını SAP uygulama işlemi içinde çalıştırmayın.
- İstemci alanı, şirket kodu alanı, mali yıl alanı, belge numarası alanı, belge türü alanı, kayıt tarihi alanı, oluşturma tarihi alanı, oluşturma saati alanı, kullanıcı alanı, yerel para birimi tutar alanı ve varsa ters kayıt veya mahsuplaşma alanları dahil olmak üzere BKPF ve ACDOCA tablolarının fiziksel şemasını doğrulayın. SAP S/4HANA kurulumlarında şema ve alan kullanılabilirliği değişebilir. Bu nedenle sorgudaki köşeli parantezli yer tutucuları sisteminizde doğruladığınız alanlarla değiştirin.
- İş akışı ve ek olayları için yetkili kaynakları belirleyin. BKPF ve ACDOCA muhasebe belgesi ve kalem verilerini sağlar; ancak beklemeye alınma, gönderim, ret, düzeltme, onay veya ek olaylarının tümünü tek başlarına güvenilir biçimde göstermez. Köşeli parantezli iş akışı ve ek kaynağı yer tutucularını uygulamanızda onaylanmış View veya tablolarla değiştirin. Bir kaynak kullanılamıyorsa olay uydurmayın. İlgili kaynağı yapılandırın veya etkinliği belgelenmiş onayla kapsam dışında bırakın.
- Gerekli tarih aralığı, şirket kodları, belge türleri ve istemci için veri çıkarma parametrelerini ayarlayın. İlk doğrulama için üç ila altı aylık bir aralık önerilir. Üzerinde anlaşılmış süreç kapsamına göre operasyonel olaylar için olay zaman damgası aralığını, muhasebe olayları içinse kayıt tarihi aralığını kullanın.
- SQL sorgusunun tamamını onaylı HANA SQL istemcisinde çalıştırın. Sorgu, açıkça çıkarılan her etkinlik için bir olay satırı oluşturur. Muhasebe olayları için BKPF ve ACDOCA’yı, iş akışı, ek, değişiklik, mahsuplaşma ve ters kayıt olayları için yapılandırılmış kaynak View’larını kullanır. Bir belgenin varlığından hareketle etkinlik çıkarımı yapmaz.
- Çıktı şemasını inceleyin. JournalEntryId vaka kimliğidir, ActivityName etkinlik etiketidir, EventTime ise olay zaman damgasıdır. Önerilen iş öznitelikleri de mevcut olduklarında sonuçta yer alır. EventTime alanının zaman damgası olduğunu ve tüm satırlarda JournalEntryId ile ActivityName alanlarının boş olmadığını doğrulayın.
- Seçilen istemci, şirket kodları, mali yıllar ve tarih aralığı için farklı JournalEntryId değerlerini beklenen BKPF kayıtlarıyla karşılaştırarak muhasebe kapsamını mutabık hale getirin. Saklama süreleri ve zaman damgası kuralları muhasebe verilerinden farklı olabileceğinden iş akışı ve ek kayıtlarını ayrı ayrı mutabık hale getirin.
- Olay sıralamasını ve yinelenen kayıt davranışını doğrulayın. Süreç tasarımı kalem düzeyinde olayları özellikle gerektirmiyorsa ACDOCA’daki birden fazla kalem yinelenen muhasebe olayları oluşturmamalıdır. Her yevmiye kaydı ve olay türü için tek bir muhasebe olayı oluşturmak üzere sorgudaki toplama mantığını kullanın; mevcut olduğunda yapılandırılmış kaynak olay kimliklerini koruyun.
- Sonucu UTF-8 CSV veya ProcessMind’in desteklediği başka bir tablo biçiminde dışa aktarın. JournalEntryId, ActivityName ve EventTime sütun adlarını aynen koruyun. Dosyayı JournalEntryId ve EventTime alanlarına göre sıralayın, ek öznitelikleri sütun olarak tutun. Dosyayı ProcessMind’e yükleyin ve JournalEntryId’yi vaka kimliği, ActivityName’i etkinlik, EventTime’ı olay zaman damgası olarak yapılandırın.
Yapılandırma
- Tarih aralığı: Üç ila altı aylık bir aralıkla başlayın. Performans testi için daha kısa bir aralık kullanın; satır sayısını ve olay kapsamını doğruladıktan sonra aralığı genişletin.
- İstemci ve şirket kapsamı: [Client parameter] değerini ayarlayın ve CompanyCode alanını gerekli tüzel kişilerle sınırlandırın. Birden fazla istemcili sistemlerde istemci koşulunu atlamayın.
- Muhasebe kapsamı: [Document type filter] değerini ve uygun olduğunda mali yıl ile kayıt tarihi filtrelerini yapılandırın. Seçilen kaynak bu belgeleri güvenilir biçimde temsil ediyorsa kaydedilmiş ve kaydedilmemiş belgeleri birlikte dahil edin.
- İş akışı kapsamı: Gönderim, ret, düzeltme ve onay etkinlikleri için [Workflow event source] kaynağını ve olay türü eşlemelerini yapılandırın. Zaman damgalarının iş akışı eyleminin oluşturulma, yürütülme veya tamamlanma zamanını gösterdiğini doğrulayın.
- Ek kapsamı: [Attachment event source] kaynağını ve eki yevmiye kaydına bağlayan ilişki alanını yapılandırın. Kaynağın ek oluşturma, değiştirme veya silme işlemlerini kaydedip kaydetmediğini doğrulayın.
- Değişiklik kapsamı: Kayıt sonrasındaki değişiklikler için [Change history source] kaynağını yapılandırın. Kaynağın yevmiye kaydını tanımladığını ve güvenilir bir değişiklik zaman damgası sağladığını doğrulayın.
- Mahsuplaşma kapsamı: [Clearing source] kaynağını ve mahsuplaşan muhasebe belgesiyle mahsuplaşma belgesi arasındaki ilişkiyi yapılandırın. Olayın asıl yevmiye kaydına mı, mahsuplaşma belgesine mi, yoksa her ikisine mi atanacağına karar verin.
- Ters kayıt kapsamı: [Reversal source] kaynağını ve asıl belgeyle ters kayıt belgesi arasındaki ilişkiyi yapılandırın. Bu ilişki mevcutsa sorgu, ters kayıt etkinliğini asıl JournalEntryId değerine atar.
- Manuel kayıt sınıflandırması: [Manual posting source] kaynağını veya doğrulanmış bir kayıt kaynağı alanını yapılandırın. Manual Posting Identified bir sınıflandırma olayıdır; kayıt zaman damgasını veya onaylanmış başka bir zaman damgasını tutarlı biçimde kullanmalıdır.
- Para birimi tutarı: ACDOCA kalem düzeyinde çalışır. Sorgu, yerel para birimi tutarlarını yevmiye kaydı bazında toplar. İşaret kuralını ve istatistiksel, deftere özgü veya uzantı defteri satırlarının dahil edilip edilmeyeceğini doğrulayın.
- Performans: Yalnızca gerekli sütunları seçin, filtreleri erken uygulayın, ACDOCA üzerinde sınırsız taramalardan kaçının ve sorguyu onaylı raporlama saatlerinde çalıştırın. Desteklendiğinde istemci, mali yıl, şirket kodu ve kayıt tarihi koşullarıyla bölüm budamasından yararlanın.
- Yinelenen kayıtların işlenmesi: Mevcut olduğunda kaynak olay kimliklerini kullanın. Bir kaynakta yinelenen teknik kayıtlar bulunabiliyorsa, birbirinden ayrı iş akışı eylemlerini birleştirmeden belgelenmiş tekilleştirme kuralını uygulayın.
- Ön koşullar: Gerekli veritabanı yetkileri, onaylı SAP HANA bağlantısı, yapılandırılmış iş akışı ve ek kaynaklarına erişim, uygun SAP Financial Accounting ve iş akışı yapılandırması ve ProcessMind’in desteklediği bir dışa aktarma biçimi.
Örnek sorgu sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Adımlar
- ABAP programını oluşturun:
SE38işlem kodunu kullanarak ABAP Editor’ü açın. Yeni program için örneğinZ_PM_JE_EXTRACTadını girin ve 'Create' seçeneğine tıklayın. Uygun bir başlık girin, 'Type' alanını 'Executable Program' olarak ayarlayın ve programı yerel nesne olarak veya bir paket içinde kaydedin. - Seçim ekranını tanımlayın: Programda, kullanıcıların verileri filtrelemesini sağlayacak parametreleri ve seçim seçeneklerini tanımlayın. Yevmiye kaydının oluşturulma tarihi için bir tarih aralığı (
P_CPUDT_FR,P_CPUDT_TO), şirket kodu için bir seçim seçeneği (SO_BUKRS) ve uygulama sunucusundaki çıktı dosyasının yolu (P_FPATH) bulunmalıdır. - Veri yapılarını tanımlayın: Gerekli Event Log biçimiyle eşleşen bir dahili tablo yapısı tanımlayın. Bu yapı son çıktıyı tutar. Ayrıca BKPF, ACDOCA, CDHDR, CDPOS ve çeşitli iş akışı tabloları gibi verilerin seçileceği SAP tabloları için dahili tablolar ve çalışma alanları tanımlayın.
- Veri seçme mantığını uygulayın: Gerekli 12 etkinliğin her biri için temel ABAP mantığını yazın. Kodu düzenli tutmak için her etkinliğe ayrı bir alt yordam (FORM) oluşturun. Örneğin
get_created_events,get_parked_eventsveget_workflow_eventsFORM’larını oluşturun. - 'Created' ve 'Posted' olaylarını seçin: Kullanıcının seçim ekranındaki ölçütlere göre BKPF tablosundan veri okuyun. BKPF’deki bir kayıt, belgenin oluşturulduğunu gösterir.
BSTAT = ' 'durumundaki bir belge kaydedilmiş kabul edilir. Olay zamanı olarak oluşturulma zaman damgasını (CPUDT,CPUTM) kullanın. - 'Parked' olaylarını seçin: Beklemeye alınan belge başlıklarını tutan VBKPF tablosundan veri okuyun. Bu tablodaki oluşturulma zaman damgası, beklemeye alma olayını gösterir.
- 'Workflow' olaylarını seçin (Submitted, Approved, Rejected): Yevmiye kaydı nesnesini bir iş akışı örneğine bağlamak için SWW_WI2OBJ, belirli adımların ayrıntılarını ve zamanlarını almak içinse SWWLOGHIST veya SWWIHEAD gibi iş akışı tablolarını sorgulayın. Sisteminizde gönderim, onay ve ret için kullanılan iş akışı görev kimliklerini belirlemeniz gerekir.
- 'Change' ve 'Correction' olaylarını seçin:
OBJECTCLAS = 'BELEG'için değişiklik belgesi tabloları CDHDR (başlık) ve CDPOS’u (kalem) sorgulayın. 'Changed After Posting' için değişiklik zaman damgası belgenin kayıt tarihinden sonraysa bu değişiklikleri filtreleyin. 'Corrected' için beklemeye alınmış veya reddedilmiş belgelerdeki değişiklikleri filtreleyin. - 'Reversal' ve 'Cleared' olaylarını seçin: BKPF’deki
STBLGalanı (Ters Kaydedilen Belge No.) dolu olan belgeleri bularak ters kayıtları belirleyin. Ters kayıt olayının zamanı, ters kaydı oluşturan belgenin oluşturulma zamanıdır. Belirli bir yevmiye kaydının kalemleri için ACDOCA tablosundaki en son mahsuplaşma tarihini (AUGDT) seçerek mahsuplaşma olaylarını belirleyin. - Verileri birleştirin ve sıralayın: Her etkinliğin verilerini seçtikçe sonuçları ana dahili tabloya ekleyin. Tüm seçimler tamamlandıktan sonra her vaka için kronolojik sıralama sağlamak üzere ana tabloyu
JournalEntryIdveEventTimealanlarına göre sıralayın. - Çıktı dosyasını oluşturun: Sıralanmış son dahili tablonun içeriğini SAP uygulama sunucusunda belirtilen dosya yoluna yazmak için
OPEN DATASET,LOOP AT... TRANSFERveCLOSE DATASETifadelerini kullanın. Dosya, başlık satırı içeren CSV biçiminde olmalıdır. - Çalıştırmayı zamanlayın: Düzenli veri çıkarma işlemleri için
SM36işlem kodunu kullanarakZ_PM_JE_EXTRACTprogramını örneğin haftalık veya aylık bir takvimle çalıştıran bir arka plan işi oluşturun. Böylece veri dışa aktarma işlemi otomatikleşir.
Yapılandırma
- Tarih aralığı: Seçim ekranında yevmiye kaydının oluşturulma tarihi (
CPUDT) için zorunlu bir tarih aralığı bulunmalıdır. Performansı korumak için verileri 3-6 aylık yönetilebilir parçalar halinde çıkarmanız önerilir. - Şirket kodu (
BUKRS): Bu filtre, veri çıkarmayı Process Mining analiziyle ilgili belirli tüzel kişilerle sınırlandırmak için önemlidir. Tüm şirket kodlarını tek seferde çıkarmanız önerilmez. - Belge türü (
BLART): 'SA' (G/L Account Posting) veya 'KR' (Vendor Invoices) gibi belirli yevmiye kaydı türlerine odaklanmak için bu isteğe bağlı filtreyi ekleyebilirsiniz. Böylece veri hacmi azalır ve veri seti daha ilgili hale gelir. - Dosya yolu: Program, çıktı dosyasının yazılacağı SAP uygulama sunucusunda mantıksal bir dosya yolu gerektirir. Yolun geçerli olduğunu ve SAP sistem kullanıcısının ilgili dizine yazma yetkisi bulunduğunu doğrulayın. Sunucu dizinlerini yönetmek ve görüntülemek için
AL11işlemini kullanın. - İş akışı görev kimlikleri: İş akışı olaylarını (Submitted, Approved, Rejected) çıkarma mantığı, kuruluşunuzun yevmiye kaydı onay iş akışında kullanılan belirli görev kimlikleriyle yapılandırılmalıdır. Bu kimlikler genellikle özeldir ve bir iş akışı danışmanı veya geliştiricisi tarafından belirlenmelidir.
- Ön koşullar: Programı çalıştıran kullanıcı veya sistem hesabının ABAP programları oluşturmak ve çalıştırmak için geliştirici yetkileri (
S_DEVELOP) ile finans tablolarına (BKPF, ACDOCA), değişiklik günlüğü tablolarına (CDHDR, CDPOS) ve iş akışı tablolarına (SWW*) geniş okuma erişimi olmalıdır.
Örnek sorgu abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. Başlamaya hazır mısınız?
Verilerinizi güvenle hazırlamak ve Kayıttan Raporlamaya - Yevmiye kaydı süreciniz hakkında önemli içgörüler edinmek için bu Templateten yararlanın. Süreçlerinizi bugün iyileştirmeye başlayın.
En yüksek verimlilik için Kayıttan Raporlamaya yevmiye kaydı sürecini kolaylaştırın
Sürecinizi iyileştirin ve Kayıttan Raporlamaya yevmiye kaydı çevrim süresini %30 azaltın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.