구매 요청 데이터 템플릿

Oracle Fusion Financials
구매 요청 데이터 템플릿

구매 요청 데이터 템플릿

이 템플릿은 구매 요청 프로세스 분석에 필요한 데이터를 수집하는 방법을 안내합니다. 수집할 주요 속성과 추적할 활동을 확인하고, Oracle Fusion Financials에서 데이터를 추출하는 방법도 살펴볼 수 있습니다. 이를 바탕으로 분석에 활용할 이벤트 로그를 준비할 수 있습니다.
  • 수집 권장 속성
  • 추적할 주요 활동
  • Oracle Fusion Financials 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

구매 요청 속성

구매 요청을 분석할 수 있도록 이벤트 로그에 포함할 데이터 필드입니다.
5 필수 7 권장 10 선택 사항
이름 설명
구매 요청 ID
PurchaseRequisitionId
구매 요청을 식별하는 고유 ID로, 프로세스의 케이스 ID로 사용됩니다.
설명

구매 요청 ID는 특정 상품이나 서비스 요청과 관련된 모든 활동을 연결하는 기준 식별자입니다. 요청을 생성할 때마다 고유한 ID가 부여되며, 요청의 전체 수명 주기 동안 유지됩니다.

process mining에서는 이 속성을 사용해 요청 생성, 제출, 승인 단계, 최종 종료 등 관련 이벤트를 하나의 케이스로 묶습니다. 이를 통해 요청의 전체 흐름을 분석하고 프로세스 맵을 시각화하며, 처리 시간과 개별 요청별 변형을 분석할 수 있습니다.

중요한 이유

요청의 시작부터 종료까지 수명 주기를 추적하는 기본 속성으로, 케이스 단위 분석과 KPI 계산에 사용됩니다.

확보 방법

일반적으로 요청 헤더 테이블의 기본 키입니다. 예를 들어 Oracle Fusion Financials의 POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID가 이에 해당합니다.

예시
100234810023491002350
이벤트 시간
EventTime
활동이 발생한 시점을 나타내는 타임스탬프입니다.
설명

이벤트 시간은 특정 활동이 발생한 날짜와 시각을 정확히 기록합니다. 케이스 내 이벤트를 시간순으로 정렬하는 데 필요한 속성으로, 시스템의 생성일, 최종 업데이트일 또는 특정 작업의 타임스탬프에서 가져옵니다.

분석에서는 이벤트 시간을 사용해 활동 간 처리 시간, 대기 시간, 전체 케이스 소요 시간 등 시간 기반 지표를 계산합니다. 병목을 찾고 SLA 대비 성과를 측정하며 요청 프로세스의 시간 흐름을 파악하는 데도 중요합니다.

중요한 이유

시간 관련 KPI 계산, 이벤트의 정확한 순서 지정, 프로세스 성과와 병목 분석에 필요한 속성입니다.

확보 방법

일반적으로 트랜잭션이나 상태 변경과 관련된 'LAST_UPDATE_DATE' 또는 'CREATION_DATE' 열에서 가져옵니다. POR_REQUISITION_HEADERS_ALL과 같은 테이블이나 워크플로 이력 테이블에서 찾을 수 있습니다.

예시
2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
활동
ActivityName
요청 프로세스의 특정 시점에 발생한 비즈니스 이벤트의 이름입니다.
설명

활동은 구매 요청 수명 주기의 개별 단계나 주요 시점을 나타냅니다. 예를 들면 '요청 생성', '승인 단계 승인', '구매 주문 생성' 등이 있습니다. 이러한 활동은 소스 시스템의 감사 로그나 트랜잭션 테이블에 기록된 상태 변경, 사용자 작업 또는 시스템 이벤트에서 도출됩니다.

이 속성은 요청 흐름을 시각적으로 보여 주는 프로세스 맵을 구성하는 데 필요합니다. 활동의 순서와 빈도를 분석하면 자주 발생하는 프로세스 경로, 병목, 재작업 반복, 표준 절차에서 벗어난 흐름을 파악할 수 있습니다.

중요한 이유

프로세스 맵의 기본 구조를 이루며, 요청 워크플로를 시각화하고 분석할 수 있게 합니다.

확보 방법

POR_REQUISITION_HEADERS_ALL과 같은 테이블의 상태 변경 기록, 트랜잭션 이력 또는 FA_FUSION_SOAINFRA.WFTASK와 같은 워크플로 감사 기록에서 도출됩니다.

