Gider Yönetimi Veri Template'inuz
Gider Yönetimi Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Ramp için veri çekme kılavuzu
Masraf Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite Adı
ActivityName
|
Harcama yönetimi süreci içinde belirli bir zamanda meydana gelen belirli event veya görevin adı. | ||
|
Açıklama
Bu öznitelik, 'Harcama Gönderildi', 'Yönetici Onayladı' veya 'Geri Ödeme Gerçekleştirildi' gibi harcama raporu süreç döngüsündeki tek bir adımı açıklar. Bu aktiviteler, süreç haritasındaki düğümleri oluşturarak süreç akışının görselleştirilmesine ve analiz edilmesine sunar. Aktiviteleri analiz etmek, hangi adımların en sık olduğunu, darboğazların nerede meydana geldiğini ve farklı iş akışlarının nasıl değiştiğini belirlemeye yardımcı olur. Operasyonların sırasını anlamak ve her aşamada performansı ölçmek için temel bir bileşendir.
Neden Önemli?dir?
Süreç haritasındaki adımları tanımlar, süreç akışının baştan sona görselleştirilmesini ve analiz edilmesini sunar.
Nereden Alınır??
Bu, genellikle Ramp'teki her harcama raporuyla ilişkili event log'larından veya durum değişikliği kayıtlarından türetilir.
Örnekler:::::::
Gider GönderildiYönetici OnayladıFinans İncelemesi BekleniyorGeri Ödeme Gerçekleşti
|
|||
|
Masraf Raporu Kimliği
ExpenseReportId
|
Her harcama raporu için sürecin birincil case tanımlayıcı'ı olarak hizmet veren benzersiz tanımlayıcı. | ||
|
Açıklama
Gider Raporu Kimliği, tek bir harcama gönderimine ilişkin tüm olayları ve aktiviteleri gruplandırır. Bir harcama talebinin ilk girişinden nihai ödemesine kadar eksiksiz, kronolojik takibine sunar. Process Mining'de bu öznitelik, her harcama raporunun tüm sürecini yeniden yapılandırmak için gereklidir. Bunu case ID olarak kullanarak analizler, döngü sürelerini doğru bir şekilde hesaplayabilir, darboğazları belirleyebilir ve raporların onay sürecinde izlediği farklı yolları görselleştirebilir.
Neden Önemli?dir?
Bu, tüm ilgili aktiviteleri tek bir süreç örneğine bağlayan temel özniteliktir ve uçtan uca analizi sunar.
Nereden Alınır??
Bu tanımlayıcı, Ramp içindeki ana harcama raporu veya işlem tablosunda bulunmalıdır.
Örnekler:::::::
ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
|
|||
|
Olay Zaman Damgası
EventTimestamp
|
Aktivitenin gerçekleştiği tam tarih ve saat. | ||
|
Açıklama
Süreçteki her aktivitenin, ne zaman gerçekleştiğini kaydeden bir zaman damgası (zaman damgası) vardır. Bu zamansal veri, olayları kronolojik olarak sıralamak için kullanılır ve tüm zamanla ilgili analizlerin temelini oluşturur. Process Miningnde, zaman damgaları aktiviteler arasındaki döngü sürelerini hesaplamak, bir vakanın toplam süresini ölçmek ve gecikmeleri belirlemek için kullanılır. Bu bilgi, performans izleme ve süreç iyileştirme fırsatlarını belirlemek için büyük önem taşır.
Neden Önemli?dir?
Bu öznitelik, olayların kronolojik sırasını sunar ve tüm süre hesaplamaları ile performans analizi için gereklidir.
Nereden Alınır??
Bu bilgi genellikle Ramp'in event log'larında veya işlem verilerinde aktivite veya durum kayıtlarının yanında bulunur.
Örnekler:::::::
2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
|
|||
|
Çalışanşan Departmanı
EmployeeDepartment
|
Harcama raporunu gönderen çalışanın departmanı. | ||
|
Açıklama
Bu öznitelik, harcamayı gönderen çalışanın ait olduğu iş birimini veya departmanı gösterir; örneğin 'Satış', 'Mühendislik' veya 'Pazarlama'. Bu, analiz için önemli bir boyuttur, çünkü kuruluşun farklı bölümlerindeki süreç performansını filtrelemeye ve karşılaştırmaya sunar. Departmanlar arasındaki onay süreleri, revizyon oranları ve politika uyumluluğundaki farklılıkları ortaya çıkararak hedeflenen iyileştirme girişimlerini destekleyebilir.
Neden Önemli?dir?
Farklı iş birimleri arasında süreç metriklerinin karşılaştırılmasını sunar, verimlilik, uyumluluk ve harcamalardaki farklılıkları vurgular.
Nereden Alınır??
Bu bilgi muhtemelen çalışanın Ramp'teki kullanıcı profili veya entegre bir İK sistemi ile ilişkilidir.
Örnekler:::::::
SatışPazarlamaMühendislikFinans
|
|||
|
Kullanıcı Adı
UserName
|
Harcamayı gönderen çalışan veya onaylayan dahil olmak üzere, aktiviteyi gerçekleştiren kullanıcının adı veya ID'si. | ||
|
Açıklama
Bu öznitelik, süreçteki belirli bir event'ten (örneğin, bir harcama raporunu gönderme, onaylama veya inceleme) sorumlu kişiyi tanımlar. Bu, bir çalışanın adı veya benzersiz bir kullanıcı ID'si olabilir. Kullanıcıya göre analiz yapmak, iş yükü dağılımını anlamaya, en iyi performans gösterenleri belirlemeye ve ek eğitim gerektirebilecek kişileri tespit etmeye yardımcı olur. Onay performansı ve kaynak yönetimi ile ilgili kontrol paneli'lar için önemlidir.
Neden Önemli?dir?
Süreç aktivitelerini belirli kişilere atar, bu da kaynak düzeyinde performans analizi yapılmasına ve eğitim ihtiyaçlarının belirlenmesine sunar.
Nereden Alınır??
Kullanıcı bilgileri genellikle Ramp'teki her harcama raporunun denetim izinde veya işlem geçmişinde kaydedilir.
Örnekler:::::::
Alice Johnson`Bob Smith``Charlie Brown`Sistem Otomasyonu`
|
|||
|
Masraf Kategorisi
ExpenseCategory
|
Bir harcamaya atanan kategori, örneğin 'Seyahat', 'Yazılım' veya 'Yemek'. | ||
|
Açıklama
Bu öznitelik, harcamaları önceden tanımlanmış kategorilere ayırır, bu da şirket harcamalarının takip edilmesine ve kontrol edilmesine yardımcı olur. Tek bir harcama raporu birden fazla kategoriden öğeler içerebilir. Harcama kategorisine göre analiz yapmak, 'Harcama Kategorisi Analizi' kontrol paneli'u için gereklidir. Finans ekiplerinin paranın nerede harcandığını anlamasına, bütçe uyumluluğunu izlemesine ve zaman içindeki harcama eğilimlerini veya anormalliklerini belirlemesine yardımcı olur.
Neden Önemli?dir?
Detaylı harcama analizi yapılmasına sunar, ana maliyet unsurlarını ve bütçe optimizasyonu fırsatlarını belirlemeye yardımcı olur.
Nereden Alınır??
Bu genellikle Ramp'teki harcama raporunda satır kalemi düzeyinde bir detaydır. Bazı analizler için verilerin rapor düzeyine toplanması gerekebilir.
Örnekler:::::::
Uçak BiletiYiyecek ve EğlenceYazılım AboneliğiOfis Malzemeleri
|
|||
|
Politika İhlali Bayrağı
PolicyViolationFlag
|
Gider raporunun bir politika ihlali nedeniyle işaretlenip işaretlenmediğini gösteren bir bayrak. | ||
|
Açıklama
Bu boolean öznitelik, sistemin otomatik kontrolleri bir harcama limitini aşma veya yinelenen bir harcama gönderme gibi şirket harcama politikalarının potansiyel bir ihlalini tespit ederse true olarak ayarlanır. Bu bayrak, 'Politika İhlali Tespiti' kontrol paneli'u ve ilgili KPI için büyük önem taşır. Politika kontrollerinin etkinliğini ölçmeye ve yaygın uyumsuzluk alanlarını belirlemeye yardımcı olur, bu da politika güncellemelerini veya çalışan eğitimini bilgilendirebilir.
Neden Önemli?dir?
Politika uyumluluğunu doğrudan ölçer, uyumsuz harcamaları ve ilgili riskleri belirlemeye ve azaltmaya yardımcı olur.
Nereden Alınır??
Bu, Ramp içinde gönderim veya onay süreci sırasında otomatik politika kontrolleri tarafından tetiklenen sistem tarafından oluşturulmuş bir bayrak olması muhtemel teşkil eder.
Örnekler:::::::
truefalse
|
|||
|
Rapor Toplam Tutarı
ReportTotalAmount
|
Harcama raporunun toplam parasal değeri. | ||
|
Açıklama
Bu öznitelik, tek bir rapora dahil edilen tüm harcamaların toplamını temsil eder. Harcama kalıplarını anlamak için önemli bir finansal metriktir. Süreç analizinde, rapor tutarı case'leri segmentlere ayırmak ve yüksek değerli raporların farklı onay yollarını izleyip izlemediğini veya işlemenin daha uzun sürüp sürmediğini araştırmak için kullanılabilir. Harcama analizi panelleri ve maliyet tasarrufu fırsatlarını belirlemek için büyük önem taşır.
Neden Önemli?dir?
Analiz için önemli bir finansal boyut sunar, raporların değere göre segmentlere ayrılmasına ve genel harcamaların izlenmesine sunar.
Nereden Alınır??
Bu, Ramp'teki harcama raporu nesnesi üzerindeki birincil alandır.
Örnekler:::::::
150.752500.0089.99
|
|||
|
Revizyon Nedeni
RevisionReason
|
Bir harcama raporu çalışana revizyon için geri gönderildiğinde verilen neden. | ||
|
Açıklama
Bir onaylayıcı bir harcama raporunu reddettiğinde veya geri gönderdiğinde, genellikle bir neden belirtir. Bu öznitelik, 'Eksik Fiş', 'Yanlış Kategori' veya 'Politika Dışı' gibi bu nedeni yakalar. Bu bilgi, 'Harcama Revizyon Oranı ve Nedenleri' kontrol paneli'u için büyük önem taşır. Yeniden işlemenin en yaygın nedenlerini analiz ederek, kuruluşlar gönderim sürecindeki sistemik sorunları belirleyebilir ve hataları azaltmak için hedeflenen eğitim veya sistem iyileştirmeleri uygulayabilir.
Neden Önemli?dir?
Yeniden işleme temel nedenlerine doğrudan önemli bilgi sunar, ilk seferdeki gönderim kalitesini artırmak için hedeflenen eylemleri sunar.
Nereden Alınır??
Bu veri, Ramp'te 'Harcama Revizyon İçin Geri Gönderildi' aktivitesi gerçekleştiğinde yorumlarda veya ret detaylarında yakalanacaktır.
Örnekler:::::::
Ayrıntılı fiş eksikliğiGider politika limitini aşıyorYanlış gider kategorisi seçildiTekrar eden işlem
|
|||
|
Denetim Sonucu
AuditOutcome
|
Harcama raporunun dahili veya harici denetiminin sonucu. | ||
|
Açıklama
Resmi bir denetimden geçen gider raporları için bu öznitelik, 'Onaylandı', 'Kısmen Reddedildi' veya 'Daha Fazla Bilgi Gerekli' gibi nihai sonucu kaydeder. Bu veri, 'Gider Denetim Performansı' kontrol paneli'unun merkezindedir. Denetim sürecinin etkinliğini değerlendirmeye, farklı sonuçların sıklığını izlemeye ve denetim bulgularının finansal etkisini anlamaya yardımcı olur.
Neden Önemli?dir?
Denetim sürecinin etkinliğini ve sonuçlarını ölçer, uyumluluk ve kontrol zayıflıkları hakkında stratejik bilgiler sunar.
Nereden Alınır??
Bu, Ramp'in denetim modülünde veya ayrıntılı harcama denetimi için kullanılıyorsa entegre bir sistemde kaydedilecektir.
Örnekler:::::::
BaşarılıNotlarla GeçtiReddedildiÜst Düzeye Aktarıldı
|
|||
|
Finans Onaylayıcısı
FinanceApprover
|
Harcama raporunu onaylayan finans ekibinden kullanıcı. | ||
|
Açıklama
Bir finans inceleme adımını içeren iş akışları için bu öznitelik, nihai onayı gerçekleştiren finans departmanındaki belirli kişiyi veya ekibi tanımlar. Bu öznitelik, performansı bireysel veya ekip düzeyinde analiz etmeye olanak tanıyarak 'Finans İnceleme Verimliliği' kontrol paneli'unu destekler. Darboğazları belirlemeye, iş yükü dağılımını değerlendirmeye ve finans inceleme aşamasının etkinliğini ölçmeye yardımcı olur.
Neden Önemli?dir?
Finans inceleme adımının detaylı performans analizine sunar, süreçteki kritik bir kontrol noktasını optimize etmeye yardımcı olur.
Nereden Alınır??
Bu, Ramp'teki harcama raporunun onay geçmişinde, finansal inceleme aşamasında yakalanacaktır.
Örnekler:::::::
Finans Ekibi ADavid LeeFinans Otomasyon Botu
|
|||
|
Geri Ödeme Yöntemi
ReimbursementMethod
|
ACH veya banka havalesi gibi geri ödeme ödemesini gerçekleştirmek için kullanılan yöntem. | ||
|
Açıklama
Bu öznitelik, çalışanın hangi ödeme kanalı aracılığıyla geri ödendiğini belirtir. Farklı yöntemlerin farklı işlem süreleri ve maliyetleri olabilir. Geri ödeme performansını yönteme göre analiz etmek, en verimli ödeme kanallarını belirlemeye yardımcı olur. 'Geri Ödeme Yöntemi Performansı' kontrol paneli'u bu verileri döngü sürelerini ve güvenilirliği karşılaştırmak için kullanarak potansiyel olarak ödeme stratejilerinin optimize edilmesine yol açabilir.
Neden Önemli?dir?
Farklı ödeme kanalları arasında performans karşılaştırmasına sunar, hız ve güvenilirlik için optimizasyon yapmaya yardımcı olur.
Nereden Alınır??
Bu bilgi, Ramp içindeki ödeme veya geri ödeme kayıtlarında bulunmalıdır.
Örnekler:::::::
ACH TransferiKurumsal Kart KredisiDoğrudan Para Yatırma
|
|||
|
Gönderim Yöntemi
SubmissionMethod
|
Harcama raporunun mobil uygulama veya web portalı gibi hangi kanal aracılığıyla gönderildiği. | ||
|
Açıklama
Bu öznitelik, çalışanın harcama raporunu nasıl gönderdiğini gösterir. Yaygın yöntemler arasında mobil uygulama, masaüstü web tarayıcısı veya e-posta yönlendirme bulunur. Gönderim yöntemini analiz etmek, kullanıcı davranışı ve teknoloji adaptasyonu hakkında stratejik bilgiler sağlayabilir. Örneğin, belirli bir kanal aracılığıyla gönderilen raporlar için yüksek bir revizyon oranı, o kanalın arayüzünde kullanılabilirlik sorunları olduğunu gösterebilir.
Neden Önemli?dir?
Kullanıcı davranışına ilişkin bağlam sunar ve belirli gönderim kanallarının daha yüksek hata oranları veya gecikmelerle ilişkili olup olmadığını belirlemeye yardımcı olabilir.
Nereden Alınır??
Bu bilgi, Ramp'in sistem log'larındaki gönderim olayınin metadata'sında yakalanabilir.
Örnekler:::::::
Mobil UygulamaWeb PortalE-posta
|
|||
|
Kaynak Sistem
SourceSystem
|
Verilerin çıkarıldığı kaynak uygulamayı tanımlar. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kayıt sistemini belirtir, ki bu durumda Ramp'tir. Verilerin birden fazla sistemden karıştırılabileceği ortamlarda, net veri soyutlaması sağlayarak faydalıdır. Analiz için, belirli bir kaynaktan veri filtrelemeye yardımcı olur ve veri doğrulama ve yönetişim amaçları için kullanılabilir.
Neden Önemli?dir?
Verilerin kökeni hakkında bağlam sunar, bu da veri yönetimi ve birden fazla sistemden veri entegre edilirken büyük önem taşır.
Nereden Alınır??
Bu, veri çekme ve dönüşüm süreci sırasında eklenen genellikle statik bir değerdir ('Ramp').
Örnekler:::::::
Ramp
|
|||
|
Olay Bitiş Zamanı
EventEndTime
|
Süresi olan bir aktivitenin ne zaman sona erdiğini gösteren zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Birçok aktivite anlık olsa da, 'Politika Kontrolü Yapıldı' gibi bazı aktivitelerin ölçülebilir bir süresi olabilir. Bu öznitelik, bu tür aktivitelerin bitiş zamanını yakalar ve Başlangıç Zamanı'nı tamamlar. Hem başlangıç hem de bitiş zamanına sahip olmak, aktivite işlem sürelerinin hassas bir şekilde hesaplanmasına sunar. Bu, 'Ortalama Politika Kontrol Süresi' gibi KPI'lar ve genel süreç içinde belirli otomatik veya manuel görevlerin tamamlanmasının tam olarak ne kadar sürdüğünü belirlemek için gereklidir.
Neden Önemli?dir?
Bireysel aktivite sürelerinin hassas bir şekilde hesaplanmasını sunar, bu da verimsiz süreç adımlarını belirlemek için büyük önem taşır.
Nereden Alınır??
Süresi olan aktiviteler için bu, Ramp'in olay verilerinde günlüğe kaydedilir. Anlık olaylar için ise StartTime ile aynı olabilir.
Örnekler:::::::
2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
|
|||
|
Onay Adım Sayısı
ApprovalStepCount
|
Bir harcama raporunun geçtiği toplam resmi onay adımı sayısı. | ||
|
Açıklama
Bu hesaplanmış metrik, tek bir harcama raporu için gerçekleşen 'Yönetici Onayladı' ve 'Finans Onayladı' gibi farklı onay aktivitelerinin sayısını sayar. Onay iş akışını (workflow)nun karmaşıklığını ölçmeye yardımcı olur. Bu öznitelik, 'Rapor Başına Ortalama Onay Adımı' KPI'sı ve 'Basit Harcama Onay Yolları' kontrol paneli'u için kullanılır. Bu sayıyı, özellikle raporun değeri veya kategorisiyle ilişkili olarak analiz ederek, kuruluşlar basit, düşük değerli harcamaların aşırı karmaşık onay süreçlerine tabi olup olmadığını belirleyebilir.
Neden Önemli?dir?
İş akışı karmaşıklığını ölçülmesini sağlar, basitleştirme fırsatlarını belirlemeye yardımcı olur, özellikle düşük riskli raporlar için.
Nereden Alınır??
Bu, event logndaki her vaka içinde belirli onay ile ilgili aktivitelerin sayılmasıyla hesaplanır.
Örnekler:::::::
123
|
|||
|
Onaylayan Yönetici
ApprovingManager
|
Onay adımını gerçekleştiren yöneticinin adı. | ||
|
Açıklama
Bu öznitelik, bir çalışanın harcama raporunu incelemekten ve onaylamaktan sorumlu yöneticiyi tanımlar. Raporu gönderen kullanıcıdan farklıdır. Onaylayan yöneticiyi takip etmek, 'Yönetici Onay Döngüsü Süresi' kontrol paneli'u için gereklidir. Onay iş yüklerini ve performansını analiz etmeye sunar, hızlı onaylayan yöneticileri darboğaz oluşturan yöneticilerden ayırır. Bu, iş yüklerini dengelemeye veya ek destek güçlüaya yardımcı olabilir.
Neden Önemli?dir?
Bireysel onaylayıcıların performans analizini sunar, onay iş akışındaki darboğazları belirlemeye ve gidermeye yardımcı olur.
Nereden Alınır??
Bu bilgi, Ramp'teki onay workflow verilerinin bir parçasıdır ve bir yönetici bir rapor üzerinde işlem yaptığında kaydedilir.
Örnekler:::::::
Ayşe YılmazJohn MillerSusan Chen
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden son yenilendiği zamanı gösteren `zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Bu öznitelik, en son veri çekiminin tarihini ve saatini kaydeder. Analiz edilen verinin güncelliği hakkında bağlam sunar. Herhangi bir analizde, verinin güncelliğini bilmek sonuçları doğru yorumlamak için büyük önem taşır. Bu öznitelik, kullanıcıların güncel bilgilere bakıp bakmadıklarını anlamalarına yardımcı olur.
Neden Önemli?dir?
Kullanıcıları verilerin güncelliği hakkında bilgilendirir, analizlerin güncel ve ilgili bilgilere dayanmasını sunar.
Nereden Alınır??
Bu zaman damgası (zaman damgası), veri çekme süreci sırasında oluşturulur ve eklenir.
Örnekler:::::::
2023-11-01T06:00:00Z
|
|||
|
Yeniden İşleme mi?
IsRework
|
Bir gider raporunun en az bir kez revizyona geri gönderilip gönderilmediğini gösteren hesaplanmış bir bayrak. | ||
|
Açıklama
Bu boolean öznitelik, belirli bir vaka için 'Harcama Revizyon İçin Geri Gönderildi' aktivitesinin gerçekleşip gerçekleşmediği kontrol edilerek türetilir. En az bir revizyon döngüsünden geçmiş herhangi bir rapor için true olarak ayarlanır. Bu bayrak, 'Harcama Raporu Revizyon Oranı' KPI'sının hesaplanmasını basitleştirir ve ilk geçişte onaylanan raporlar ile yeniden işleme gerektiren raporlar arasında kolay filtreleme ve karşılaştırma yapılmasına sunar. Bu iki grubun analizi, revizyonların zaman ve maliyet etkisini ortaya çıkarabilir.
Neden Önemli?dir?
Süreci yeniden işleme analizi için kolayca segmentlere ayırır, düzeltme için geri gönderilen raporların sıklığını ve etkisini ölçmeye yardımcı olur.
Nereden Alınır??
Bu, veri dönüşümü sırasında vaka içinde bir revizyon aktivitesinin varlığı kontrol edilerek türetilen hesaplanmış bir alandır.
Örnekler:::::::
truefalse
|
|||
Masraf Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Geri Ödeme Gerçekleşti
|
Geri ödeme ödemesi başarıyla işlendi ve çalışana gönderildi. Bu genellikle çalışan için son adımdır ve ödeme döngüsünün sonunu işaret eder. | ||
|
Neden Önemli?dir?
Bu, geri ödeme süreci için birincil bitiş event'idir. Gönderimden bu noktaya kadar olan süre, çalışan memnuniyeti ve süreç verimliliği için kritik bir KPI'dır.
Nereden Alınır??
Ödeme işleme günlüklerinden veya ödeme sağlayıcısıyla yapılan bir entegrasyondan yakalandı. Ramp'teki gider durumu 'Geri Ödendi' veya 'Ödendi' olarak güncellenir.
Yakala
Ödeme sistemi başarılı ödeme transferini onayladığında bir olay günlüğe kaydedilir.
Event tipi
explicit
|
|||
|
Gider Gönderildi
|
Bir çalışan, bir gider için gerekli tüm bilgilerin eksiksiz olduğunu onaylar ve onay süreci için gönderir. Bu, gideri 'taslak' veya 'dikkat gerektiren' durumdan 'onay bekleyen' durumuna taşıyan açık bir kullanıcı eylemidir. | ||
|
Neden Önemli?dir?
Bu aktivite, onay ve geri ödeme döngüsünü resmi olarak başlatan kritik bir kilometre taşıdır. Onay ve geri ödeme SLA'larını ölçmek için temel teşkil eder.
Nereden Alınır??
Gider nesnesinin durum geçmişinden yakalandı. Bu, kullanıcının işlemi inceleme için gönderme eylemine karşılık gelir.
Yakala
Kullanıcı 'Gönder' düğmesine tıkladığında, bir durum değişikliğini tetikleyerek günlüğe kaydedilir.
Event tipi
explicit
|
|||
|
Gider Oluştu
|
Bir harcamanın oluşturulmasını işaret eder; genellikle bir kurumsal kart kullanıldığında otomatik olarak veya bir çalışan manuel olarak cep harcaması kaydı oluşturduğunda başlatılır. Bu event genellikle işlem veri akışlarından veya kullanıcı arayüzü eylemlerinden yakalanır. | ||
|
Neden Önemli?dir?
Bu, harcama süreç döngüsü için birincil başlangıç event'idir. Bu event'ten itibaren geçen süreyi analiz etmek, gönderim gecikmelerini ve genel süreç hızını anlamaya yardımcı olur.
Nereden Alınır??
Ramp kart işlem günlüklerinden veya manuel olarak girilen bir gider nesnesinin oluşturulma zaman damgası (zaman damgası)ndan oluşturuldu. Gider veya işlem tablosundaki ilk kayıt oluşturma olayını arayın.
Yakala
Bir kart işlemi işlendiğinde veya bir kullanıcı yeni bir gider girişi oluşturduğunda doğrudan günlüğe kaydedilir.
Event tipi
explicit
|
|||
|
Muhasebe Sistemiyle Senkronize Edildi
|
Harcama işlem verileri, NetSuite, QuickBooks veya Xero gibi entegre muhasebe sistemine başarıyla kaydedildi. Bu event, sürecin finansal kayıt tutma bölümünün tamamlandığını işaret eder. | ||
|
Neden Önemli?dir?
Bu, uçtan uca sürecin son aktivitesidir. Buradaki gecikmeler, finansal raporlamanın doğruluğunu ve finansal kapanışın hızını etkileyebilir.
Nereden Alınır??
Bir entegrasyon log'unda veya Ramp'teki harcama nesnesi üzerinde bir durum güncellemesi olarak kaydedilir. 'Senkronize Edildi', 'Kaydedildi' veya 'Dışa Aktarıldı' gibi bir durum arayın.
Yakala
Başarılı veri senkronizasyonunda muhasebe entegrasyon hizmeti tarafından bir günlük girdisi oluşturulur.
Event tipi
explicit
|
|||
|
Yönetici Onayladı
|
Yönetici harcamayı inceledi ve onayladı, böylece finansal inceleme veya geri ödeme gibi bir sonraki adıma geçmesine izin verdi. Bu, açık bir kullanıcı eylemi aracılığıyla yakalanır. | ||
|
Neden Önemli?dir?
Bu, ilk düzey onayın başarıyla tamamlandığını gösteren önemli bir kilometre taşıdır. Onay iş akışlarınını analiz etmek ve darboğazları belirlemek için büyük önem taşır.
Nereden Alınır??
Yönetici 'Onayla' düğmesine tıkladığında, harcamanın onay geçmişine bir event olarak kaydedilir. Event log'u onaylayıcının ID'sini ve bir zaman damgası (zaman damgası) içermelidir.
Yakala
Yönetici yetkilerine sahip bir kullanıcı tarafından 'Onayla' eylemi üzerine bir olay günlüğe kaydedilir.
Event tipi
explicit
|
|||
|
Finans İncelemesi Bekleniyor
|
Onaylanmış bir gider yükseltildi ve şu anda finans veya muhasebe ekibinden inceleme beklemektedir. Bu durum genellikle yüksek değerli giderler veya politika işaretleri olanlar için geçerlidir. Aktivite bir durum değişikliğinden çıkarılır. | ||
|
Neden Önemli?dir?
Finansal inceleme döngüsünün başlangıcını işaret eder. Bu aşamanın süresini ölçmek, finans ekibinin iş yükünü ve verimliliğini değerlendirmeye yardımcı olur ve otomasyon fırsatlarını belirler.
Nereden Alınır??
Yönetici onayından sonra gider nesnesindeki bir durum değişikliğinden 'Finans Onayı Bekleniyor' olarak çıkarıldı. Bu, giderin durum geçmişine erişim gerektirir.
Yakala
Gider durumunun 'Finans İncelemesi Bekleniyor' olarak güncellendiği zamanki zaman damgası (zaman damgası)ndan türetilmiştir.
Event tipi
inferred
|
|||
|
Finans Onaylandı
|
Finans ekibi harcamayı inceledi ve nihai onayı verdi, geri ödeme ve muhasebe senkronizasyonu için uygun hale getirdi. Bu, finans ekibinin bir üyesi tarafından açık bir kullanıcı eylemi olarak kaydedilir. | ||
|
Neden Önemli?dir?
Ödeme öncesindeki son onay kapısını temsil eder. Bu aktiviteyi analiz etmek, uçtan uca onay döngüsünü ve finans ekibi verimliliğini anlamaya yardımcı olur.
Nereden Alınır??
Giderin onay geçmişinde bir olay olarak kaydedildi. Finans departmanından bir kullanıcıyla ilişkili bir onay olayı arayın.
Yakala
Finans yetkilerine sahip bir kullanıcı tarafından 'Onayla' eylemi üzerine bir olay günlüğe kaydedilir.
Event tipi
explicit
|
|||
|
Geri Ödeme Planlandı
|
Cepten ödenen giderler için onaylanan tutar ödeme işleme sırasına alınmıştır. Bu olay, giderin tüm onaylardan geçtiğini ve ödenmeye hazır olduğunu gösterir. | ||
|
Neden Önemli?dir?
Bu kilometre taşı, onay sürecini ödeme uygulama sürecinden ayırır. Ödeme işlemedeki gecikmelerle onaylardaki gecikmeleri izole etmeye yardımcı olur.
Nereden Alınır??
Büyük olasılıkla son onaydan sonra gider durumunun 'Geri Ödeme Bekleniyor' veya 'Ödeme İçin Hazır' olarak değişmesinden çıkarıldı. Ödemeler toplu yapılıyorsa açık bir olay da olabilir.
Yakala
'Ödeme için Hazır' durum değişikliğinden veya bir ödeme toplu işlem tablosunda bir kayıt oluşturulmasından türetilmiştir.
Event tipi
inferred
|
|||
|
Gider Revizyon İçin Geri Gönderildi
|
Bir onaylayıcı, yönetici veya finans inceleyicisi, gideri reddetmiş ve düzeltme için çalışana geri göndermiştir. Bu, 'Revizyon Gerekli' veya 'Reddedildi' durumuna bir durum değişikliği ile yakalanır. | ||
|
Neden Önemli?dir?
Bu aktivite, süreçte yeniden işleme döngüsünü ifade eder ve bu da döngü süresini doğrudan artırır. Bu olayları izlemek, yaygın gönderim hatalarını belirlemeye ve ilk geçiş verimini artırmaya yardımcı olur.
Nereden Alınır??
Gider nesnesindeki bir durum değişikliğinden 'Revizyon Gerekli' veya benzer bir duruma çıkarıldı. Olay, eylemi başlatan onaylayıcıya bağlanmalıdır.
Yakala
Gider durumunun 'Revizyon Gerekli' veya 'Reddedildi' olduğu zamanki zaman damgası (zaman damgası)ndan türetilmiştir.
Event tipi
inferred
|
|||
|
Makbuz Eklendi
|
Bir fişin bir harcamayla ilişkilendirildiği anı temsil eder; bu, OCR eşleştirmesi yoluyla otomatik olarak veya kullanıcı tarafından manuel olarak yapılabilir. Bu, fiş dosyasının işlem kaydına başarıyla bağlandığı zaman yakalanır. | ||
|
Neden Önemli?dir?
Bu aktiviteyi takip etmek, eksik belgelerden kaynaklanan gecikmeleri belirlemeye yardımcı olur. Uyumluluğu ve denetim hazırlığını güçlüak için önemli bir adımdır.
Nereden Alınır??
Bir fiş yüklendiğinde veya eşleştirildiğinde gider veya işlem geçmişine kaydedildi. Bir ek oluşturma olayını veya 'receipt_attached' gösteren bir bayrağı kontrol edin.
Yakala
Sistem bir fiş görüntüsünü veya dosyasını gider kaydına bağladığında olay oluşturulur.
Event tipi
explicit
|
|||
|
Politika Kontrolü Yapıldı
|
Sistem, harcamayı yapılandırılmış şirket politikalarına göre otomatik olarak denetler ve olası ihlalleri işaretler. Bu genellikle gönderimden kısa bir süre sonra meydana gelen sistem tarafından oluşturulan bir event'tir. | ||
|
Neden Önemli?dir?
Otomatik uyumluluk kontrollerinin verimliliğini ve süreç üzerindeki etkisini ölçer. Yaygın politika ihlallerini ve çalışan eğitimi gereken alanları belirlemeye yardımcı olur.
Nereden Alınır??
Büyük olasılıkla gider işlemiyle ilişkili bir denetim izinde veya günlükte kaydedildi. 'policy_check' veya 'uyumluluk_scan' ile ilgili sistem olaylarını arayın.
Yakala
Otomatik politika motoru işlem üzerinde çalıştıktan sonra bir sistem günlük girdisi oluşturulur.
Event tipi
explicit
|
|||
|
Yönetici İncelemesi Bekleniyor
|
Harcama gönderildi ve şimdi çalışanın doğrudan yöneticisinin incelemesini bekliyor. Bu durum, harcama durumu gönderimden sonra 'Yönetici Onayı Bekleniyor' veya benzer bir değere değiştiğinde anlaşılır. | ||
|
Neden Önemli?dir?
Yönetici onay aşamasının başlangıcını belirler. Bu durumda geçirilen sürenin analizi, yönetici onay döngü sürelerini ölçmek ve iyileştirmek için temel rol oynar.
Nereden Alınır??
Gider nesnesindeki bir durum değişikliğinden 'Onay Bekleniyor' gibi bir duruma ve bir yöneticinin kuyruğuna atanmasından çıkarıldı. Durum geçmişi takibi gerektirir.
Yakala
Gider durumunun 'Yönetici Onayı Bekleniyor' olduğu zamanki zaman damgası (zaman damgası)ndan türetilmiştir.
Event tipi
inferred
|
|||