Harcama Yönetimi Veri Şablonunuz
Harcama Yönetimi Veri Şablonunuz
- Kapsamlı analiz için toplanması önerilen öznitelikler
- Doğru süreç keşfi için izlenecek temel faaliyetler
- Veri çekme için pratik rehberlik
Gider Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet Adı
ActivityName
|
Bir masraf raporu için belirli bir zamanda gerçekleşen iş olayının adı. | ||
|
Açıklama
Etkinlik Adı, 'Masraf Raporu Gönderildi' veya 'Yönetici Onayladı' gibi masraf yönetimi sürecindeki belirli bir adımı veya dönüm noktasını açıklar. İş akışını görselleştirmeyi, ortak yolları belirlemeyi ve sapmaları veya darboğazları tespit etmeyi sağlayan süreç haritasının temelini oluşturur. Etkinliklerin sırasını analiz etmek, süreç verimliliğini ve uyumluluğunu anlamak için esastır.
Neden önemli
Bu öznitelik, süreç haritasındaki adımları tanımlar, böylece süreç akışını, varyasyonları ve yeniden işleme döngülerini görselleştirmeyi ve analiz etmeyi mümkün kılar.
Nereden alınır
Bu öznitelik, genellikle Expensify'daki rapor durumu değişikliklerini, yorumları veya geçmiş günlüğü girişlerini standartlaştırılmış bir etkinlik listesine eşleyerek türetilir.
Örnekler
Gider Raporu GönderildiYönetici OnayladıFinans ReddettiGeri Ödeme Gerçekleşti
|
|||
|
Gider Raporu Kimliği
ExpenseReportId
|
Gönderimden geri ödemeye kadar tüm ilgili faaliyetleri gruplandıran, bir masraf raporu için benzersiz tanımlayıcı. | ||
|
Açıklama
Masraf Raporu Kimliği, masraf yönetimi süreci için birincil durum tanımlayıcısıdır. Her kimlik, bir çalışan tarafından onay ve geri ödeme için gönderilen tek bir masraf koleksiyonunu temsil eder. Bu öznitelik, bir masraf raporunun baştan sona yolculuğunu izlemek için çok önemlidir ve tüm gönderimleri, onayları, retleri ve ödemeleri dahil olmak üzere tüm yaşam döngüsünün yeniden yapılandırılmasına olanak tanır.
Neden önemli
İlgili tüm event'lerin tek bir process instance'ında toplanmasını sağlar, bu da herhangi bir Process Mining analizinin temelini oluşturur.
Nereden alınır
Bu, masraf raporları veri nesnesindeki birincil anahtardır ve genellikle Expensify API raporlar uç noktası aracılığıyla 'reportID' olarak mevcuttur.
Örnekler
RPT_84321RPT_99012RPT_10573
|
|||
|
Olay Zamanı
EventTime
|
Bir masraf raporu için belirli bir faaliyet veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Event Time, süreçteki her aktivite için kesin tarih ve saati sağlar. Bu zamansal bilgi, döngü sürelerini, süreleri ve farklı adımlar arasındaki bekleme sürelerini hesaplamak için esastır. Darboğazların, zaman içindeki performans eğilimlerinin ve hizmet seviyesi anlaşmalarına uyumluluğun analizini sağlar. Doğru timestamp'ler olmadan, Process Mining analizi akış keşfi ile sınırlıdır.
Neden önemli
Zaman damgaları, döngü sürelerini hesaplama, darboğazları belirleme ve süreç performansını izleme dahil olmak üzere tüm zaman tabanlı analizler için esastır.
Nereden alınır
Bu, Expensify rapor verilerindeki her geçmiş günlüğü girişi veya durum değişikliğiyle ilişkili oluşturma zaman damgasıdır.
Örnekler
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:12:05Z
|
|||
|
Çalışan Departmanı
EmployeeDepartment
|
Gönderenin ait olduğu iş birimi veya departmanı. | ||
|
Açıklama
Bu öznitelik, masraf raporunu gönderen çalışanın 'Satış', 'Mühendislik' veya 'Pazarlama' gibi organizasyonel departmanını belirtir. Analiz için kritik bir boyuttur ve işin farklı bölümlerindeki döngü süreleri, ret oranları ve politika uyumluluğu karşılaştırmalarına olanak tanır. Bu, departmana özgü sorunları veya eğitim ihtiyaçlarını belirlemeye yardımcı olur.
Neden önemli
Farklı iş birimleri arasında süreç performansını ve uyumluluğu karşılaştırmak için güçlü detaylı analizler sağlar.
Nereden alınır
Bu bilgi, rapor üzerinde bir etiket olarak saklanabilir veya Expensify'daki gönderenin kullanıcı profiliyle ilişkilendirilebilir. Harici bir İK sisteminden zenginleştirme gerektirebilir.
Örnekler
SatışPazarlamaMühendislikFinans
|
|||
|
Gönderen
Submitter
|
Masraf raporunu oluşturan ve gönderen çalışan. | ||
|
Açıklama
Gönderen özniteliği, masrafları yapan ve geri ödeme talep eden çalışanı tanımlar. Bu bilgi, çalışan, departman veya role göre masraf kalıplarını analiz etmek için kullanılır. Hangi çalışanların veya grupların en çok gecikme yaşadığı veya en yüksek politika ihlali oranlarına sahip olduğu gibi soruları yanıtlamaya yardımcı olarak daha iyi bir çalışan deneyimi analizine katkıda bulunur.
Neden önemli
Süreç performansının çalışanın bakış açısından analiz edilmesini sağlar, sık sorunlar veya gecikmeler yaşayan grupların belirlenmesine yardımcı olur.
Nereden alınır
Bu, masraf raporu nesnesindeki birincil bir alandır, genellikle 'policyEmail', 'submitterEmail' veya 'employeeEmail' olarak etiketlenir.
Örnekler
sara.jones@example.comkevin.lee@example.commaria.garcia@example.com
|
|||
|
Onaylayan
Approver
|
Masraf raporunu onaylamaktan veya reddetmekten sorumlu kullanıcının adı veya kimliği. | ||
|
Açıklama
Onaylayan özniteliği, gönderilen bir masraf raporu üzerinde işlem yapan yöneticiyi veya finans ekibi üyesini tanımlar. Bu, onay süreleri, ret oranları ve iş yükü dağılımı gibi onaylayana özgü davranışları analiz etmek için çok önemlidir. Onaylayıcı performansını anlamak, eğitim ihtiyaçlarını belirlemeye, iş yüklerini yeniden tahsis etmeye ve onay sürecini düzene sokmaya yardımcı olabilir.
Neden önemli
Bu öznitelik, onay darboğazlarını, iş yükü dağılımını ve onaylayana özgü ret oranlarını analiz etmek için anahtardır.
Nereden alınır
Bu bilgi, raporun geçmişinde veya iş akışı günlüğünde, genellikle onay veya ret olaylarıyla ilişkili olarak bulunur. Alan 'managerEmail' veya benzeri bir şekilde etiketlenebilir.
Örnekler
jane.doe@example.comjohn.smith@example.comfinance.approver@example.com
|
|||
|
Politika İhlali Bayrağı
PolicyViolationFlag
|
Raporun bir politika ihlali nedeniyle işaretlendiği durumda doğru olan bir boolean gösterge. | ||
|
Açıklama
Bu bayrak, bir masraf raporunun harcama limitini aşma veya makbuz eksikliği gibi bir veya daha fazla politika ihlaline neden olup olmadığını gösterir. Expensify'ın otomatik sistemi genellikle bu sorunları işaretler. Bu öznitelik, Politika İhlali Genel Bakış dashboardu için hayati önem taşır ve uyumluluk sorunlarını nicelleştirmeye ve iyileştirme alanlarını hedeflemeye yardımcı olur.
Neden önemli
Politika uyumluluğunu doğrudan ölçer ve ek inceleme gerektiren raporları belirlemeye yardımcı olur, bu da uyumluluk Dashboard'ları için önemli bir girdidir.
Nereden alınır
Expensify raporları genellikle bir ihlali gösteren belirli bir alan veya durum içerir, örneğin 'hasViolations' veya benzer bir boolean bayrağı.
Örnekler
truefalse
|
|||
|
Rapor Toplam Tutarı
ReportTotalAmount
|
Masraf raporunun toplam parasal değeri. | ||
|
Açıklama
Bu öznitelik, tek bir masraf raporunda yer alan tüm masrafların toplamını temsil eder. Ek inceleme gerektirebilecek veya farklı bir onay yolunu izleyebilecek yüksek değerli masrafları belirlemek gibi çeşitli analizler için kullanılan kritik bir finansal metriktir. Ayrıca finansal raporlama ve kuruluş genelindeki harcama kalıplarını anlamak için de kullanılır.
Neden önemli
Yüksek değerli gider raporlarının analizini sağlar, harcama eğilimlerini belirlemeye yardımcı olur ve finansal ve uyumluluk Dashboard'ları için kritik öneme sahiptir.
Nereden alınır
Expensify raporları nesnesinde bulunur, genellikle 'total' veya 'amount' olarak adlandırılır.
Örnekler
150.752500.0089.50
|
|||
|
Denetim Sonucu
AuditOutcome
|
Masraf raporu üzerinde gerçekleştirilen manuel veya otomatik bir denetimin sonucu. | ||
|
Açıklama
Bu öznitelik, 'Geçti', 'Başarısız' veya 'Bulgularla Geçti' olabilecek bir denetimin sonucunu yakalar. Bu, masraf süreçlerinde tüm raporlar veya bir örneklem için resmi bir denetim adımı olan şirketler için geçerlidir. Denetim sonuçlarını analiz etmek, uyumluluk düzeylerini ve mevcut kontrollerin etkinliğini anlamaya yardımcı olur.
Neden önemli
Uyumluluk kontrollerinin sonucunu doğrudan ölçer ve denetim sürecinin etkinliğini analiz etmek için esastır.
Nereden alınır
Bu muhtemelen kavramsal bir özniteliktir veya bir etiket ya da yorum olarak saklanabilir. Varlığı, şirketin Expensify içindeki özel süreç yapılandırmasına bağlıdır.
Örnekler
BaşarılıBaşarısız - Politika İhlaliNotlarla Geçti
|
|||
|
Gider Kategorisi
ExpenseCategory
|
Bir rapordaki bireysel masraf kalemine atanan kategori. | ||
|
Açıklama
Gider Kategorisi, 'Seyahat', 'Yemek ve Eğlence' veya 'Yazılım' gibi harcama türünü sınıflandırır. Bir raporun birden fazla kategorisi olabilse de, bu öznitelik genellikle en sık kullanılan kategoriyi veya en yüksek miktara sahip kategoriyi alarak rapor düzeyine indirgenir. Harcama eğilimlerini analiz etmek ve belirli gider türleri için politika uyumluluğunu kontrol etmek için kullanılır.
Neden önemli
Farklı gider türleri için harcama modelleri, politika ihlalleri ve onay sürelerinin analiz edilmesine yardımcı olur.
Nereden alınır
Bir rapor içindeki line-item düzeyinde ('transactions') bulunur. Case düzeyine atamak için bir aggregation veya business rule gereklidir.
Örnekler
Uçak BiletiKonaklamaYemeklerOfis Malzemeleri
|
|||
|
İlk Geçiş Onayı mı
IsFirstPassApproval
|
Raporun herhangi bir ret veya revizyon olmaksızın onaylandığı durumda doğru olan hesaplanmış bir işaret. | ||
|
Açıklama
Bu boolean bayrağı, her masraf raporu için, reddedilme veya revizyon için geri gönderilme gibi herhangi bir olumsuz sonuç olmadan onay sürecinden geçip geçmediğini belirlemek için hesaplanır. Süreç kalitesi ve verimliliğinin doğrudan bir ölçüsüdür ve İlk Geçiş Onay Oranı KPI'sına doğrudan katkıda bulunur. Yüksek bir oran, gönderimlerin kaliteli olduğunu ve politikaların iyi anlaşıldığını gösterir.
Neden önemli
İlk gönderimlerin kalitesini ve onay akışının verimliliğini doğrudan ölçer, yeniden işleme sıklığını vurgular.
Nereden alınır
Bu, belirli bir ExpenseReportId için etkinlik dizisi kontrol edilerek hesaplanır. Eğer dizi 'Yönetici Reddedildi', 'Finans Reddedildi' veya 'Revizyon İçin Rapor Geri Gönderildi' içermiyorsa, bayrak doğrudur.
Örnekler
truefalse
|
|||
|
İşlem Süresi
ProcessingTime
|
Tek bir etkinlik üzerinde harcanan sürenin süresi. | ||
|
Açıklama
İşleme Süresi, bir etkinliğin başlangıç ve bitiş zamanı arasındaki süreyi ölçen hesaplanmış bir metriktir. Bir görev üzerinde harcanan aktif süreyi temsil eder. Örneğin, bir yöneticinin bir raporu onaylamadan önce ne kadar süre açık tuttuğunu ölçebilir. Bu metrik, aktif çalışma süresi ile bekleme süresini ayırt etmek için kullanılır ve süreç verimliliği hakkında daha derinlemesine bilgi sağlar.
Neden önemli
Aktif işleme süresi ile pasif bekleme süresi arasında ayrım yapmaya yardımcı olur, bu da darboğazların daha kesin bir şekilde belirlenmesini sağlar.
Nereden alınır
Bu, veri dönüştürme sırasında EventEndTime'dan EventTime çıkarılarak hesaplanır.
Örnekler
864003600600
|
|||
|
Kaynak Sistem
SourceSystem
|
Verilerin çekildiği sistem. | ||
|
Açıklama
Bu öznitelik, bu durumda 'Expensify' olan süreç verisinin kaynağını tanımlar. Özellikle birden çok sistemden gelen verilerin birleştirildiği ortamlarda veri yönetimi için önemlidir. Veri kaynağını izlemeye ve sürecin bağlamını anlamaya yardımcı olur.
Neden önemli
Veri kaynağı için kritik bağlam sağlar ve birden çok kaynak sistemden veri aynı ortama yüklendiğinde süreçleri ayırt etmeye yardımcı olur.
Nereden alınır
Bu, veri dönüştürme süreci sırasında eklenmesi gereken statik bir değerdir ('Expensify').
Örnekler
ExpensifyExpensifyAPI-v2.0
|
|||
|
Ödeme Yöntemi
PaymentMethod
|
Çalışana geri ödeme yapmak için kullanılan yöntem. | ||
|
Açıklama
Bu öznitelik, çalışanın nasıl geri ödendiğini açıklar; örneğin 'Doğrudan Para Yatırma (ACH)', 'PayPal' veya 'Şirket Kredi Kartı'. Ödeme yöntemini analiz etmek, sürecin geri ödeme kısmını anlamaya yardımcı olabilir, özellikle belirli yöntemler daha uzun gecikmelerle ilişkiliyse. Sürecin son adımları için ek bağlam sağlar.
Neden önemli
Geri ödeme aşaması için bağlam sağlar ve farklı ödeme yöntemleriyle ilişkili gecikmeleri veya maliyetleri analiz etmek için kullanılabilir.
Nereden alınır
Bu bilgi, genellikle kapatılmış bir raporun geri ödeme ayrıntıları içinde mevcuttur.
Örnekler
ACHPayPalBill.com
|
|||
|
Olay Bitiş Zamanı
EventEndTime
|
Belirli bir etkinliğin ne zaman sona erdiğini gösteren zaman damgası. Ölçülebilir süresi olan etkinlikler için kullanışlıdır. | ||
|
Açıklama
Masraf yönetimindeki birçok faaliyet anlık olsa da, 'Yönetici İncelemesi' gibi bazıları başlangıç ve bitiş zamanıyla modellenebilir. Olay Bitiş Zamanı, böyle bir faaliyetin tamamlandığını işaret eder. Bireysel adımlar için kesin işleme süresini hesaplamak amacıyla Başlangıç Zamanı ile birlikte kullanılır ve zamanın nerede harcandığına dair daha ayrıntılı bir görünüm sunar.
Neden önemli
Aktif çalışma süresi ile boş bekleme süresi arasında ayrım yapmaya yardımcı olan aktivite işleme sürelerinin hesaplanmasını sağlar.
Nereden alınır
Bu genellikle doğrudan bir alan değildir. Aynı durum için dizideki bir sonraki olayın zaman damgası alınarak türetilir.
Örnekler
2023-10-26T10:05:12Z2023-10-27T15:00:00Z
|
|||
|
Para Birimi
Currency
|
Masraf raporundaki tutarların para birimi kodu. | ||
|
Açıklama
Para Birimi özniteliği, Rapor Toplam Tutarı'nın para birimini (örn. USD, EUR veya GBP) belirtir. Bu, finansal verilerin doğru yorumlanmasını sağlamak için birden çok ülkede faaliyet gösteren kuruluşlar için çok önemlidir. Yanlış toplamlardan kaçınmak için tüm parasal değerler bu öznitelikle birlikte analiz edilmelidir.
Neden önemli
Tüm parasal değerler için gerekli bağlamı sağlayarak doğru finansal analiz ve raporlama sağlar.
Nereden alınır
Bu, Expensify rapor nesnesinde genellikle 'currency' olarak adlandırılan standart bir alandır.
Örnekler
USDEURGBPCAD
|
|||
|
Politika Adı
PolicyName
|
Rapor için uygulanan masraf politikasının adı. | ||
|
Açıklama
Expensify'da, farklı çalışan grupları farklı gider politikalarına tabi olabilir. Bu öznitelik, gider raporunun kurallarını yöneten belirli politikayı tanımlar. Analiz için kritik bir boyuttur, çünkü farklı kurallara ve onay workflow'larına sahip olabilecek farklı politikalar arasında uyumluluğu ve verimliliği karşılaştırmaya olanak tanır.
Neden önemli
Uygulanan kural setine göre süreç analizinin segmentlere ayrılmasını sağlar, bu da farklı politikaların neden olduğu varyasyonları anlamak için hayati öneme sahiptir.
Nereden alınır
Bu, Expensify'daki rapor nesnesinde genellikle 'policyID' veya 'policyName' olarak adlandırılan standart bir alandır.
Örnekler
ABD Çalışan PolitikasıBirleşik Krallık Satış Ekibi PolitikasıYönetici Seyahat Politikası
|
|||
|
Rapor Durumu
ReportStatus
|
Masraf raporunun yaşam döngüsündeki mevcut durumu. | ||
|
Açıklama
Rapor Durumu, masraf raporunun süreçteki mevcut konumunu (örn. 'AÇIK', 'GÖNDERİLDİ', 'ONAYLANDI', 'GERİ ÖDENDİ' veya 'KAPALI') belirtir. Raporun ilerlemesinin bir anlık görüntüsünü sağlar. Process Mining'de bu öznitelik genellikle Etkinlik Adını türetmek için kullanılır, ancak raporların her durumda ne kadar zaman geçirdiğini analiz etmek için bir boyut olarak da kullanılabilir.
Neden önemli
Bir case'in mevcut durumunu gösterir ve genellikle Process Mining için activity log'u türetmek için kaynaktır.
Nereden alınır
Bu, Expensify rapor nesnesinde genellikle 'status' veya 'state' olarak adlandırılan standart bir alandır.
Örnekler
GÖNDERİLDİONAYLANDIGERİ ÖDENDİCLOSED
|
|||
|
Ret Nedeni
RejectionReason
|
Bir onaylayanın masraf raporunu reddederken veya revizyon için geri gönderirken verdiği neden. | ||
|
Açıklama
Bir masraf raporu reddedildiğinde, onaylayan genellikle bir neden sunabilir. Bu metin özniteliği, bu nedeni yakalayarak raporların neden onaydan geçemediğine dair paha biçilmez nitel içgörüler sağlar. Ret nedenlerini analiz etmek, yaygın gönderim hatalarını, belirsiz politikaları veya çalışanların daha fazla eğitime ihtiyaç duyduğu alanları belirlemeye yardımcı olur ve ilk geçiş onay oranını iyileştirme çabalarını doğrudan destekler.
Neden önemli
Yeniden işleme nedenlerini açıklayan nitel veriler sağlar; bu da rapor retlerinin temel neden analizleri için çok önemlidir.
Nereden alınır
Bu bilgi, genellikle bir ret olayıyla ilişkili yorumlarda veya geçmiş günlüğünde bulunur.
Örnekler
75 dolar üzerindeki kalem için eksik fişYanlış gider kategorisi seçildiYinelenen gider gönderildi
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Bu kayda ait verilerin kaynak sistemden en son ne zaman güncellendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin Process Mining aracında en son ne zaman ayıklandığını ve güncellendiğini kaydeder. Veri güncelliği konusunda şeffaflık sağlar ve analizin ne kadar güncel olduğunu anlamak için çok önemlidir. Bu, kullanıcıların içgörülere güvenmelerine ve zamanında verilere dayanarak bilinçli kararlar almalarına yardımcı olur.
Neden önemli
Kullanıcıların
Nereden alınır
Bu, genellikle veri dönüştürme (ETL) süreci sırasında eklenen veri çıkarma görevinin zaman damgasıdır.
Örnekler
2023-11-20T08:00:00Z2023-11-21T08:00:00Z
|
|||
|
Toplam Cycle Time
TotalCycleTime
|
Bir masraf raporu için ilk olayın oluşturulmasından son olayın tamamlanmasına kadar geçen toplam süre. | ||
|
Açıklama
Toplam Döngü Süresi, tek bir rapor için masraf yönetimi sürecinin baştan sona süresini ölçen vaka düzeyinde bir hesaplamadır. Genel süreç verimliliği için temel bir performans göstergesidir (KPI). Bu metrik, en ilk etkinliğin (örn. 'Masraf Raporu Oluşturuldu') zaman damgası ile en son etkinliğin (örn. 'Geri Ödeme Gerçekleşti') zaman damgası arasındaki fark alınarak hesaplanır.
Neden önemli
Bu, genel süreç hızını ölçmek ve sistemik sorunları gösterebilecek uzun süreli vakaları belirlemek için birincil bir KPI'dır.
Nereden alınır
Bu öznitelik, her ExpenseReportId için (MAX(EventTime) - MIN(EventTime)) alınarak hesaplanır.
Örnekler
6048001209600259200
|
|||
Gider Yönetimi Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Finans Onayladı
|
Finans departmanı veya son onaylayan, masraf raporunu incelemiş ve nihai onayını vermiştir. Bu eylem, iş akışı geçmişine kaydedilir ve genellikle rapor durumunu 'Onaylandı' olarak değiştirir. | ||
|
Neden önemli
Bu, geri ödemeden önceki son onay kapısıdır. Bu adım için harcanan süre, genel döngü süresi ve Ortalama Geri Ödeme Süresi KPI'sı için kritiktir.
Nereden alınır
Raporun geçmişinden veya denetim izinden yakalanır; bu, nihai onay eylemini, finans ekibinden onaycıyı ve zaman damgasını kaydeder.
Yakala
Raporun workflow geçmişinde ayrı bir nihai onay eylemi olarak kaydedilir.
Event tipi
explicit
|
|||
|
Geri Ödeme Gerçekleşti
|
Ödeme, çalışana başarıyla gönderildi ve sürecin geri ödeme kısmı tamamlandı. Bu, ödeme işleme günlüklerinden veya Expensify'daki son bir durum güncellemesinden yakalanır. | ||
|
Neden önemli
Bu, çalışan odaklı döngü sürelerini ölçmek için kilit bir bitiş noktasıdır. Ortalama Masraf Raporu Döngü Süresi ve Ortalama Geri Ödeme Süresi KPI'ları için kritiktir.
Nereden alınır
Rapor durumunun 'Reimbursed' olarak değişmesinden çıkarılır. Expensify'ın ödeme sistemleriyle entegrasyonu, bu durum değişikliği için bir timestamp sağlar.
Yakala
Rapor durumunun 'Reimbursed' olarak değişmesinden ve ilgili timestamp'ten türetilmiştir.
Event tipi
inferred
|
|||
|
Gider Raporu Gönderildi
|
Çalışan, onay iş akışının başlaması için tamamlanmış masraf raporunu resmi olarak gönderir. Bu, veri girişinden inceleme sürecine önemli bir geçiştir ve genellikle bir durum değişikliği ve gönderim zaman damgasıyla yakalanır. | ||
|
Neden önemli
Bu faaliyet, onay döngüsünü tetikleyen kritik bir dönüm noktasıdır. Yönetici ve finans inceleme sürelerini ölçmek için başlangıç noktası olarak hizmet eder.
Nereden alınır
Raporun durumunun 'Open' veya 'Draft'tan 'Processing' veya 'Submitted'a değişmesinden ve bu değişikliğe ilişkin timestamp'ten çıkarılır.
Yakala
Durumun 'Processing' olarak değişmesinden ve ilgili gönderim timestamp'ten türetilmiştir.
Event tipi
inferred
|
|||
|
Gider Raporu Oluşturuldu
|
Bir çalışan tarafından yeni bir gider raporunun başlatılmasını işaretler. Bu, genellikle rapor Expensify'da ilk kaydedildiğinde bir creation timestamp'i ile açık bir event olarak yakalanır. | ||
|
Neden önemli
Bu faaliyet, tüm süreç analizleri için başlangıç noktasıdır ve oluşturmadan geri ödemeye kadar toplam döngü süresini ölçmek için çok önemlidir.
Nereden alınır
Bu olay, Expensify'ın rapor geçmişindeki veya denetim günlüklerindeki rapor oluşturma zaman damgasından yakalanır. Her rapor nesnesinin bir oluşturma tarihi vardır.
Yakala
Gider raporunun ilk oluşturulması ve kaydedilmesi üzerine kaydedilir.
Event tipi
explicit
|
|||
|
Rapor Kapatıldı
|
Masraf raporu, geri ödeme ve muhasebe senkronizasyonu dahil tüm işlemler tamamlandıktan sonra sistemde resmi olarak kapatılır. Bu olay genellikle 'Kapalı' gibi son, nihai bir durumdan çıkarılır. | ||
|
Neden önemli
Süreç için, geri ödemeden ayrı, son muhasebe ve arşivleme adımlarını analiz etmek için faydalı olan kesin bir bitiş noktası sağlar.
Nereden alınır
Rapor durumunun 'Closed' gibi terminal bir duruma değişmesinden çıkarılır. Bu genellikle reimbursement ve muhasebe export'undan sonra gerçekleşir.
Yakala
Rapor durumunun 'Closed' olarak değişmesinden ve ilgili timestamp'ten türetilmiştir.
Event tipi
inferred
|
|||
|
Revizyon İçin Rapor Geri Gönderildi
|
Bir onaycı, yönetici veya finans bölümünden, raporu düzeltme veya daha fazla bilgi için çalışana geri gönderir. Bu, genellikle 'İşlemde' durumundan sonra 'Açık' durumuna yapılan bir değişiklikten çıkarılır. | ||
|
Neden önemli
Bu faaliyet, büyük bir verimsizlik kaynağı olan yeniden işlemeyi temsil eder. Bunu izlemek, yeniden işleme döngülerini nicelleştirmeye, Yeniden İşleme Oranı KPI'sını ölçmeye ve temel nedenleri belirlemeye yardımcı olur.
Nereden alınır
Bir rapor durumunun 'Processing' veya 'Submitted'dan tekrar 'Open'a değişmesinden çıkarılır. Bu durum değişikliğinin timestamp'i event'i işaretler.
Yakala
Bir rapor durumunun 'Processing'den tekrar 'Open'a değişmesinden türetilmiştir.
Event tipi
inferred
|
|||
|
Yönetici Onayladı
|
Doğrudan yönetici veya birinci düzey onaylayıcı, masraf raporunu incelemiş ve onaylamıştır. Bu olay, onaylayanın eylemini ve zaman damgasını kaydeden onay iş akışı günlüğünden yakalanır. | ||
|
Neden önemli
Onay sürecinde kritik bir dönüm noktası. Gönderimden bu olaya kadar geçen sürenin analiz edilmesi, yöneticiyle ilgili darboğazları belirlemeye ve Yönetici Onay Döngüsü Süresi KPI'sını ölçmeye yardımcı olur.
Nereden alınır
Raporun geçmişinden veya denetim izinden yakalanır; bu, onay eylemini, onaycının adını ve zaman damgasını açıkça kaydeder.
Yakala
Raporun workflow geçmişinde ayrı bir onay eylemi olarak kaydedilir.
Event tipi
explicit
|
|||
|
Finans Reddetti
|
Finans departmanı masraf raporunu incelemiş ve reddetmiş, böylece geri ödeme sürecini durdurmuştur. Bu olay, iş akışı geçmişine bir zaman damgası ve ret nedeni ile birlikte kaydedilir. | ||
|
Neden önemli
Son inceleme aşamasındaki darboğazları ve başarısızlık nedenlerini belirler. Genel ret oranını ve uyumluluk sorunlarını analiz etmek için esastır.
Nereden alınır
Raporun geçmişinden yakalanır; bu, finans ekibi tarafından yapılan ret eylemini, zaman damgası ve kullanıcı ile birlikte kaydeder.
Yakala
Raporun workflow geçmişinde ayrı bir ret eylemi olarak kaydedilir.
Event tipi
explicit
|
|||
|
Geri Ödeme Planlandı
|
Nihai onayın ardından, gider raporu ödeme işleme için sıraya alınır. Bu olay, onaydan ödeme aşamasına geçişi işaret eder ve genellikle rapor durumu 'Ödeniyor' olarak değiştiğinde yakalanır. | ||
|
Neden önemli
Geri ödeme lead time'ının başlangıcını işaretler. Bununla gerçek ödeme arasındaki sürenin analiz edilmesi, payout sürecindeki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır
Bir rapor durumunun 'Reimbursing' veya 'Processing Payment' olarak değişmesinden ve ilgili timestamp'inden çıkarılır.
Yakala
Raporun ödeme için sıraya alındığını belirten bir durum değişikliğinden türetilmiştir.
Event tipi
inferred
|
|||
|
Gider Raporuna Eklendi
|
Bir çalışanın, taranmış bir makbuz veya manuel olarak girilmiş bir masraf gibi belirli bir kalem eklemesini temsil eder. Bu, raporun ayrıntılı geçmiş günlüğüne bir giriş olarak kaydedilir. | ||
|
Neden önemli
Rapor oluşturma ile giderlerin eklenmesi arasındaki sürenin analiz edilmesi, çalışanlar tarafından kanıt toplama veya gönderim hazırlığında yaşanan gecikmeleri ortaya çıkarabilir.
Nereden alınır
Gider raporunun denetim izinden veya geçmişinden alınır; bu, bireysel gider girişleri ekleme gibi eylemleri kaydeder.
Yakala
Raporun geçmişine her yeni gider satırı eklendiğinde kaydedilir.
Event tipi
explicit
|
|||
|
Muhasebe Kaydı Yapıldı
|
Masraf raporundaki finansal veriler dışa aktarılmış ve şirketin muhasebe sistemine veya ERP'ye kaydedilmiştir. Bu, finansal kayıtlar açısından süreci tamamlayan son adımdır. | ||
|
Neden önemli
Masraf raporunun finansal sistemdeki nihai kapanışını temsil eder. Baştan sona tüm süreci ölçmek ve veri senkronizasyonunu sağlamak için önemlidir.
Nereden alınır
Expensify ile muhasebe yazılımı arasındaki entegrasyon günlüklerinden yakalanır. Bu, iki sistemden gelen verilerin birleştirilmesini gerektirebilir.
Yakala
Datelar muhasebe sistemine başarıyla sync edildiğinde integration geçmişine kaydedilir.
Event tipi
explicit
|
|||
|
Politika İhlali İşaretlendi
|
Otomatik bir kontrol, şirket politikasını ihlal eden, örneğin bütçeyi aşan veya fişi eksik olan bir gideri belirler. Bu olay, rapor veya kalem üzerinde belirli bir politika ihlali bayrağı ayarlandığında yakalanır. | ||
|
Neden önemli
Uyumluluk sorunlarını vurgular ve hangi politikaların sıkça ihlal edildiğini belirlemeye yardımcı olur, hedeflenmiş eğitim veya politika açıklığı sağlar. Bu, Politika İhlali Sayısı KPI'sı için kritik öneme sahiptir.
Nereden alınır
Gider raporu datalarında 'Policy Violation' flag'inin veya özniteliğinin true olarak ayarlanmasından çıkarılır. Timestamp, bu flag'in ayarlandığı zamana karşılık gelir.
Yakala
Rapor için politika ihlali özniteliğinin güncellendiği timestamp'ten türetilmiştir.
Event tipi
inferred
|
|||
|
Yönetici Reddetti
|
Birinci düzey onaylayıcı, masraf raporunu incelemiş ve reddetmiştir, bu da genellikle süreci durdurur. Bu, iş akışı günlüğünde bir ret olayı olarak kaydedilir ve genellikle bir neden belirtilir. | ||
|
Neden önemli
Ret olaylarını analiz etmek, Gider Raporu Ret Oranı KPI'sını anlamak için anahtardır. Başarısızlığın yaygın nedenlerini ve süreç iyileştirmesi gerektiren alanları belirlemeye yardımcı olur.
Nereden alınır
Raporun geçmişinden yakalanır; bu, ret eylemini, ret edenin kimliğini ve zaman damgasını kaydeder. Rapor durumu genellikle 'Reddedildi' olarak değişir.
Yakala
Raporun workflow geçmişinde ayrı bir ret eylemi olarak kaydedilir.
Event tipi
explicit
|
|||