예시
구매 요청 생성승인 단계 승인구매 요청 최종 반려구매 주문서 생성
소스 시스템
SourceSystem
데이터를 추출한 정보 시스템입니다.
설명

이 속성은 프로세스 데이터의 출처를 나타냅니다. 이 데이터 모델에서는 값이 항상 'Oracle Fusion Financials'로 설정됩니다.

ERP나 통합 시스템을 여러 개 사용하는 환경에서는 데이터 계보 추적, 문제 해결, 데이터 품질 확인에 이 필드가 중요합니다. 분석 대상 프로세스 이벤트의 기준 데이터가 어디에서 왔는지 파악할 수 있습니다.

중요한 이유

데이터 출처에 대한 정보를 제공하므로 데이터 거버넌스와 여러 시스템의 데이터 통합에 중요합니다.

확보 방법

데이터 추출 및 변환 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다.

예시
Oracle Fusion Financials
최종 데이터 업데이트
LastDataUpdate
소스 시스템에서 데이터를 가장 최근에 새로 고친 시점의 타임스탬프입니다.
설명

이 속성은 Oracle Fusion Financials에서 데이터를 마지막으로 추출한 날짜와 시각을 나타냅니다. 개별 이벤트가 아니라 데이터 세트 전체에 적용됩니다.

분석가는 이 정보를 통해 데이터의 최신성을 확인하고 최신 트랜잭션이 언제 반영되었는지 파악할 수 있습니다. 대시보드 보고와 최신 데이터를 바탕으로 분석이 이루어지는지 확인하는 데 필요한 메타데이터입니다.

중요한 이유

데이터가 얼마나 최신인지 알려 주므로, 분석이 적절한 시점의 최신 정보를 바탕으로 이루어지도록 합니다.

확보 방법

데이터 추출 과정에서 생성되어 저장되는 타임스탬프입니다. 일반적으로 ETL 도구나 데이터 파이프라인이 기록합니다.

예시
2023-10-27T02:00:00Z
반려 사유
RejectionReason
요청이나 승인 단계가 반려될 때 승인자가 입력한 사유입니다.
설명

요청이 반려되면 승인자는 보통 미리 정해진 목록에서 사유를 선택하거나 직접 입력합니다. 이 속성은 해당 사유를 기록합니다.

프로세스 실패의 근본 원인을 분석하는 데 필요한 속성입니다. '수정 및 반려 추이' 대시보드에서 반려 이유를 파악할 수 있습니다. 반려 사유를 분석하면 계정 코드 오류, 예산 초과, 정책 위반과 같은 반복 문제를 찾아 교육이나 시스템 제어로 개선할 수 있습니다.

중요한 이유

요청이 반려된 이유를 직접 파악해 재작업을 줄이고 무중단 처리율을 높이는 개선 방안을 마련할 수 있습니다.

확보 방법

워크플로 의견이나 감사 추적의 반려 사유 코드 필드에서 가져옵니다. FA_FUSION_SOAINFRA.WFTASK 관련 테이블이나 의견 저장소에 있을 수 있습니다.

예시
잘못된 GL 계정비용 센터 예산 초과선호 공급업체가 아닌 업체 선택중복 요청
부서
DepartmentName
요청자가 소속된 사업 부서입니다.
설명

이 속성은 요청을 생성한 사람의 조직 단위를 나타냅니다. 예를 들면 '재무', 'IT', '마케팅' 등이 있습니다. 일반적으로 HR 시스템의 요청자 프로필에서 가져옵니다.

부서별 분석은 프로세스 데이터를 구분하는 일반적인 방법입니다. 부서별 반려율이나 처리 시간 차이를 파악해 해당 부서에 맞는 프로세스 개선을 추진할 수 있습니다. '요청자 성과 지표' 대시보드의 주요 분석 기준입니다.

중요한 이유

사업 부서별로 프로세스를 분석해 부서별 패턴과 성과, 규정 준수 문제를 파악할 수 있습니다.

확보 방법

일반적으로 요청자 프로필에서 가져옵니다. 부서 정보가 있는 HR 또는 사용자 디렉터리 테이블과 요청 테이블을 조인해야 할 수 있습니다.

예시
정보 기술재무운영마케팅
사업부
BusinessUnit
요청이 속한 조직 내 사업부입니다.
설명

사업부는 요청이 이루어진 회사 내 별도의 법인 또는 기능 조직을 나타냅니다. 부서보다 상위 조직 단위입니다.

