Kayıttan Raporlamaya - Yevmiye Kaydı Veri Templateiniz
Kayıttan Raporlamaya - Yevmiye Kaydı Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Microsoft Dynamics 365 için veri çıkarma rehberi
Kayıttan Raporlamaya - yevmiye kaydı öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik adı
ActivityName
|
Gerçekleşen belirli iş süreci adımının veya olayın adı. | ||
|
Açıklama
Bu öznitelik, Journal Entry yaşam döngüsündeki tek bir olayı veya görevi açıklar. Örneğin 'Journal Entry Created', 'Journal Submitted For Approval' veya 'Journal Entry Posted'. Bu etkinlikler, keşfedilen süreç haritasının düğümlerini oluşturur. Bu etkinliklerin sırasını ve sıklığını analiz etmek Process Mining'in temelini oluşturur. Gerçek süreç akışını ortaya çıkarır, standart prosedürden sapmaları belirlemenize yardımcı olur ve etkinliklerin beklenenden uzun sürdüğü veya tekrarlandığı darboğazları gösterir.
Neden önemli?
Bu öznitelik süreçteki adımları tanımlar, süreç haritasının temelini oluşturur ve süreç akışı ile varyasyonlarını analiz etmenizi sağlar.
Nereden alınır?
Bu, Microsoft Dynamics 365 içindeki sistem olaylarından, durum değişikliklerinden veya Workflow günlüklerinden türetilen kavramsal bir özniteliktir.
Örnekler
Journal Entry oluşturulduJournal onaya gönderildiJournal onaylandıJournal Entry kaydedildi
|
|||
|
Olay zamanı
EventTime
|
Bir etkinliğin veya olayın gerçekleştiği anı gösteren kesin zaman damgası. | ||
|
Açıklama
Event Time, yevmiye kaydı sürecindeki belirli bir etkinliğin gerçekleştiği tarih ve saati kaydeder. Bu kronolojik veri, olayları sıralamak ve aralarındaki süreyi hesaplamak için gereklidir. Analizde bu zaman damgası, her vaka için zaman çizelgesini oluşturmak üzere kullanılır. Çevrim süreleri, işlem süreleri ve bekleme süreleri gibi zamana dayalı tüm metrikleri hesaplamak için önemlidir. Adımlar arasındaki gecikmelerin belirlenmesini sağlar ve darboğazlar ile SLA uyumluluğuna ilişkin Dashboardları destekler.
Neden önemli?
Bu zaman damgası, olayları doğru sıralamak ve çevrim süresi ile işlem gecikmeleri gibi süreye dayalı tüm KPI'ları hesaplamak için gereklidir.
Nereden alınır?
Olay zaman damgaları genellikle Workflow geçmişi günlüklerinde, denetim izi tablolarında, örneğin SysDatabaseLog'da, veya LedgerJournalTable ve LedgerJournalTrans gibi ilişkili kayıtlardaki oluşturma ve değiştirme zaman damgalarında bulunur.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
|
|||
|
Yevmiye kaydı ID'si
JournalEntryId
|
Bir Journal Entry için birincil vaka tanımlayıcısı olarak kullanılan benzersiz tanımlayıcı. | ||
|
Açıklama
Journal Entry ID, tek bir Journal Entry işlemiyle ilişkili tüm etkinlikleri ve veri noktalarını benzersiz biçimde birbirine bağlar. Journal'ın oluşturulmasından ve incelenmesinden genel defterdeki son kaydına kadar yaşam döngüsünü uçtan uca izlemenizi sağlar. Process Mining analizinde bu öznitelik, süreç akışını yeniden oluşturmak için temel öneme sahiptir. Her benzersiz Journal Entry ID, sürecin tek bir örneğini temsil eder. Böylece tek tek finansal işlemler için süreç varyantlarını, çevrim sürelerini ve uyumluluğu ayrıntılı biçimde inceleyebilirsiniz.
Neden önemli?
Bu, bir Journal Entry'yi başlangıçtan sona kadar izlemek için gereken temel anahtardır ve her vaka için tüm süreç akışını analiz etmenizi sağlar.
Nereden alınır?
Bu tanımlayıcı genellikle LedgerJournalTable gibi journal header tablosunda, çoğu zaman JournalNum adlı bir alanda bulunur.
Örnekler
JRN-0012345JV-2023-08-156GENJ0000891
|
|||
|
Journal durumu
JournalStatus
|
Journal Entry'nin mevcut veya son durumu. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydının belirli bir andaki durumunu gösterir. Draft, In Review, Approved, Rejected veya Posted buna örnektir. Kaydın yaşam döngüsünde nerede bulunduğuna ilişkin bir anlık görünüm sunar. Durumu analiz etmek, vakaların sonuçlarını anlamaya yardımcı olur. Tüm reddedilen yevmiye kayıtlarını filtrelemek veya belirli bir aşamadaki kayıt hacmini izlemek için kullanılabilir. Bu öznitelik, işlem hacmi ve durum analizine bağlam sağlayarak birden fazla Dashboardı destekler.
Neden önemli?
Her Journal Entry için net bir sonuç sunar ve başarı oranlarını, ret oranlarını ve farklı aşamalardaki iş hacmini analiz etmenizi sağlar.
Nereden alınır?
Durum genellikle journal header tablosu olan LedgerJournalTable'da bulunur veya Workflow durumundan türetilir.
Örnekler
TaslakGönderildiOnaylandıKaydedildiReddedildi
|
|||
|
Journal türü
JournalType
|
Journal Entry'nin General Journal veya Accrual gibi sınıflandırması. | ||
|
Açıklama
Journal Type, kayıtları iş amaçlarına göre sınıflandırır. Günlük kayıtlar, tahakkuklar, dağıtımlar veya eliminasyonlar buna örnek verilebilir. Bu segmentasyon, farklı süreç yollarını ve davranışlarını anlamak için önemlidir. Bu öznitelik, süreci farklı yevmiye kaydı türlerine göre filtrelemenizi ve karşılaştırmanızı sağlar. Journal Entry Throughput Volume by Type Dashboardı için gereklidir. Belirli kayıt türlerinin gecikme, ret veya yeniden çalışmaya daha yatkın olup olmadığını analiz etmenize yardımcı olur.
Neden önemli?
Analizi farklı iş amaçlarına göre segmentlere ayırmanızı sağlar. Bu amaçların süreç yolları, çevrim süreleri ve onay gereksinimleri farklı olabilir.
Nereden alınır?
Bu bilgi genellikle journal header tablosu olan LedgerJournalTable'da, journal adları veya türleriyle ilişkili bir alanda, örneğin JournalName'de saklanır.
Örnekler
Genel yevmiyeTahakkuk düzeltmesiŞirketler arası transferBordro
|
|||
|
Kullanıcı adı
UserName
|
Etkinliği gerçekleştiren kullanıcının adı. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydı oluşturma, onaylama veya kaydetme gibi belirli bir etkinliği gerçekleştirmekten sorumlu çalışanı veya sistem kullanıcısını belirler. Süreç adımlarını insan kaynaklarıyla ilişkilendirir. Kullanıcıya göre performans analizi, Process Mining’in temel yeteneklerinden biridir. Journal Entry User Performance Dashboardını oluşturarak farklı kullanıcılar veya ekipler arasındaki etkinlik sürelerini ve işlem hacmini karşılaştırmanıza yardımcı olur. Bu analiz, en iyi performans gösterenleri öne çıkarabilir, eğitim ihtiyaçlarını belirleyebilir ve iş yükünün dengelenmesine yardımcı olabilir.
Neden önemli?
Süreç etkinliklerini belirli kişilerle ilişkilendirerek kullanıcı performansını, iş yükü dağılımını ve kaynak tahsisini analiz etmenizi sağlar.
Nereden alınır?
Kullanıcı bilgileri genellikle LedgerJournalTable gibi tablolardaki createdBy veya modifiedBy alanlarında ya da ilişkili Workflow geçmişi günlüklerinde bulunur.
Örnekler
Alice SmithBob Johnsonsystem.batch
|
|||
|
Olay bitiş zamanı
EventEndTime
|
Bir etkinliğin veya olayın tamamlandığı anı gösteren zaman damgası. | ||
|
Açıklama
Event End Time, belirli bir etkinliğin tamamlandığı anı gösterir. StartTime bir etkinliğin ne zaman başladığını belirtirken EndTime diğer sınırı sağlar ve tek tek görevlerin süresinin hassas biçimde hesaplanmasına imkan verir. Process Mining içinde hem başlangıç hem de bitiş zamanının bulunması, etkinlik işlem süresinin hesaplanmasını sağlar. Bu süre bekleme süresinden farklıdır. Kullanıcı performansını analiz eden ve yalnızca adımlar arasındaki boşlukları değil, en fazla zamanı hangi görevlerin tükettiğini belirleyen Dashboardlar için önemlidir.
Neden önemli?
Her etkinliğin ne kadar sürdüğünü kesin biçimde hesaplamanızı sağlar. Bu, kullanıcı performansını analiz etmek ve kaynak tüketimi yüksek görevleri belirlemek için önemlidir.
Nereden alınır?
Bu veri Workflow günlüklerinde açıkça saklanabilir veya dizideki sonraki etkinliğin StartTime değeri kullanılarak türetilmesi gerekebilir.
Örnekler
2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Ret nedeni
RejectionReason
|
Onay sürecinde bir Journal Entry reddedildiğinde belirtilen neden. | ||
|
Açıklama
Bir yevmiye kaydı reddedildiğinde onaylayan kişi çoğu zaman ret nedeni belirtir. Bu öznitelik, kök neden analizi için çok değerli olan bu bilgiyi yakalar. Journal Entry Rejection Rate Analysis Dashboardının temel özniteliğidir. Kuruluşlar ret nedenlerini kategorilere ayırıp analiz ederek yanlış belgeler, politika ihlalleri veya veri girişi hataları gibi yaygın sorunları belirleyebilir. Ardından hedefli eğitimler veya süreç iyileştirmeleri uygulayabilir.
Neden önemli?
Yeniden çalışmanın neden gerçekleştiğini açıklar. Ret oranlarını azaltmak ve ilk seferde doğru onayları artırmak için gereken doğrudan içgörüyü sağlar.
Nereden alınır?
Bu bilgi genellikle ret adımıyla ilişkili Workflow geçmişinde veya yorumlar bölümünde saklanır.
Örnekler
Destekleyici belgeler yetersizHatalı hesap kullanıldıOnay eşiği aşıldıYinelenen kayıt
|
|||
|
Tüzel Kişilik
LegalEntity
|
Yevmiye kaydının oluşturulduğu tüzel kişilik veya şirket kodu. | ||
|
Açıklama
Tüzel Kişilik, finansal işlemin kaydedildiği kuruluş içindeki belirli şirketi veya iş birimini ifade eder. Finansal sistemlerde temel bir organizasyon boyutudur. Process Mining kapsamında bu öznitelik, yevmiye kaydı sürecini kuruluşun farklı bölümleri arasında karşılaştırmanızı sağlar. Belirli tüzel kişiliklerin daha verimli süreçlere, daha yüksek ret oranlarına veya daha uzun çevrim sürelerine sahip olup olmadığını ortaya çıkararak en iyi uygulamaların belirlenmesine ve paylaşılmasına yardımcı olabilir.
Neden önemli?
Farklı şirketler veya iş birimleri arasındaki süreç performansını karşılaştırmanızı, farklılıkları ve iyileştirme fırsatlarını görmenizi sağlar.
Nereden alınır?
Bu, Dynamics 365 içindeki temel alanlardan biridir. Genellikle LedgerJournalTable gibi işlem tablolarında bulunur ve çoğunlukla DataAreaId ile ilişkilidir.
Örnekler
USMFDEMFGBSI
|
|||
|
Yevmiye Toplam Tutarı
JournalTotalAmount
|
Yevmiye kaydının toplam parasal değeri, genellikle borç tutarlarının toplamıdır. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydının toplam finansal değerini ifade eder. Kayıtları düşük, orta ve yüksek değer gibi değer aralıklarına ayırmak için kullanılabilir. Süreci finansal değere göre analiz etmek önemli örüntüleri ortaya çıkarabilir. Örneğin, yüksek değerli yevmiye kayıtları daha fazla adım içeren ve daha uzun çevrim sürelerine sahip, daha sıkı bir onay sürecinden geçebilir. Bu öznitelik, önemlilik analizleri ve süreç verimsizliklerinin finansal etkisini anlamak için gereklidir.
Neden önemli?
Süreci finansal değere göre segmentlere ayırmanızı sağlar. Finansal değer çoğu zaman süreç karmaşıklığı, risk ve onay iş akışlarıyla ilişkilidir.
Nereden alınır?
Bu değerin, her yevmiye kaydı için yevmiye satırı tablosundaki LedgerJournalTrans borç tutarlarının toplanmasıyla hesaplanması gerekebilir.
Örnekler
1500.75125000.0050.25
|
|||
|
Departman
DepartmentName
|
Yevmiye kaydıyla ilişkili departman veya maliyet merkezi. | ||
|
Açıklama
Departman veya maliyet merkezi, finansal işlemden sorumlu olan ya da işlemden etkilenen iç iş birimini tanımlar. İç yönetim raporlaması için önemli bir boyuttur. Bu öznitelik, yevmiye kaydı sürecini departman bazında analiz etmenizi sağlar. Hangi departmanların en fazla yevmiye kaydı gönderdiği, belirli departmanlarda ret oranlarının veya onay sürelerinin daha yüksek olup olmadığı gibi sorulara yanıt vermenize yardımcı olabilir. Hedefli süreç iyileştirme çalışmaları için faydalıdır.
Neden önemli?
Süreç performansını işlev bazında analiz etmenizi sağlar; departmana özgü darboğazları veya eğitim ihtiyaçlarını belirlemenize yardımcı olur.
Nereden alınır?
Bu bilgi genellikle yevmiye satırı düzeyinde, LedgerJournalTrans içinde bir finansal boyut olarak bulunur.
Örnekler
SatışFinansPazarlamaOperasyonlar
|
|||
|
İlk Seferde Doğru mu
IsFirstTimeRight
|
Yevmiye kaydının daha önce reddedilmeden onaylanıp onaylanmadığını belirten işaret. | ||
|
Açıklama
Bu vaka düzeyindeki boolean öznitelik, yevmiye kaydı gönderimden onaya kadar arada 'Yevmiye Kaydı Reddedildi' veya 'Yevmiye Kaydı Düzeltildi' etkinlikleri olmadan ilerlediğinde true olur. Süreç kalitesinin temel ölçütlerinden biridir. 'İlk Seferde Doğru Onay Oranı' KPI'ı doğrudan bu öznitelikten hesaplanır. Yüksek oran, verimli ve kaliteli bir sürece işaret eder. Düşük oran ise ilk veri kalitesi, gereksinimlerin açıklığı veya gönderim prosedürleriyle ilgili sistemik sorunları gösterir.
Neden önemli?
Bu, süreç kalitesinin önemli bir ölçütüdür. Herhangi bir yeniden çalışma olmadan onay sürecinden sorunsuz geçen yevmiye kayıtlarının sayısını gösterir.
Nereden alınır?
Bu, her Journal Entry ID için etkinlik sırası analiz edilerek vaka düzeyinde elde edilen hesaplanmış bir özniteliktir.
Örnekler
truefalse
|
|||
|
Kayıt Tarihi
PostingDate
|
Yevmiye kaydının genel muhasebeye işlendiği tarih. | ||
|
Açıklama
Kayıt Tarihi, işlemin genel muhasebe bakiyelerini etkilediği resmi tarihtir. Bu tarih, finansal raporlama ve dönem kapanışları için önemlidir. Bu öznitelik, onay ile kayıt arasındaki gecikmeyi analiz etmek için kullanılır. Bu analiz, Yevmiye Kaydı İşleme Süresi KPI'ının temelini oluşturur. Bu gecikmeyi azaltmak, finansal kapanış sürecini hızlandırmak için çoğu zaman önemli bir hedeftir. Ayrıca zaman içindeki kayıt hacimlerini analiz etmek için de kullanılabilir.
Neden önemli?
Kayıt işlemi süresi KPI'ını hesaplamak ve onay ile işlemin muhasebe defterinde resmileşmesi arasındaki gecikmeleri anlamak için gereklidir.
Nereden alınır?
Bu tarih genellikle yevmiye başlığı tablosunda, LedgerJournalTable içinde veya ilgili kaydedilmiş işlem tablolarında saklanır.
Örnekler
2023-10-282023-11-012023-10-31
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin çıkarıldığı kayıt sistemi. | ||
|
Açıklama
Bu öznitelik, Journal Entry verilerinin geldiği kaynak uygulamayı tanımlar. Bu süreçte değer genellikle 'Microsoft Dynamics 365' gibi sabit bir değerdir. Daha geniş analizlerde, özellikle birden fazla ERP veya entegre sistem bulunan ortamlarda bu alan, süreçleri ve veri kaynaklarını birbirinden ayırmaya yardımcı olur. Veri kaynağının net biçimde izlenmesini sağlar ve veri yönetişimi ile doğrulama açısından önemlidir.
Neden önemli?
Verilerin kaynağını tanımlar. Bu bilgi, veri yönetişimi ve birden fazla kurumsal sistemi kapsayabilecek analizler için önemlidir.
Nereden alınır?
Bu, Veri Setinin kaynağını belirtmek üzere veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen statik bir değerdir.
Örnekler
Microsoft Dynamics 365D365 F&O
|
|||
|
Onay Düzeyi
ApprovalLevel
|
Çok düzeyli bir onay iş akışındaki mevcut veya tamamlanmış aşamayı gösterir. | ||
|
Açıklama
Birden fazla onay gerektiren yevmiye kayıtlarında bu öznitelik, kaydın hiyerarşinin hangi düzeyine ulaştığını izler. Örneğin 'Yönetici Onayı' veya 'Direktör Onayı'. Bu öznitelik, onay darboğazlarını daha ayrıntılı analiz etmek için faydalıdır. Gecikmelerin onay zincirinin belirli bir düzeyinde sürekli olarak yaşanıp yaşanmadığını belirlemenize yardımcı olabilir. Böyle bir durum, ilgili aşamada süreç yeniden tasarımı veya kaynakların yeniden dağıtılması gerektiğine işaret edebilir.
Neden önemli?
Çok aşamalı onay iş akışlarını görünür kılar ve belirli onay düzeylerindeki darboğazların belirlenmesine yardımcı olur.
Nereden alınır?
Bu bilgi, farklı onay adımlarının tamamlanmasını izleyen Workflow geçmişi günlüğünden elde edilir.
Örnekler
1. seviye: Yönetici2. seviye: Direktör3. seviye: Finans Başkan Yardımcısı
|
|||
|
Onay SLA Durumu
ApprovalSlaState
|
Yevmiye kaydı onayının hizmet seviyesi sözleşmesinde belirtilen hedefi karşılayıp karşılamadığını belirtir. | ||
|
Açıklama
Bu öznitelik, her yevmiye kaydının onay döngüsünü, Service Level Agreement (SLA) tarafından belirlenen hedef süre içinde tamamlanıp tamamlanmadığına göre kategorilere ayırır. Olası değerler genellikle Met veya Breached şeklindedir. Journal Entry Approval SLA Compliance Dashboardının temel metriğidir. Hedeflere göre performansı iş odaklı ve net biçimde gösterir. Onay sürecinin zamanında tamamlanmasını izlemenize, yönetmenize ve SLA hedeflerinin sıkça kaçırıldığı alanlarda iyileştirmeler yapmanıza yardımcı olur.
Neden önemli?
Ham çevrim süresi verilerini, hedeflere göre performansı kolayca izlemenizi sağlayan net bir iş sonucuna, karşılandı veya ihlal edildi durumuna dönüştürür.
Nereden alınır?
Bu, hesaplanmış bir özniteliktir. Mantık, hesaplanan Onay Çevrim Süresi KPI'ının önceden belirlenmiş bir SLA hedefiyle karşılaştırılmasını gerektirir.
Örnekler
Karşılandıİhlal edildi
|
|||
|
Otomatik Kayıt mı
IsAutomatedPosting
|
Yevmiye kaydının otomatik olarak oluşturulup oluşturulmadığını veya işlendiğini belirten işaret. | ||
|
Açıklama
Bu boolean öznitelik, kullanıcı tarafından manuel olarak oluşturulan yevmiye kayıtlarıyla sistem veya bir alt sistem tarafından otomatik olarak oluşturulan kayıtları birbirinden ayırır. Örneğin bir sistem entegrasyonu veya otomatik dağıtım süreci bu kayıtları oluşturabilir. Bu özniteliği analiz ederek otomatik ve manuel süreçlerin verimliliğini ve hata oranlarını karşılaştırabilirsiniz. Manuel kayıtların hatalara, yeniden çalışmaya veya gecikmelere daha yatkın olup olmadığını göstererek daha fazla otomasyon fırsatlarını ortaya çıkarabilir.
Neden önemli?
Manuel ve otomatik süreçleri birbirinden ayırarak verimlilik, doğruluk ve uyumluluk açısından karşılaştırma yapmanızı sağlar.
Nereden alınır?
Bu durum, 'Oluşturan' kullanıcı alanında bir sistem veya toplu işlem kullanıcısının görünmesiyle ya da yevmiye başlığında veya tür yapılandırmasında bulunan belirli bir işaretle belirtilebilir.
Örnekler
truefalse
|
|||
|
Para Birimi Kodu
CurrencyCode
|
Yevmiye kaydı tutarının para birimi. | ||
|
Açıklama
Bu öznitelik, yevmiye kaydının USD, EUR veya GBP gibi hangi para birimi üzerinden ifade edildiğini belirtir. Yevmiye Toplam Tutarı için gerekli bağlamı sağlar. Para birimi, süreç akışını analiz etmek için her zaman kullanılmasa da yevmiye tutarlarına dayalı finansal raporlama ve analiz için önemlidir. Özellikle çok uluslu kuruluşlarda değerlerin doğru şekilde toplanmasını ve karşılaştırılmasını sağlar.
Neden önemli?
Finansal analizler için gerekli bağlamı sağlar ve özellikle çok para birimli ortamlarda parasal değerlerin doğru yorumlanmasına yardımcı olur.
Nereden alınır?
Para birimi kodu genellikle yevmiye satırı tablosu olan LedgerJournalTrans içinde bulunur.
Örnekler
USDEURGBPJPY
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden en son yenilendiği zaman damgası. | ||
|
Açıklama
Bu öznitelik, kaynak sistemden en son veri çıkarma işleminin tarih ve saatini gösterir. Analizin ve içerdiği verilerin güncelliği hakkında bağlam sağlar. Bu bilgiyi Dashboardlarda göstermek, kullanıcıların verilerin zamanında hazırlandığını görmesini ve mevcut süreç analizinin kapsadığı zaman aralığını anlamasını sağlar. Her Process Mining projesi için önemli bir üst veri parçasıdır.
Neden önemli?
Verilerin güncelliği hakkında önemli bağlam sağlar ve kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasına yardımcı olur.
Nereden alınır?
Bu zaman damgası, veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde oluşturulur ve saklanır.
Örnekler
2023-10-27T02:00:00Z
|
|||
|
Yeniden Çalışma mı
IsRework
|
Yeniden çalışma veya düzeltme döngüsünün parçası olan etkinlikleri belirten işaret. | ||
|
Açıklama
Bu hesaplanan boolean öznitelik, Journal Entry Corrected veya tekrarlanan Journal Submitted For Approval gibi ret sonrasında gerçekleşen etkinlikler için true değerini alır. Yeniden çalışmayı ayırmanıza ve ölçmenize yardımcı olur. Bu öznitelik, Journal Entry Rework and Correction Loops Dashboardı ve Rework Rate KPI için gereklidir. Yeniden çalışmayı işaretlediği için düzeltme döngülerinin sıklığını ve etkisini kolayca görselleştirip ölçebilirsiniz. Bu döngüler, süreçteki verimsizliğin başlıca kaynaklarından biridir.
Neden önemli?
Verimsiz yeniden çalışma döngülerini doğrudan işaretler; ret ve düzeltmelerin genel çevrim süresi ile maliyet üzerindeki etkisini kolayca ölçmenizi sağlar.
Nereden alınır?
Bu, bir vaka içindeki etkinlik sırası analiz edilerek veri dönüşümü sırasında elde edilen hesaplanmış bir özniteliktir.
Örnekler
truefalse
|
|||
Kayıttan Raporlamaya - yevmiye kaydı aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Journal Entry kaydedildi
|
Bu etkinlik, Journal Entry'nin genel deftere başarıyla kaydedilmesini ve resmî bir finansal kayıt hâline gelmesini gösterir. Journal header durumu 'Posted' olarak güncellendiğinde yakalanan önemli bir olaydır. | ||
|
Neden önemli?
Bu, sürecin temel başarılı bitiş olayıdır. Finansal kapanış verimliliğinin önemli göstergeleri olan uçtan uca çevrim süresini ve kayıt için geçen süreyi hesaplamak için kullanılır.
Nereden alınır?
LedgerJournalTable üzerindeki durum alanı değişikliğinden, örneğin JournalStatus değerinin 'Posted' olması, ve GeneralJournalAccountEntry tablosunda ilgili kayıtların oluşturulmasından alınır.
Yakalayın
Journal durumunun 'Posted' olduğu zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Journal Entry oluşturuldu
|
Bu etkinlik yeni bir Journal Entry oluşturulmasını başlatır. Kullanıcı sistemde yeni bir journal header kaydı oluşturduğunda yakalanır ve süreç analizi için vaka tanımlayıcısı olarak kullanılan benzersiz bir Journal Entry ID oluşturur. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Bu noktadan kayda kadar geçen süreyi analiz etmek, uçtan uca çevrim süresini ölçmek ve ilk veri girişi gecikmelerini belirlemek için önemlidir.
Nereden alınır?
Bu olay, GeneralJournalEntry veya LedgerJournalTable varlığındaki journal header oluşturma zaman damgasından alınır. Genellikle açık bir kayıt oluşturma olayıdır.
Yakalayın
GeneralJournalEntry veya LedgerJournalTable üzerindeki createdDateTime alanını kullanın.
Olay türü
explicit
|
|||
|
Journal onaya gönderildi
|
Tamamlanan bir yevmiye kaydının inceleme ve onay iş akışına resmi olarak gönderilmesini ifade eder. Bu durum genellikle yevmiye kaydı üst bilgisindeki Draft durumundan In Review veya Submitted durumuna geçiş gibi bir durum değişikliğinden anlaşılır. | ||
|
Neden önemli?
Bu, onay döngüsünü başlatan önemli bir kilometre taşıdır. Gönderimden son onaya kadar geçen süreyi ölçmek, inceleme sürecindeki darboğazları belirlemek ve SLA uyumluluğunu izlemek için önemlidir.
Nereden alınır?
LedgerJournalTable üzerindeki bir durum alanı değişikliğinden, örneğin ApprovalStatus değerinin 'InReview' olması, veya journal ile ilişkili Workflow geçmişi günlüklerinden anlaşılır.
Yakalayın
Journal durumunun 'submitted' veya 'in review' durumuna geçtiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Journal onaylandı
|
Yevmiye kaydı, belirlenen yetkili tarafından onaylanmış ve onay iş akışındaki son adım tamamlanmıştır. Bu durum genellikle yevmiye kaydı üst bilgisinin Approved durumuna geçmesi gibi bir durum değişikliğinden alınır. | ||
|
Neden önemli?
Bu, onay sürecini tamamlayan ve kayda izin veren önemli bir kilometre taşıdır. Onay çevrim süresini, kayıt için geçen süreyi ve ilk seferde doğru oranını hesaplamak için gereklidir.
Nereden alınır?
LedgerJournalTable üzerindeki bir durum alanı değişikliğinden, örneğin ApprovalStatus değerinin 'Approved' olması, veya Workflow geçmişi tablosunda son onay durumunun gösterilmesinden anlaşılır.
Yakalayın
Journal durumunun 'Approved' olarak değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Journal reddedildi
|
Journal Entry, inceleyen veya onaylayan kişi tarafından reddedilir ve düzeltme gerektirir. Bu olay, journal durumunun 'Rejected' veya 'Needs Correction' durumuna geçmesiyle yakalanır. | ||
|
Neden önemli?
Retleri izlemek, ret oranını hesaplamak ve yeniden çalışmanın temel nedenlerini belirlemek için gereklidir. Veri kalitesi, uyumluluk veya kullanıcı eğitimiyle ilgili sorunları ortaya çıkarır.
Nereden alınır?
LedgerJournalTable üzerindeki bir durum alanı değişikliğinden, örneğin ApprovalStatus değerinin 'Rejected' olması, veya Workflow geçmişi günlüğünden anlaşılır.
Yakalayın
Journal durumunun 'Rejected' olarak değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Journal Entry düzeltildi
|
Bu etkinlik, daha önce reddedilmiş bir Journal Entry'nin kullanıcı tarafından değiştirildiğini gösterir. Genellikle 'Rejected' durumu kaydedildikten sonra journal header veya satırlarında yapılan değişiklik belirlenerek anlaşılır. | ||
|
Neden önemli?
Bu etkinlik yeniden çalışmayı açıkça gösterir. Düzeltme döngülerinin sıklığını ve süresini analiz etmek, süreci sadeleştirmenize ve manuel iş yükünü azaltmanıza yardımcı olur.
Nereden alınır?
LedgerJournalTable veya LedgerJournalTrans tablolarındaki modifiedDateTime ve modifiedBy alanları, 'Journal Rejected' olayından sonra izlenerek anlaşılır.
Yakalayın
'Rejected' durumunun zaman damgasını, kaydı oluşturan kişinin sonraki değişiklik zaman damgalarıyla karşılaştırın.
Olay türü
inferred
|
|||
|
Journal Entry ters kaydı tamamlandı
|
Ters kayıt journal'ının başarıyla kaydedildiği Journal Entry ters kayıt sürecinin tamamlandığını gösterir. Hatalı bir journal'ın yaşam döngüsü için alternatif bir bitiş noktasıdır. | ||
|
Neden önemli?
Bu etkinlik düzeltilen kayıtları tamamlar ve kayıt sonrasında yapılan düzeltmeler için harcanan toplam çabayı analiz etmenize yardımcı olur. Bu da genel süreç verimliliğini etkiler.
Nereden alınır?
Yeni ters kayıt journal'ı 'Posted' durumuna geçtiğinde yakalanır. Orijinal journal ile bağlantı bir referans alanı üzerinden korunur.
Yakalayın
İlişkili ters kayıt journal'ı için 'Posted' durum olayını belirleyin.
Olay türü
inferred
|
|||
|
Journal Entry ters kayıt işlemi başlatıldı
|
Bu olay, daha önce kaydedilmiş bir Journal Entry'yi tersine çevirme sürecinin başladığını gösterir. Kullanıcı sistemde ters kayıt işlemini başlattığında yakalanır. | ||
|
Neden önemli?
Ters kayıtları izlemek, kaydedilmiş kayıtların düzeltilme sıklığını ve nedenlerini belirlemeye yardımcı olur. Bu durum, ilk veri girişi veya onay aşamalarındaki temel sorunlara işaret edebilir.
Nereden alınır?
Bu genellikle denetim izlerinden veya orijinal kayıtla ilişkilendirilmiş yeni bir ters kayıt journal'ının oluşturulmasından alınabilen açık bir kullanıcı işlemidir.
Yakalayın
Kaydedilmiş bir journal'ın ters kaydı olarak işaretlenen yeni bir Journal Entry'nin oluşturulma olayını kullanın.
Olay türü
explicit
|
|||
|
Journal incelemesi başladı
|
Bu etkinlik, incelemeyi yapan kişinin gönderilmiş bir journal üzerinde çalışmaya başladığı anı gösterir. Journal'ın bir inceleyene atanmasıyla veya inceleyenin kaydı ilk kez açıp incelemesiyle anlaşılabilir. | ||
|
Neden önemli?
Bu etkinlik, gönderim ile incelemenin başlaması arasındaki gecikme olan inceleyene devir süresini ölçmenize yardımcı olur. Kaynak tahsisi veya bildirim sorunlarını ortaya çıkarabilir.
Nereden alınır?
Bu olay çoğu zaman açıkça günlüğe kaydedilmez. Workflow atama günlüklerinden anlaşılabilir veya gönderim zaman damgası ile inceleyen kullanıcının yaptığı ilk değişiklik zaman damgasının karşılaştırılmasını gerektirebilir.
Yakalayın
Standart olarak bulunmayabilecek Workflow kullanıcı atama günlüklerinin veya kullanıcı etkinlik günlüklerinin analiz edilmesi gerekir.
Olay türü
inferred
|
|||
|
Journal kaydı deneniyor
|
Bu etkinlik, kullanıcının onaylanmış bir journal için kayıt işlemini başlattığını gösterir. Sistem kayıt işinin başlangıcını günlüğe kaydediyorsa açıkça yakalanabilir. | ||
|
Neden önemli?
Kayıt denemesi ile başarılı kaydı birbirinden ayırmak, finansal kapanışı etkileyen sistem performansı sorunlarını veya toplu iş gecikmelerini teşhis etmeye yardımcı olur.
Nereden alınır?
Bu, toplu iş geçmişi tablosunda açıkça günlüğe kaydedilmiş bir olay olabilir veya LedgerJournalTable üzerindeki durumun 'Posting in progress' olarak değişmesinden anlaşılabilir.
Yakalayın
General Ledger kayıt rutiniyle ilişkili toplu iş veya sistem günlüklerinin analiz edilmesi gerekir.
Olay türü
explicit
|
|||
|
Journal Line eklendi
|
Bu olay, Journal Entry'ye bir borç veya alacak satırı eklendiğini gösterir. Journal header ile ilişkilendirilen yeni bir işlem satırı oluşturulduğunda yakalanır. | ||
|
Neden önemli?
Satır öğesi oluşturma işlemini izlemek, farklı journal türlerinin karmaşıklığını ve veri girişi için gereken çabayı anlamanıza yardımcı olur. Ayrıca header oluşturma ile satırın tamamlanması arasındaki gecikmeleri gösterebilir.
Nereden alınır?
Journal header ile ilişkilendirilen LedgerJournalTrans varlığındaki kayıtların oluşturulma zaman damgasından alınır. Her satır oluşturma işlemi ayrı bir olaydır.
Yakalayın
LedgerJournalTrans tablosundaki her kayıt için createdDateTime alanını kullanın.
Olay türü
explicit
|
|||
|
Journal onay için yeniden gönderildi
|
Düzeltilen yevmiye kaydı, yeni bir inceleme döngüsü için onay iş akışına geri gönderilir. Bu durum, Rejected veya Draft durumundan In Review veya Submitted durumuna geçiş gibi bir durum değişikliğinden anlaşılır. | ||
|
Neden önemli?
Bu etkinlik bir yeniden çalışma döngüsünün başladığını gösterir. Bu olayları saymak, yeniden çalışma oranını ve Journal Entry başına ortalama onay döngüsü sayısını ölçmenize yardımcı olur.
Nereden alınır?
Workflow geçmişinden veya LedgerJournalTable üzerindeki durum değişiklikleri izlenerek anlaşılır. Durum, reddedilmiş bir durumdan gönderilmiş duruma geri döner.
Yakalayın
Aynı journal için 'Rejected' olayından sonra gerçekleşen bir 'Submitted' durum olayını belirleyin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu Template ile Kayıttan Raporlamaya - Yevmiye Kaydı sürecinizi optimize etmeye başlamak için ihtiyacınız olan her şeye sahipsiniz. Verimliliği artırmak ve finansal raporlama döngülerinizi hızlandırmak için verilerinizden bugün yararlanmaya başlayın.
Dynamics 365'te Yevmiye Kaydınızı iyileştirin, şimdi daha hızlı raporlayın
Darboğazları ortadan kaldırın, R2R Yevmiye Kaydı çevrim süresini %30 azaltın.
Kredi kartı gerekmez, dakikalar içinde başlayın.