Harcama Yönetimi Veri Şablonunuz
Harcama Yönetimi Veri Şablonunuz
- Analiz için Önerilen Nitelikler
- Süreç boyunca izlenecek temel aktiviteler
- `Veri` çıkarma rehberliği
Masraf Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet Adı
ActivityName
|
Harcama raporu yaşam döngüsü içinde meydana gelen belirli bir olayın veya görevin adı. | ||
|
Açıklama
Etkinlik Adı, 'Harcama Raporu Gönderildi', 'Yönetici Onayladı' veya 'Geri Ödeme Gerçekleşti' gibi süreçteki bir adımı tanımlar. Bu olaylar, süreç akışını oluşturan eylemler dizisini meydana getirir. Bu etkinlikleri analiz etmek, süreç haritasının görselleştirilmesine, adımlar arasındaki darboğazların belirlenmesine ve onaylar veya retler gibi farklı sonuçların sıklıklarının hesaplanmasına olanak tanır. Harcama yönetimi süreci boyunca ne olduğunu anlamanın temelini oluşturur.
Neden önemli
Bu öznitelik, süreç haritasını oluşturmak ve her bir harcama raporunun geçtiği olay dizisini anlamak için kritik öneme sahiptir.
Nereden alınır
Bu bilgi, Brex sistemi içindeki olay günlüklerinden veya işlem durumlarından türetilmiştir. Durum kodlarından veya olay türlerinden kullanıcı dostu adlara eşleme gerektirebilir.
Örnekler
Masraf Raporu OluşturulduYönetici OnayladıFinans ReddedildiGeri Ödeme Gerçekleşti
|
|||
|
Masraf Raporu Kimliği
ExpenseReportId
|
Harcama raporu için benzersiz tanımlayıcı, yaşam döngüsünü takip etmek için birincil vaka tanımlayıcısı olarak hizmet eder. | ||
|
Açıklama
Harcama Raporu Kimliği, harcama yönetimi sürecinin temel taşıdır. Oluşturmadan gönderime, onaya ve geri ödemeye kadar tüm ilgili etkinlikleri tek bir vakada gruplandırır. Süreç madenciliğinde, bu Kimlik her bir harcama raporunun yolculuğunun uçtan uca analizini sağlar. Bir raporun izlediği kesin yolu yeniden yapılandırmak, toplam döngü sürelerini ölçmek, raporlar revizyon için geri gönderildiğinde yeniden işleme döngülerini belirlemek ve yaygın ve istisnai akışları anlamak için süreç varyantlarını analiz etmek için kullanılır.
Neden önemli
Bu Kimlik, bir harcama raporunun tüm yaşam döngüsünü takip etmek, döngü süreleri, darboğazlar ve süreç sapmalarını analiz etmek için hayati öneme sahiptir.
Nereden alınır
Bu, Brex'in harcama yönetimi modülünde birincil bir tanımlayıcıdır ve genellikle tüm harcama raporuyla ilgili veri dışa aktarımlarında ve API uç noktalarında bulunur.
Örnekler
ER-2023-08-1012ER-2023-09-2345ER-2023-10-5567
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir faaliyetin veya event'in ne zaman gerçekleştiğini gösteren zaman damgasıdır. | ||
|
Açıklama
Event Time, süreçteki her aktivite için kesin tarihi ve saati sağlar. Bu zamansal bilgi, olayların kronolojik sırasını belirlediği için Process Mining için temeldir. Bu zaman damgası, aktiviteler arasındaki cycle time'ları hesaplamak, bekleme sürelerini ve gecikmeleri belirlemek ve farklı zaman dilimlerindeki süreç performansını analiz etmek için kullanılır. 'Ortalama Yönetici İnceleme Süresi' ve 'Geri Ödeme Yürütme Gecikmesi' gibi temel metrikleri güçlendirerek, darboğaz analizini ve performans izlemeyi doğrudan destekler.
Neden önemli
Zaman damgası, döngü süreleri ve bekleme süreleri gibi tüm zaman tabanlı metrikleri hesaplamak için hayati öneme sahiptir ve gecikmeleri belirlemek için kritik öneme sahiptir.
Nereden alınır
Brex'teki her olay veya işlem kaydının ilişkili bir zaman damgası olmalıdır. Bu, masraf raporları için API yanıtlarında veya veri dışa aktarımlarında bulunabilir.
Örnekler
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Çalışan Departmanı
EmployeeDepartment
|
Harcama raporunu gönderen çalışanın departmanı. | ||
|
Açıklama
Bu öznitelik, gönderen çalışanın ait olduğu Satış, Mühendislik veya Pazarlama gibi iş departmanını tanımlar. Analiz için önemli bir organizasyonel boyuttur. Verileri departman bazında analiz etmek, organizasyonun belirli bölümlerine özgü süreç varyasyonlarını, darboğazları veya uyumluluk sorunlarını belirlemeye yardımcı olur. Örneğin, bir departmanın diğerlerinden önemli ölçüde daha yüksek bir ret oranına veya daha uzun onay sürelerine sahip olup olmadığını ortaya çıkarabilir, bu da hedefe yönelik eğitim veya süreç ayarlamalarına ihtiyaç duyulduğunu gösterir. Ayrıca departman bütçesi takibi ve maliyet tahsisi için de hayati öneme sahiptir.
Neden önemli
Farklı iş birimleri arasındaki süreç performansını filtrelemeye ve karşılaştırmaya olanak tanır, departmana özgü sorunları veya eğilimleri belirlemeye yardımcı olur.
Nereden alınır
Bu bilgi genellikle Brex'teki çalışanın profilinden alınır ve bu profil sıklıkla bir İK bilgi sisteminden senkronize edilir.
Örnekler
SatışMühendislikPazarlamaFinans
|
|||
|
Olay Kullanıcısı
EventUser
|
Etkinliği gerçekleştiren kullanıcı, örneğin raporu onaylayan yönetici. | ||
|
Açıklama
Olay Kullanıcısı özniteliği, bir etkinlikten sorumlu belirli kişiyi tanımlar. Bu, raporu gönderen çalışan, raporu inceleyen yönetici veya geri ödemeyi işleyen finans ekip üyesi olabilir. Bu öznitelik, 'Onaylayıcı Performansı ve İş Yükü' dashboard'unda görüldüğü gibi, iş yükü analizi ve performans takibi için hayati öneme sahiptir. Hangi onaylayıcıların en çok raporu işlediğini, kimin en hızlı onay sürelerine sahip olduğunu ve süreçte darboğaz olabilecek bireyler olup olmadığını belirlemeye yardımcı olur. Bu, daha dengeli bir iş dağılımı ve gerektiğinde hedefe yönelik destek sağlar.
Neden önemli
Bir eylemden sorumlu belirli kişiyi belirler, bu da bireysel düzeyde iş yükü analizini, performans takibini ve darboğaz tespitini mümkün kılar.
Nereden alınır
Bu veri, genellikle Brex'teki bir harcama raporunun denetim izinde veya olay geçmişinde yakalanır.
Örnekler
john.smith@example.comjane.doe@example.comfinance-bot
|
|||
|
Politika İhlali Bayrağı
PolicyViolationFlag
|
Masraf raporunun bir politika ihlali nedeniyle işaretlenip işaretlenmediğini gösteren bir boolean bayrak. | ||
|
Açıklama
Bu öznitelik, Brex'in otomatik politika motoru, kategori sınırını aşan bir harcama veya eksik bir makbuz gibi potansiyel bir ihlali tespit ettiğinde ayarlanan basit bir doğru veya yanlış göstergesidir. Bu bayrak, uyumluluk analizi için temeldir ve 'Politika İhlali Oranı' KPI'ının temelini oluşturur. Uyumluluğa uymayan raporları hızla filtrelemeye olanak tanır ve bunların işlem süreleri ile ret oranları üzerindeki etkisini anlamaya yardımcı olur. Bu işaretlenmiş raporları analiz etmek, şirket politikalarını iyileştirmeye ve çalışanların daha fazla rehberliğe ihtiyaç duyduğu alanları belirlemeye yardımcı olur.
Neden önemli
Uyumluluk izlemeyi doğrudan destekler ve politika ihlallerinin süreç verimliliği ve yeniden işleme üzerindeki etkisini ölçmeye yardımcı olur.
Nereden alınır
Bu, muhtemelen Brex'teki harcama raporu verilerinde, genellikle politika motoru tarafından yönetilen bir boolean alanı veya durum göstergesidir.
Örnekler
truefalse
|
|||
|
Rapor Durumu
ReportStatus
|
Harcama raporunun yaşam döngüsündeki mevcut durumu. | ||
|
Açıklama
Rapor Durumu, harcama raporunun süreçteki mevcut konumunun anlık görüntüsünü sağlar; örneğin, 'Yönetici Onayı Bekleniyor', 'Onaylandı', 'Ödendi' veya 'Reddedildi'. Bu öznitelik, özellikle 'Açık Harcama Raporları Durum Monitörü' dashboard'u için operasyonel izleme açısından kritik öneme sahiptir. Yöneticilerin ve finans ekiplerinin mevcut iş yükünü hızla görmelerine, belirli bir durumda takılı kalan raporları belirlemelerine ve eylemlerini önceliklendirmelerine olanak tanır. Her bir durumda harcanan süreyi analiz etmek, süreçteki gecikmeleri ve verimsizlikleri tespit etmeye yardımcı olur.
Neden önemli
Bir harcama raporunun iş akışındaki mevcut konumunun anlık görüntüsünü sağlar; bu, operasyonel dashboard'lar ve durum izleme için hayati öneme sahiptir.
Nereden alınır
Bu, Brex içindeki harcama raporu nesnesindeki önemli bir durum alanıdır.
Örnekler
PENDING_APPROVALONAYLANDIREDDEDİLDİÖDENDİ
|
|||
|
Toplam Tutar
TotalAmount
|
Harcama raporunun toplam parasal değeri. | ||
|
Açıklama
Bu öznitelik, harcama raporunda talep edilen toplam tutarı temsil eder. Harcama kalıplarını ve harcama sürecinin finansal etkisini anlamak için kritik bir finansal metriktir. Analizde, toplam tutar, harcama raporlarını yüksek değerli ve düşük değerli raporlar gibi farklı değer aralıklarına ayırmak için kullanılabilir; bu raporlar farklı onay yollarına veya inceleme seviyelerine sahip olabilir. Ayrıca finansal raporlama, bütçeleme analizi ve departman veya kategoriye göre harcama eğilimlerini belirlemek için de önemlidir.
Neden önemli
Bu öznitelik, daha fazla inceleme gerektirebilecek veya daha uzun onay sürelerine sahip yüksek değerli harcama raporlarını belirlemek gibi finansal analizlere olanak tanır.
Nereden alınır
Bu, Brex'teki her harcama raporuyla ilişkili standart bir alandır. API yanıtlarında veya dışa aktarımlarda ana harcama raporu nesnesinde bulunabilir.
Örnekler
150.752500.0079.99
|
|||
|
Bitiş Saati
EndTime
|
Bir aktivitenin tamamlandığını gösteren timestamp. | ||
|
Açıklama
Başlangıç Zamanı (Olay Zamanı) bir etkinliğin başlangıcını işaret ederken, Bitiş Zamanı onun sonucunu işaret eder. Bu, 'Yönetici İncelemesi Başlatıldı' ve 'Yönetici Onayladı' gibi bir süreye sahip etkinlikler için en alakalıdır. Bir etkinlik için hem başlangıç hem de bitiş zamanının varlığı, işlem süresinin kesin olarak hesaplanmasına olanak tanır ve onu önündeki bekleme süresinden ayırır. Bu, işin kendisini gerçekleştirmenin ne kadar sürdüğünü doğru bir şekilde ölçmeye yardımcı olur, bu da darboğaz analizinin temel bir bileşenidir.
Neden önemli
Aktiviteler için bekleme sürelerinden farklı olarak kesin işlem sürelerinin hesaplanmasına olanak tanır, bu da daha doğru darboğaz analizine yol açar.
Nereden alınır
EndTime genellikle sıradaki bir sonraki aktivitenin StartTime'ıdır. Ayrıca, belirli bir süreye sahip aktiviteler için kaynak verisinde özel bir alan olabilir.
Örnekler
2023-10-26T10:05:12Z2023-10-26T14:40:00Z2023-10-27T09:15:25Z
|
|||
|
Çalışan Adı
EmployeeName
|
Harcama raporunu oluşturan ve gönderen çalışanın adı. | ||
|
Açıklama
Bu öznitelik, harcama raporunun adına düzenlendiği çalışanın adını belirtir. Olay Kullanıcısı bir eylemi kimin gerçekleştirdiğini tanımlarken, Çalışan Adı harcama raporu davasının konusunu tanımlar. Analizde bu, harcamaların çalışan başına takip edilmesini sağlar. Sık sık politika ihlalleri içeren raporlar gönderen veya raporları sürekli reddedilen kişileri belirlemeye yardımcı olabilir, bu da ek eğitime ihtiyaç duyulduğunu gösterir. Ayrıca kuruluş içindeki farklı çalışanlar veya roller için harcama kalıplarını anlamaya da yardımcı olur.
Neden önemli
Masraf raporunun sahibini belirler, bu da bireysel çalışan düzeyinde gönderim kalitesinin ve uyumluluğun analiz edilmesine olanak tanır.
Nereden alınır
Bu, Brex'teki yaratıcının kullanıcı profilinden bağlanan her harcama raporundaki temel bir bilgi parçasıdır.
Örnekler
Alice JohnsonRobert WilliamsMaria Garcia
|
|||
|
Döngü Süresi
CycleTime
|
Harcama raporunun oluşturulmasından nihai tamamlanmasına kadar geçen toplam süre. | ||
|
Açıklama
Cycle Time, her masraf raporu durumu için uçtan uca süreyi ölçen hesaplanmış bir metriktir. Genellikle ilk olayın (örn. 'Masraf Raporu Oluşturuldu') zaman damgası ile son olayın (örn. 'Geri Ödeme Gerçekleştirildi' veya 'Muhasebe Kaydedildi') zaman damgası arasındaki fark olarak hesaplanır. Bu, genel süreç verimliliğini ölçmek için en temel KPI'lardan biridir ve 'Masraf Raporu Uçtan Uca Cycle Time' dashboard'unu doğrudan destekler. Cycle Time'ı analiz etmek, uzun süren durumları belirlemeye, süreç performansındaki eğilimleri anlamaya ve süreç iyileştirme girişimlerinin etkisini ölçmeye yardımcı olur.
Neden önemli
Bu, harcama yönetimi sürecinin baştan sona genel hızını ve verimliliğini ölçen temel bir performans göstergesidir.
Nereden alınır
Bu, süreç madenciliği aracı içinde her vaka için en erken olay zaman damgasını en son olay zaman damgasından çıkararak hesaplanır.
Örnekler
3 gün 4 saat10 gün 1 saat22 saat 30 dakika
|
|||
|
İlk Geçiş Onayı
FirstPassApproval
|
Bir raporun herhangi bir ret veya revizyon olmadan onaylanıp onaylanmadığını gösteren bir bayrak. | ||
|
Açıklama
Bu hesaplanmış boolean öznitelik, en verimli süreç örneklerini tanımlar. Bir harcama raporu, gönderimden nihai onaya kadar tüm süreci hiçbir zaman reddedilmeden veya revizyon için geri gönderilmeden tamamlarsa 'doğru' olarak ayarlanır. Bu, süreç kalitesi ve verimliliğinin temel bir ölçüsü olan 'İlk Geçiş Onay Oranı' KPI'ının temelini oluşturur. Yüksek bir oran, çalışanların yüksek kaliteli, uyumlu raporlar gönderdiğini ve onay sürecinin sorunsuz olduğunu gösterir. İlk geçiş onayında başarısız olan raporların özelliklerini analiz etmek, süreçteki sürtünme ve hata kaynaklarını belirlemeye yardımcı olur.
Neden önemli
Başlangıçtaki gönderimlerin kalitesini ve temel workflow'un verimliliğini, herhangi bir sürtünme olmadan akan raporları belirleyerek ölçer.
Nereden alınır
Bu öznitelik, her vaka için etkinlik sırasını analiz ederek ret veya revizyon etkinliklerinin yokluğunu kontrol etmek suretiyle süreç madenciliği platformu içinde hesaplanır.
Örnekler
truefalse
|
|||
|
Kaynak Sistem
SourceSystem
|
Verilerin çekildiği sistem. | ||
|
Açıklama
Bu öznitelik, bu bağlamda 'Brex' olan süreç verilerinin kaynağını tanımlar. Veri yönetimi ve izlenebilirlik için önemlidir, özellikle birden fazla sistemden gelen verilerin bütünsel bir süreç görünümü için birleştirilebileceği ortamlarda. Analizde, birden fazla kaynak sistemin söz konusu olduğu durumlarda verileri filtrelemeye ve segmentlere ayırmaya yardımcı olur, metriklerin ve süreç haritalarının kaynaklarına göre doğru yorumlanmasını sağlar. Tek sistem görünümü için, verinin kaynağının sürekli bir doğrulaması olarak hizmet eder.
Neden önemli
Veri kaynağı hakkında temel bağlam sağlar, izlenebilirliği garantiler ve çoklu sistem ortamlarında doğru veri filtrelemesini mümkün kılar.
Nereden alınır
Bu, veri çıkarma ve dönüştürme aşamasında tipik olarak eklenen statik bir değer olan 'Brex'tir.
Örnekler
BrexBrex-API-v2.1
|
|||
|
Makbuzlar Zamanında Eklendi
ReceiptsAttachedOnTime
|
Rapor gönderilmeden önce fişlerin eklenip eklenmediğini gösteren bir bayrak. | ||
|
Açıklama
Bu hesaplanmış boolean öznitelik, yaygın bir süreç en iyi uygulamasını ölçmek için tasarlanmıştır: bir harcama raporunu incelemeye göndermeden önce tüm gerekli makbuzları eklemek. Belirli bir vaka için 'Makbuzlar Eklendi' etkinliği, 'Harcama Raporu Gönderildi' etkinliğinden önce gerçekleşirse 'doğru' olarak ayarlanır. Bu bayrak, 'Makbuz Uyumluluğu ve Etkisi' dashboard'unu ve 'Makbuz Ekleme Uyumluluğu' KPI'ını doğrudan destekler. Bu özniteliği analiz etmek, geç veya eksik makbuzların ne sıklıkta meydana geldiğini ve bu davranışın gecikmeler, retler ve yeniden işleme gibi süreç sonuçlarıyla nasıl ilişkili olduğunu nicel olarak belirlemeye yardımcı olur.
Neden önemli
Fiş gönderim politikalarına uyumu ölçer, süreç gecikmelerinin ve retlerinin yaygın bir temel nedenini belirlemeye yardımcı olur.
Nereden alınır
Bu, süreç madenciliği aracı içinde her vaka için 'Makbuzlar Eklendi' ve 'Harcama Raporu Gönderildi' etkinliklerinin zaman damgalarını karşılaştırarak hesaplanır.
Örnekler
truefalse
|
|||
|
Masraf Kategorisi
ExpenseCategory
|
Seyahat, yemek veya yazılım gibi harcamaya atanan kategori. | ||
|
Açıklama
Harcama Kategorisi, çalışanın harcamanın niteliğini tanımlamak için seçtiği bir sınıflandırmadır. Bu, muhasebe, bütçeleme ve politika uygulamasında kullanılır. Süreç madenciliğinde, harcamaların kategorize edilmesi, sürecin daha ayrıntılı bir görünümünü sağlar. Uluslararası seyahat gibi belirli harcama kategorilerinin daha uzun onay döngülerine veya daha yüksek ret oranlarına sahip olup olmadığını belirlemeye yardımcı olabilir. Bu analiz, belirli harcama türleri için politika ve süreçlerin iyileştirilmesini destekler.
Neden önemli
Sürecin harcama türüne göre analizine olanak tanır, bu da farklı masraf türleri için farklı davranışlar veya darboğazlar ortaya çıkarabilir.
Nereden alınır
Bu, harcama kalemleri üzerindeki standart bir alandır ve bir rapor birden fazla kategori içeriyorsa harcama raporu seviyesine toplanması gerekecektir.
Örnekler
Uçak BiletiYemek ve EğlenceYazılım AbonelikleriOfis Malzemeleri
|
|||
|
Ödeme Yöntemi
PaymentMethod
|
Masrafın nasıl ödendiğini gösterir, örn. kurumsal kart veya kişisel fonlar. | ||
|
Açıklama
Bu öznitelik, şirket tarafından verilen Brex kartına yüklenen harcamalar ile bir çalışan tarafından cepten ödenen ve geri ödeme gerektiren harcamalar arasında ayrım yapar. Bu ayrım önemlidir çünkü süreç, ödeme yöntemine göre önemli ölçüde farklılık gösterebilir. Kurumsal kart işlemleri bir doğrulama ve mutabakat sürecini takip ederken, geri ödemeler bir talep ve ödeme sürecini takip eder. Ödeme yöntemine göre analiz yapmak, her akışa özgü sorunları izole etmeye ve bunları bağımsız olarak optimize etmeye yardımcı olabilir.
Neden önemli
Süreç akışı ve gerekli adımlar, kurumsal kart harcamaları ile cepten geri ödemeler arasında genellikle farklılık gösterir, bu da bunu varyant analizi için önemli bir öznitelik haline getirir.
Nereden alınır
Bu bilgi, Brex içindeki işlem verilerine özgüdür.
Örnekler
Brex Kurumsal KartGeri ÖdemeFatura Ödeme
|
|||
|
Otomatikleştirildi mi?
IsAutomated
|
Aktivitenin bir sistem kullanıcısı veya bot tarafından gerçekleştirilip gerçekleştirilmediğini gösteren bir boolean bayrak. | ||
|
Açıklama
Bu öznitelik, bir etkinliğin otomatik bir politika kontrolü gibi sistem tarafından mı yoksa manuel bir onay gibi bir insan kullanıcı tarafından mı yürütüldüğünü belirler. Otomatik ve manuel etkinlikleri ayırt etmek, süreçteki otomasyon seviyesini anlamak için kritik öneme sahiptir. Kural tabanlı sistemlerin etkinliğini değerlendirmeye ve daha fazla otomasyon fırsatlarını belirlemeye yardımcı olur. Örneğin, kaç raporun otomatik olarak onaylandığını ve kaçının manuel müdahale gerektirdiğini gösterebilir, böylece dokunmasız işlemeyi artırma çabalarına rehberlik eder.
Neden önemli
Süreçteki otomasyon seviyesini ölçmeye ve hangi adımların insanlar tarafından, hangilerinin sistem tarafından gerçekleştirildiğini belirlemeye yardımcı olur.
Nereden alınır
Bu, tipik olarak bir olayla ilişkili kullanıcı kontrol edilerek türetilir. Sistem tarafından oluşturulan olaylar genellikle genel bir 'sistem' veya 'bot' kullanıcısıyla ilişkilendirilir.
Örnekler
truefalse
|
|||
|
Para Birimi
Currency
|
Harcama raporunun toplam tutarı için para birimi kodu. | ||
|
Açıklama
Para Birimi özniteliği, Toplam Tutarın birimini belirtir; örneğin USD, EUR veya GBP. Bu, özellikle birden fazla para birimiyle çalışan çok uluslu kuruluşlar için doğru finansal analiz açısından kritik öneme sahiptir. Bu öznitelik, finansal verilerin doğru yorumlanmasını sağlar. Harcama tutarlarının uygun şekilde birleştirilmesine ve karşılaştırılmasına olanak tanır, bu da genellikle ortak bir raporlama para birimine dönüştürme gerektirir. Farklı para birimlerinden parasal değerlerin toplanması gibi analitik hataları önler.
Neden önemli
Çoklu para birimli bir ortamda finansal doğruluğu sağlar ve masraf değerlerinin doğru bir şekilde toplanmasına ve raporlanmasına olanak tanır.
Nereden alınır
Bu alan, genellikle Brex'in harcama raporu verilerindeki miktar alanının yanında bulunur.
Örnekler
USDEURGBP
|
|||
|
Politika İhlali Detayları
PolicyViolationDetails
|
İhlal edilen spesifik politikanın metin açıklaması. | ||
|
Açıklama
Politika İhlali Bayrağı bir ihlalin meydana geldiğini gösterirken, bu öznitelik 'nedenini' sağlar. '50 dolar yemek limitini aştı' veya '25 dolar üzerindeki harcamalar için makbuz gerekli' gibi ihlal edilen belirli kural hakkında ayrıntılar içerir. Bu ayrıntı seviyesi, 'Politika İhlali ve Yeniden İşleme Analizi' dashboard'u için paha biçilmezdir. En yaygın ihlal türlerini belirleyerek temel neden analizine olanak tanır. Bu içgörü, belirli bir politikayı netleştirmek, çalışanlara hatırlatıcılar göndermek veya otomatik sistem kurallarını ayarlamak gibi hedefe yönelik eylemleri yönlendirebilir.
Neden önemli
Politika ihlallerinin temel nedenini sağlar, politikaların, kullanıcı eğitimlerinin ve sistem konfigürasyonlarının hedefe yönelik iyileştirilmesini mümkün kılar.
Nereden alınır
Bu bilgi, Brex'te işaretlenmiş bir harcama ile ilişkili uyumluluk veya inceleme notları bölümünde bulunabilir.
Örnekler
Masraf kategori limitini aşıyor.Makbuz eksik.Yinelenen masraf tespit edildi.
|
|||
|
Ret Nedeni
RejectionReason
|
Bir yönetici veya finans kullanıcısı tarafından bir harcama raporunu reddetmek için verilen neden. | ||
|
Açıklama
Bu öznitelik, bir harcama raporu reddedildiğinde verilen serbest metin veya önceden tanımlanmış nedeni yakalar. Bu, otomatik bir politika bayrağından farklıdır ve bir onaylayıcı tarafından manuel bir kararı temsil eder. Ret nedenlerini analiz etmek, süreç başarısızlıklarının ve yeniden işleme nedenlerinin anlaşılması için kritik öneme sahiptir. Ortak gönderim hatalarını, belirsiz politikaları veya çalışanların veya yöneticilerin yanlış anlamalarını belirlemeye yardımcı olur. Bu bilgiler, eğitim materyallerini ve Sıkça Sorulan Soruları iyileştirmek için kullanılabilir ve nihayetinde ret ve yeniden işleme oranlarını azaltır.
Neden önemli
Manuel retlerin neden meydana geldiğini açıklar, kullanıcı eğitimini iyileştirmek ve gelecekteki hataları azaltmak için kullanılabilecek doğrudan geri bildirim sağlar.
Nereden alınır
Bu, tipik olarak onaylayıcıların Brex kullanıcı arayüzünde 'Reddet' eylemini gerçekleştirdiklerinde doldurabilecekleri bir yorum alanıdır.
Örnekler
Yanlış masraf kategorisi seçildi.Lütfen daha detaylı bir iş gerekçesi sunun.Bu satın alma önceden onaylanmamıştı.
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, analiz edilen verinin güncelliğini gösterir. Brex'ten son başarılı veri çıkarma tarihini ve saatini kaydeder. Son veri güncelleme zamanını bilmek, kullanıcıların içgörülerin güncelliğini anlaması için kritik öneme sahiptir. Kontrol panellerinin operasyonların en güncel durumunu mu yansıttığını yoksa daha eski verilere mi dayandığını belirlemelerine yardımcı olur ve analizin gerçek zamanlı doğruluğu hakkındaki beklentileri yönetir.
Neden önemli
Kullanıcılara verinin güncelliği hakkında bilgi verir, bu da doğru, güncel operasyonel kararlar almak için kritik öneme sahiptir.
Nereden alınır
Bu zaman damgası, Brex'ten başarılı bir veri çekme işleminin sonunda veri çıkarma aracı veya süreci tarafından oluşturulur.
Örnekler
2023-11-20T02:00:00Z2023-11-21T02:00:00Z
|
|||
|
Ülke
Country
|
Çalışan veya harcama işlemiyle ilişkili ülke. | ||
|
Açıklama
Bu öznitelik, çalışanın birincil ofisinin veya maliyet merkezinin ülkesini gösterir. Küresel şirketler için bu, karşılaştırmalı analiz için önemli bir boyuttur. Süreci ülke bazında analiz etmek, süreç performansında, uyumluluk oranlarında veya harcama davranışlarında bölgesel farklılıkları vurgulayabilir. Örneğin, onay süreleri bir ülkede yerel düzenlemeler veya farklı yönetim yapıları nedeniyle daha uzun olabilir. Bu içgörü, yerel ihtiyaçları karşılarken süreçleri küresel olarak standartlaştırmak için değerlidir.
Neden önemli
Çok uluslu kuruluşlar için kritik olan farklı coğrafi bölgelerdeki süreç performansının ve uyumluluğun analizine olanak tanır.
Nereden alınır
Brex içindeki çalışanın profil bilgilerinden alınır; bu bilgiler genellikle merkezi bir İK sisteminden senkronize edilir.
Örnekler
USACANGBRDEU
|
|||
|
Yeniden İşleme mi?
IsRework
|
Raporun en az bir kez revizyon için geri gönderildiğini gösteren hesaplanmış bir bayrak. | ||
|
Açıklama
Bu boolean öznitelik, süreç akışından türetilmiştir. Geçmişinde 'Rapor Revizyon İçin Gönderildi' etkinliğini içeren her harcama raporu için 'doğru' olarak ayarlanır. Bu, yeniden işlenmiş vakaları etiketlemenin ve analiz etmenin basit bir yolunu sağlar. Bu bayrak, 'Harcama Raporu Yeniden İşleme Oranı' KPI'ını hesaplamak ve 'Politika İhlali ve Yeniden İşleme Analizi' dashboard'unu desteklemek için kullanılır. Süreçten sorunsuz geçen vakalar ile geri gönderilen vakalar arasında kolay karşılaştırma yapılmasına olanak tanır, böylece yeniden işleme ile ilişkili zaman ve maliyetin belirlenmesine yardımcı olur.
Neden önemli
Ekstra çalışma ve düzeltme gerektiren masraf raporlarını belirler, bu da yeniden işin nedenleri ve maliyetlerinin analiz edilmesine olanak tanır.
Nereden alınır
Bu öznitelik kaynak sistemde bulunmamaktadır. Bir vaka için etkinlik dizisinin 'Rapor Revizyon İçin Gönderildi' veya benzeri yeniden işleme etkinlikleri içerip içermediği kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
Masraf Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Finans Onaylandı
|
Finans departmanı incelemesini tamamladı ve harcama raporu için son onayı verdi. Bu, geri ödeme işlemi yapılmadan önceki son onay kapısıdır. | ||
|
Neden önemli
Bu, ödemeyi yetkilendiren kritik bir kilometre taşıdır. Tam onay döngüsünü ölçmek için bitiş noktası ve 'Geri Ödeme Yürütme Gecikmesi' KPI'sını ölçmek için başlangıç noktasıdır.
Nereden alınır
Bu olay, nihai onaylayanın kimliği ve bir zaman damgası ile bir onay geçmişine veya denetim izine açıkça kaydedilmelidir.
Yakala
Bir event log'dan veya 'Finans Onaylandı' veya 'Ödeme İçin Onaylandı' durum değişikliğinden yakalandı.
Event tipi
explicit
|
|||
|
Geri Ödeme Gerçekleşti
|
Bu etkinlik, ödemenin çalışana fiilen ödendiği anı işaret eder. Bu, çalışanın bakış açısından son adım ve sürecin başarılı bir sonudur. | ||
|
Neden önemli
Bu, sürecin birincil başarı bitiş noktasıdır. 'Ortalama Uçtan Uca Döngü Süresi' ve 'Geri Ödeme Yürütme Gecikmesi' KPI'larını hesaplamak için gereklidir ve çalışan memnuniyetini doğrudan etkiler.
Nereden alınır
Bu olay, ödeme işlem günlüklerinden veya bir banka ya da ödeme işlemcisinden gelen bir API onayından yakalanmalıdır. Gerçek ödeme yürütme tarihine karşılık gelir.
Yakala
Bir yürütme zaman damgası içeren ödeme işlem log'undan yakalandı.
Event tipi
explicit
|
|||
|
Masraf Raporu Gönderildi
|
Bu etkinlik, çalışanın tamamlanmış harcama raporunu onay için resmi olarak göndermesiyle gerçekleşir. Raporun durumunu 'Taslak' veya 'Açık'tan 'Onay Bekleniyor'a geçiren önemli bir kullanıcı odaklı eylemdir. | ||
|
Neden önemli
Bu, onay iş akışını resmi olarak başlatan önemli bir kilometre taşıdır. Gönderim ve nihai onay arasındaki süre, genel döngü süresinin kritik bir bileşenidir.
Nereden alınır
Bu, tipik olarak bir denetim günlüğüne kaydedilen açık bir olaydır veya 'Gönderildi' veya 'Yönetici Onayı Bekleniyor' durumuna geçişten ve buna karşılık gelen bir zaman damgasından çıkarılabilir.
Yakala
Event log'dan veya masraf raporu kaydındaki 'submission_timestamp' alanından yakalandı.
Event tipi
explicit
|
|||
|
Masraf Raporu Oluşturuldu
|
Bu etkinlik, bir çalışan tarafından bir harcama raporunun başlatılmasını işaret eder. Sistem, yeni bir harcama raporu kaydı taslak olarak veya başlangıçtaki harcama kalemleri eklenmiş olarak oluşturulduğunda bu olayı yakalar. | ||
|
Neden önemli
Bu, sürecin birincil başlangıç olayıdır. Bu noktadan gönderime kadar geçen süreyi analiz etmek, çalışan davranışlarını ve harcamaların raporlanmasındaki potansiyel gecikmeleri anlamaya yardımcı olur.
Nereden alınır
Bu olay muhtemelen Brex veritabanındaki harcama raporu nesnesinin veya kaydının oluşturma zaman damgasından yakalanır. Harcama Raporu Kimliği ile ilişkili en erken zaman damgasına karşılık gelmelidir.
Yakala
Masraf raporu başlık kaydının oluşturulma tarihi ile belirlenir.
Event tipi
explicit
|
|||
|
Muhasebe Kaydı Yapıldı
|
Harcama verilerinin şirketin genel muhasebesine veya ERP sistemine başarıyla gönderildiği son adımı temsil eder. Bu, harcama raporunun finansal mutabakatını tamamlar. | ||
|
Neden önemli
Bu etkinlik, finansal muhasebe perspektifinden sürecin tamamlandığını doğrular. Geri ödeme ve kaydetme arasındaki gecikmeler, sistem entegrasyonu veya muhasebe iş akışlarıyla ilgili sorunlara işaret edebilir.
Nereden alınır
Bu, muhtemelen bir API onayı veya muhasebe sistemiyle başarılı bir senkronizasyon sonrası bir durum güncellemesi aracılığıyla yakalanır. Olay zaman damgası, kaydetme zamanını yansıtır.
Yakala
Entegre ERP veya muhasebe yazılımından başarılı API geri çağrısı veya durum güncellemesi üzerine loglandı.
Event tipi
explicit
|
|||
|
Rapor Revizyon İçin Gönderildi
|
Bir onaylayıcı, yönetici veya finans, raporu düzeltilmesi için çalışana geri gönderir. Bu, kesin bir ret işleminden farklıdır ve bir yeniden işleme döngüsü başlatır. | ||
|
Neden önemli
Bu etkinlik, yeniden işleme (rework) nin birincil göstergesidir. Sıklığını takip etmek, 'Harcama Raporu Yeniden İşleme Oranı' KPI'ı ve 'Politika İhlali ve Yeniden İşleme Analizi' dashboard'u için hayati öneme sahiptir.
Nereden alınır
Bu, muhtemelen durumun 'Revizyon Gerekiyor' veya 'Geri Gönderildi' olarak değişmesinden çıkarılır. Sistem bu durum güncellemesinin zaman damgasını yakalamalıdır.
Yakala
'Revizyon Gerekiyor' gibi bir duruma geçişten çıkarılmıştır, genellikle yorumlarla birlikte.
Event tipi
inferred
|
|||
|
Yönetici Onayladı
|
Birinci seviye yönetici harcama raporunu inceledi ve daha fazla işlem için onayladı. Bu, raporu bir sonraki aşamaya, genellikle finans incelemesine veya otomatik onaya taşıyan önemli bir karar noktasıdır. | ||
|
Neden önemli
Bu kilometre taşı, ilk onay adımını tamamlar. Onay döngüsü sürelerini, yönetici iş yükünü ve 'İlk Geçiş Onay Oranı'nı takip etmek için hayati öneme sahiptir.
Nereden alınır
Bu olay, onaylayanın kimliği ve bir zaman damgası içeren bir onay geçmişi tablosunda veya denetim izinde açıkça günlüğe kaydedilir.
Yakala
Bir event log'dan veya ilişkili bir zaman damgasıyla 'Yönetici Onaylandı' durum değişikliğinden yakalandı.
Event tipi
explicit
|
|||
|
Finans İncelemesi Başlatıldı
|
Bir masraf raporunun nihai inceleme için finans veya muhasebe departmanının kuyruğuna ne zaman girdiğini işaretler. Bu genellikle yönetici onayından sonra bir durum değişikliğinden çıkarılır. | ||
|
Neden önemli
Bu, son ve genellikle en kritik onay aşamasının başlangıcını işaret eder. Süresini analiz etmek, finans departmanındaki darboğazları belirlemeye yardımcı olur.
Nereden alınır
Bu, raporun durumu yönetici onayının ardından 'Finans Onayı Bekleniyor' veya benzeri bir duruma geçtiğinde zaman damgasından çıkarılır.
Yakala
'Finans İncelemesi Bekleniyor' durum değişikliğinin zaman damgasından çıkarılmıştır.
Event tipi
inferred
|
|||
|
Finans Reddedildi
|
Finans departmanı, genellikle politika, uyumluluk veya belge nedenleriyle harcama raporunu reddetti. Bu, süreci durduran nihai bir reddetmedir. | ||
|
Neden önemli
Bu, önemli bir istisna olayıdır. Sıklığını ve nedenlerini analiz etmek, uyumluluk bozulmalarını anlamak ve genel 'Harcama Raporu Ret Oranı'nı hesaplamak için hayati öneme sahiptir.
Nereden alınır
Diğer onay kararları gibi, bu da onaylayıcının kimliği, bir zaman damgası ve bir neden ile denetim izinde açıkça loglanmalıdır.
Yakala
Bir event log'dan veya 'Finans Reddedildi' durum değişikliğinden yakalandı.
Event tipi
explicit
|
|||
|
Geri Ödeme Planlandı
|
Son onayın ardından, masraf raporu yaklaşan bir geri ödeme grubunda ödeme için sıraya alınır. Bu aktivite, onaydan ödeme sistemine geçişi temsil eder. | ||
|
Neden önemli
Bu adım, nihai onay ile gerçek ödeme işleme arasındaki gecikmeleri ortaya çıkarabilir. Onay darboğazları ile ödeme sistemi verimsizlikleri arasında ayrım yapmaya yardımcı olur.
Nereden alınır
Bu, 'Ödeme için Hazır' veya 'Planlandı' durumuna geçişten çıkarılabilir. Sistem ayrı bir ödeme veya ERP sistemiyle arayüz kuruyorsa açık bir olay da olabilir.
Yakala
'Ödeme Bekliyor' durum değişikliğinden veya bir ödeme grubu kaydının oluşturulmasından çıkarılmıştır.
Event tipi
inferred
|
|||
|
Makbuzlar Eklendi
|
Bir kullanıcının bir makbuz görseli veya belgesini bir harcama kalemine yüklemesi veya eklemesi eylemini temsil eder. Bu genellikle her ek için bir zaman damgasıyla açık bir olay olarak yakalanır. | ||
|
Neden önemli
Bu etkinliği takip etmek, 'Makbuz Uyumluluğu ve Etkisi' dashboard'u için kritik öneme sahiptir. Gecikmelerin veya retlerin eksik veya geç makbuz gönderimleriyle ilişkili olup olmadığını belirlemeye yardımcı olur.
Nereden alınır
Bu, muhtemelen ekleri harcama kalemlerine bağlayan ilgili bir tabloda kaydedilir. Her ek kaydının kendi oluşturma zaman damgası olmalıdır.
Yakala
Bir kullanıcı, bir masraf kalemiyle ilişkili bir dosyayı başarıyla yüklediğinde loglandı.
Event tipi
explicit
|
|||
|
Politika İhlali İşaretlendi
|
Rapordaki bir veya daha fazla masraf kaleminin şirket politikasını ihlal ettiğini gösteren otomatik veya manuel bir olay. Bu, bir sistem kuralı tetiklendiğinde veya bir gözden geçiren manuel olarak bir sorun işaretlediğinde yakalanabilir. | ||
|
Neden önemli
Bu etkinlik, 'Politika İhlali ve Yeniden İşleme Analizi' dashboard'u ve 'Politika İhlali Oranı' KPI'ı için kritik öneme sahiptir. Ortak uyumluluk sorunlarını ve politika netleştirme alanlarını belirlemeye yardımcı olur.
Nereden alınır
'Politika İhlali Bayrağı' özniteliğinin doğru olarak ayarlanmasından türetilmiştir. Zaman damgası, bayrağın durumunun en son güncellendiği zaman olacaktır.
Yakala
Bir politika ihlalini gösteren bir boolean bayrak veya durum alanındaki değişiklikten çıkarılmıştır.
Event tipi
inferred
|
|||
|
Yönetici İncelemesi Başlatıldı
|
Bu etkinlik, bir harcama raporunun yöneticinin onay kuyruğuna girdiği noktayı işaret eder. Genellikle, raporun durumu gönderimden hemen sonra 'Yönetici Onayı Bekleniyor' olarak değiştiğinde anlaşılır. | ||
|
Neden önemli
Bu, ilk onay aşamasının başlangıcını işaret eder. Bu noktadan 'Yönetici Onayladı' veya 'Yönetici Reddedildi'ye kadar olan süreyi ölçmek, 'Ortalama Yönetici İnceleme Süresi' KPI'ı için önemlidir.
Nereden alınır
Bu, harcama raporu durumu 'Yönetici Onayı Bekleniyor' veya benzeri bir duruma geçtiğinde zaman damgasından çıkarılır. Genellikle 'Harcama Raporu Gönderildi' olayıyla çakışır.
Yakala
'Yönetici Onayı Bekleniyor' durum değişikliğinin zaman damgasından çıkarılmıştır.
Event tipi
inferred
|
|||
|
Yönetici Reddedildi
|
Birinci seviye yönetici harcama raporunu inceledi ve reddetti. Bu eylem genellikle süreci durdurur veya raporu düzeltme için çalışana geri gönderir. | ||
|
Neden önemli
Bu etkinlik, olumsuz bir sonucu ve bir süreç istisnasını temsil eder. 'Harcama Raporu Ret Oranı'nı hesaplamak ve ilk onay seviyesindeki başarısızlık nedenlerini belirlemek için kritik öneme sahiptir.
Nereden alınır
Bu, bir onaya benzer şekilde, bir zaman damgası ve neden koduyla bir onay geçmişi tablosunda veya denetim izinde açıkça günlüğe kaydedilmelidir.
Yakala
Bir event log'dan veya ilişkili bir zaman damgasıyla 'Yönetici Reddedildi' durum değişikliğinden yakalandı.
Event tipi
explicit
|
|||