사업부별 데이터를 분석하면 조직 내 여러 부문의 성과를 상위 수준에서 비교할 수 있습니다. 이를 통해 경영진은 프로세스 비효율이 특정 부문에 국한되는지 조직 전반에 걸쳐 있는지 파악하고 개선이 필요한 곳을 정할 수 있습니다. 대부분의 대시보드와 KPI에서 주요 필터 기준으로 사용됩니다.

중요한 이유

조직의 상위 구조를 기준으로 정보를 제공해 기업 내 여러 부문의 성과 비교와 전략 분석을 지원합니다.

확보 방법

Oracle Fusion의 기본 조직 필드로, 일반적으로 POR_REQUISITION_HEADERS_ALL과 같은 테이블의 요청 헤더에서 확인할 수 있습니다.

예시
북미 사업부유럽 사업부본사
요청 상태
RequisitionStatus
구매 요청의 현재 상태 또는 최종 상태입니다.
설명

이 속성은 특정 시점의 요청 상태나 최종 결과를 나타냅니다. 예를 들면 '승인', '반려', '진행 중', '종료' 등이 있습니다. 이벤트 로그의 여러 활동을 도출하는 기준이 되기도 합니다.

'요청 상태 개요' 대시보드에서 현재 업무량과 적체 현황을 확인하는 데 사용됩니다. 특정 상태로 종료된 케이스를 필터링해 요청 반려율과 같은 결과 기반 KPI를 계산할 수도 있습니다.

중요한 이유

요청의 현재 상태를 파악하고 KPI 계산에 필요한 최종 결과를 확인할 수 있습니다.

확보 방법

요청 헤더 테이블의 POR_REQUISITION_HEADERS_ALL에서 'DOCUMENT_STATUS' 또는 'APPROVAL_STATUS'와 같은 필드로 확인할 수 있습니다.

예시
승인진행 중반려철회
요청 총액
RequisitionTotalAmount
구매 요청의 총 금액입니다.
설명

이 속성은 하나의 구매 요청에 포함된 모든 품목 금액의 합계를 나타냅니다. 각 요청의 재무적 규모를 파악하는 데 필요한 데이터입니다.

process mining에서는 다양한 분석에 총액을 활용할 수 있습니다. 금액이 큰 요청을 필터링하면 승인 경로가 다르거나 더 엄격한 검토를 받는 요청을 살펴볼 수 있습니다. 대시보드에서 총액과 처리 시간, 반려율 등 프로세스 지표의 관계를 분석할 수도 있습니다.

중요한 이유

재무 정보를 제공해 금액별 분석을 가능하게 합니다. 이를 통해 프로세스 개선의 우선순위를 정하고 요청 금액이 프로세스에 미치는 영향을 파악할 수 있습니다.

확보 방법

요청 헤더에 있으며, POR_REQUISITION_HEADERS_ALL의 REQUISITION_TOTAL과 같은 필드에서 찾을 수 있습니다. POR_REQUISITION_LINES_ALL의 품목 금액을 합산해 계산할 수도 있습니다.

예시
550.0012500.7599.99
요청자 이름
RequesterName
구매 요청을 생성하고 제출한 직원의 이름입니다.
설명

이 속성은 상품이나 서비스 요청을 시작한 사람을 식별합니다. 일반적으로 요청을 처음 생성할 때 기록됩니다.

요청자별 프로세스 성과 분석은 '요청자 성과 지표' 대시보드에 중요합니다. 요청자의 수정, 반려 비율이나 긴 처리 시간을 확인해 추가 교육이 필요한 사용자나 그룹을 파악할 수 있습니다. 이를 통해 프로세스를 사람 중심으로 살펴볼 수 있습니다.

중요한 이유

요청자별 성과를 분석해 교육이 필요한 대상을 찾고, 효율적인 사용자나 부서를 파악할 수 있습니다.

확보 방법

요청 헤더 데이터에서 가져오며, 보통 요청자 ID를 직원 또는 사용자 마스터 데이터 테이블과 조인합니다. POR_REQUISITION_HEADERS_ALL의 'PREPARER_ID' 관련 필드를 확인하고 PER_ALL_PEOPLE_F와 조인할 수 있습니다.

예시
John SmithJane DoeEmily Jones
필요 일자
RequiredByDate
요청자가 상품이나 서비스를 필요로 하는 날짜입니다.
설명

요청자가 요청한 품목을 받아야 하는 기한으로 지정한 날짜입니다. 조달 프로세스의 내부 서비스 수준 협약(SLA) 목표로 사용됩니다.

