Kayıttan Raporlamaya - yevmiye kaydı Veri Templateiniz
Kayıttan Raporlamaya - yevmiye kaydı Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Oracle Fusion Financials için veri çıkarma yönergeleri
Kayıttan Raporlamaya - yevmiye kaydı öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç zamanı
EventTime
|
Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Bu zaman damgası, bir etkinliğin gerçekleştiği tarih ve saati tam olarak gösterir. Process Mining çalışmalarında olayların sırasını belirlemek ve aralarındaki süreleri hesaplamak için kullanılan temel zaman bilgisidir. Çevrim sürelerini hesaplamak, darboğazları belirlemek ve hizmet düzeyi anlaşmalarına göre performansı izlemek dahil, zamana dayalı tüm analizlerde olay zamanının doğru olması önemlidir. Süreç akışını gerçekleştiği sırayla yeniden oluşturmak için gereken kronolojik bilgiyi sağlar.
Neden önemli?
Olayları sıralamak, tüm süreç sürelerini hesaplamak ve zamana dayalı analizler yapmak için bu zaman damgası gereklidir.
Nereden alınır?
Bu bilgi genellikle denetim izi tablolarında veya belirli olaylar için GL_JE_HEADERS ve GL_JE_LINES gibi işlem tablolarındaki 'Last Update Date' ya da 'Creation Date' alanlarında saklanır.
Örnekler
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
|
|||
|
Etkinlik
ActivityName
|
Yevmiye kaydı sürecinde belirli bir anda gerçekleşen iş olayının veya görevin adı. | ||
|
Açıklama
Etkinlik adı, yevmiye kaydının yaşam döngüsündeki 'Journal Entry Created' veya 'Journal Entry Approved' gibi tek bir adımı tanımlar. Bu veri, süreç haritasını oluşturmak ve olayların sırasını anlamak için önemlidir. Etkinlikleri analiz ederek standart yollar, sapmalar ve yeniden çalışma döngüleri dahil olmak üzere süreç akışını belirleyebilirsiniz. Farklı etkinlikleri izlemek, onay gibi belirli aşamalarda harcanan süreyi ölçmenize ve en çok zaman alan ya da hataya en açık adımları bulmanıza yardımcı olur.
Neden önemli?
Sürecin adımlarını tanımlar, süreç haritasının temelini oluşturur ve akışın, darboğazların ve farklılıkların analiz edilmesini sağlar.
Nereden alınır?
Bu öznitelik genellikle Büyük Defter modülündeki yevmiye kaydı nesneleriyle ilişkili durum değişikliklerinden, olay günlüklerinden veya denetim izi tablolarından elde edilir.
Örnekler
Yevmiye kaydı oluşturulduYevmiye kaydı onaya gönderildiYevmiye kaydı onaylandıYevmiye kaydı muhasebeleştirildi
|
|||
|
Yevmiye kaydı kimliği
JournalEntryId
|
Tek bir yevmiye kaydını benzersiz biçimde tanımlayan ve ilgili tüm finansal işlem etkinliklerini birbirine bağlayan kimlik. | ||
|
Açıklama
Yevmiye kaydı kimliği, temel vaka tanımlayıcısıdır ve belirli bir finansal işlem grubuyla ilgili tüm etkinlikleri benzersiz biçimde birbirine bağlar. Böylece tek bir yevmiye kaydının başlatılmasından muhasebeleştirilmesine kadar tüm yaşam döngüsü izlenebilir ve borç ile alacak tutarlarının tamamı hesaba katılır. Process Mining çalışmalarında bu kimlik, her yevmiye kaydının baştan sona izlediği yolu yeniden oluşturmak için gereklidir. 'Journal Entry Created', 'Journal Submitted For Approval' ve 'Journal Entry Posted' gibi farklı olayları tutarlı bir süreç akışında birleştirerek çevrim sürelerinin, darboğazların ve süreç farklılıklarının analiz edilmesini sağlar.
Neden önemli?
Yevmiye kaydını baştan sona izlemek için kullanılan temel anahtardır. Her bir vakaya ait tüm süreç akışının analiz edilmesini sağlar.
Nereden alınır?
GL_JE_HEADERS ve GL_JE_LINES gibi temel Büyük Defter tablolarında bulunan birincil anahtardır.
Örnekler
JE100523JE202311001882019
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin geldiği sistem veya modül. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin hangi kaynak sistemden çıkarıldığını belirtir. Karmaşık bir BT ortamında veriler birden fazla entegre sistemden gelebilir; bu alan, kaynakları birbirinden ayırmaya yardımcı olur. Süreç analizinde kaynak sistemi bilmek önemlidir; çünkü farklı sistem davranışları süreçteki farklılıklara yol açabilir. Ayrıca verinin kaynağına kadar izlenmesini sağlayarak doğrulama ve sorun giderme çalışmalarını kolaylaştırır.
Neden önemli?
Verinin kaynağını belirtir. Veri yönetişimi, doğrulama ve farklı sistemlerdeki süreç farklılıklarını anlamak için önemlidir.
Nereden alınır?
Bu genellikle veri çıkarma sırasında yapılandırılan sabit bir değerdir. Kaynak tablolarda, verinin hangi sistemde girildiğini belirten bir alan da olabilir.
Örnekler
Oracle Fusion Financials CloudOracle EBS R12Fusion GL
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Kaynak sistemden yapılan en son veri yenileme veya çıkarma işleminin zaman damgası. | ||
|
Açıklama
Bu öznitelik, veri setinin en son ne zaman güncellendiğini kaydeder. Analiz edilen verinin ne kadar güncel olduğunu gösterir; bu da elde edilen içgörülerin geçerliliğini değerlendirmek açısından önemlidir. Özellikle operasyonel Dashboardlarda, kullanıcıların verilere güvenip bilinçli kararlar alabilmesi için son veri güncellemesi zamanını bilmesi gerekir. Ayrıca Process Mining modeline dahil edilen verilerin hangi ana kadar güncel olduğunu açıkça gösterir.
Neden önemli?
Verinin güncelliğini gösterir. Böylece kullanıcılar süreç analizinin ne kadar güncel olduğunu anlayabilir ve içgörülere güvenebilir.
Nereden alınır?
Bu değer, veri çıkarma ve dönüştürme işlemi sırasında oluşturulup kaydedilir. Genellikle 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
|
Yevmiye kaydını oluşturan, onaylayan veya muhasebeleştiren kullanıcı. | ||
|
Açıklama
Bu öznitelik, bir etkinliği gerçekleştirmekten sorumlu çalışanı veya sistem kullanıcısını belirtir. İş yükü dağılımını ve performansı anlamak, kişiye bağlı darboğazları belirlemek için önemlidir. Kullanıcı adı sayesinde süreçleri kullanıcıya göre filtreleyebilir, kullanıcı verimliliğini karşılaştırabilir ve gecikme ya da hataların nedenlerini inceleyebilirsiniz. Ayrıca 'User Workload & Efficiency Across Teams' gibi Dashboardları ve 'User Journal Bottleneck Index' gibi KPI’ları destekler.
Neden önemli?
Süreç adımlarının sorumlularını göstererek kullanıcı iş yükünün, bireysel performansın ve eğitim ihtiyaçlarının analiz edilmesini sağlar.
Nereden alınır?
GL_JE_HEADERS gibi işlem tablolarında (ör. CREATED_BY, LAST_UPDATED_BY alanları) ve ilgili denetim izi tablolarında bulunur.
Örnekler
john.doesusan.smithautoprocess_user
|
|||
|
Kullanıcı departmanı
UserDepartment
|
Etkinliği gerçekleştiren kullanıcının bağlı olduğu departman veya ekip. | ||
|
Açıklama
Bu öznitelik, etkinliği 'Finance', 'Accounting Operations' veya 'Internal Audit' gibi belirli bir departmanla ilişkilendirerek kurumsal bağlam sağlar. Genellikle kullanıcı ana verilerinden elde edilir. Kullanıcı departmanına göre analiz yapmak, departmanlar arası darboğazları belirlemeye, ekip performansını karşılaştırmaya ve süreçlerin kuruluş genelinde nasıl farklı yürütüldüğünü anlamaya yardımcı olur. Kaynak tahsisi ve hedefli süreç iyileştirme çalışmaları için de yararlıdır.
Neden önemli?
Kurumsal bağlam sağlar; ekip veya departman bazında performans analizine ve işlevler arası verimsizliklerin belirlenmesine yardımcı olur.
Nereden alınır?
Bu bilgi genellikle işlem tablolarında bulunmaz. Kullanıcı adını kullanıcı ana verileri tablosuyla veya İK sistemi verileriyle birleştirerek elde edilmelidir.
Örnekler
Genel muhasebeFinansal raporlamaBorçlar muhasebesi
|
|||
|
Ret nedeni
RejectionReason
|
Yevmiye kaydının neden reddedildiğini açıklayan metin veya kod. | ||
|
Açıklama
Yevmiye kaydı onay sürecinde reddedildiğinde bu öznitelik, ret nedenini kaydeder. Önceden tanımlanmış bir kod veya onaylayanın serbest metinli yorumu olabilir. Süreç verimsizliklerinin temel nedenlerini analiz etmek için en önemli özniteliklerden biridir. En sık karşılaşılan ret nedenlerini inceleyerek kuruluşlar, kayıt hazırlayanlara daha iyi eğitim verilmesi, yönergelerin netleştirilmesi veya sistem kontrollerinin iyileştirilmesi gibi alanları belirleyebilir. 'Journal Entry Rejection Rate Analysis' Dashboardunu doğrudan destekler.
Neden önemli?
Yeniden çalışma ve süreç gecikmelerinin temel nedenlerini doğrudan göstererek ret oranlarını azaltmaya yönelik iyileştirmeleri hedeflemeyi sağlar.
Nereden alınır?
Bu bilgi, onay süreciyle ilişkili iş akışı veya denetim izi tablolarında ya da yevmiye kaydı üstbilgisindeki not alanında saklanabilir.
Örnekler
Hatalı hesap birleşimiDestekleyici dokümantasyon yetersizBütçe aşıldı
|
|||
|
Yevmiye kategorisi
JournalCategory
|
'Accrual', 'Adjustment' veya 'Reclassification' gibi yevmiye kaydı kategorisi. | ||
|
Açıklama
Yevmiye kategorisi, kayıtları iş amaçlarına göre sınıflandırır. Farklı kategorilerin süreç akışları, onay kuralları veya çevrim süreleri değişebileceğinden bu sınıflandırma, sürecin daha ayrıntılı analiz edilmesini sağlar. Örneğin, ay sonu düzeltme kayıtlarının süreci, rutin tahakkuk kayıtlarına kıyasla daha karmaşık ve acil olabilir. Süreci kategoriye göre analiz etmek, bu farklılıkları ortaya çıkarır ve iyileştirmelerin belirli yevmiye kaydı türlerine göre uyarlanmasına yardımcı olur.
Neden önemli?
Sürecin yevmiye kaydının iş amacına göre ayrıştırılmasını sağlar; farklı kayıt türlerinin davranış ve performans farklarını ortaya çıkarır.
Nereden alınır?
GL_JE_HEADERS tablosunda, genellikle JE_CATEGORY adlı alanda bulunur.
Örnekler
TahakkukManuelDüzeltmeYeniden değerleme
|
|||
|
Yevmiye kaynağı
JournalSource
|
'Payables', 'Receivables' veya 'Manual' gibi, yevmiye kaydını oluşturan alt defter ya da kaynak. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydının ERP sistemi içindeki kaynağını belirtir. Kayıtlar Büyük Defter’de manuel olarak oluşturulabilir veya Borçlar Muhasebesi, Alacaklar Muhasebesi ya da Sabit Kıymetler gibi alt defterlerden otomatik olarak üretilebilir. Yevmiye kaynağı, otomasyon analizinde önemli bir özniteliktir. Manuel kayıtlarla sistem tarafından oluşturulan kayıtları ayırmaya yardımcı olur ve 'Automated Journal Entry Rate' KPI’ını destekler. Farklı kaynaklardan gelen kayıtların süreçleri, karmaşıklık ve verimlilik açısından önemli ölçüde farklılık gösterebilir.
Neden önemli?
Manuel kayıtlarla otomatik kayıtları birbirinden ayırır. Otomasyon oranlarını ölçmek ve süreç farklılıklarını analiz etmek için önemlidir.
Nereden alınır?
GL_JE_HEADERS tablosunda, genellikle JE_SOURCE adlı alanda bulunur.
Örnekler
ManuelBorçlarVarlıklarAlacaklar
|
|||
|
Yevmiye tutarı
JournalAmount
|
Yevmiye kaydının toplam parasal değeri; genellikle borç tutarlarının toplamı. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydındaki işlemin toplam finansal değerini gösterir. Tutar, süreci önemli ölçüde etkileyebilir. Örneğin, yüksek tutarlı kayıtlar için ek onay adımları veya daha ayrıntılı incelemeler gerekebilir. Yevmiye tutarını analiz ederek vakaları finansal etkilerine göre gruplandırabilirsiniz. 'Yüksek tutarlı kayıtların onaylanması daha uzun sürüyor mu?' veya 'Belirli bir eşiğin üzerindeki kayıtlar daha sık reddediliyor mu?' gibi soruları yanıtlamaya yardımcı olur. Böylece süreç akışına ilişkin önemli bir iş bağlamı sunar.
Neden önemli?
Finansal etkiye göre analiz yapılmasını ve yüksek tutarlı kayıtların farklı bir süreç izleyip izlemediğinin belirlenmesini sağlayan önemli bir iş bağlamı sunar.
Nereden alınır?
Bu değer genellikle belirli bir yevmiye kaydı için GL_JE_LINES tablosundaki borç veya alacak tutarlarının toplamı olarak hesaplanır.
Örnekler
5000.00125000.75750.50
|
|||
|
Baştan sona çevrim süresi
EndToEndCycleTime
|
Yevmiye kaydının oluşturulmasından nihai mutabakatına kadar geçen toplam hesaplanmış süre. | ||
|
Açıklama
Bu metrik, yevmiye kaydının ilk 'Journal Entry Created' olayından son 'Journal Entry Reconciled' olayına kadar tüm süreçte geçirdiği toplam süreyi gösterir. Süreç performansına bütünsel bir bakış sunar. Genel süreç verimliliğini ölçmek için kullanılan temel KPI’lardan biridir. İyileştirme çalışmalarının zaman içindeki etkisini izleyen eğilim Dashboardlarında kullanılır ve süreçteki tüm değişiklikleri değerlendirmek için bir başlangıç ölçütü sağlar.
Neden önemli?
Sürecin genel sağlığını ve verimliliğini üst düzeyde ölçer; yönetici raporlamasında önemli bir metriktir.
Nereden alınır?
Bu metrik, her vaka için ilk ve son olay zaman damgaları arasındaki fark olarak Process Mining platformunda hesaplanır.
Örnekler
10 gün 5 saatP4DT12HP22D
|
|||
|
Bitiş zamanı
EndTime
|
Belirli bir etkinliğin ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Bitiş zamanı, bir etkinliğin tamamlandığı anı gösterir. Başlangıç zamanı etkinliğin ne zaman başladığını kaydederken bitiş zamanı, kapanış noktasını belirler ve o adımın işlem süresinin doğru hesaplanmasını sağlar. Darboğazları belirlemek ve kaynak verimliliğini ölçmek için temel bir metrik olan etkinlik işlem sürelerini hesaplamak açısından önemlidir. Örneğin, 'Journal Entry Reviewed' etkinliğinin bitiş ve başlangıç zamanları arasındaki fark, inceleyenin görev için harcadığı gerçek süreyi gösterir.
Neden önemli?
Tek tek etkinliklerin gerçek süresini veya işlem süresini hesaplamayı sağlar. Bu bilgi, verimlilik sorunlarını belirlemek için önemlidir.
Nereden alınır?
Başlangıç zamanına benzer şekilde, bu bilgi genellikle denetim izi tablolarında bulunur veya süreçteki sonraki etkinliğin 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 işlendiği büyük defterin adı. | ||
|
Açıklama
Defter adı, yevmiye kaydının hangi deftere ait olduğunu belirtir. Birden fazla tüzel kişiliği veya raporlama gereksinimi olan kuruluşlarda, kurumsal muhasebe için birincil defter ve yerel yasal raporlama için ikincil defterler gibi birden fazla defter bulunabilir. Bu öznitelik, farklı tüzel kişilikler veya iş birimleri arasındaki süreçleri filtrelemeyi ve karşılaştırmayı sağlar. Analizlerin doğru kurumsal bağlamda yapılmasına yardımcı olur; bu da özellikle finansal uyumluluk ve raporlama açısından önemlidir.
Neden önemli?
Büyük kuruluşlarda özellikle önemli olan bu öznitelik, süreç analizlerinin farklı tüzel kişilikler veya muhasebe çerçeveleri arasında filtrelenmesini ve karşılaştırılmasını sağlar.
Nereden alınır?
GL_JE_HEADERS tablosunda bulunur. Genellikle LEDGER_ID üzerinden ilişkilendirilir; adını almak için GL_LEDGERS tablosuyla birleştirilebilir.
Örnekler
ABD birincil defteriBirleşik Krallık yasal defteriKüresel konsolidasyon defteri
|
|||
|
Hedef muhasebeleştirme tarihi
TargetPostingDate
|
Yevmiye kaydının muhasebeleştirilmesinin beklendiği önceden belirlenmiş tarih. | ||
|
Açıklama
Hedef muhasebeleştirme tarihi, yevmiye kaydının büyük deftere işlenmesi için belirlenen son tarihi gösterir. Bu tarih genellikle hizmet düzeyi anlaşmalarına (SLA) veya ay sonu kapanış takvimlerine göre belirlenir ve performansı ölçmek için bir referans noktası oluşturur. Bu öznitelik, 'On-Time Journal Posting Rate' KPI’ını hesaplamak için gereklidir. Gerçek muhasebeleştirme tarihi hedef tarihle karşılaştırılarak kayıtların zamanında mı yoksa geç mi işlendiği otomatik olarak belirlenebilir. Böylece sürecin takvime uygunluğu net biçimde ölçülür.
Neden önemli?
Muhasebeleştirme için hizmet düzeyi anlaşmasını veya son tarihi tanımlar ve zamanında tamamlanma KPI’larının hesaplanmasını sağlar.
Nereden alınır?
Standart bir alan olmayabilir. Oluşturulma tarihi, muhasebe dönemi veya yevmiye kategorisine dayalı iş kurallarından türetilebilir.
Örnekler
2023-10-312023-11-302024-01-05
|
|||
|
Muhasebe dönemi
AccountingPeriod
|
'Jan-24' gibi, yevmiye kaydının muhasebeleştirildiği mali dönem. | ||
|
Açıklama
Muhasebe dönemi, işlemin hangi mali dönemde kayda alındığını belirtir. Tüm finansal raporlama ve analizlerin temelini oluşturur. Process Mining çalışmalarında bu öznitelik, eğilim analizi için önemlidir. Çevrim süreleri veya ret oranları gibi süreç performansı ölçütlerinin farklı aylar ya da çeyrekler arasında karşılaştırılmasını sağlar. Böylece ay sonu kapanışındaki iş yükü artışı gibi mevsimsel etkiler belirlenebilir ve süreç iyileştirmelerinin zaman içindeki etkisi ölçülebilir.
Neden önemli?
KPI’ların zaman içindeki eğilimlerini analiz etmeyi sağlar; süreç iyileştirmelerinin ölçülmesine ve ay sonu yoğunluğu gibi dönemsel örüntülerin belirlenmesine yardımcı olur.
Nereden alınır?
GL_JE_HEADERS tablosunda, genellikle PERIOD_NAME adlı alanda bulunur.
Örnekler
Oca-24Şub-24Mar-24
|
|||
|
Muhasebeleştirme durumu
PostingStatus
|
'Unposted' veya 'Posted' gibi, yevmiye kaydının mevcut muhasebeleştirme durumu. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydının büyük deftere işlenme durumunu gösterir. Özellikle devam eden vakalarda, kaydın yaşam döngüsünün hangi aşamasında olduğunu belirten önemli bir göstergedir. Muhasebeleştirme durumu, etkin tüm kayıtların anlık görüntüsünü sunarak 'Real-Time Journal Entry Status Tracker' Dashboardu için önemli bir veri sağlar. Henüz muhasebeleştirilmemiş kayıtların birikimini izlemeye ve sürecin son aşamalarındaki gecikmeleri belirlemeye yardımcı olur.
Neden önemli?
Yevmiye kaydının mevcut durumunu gösterir; birikmiş kayıtları izlemek ve devam eden kayıtların durumunu takip etmek için gereklidir.
Nereden alınır?
GL_JE_HEADERS tablosunda, genellikle STATUS veya POSTING_STATUS gibi bir sütunda bulunur.
Örnekler
MuhasebeleştirildiMuhasebeleştirilmediHata
|
|||
|
Para birimi
CurrencyCode
|
USD, EUR veya GBP gibi yevmiye kaydı tutarının para birimi kodu. | ||
|
Açıklama
Para birimi kodu, yevmiye kaydındaki finansal tutarların hangi para biriminde olduğunu belirtir. Birden fazla para birimiyle işlem yapan çok uluslu kuruluşlar için gereklidir. Bu öznitelik, finansal değerlerin doğru yorumlanmasını sağlar. Para birimine göre filtreleme yapılmasına imkân verir ve farklı bölgelerdeki parasal tutarları karşılaştıran veya bir araya getiren analizler için gereklidir.
Neden önemli?
Finansal tutarların doğru yorumlanması için gerekli bağlamı sağlar ve farklı para birimlerine göre analiz yapılmasına imkân verir.
Nereden alınır?
GL_JE_HEADERS tablosunda, genellikle CURRENCY_CODE adlı alanda bulunur.
Örnekler
USDEURGBPJPY
|
|||
|
Ters kayıt göstergesi
ReversalIndicator
|
Yevmiye kaydının başka bir kaydın ters kaydı olup olmadığını belirten işaret. | ||
|
Açıklama
Bu Boole özniteliği, daha önce muhasebeleştirilmiş bir kaydı ters çevirmek için oluşturulan yevmiye kayıtlarını belirler. Ters kayıtlar, genellikle kendine özgü ve bazen sorunlu bir süreç izleyen özel bir yevmiye kaydı türüdür. Bu göstergeyi analiz etmek, 'Journal Reversal Process Performance' Dashboardunu desteklemek açısından önemlidir. Ters kayıt süreçlerini ayrı inceleyerek sıklıklarını, nedenlerini ve çevrim sürelerini ölçmeye, ayrıca ters kayıt gerektiren özgün kayıtlardaki temel sorunları belirlemeye yardımcı olur.
Neden önemli?
Genellikle özgün işlemdeki hata veya sorunlara işaret eden ters kayıt sürecini ayrı incelemeye ve analiz etmeye yardımcı olur.
Nereden alınır?
GL_JE_HEADERS tablosundaki ACCRUAL_REV_FLAG gibi özel bir işaretle veya ters çevrilen özgün yevmiye kaydıyla kurulan bağlantılar üzerinden belirlenebilir.
Örnekler
truefalse
|
|||
|
Yeniden çalışma var mı
IsRework
|
Yevmiye kaydının ret ve düzeltme döngüsünden geçip geçmediğini gösteren hesaplanmış bir işaret. | ||
|
Açıklama
Bu Boole özniteliği, yeniden çalışma yaşanan vakaları belirlemek için hesaplanır. Genellikle 'Journal Entry Rejected' olayından sonra gerçekleşen 'Journal Corrected and Resubmitted' gibi etkinlikler için 'true' olarak işaretlenir. Yeniden çalışma var mı özniteliği, yeniden çalışma döngülerinin hacmini ve etkisini kolayca ölçmeyi sağladığından analiz açısından yararlıdır. 'Average Journal Rework Rate' KPI’ını doğrudan destekler ve yeniden çalışılan vakaların süreç akışını ve süresini, ilk seferde doğru işlenen vakalarla karşılaştırmaya yardımcı olur.
Neden önemli?
Verimsiz yeniden çalışma döngülerinden geçen vakaları doğrudan işaretleyerek süreç aksaklıklarının sıklığını ve etkisini ölçmeyi kolaylaştırır.
Nereden alınır?
Kaynak sistemde bulunmaz. Her vaka için etkinlik sırası incelenerek Process Mining aracında hesaplanır.
Örnekler
truefalse
|
|||
|
Zamanında muhasebeleştirildi mi
IsOnTimePosting
|
Yevmiye kaydının hedef tarihte veya daha önce muhasebeleştirilip muhasebeleştirilmediğini gösteren hesaplanmış bir işaret. | ||
|
Açıklama
Bu Boole özniteliği, 'Journal Entry Posted' etkinliğinin zaman damgası ile 'Target Posting Date' karşılaştırılarak elde edilir. Muhasebeleştirme hedef tarihte veya daha önce gerçekleşmişse değer 'true', aksi durumda 'false' olur. Bu öznitelik, hesaplamayı basitleştirerek 'On-Time Journal Posting Rate' KPI’ını doğrudan destekler. Gecikmiş kayıtları kolayca filtreleyip analiz etmeyi ve yevmiye kategorileri ya da onaylayanlar gibi yaygın gecikme nedenlerini belirlemeyi sağlar.
Neden önemli?
Muhasebeleştirme performansını açık ve ikili bir sonuçla gösterir; zamanında tamamlanma oranlarının ve gecikmelerin temel nedenlerinin analizini kolaylaştırır.
Nereden alınır?
Bu öznitelik Process Mining aracı tarafından hesaplanır. 'TargetPostingDate' özniteliği ve 'Journal Entry Posted' etkinliğinin zaman damgası gerekir.
Örnekler
truefalse
|
|||
Kayıttan Raporlamaya - yevmiye kaydı etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Yevmiye kaydı muhasebeleştirildi
|
Yevmiye kaydının finansal verileri Büyük Deftere başarıyla kaydedilmiştir. Borç ve alacak tutarları artık hesap bakiyelerine yansır. | ||
|
Neden önemli?
Bu önemli kilometre taşı, yevmiye kaydının resmî finansal kayıtlara girdiğini gösterir. Zamanında muhasebeleştirme oranını ve oluşturulma ile muhasebeleştirme arasındaki toplam süreyi ölçmek için gereklidir.
Nereden alınır?
Bu olay, GL_JE_HEADERS tablosundaki STATUS alanının 'P' (Posted) olarak değişmesinden çıkarılır. GL_JE_BATCHES tablosunda da muhasebeleştirme durumu bulunur.
Kaydedin
GL_JE_HEADERS tablosundaki STATUS alanı 'P' olarak değiştiğinde oluşan zaman damgasını izleyin.
Olay türü
inferred
|
|||
|
Yevmiye kaydı mutabık hale getirildi
|
Dönem sonu hesap mutabakatı sırasında yevmiye kaydı eşleştirilip kapatılmıştır. Bu, işlemin banka ekstreleri gibi diğer finansal verilerle uyumlu olduğunu doğrular. | ||
|
Neden önemli?
Bu etkinlik, yevmiye kaydının yaşam döngüsünün gerçek bitiş noktasıdır. Muhasebeleştirme ile mutabakat arasındaki süreyi ölçmek, finansal kapanış sürecinin verimliliğini değerlendirmek için önemli bir KPI’dır.
Nereden alınır?
Bu olay genellikle Büyük Defter’de değil, Oracle Financial Consolidation and Close Cloud Service (FCCS) veya Account Reconciliation Cloud Service (ARCS) içinde kaydedilir. Yevmiye kaydıyla bağlantılı mutabakat kaydındaki durum değişikliğinden çıkarılır.
Kaydedin
Yevmiye verilerini ARCS veya FCCS tablolarındaki mutabakat durumu güncellemeleriyle ilişkilendirin.
Olay türü
inferred
|
|||
|
Yevmiye kaydı oluşturuldu
|
Bu etkinlik, yevmiye kaydı sürecinin başlangıcını gösterir. Kullanıcının yeni bir yevmiye başlığı oluşturup veri girmeye başladığı, ancak kaydı henüz inceleme veya onaya göndermediği anı ifade eder. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Bu etkinlikten sonraki adımlara kadar geçen süreyi analiz ederek ilk veri girişi verimliliğini ve genel süreç çevrim süresini ölçebilirsiniz.
Nereden alınır?
Bu olay genellikle GL_JE_HEADERS tablosundaki belirli bir Yevmiye Kaydı Kimliği için oluşturulma tarihi zaman damgasından çıkarılır. Kaydı oluşturan kullanıcı bilgisi de bu tabloda bulunur.
Kaydedin
GL_JE_HEADERS tablosundaki CREATION_DATE alanını kullanın.
Olay türü
inferred
|
|||
|
Yevmiye kaydı onaya gönderildi
|
Bu etkinlik, kullanıcı tamamlanmış yevmiye kaydını resmî olarak onay iş akışına gönderdiğinde gerçekleşir. Böylece kayıt taslak veya eksik durumdan onay bekleyen duruma geçer. | ||
|
Neden önemli?
Bu önemli aşama, onay çevrim sürelerinin ölçümünü başlatır ve darboğazların belirlenmesini sağlar. Veri girişi aşamasını inceleme ve onay aşamasından ayırır.
Nereden alınır?
Bu olay, GL_JE_HEADERS tablosundaki durum değişikliğinden çıkarılır. Özellikle APPROVAL_STATUS_CODE alanı 'REQUIRED' veya 'INITIATED' gibi bir değere geçtiğinde gerçekleşir. Gönderim tarihinin zaman damgası da kaydedilmiş olabilir.
Kaydedin
Gönderimi belirten değişiklik gerçekleştiğinde GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE alanının zaman damgasını izleyin.
Olay türü
inferred
|
|||
|
Yevmiye kaydı onaylandı
|
Yetkili onaylayan, doğruluğunu ve geçerliliğini teyit ederek yevmiye kaydını resmen onaylamıştır. Bu, onay iş akışının son adımıdır ve kaydın muhasebeleştirilmesinin önünü açar. | ||
|
Neden önemli?
Bu kilometre taşı, onay sürecinin sona erdiğini gösterir. Gönderim ile onay arasındaki süre, iş akışının verimliliğini ölçmek ve onay sürecindeki darboğazları belirlemek için önemli bir KPI’dır.
Nereden alınır?
Bu olay, GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE alanının 'APPROVED' olarak güncellenmesiyle anlaşılıyor. İş akışı tablolarında onaylayanın kimliği ve zaman damgası bulunur.
Kaydedin
GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE alanı 'APPROVED' olarak değiştiğinde oluşan zaman damgasını izleyin.
Olay türü
inferred
|
|||
|
Destekleyici belgeler eklendi
|
Fatura veya elektronik tablo gibi destekleyici belgelerin yevmiye kaydına eklenmesini ifade eder. Bu işlem genellikle denetçilere ve onaylayanlara bağlam ve kanıt sunmak için yapılır. | ||
|
Neden önemli?
Bu etkinliği 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 bilgi verir.
Nereden alınır?
Bu etkinliği ayrı bir olay olarak izlemek zor olabilir. GL_JE_HEADERS tablosundaki yevmiye kaydıyla ilişkilendirilmiş FND_ATTACHED_DOCUMENTS gibi ek tablolarındaki zaman damgalarından çıkarılabilir.
Kaydedin
Yevmiye kaydıyla ilişkilendirilmiş FND_ATTACHED_DOCUMENTS kayıtlarının oluşturulma tarihinden çıkarın.
Olay türü
inferred
|
|||
|
Muhasebeleştirme doğrulandı
|
Muhasebeleştirme sonrasında kullanıcı veya sistem, yevmiye kaydının doğru işlendiğini ve bakiyelerin beklendiği gibi olduğunu doğrular. Bu adım genellikle manuel bir kontroldür. | ||
|
Neden önemli?
Bu etkinliği incelemek, muhasebeleştirme sonrasındaki manuel kontroller ve kalite güvencesi için harcanan süreyi anlamaya yardımcı olur. Doğrulama süreçlerinin otomatikleştirilebileceği alanları da ortaya çıkarabilir.
Nereden alınır?
Oracle Fusion’da bunun açıkça kaydedilen bir olay olması pek olası değildir. Belirli bir raporun çalıştırılması veya standart olmayan özel bir durum alanının güncellenmesi gibi başka işlemlerden çıkarılması gerekir.
Kaydedin
Doğrulama raporlarının çalıştırılma zamanını veya açıklayıcı esnek alan güncellemelerini izlemek gibi özel bir mantık gerektirir.
Olay türü
inferred
|
|||
|
Yevmiye kaydı düzeltildi ve yeniden gönderildi
|
Yevmiye kaydı reddedildikten sonra kaydı oluşturan kişi gerekli düzeltmeleri yapar ve onay için yeniden gönderir. Bu etkinlik, aynı yevmiye kaydı için yeni bir onay çevriminin başlangıcını gösterir. | ||
|
Neden önemli?
Süreçteki verimsizlikleri anlamak için yeniden çalışmayı izlemek önemlidir. Bu etkinlik, 'Yevmiye kaydı reddedildi' etkinliğiyle birlikte yeniden çalışma süresini ve sıklığını ölçmenizi sağlar.
Nereden alınır?
Daha önce 'REJECTED' durumunda olan bir yevmiye için sonradan gerçekleşen 'Journal Submitted For Approval' olayıdır. Tek bir yevmiye kaydı kimliğine ait durum değişikliklerinin sırası incelenerek belirlenir.
Kaydedin
Aynı vaka kimliği için ret olayından sonra gerçekleşen gönderim olayının zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Yevmiye kaydı incelendi
|
Bu inceleme adımı, resmî onay sürecinden önce veya sürecin bir parçası olarak gerçekleşebilir. Bir çalışma arkadaşının ya da yöneticinin, kaydın son onaylayana iletilmeden önce doğruluğunu ve uyumluluğunu kontrol etmesini ifade eder. | ||
|
Neden önemli?
Bu etkinliği ayrı izlemek, ön inceleme süresiyle nihai onay süresini birbirinden ayırmaya yardımcı olur. İnceleme aşaması resmî olmasa da uzun sürüyorsa gizli darboğazları ortaya çıkarabilir.
Nereden alınır?
Bu, çok aşamalı bir onay iş akışında açıkça tanımlanmış bir adım olabilir ve iş akışı geçmişi tablolarında tutulabilir. Gayriresmî bir inceleme kaydedilmez. Son onay kararından önce belirli bir kullanıcı eylemi kaydedilmişse bu adımdan çıkarılabilir.
Kaydedin
Nihai 'Onaylandı' durumundan önceki ara onay veya inceleme adımları için iş akışı geçmişi tablolarını analiz edin.
Olay türü
inferred
|
|||
|
Yevmiye kaydı reddedildi
|
Onaylayan, yevmiye kaydını incelemiş ve hata, eksik belge veya politika ihlali nedeniyle reddetmiştir. Bu işlem, kaydı düzeltmesi için oluşturana geri gönderir. | ||
|
Neden önemli?
Bu etkinlik, yeniden çalışma döngülerini, ret oranlarını ve ilk seferde doğru tamamlama metriklerini analiz etmek için önemlidir. Retlerin sık yaşanması, veri kalitesi veya eğitimle ilgili sorunlara işaret eder.
Nereden alınır?
Bu olay, GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE alanı 'REJECTED' olarak güncellendiğinde gerçekleşen durum değişikliğinden çıkarılır. İş akışı geçmişinde bu işlemi yapan kullanıcı ve zaman damgası kaydedilir.
Kaydedin
GL_JE_HEADERS tablosundaki APPROVAL_STATUS_CODE alanı 'REJECTED' olarak ayarlandığında oluşan zaman damgasını izleyin.
Olay türü
inferred
|
|||
|
Yevmiye kaydının muhasebeleştirilmesi başlatıldı
|
Onaylanan yevmiye kaydının Büyük Deftere işlenmesi başlatılmıştır. Bu adım otomatik veya manuel olabilir; yevmiye kaydı, muhasebeleştirme programı tarafından işlenmek üzere sıraya alınır. | ||
|
Neden önemli?
Bu etkinlik, onay ile teknik muhasebeleştirme sürecini birbirinden ayırır. Onay ile muhasebeleştirmenin başlatılması arasındaki gecikmeler, zamanlama sorunlarına veya muhasebeleştirme motorundaki kaynak kısıtlarına işaret edebilir.
Nereden alınır?
Bu olay, GL_JE_BATCHES tablosundaki durum değişikliklerinden veya yevmiye grubuyla ilişkili eşzamanlı muhasebeleştirme isteğinin gönderim zamanından çıkarılabilir.
Kaydedin
Belirli yevmiye grubu için Büyük Defter muhasebeleştirme programının istek gönderim zamanını belirleyin.
Olay türü
inferred
|
|||
|
Yevmiye kaydının ters kaydı işlendi
|
Önceki dönemdeki özgün yevmiye kaydının finansal etkisini sıfırlamak için ters kayıt oluşturulmuş ve muhasebeleştirilmiştir. Tahakkuklarda sıkça kullanılan bir işlemdir. | ||
|
Neden önemli?
Ters kayıtları izlemek, hangi kayıtların sıkça ters çevrildiğini belirlemeye ve ters kayıt sürecinin verimliliğini incelemeye yardımcı olur. Bu durum, tahakkuk yönetimindeki sorunlara işaret edebilir.
Nereden alınır?
Özgün kayda açıkça ters kayıt olarak bağlanan yeni bir yevmiye kaydı belirlenerek çıkarılır. GL_JE_HEADERS tablosundaki REVERSAL_PERIOD ve REVERSAL_FLAG gibi alanlar, bu kayıtları belirlemeye ve ilişkilendirmeye yarar.
Kaydedin
Üstbilgisinde özgün yevmiye kaydının ters çevrildiğini belirten yeni yevmiye kaydının oluşturulma ve muhasebeleştirilme tarihlerini belirleyin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Oracle Fusion yevmiye kaydı verilerinizi uygulanabilir içgörülere dönüştürmek ve Kayıttan Raporlamaya çevrimini hızlandırmak için bu Templateten yararlanın. Finansal operasyonlarınızı iyileştirmeye bugün başlayın.
Kayıttan Raporlamaya - yevmiye kaydı sürecinizi bugün hızlandırın
Yevmiye kaydı çevrim süresini %30 azaltın ve finansal operasyonlarınızı kolaylaştırın.
Kredi kartı gerekmez, denemenizi şimdi etkinleştirin.