Kayıttan Raporlamaya - Yevmiye Kaydı Veri Şablonunuz
Kayıttan Raporlamaya - Yevmiye Kaydı Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Oracle Fusion Financials için Veri Çıkarma Rehberliği
Kayıttan Raporlamaya - Yevmiye Kaydı Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Yevmiye kaydı sürecinde belirli bir zamanda meydana gelen özel iş olayı veya görevin adı. | ||
|
Açıklama
Faaliyet Adı, "Journal Entry Created" (Yevmiye Kaydı Oluşturuldu) veya "Journal Entry Approved" (Yevmiye Kaydı Onaylandı) gibi yevmiye kaydı yaşam döngüsü içindeki tek bir adımı tanımlar. Bu veri, süreç haritasını oluşturmak ve olayların sırasını anlamak için çok önemlidir. Faaliyetleri analiz etmek, standart yollar, sapmalar ve yeniden işleme döngüleri dahil olmak üzere süreç akışının belirlenmesine olanak tanır. Farklı faaliyetleri izleyerek, onay gibi belirli aşamalarda harcanan zamanı ölçebilir ve hangi adımların en çok zaman alan veya hataya açık olduğunu belirleyebiliriz.
Neden önemli
Sürecin adımlarını tanımlar, süreç haritasının temelini oluşturur ve akış, darboğazlar ve varyasyonların analizini sağlar.
Nereden alınır
Bu öznitelik tipik olarak, Genel Muhasebe modülündeki yevmiye kaydı nesneleriyle ilişkili durum değişikliklerinden, Event Log'lardan veya denetim izi tablolarından türetilir.
Örnekler
Yevmiye Kaydı OluşturulduOnay İçin Yevmiye GönderildiYevmiye Kaydı OnaylandıYevmiye Kaydı Deftere İşlendi
|
|||
|
Başlangıç Zamanı
EventTime
|
Belirli bir faaliyetin veya event'in ne zaman gerçekleştiğini gösteren zaman damgasıdır. | ||
|
Açıklama
Bu zaman damgası, bir faaliyetin tam olarak ne zaman gerçekleştirildiğini belirten tarih ve saati işaretler. Process Mining'de olayların sırasını belirlemek ve aralarındaki süreleri hesaplamak için kullanılan birincil zamansal öğedir. Olay Zamanı'nın doğruluğu, döngü sürelerini hesaplamak, darboğazları belirlemek ve hizmet seviyesi anlaşmalarına karşı performansı izlemek de dahil olmak üzere tüm zamana dayalı analizler için kritiktir. Süreç akışını olduğu gibi yeniden yapılandırmak için gereken kronolojik sırayı sağlar.
Neden önemli
Bu zaman damgası, olayları sıralamak, tüm süreç sürelerini hesaplamak ve zamana dayalı herhangi bir analiz yapmak için esastır.
Nereden alınır
Bu bilgi tipik olarak denetim izi tablolarında veya belirli olaylar için GL_JE_HEADERS ve GL_JE_LINES gibi işlem tablolarında 'Son Güncelleme Tarihi' veya 'Oluşturma Tarihi' olarak saklanır.
Örnekler
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
|
|||
|
Yevmiye Kaydı Kimliği
JournalEntryId
|
Tek bir yevmiye kaydı için tüm ilgili finansal işlem faaliyetlerini birbirine bağlayan benzersiz tanımlayıcı. | ||
|
Açıklama
Yevmiye Kaydı Kimliği, belirli bir finansal işlem kümesiyle ilgili tüm faaliyetleri benzersiz bir şekilde birbirine bağlayan birincil vaka tanımlayıcısı olarak hizmet eder. Bu, tek bir yevmiye kaydının başlangıcından nihai kayda kadar tüm yaşam döngüsünün izlenmesine olanak tanır ve tüm borç ve alacakların muhasebeleştirilmesini sağlar. Process Mining'de bu kimlik, her bir yevmiye kaydının uçtan uca yolculuğunu yeniden yapılandırmak için esastır. 'Journal Entry Created' (Yevmiye Kaydı Oluşturuldu), 'Journal Submitted For Approval' (Yevmiye Onay İçin Gönderildi) ve 'Journal Entry Posted' (Yevmiye Kaydı Kaydedildi) gibi farklı olayları tutarlı bir süreç akışına bağlar, döngü sürelerinin, darboğazların ve süreç varyasyonlarının analizine olanak tanır.
Neden önemli
Bu, bir yevmiye kaydını baştan sona izlemek için temel anahtardır ve her benzersiz vaka için tüm süreç akışını analiz etmeyi mümkün kılar.
Nereden alınır
Bu, GL_JE_HEADERS ve GL_JE_LINES gibi temel Genel Muhasebe tablolarında bulunan birincil bir anahtardır.
Örnekler
JE100523JE202311001882019
|
|||
|
Kaynak Sistem
SourceSystem
|
Verinin kaynaklandığı sistem veya modül. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin çıkarıldığı kaynak sistemi tanımlar. Karmaşık bir BT ortamında, veriler birden fazla entegre sistemden gelebilir ve bu alan bunları ayırt etmeye yardımcı olur. Süreç analizinde, kaynak sistemi bilmek, farklı sistem davranışlarından kaynaklanabilecek süreç varyasyonlarını anlamak için çok önemlidir. Ayrıca verileri kaynağına kadar izleyerek veri doğrulama ve sorun gidermede de yardımcı olur.
Neden önemli
Verinin kaynağını tanımlar; bu da veri yönetişimi, doğrulama ve farklı sistemler arasındaki süreç farklılıklarını anlamak için çok önemlidir.
Nereden alınır
Bu genellikle veri çıkarma sırasında yapılandırılan statik bir değerdir veya kaynak tablolarda giriş sistemini tanımlayan bir alan olabilir.
Örnekler
Oracle Fusion Financials CloudOracle EBS R12Fusion GL
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Kaynak sistemden en son veri yenileme veya çekme işleminin zaman damgasıdır. | ||
|
Açıklama
Bu öznitelik, veri kümesinin en son ne zaman güncellendiğini kaydeder. Analiz edilen verinin güncelliği hakkında bağlam sağlar ki bu, elde edilen içgörülerin alaka düzeyini anlamak için önemlidir. Herhangi bir analizde, özellikle operasyonel Dashboard'larda, Son Veri Güncelleme zamanını bilmek, kullanıcıların verilere güvenmesi ve bilinçli kararlar alması için kritiktir. Process Mining modeline dahil edilen veriler için kesme noktasını açıkça iletir.
Neden önemli
Verinin güncelliğini gösterir; kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamalarını ve içgörülere güvenmelerini sağlar.
Nereden alınır
Bu değer, veri çıkarma ve dönüştürme süreci sırasında oluşturulur ve depolanır. Tipik olarak ETL/ELT işinin tamamlandığı zaman damgasıdır.
Örnekler
2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
|
|||
|
Kullanıcı
UserName
|
Faaliyeti gerçekleştiren (örneğin, yevmiye kaydını oluşturan, onaylayan veya kaydeden) kullanıcı. | ||
|
Açıklama
Bu öznitelik, bir faaliyeti yürütmekten sorumlu belirli çalışanı veya sistem kullanıcısını tanımlar. İş yükü dağılımını, performansı anlamak ve bireysel darboğazları belirlemek için çok önemlidir. Analizde, UserName kullanıcıya göre süreçleri filtrelemeye, kullanıcı verimliliğini karşılaştırmaya ve gecikmelerin veya hataların nedenlerini araştırmaya olanak tanır. Doğrudan 'Ekipler Arası Kullanıcı İş Yükü ve Verimlilik' gibi Dashboard'ları ve 'Kullanıcı Yevmiye Darboğaz Endeksi' gibi KPI'ları destekler.
Neden önemli
Süreç adımları için sorumluluk atar; kullanıcı iş yükü, bireysel performans ve eğitim ihtiyaçlarının analiz edilmesini sağlar.
Nereden alınır
GL_JE_HEADERS gibi işlem tablolarında (örneğin CREATED_BY, LAST_UPDATED_BY) ve ilgili denetim izi (audit trail) tablolarında bulunur.
Örnekler
john.doesusan.smithautoprocess_user
|
|||
|
Kullanıcı Departmanı
UserDepartment
|
Faaliyeti gerçekleştiren kullanıcının ait olduğu departman veya ekip. | ||
|
Açıklama
Bu öznitelik, bir faaliyeti 'Finans', 'Muhasebe Operasyonları' veya 'İç Denetim' gibi belirli bir departmana bağlayarak kurumsal bağlam sağlar. Genellikle kullanıcı ana verilerinden türetilir. Kullanıcı Departmanı'na göre analiz yapmak, departmanlar arası darboğazları belirlemeye, ekip performansını karşılaştırmaya ve süreç yürütmesinin kuruluş genelinde nasıl farklılık gösterdiğini anlamaya yardımcı olur. Kaynak tahsisi ve hedeflenmiş süreç iyileştirme girişimleri için değerlidir.
Neden önemli
Kurumsal bağlam sağlar, ekip veya departman bazında performans analizi yapılmasına olanak tanır ve çapraz fonksiyonel verimsizlikleri vurgular.
Nereden alınır
Bu tipik olarak işlem tablolarında bulunmaz. UserName'in bir kullanıcı ana veri tablosu veya İK sistemi verileriyle birleştirilmesiyle kaynaklanması gerekir.
Örnekler
Genel MuhasebeFinansal RaporlamaSatıcı Ödemeleri
|
|||
|
Ret Nedeni
RejectionReason
|
Bir yevmiye kaydının neden reddedildiğini açıklayan metinsel bir açıklama veya kod. | ||
|
Açıklama
Bir yevmiye kaydı onay süreci sırasında reddedildiğinde, bu öznitelik reddetme nedenini yakalar. Bu, önceden tanımlanmış bir kod veya onaylayıcıdan serbest metin yorumu olabilir. Bu, süreç verimsizliklerinin temel neden analizi için en önemli özniteliklerden biridir. En yaygın ret nedenlerini analiz ederek, kuruluşlar hazırlayıcılar için daha iyi eğitim, daha net yönergeler veya sistem kontrol geliştirmeleri gibi iyileştirme alanlarını belirleyebilir. Doğrudan 'Yevmiye Kaydı Ret Oranı Analizi' Dashboard'unu destekler.
Neden önemli
Yeniden işleme ve süreç gecikmelerinin temel nedenlerine doğrudan içgörü sunarak, ret oranlarını azaltmak için hedeflenmiş iyileştirmeler yapılmasına olanak tanır.
Nereden alınır
Bu bilgi, onay süreciyle ilişkili iş akışı veya denetim izi tablolarında veya yevmiye başlığındaki bir notlar alanında saklanabilir.
Örnekler
Yanlış Hesap KombinasyonuYetersiz Destekleyici BelgeBütçeyi aşıyor
|
|||
|
Yevmiye Kategorisi
JournalCategory
|
Yevmiye kaydının kategorisi; örneğin 'Tahakkuk', 'Düzeltme' veya 'Yeniden Sınıflandırma'. | ||
|
Açıklama
Yevmiye Kategorisi, girişleri iş amaçlarına göre sınıflandırır. Bu sınıflandırma, farklı kategorilerin farklı süreç akışlarına, onay kurallarına veya döngü sürelerine sahip olabileceği için sürecin daha ayrıntılı analizine olanak tanır. Örneğin, ay sonu düzeltme yevmiyeleri, rutin tahakkuklardan daha karmaşık ve acil bir sürece sahip olabilir. Süreci kategoriye göre analiz etmek, bu farklılıkları ortaya çıkarmaya ve iyileştirmeleri belirli yevmiye kaydı türlerine uyarlamaya yardımcı olur.
Neden önemli
Süreci, yevmiyenin iş amacına göre bölümlere ayırmaya olanak tanır; farklı giriş türleri için farklı davranışlar ve performanslar ortaya çıkarır.
Nereden alınır
GL_JE_HEADERS tablosunda, genellikle JE_CATEGORY adlı bir alanda mevcuttur.
Örnekler
TahakkukManuelDüzeltmeYeniden Değerleme
|
|||
|
Yevmiye Kaynağı
JournalSource
|
Yevmiye kaydını oluşturan alt defter veya kaynak; örneğin 'Borçlar', 'Alacaklar' veya 'Manuel'. | ||
|
Açıklama
Bu öznitelik, ERP sistemi içindeki yevmiye kaydının kaynağını belirtir. Kayıtlar Genel Muhasebe'de manuel olarak oluşturulabilir veya Borçlar, Alacaklar veya Duran Varlıklar gibi alt defterlerden otomatik olarak üretilebilir. Yevmiye Kaynağı, otomasyon analizi için anahtar bir özniteliktir. Manuel ve sistem tarafından oluşturulan kayıtlar arasında ayrım yapmaya yardımcı olarak 'Otomatik Yevmiye Kaydı Oranı' KPI'ını destekler. Farklı kaynaklardan gelen kayıtlar için süreçler, genellikle karmaşıklık ve verimlilik açısından önemli ölçüde farklılık gösterir.
Neden önemli
Manuel ve otomatik girişler arasında ayrım yapar, bu da otomasyon oranlarını ölçmek ve süreç farklılıklarını analiz etmek için kritiktir.
Nereden alınır
GL_JE_HEADERS tablosunda, genellikle JE_SOURCE adlı bir alanda mevcuttur.
Örnekler
ManuelBorçlarVarlıklarAlacaklar
|
|||
|
Yevmiye Tutarı
JournalAmount
|
Yevmiye kaydının toplam parasal değeri, tipik olarak borçların toplamı. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydında işlem gören toplam finansal değeri temsil eder. Tutar, süreci etkileyen önemli bir faktör olabilir. Örneğin, yüksek değerli kayıtlar ek onay adımları veya daha kapsamlı incelemeler gerektirebilir. Yevmiye Kaydı Tutarını analiz etmek, vakaların finansal etkiye göre segmentasyonuna olanak tanır. 'Yüksek değerli kayıtların onaylanması daha mı uzun sürer?' veya 'Belirli bir eşiğin üzerindeki kayıtlar için retler daha mı yaygındır?' gibi soruların yanıtlanmasına yardımcı olur. Bu, süreç akışına kritik iş bağlamı sağlar.
Neden önemli
Kritik iş bağlamı sağlar, finansal etkiye dayalı analiz yapılmasına olanak tanır ve yüksek değerli kayıtların farklı bir süreci takip edip etmediğini belirlemeye yardımcı olur.
Nereden alınır
Bu değer, tipik olarak belirli bir yevmiye kaydı için GL_JE_LINES tablosundaki borç veya alacakların toplamı olarak hesaplanır.
Örnekler
5000.00125000.75750.50
|
|||
|
Bitiş Saati
EndTime
|
Belirli bir etkinliğin ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Bitiş Zamanı, bir faaliyetin tamamlanmasını işaretler. Başlangıç Zamanı başlangıcı kaydederken, Bitiş Zamanı kapanış noktasını sağlayarak o belirli adım için işlem süresinin kesin olarak hesaplanmasına olanak tanır. Bu, darboğazları belirlemek ve kaynak verimliliğini ölçmek için temel bir metrik olan faaliyet işlem sürelerini hesaplamak için çok önemlidir. Örneğin, 'Journal Entry Reviewed' (Yevmiye Kaydı İncelendi) faaliyetinin Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark, bir inceleyicinin görev üzerinde harcadığı gerçek zamanı verir.
Neden önemli
Bireysel aktivitelerin gerçek süresinin veya işlem süresinin hesaplanmasını sağlar; ki bu verimlilik sorunlarını belirlemek için anahtardır.
Nereden alınır
Başlangıç Zamanı'na benzer şekilde, bu genellikle denetim izi tablolarında bulunur veya süreçteki sonraki faaliyetin Başlangıç Zamanı'ndan çıkarılabilir.
Örnekler
2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
|
|||
|
Defter Adı
LedgerName
|
Yevmiye kaydının kaydedildiği genel muhasebe defterinin adı. | ||
|
Açıklama
Defter Adı, yevmiye kaydının ait olduğu belirli defteri tanımlar. Birden fazla yasal varlığa veya raporlama gereksinimine sahip kuruluşlarda, kurumsal muhasebe için birincil defter ve yerel yasal raporlama için ikincil defterler gibi birden fazla defter bulunabilir. Bu öznitelik, farklı yasal varlıklar veya iş birimleri arasında süreçleri filtrelemek ve karşılaştırmak için esastır. Analizlerin doğru kurumsal bağlamda yapılmasını sağlar ki bu, finansal uyumluluk ve raporlama için özellikle önemlidir.
Neden önemli
Süreç analizinin farklı yasal varlıklar veya muhasebe çerçeveleri arasında filtrelenmesini ve karşılaştırılmasını sağlar, bu da büyük kuruluşlar için hayati öneme sahiptir.
Nereden alınır
GL_JE_HEADERS tablosunda bulunur; genellikle isme ulaşmak için GL_LEDGERS ile birleştirilebilen (join) bir LEDGER_ID üzerinden bağlanır.
Örnekler
ABD Birincil DefteriBirleşik Krallık Yasal DefteriKüresel Konsolidasyon Defteri
|
|||
|
Deftere İşleme Durumu
PostingStatus
|
Yevmiye kaydının mevcut kayıt durumu; örneğin, 'Kaydedilmemiş' veya 'Kaydedildi'. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydının genel muhasebedeki kayıt durumuyla ilgili mevcut durumunu yansıtır. Özellikle devam eden vakalar için bir yevmiye kaydının yaşam döngüsünde nerede olduğunun anahtar bir göstergesidir. Kayıt Durumu, 'Gerçek Zamanlı Yevmiye Kaydı Durum Takipçisi' Dashboard'u için çok önemlidir ve tüm aktif kayıtların anlık görüntüsünü sağlar. Kaydedilmemiş yevmiye kaydı birikimlerini izlemeye ve sürecin son aşamalarındaki gecikmeleri belirlemeye yardımcı olur.
Neden önemli
Bir yevmiyenin mevcut durumunu gösterir; bu da birikmiş işleri izlemek ve devam eden girişlerin durumunu takip etmek için esastır.
Nereden alınır
GL_JE_HEADERS tablosunda, genellikle STATUS veya POSTING_STATUS gibi bir sütunda mevcuttur.
Örnekler
KaydedildiKaydedilmemişHata
|
|||
|
Hedef Kayıt Tarihi
TargetPostingDate
|
Yevmiye kaydının kaydedilmesi beklenen önceden belirlenmiş tarih. | ||
|
Açıklama
Hedef Kayıt Tarihi, bir yevmiye kaydının genel muhasebeye kaydedilmesi için son tarihi temsil eder ve genellikle hizmet seviyesi anlaşmaları (SLA'lar) veya ay sonu kapanış takvimleri tarafından belirlenir. Performansı ölçmek için bir kıyaslama noktası görevi görür. Bu öznitelik, 'Zamanında Yevmiye Kaydı Oranı' KPI'ını hesaplamak için esastır. Gerçek kayıt tarihini bu hedefle karşılaştırarak, sistem kayıtları otomatik olarak zamanında veya geç olarak işaretleyebilir ve süreç takvimlerine bağlılığın net bir ölçümünü sağlar.
Neden önemli
Deftere işleme için hizmet seviyesi anlaşmasını veya son teslim tarihini tanımlar, bu da zamanında performans KPI'larının hesaplanmasını sağlar.
Nereden alınır
Bu standart bir alan olmayabilir. Oluşturma tarihi, muhasebe dönemi veya yevmiye kategorisine dayalı iş kurallarından türetilebilir.
Örnekler
2023-10-312023-11-302024-01-05
|
|||
|
İptal Göstergesi
ReversalIndicator
|
Yevmiye kaydının başka bir kaydın ters kaydı (reversal) olup olmadığını belirten bir işarettir (flag). | ||
|
Açıklama
Bu boolean öznitelik, daha önce kaydedilmiş bir kaydı geri almak için oluşturulan yevmiye kayıtlarını tanımlar. İptaller, genellikle farklı ve bazen sorunlu bir süreci takip eden belirli bir yevmiye kaydı türüdür. Bu göstergeyi analiz etmek, 'Yevmiye Kaydı İptal Süreci Performansı' Dashboard'unu desteklemek için anahtardır. İptal süreçlerini frekanslarını, nedenlerini ve döngü sürelerini ölçmek için izole etmeye olanak tanır, bu da iptali gerektiren orijinal kayıtlardaki temel sorunları belirlemeye yardımcı olur.
Neden önemli
Düzeltme sürecini izole etmeye ve analiz etmeye yardımcı olur; ki bu genellikle orijinal işlemdeki hata veya sorunların bir göstergesidir.
Nereden alınır
Bu, GL_JE_HEADERS tablosunda ACCRUAL_REV_FLAG gibi belirli bir işaret olabilir veya geri alınan orijinal yevmiye kaydına yapılan bağlantılar aracılığıyla tanımlanabilir.
Örnekler
truefalse
|
|||
|
Is On-Time Posting
IsOnTimePosting
|
Yevmiye kaydının hedef tarihinde veya öncesinde deftere nakledilip edilmediğini gösteren hesaplanmış bir işarettir (flag). | ||
|
Açıklama
Bu boolean öznitelik, 'Journal Entry Posted' (Yevmiye Kaydı Kaydedildi) faaliyetinin zaman damgasının 'Target Posting Date' (Hedef Kayıt Tarihi) ile karşılaştırılmasıyla türetilir. Eğer kayıt hedeften önce veya hedefte gerçekleşirse, değer 'doğru'; aksi takdirde 'yanlış' olur. Bu öznitelik, hesaplamayı basitleştirerek 'Zamanında Yevmiye Kaydı Oranı' KPI'ını doğrudan destekler. Belirli yevmiye kategorileri veya onaylayıcılar gibi gecikmelerin yaygın nedenlerini belirlemek için geç kalan kayıtların kolayca filtrelenmesine ve analiz edilmesine olanak tanır.
Neden önemli
Kayıt performansına yönelik net, ikili bir sonuç sunarak, zamanında tamamlama oranlarının ve gecikmelerin temel nedenlerinin analizini basitleştirir.
Nereden alınır
Bu öznitelik, Process Mining aracı tarafından hesaplanır. 'TargetPostingDate' özniteliğini ve 'Journal Entry Posted' (Yevmiye Kaydı Kaydedildi) faaliyetinin zaman damgasını gerektirir.
Örnekler
truefalse
|
|||
|
Muhasebe Dönemi
AccountingPeriod
|
Yevmiye kaydının kaydedildiği mali dönem; örneğin 'Ocak-24'. | ||
|
Açıklama
Muhasebe Dönemi, işlemin tanındığı finansal dönemi belirtir. Bu, tüm finansal raporlama ve analizler için temeldir. Process Mining'de bu öznitelik, trend analizi için çok önemlidir. Farklı aylar veya çeyrekler arasında döngü süreleri veya ret oranları gibi süreç performansını karşılaştırmaya olanak tanır. Bu, ay sonu kapanışında artan iş yükü gibi mevsimsellik etkilerini belirlemeye ve süreç iyileştirmelerinin zaman içindeki etkisini ölçmeye yardımcı olur.
Neden önemli
Zaman içinde KPI'ların trend analizini sağlar; süreç iyileştirmesini ölçmeye ve ay sonu baskıları gibi mevsimsel modelleri belirlemeye yardımcı olur.
Nereden alınır
GL_JE_HEADERS tablosunda, genellikle PERIOD_NAME adlı bir alanda mevcuttur.
Örnekler
Jan-24Feb-24Mar-24
|
|||
|
Para Birimi
CurrencyCode
|
Yevmiye kaydı tutarı için USD, EUR veya GBP gibi para birimi kodu. | ||
|
Açıklama
Para Birimi Kodu, yevmiye kaydındaki finansal tutarların para birimini belirtir. Bu, birden fazla para biriminde işlem yapan çok uluslu kuruluşlar için zorunludur. Bu öznitelik, finansal değerlerin doğru yorumlanmasını sağlar. Para birimine göre filtreleme yapılmasına olanak tanır ve farklı bölgelerdeki parasal tutarları karşılaştırmayı veya birleştirmeyi içeren herhangi bir analizde gerekli bir alandır.
Neden önemli
Herhangi bir finansal miktar için gerekli bağlamı sağlar, doğru yorumlamayı garanti eder ve farklı para birimlerine özgü analizlere olanak tanır.
Nereden alınır
GL_JE_HEADERS tablosunda, genellikle CURRENCY_CODE adlı bir alanda mevcuttur.
Örnekler
USDEURGBPJPY
|
|||
|
Uçtan Uca Döngü Süresi
EndToEndCycleTime
|
Bir yevmiye kaydının oluşturulmasından nihai mutabakatına kadar olan toplam hesaplanan süre. | ||
|
Açıklama
Bu metrik, bir yevmiye kaydının tüm süreçte, ilk 'Journal Entry Created' (Yevmiye Kaydı Oluşturuldu) olayından son 'Journal Entry Reconciled' (Yevmiye Kaydı Mutabık Kalındı) olayına kadar harcadığı toplam süreyi temsil eder. Süreç performansına bütünsel bir bakış açısı sunar. Bu, genel süreç verimliliğini ölçmek için birincil bir KPI'dır. İyileştirme girişimlerinin zaman içindeki etkisini izlemek için trend Dashboard'larında kullanılır ve tüm süreç değişikliklerinin ölçülebileceği bir temel sağlar.
Neden önemli
Tüm sürecin sağlığı ve verimliliği hakkında üst düzey bir ölçüm sunarak, yönetici raporlaması için anahtar bir metrik haline gelir.
Nereden alınır
Bu metrik, Process Mining platformu tarafından her vaka için ilk ve son olay zaman damgaları arasındaki zaman farkı olarak hesaplanır.
Örnekler
P10DT5HP4DT12HP22D
|
|||
|
Yeniden İşleme mi?
IsRework
|
Yevmiye kaydının bir reddedilme ve düzeltme döngüsünden geçip geçmediğini belirten hesaplanmış bir işarettir (flag). | ||
|
Açıklama
Bu boolean öznitelik, yeniden işleme maruz kalmış vakaları belirlemek için hesaplanır. Genellikle 'Journal Entry Rejected' (Yevmiye Kaydı Reddedildi) olayını takip eden 'Journal Corrected and Resubmitted' (Yevmiye Düzeltildi ve Yeniden Gönderildi) gibi herhangi bir faaliyet için 'doğru' olarak işaretlenir. Yeniden İşleme, analiz için güçlü bir özniteliktir, çünkü yeniden işleme döngülerinin hacmini ve etkisini kolayca ölçmeye olanak tanır. Doğrudan 'Ortalama Yevmiye Kaydı Yeniden İşleme Oranı' KPI'ını destekler ve yeniden işlenen vakaların süreç akışını ve süresini, ilk seferde doğru işlenenlerle karşılaştırmaya yardımcı olur.
Neden önemli
Verimsiz yeniden işleme döngülerinden geçen vakaları doğrudan işaretler, bu da süreç başarısızlıklarının sıklığını ve etkisini nicelleştirmeyi kolaylaştırır.
Nereden alınır
Bu, kaynak sistemde mevcut değildir. Her vaka için faaliyet dizisi analiz edilerek Process Mining aracı içinde hesaplanır.
Örnekler
truefalse
|
|||
|
Yevmiye Onay Süresi
JournalApprovalTime
|
Yevmiye kaydının gönderilmesi ile nihai onay veya ret kararı arasındaki hesaplanan süre. | ||
|
Açıklama
Bu metrik, bir yevmiye kaydının onay için gönderilmesinden onaylanmasına veya reddedilmesine kadar geçen süreyi ölçer. Onay iş akışının verimliliğinin kritik bir ölçüsüdür. Yevmiye Onay Süresi, 'Ortalama Yevmiye Onay Süresi' KPI'ı ve 'Yevmiye Kaydı Onay Darboğazları' Dashboard'u için doğrudan bir girdidir. Bu süreyi analiz etmek, onay zincirindeki gecikmeleri, ister belirli onaylayıcılar, departmanlar veya yevmiye türlerinden kaynaklansın, belirlemeye yardımcı olur.
Neden önemli
Onay iş akışının verimliliğini doğrudan ölçer; ki bu genellikle süreç gecikmelerinin önemli bir kaynağıdır.
Nereden alınır
Bu, Process Mining aracı içinde hesaplanan bir metriktir. 'Journal Submitted For Approval' (Yevmiye Onay İçin Gönderildi) ile 'Journal Entry Approved' (Yevmiye Kaydı Onaylandı) veya 'Journal Entry Rejected' (Yevmiye Kaydı Reddedildi) olayları arasındaki zaman farkıdır.
Örnekler
P2DT4H30M8SP5D
|
|||
Kayıttan Raporlamaya - Yevmiye Kaydı Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Onay İçin Yevmiye Gönderildi
|
Bu faaliyet, kullanıcının tamamlanmış yevmiye kaydını onay iş akışına resmi olarak göndermesiyle gerçekleşir. Yevmiye kaydını taslak veya eksik durumdan onay bekleyen duruma geçirir. | ||
|
Neden önemli
Bu, onay döngü sürelerini ölçmek ve darboğazları belirlemek için saati başlatan kritik bir kilometre taşıdır. Veri giriş aşamasını inceleme ve onay aşamasından ayırır.
Nereden alınır
Bu olay, GL_JE_HEADERS tablosundaki bir durum değişikliğinden, özellikle APPROVAL_STATUS_CODE'un 'REQUIRED' (GEREKLİ) veya 'INITIATED' (BAŞLATILDI) gibi bir değere değiştiğinde çıkarılır. Gönderim tarihi zaman damgası da kaydedilebilir.
Yakala
GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE gönderimi gösterecek şekilde değiştiğinde zaman damgasını izleyin.
Event tipi
inferred
|
|||
|
Yevmiye Kaydı Deftere İşlendi
|
Yevmiye kaydının finansal verileri Genel Muhasebe'ye başarıyla kaydedilmiştir. Borçlar ve alacaklar artık hesap bakiyelerine yansımaktadır. | ||
|
Neden önemli
Bu, yevmiye kaydının resmi finansal kayıtlara girişini temsil eden kritik bir kilometre taşıdır. Zamanında kayıt oranını ve oluşturulmadan kayda kadar geçen toplam süreyi ölçmek için esastır.
Nereden alınır
Bu, GL_JE_HEADERS tablosundaki durum değişikliğinden, STATUS alanı 'P' (Kaydedildi) olarak değiştiğinde çıkarılır. GL_JE_BATCHES tablosu da bir kayıt durumuna sahiptir.
Yakala
GL_JE_HEADERS tablosundaki STATUS 'P' olarak değiştiğinde zaman damgasını izleyin.
Event tipi
inferred
|
|||
|
Yevmiye Kaydı Mutabakatı Sağlandı
|
Yevmiye kaydı, dönem sonu hesap mutabakatı sürecinde eşleştirilmiş ve kapatılmıştır. Bu, işlemin banka hesap özetleri gibi diğer finansal verilerle uyumlu olduğunu doğrular. | ||
|
Neden önemli
Bu faaliyet, yevmiye kaydının yaşam döngüsü için gerçek bir son nokta görevi görür. Kayda almadan mutabakata kadar geçen süreyi ölçmek, finansal kapanış sürecinin verimliliğini değerlendirmek için anahtar bir KPI'dır.
Nereden alınır
Bu olay genellikle Oracle Financial Consolidation and Close Cloud Service (FCCS) veya Account Reconciliation Cloud Service (ARCS) içinde yakalanır, Genel Muhasebe'nin kendisinde değil. Yevmiye kaydına bağlı mutabakat kaydındaki bir durum değişikliğinden çıkarılır.
Yakala
Correlate journal data with reconciliation status updates from ARCS or FCCS tables.
Event tipi
inferred
|
|||
|
Yevmiye Kaydı Oluşturuldu
|
Bu faaliyet, yevmiye kaydı sürecinin başlangıcını işaret eder. Bir kullanıcının yeni bir yevmiye başlığı oluşturduğu ve veri girmeye başladığı, ancak herhangi bir inceleme veya onay için gönderilmeden önceki anı temsil eder. | ||
|
Neden önemli
Bu, süreç için birincil başlangıç olayıdır. Bu faaliyetten sonraki adımlara kadar geçen süreyi analiz etmek, ilk veri giriş verimliliğini ve genel süreç döngü süresini ölçmeye yardımcı olur.
Nereden alınır
Bu olay tipik olarak, belirli bir Yevmiye Kaydı Kimliği için GL_JE_HEADERS tablosundaki oluşturma tarihi zaman damgasından çıkarılır. Kaydı oluşturan kullanıcı da bu tabloda mevcuttur.
Yakala
GL_JE_HEADERS tablosundaki CREATION_DATE'i kullanın.
Event tipi
inferred
|
|||
|
Yevmiye Kaydı Onaylandı
|
Atanmış onaylayıcı, yevmiye kaydını resmi olarak onaylayarak doğruluğunu ve geçerliliğini teyit etmiştir. Bu, onay iş akışındaki son adımdır ve kayda alma için yolu açar. | ||
|
Neden önemli
Bu kilometre taşı, onay sürecinin sonunu işaret eder. Gönderim ve onay arasındaki süre, iş akışı verimliliğini ölçmek ve onay darboğazlarını belirlemek için anahtar bir KPI'dır.
Nereden alınır
Bu olay, GL_JE_HEADERS tablosundaki bir durum değişikliğinden, APPROVAL_STATUS_CODE'un 'APPROVED' (ONAYLANDI) olarak güncellenmesiyle çıkarılır. İş akışı tabloları, onaylayıcının kimliğini ve zaman damgasını içerir.
Yakala
GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE 'APPROVED' (ONAYLANDI) olarak değiştiğinde zaman damgasını izleyin.
Event tipi
inferred
|
|||
|
Deftere İşleme Doğrulandı
|
Kayda alma sonrası, bir kullanıcının veya sistemin yevmiyenin doğru kaydedildiğini ve bakiyelerin beklendiği gibi olduğunu onayladığı bir doğrulama adımıdır. Bu genellikle manuel bir kontrol adımıdır. | ||
|
Neden önemli
Bu aktiviteyi analiz etmek, kayda alma sonrası manuel kontrollere ve kalite güvencesine harcanan zamanı anlamaya yardımcı olur. Doğrulama süreçlerini otomatikleştirmek için fırsatları ortaya çıkarabilir.
Nereden alınır
Bunun Oracle Fusion'da açık bir olay olması pek olası değildir. Bir kullanıcının belirli bir raporu çalıştırması veya standart olmayan özel bir durum alanının güncellenmesi gibi diğer eylemlerden çıkarılması gerekirdi.
Yakala
Doğrulama raporlarının çalışma süresi veya açıklayıcı bir esnek alandaki güncellemelerin takibi gibi özel bir mantık gerektirir.
Event tipi
inferred
|
|||
|
Destekleyici Belgeler Eklendi
|
Fatura veya elektronik tablolar gibi destekleyici belgeleri yevmiye kaydına ekleme eylemini temsil eder. Bu genellikle denetçiler ve onaylayanlar için bağlam ve kanıt sağlamak amacıyla yapılır. | ||
|
Neden önemli
Bu faaliyeti izlemek, gecikmelerin eksik belgelerden kaynaklanıp kaynaklanmadığını anlamaya yardımcı olur. Ayrıca yevmiye kayıtlarının onay iş akışına girmeden önceki uyumluluğu ve eksiksizliği hakkında içgörüler sağlar.
Nereden alınır
Bunu ayrı bir olay olarak takip etmek zor olabilir. FND_ATTACHED_DOCUMENTS gibi ek tablolarındaki zaman damgalarından, GL_JE_HEADERS'daki yevmiye kaydı kaydına bağlanarak çıkarılabilir.
Yakala
Yevmiyeye bağlı FND_ATTACHED_DOCUMENTS içindeki kayıtların oluşturulma tarihinden çıkarım yapın.
Event tipi
inferred
|
|||
|
Yevmiye Deftere İşleme Başlatıldı
|
Onaylanmış yevmiye kaydının Genel Muhasebe'ye kaydedilmesi süreci başlatıldı. Bu, kaydı, kayıt programı tarafından işlenmek üzere sıraya alan otomatik veya manuel bir adım olabilir. | ||
|
Neden önemli
Bu faaliyet, onayı teknik kayda alma sürecinden ayırır. Onay ve kayıt başlatma arasındaki gecikmeler, kayıt motorundaki zamanlama sorunlarını veya kaynak kısıtlamalarını gösterebilir.
Nereden alınır
Bu, GL_JE_BATCHES tablosundaki durum değişikliklerinden veya yevmiye toplu işlemiyle ilişkili kayıt eşzamanlı isteğinin gönderim zamanından çıkarılabilir.
Yakala
Belirli bir yevmiye grubu için Genel Muhasebe Nakil (Posting) programının istek gönderim zamanını tanımlayın.
Event tipi
inferred
|
|||
|
Yevmiye Düzeltildi ve Yeniden Gönderildi
|
Bir yevmiye kaydı reddedildikten sonra, oluşturan kişi gerekli düzeltmeleri yapar ve onay için yeniden gönderir. Bu aktivite, aynı yevmiye için yeni bir onay döngüsünün başlangıcını temsil eder. | ||
|
Neden önemli
Yeniden işlemeyi izlemek, süreç verimsizliğini anlamak için esastır. Bu faaliyet, 'Journal Entry Rejected' (Yevmiye Kaydı Reddedildi) ile birleştirildiğinde, yeniden işleme süresini ve sıklığını ölçmeye olanak tanır.
Nereden alınır
Bu, daha önce 'REDDEDİLDİ' durumunda olan bir yevmiye kaydı için sonraki bir 'Journal Submitted For Approval' (Yevmiye Onay İçin Gönderildi) olayıdır. Tek bir Yevmiye Kaydı Kimliği için durum değişikliklerinin sırası analiz edilerek tanımlanır.
Yakala
Aynı case ID için bir reddetme olayından sonra gerçekleşen bir gönderim olayı zaman damgasını tanımlayın.
Event tipi
inferred
|
|||
|
Yevmiye Düzeltme İşlemi Tamamlandı
|
Bir düzeltme yevmiye kaydı oluşturulmuş ve orijinal yevmiyenin sonraki bir dönemdeki finansal etkisini ortadan kaldırmak için kaydedilmiştir. Bu, genellikle tahakkuklar için yapılan yaygın bir eylemdir. | ||
|
Neden önemli
İptalleri izlemek, sıkça iptal edilen kayıt türlerini belirlemeye ve iptal sürecinin verimliliğini analiz etmeye yardımcı olur. Bu, tahakkuk yönetimiyle ilgili sorunlara işaret edebilir.
Nereden alınır
Bu, orijinal kaydın iptali olarak açıkça bağlantılı yeni bir yevmiye kaydının tanımlanmasıyla çıkarılır. GL_JE_HEADERS tablosu, bu kayıtları tanımlamak ve bağlamak için REVERSAL_PERIOD ve REVERSAL_FLAG gibi alanlara sahiptir.
Yakala
Başlığı orijinal yevmiyeyi ters kayıt olarak referans gösteren yeni yevmiye kaydının oluşturulma ve nakil tarihini tanımlayın.
Event tipi
inferred
|
|||
|
Yevmiye Kaydı İncelendi
|
Resmi onay sürecinden önce veya bu sürecin bir parçası olarak gerçekleşebilen bir inceleme adımıdır. Bu, son onaylayıcıya geçmeden önce doğruluk ve uyumluluğu sağlamak için bir akran veya yönetici tarafından yapılan bir kontrolü temsil eder. | ||
|
Neden önemli
Bu aktiviteyi izole etmek, ön inceleme süreleri ile nihai onay süreleri arasında ayrım yapmaya yardımcı olur. İnceleme aşaması resmi olmasa da zaman alıcıysa, gizli darboğazları ortaya çıkarabilir.
Nereden alınır
Bu, iş akışı geçmişi tablolarında yakalanan çok aşamalı bir onay iş akışında açık bir adım olabilir. Gayri resmi ise yakalanmaz. Nihai onay kararından önce belirli bir kullanıcı eylemi kaydedilmişse çıkarılabilir.
Yakala
Nihai 'Approved' durumundan önceki ara onay veya inceleme adımları için workflow geçmiş tablolarını analiz edin.
Event tipi
inferred
|
|||
|
Yevmiye Kaydı Reddedildi
|
Bir onaylayıcı yevmiye kaydını incelemiş ve hatalar, eksik belgeler veya politika ihlalleri nedeniyle reddetmiştir. Bu eylem, yevmiyeyi düzeltilmesi için oluşturan kişiye geri gönderir. | ||
|
Neden önemli
Bu faaliyet, yeniden işleme döngülerini, ret oranlarını ve ilk seferde doğru metrikleri analiz etmek için çok önemlidir. Yüksek ret sıklığı, veri kalitesi veya eğitimle ilgili sorunlara işaret eder.
Nereden alınır
Bu, GL_JE_HEADERS tablosundaki bir durum değişikliğinden, APPROVAL_STATUS_CODE 'REJECTED' (REDDEDİLDİ) olarak güncellendiğinde çıkarılır. İş akışı geçmişi, bu eylem için kullanıcıyı ve zaman damgasını kaydedecektir.
Yakala
GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE 'REJECTED' (REDDEDİLDİ) olarak ayarlandığında zaman damgasını izleyin.
Event tipi
inferred
|
|||