이 속성은 '필요 일자 성과' 대시보드와 '필요 일자 준수율' KPI의 기준입니다. 이 날짜를 실제 구매 주문 생성일이나 상품 수령일과 비교하면 조달 프로세스가 내부 고객의 요구를 얼마나 충족하는지 확인하고 반복되는 지연을 찾을 수 있습니다.

중요한 이유

내부 기한 대비 프로세스 성과를 측정하고 조달 프로세스가 적시에 비즈니스 요구를 충족하는지 파악하는 데 중요합니다.

확보 방법

일반적으로 POR_REQUISITION_LINES_ALL과 같은 테이블의 요청 품목 수준에 저장되며, 'NEED_BY_DATE'와 같은 필드에서 확인할 수 있습니다.

예시
2023-11-012023-12-152024-01-31
공급업체 이름
SupplierName
상품이나 서비스의 제안된 공급업체 또는 사전 선택된 공급업체의 이름입니다.
설명

이 속성은 상품이나 서비스를 구매할 예정인 공급업체를 식별합니다. 요청자가 공급업체를 제안하거나 카탈로그 또는 기존 계약을 바탕으로 시스템이 지정할 수 있습니다.

공급업체별 분석을 통해 조달 패턴을 파악할 수 있습니다. 특정 공급업체 관련 요청의 승인에 시간이 더 걸리거나 반려율이 높은지 확인할 수 있습니다. 이 정보는 공급업체 관계 관리와 조달 전략 수립에 활용할 수 있습니다.

중요한 이유

공급업체별 프로세스 성과를 분석해 공급업체 선정 전략과 관계 관리를 지원합니다.

확보 방법

요청 품목 테이블 POR_REQUISITION_LINES_ALL에서 확인할 수 있습니다. 보통 VENDOR_ID를 통해 POZ_SUPPLIERS와 같은 공급업체 마스터 테이블에 연결됩니다.

예시
Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
구매 주문 번호
PurchaseOrderNumber
승인된 요청을 바탕으로 생성된 구매 주문의 식별자입니다.
설명

이 속성은 구매 요청과 그 결과로 생성된 구매 주문을 연결합니다. 요청이 최종 승인되면 일반적으로 공급업체에 보낼 하나 이상의 구매 주문으로 전환됩니다.

분석에서는 이 ID를 사용해 요청 이후의 프로세스를 추적합니다. '요청부터 PO까지 소요 시간' KPI를 계산하고 '요청부터 PO까지의 처리 시간' 대시보드를 구성할 수 있습니다. 요청 데이터를 후속 PO 및 송장 처리 데이터와 결합해 구매부터 지급까지의 전체 프로세스를 분석할 수도 있습니다.

중요한 이유

요청과 후속 구매 주문을 연결해 요청부터 PO까지의 처리 시간을 측정하고 전체 프로세스를 분석할 수 있습니다.

확보 방법

PO가 생성된 후 이 정보가 저장됩니다. 일반적으로 PO 배분 테이블의 요청 참조 정보를 확인합니다. 예를 들어 PO_DISTRIBUTIONS_ALL은 요청 품목과 연결됩니다.

예시
PO-2023-5832PO-2023-5833PO-2023-5834
무중단 처리 여부
IsStraightThrough
요청이 수정이나 반려 없이 승인되었는지 나타내는 플래그입니다.
설명

이 계산 플래그는 제출부터 승인까지 수정이나 반려와 같은 재작업 없이 처리된 요청을 식별합니다. 단일 케이스가 처음부터 끝까지 문제없이 처리되었음을 나타냅니다.

이 속성은 '요청 무중단 처리율' KPI의 기준입니다. 무중단 처리된 요청의 부서, 요청자, 유형 등을 분석하면 모범 사례와 자동화 기회를 찾을 수 있습니다. 반대로 무중단 처리되지 않은 요청을 분석하면 비효율의 주요 원인을 파악할 수 있습니다.

중요한 이유

프로세스 효율을 직접 측정하며, 요청 무중단 처리율 KPI의 기준으로 재작업 원인을 찾는 데 도움이 됩니다.

확보 방법

데이터 변환 과정에서 계산합니다. '요청 수정' 또는 '승인 단계 반려' 활동이 없는 케이스를 참으로 표시합니다.

예시
truefalse
사용자 이름
UserName
승인자나 편집자 등 특정 활동을 수행한 사용자의 이름입니다.
설명

