Satın Almadan Ödemeye - Talep Veri Şablonunuz
Satın Almadan Ödemeye - Talep Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Oracle Fusion Financials için Veri Çıkarma Rehberliği
Satın Almadan Ödemeye - Talep Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Talep sürecinde belirli bir noktada meydana gelen iş olayının adı. | ||
|
Açıklama
Aktivite, satın alma talebi yaşam döngüsündeki belirgin bir adımı veya dönüm noktasını temsil eder. Örnekler arasında 'Talep Oluşturuldu', 'Onay Adımı Onaylandı' veya 'Satın Alma Siparişi Oluşturuldu' yer alır. Bu aktiviteler, kaynak sistemin denetim loglarında veya işlem tablolarında kaydedilen durum değişikliklerinden, kullanıcı eylemlerinden veya sistem olaylarından türetilir. Bu nitelik, taleplerin akışını görsel olarak temsil eden süreç haritasını oluşturmak için hayati öneme sahiptir. Aktivitelerin sırasını ve sıklığını analiz etmek, ortak süreç yollarını, darboğazları, yeniden işleme döngülerini ve standart prosedürden sapmaları belirlemeye yardımcı olur.
Neden önemli
Talep iş akışının görselleştirilmesini ve analizini sağlayarak süreç haritasının temelini oluşturur.
Nereden alınır
POR_REQUISITION_HEADERS_ALL gibi tablolardaki durum değişikliği kayıtlarından, işlem geçmişinden veya FA_FUSION_SOAINFRA.WFTASK gibi Workflow denetim izlerinden türetilir.
Örnekler
Talep OluşturulduOnay Adımı OnaylandıTalep ReddedildiSatın Alma Siparişi Oluşturuldu
|
|||
|
Olay Zamanı
EventTime
|
Aktivitenin ne zaman gerçekleştiğini gösteren timestamp. | ||
|
Açıklama
Olay Zamanı, belirli bir aktivitenin gerçekleştiği kesin tarih ve saati kaydeder. Bu zaman damgası, bir vaka içindeki olayların kronolojik sıralaması için temeldir ve sistemdeki oluşturma tarihlerinden, son güncelleme tarihlerinden veya belirli eylem zaman damgalarından alınır. Analizde, Olay Zamanı, aktiviteler arasındaki döngü süreleri, bekleme süreleri ve genel vaka süresi gibi tüm süre tabanlı metrikleri hesaplamak için kullanılır. Darboğazları belirlemek, SLA'lara karşı performansı ölçmek ve talep sürecinin zamansal dinamiklerini anlamak için kritik öneme sahiptir.
Neden önemli
Bu nitelik, tüm zamanla ilgili KPI'ları hesaplamak, olayları doğru şekilde sıralamak ve süreç performansını ve bottleneck'leri (darboğazları) analiz etmek için hayati öneme sahiptir.
Nereden alınır
Bu genellikle işlem veya durum değişikliği ile ilişkili bir 'LAST_UPDATE_DATE' veya 'CREATION_DATE' sütunundan alınır, sıklıkla POR_REQUISITION_HEADERS_ALL veya workflow geçmişi tablolarında bulunur.
Örnekler
2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
|
|||
|
Satın Alma İsteği Kimliği
PurchaseRequisitionId
|
Süreç için vaka kimliği olarak hizmet veren bir satın alma talebinin benzersiz tanımlayıcısı. | ||
|
Açıklama
Satın Alma Talep Kimliği, belirli bir mal veya hizmet talebiyle ilgili tüm aktiviteleri birbirine bağlayan merkezi tanımlayıcıdır. Her talebe oluşturulduğunda benzersiz bir kimlik atanır ve bu kimlik yaşam döngüsü boyunca sabit kalır. Process Mining'de, bu nitelik oluşturma, gönderme, onay adımları ve nihai kapatma gibi ilgili tüm olayları tek bir vaka halinde gruplamak için kullanılır. Bu, talebin yolculuğunun uçtan uca analizine olanak tanır, böylece süreç haritalarını görselleştirmek, döngü sürelerini hesaplamak ve her bir talep için varyantları analiz etmek mümkün hale gelir.
Neden önemli
Bu, bir talebin yaşam döngüsünü baştan sona izlemek için temel niteliktir, tüm vaka düzeyinde analizleri ve KPI hesaplamalarını mümkün kılar.
Nereden alınır
Bu, genellikle Oracle Fusion Financials'taki POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID gibi talep başlık tablosundaki birincil anahtardır.
Örnekler
100234810023491002350
|
|||
|
Kaynak Sistem
SourceSystem
|
Bu verilerin çıkarıldığı bilgi sistemi. | ||
|
Açıklama
Bu nitelik, süreç verilerinin kaynağını tanımlar. Bu veri modeli için sürekli olarak 'Oracle Fusion Financials' olacaktır. Birden fazla ERP veya entegre sistemin bulunduğu ortamlarda, bu alan veri soyu, sorun giderme ve veri kalitesini sağlamak için çok önemlidir. Analiz edilen süreç olayları için doğruluk kaynağı hakkında bağlam sağlar.
Neden önemli
Veri yönetimi ve birden fazla sistemden veri entegrasyonu yaparken kritik önem taşıyan veri kaynağı hakkında temel bağlam sağlar.
Nereden alınır
Bu, veri çıkarma ve dönüştürme süreci sırasında veri kümesinin kaynağını etiketlemek için eklenen statik bir değerdir.
Örnekler
Oracle Fusion Financials
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Kaynak sistemden en son veri yenilemesinin zaman damgası. | ||
|
Açıklama
Bu nitelik, verilerin Oracle Fusion Financials'tan son olarak ne zaman çekildiğinin tarihini ve saatini gösterir. Bireysel olaylara değil, tüm veri kümesine uygulanır. Analistler bu bilgiyi, verilerin güncelliğini anlamak ve en son işlemlerin ne zaman dahil edildiğini doğrulamak için kullanır. Dashboard raporlaması ve analizlerin güncel bilgilere dayanmasını sağlamak için önemli bir metadata parçasıdır.
Neden önemli
Verilerin güncelliği hakkında kullanıcıları bilgilendirir, böylece analizlerin alakalı ve en son bilgilere dayalı olmasını sağlar.
Nereden alınır
Bu timestamp, data çıkarma işlemi sırasında, genellikle ETL aracı veya data pipeline tarafından oluşturulur ve saklanır.
Örnekler
2023-10-27T02:00:00Z
|
|||
|
`Teslim Edilmesi Gereken Tarih`
RequiredByDate
|
Talep sahibinin mal veya hizmetleri ihtiyaç duyduğu tarih. | ||
|
Açıklama
Bu tarih, talep sahibi tarafından talep edilen öğelerin alınması için son tarihi belirtmek üzere belirlenir. Tedarik süreci için dahili bir hizmet seviyesi anlaşması (SLA) hedefi olarak hizmet eder. Bu nitelik, 'Gereken Tarih Performansı' dashboard'u ve 'Gereken Tarihe Uyma Oranı' KPI'sının temelini oluşturur. Bu tarihin gerçek Satın Alma Siparişi oluşturma tarihi veya mal teslim alma tarihi ile karşılaştırılması, tedarik sürecinin iç müşteri taleplerini ne kadar iyi karşıladığını ortaya çıkarabilir ve sistemik gecikmeleri belirleyebilir.
Neden önemli
Süreç performansını dahili son teslim tarihlerine göre ölçmek ve tedarik sürecinin iş ihtiyaçlarını zamanında karşılayıp karşılamadığını anlamak için çok önemlidir.
Nereden alınır
Genellikle talep kalem satırı düzeyinde, POR_REQUISITION_LINES_ALL gibi tablolarda 'NEED_BY_DATE' gibi bir alanda saklanır.
Örnekler
2023-11-012023-12-152024-01-31
|
|||
|
Bölüm
DepartmentName
|
Talep sahibinin ait olduğu iş departmanı. | ||
|
Açıklama
Bu nitelik, talebi oluşturan kişinin organizasyonel birimini, örneğin 'Finans', 'BT' veya 'Pazarlama' gibi, gösterir. Genellikle talep sahibinin İK sistemindeki kullanıcı profilinden türetilir. Departmana göre analiz yapmak, süreç verilerini segmentlere ayırmak için yaygın ve güçlü bir yoldur. Daha yüksek ret oranları veya daha uzun döngü süreleri gibi departmana özgü davranışları belirlemeye yardımcı olur, bu da hedeflenen süreç iyileştirme girişimlerini bilgilendirebilir. Bu, 'Talep Sahibi Performans Metrikleri' dashboard'u için önemli bir boyuttur.
Neden önemli
İş birimine göre süreç analizi yapılmasına olanak tanıyarak, departmana özgü kalıpları, performansı ve uyumluluk sorunlarını ortaya çıkarır.
Nereden alınır
Genellikle talep sahibinin profilinden türetilir, sıklıkla talep tablosundan departman bilgisini içeren bir İK veya kullanıcı dizini tablosuna birleştirme gerektirir.
Örnekler
Bilgi TeknolojileriFinansOperasyonlarPazarlama
|
|||
|
İş Birimi
BusinessUnit
|
Talebin ait olduğu kuruluş içindeki belirli iş birimi. | ||
|
Açıklama
İş Birimi, talebin yapıldığı şirketin içinde ayrı bir yasal veya fonksiyonel birimi temsil eder. Bir departmandan daha üst düzey bir organizasyonel gruplandırmadır. Verileri İş Birimi'ne göre analiz etmek, organizasyonun farklı bölümleri arasında üst düzey performans karşılaştırmaları yapılmasına olanak tanır. Bu, üst yönetimin süreç verimsizliklerinin yerel mi yoksa yaygın mı olduğunu anlamasına ve iyileştirme çabalarını nereye odaklayacağını belirlemesine yardımcı olur. Neredeyse tüm dashboard'lar ve KPI'lar için önemli bir filtreleme boyutudur.
Neden önemli
İşletmenin farklı bölümleri arasında performans karşılaştırması ve stratejik analiz sağlayan üst düzey bir organizasyonel bağlam sunar.
Nereden alınır
Bu, Oracle Fusion'da temel bir organizasyonel alandır, genellikle POR_REQUISITION_HEADERS_ALL gibi tablolardaki talep başlığında bulunur.
Örnekler
BU North AmericaBU EuropeKurumsal Merkez
|
|||
|
Ret Nedeni
RejectionReason
|
Bir onaylayıcı tarafından bir talep veya onay adımı reddedildiğinde sağlanan neden. | ||
|
Açıklama
Bir satın alma talebi reddedildiğinde, onaylayan kişi genellikle önceden tanımlı bir listeden seçerek veya serbest metin girerek bir neden belirtir. Bu öznitelik, bu gerekçeyi kaydeder. Bu, süreç hatalarının kök neden analizi için kritik bir özniteliktir. Reddetmelerin 'nedenini' sağlayarak 'Değişiklik ve Reddetme Eğilimleri' Dashboard'unu doğrudan destekler. Reddetme nedenlerini analiz etmek, hatalı kodlama, bütçe aşımları veya politika ihlalleri gibi yaygın sorunları belirlemeye yardımcı olur; bu sorunlar daha sonra eğitim veya sistem kontrolleri aracılığıyla giderilebilir.
Neden önemli
Taleplerin neden reddedildiğine dair doğrudan içgörü sağlayarak, yeniden işlemeyi azaltmak ve akıcı işlem oranını artırmak için hedeflenen iyileştirmelere olanak tanır.
Nereden alınır
İş akışı yorumlarından veya iş akışı denetim izindeki belirli ret nedeni kodu alanlarından alınır, potansiyel olarak FA_FUSION_SOAINFRA.WFTASK veya ilgili yorum depolama tablolarında bulunabilir.
Örnekler
Yanlış Genel Muhasebe HesabıMaliyet merkezi bütçesini aşıyorTercih edilmeyen tedarikçi seçildiTekrar Eden Talep
|
|||
|
Talep Durumu
RequisitionStatus
|
Satın alma talebinin mevcut veya nihai durumu. | ||
|
Açıklama
Bu nitelik, talebin belirli bir zamandaki genel durumunu veya nihai sonucunu, örneğin 'Onaylandı', 'Reddedildi', 'İşlemde' veya 'Kapalı' gibi, gösterir. Bu genellikle event log'daki birçok aktivitenin türetildiği kaynaktır. Bu nitelik, 'Talep Durumu Genel Bakış' dashboard'u için anahtardır, mevcut iş yükü ve birikim hakkında anlık bir görüntü sağlar. Ayrıca, belirli bir durumla biten vakaları filtreleyerek Talep Ret Oranı gibi sonuç tabanlı KPI'ları hesaplamak için de kullanılır.
Neden önemli
Taleplerin mevcut durumunun anlık görüntüsünü sağlar ve KPI hesaplamaları için nihai sonuçları belirlemek için kullanılır.
Nereden alınır
Genellikle POR_REQUISITION_HEADERS_ALL tablosundaki 'DOCUMENT_STATUS' veya 'APPROVAL_STATUS' gibi bir alanda, talep başlık tablosunda bulunur.
Örnekler
ONAYLANDIİŞLEMDEREDDEDİLDİGERİ ÇEKİLDİ
|
|||
|
Talep Edenin Adı
RequesterName
|
Satın alma talebini oluşturan ve gönderen çalışanın adı. | ||
|
Açıklama
Bu nitelik, mal veya hizmet talebini başlatan kişiyi tanımlar. Bu bilgi genellikle talebin ilk oluşturulduğu sürecin başında yakalanır. Talep Sahibine göre süreç performansını analiz etmek, 'Talep Sahibi Performans Metrikleri' dashboard'u için kritik öneme sahiptir. Yüksek düzeltme, ret oranları veya talepleriyle ilişkili uzun döngü sürelerini vurgulayarak hangi kullanıcıların veya grupların ek eğitime ihtiyaç duyabileceğini belirlemeye yardımcı olur. Sürecin insan merkezli bir görünümünü sunar.
Neden önemli
Talep edenlere göre performans analizine olanak tanır, eğitim ihtiyaçlarını belirlemeye ve verimli kullanıcıları veya departmanları vurgulamaya yardımcı olur.
Nereden alınır
Talep başlığı verilerinden alınır, genellikle talep sahibinin kimliği bir çalışan veya kullanıcı ana veri tablosuyla birleştirilerek elde edilir. POR_REQUISITION_HEADERS_ALL'daki 'PREPARER_ID' ile ilgili alanları arayın ve PER_ALL_PEOPLE_F'ye birleştirin.
Örnekler
Can DemirAyşe YılmazEmily Jones
|
|||
|
Toplam Talep Tutarı
RequisitionTotalAmount
|
Satın alma talebinin toplam parasal değeri. | ||
|
Açıklama
Bu nitelik, tek bir satın alma talebindeki tüm kalemlerin değerinin toplamını temsil eder. Her talebin finansal önemini anlamak için kritik bir veri noktasıdır. Process Mining'de, toplam tutar geniş bir analiz yelpazesi için kullanılır. Farklı onay yolları veya daha yüksek inceleme gerektiren yüksek değerli talepleri filtrelemek için kullanılabilir. Dashboard'lar bu niteliği, döngü süresi veya ret oranı gibi süreç metriklerinin talebin değeriyle nasıl korelasyon gösterdiğini analiz etmek için kullanabilir.
Neden önemli
Süreç iyileştirmelerini önceliklendirmek ve talep değerinin süreç davranışını nasıl etkilediğini anlamak için değer tabanlı analizi mümkün kılan finansal bağlam sağlar.
Nereden alınır
Talep başlığında, genellikle POR_REQUISITION_HEADERS_ALL tablosundaki REQUISITION_TOTAL gibi bir alanda bulunur. Ayrıca POR_REQUISITION_LINES_ALL tablosundaki kalem tutarları toplanarak da hesaplanabilir.
Örnekler
550.0012500.7599.99
|
|||
|
Değiştirildi
IsAmendedFlag
|
Talebin en az bir kez değiştirilmiş olması durumunda doğru (true) olan bir boolean işareti. | ||
|
Açıklama
Bu hesaplanmış nitelik, bir talebin ilk gönderiminden sonra herhangi bir değişikliğe uğrayıp uğramadığını gösterir. Vakanın geçmişinde 'Talep Düzeltildi' aktivitesinin varlığı kontrol edilerek türetilir. Bu işaret, analiz ve KPI hesaplamasını basitleştirir. Doğrudan 'Talep Düzeltme Oranı' KPI'sını hesaplamak ve akıcı olmayan vakaları belirlemek için kullanılır. Düzeltilmiş ve düzeltilmemiş talepler arasındaki süreç metriklerinin kolayca filtrelenmesini ve karşılaştırılmasını sağlar.
Neden önemli
Düzeltme oranının hesaplanmasını basitleştirir ve düzeltilmiş taleplerle düzeltilmemiş taleplerin kolayca karşılaştırılmasını sağlar.
Nereden alınır
Bu nitelik kaynak sistemde değildir ancak event log'da düzeltme ile ilgili aktivitelerin varlığına dayanarak veri dönüşümü sırasında hesaplanır.
Örnekler
truefalse
|
|||
|
Doğrudan Geçiş mi
IsStraightThrough
|
Talebin herhangi bir değişiklik veya reddedilme olmadan onaylanıp onaylanmadığını gösteren bir işaret. | ||
|
Açıklama
Bu hesaplanmış işaret, bir talebin gönderimden onaya kadar, düzeltmeler veya retler gibi herhangi bir yeniden işleme döngüsü olmadan süreçten geçtiğini belirtir. Tek bir vaka için kusursuz bir şekilde yürütülen bir süreci ifade eder. Bu nitelik, 'Akıcı Talep Oranı' KPI'sının temelini oluşturur. Akıcı taleplerin özelliklerini (örneğin, ortak departmanlar, talep sahipleri veya türler) analiz etmek, en iyi uygulamaları ve otomasyon fırsatlarını ortaya çıkarabilir. Tersine, akıcı olmayanları analiz etmek, verimsizliğin birincil nedenlerini belirlemeye yardımcı olur.
Neden önemli
Süreç verimliliğini doğrudan ölçer ve Doğrudan Talep Oranı KPI'sının temelini oluşturarak yeniden işleme nedenlerini belirlemeye yardımcı olur.
Nereden alınır
Bu nitelik, veri dönüşümü sırasında hesaplanır. Bir vaka, 'Talep Düzeltildi' veya 'Onay Adımı Reddedildi' aktiviteleri yoksa doğru olarak işaretlenir.
Örnekler
truefalse
|
|||
|
Kullanıcı Adı
UserName
|
Onaylayan veya düzenleyici gibi belirli bir aktiviteyi gerçekleştiren kullanıcının adı. | ||
|
Açıklama
Talep Eden Adı, başlatıcıyı tanımlarken, Kullanıcı Adı süreçteki belirli bir olayı (örneğin bir onay veya red gibi) gerçekleştiren kişiyi belirtir. Bu, farklı kişilerin dahil olduğu çok adımlı onay Workflow'ları için özellikle önemlidir. Bu öznitelik, onay darboğazlarını analiz etmek ve belirli onaylayıcıların veya ekiplerin performansını ölçmek için hayati öneme sahiptir. Onay zincirindeki her kullanıcının işlem sürelerinin analizine olanak tanıyarak 'Onay Workflow Darboğazları' Dashboard'unu doğrudan destekler.
Neden önemli
Her olay için aktörü belirler, bu da devir sürelerini, onaylayıcı performansını ve kaynak tahsisini analiz etmek için hayati öneme sahiptir.
Nereden alınır
Her görev tamamlama ile ilişkili kullanıcıyı kaydeden FA_FUSION_SOAINFRA.WFTASK gibi iş akışı geçmişi veya denetim izi tablolarından alınır.
Örnekler
David LeeSusan ChenMichael Brown
|
|||
|
Onay Workflow Yolu
ApprovalWorkflowPath
|
Talep için gereken onaylayıcıların veya onay gruplarının önceden tanımlanmış sırası. | ||
|
Açıklama
Bu nitelik, şirket politikalarını dikkate alarak (talep tutarı, türü ve departman gibi faktörler göz önüne alınarak) belirli bir talep için beklenen, standart onay sürecini tanımlar. 'Olması gereken' süreç modelini temsil eder. Onay Workflow Yolu, uyumluluk ve uygunluk analizi için temeldir. Gerçekte atılan onay adımlarının belirlenmiş yolla doğrudan karşılaştırılmasına izin vererek 'Uyumluluk ve Sapma Analizi' dashboard'unu ve 'Talep Uygunluk Endeksi' KPI'sını doğrudan destekler. Sapmalar, politika ihlallerini veya süreç verimsizliklerini gösterebilir.
Neden önemli
Gerçek süreç akışını gerekli onay hiyerarşisiyle karşılaştırarak uyumluluk kontrolüne olanak tanır ve uyumsuz talepleri vurgular.
Nereden alınır
Bu bilgi Oracle Fusion BPM İş Listesi veya Onay Yönetim Motoru (AMX) içinde yapılandırılır. Her talep için tanımlanmış yolu çıkarmak karmaşık olabilir ve yapılandırma tablolarının sorgulanmasını gerektirebilir.
Örnekler
Yönetici > Direktör > Finans Başkan YardımcısıMaliyet Merkezi Sahibi > BT GüvenliğiYönetici > Departman Müdürü
|
|||
|
Otomatikleştirildi mi?
IsAutomated
|
Bir faaliyetin sistem tarafından otomatik olarak gerçekleştirilip gerçekleştirilmediğini gösteren bir bayraktır. | ||
|
Açıklama
Bu nitelik, süreçte bir sistem kullanıcısı veya otomatik bir aracı tarafından, insan tarafından değil, gerçekleştirilen olayları tanımlar. Örnekler arasında sistem tarafından yönlendirilen durum değişiklikleri veya düşük değerli kalemler için otomatik onay adımları yer alabilir. Bu niteliği analiz etmek, süreçteki otomasyon seviyesini nicelleştirmeye yardımcı olur. Otomatik adımların manuel olanlara kıyasla hızı ve verimliliğini karşılaştırmak ve daha fazla otomasyon fırsatlarını belirlemek için kullanılabilir.
Neden önemli
Süreçteki otomasyon seviyesini ölçmeye ve manuel görevleri otomatikleştirme fırsatlarını belirlemeye yardımcı olur.
Nereden alınır
Bir etkinlikle ilişkili kullanıcının bir sistem veya hizmet hesabı olup olmadığının kontrol edilmesiyle türetilir. Bu, bilinen sistem kullanıcı kimliklerinin bir listesini gerektirir.
Örnekler
truefalse
|
|||
|
Para Birimi
CurrencyCode
|
USD veya EUR gibi talep tutarının para birimi kodu. | ||
|
Açıklama
Bu nitelik, Toplam Talep Tutarının hangi para biriminde olduğunu belirtir. Küresel kuruluşlar için talepler çeşitli para birimlerinde oluşturulabilir. Finansal verileri doğru bir şekilde yorumlamak ve birleştirmek için çok önemlidir. Parasal değerleri içeren herhangi bir analizde, tutarların doğru bir şekilde karşılaştırıldığından emin olmak için para birimi kodu kullanılmalıdır; bu ya tek bir para birimi için filtreleme yaparak ya da tüm tutarları ortak bir para birimine dönüştürerek sağlanır.
Neden önemli
Özellikle çoklu para birimleriyle uğraşan çok uluslu kuruluşlarda doğru finansal analiz ve raporlama sağlar.
Nereden alınır
Genellikle tutar alanlarının yanında talep başlık tablosunda bulunur, örneğin POR_REQUISITION_HEADERS_ALL'da.
Örnekler
USDEURGBPJPY
|
|||
|
Purchase Order Number
PurchaseOrderNumber
|
Onaylanmış talepten oluşturulan satın alma siparişinin tanımlayıcısı. | ||
|
Açıklama
Bu nitelik, bir satın alma talebini ortaya çıkan satın alma siparişine bağlar. Bir talep tamamen onaylandıktan sonra, genellikle bir tedarikçiye gönderilmek üzere bir veya daha fazla satın alma siparişine dönüştürülür. Analizde, bu kimlik, talepten sonraki süreci izlemek için hayati öneme sahiptir. 'Talep-Satın Alma Siparişi Teslim Süresi' KPI'sının hesaplanmasını sağlar ve 'Talep-Satın Alma Siparişi Döngü Süresi' dashboard'unu destekler. Ayrıca, gerçek bir uçtan uca Satın Almadan Ödemeye analizi için talep süreç verilerini sonraki Satın Alma Siparişi ve faturalandırma süreçleriyle birleştirmeye olanak tanır.
Neden önemli
Talebi sonraki satın alma siparişine bağlar, talep-sipariş döngü süresinin ölçülmesini ve uçtan uca süreç analizini sağlar.
Nereden alınır
Bu bilgi bir Satın Alma Siparişi oluşturulduktan sonra saklanır. Genellikle, talebin satırına geri bağlanan PO_DISTRIBUTIONS_ALL gibi Satın Alma Siparişi dağıtım tablolarındaki destekleyici talep referanslarına bakılarak bulunur.
Örnekler
PO-2023-5832PO-2023-5833PO-2023-5834
|
|||
|
Talep Türü
RequisitionType
|
Mal veya hizmet talebi gibi talebin kategorisi. | ||
|
Açıklama
Bu nitelik, talebin ne istendiğine göre sınıflandırılmasını sağlar. Yaygın türler arasında mal, hizmet veya sermaye harcamaları bulunur. Bu tür, gerekli onay workflow'unu ve tedarik stratejisini etkileyebilir. Analizde, Talep Türü filtreleme ve karşılaştırma için güçlü bir boyut olarak hizmet eder. Örneğin, hizmet taleplerinin mal taleplerinden daha uzun bir onay döngü süresine sahip olup olmadığını analiz edilebilir. Farklı talep türlerinin farklı süreç davranışları veya bottleneck'ler (darboğazlar) gösterip göstermediğini anlamaya yardımcı olur.
Neden önemli
Analizi, mal ve hizmet gibi çeşitli satın alma türleri için sürecin nasıl farklılaştığını anlamak üzere bölümlere ayırmaya olanak tanır.
Nereden alınır
Bu genellikle talep oluşturma sırasında seçilen kalem türü veya kategorisi tarafından belirlenir. POR_REQUISITION_LINES_ALL talep satırı tablosunda saklanabilir.
Örnekler
MallarHizmetlerSermaye Harcaması
|
|||
|
Tedarikçi Adı
SupplierName
|
Mal veya hizmetler için önerilen veya önceden seçilmiş tedarikçinin adı. | ||
|
Açıklama
Bu nitelik, mal veya hizmetlerin satın alınması amaçlanan tedarikçiyi tanımlar. Tedarikçi, talep sahibi tarafından önerilebilir veya kataloglara veya önceki anlaşmalara göre sistem tarafından belirlenebilir. Tedarikçiye göre analiz yapmak önemli tedarik kalıplarını ortaya çıkarabilir. Örneğin, belirli tedarikçiler için taleplerin onaylanmasının daha uzun sürüp sürmediğini veya daha yüksek ret oranlarına sahip olup olmadığını belirlemeye yardımcı olur. Bu bilgi, tedarikçi ilişki yönetimi ve tedarik stratejisi için değerli olabilir.
Neden önemli
Süreç performansının tedarikçiye göre analiz edilmesini sağlayarak, kaynak bulma stratejisi ve tedarikçi ilişkileri yönetiminde yardımcı olabilir.
Nereden alınır
Talep kalem tablosu olan POR_REQUISITION_LINES_ALL'da bulunur ve genellikle bir VENDOR_ID aracılığıyla POZ_SUPPLIERS gibi bir tedarikçi ana tablosuna bağlanır.
Örnekler
Office Supplies Inc.Global Tech SolutionsYaratıcı ```Pazarlama Ajansı```
|
|||
|
Ürün Açıklaması
ItemDescription
|
Bir talep satırında talep edilen ürün veya hizmetin açıklaması. | ||
|
Açıklama
Bu nitelik, tedarik edilen kalemin metinsel açıklamasını içerir. Talep edilen mal veya hizmetler hakkında belirli ayrıntılar sağlar. Genellikle yapılandırılmamış olsa da, Kalem Açıklaması analiz için değerli bir bağlam sunar. Talep Türü tarafından yakalanmayabilecek belirli satın alma türleri için talepleri izole etmek üzere filtrelerde kullanılabilir. Örneğin, bir analist, 'Yazılım Lisansı' içeren tüm talepleri arayarak bunların özel süreç akışlarını ve döngü sürelerini anlayabilir.
Neden önemli
Ne satın alındığına dair ayrıntılı bağlam sunarak, belirli mal veya hizmetlerin daha ayrıntılı filtrelenmesine ve analizine olanak tanır.
Nereden alınır
Talep kalem tablosu olan POR_REQUISITION_LINES_ALL'da, ITEM_DESCRIPTION gibi bir alanda bulunur.
Örnekler
15 inç Dizüstü Bilgisayar, 16GB RAMDanışmanlık Hizmetleri - 4. Çeyrek ProjesiYıllık Yazılım Bakım Yenileme
|
|||
Satın Almadan Ödemeye - Talep Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Satın Alma Siparişi Oluşturuldu
|
Bu olay, onaylanmış bir talep satırı bir satın alma siparişi oluşturmak için kullanıldığında meydana gelir. Talep sürecini sonraki tedarik sürecine bağlar. | ||
|
Neden önemli
Bu, Talep-Satın Alma Siparişi Teslim Süresi'ni ölçmek için kritik bir dönüm noktasıdır. Buradaki gecikmeler, onaydan satın almaya geçişteki bottleneck'leri (darboğazları) gösterir.
Nereden alınır
Bu açık bir olaydır. Talep ile satın alma siparişi arasındaki bağlantı, kaynak talep satır kimliğine bir referans içeren PO_LINE_LOCATIONS_ALL gibi tablolarda saklanır.
Yakala
Verilen Talep ID'sini referans alan Satın Alma Siparişi'nin oluşturulma tarihini bulun.
Event tipi
explicit
|
|||
|
Talep Gönderildi
|
Tamamlanmış talebin onay iş akışına gönderilmesi kullanıcı eylemini temsil eder. Bu, talep durumunun 'Tamamlanmamış' veya 'Taslak'tan, onayı beklediğini gösteren bir duruma değiştiğinde yakalanır. | ||
|
Neden önemli
Bu aktivite, onay döngüsünü başlatır. Talep Onay Döngü Süresi ve genel teslim sürelerini ölçmek için kritik bir dönüm noktasıdır.
Nereden alınır
POR_REQUISITION_HEADERS_ALL tablosundaki bir durum değişikliğinden (örn. durum 'ONAY BEKLİYOR'a geçer) çıkarılır. Gönderme tarihi de genellikle açıkça saklanır.
Yakala
Belge durumu alanının ilk olarak 'Onay Bekliyor' olarak değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Kapatıldı
|
Bir talebin yaşam döngüsünün nihai kapanışını gösterir; yani tüm satırlarının yerine getirildiği (örn. Satın Alma Siparişlerine dönüştürüldüğü) veya iptal edildiği anlamına gelir. Bu, son bir durum güncellemesinden çıkarılır. | ||
|
Neden önemli
Bu, süreç için birincil başarılı bitiş olayıdır. Talebin tamamen işlendiğini ve başka bir eyleme gerek olmadığını doğrular.
Nereden alınır
POR_REQUISITION_HEADERS_ALL tablosundaki talep başlığı durumunun 'KAPALI' olarak değişmesinden çıkarılır.
Yakala
Talebin belge durumunun 'Kapalı' olarak değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Oluşturuldu
|
Bir kullanıcı yeni bir satın alma talebini ilk kez kaydettiğinde tedarik sürecinin başlatıldığını gösterir. Bu olay genellikle sistemde ilgili bir zaman damgası ile açık bir kayıt oluşturma olarak yakalanır. | ||
|
Neden önemli
Bu, talep süreci için birincil başlangıç olayıdır. Oluşturmadan gönderime kadar geçen süreyi analiz etmek, talep resmileştirmesindeki gecikmeleri ortaya çıkarabilir.
Nereden alınır
Bu olay POR_REQUISITION_HEADERS_ALL tablosunda kaydedilir ve yeni bir Talep Kimliği oluşturulduğunda creation_date sütunundan yakalanır.
Yakala
Talep başlık kaydı için oluşturma timestamp'ını kullanın.
Event tipi
explicit
|
|||
|
Talep Onaylandı
|
İş akışındaki tüm adımları başarıyla geçtikten sonra satın alma talebinin nihai onayını işaretler. Bu, talebin genel durumunun 'Onaylandı' olarak değişmesinden anlaşılır. | ||
|
Neden önemli
Bu, talebin tedarik eylemi için hazır olduğunu gösteren önemli bir dönüm noktasıdır. Toplam talep onay döngü süresini ölçmek için son noktadır.
Nereden alınır
POR_REQUISITION_HEADERS_ALL tablosundaki belge durumu alanının 'ONAYLANDI' olarak değişmesinden çıkarılır. Bu durum değişikliğinin tarihi olay zamanıdır.
Yakala
Belge durumunun ilk olarak 'Onaylandı' olarak ayarlandığı zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Reddedildi
|
Talebin nihai olarak reddedilmesini temsil eder ve bu talep için süreci sonlandırır. Bu, talebin genel durumunun 'Reddedildi' olarak güncellenmesinden anlaşılır. | ||
|
Neden önemli
Bu aktivite, başarısız talepler için son bir noktadır. Bu vakaları analiz etmek, Talep Ret Oranı KPI'sını ve başarısızlık nedenlerini anlamak için gereklidir.
Nereden alınır
POR_REQUISITION_HEADERS_ALL tablosundaki belge durumunun 'REDDEDİLDİ' olarak değişmesinden çıkarılır.
Yakala
Belge durumunun ilk olarak 'Reddedildi' olarak ayarlandığı zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Onay Adımı Başlatıldı
|
Bir talebin iş akışı içinde belirli bir onaylayıcıya veya onay grubuna atandığı anı işaretler. Bu, iş akışı motorunun işlem logundan yakalanır. | ||
|
Neden önemli
Bu aktivite, her onay adımı için bekleme süresini hesaplamak için çok önemlidir. Belirli onaylayıcıların veya onay seviyelerinin neden olduğu bottleneck'leri (darboğazları) belirlemeye yardımcı olur.
Nereden alınır
Oracle Fusion'ın kullanıcılara atanan görevleri kaydeden iş akışı tablolarından alınır. Onay görevi için atama zaman damgası kullanılır.
Yakala
Belirli talep için workflow geçmişindeki görevin oluşturma timestamp'ını kullanın.
Event tipi
explicit
|
|||
|
Onay Adımı İade Edildi
|
Bir onaylayıcı, talebi resmi olarak reddetmeden, ek bilgi veya küçük düzeltmeler için hazırlayıcıya iade eder. Bu genellikle Workflow sisteminde açık bir eylemdir. | ||
|
Neden önemli
Bu, açıklama ihtiyacını gösterir ve döngü süresini uzatan bir yeniden işleme döngüsü oluşturur. İadeleri retlerden ayırmak, süreç sürtünmesi hakkında daha derinleşimli içgörü sağlar.
Nereden alınır
Talebin onay eylemi geçmişinden alınır. Workflow sistemi, bir zaman damgası ile 'İADE ET' veya benzeri bir eylemi kaydeder.
Yakala
Workflow geçmişinden 'İADE' veya 'Bilgi Talebi' eyleminin timestamp'ını kullanın.
Event tipi
explicit
|
|||
|
Onay Adımı Onaylandı
|
İş akışındaki belirlenen adımda tek bir onaylayıcının talebi onaylama eylemini temsil eder. Olay, onay geçmişine açıkça kaydedilir. | ||
|
Neden önemli
Bireysel onay adımlarını takip etmek, gerçek onay yolunu haritalandırmaya ve hiyerarşinin her aşamasındaki işlem süresini ölçmeye yardımcı olur.
Nereden alınır
Talebin onay eylemi geçmişinden alınır, bu genellikle Workflow (WF) veya İnsan Sermayesi Yönetimi (HCM) tablolarında saklanır.
Yakala
Workflow eylem geçmişi logundan 'ONAYLA' eyleminin timestamp'ını kullanın.
Event tipi
explicit
|
|||
|
Onay Adımı Reddedildi
|
Bireysel bir onaylayıcı talebi reddeder, bu da genellikle düzeltme için hazırlayıcıya geri gönderilmesine veya talebin sonlandırılmasına neden olur. Bu eylem, Workflow geçmişinde açıkça kaydedilir. | ||
|
Neden önemli
Bu aktivite, yeniden işleme ve gecikmelerin temel nedenidir. Retleri analiz etmek, uyumluluk sorunlarını, bütçe problemlerini veya net olmayan gerekçeleri belirlemeye yardımcı olur.
Nereden alınır
Talebin onay eylemi geçmişinden alınır. Workflow sistemi, bir zaman damgası ile 'REDDET' eylemini kaydeder.
Yakala
Workflow eylem geçmişi logundan 'REDDET' eyleminin timestamp'ını kullanın.
Event tipi
explicit
|
|||
|
Talep Düzeltildi
|
Bu olay, bir kullanıcının ilk gönderiminden sonra bir talebi değiştirdiğini gösterir, bu da genellikle onay sürecinin yeniden başlamasını gerektirir. Bu, ana veri alanlarındaki değişikliklerin veya talebin yeni bir versiyonunun oluşturulmasının tespit edilmesiyle anlaşılır. | ||
|
Neden önemli
Sık yapılan değişiklikler, veri kalitesi sorunlarını veya değişen gereksinimleri gösterir, bu da yeniden işleme ve süreç gecikmelerine yol açar. Bu durum, 'Talep Değişiklik Oranı' KPI'sını doğrudan destekler.
Nereden alınır
Talebin sürüm numaralarını takip ederek veya gönderildikten sonra durum değişikliklerinin 'Eksik'e geri döndüğünü belirleyerek çıkarılır. Değişiklik günlükleri veya denetim izleme tabloları da bu değişiklikleri yakalayabilir.
Yakala
Aynı Talep ID'si için gönderildikten sonra yeni sürüm oluşturma zaman damgalarını belirleyin.
Event tipi
inferred
|
|||
|
Talep Geri Çekildi
|
Talep sahibinin gönderdiği bir talebi, tam olarak onaylanmadan önce iptal etmesi veya geri çekmesi durumunda meydana gelir. Bu genellikle durum değişikliğiyle sonuçlanan açık bir kullanıcı eylemidir. | ||
|
Neden önemli
Geri çekmeleri takip etmek, değişen iş ihtiyaçları veya kullanıcıların gönderim sonrası hataları düzeltmesi gibi erken sonlandırma nedenlerini belirlemeye yardımcı olur.
Nereden alınır
POR_REQUISITION_HEADERS_ALL tablosundaki 'GERİ ÇEKİLDİ' durum değişikliğinden çıkarılır. Eylem, talebin eylem geçmişinde kaydedilir.
Yakala
Talebin durumunun 'Geri Çekildi' olarak güncellendiği zaman damgasını tespit edin.
Event tipi
inferred
|
|||