구매 대금 지급 요청 데이터 템플릿
구매 대금 지급 요청 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
구매 대금 지급 요청 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
구매 요청 ID
PurchaseRequisitionId
|
구매 요청을 식별하는 고유 ID로, 기본 케이스 식별자 역할을 합니다. | ||
|
설명
구매 요청 ID는 상품이나 서비스에 대한 단일 요청과 관련된 모든 활동을 연결하는 기준 키입니다. 생성부터 최종 승인과 종료까지 각 구매 요청 프로세스를 이 고유 ID로 추적합니다. process mining에서 이 속성은 각 구매 요청의 전체 처리 과정을 재구성하는 데 필수적입니다. 개별 케이스의 프로세스 변형, 처리 시간, 규정 준수를 분석해 구매 요청의 전체 흐름을 파악할 수 있습니다.
중요한 이유
관련된 모든 이벤트를 하나의 프로세스 인스턴스로 묶어 각 구매 요청의 전체 처리 과정을 분석할 수 있습니다.
확보 방법
일반적으로 Microsoft Dynamics 365의 PurchReqTable과 같은 구매 요청 헤더 테이블에서 기본 키로 사용됩니다.
예시
구매 요청-001254구매 요청-001255구매 요청-001256
|
|||
|
이벤트 시간
EventTime
|
특정 활동이나 이벤트가 발생한 정확한 타임스탬프입니다. | ||
|
설명
이벤트 시간, 즉 타임스탬프는 업무 이벤트가 시스템에 기록된 날짜와 시간을 나타냅니다. 시간 기반 프로세스 분석의 기준이 됩니다. 이 속성은 처리 시간과 활동 간 대기 시간을 계산하는 데 중요합니다. 프로세스 성과 분석, 병목 식별, SLA 준수 모니터링에 활용됩니다. 신뢰할 수 있는 process mining 분석을 위해서는 정확한 타임스탬프가 필요합니다.
중요한 이유
이벤트의 시간순서를 제공하므로 프로세스 소요 시간 계산, 병목 식별, 시간에 따른 성과 분석에 필요합니다.
확보 방법
워크플로 이력이나 문서 로그 테이블에서 확인할 수 있습니다. 각 상태 변경 또는 이벤트 레코드에 연결된 'CreatedDateTime' 또는 'ModifiedDateTime' 필드로 기록되는 경우가 많습니다.
예시
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
|
|||
|
활동명
ActivityName
|
구매 요청 프로세스에서 발생한 구체적인 업무 이벤트나 단계의 이름입니다. | ||
|
설명
이 속성은 구매 요청의 전체 처리 과정에서 수행된 각 활동의 이름을 기록합니다. 예를 들면 '구매 요청 생성', '승인 단계 승인', '구매 주문 생성' 등이 있습니다. 이러한 활동은 발견된 프로세스 맵의 노드가 됩니다. 활동의 순서와 빈도, 활동 간 소요 시간을 분석하는 것이 process mining의 핵심입니다. 이를 통해 병목, 재작업 반복, 표준 프로세스 흐름에서 벗어난 사례를 찾아 운영 비효율을 파악할 수 있습니다.
중요한 이유
이 속성은 프로세스 맵의 단계를 정의하므로 구매 요청 워크플로를 시각화하고 분석해 이해할 수 있습니다.
확보 방법
일반적으로 Microsoft Dynamics 365의 상태 변경 로그, 워크플로 이력 테이블 또는 WorkflowTrackingStatusTable과 같은 특정 이벤트 테이블에서 가져옵니다.
예시
구매 요청 승인 제출승인 단계 승인구매 요청 수정
|
|||
|
마지막 데이터 업데이트
LastDataIngestionTimestamp
|
데이터를 마지막으로 추출해 process mining 도구에 불러온 시점의 타임스탬프입니다. | ||
|
설명
이 속성은 분석 중인 데이터의 최신성을 나타냅니다. 원천 시스템에서 가장 최근에 데이터를 새로 고친 날짜와 시간을 보여줍니다. Dynamics 365 자체의 필드가 아니라 데이터 수집 과정에서 추가하는 메타데이터입니다. 이 타임스탬프를 통해 사용자는 인사이트가 얼마나 최신인지 파악할 수 있습니다. 실시간 데이터인지 특정 시점의 스냅샷인지 확인할 수 있어 분석 결과의 적절성을 판단하는 데 도움이 됩니다.
중요한 이유
데이터의 최신성과 분석 기간을 알려주므로 인사이트가 현재 상황에 얼마나 적절한지 파악할 수 있습니다.
확보 방법
데이터 수집 또는 ETL 과정에서 생성해 데이터셋에 추가하는 값입니다.
예시
2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
|
|||
|
원천 시스템
SourceSystemId
|
데이터를 추출한 기준 시스템입니다. | ||
|
설명
이 속성은 이벤트 데이터가 발생한 원천 시스템을 식별합니다. 이 경우 값은 'Microsoft Dynamics 365'입니다. 여러 시스템이 연동된 환경에서는 데이터 계보와 맥락을 파악하는 데 중요합니다. 분석 시 여러 시스템에 걸친 프로세스를 구분하거나 데이터가 단일 기준 시스템에서 왔는지 확인할 수 있습니다. 올바른 데이터셋을 기반으로 분석하고 데이터의 유효성을 검증하는 데 도움이 됩니다.
중요한 이유
데이터의 출처를 파악할 수 있어 데이터 거버넌스와 검증에 중요하며, 여러 시스템이 연동된 환경에서도 유용합니다.
확보 방법
데이터 추출 및 변환 과정에서 추가하는 고정값 'Microsoft Dynamics 365'입니다.
예시
Microsoft Dynamics 365 F&OD365MSD365
|
|||
|
긴급도
UrgencyLevel
|
요청의 긴급도를 '높음', '보통', '낮음' 등으로 분류한 값입니다. | ||
|
설명
긴급도 또는 우선순위는 요청한 상품이나 서비스가 얼마나 빨리 필요한지를 나타냅니다. 이 속성은 승인 경로를 결정하거나 승인 담당자의 업무 우선순위를 정하는 데 사용되기도 합니다. 이 속성을 분석하면 우선순위 체계가 효과적으로 작동하는지 확인할 수 있습니다. 예를 들어 긴급도가 '높음'인 요청과 '낮음'인 요청의 처리 시간을 비교할 수 있습니다. 차이가 거의 없다면 우선순위 필드를 무시하거나 잘못 사용하고 있을 수 있습니다. 이는 '긴급도 영향 분석' 대시보드에서 확인할 수 있는 중요한 정보입니다.
중요한 이유
우선순위 설정에 따라 긴급한 요청이 실제로 더 빨리 처리되는지 평가하고, 긴급도 분류가 잘못 사용되는 경우를 파악할 수 있습니다.
확보 방법
PurchReqTable의 기본 필드이거나 사용자 지정 필드일 수 있습니다. 시스템 구성에 따라 필드의 존재 여부와 이름이 다를 수 있습니다.
예시
높음보통낮음
|
|||
|
부서
Department
|
요청자의 부서 또는 구매 요청과 연결된 비용 센터입니다. | ||
|
설명
이 속성은 구매 요청을 시작한 사업 부서나 비용 센터를 나타냅니다. 예를 들면 '마케팅', 'IT', '운영' 등이 있습니다. 일반적으로 구매 요청 헤더에 포함됩니다. 부서별로 프로세스를 나누어 비교하면 부서별 처리 시간, 반려율, 수정 빈도를 확인할 수 있습니다. 이러한 인사이트를 바탕으로 각 부서의 요구에 맞춰 프로세스를 개선할 수 있습니다.
중요한 이유
사업 부서별 프로세스 성과를 필터링하고 비교해 부서별 패턴, 병목, 비효율을 파악할 수 있습니다.
확보 방법
이 정보는 구매 요청 헤더(PurchReqTable)에 저장되는 경우가 많으며, Dynamics 365의 재무 차원 구성과 연결됩니다.
예시
IT 부서재무운영
|
|||
|
사용자
User
|
활동을 수행한 사람의 사용자 ID 또는 이름입니다. | ||
|
설명
이 속성은 구매 요청 제출이나 승인과 같은 특정 프로세스 단계를 수행한 직원 또는 시스템 사용자를 식별합니다. 사용자 ID, 전체 이름 또는 이메일 주소일 수 있습니다. 사용자별 활동을 분석하면 교육이 필요한 영역, 성과가 높은 개인이나 팀, 업무량 분포를 파악할 수 있습니다. 직무 분리와 같은 규정 준수 분석과 사용자 역할별 프로세스 상호작용을 이해하는 데도 필요합니다.
중요한 이유
사용자별 행동, 업무량, 성과를 분석할 수 있어 리소스 관리와 교육 기회 파악에 도움이 됩니다.
확보 방법
일반적으로 워크플로 이력 테이블(예: WorkflowTrackingStatusTable)이나 사용자 테이블(예: UserInfo)과 연결된 거래 테이블(예: PurchReqTable)에서 확인할 수 있습니다.
예시
김민수이수진박지훈
|
|||
|
승인 단계
ApprovalStep
|
워크플로의 특정 승인 단계 이름 또는 단계입니다. | ||
|
설명
이 속성은 승인 워크플로의 특정 단계를 식별합니다. 예를 들어 '관리자 승인' 또는 '재무 승인'이 해당합니다. 일반적인 활동명보다 세부적인 정보를 제공합니다. 이 속성은 '승인 단계 병목 분석'에 중요합니다. 각 승인 단계에 소요된 시간을 추적하면 전체 프로세스의 지연을 유발하는 단계를 정확히 찾을 수 있습니다. 이를 바탕으로 해당 단계에 맞는 개선 조치를 취해 워크플로 효율성을 높일 수 있습니다.
중요한 이유
승인 워크플로를 세부적으로 분석해 병목을 일으키는 단계를 구체적으로 찾을 수 있습니다.
확보 방법
이 정보는 WorkflowTrackingStatusTable과 같은 워크플로 이력 테이블에 저장되며, 구성된 워크플로의 각 단계를 기록합니다.
예시
관리자 승인부서장 승인재무 검토
|
|||
|
요청 상태
RequisitionStatus
|
구매 요청의 현재 상태 또는 최종 상태입니다. | ||
|
설명
이 속성은 구매 요청의 전체 상태를 시점별로 나타냅니다. 예를 들어 '검토 중', '승인됨', '거부됨', '종료됨' 등이 있습니다. 일반적으로 케이스 수준의 속성으로, 최종 결과를 나타냅니다. 최종 상태를 분석하면 프로세스의 전반적인 결과를 파악할 수 있습니다. 예를 들어 '거부됨' 또는 '철회됨' 상태인 요청이 많다면 최초 요청 단계에 문제가 있거나 승인 절차가 복잡하다는 신호일 수 있습니다. 이 속성은 성공률과 프로세스 효율성을 측정하는 데 중요합니다.
중요한 이유
각 케이스의 결과를 명확히 보여주므로 승인율, 거부율, 철회율과 같은 주요 성과 지표를 분석할 수 있습니다.
확보 방법
상태 필드는 일반적으로 구매 요청 헤더 테이블인 PurchReqTable에 있으며, 필드명은 'Status' 또는 'PurchReqStatus'인 경우가 많습니다.
예시
승인됨검토 중거부됨초안
|
|||
|
요청 총액
RequisitionTotalAmount
|
구매 요청의 총 금액입니다. | ||
|
설명
이 속성은 구매 요청의 모든 품목 금액을 합산한 총액을 나타냅니다. 금액이 클수록 승인 단계가 늘어나는 등 승인 워크플로의 복잡성에 영향을 주는 경우가 많습니다. 프로세스 분석에서는 금액을 기준으로 데이터를 필터링하고 분석할 때 이 속성이 중요합니다. '고액 요청은 승인까지 더 오래 걸리는가?', '현재 프로세스에 정체된 요청의 금액은 얼마인가?'와 같은 질문에 답할 수 있습니다. 이를 통해 프로세스 성과를 재무 관점에서 파악할 수 있습니다.
중요한 이유
분석에 재무 관점을 더해 고액 케이스의 우선순위를 정하고 금액이 프로세스 흐름에 미치는 영향을 파악할 수 있습니다.
확보 방법
이 값은 일반적으로 구매 요청 헤더 테이블에 저장되거나, 구매 요청 라인 테이블(PurchReqLine)의 품목 금액을 합산해 계산합니다.
예시
1500.0025000.50500.75
|
|||
|
구매 주문 번호
PurchaseOrderNumber
|
요청을 바탕으로 생성된 구매 주문의 식별자입니다. | ||
|
설명
이 속성에는 승인된 구매 요청에서 생성된 구매 주문의 고유 ID가 저장됩니다. 요청 프로세스와 후속 조달 프로세스를 연결하는 역할을 합니다. '요청에서 PO 생성까지 걸린 시간'을 분석하려면 이 번호를 추적해야 합니다. 요청이 구매 대금 지급(P2P) 주기의 다음 단계로 정상적으로 넘어갔는지 확인할 수 있으며, 구매 요청과 구매 주문을 아우르는 엔드투엔드 프로세스 분석에도 활용할 수 있습니다.
중요한 이유
요청과 후속 구매 주문을 연결해 요청에서 PO로 전환되는 과정을 분석하고 P2P 프로세스의 여러 단계를 연계할 수 있습니다.
확보 방법
PO 생성 후 구매 요청 라인 테이블(PurchReqLine)에서 이 정보를 찾을 수 있으며, PurchTable과 연결됩니다.
예시
PO-000987PO-000988PO-000989
|
|||
|
수정 횟수
AmendmentCount
|
요청이 수정된 총 횟수입니다. | ||
|
설명
이 계산형 숫자 속성은 각 구매 요청 케이스에서 '요청 수정' 활동이 발생한 횟수를 셉니다. 이 속성은 '요청 수정 빈도' 대시보드와 '요청 수정 비율' KPI에 중요합니다. 케이스별 재작업 규모를 수치로 보여주므로 수정과 비효율이 잦은 요청, 부서 또는 사용자를 쉽게 찾을 수 있습니다. 이를 통해 최초 요청의 품질을 높이는 개선 활동에 집중할 수 있습니다.
중요한 이유
케이스별 재작업 규모를 수치로 나타내므로 수정 빈도와 프로세스 효율성에 미치는 영향을 측정하고 분석할 수 있습니다.
확보 방법
계산형 속성입니다. 데이터 변환 과정에서 고유한 PurchaseRequisitionId별로 '요청 수정' 활동을 세어 산출합니다.
예시
013
|
|||
|
승인 담당 그룹
ApproverGroup
|
승인 단계를 담당하는 사용자 그룹 또는 역할입니다. | ||
|
설명
이 속성은 특정 승인 작업을 맡은 그룹, 역할 또는 대기열을 식별합니다. 예를 들어 '재무 승인 담당자' 또는 'IT 관리자'가 해당합니다. 승인 담당 그룹별 프로세스 성과를 분석하면 업무량 분포를 파악하고, 리소스가 부족하거나 추가 교육이 필요한 그룹을 찾을 수 있습니다. 또한 담당 팀별로 성과를 구분해 볼 수 있어 '승인 단계 병목 분석' 대시보드에 활용할 수 있습니다.
중요한 이유
승인 팀 간 성과 차이를 파악하고 특정 그룹의 리소스 부족이나 교육 필요성을 확인할 수 있습니다.
확보 방법
이 정보는 WorkflowTrackingStatusTable 등의 워크플로 이력에 포함되며, 각 작업에 배정된 사용자 또는 사용자 그룹을 기록합니다.
예시
재무 승인 담당자IT 관리자고위 경영진
|
|||
|
승인 워크플로 경로
ApprovalWorkflowPath
|
진행된 승인 단계의 순서를 나타냅니다. | ||
|
설명
이 파생 필드는 특정 요청에서 진행된 승인 단계를 순서대로 연결합니다. 예를 들어 '관리자 승인 -> 부서장 승인 -> 재무 승인'과 같이 표시합니다. 승인 하위 프로세스의 변형을 요약해 보여줍니다. 이 속성은 '규정 준수 편차 모니터' 대시보드에 중요합니다. 실제 워크플로 경로를 사전에 정의한 표준 또는 예상 경로와 비교하면 정책 위반이나 운영 리스크로 이어질 수 있는 비준수 또는 이례적인 흐름을 쉽게 찾아낼 수 있습니다.
중요한 이유
프로세스 변형을 명확한 문자열로 보여주므로 규정 준수 분석이 간편해지고 표준 절차에서 벗어난 흐름을 쉽게 찾을 수 있습니다.
확보 방법
이 속성은 기본 필드가 아닙니다. 데이터 변환 과정에서 각 케이스의 'ApprovalStep' 값을 시간순으로 연결해 생성해야 합니다.
예시
관리자 -> 이사관리자 -> 이사 -> 재무 담당 부사장관리자 -> 자동 승인
|
|||
|
최초 승인 여부
IsFirstPass
|
이전 수정이나 거부 없이 요청이 승인되었는지를 나타내는 플래그입니다. | ||
|
설명
요청이 승인되기까지 '요청 수정' 또는 '승인 단계 거부' 활동이 없으면 'true', 하나라도 있으면 'false'로 설정되는 계산형 불리언 속성입니다. 이 속성은 '요청 최초 승인율' KPI를 산출하는 데 직접 활용됩니다. 케이스별 재작업 여부를 명확히 보여주므로 프로세스 효율성을 간편하게 분석할 수 있습니다. 최초 승인율이 낮다면 최초 요청 데이터의 품질이 낮거나 요구사항이 명확하지 않을 수 있으며, 이는 프로세스 개선 기회를 나타냅니다.
중요한 이유
재작업이 필요한 케이스를 찾아 프로세스 품질과 효율성을 직접 측정하고, 최초 승인율 관련 KPI를 산출할 수 있습니다.
확보 방법
계산형 속성입니다. 데이터 변환 과정에서 각 케이스의 전체 활동 순서를 분석해 승인 전에 재작업 활동이 있었는지 확인해야 합니다.
예시
truefalse
|
|||
|
통화
Currency
|
요청 금액의 통화 코드입니다. | ||
|
설명
이 속성은 요청 총액의 통화를 지정합니다. 예를 들어 USD, EUR, GBP 등이 해당합니다. 여러 통화를 사용하는 다국적 조직의 재무 분석에 특히 중요합니다. 통화 속성을 사용하면 재무 데이터를 올바르게 처리하고 집계할 수 있습니다. 금액을 정확히 해석하고 공통 통화로 환산해 지역이나 사업부 간에 정확히 보고하고 비교할 수 있습니다.
중요한 이유
재무 속성을 해석하는 데 필요한 맥락을 제공하므로 여러 통화를 사용하는 환경에서도 금액을 정확히 해석하고 집계할 수 있습니다.
확보 방법
이 필드는 일반적으로 구매 요청 헤더 테이블인 PurchReqTable에서 금액 필드와 함께 찾을 수 있습니다.
예시
USDEURGBP
|
|||
구매 대금 지급 요청 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
구매 요청 반려
|
승인 워크플로에서 구매 요청이 반려되어 더 이상 처리되지 않습니다. 구매 요청이 최종적으로 실패한 상태입니다. | ||
|
중요한 이유
이 종료 이벤트는 전체 반려율을 분석하고 요청 실패가 재무 또는 운영에 미치는 영향을 파악하는 데 중요합니다.
확보 방법
워크플로가 'Rejected' 상태로 완료될 때 WorkflowTrackingStatusTable에 명시적으로 기록되며, PurchReqTable의 상태 필드도 업데이트됩니다.
기록
워크플로의 'Completion' 이벤트 중 상태가 'Rejected'인 항목을 필터링하거나 PurchReqTable의 상태 변경을 추적합니다.
이벤트 유형
explicit
|
|||
|
구매 요청 생성
|
이 이벤트는 구매 요청 레코드가 초안 상태로 처음 생성된 시점을 나타냅니다. 구매 요청 헤더의 생성 타임스탬프를 확인해 기록합니다. | ||
|
중요한 이유
프로세스의 시작 활동으로, 전체 구매 요청 처리 기간과 일별 요청 처리량을 분석하는 데 필요합니다.
확보 방법
각 신규 구매 요청 ID의 PurchReqTable에 있는 'createdDateTime' 필드에서 이 활동을 추론합니다.
기록
PurchReqTable 레코드의 생성 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
구매 요청 승인
|
구매 요청이 워크플로에서 필요한 모든 승인 단계를 통과했습니다. 워크플로 인스턴스가 최종 승인 상태로 완료될 때 이 활동을 기록합니다. | ||
|
중요한 이유
승인 주기가 끝나고 구매 단계가 시작되는 중요한 시점입니다. '구매 요청 승인 주기 시간' KPI의 종료 이벤트입니다.
확보 방법
워크플로가 완료될 때 WorkflowTrackingStatusTable에서 명시적으로 확인합니다. 이때 PurchReqTable의 'Status' 필드도 'Approved'로 업데이트됩니다.
기록
워크플로의 'Completion' 이벤트 중 상태가 'Approved'인 항목을 필터링하거나 PurchReqTable의 상태 변경을 추적합니다.
이벤트 유형
explicit
|
|||
|
구매 요청 승인 제출
|
사용자가 작성이 완료된 구매 요청을 제출하면 공식 승인 워크플로가 시작됩니다. 시스템의 워크플로 엔진에 명시적으로 기록되는 작업입니다. | ||
|
중요한 이유
이 활동은 승인 주기가 시작되는 중요한 시점입니다. '구매 요청 승인 주기 시간'과 '최초 승인율'을 측정하는 기준이 됩니다.
확보 방법
구매 요청에 대한 'Submission' 이벤트가 기록된 WorkflowTrackingStatusTable 또는 유사한 워크플로 이력 테이블에서 확인합니다.
기록
워크플로 이력 로그에서 해당 구매 요청과 연결된 'Submission' 또는 'Start' 이벤트 유형을 필터링합니다.
이벤트 유형
explicit
|
|||
|
구매 요청 종료
|
구매 요청의 모든 항목이 구매 주문으로 처리되거나 취소되어 전체 요청이 완료된 상태입니다. 성공적으로 마무리된 최종 상태입니다. | ||
|
중요한 이유
이 활동은 구매 요청의 전체 처리 과정이 성공적으로 완료된 시점을 나타냅니다. 처음부터 끝까지 걸린 총 시간을 측정하는 최종 지점입니다.
확보 방법
이 상태는 일반적으로 계산하거나 추론합니다. 연결된 모든 PurchReqLine 레코드가 'Closed', 'Cancelled'와 같은 최종 상태에 도달하면 발생합니다.
기록
PurchReqTable의 모든 하위 PurchReqLine 레코드가 최종 상태인지 확인해 이 이벤트를 도출합니다.
이벤트 유형
calculated
|
|||
|
구매 주문 생성
|
승인된 구매 요청 항목이 구매 주문 항목으로 전환되면서 구매팀으로 전달됩니다. 구매 요청 항목과 구매 주문 항목을 연결해 기록합니다. | ||
|
중요한 이유
구매 요청과 후속 구매 프로세스를 연결하는 중요한 시점입니다. '구매 요청에서 구매 주문까지의 전환 시간' KPI를 측정하는 데 필요합니다.
확보 방법
해당 구매 요청 케이스와 연결된 PurchReqLine의 ID를 참조하는 레코드가 PurchLine 테이블에 있는지 확인해 추론합니다.
기록
연결 참조 필드(예: PurchReqLineRefId)를 기준으로 PurchReqLine과 PurchLine을 조인합니다.
이벤트 유형
inferred
|
|||
|
승인 단계 승인
|
승인자가 할당된 작업을 완료하고 해당 프로세스 단계에서 구매 요청을 승인합니다. 이후 요청은 다음 단계로 이동하거나 최종 승인을 받습니다. | ||
|
중요한 이유
각 승인 단계의 처리 시간을 측정하고 워크플로에서 효율적으로 진행되는 부분을 찾는 데 도움이 됩니다. 프로세스 변형 분석의 주요 요소입니다.
확보 방법
사용자가 'Approve' 결과로 작업 항목을 완료하면 WorkflowTrackingStatusTable에 명시적으로 기록됩니다.
기록
워크플로 이력 로그에서 결과가 'Approve'인 'WorkItemCompleted' 이벤트를 찾습니다.
이벤트 유형
explicit
|
|||
|
구매 요청 수정
|
사용자가 변경을 위해 제출한 구매 요청을 워크플로에서 회수할 때 발생하는 이벤트입니다. 일반적으로 회수 작업이 발생한 뒤 다시 제출된 기록을 확인해 파악합니다. | ||
|
중요한 이유
수정 내역을 추적하면 재작업, 불명확한 최초 요청, 프로세스 비효율을 찾을 수 있습니다. 이는 '구매 요청 수정 빈도' 대시보드의 주요 데이터입니다.
확보 방법
워크플로 이력('WorkflowTrackingStatusTable')에서 'Recall' 또는 'RequestChange' 작업을 찾아 추론할 수 있습니다. 제출 후 PurchReqTable의 'modifiedDateTime' 필드가 변경된 기록으로도 파악할 수 있습니다.
기록
워크플로 회수 이벤트를 찾거나 제출 이벤트 사이의 레코드 버전 변경을 확인합니다.
이벤트 유형
inferred
|
|||
|
구매 요청 철회
|
작성자나 권한이 있는 사용자가 제출된 구매 요청을 취소합니다. 이 작업으로 워크플로와 요청이 종료됩니다. | ||
|
중요한 이유
철회를 추적하면 수요 계획의 문제나 지나치게 복잡한 프로세스를 찾을 수 있습니다. 이 데이터는 '구매 요청 철회 인사이트' 대시보드에 활용됩니다.
확보 방법
PurchReqTable의 상태가 'Cancelled'로 변경되거나 WorkflowTrackingStatusTable에 'Cancel' 이벤트가 기록된 경우 철회로 추론합니다.
기록
PurchReqTable의 상태가 'Cancelled'로 변경됐는지 확인하거나 워크플로 취소 이벤트를 찾습니다.
이벤트 유형
inferred
|
|||
|
구매 요청 항목 종료
|
구매 요청의 개별 항목이 모두 처리된 상태입니다. 일반적으로 해당 항목이 구매 주문으로 완전히 전환된 뒤에 발생합니다. | ||
|
중요한 이유
구매 요청 이행 현황을 세부적으로 파악해 요청이 구매 주문으로 일부 또는 전부 전환됐는지 확인할 수 있습니다.
확보 방법
개별 PurchReqLine 테이블의 상태 필드에서 추론합니다. 주문 또는 수령 상태라면 해당 항목이 종료된 것으로 볼 수 있습니다.
기록
PurchReqLine 테이블의 상태 필드에서 'Invoiced' 또는 'Closed'와 같은 최종 값을 확인합니다.
이벤트 유형
inferred
|
|||
|
승인 단계 반려
|
승인자가 할당된 작업을 반려하면 일반적으로 구매 요청이 수정을 위해 요청자에게 돌아갑니다. 워크플로 엔진에 명시적으로 기록되는 작업입니다. | ||
|
중요한 이유
이 활동은 '구매 요청 반려율'을 계산하고 반려가 자주 발생하는 단계를 찾아 프로세스 개선 영역을 파악하는 데 중요합니다.
확보 방법
사용자가 'Reject' 결과로 작업 항목을 완료하면 WorkflowTrackingStatusTable에 명시적으로 기록됩니다.
기록
워크플로 이력 로그에서 결과가 'Reject'인 'WorkItemCompleted' 이벤트를 찾습니다.
이벤트 유형
explicit
|
|||
|
승인 단계 시작
|
워크플로의 일부로 개별 승인 작업이 사용자나 그룹에 할당됩니다. 특정 승인자의 대기 또는 처리 시간이 시작되는 시점입니다. | ||
|
중요한 이유
이 활동은 '승인 단계 병목 분석'에 중요하며, 특정 승인 단계의 대기 시간을 측정할 수 있습니다.
확보 방법
구매 요청의 워크플로 인스턴스에 새 작업 항목이 생성되어 할당될 때 WorkflowTrackingStatusTable에서 확인합니다.
기록
해당 구매 요청의 워크플로 이력 로그에서 'WorkItemCreated' 또는 유사한 이벤트를 찾습니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿을 활용하면 구매 대금 지급 요청 프로세스의 최적화를 시작하는 데 필요한 내용을 확인할 수 있습니다. 지금 프로세스 데이터를 분석해 유용한 인사이트를 찾아보세요.
승인을 앞당기도록 구매부터 지급까지의 구매 요청 프로세스 개선
Dynamics 365에서 지연을 줄이고 처리 시간을 30% 단축하세요.
신용카드가 필요하지 않습니다. 몇 분이면 설정할 수 있습니다.