요청자 이름이 요청을 시작한 사람을 나타낸다면, 사용자 이름은 승인이나 반려처럼 프로세스의 특정 이벤트를 수행한 사람을 나타냅니다. 여러 사람이 참여하는 다단계 승인 워크플로에서 특히 중요합니다.

이 속성은 승인 병목을 분석하고 특정 승인자나 팀의 성과를 측정하는 데 필요합니다. 승인 과정에 참여한 각 사용자의 처리 시간을 분석할 수 있어 '승인 워크플로 병목' 대시보드에도 활용됩니다.

중요한 이유

각 이벤트를 수행한 사람을 식별하므로 인계 시간, 승인자 성과, 리소스 배분을 분석하는 데 중요합니다.

확보 방법

FA_FUSION_SOAINFRA.WFTASK와 같은 워크플로 이력 또는 감사 추적 테이블에서 가져옵니다. 이 테이블에는 각 작업을 완료한 사용자가 기록됩니다.

예시
David LeeSusan ChenMichael Brown
수정 여부
IsAmendedFlag
요청이 한 번 이상 수정된 경우 참으로 설정되는 불리언 플래그입니다.
설명

이 계산 속성은 요청을 처음 제출한 후 변경이 있었는지 나타냅니다. 케이스 이력에 '요청 수정' 활동이 있는지 확인해 계산합니다.

이 플래그를 사용하면 분석과 KPI 계산이 간편해집니다. '요청 수정률' KPI를 계산하고 무중단 처리되지 않은 케이스를 식별하는 데 직접 사용됩니다. 수정된 요청과 수정되지 않은 요청을 쉽게 필터링하고 프로세스 지표를 비교할 수 있습니다.

중요한 이유

수정률을 간편하게 계산하고 수정된 요청과 수정되지 않은 요청의 지표를 쉽게 비교할 수 있습니다.

확보 방법

소스 시스템에는 없는 속성입니다. 이벤트 로그에 수정 관련 활동이 있는지 확인해 데이터 변환 과정에서 계산합니다.

예시
truefalse
승인 워크플로 경로
ApprovalWorkflowPath
요청에 필요한 승인자 또는 승인 그룹의 사전 정의된 순서입니다.
설명

이 속성은 회사 정책에 따라 요청 금액, 유형, 부서 등을 고려해 정해지는 표준 승인 절차를 나타냅니다. 즉, 목표 프로세스 모델을 의미합니다.

승인 워크플로 경로는 규정 준수와 적합성 분석의 기준입니다. 실제 승인 단계와 정해진 경로를 직접 비교해 '규정 준수 및 편차 분석' 대시보드와 '요청 적합성 지수' KPI를 지원합니다. 경로에서 벗어난 경우 정책 위반이나 프로세스 비효율을 나타낼 수 있습니다.

중요한 이유

실제 프로세스 흐름을 필수 승인 단계와 비교해 적합성을 확인하고, 규정을 준수하지 않은 요청을 찾을 수 있습니다.

확보 방법

이 정보는 Oracle Fusion BPM Worklist 또는 Approval Management Engine (AMX)에 설정됩니다. 요청별로 정의된 경로를 추출하는 작업은 복잡할 수 있으며 설정 테이블을 조회해야 할 수 있습니다.

예시
관리자 > 이사 > 재무 부사장비용 센터 책임자 > IT 보안관리자 > 부서장
요청 유형
RequisitionType
상품 요청이나 서비스 요청 등 요청의 분류입니다.
설명

이 속성은 요청 대상에 따라 요청을 분류합니다. 일반적인 유형으로는 상품, 서비스, 자본 지출이 있습니다. 요청 유형에 따라 필요한 승인 워크플로와 조달 전략이 달라질 수 있습니다.

분석에서는 요청 유형을 기준으로 데이터를 필터링하고 비교할 수 있습니다. 예를 들어 서비스 요청의 승인 처리 시간이 상품 요청보다 긴지 분석할 수 있습니다. 요청 유형별로 프로세스 흐름이나 병목이 어떻게 다른지 파악하는 데 도움이 됩니다.

중요한 이유

상품과 서비스 등 구매 유형에 따라 프로세스가 어떻게 다른지 분석할 수 있습니다.

확보 방법

요청 생성 시 선택한 품목 유형이나 범주에 따라 결정되는 경우가 많습니다. POR_REQUISITION_LINES_ALL의 요청 품목 테이블에 저장될 수 있습니다.

예시
상품서비스자본 지출
자동 처리 여부
IsAutomated
활동이 시스템에 의해 자동으로 수행되었는지 나타내는 플래그입니다.
설명

이 속성은 사람이 아니라 시스템 사용자나 자동화 에이전트가 실행한 프로세스 이벤트를 식별합니다. 예를 들어 시스템이 상태를 변경하거나 금액이 적은 품목을 자동 승인하는 경우가 이에 해당합니다.

이 속성을 분석하면 프로세스의 자동화 수준을 측정할 수 있습니다. 자동 처리 단계와 수동 처리 단계의 속도와 효율을 비교하고 추가 자동화 기회를 찾는 데 활용할 수 있습니다.

중요한 이유

프로세스의 자동화 수준을 측정하고 수동 작업의 자동화 기회를 찾는 데 도움이 됩니다.

확보 방법

활동과 연결된 사용자가 시스템 계정 또는 서비스 계정인지 확인해 도출합니다. 이를 위해 알려진 시스템 사용자 ID 목록이 필요합니다.

예시
truefalse
통화
CurrencyCode
요청 금액의 통화 코드입니다. 예를 들어 USD 또는 EUR입니다.
설명

이 속성은 요청 총액이 어떤 통화로 표시되는지 나타냅니다. 글로벌 조직에서는 요청이 여러 통화로 생성될 수 있습니다.

재무 데이터를 정확히 해석하고 집계하려면 이 속성이 필요합니다. 금액을 분석할 때는 단일 통화만 필터링하거나 모든 금액을 공통 통화로 환산해 정확히 비교해야 합니다.

중요한 이유

여러 통화를 사용하는 다국적 조직에서 정확한 재무 분석과 보고를 지원합니다.

확보 방법

일반적으로 금액 필드와 함께 요청 헤더 테이블에 저장됩니다. 예를 들어 POR_REQUISITION_HEADERS_ALL에서 찾을 수 있습니다.

예시
USDEURGBPJPY
품목 설명
ItemDescription
요청 품목에 기재된 상품 또는 서비스 설명입니다.
설명

이 속성에는 구매 대상 품목에 대한 설명이 텍스트로 기록됩니다. 요청한 상품이나 서비스의 구체적인 내용을 확인할 수 있습니다.

비정형 데이터인 경우가 많지만 품목 설명은 분석에 유용한 정보를 제공합니다. 요청 유형만으로 구분하기 어려운 특정 구매를 필터링하는 데 사용할 수 있습니다. 예를 들어 '소프트웨어 라이선스'가 포함된 요청을 검색해 해당 요청의 프로세스 흐름과 처리 시간을 분석할 수 있습니다.

중요한 이유

구매 대상을 구체적으로 파악할 수 있어 특정 상품이나 서비스별로 세분화된 필터링과 분석이 가능합니다.

확보 방법

요청 품목 테이블 POR_REQUISITION_LINES_ALL의 ITEM_DESCRIPTION과 같은 필드에서 확인할 수 있습니다.

예시
15인치 노트북, RAM 16GB4분기 프로젝트 컨설팅 서비스연간 소프트웨어 유지보수 갱신
필수 권장 선택 사항

구매 요청 활동

구매 요청 프로세스를 정확히 파악하려면 이벤트 로그에 다음 주요 단계와 이정표를 기록해야 합니다.
6 권장 6 선택 사항
활동 설명
구매 요청 생성
사용자가 새 구매 요청을 처음 저장하면 조달 프로세스가 시작됩니다. 일반적으로 시스템에서 생성 시각과 함께 기록된 데이터로 이 이벤트를 확인할 수 있습니다.
중요한 이유

구매 요청 프로세스의 주요 시작 이벤트입니다. 생성부터 제출까지 걸리는 시간을 분석하면 요청을 정식으로 제출하기까지 지연되는 지점을 찾을 수 있습니다.

확보 방법

POR_REQUISITION_HEADERS_ALL 테이블에서 새 Requisition ID가 생성될 때 creation_date 열에 기록된 이벤트입니다.

기록

구매 요청 헤더 레코드의 생성 시각을 사용합니다.

이벤트 유형 explicit
구매 요청 승인
구매 요청이 워크플로의 모든 단계를 통과해 최종 승인된 상태입니다. 구매 요청의 전체 상태가 'Approved'로 바뀌었는지 확인합니다.
중요한 이유

요청이 조달 단계로 넘어갈 준비가 되었음을 나타내는 주요 기준점입니다. 전체 구매 요청 승인 주기를 측정하는 종료 지점입니다.

확보 방법

POR_REQUISITION_HEADERS_ALL 테이블의 문서 상태가 'APPROVED'로 바뀐 기록으로 확인합니다. 상태가 변경된 날짜를 이벤트 시각으로 사용합니다.

기록

문서 상태가 처음으로 'Approved'로 설정된 시각을 확인합니다.

이벤트 유형 inferred
구매 요청 제출
사용자가 작성한 구매 요청을 승인 워크플로에 제출하는 작업입니다. 요청 상태가 'Incomplete' 또는 'Draft'에서 승인 대기 상태로 바뀔 때 확인할 수 있습니다.
중요한 이유

이 활동을 시작으로 승인 주기가 진행됩니다. 구매 요청 승인 주기와 전체 조달 기간을 측정하는 주요 기준점입니다.

확보 방법

POR_REQUISITION_HEADERS_ALL 테이블의 상태 변경으로 확인합니다. 예를 들어 상태가 'PENDING APPROVAL'로 바뀌는 경우입니다. 제출일이 별도로 저장되는 경우도 많습니다.

기록

문서 상태 필드가 처음으로 'Pending Approval'로 바뀐 시각을 확인합니다.

이벤트 유형 inferred
구매 요청 종료
구매 요청의 모든 라인이 처리되거나(예: PO로 전환) 취소되어 전체 처리 과정이 종료된 상태입니다. 최종 상태 변경 기록으로 확인합니다.
중요한 이유

프로세스가 성공적으로 완료되었음을 나타내는 주요 종료 이벤트입니다. 구매 요청 처리가 끝나 추가 작업이 필요하지 않음을 확인합니다.

확보 방법

POR_REQUISITION_HEADERS_ALL의 구매 요청 헤더 상태가 'CLOSED'로 바뀐 기록으로 확인합니다.

기록

구매 요청의 문서 상태가 'Closed'로 변경된 시각을 확인합니다.

이벤트 유형 inferred
구매 요청 최종 반려
구매 요청이 최종 반려되어 해당 요청의 프로세스가 종료된 상태입니다. 전체 상태가 'Rejected'로 변경되었는지 확인합니다.
중요한 이유

요청이 성공적으로 처리되지 않고 종료되는 지점입니다. 구매 요청 반려율 KPI와 실패 원인을 파악하려면 이 사례를 분석해야 합니다.

확보 방법

POR_REQUISITION_HEADERS_ALL 테이블의 문서 상태가 'REJECTED'로 바뀐 기록으로 확인합니다.

기록

문서 상태가 처음으로 'Rejected'로 설정된 시각을 확인합니다.

이벤트 유형 inferred
구매 주문서 생성
승인된 구매 요청 라인을 사용해 구매 주문서를 생성할 때 발생합니다. 구매 요청 프로세스와 후속 조달 프로세스를 연결하는 이벤트입니다.
중요한 이유

구매 요청부터 PO까지 걸리는 시간을 측정하는 주요 기준점입니다. 이 구간의 지연은 승인에서 구매로 넘어가는 과정에 병목이 있음을 나타냅니다.

확보 방법

시스템에 명시적으로 기록되는 이벤트입니다. 구매 요청과 구매 주문서 간 연결 정보는 PO_LINE_LOCATIONS_ALL 등의 테이블에 저장되며, 이 테이블에는 원본 구매 요청 라인 ID가 포함됩니다.

기록

해당 Requisition ID를 참조하는 Purchase Order의 생성일을 확인합니다.

이벤트 유형 explicit
구매 요청 수정
구매 요청을 처음 제출한 뒤 사용자가 내용을 변경한 이벤트입니다. 이 경우 승인 절차를 다시 시작해야 할 수 있습니다. 주요 데이터 필드의 변경이나 새 버전 생성 여부로 확인합니다.
중요한 이유

수정이 잦으면 데이터 품질에 문제가 있거나 요구사항이 바뀌고 있다는 뜻일 수 있으며, 재작업과 처리 지연으로 이어집니다. 이 이벤트는 '구매 요청 수정률' KPI를 계산하는 데 직접 활용됩니다.

확보 방법

구매 요청의 버전 번호를 추적하거나 제출 후 상태가 'Incomplete'로 되돌아갔는지 확인해 추정합니다. 변경 로그나 감사 추적 테이블에 수정 내역이 기록될 수도 있습니다.

기록

제출된 Requisition ID에 대해 새 버전이 생성된 시각을 확인합니다.

이벤트 유형 inferred
구매 요청 철회
요청자가 제출한 구매 요청이 최종 승인되기 전에 취소하거나 철회하는 경우입니다. 일반적으로 사용자의 명시적인 작업으로 상태가 변경됩니다.
중요한 이유

철회 사례를 추적하면 업무상 필요가 바뀌었거나 제출 후 오류를 수정하는 등 요청이 조기에 종료된 이유를 파악할 수 있습니다.

확보 방법

POR_REQUISITION_HEADERS_ALL 테이블의 상태가 'WITHDRAWN'으로 바뀐 기록으로 확인합니다. 해당 작업은 구매 요청의 작업 이력에도 기록됩니다.

기록

구매 요청 상태가 'Withdrawn'으로 변경된 시각을 확인합니다.

이벤트 유형 inferred
승인 단계 반려
승인자가 구매 요청을 반려하면 일반적으로 작성자에게 돌려보내 수정하게 하거나 요청을 종료합니다. 이 작업은 워크플로 이력에 명시적으로 기록됩니다.
중요한 이유

이 활동은 재작업과 지연을 일으키는 주요 원인입니다. 반려를 분석하면 규정 준수 문제, 예산 문제, 불분명한 요청 사유를 파악할 수 있습니다.

확보 방법

구매 요청의 승인 작업 이력에서 확인합니다. 워크플로 시스템은 시각과 함께 'REJECT' 작업을 기록합니다.

기록

워크플로 작업 이력 로그에서 'REJECT' 작업의 시각을 사용합니다.

이벤트 유형 explicit
승인 단계 반환
승인자가 공식적으로 반려하지 않고 추가 정보나 간단한 수정을 요청하며 구매 요청을 작성자에게 돌려보내는 경우입니다. 일반적으로 워크플로 시스템에서 명시적인 작업으로 기록됩니다.
중요한 이유

추가 설명이 필요하다는 뜻이며 재작업이 발생해 처리 시간이 늘어납니다. 반환과 반려를 구분하면 프로세스에서 마찰이 발생하는 지점을 더 정확히 파악할 수 있습니다.

확보 방법

구매 요청의 승인 작업 이력에서 확인합니다. 워크플로 시스템은 시각과 함께 'RETURN' 또는 유사한 작업을 기록합니다.

기록

워크플로 이력에서 'RETURN' 또는 'Request for Information' 작업의 시각을 사용합니다.

이벤트 유형 explicit
승인 단계 승인
승인자가 워크플로에서 담당하는 단계의 구매 요청을 승인한 작업입니다. 승인 이력에 명시적으로 기록됩니다.
중요한 이유

개별 승인 단계를 추적하면 실제 승인 경로를 매핑하고 계층별 처리 시간을 측정할 수 있습니다.

확보 방법

구매 요청의 승인 작업 이력에서 확인합니다. 일반적으로 승인 계층을 관리하는 워크플로(WF) 또는 Human Capital Management(HCM) 테이블에 저장됩니다.

기록

워크플로 작업 이력 로그에서 'APPROVE' 작업의 시각을 사용합니다.

이벤트 유형 explicit
승인 단계 시작
워크플로에서 구매 요청이 특정 승인자나 승인 그룹에 배정된 시점을 나타냅니다. 워크플로 엔진의 트랜잭션 로그에서 확인합니다.
중요한 이유

각 승인 단계의 대기 시간을 계산하는 데 필요한 활동입니다. 특정 승인자나 승인 단계에서 발생하는 병목을 찾는 데 도움이 됩니다.

확보 방법

사용자에게 할당된 작업을 기록하는 Oracle Fusion 워크플로 테이블에서 가져옵니다. 승인 작업의 할당 시각을 사용합니다.

기록

해당 구매 요청의 워크플로 이력에서 작업이 생성된 시각을 사용합니다.

이벤트 유형 explicit
권장 선택 사항

데이터 추출 가이드

Oracle Fusion Financials에서 데이터 가져오기

시작할 준비가 되셨나요?

이 템플릿을 활용해 구매 요청 프로세스 최적화를 시작하고 효율을 높여 보세요. 조달 운영을 개선하는 데 필요한 첫 단계를 안내합니다.

구매 요청 처리 시간 30% 단축

Oracle P2P 구매 요청 프로세스를 간소화하고 처리 주기를 30% 단축하세요.

무료 체험 시작

신용카드 없이 몇 분 만에 설정할 수 있습니다.