Mẫu dữ liệu cho quy trình yêu cầu mua hàng từ mua đến thanh toán

Oracle Fusion Financials
Mẫu dữ liệu cho quy trình yêu cầu mua hàng từ mua đến thanh toán

Mẫu dữ liệu cho quy trình yêu cầu mua hàng từ mua đến thanh toán

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích quy trình yêu cầu mua hàng từ mua đến thanh toán. Mẫu nêu rõ các thuộc tính cần thu thập, hoạt động quan trọng cần theo dõi và cách trích xuất dữ liệu từ Oracle Fusion Financials. Nhờ đó, bạn có thể chuẩn bị nhật ký sự kiện để phân tích process mining.
  • Các thuộc tính nên thu thập
  • Các hoạt động chính cần theo dõi
  • Hướng dẫn trích xuất dữ liệu từ Oracle Fusion Financials
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính của yêu cầu mua hàng từ mua đến thanh toán

Đây là các trường dữ liệu nên có trong nhật ký sự kiện để phân tích đầy đủ quy trình yêu cầu mua hàng từ mua đến thanh toán.
5 Bắt buộc 7 Nên có 10 Không bắt buộc
Tên Mô tả
Hoạt động
ActivityName
Tên sự kiện nghiệp vụ xảy ra tại một thời điểm cụ thể trong quy trình yêu cầu mua hàng.
Mô tả

Hoạt động là một bước hoặc cột mốc riêng biệt trong vòng đời yêu cầu mua hàng. Ví dụ: 'Đã tạo yêu cầu', 'Đã phê duyệt bước phê duyệt' hoặc 'Đã tạo đơn đặt hàng'. Các hoạt động này được xác định từ những thay đổi trạng thái, thao tác của người dùng hoặc sự kiện hệ thống được ghi lại trong nhật ký kiểm tra hoặc bảng giao dịch của hệ thống nguồn.

Thuộc tính này rất cần thiết để tạo sơ đồ quy trình, thể hiện trực quan luồng xử lý yêu cầu. Phân tích trình tự và tần suất hoạt động giúp xác định các luồng phổ biến, điểm nghẽn, vòng lặp làm lại và những trường hợp lệch khỏi quy trình chuẩn.

Vì sao điều này quan trọng

Thuộc tính này tạo nền tảng cho sơ đồ quy trình, giúp trực quan hóa và phân tích quy trình làm việc của yêu cầu mua hàng.

Lấy dữ liệu ở đâu

Có thể lấy từ bản ghi thay đổi trạng thái trong các bảng như POR_REQUISITION_HEADERS_ALL, lịch sử giao dịch hoặc nhật ký kiểm tra workflow như FA_FUSION_SOAINFRA.WFTASK.

Ví dụ
Tạo yêu cầu mua hàngPhê duyệt bướcTừ chối yêu cầu mua hàngTạo đơn đặt hàng
Mã Purchase Requisition
PurchaseRequisitionId
Mã định danh duy nhất của yêu cầu mua hàng, được dùng làm mã trường hợp trong quy trình.
Mô tả

ID yêu cầu mua hàng là mã định danh chính, liên kết mọi hoạt động với một yêu cầu hàng hóa hoặc dịch vụ cụ thể. Mỗi yêu cầu được cấp một ID duy nhất khi tạo và giữ nguyên ID đó trong suốt vòng đời.

Trong process mining, thuộc tính này dùng để nhóm các sự kiện liên quan, như tạo yêu cầu, gửi yêu cầu, các bước phê duyệt và đóng yêu cầu, thành một case duy nhất. Nhờ đó, bạn có thể phân tích toàn bộ hành trình của yêu cầu, trực quan hóa sơ đồ quy trình, tính thời gian chu kỳ và phân tích các biến thể của từng yêu cầu.

Vì sao điều này quan trọng

Đây là thuộc tính cốt lõi để theo dõi vòng đời yêu cầu từ đầu đến cuối, đồng thời hỗ trợ mọi phân tích ở cấp case và tính KPI.

Lấy dữ liệu ở đâu

Thông thường, đây là khóa chính trong bảng tiêu đề yêu cầu, chẳng hạn POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID trong Oracle Fusion Financials.

Ví dụ
100234810023491002350
Thời điểm sự kiện
EventTime
Dấu thời gian cho biết hoạt động diễn ra khi nào.
Mô tả

Thời điểm sự kiện ghi lại chính xác ngày giờ một hoạt động diễn ra. Dấu thời gian này rất quan trọng để sắp xếp sự kiện theo trình tự thời gian trong từng case. Dữ liệu thường được lấy từ ngày tạo, ngày cập nhật gần nhất hoặc dấu thời gian của từng thao tác trong hệ thống.

Khi phân tích, thời điểm sự kiện được dùng để tính mọi chỉ số về thời lượng, chẳng hạn thời gian chu kỳ giữa các hoạt động, thời gian chờ và tổng thời gian xử lý case. Thuộc tính này giúp xác định điểm nghẽn, đo lường hiệu suất so với SLA và hiểu rõ diễn biến theo thời gian của quy trình yêu cầu mua hàng.

Vì sao điều này quan trọng

Thuộc tính này cần thiết để tính mọi KPI liên quan đến thời gian, sắp xếp sự kiện chính xác và phân tích hiệu suất cũng như điểm nghẽn của quy trình.

Lấy dữ liệu ở đâu

Thông thường, dữ liệu được lấy từ cột 'LAST_UPDATE_DATE' hoặc 'CREATION_DATE' gắn với giao dịch hay thay đổi trạng thái, thường có trong các bảng như POR_REQUISITION_HEADERS_ALL hoặc bảng lịch sử workflow.

Ví dụ
2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
Hệ thống nguồn
SourceSystem
Hệ thống thông tin nơi dữ liệu này được trích xuất.
Mô tả

Thuộc tính này cho biết nguồn gốc của dữ liệu quy trình. Trong mô hình dữ liệu này, giá trị luôn là 'Oracle Fusion Financials'.

Khi sử dụng nhiều ERP hoặc hệ thống tích hợp, trường này rất quan trọng để theo dõi nguồn gốc dữ liệu, xử lý sự cố và đảm bảo chất lượng dữ liệu. Trường này cho biết hệ thống nào là nguồn dữ liệu chuẩn cho các sự kiện quy trình đang được phân tích.

Vì sao điều này quan trọng

Cho biết dữ liệu bắt nguồn từ đâu, rất cần thiết cho việc quản trị dữ liệu và tích hợp dữ liệu từ nhiều hệ thống.

Lấy dữ liệu ở đâu

Đây là giá trị tĩnh được thêm trong quá trình trích xuất và chuyển đổi dữ liệu để ghi nhãn nguồn gốc của tập dữ liệu.

Ví dụ
Oracle Fusion Financials
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
Dấu thời gian của lần làm mới dữ liệu gần nhất từ hệ thống nguồn.
Mô tả

Thuộc tính này cho biết ngày giờ dữ liệu được trích xuất gần nhất từ Oracle Fusion Financials. Thuộc tính áp dụng cho toàn bộ tập dữ liệu, không phải từng sự kiện riêng lẻ.

Thông tin này giúp nhà phân tích biết dữ liệu mới đến đâu và xác nhận các giao dịch mới nhất đã được đưa vào hay chưa. Đây là siêu dữ liệu quan trọng cho báo cáo trên bảng điều khiển và giúp đảm bảo phân tích dựa trên thông tin cập nhật.

Vì sao điều này quan trọng

Cho người dùng biết dữ liệu được cập nhật gần đây đến mức nào, để phân tích luôn phù hợp và dựa trên thông tin mới nhất hiện có.

Lấy dữ liệu ở đâu

Dấu thời gian này được tạo và lưu trong quá trình trích xuất dữ liệu, thường do công cụ ETL hoặc pipeline dữ liệu ghi lại.

Ví dụ
2023-10-27T02:00:00Z
Đơn vị kinh doanh
BusinessUnit
Đơn vị kinh doanh cụ thể trong tổ chức mà yêu cầu thuộc về.
Mô tả

Đơn vị kinh doanh là một pháp nhân hoặc đơn vị chức năng riêng trong công ty, nơi phát sinh yêu cầu. Đây là nhóm tổ chức cấp cao hơn phòng ban.

Phân tích dữ liệu theo đơn vị kinh doanh giúp so sánh hiệu suất ở cấp cao giữa các bộ phận trong tổ chức. Nhờ đó, ban lãnh đạo có thể biết điểm kém hiệu quả chỉ tập trung ở một nơi hay xuất hiện trên diện rộng, từ đó xác định nơi cần ưu tiên cải tiến. Đây là chiều dữ liệu quan trọng để lọc hầu hết bảng điều khiển và KPI.

Vì sao điều này quan trọng

Cung cấp bối cảnh tổ chức ở cấp cao, giúp so sánh hiệu suất và phân tích định hướng giữa các bộ phận trong doanh nghiệp.

Lấy dữ liệu ở đâu

Đây là trường tổ chức cơ bản trong Oracle Fusion, thường có trong phần tiêu đề yêu cầu ở các bảng như POR_REQUISITION_HEADERS_ALL.

Ví dụ
Đơn vị kinh doanh Bắc MỹĐơn vị kinh doanh châu ÂuTrụ sở chính
Lý do từ chối
RejectionReason
Lý do người phê duyệt đưa ra khi từ chối yêu cầu hoặc một bước phê duyệt.
Mô tả

Khi yêu cầu bị từ chối, người phê duyệt thường nêu lý do bằng cách chọn trong danh sách có sẵn hoặc nhập nội dung tự do. Thuộc tính này ghi lại lý do đó.

Đây là thuộc tính quan trọng để tìm nguyên nhân gốc rễ của các vấn đề trong quy trình. Thuộc tính hỗ trợ trực tiếp bảng điều khiển 'Xu hướng sửa đổi và từ chối', giúp làm rõ nguyên nhân yêu cầu bị từ chối. Phân tích lý do từ chối giúp phát hiện các vấn đề phổ biến như hạch toán sai, vượt ngân sách hoặc vi phạm chính sách. Sau đó, bạn có thể xử lý bằng cách đào tạo hoặc thiết lập kiểm soát trong hệ thống.

Vì sao điều này quan trọng

Cho biết trực tiếp lý do yêu cầu bị từ chối, giúp cải tiến đúng trọng tâm để giảm việc làm lại và tăng tỷ lệ xử lý xuyên suốt.

Lấy dữ liệu ở đâu

Dữ liệu được lấy từ bình luận trong workflow hoặc các trường mã lý do từ chối trong nhật ký kiểm tra workflow, có thể nằm trong các bảng liên quan đến FA_FUSION_SOAINFRA.WFTASK hoặc nơi lưu bình luận.

Ví dụ
Tài khoản GL không chính xácVượt ngân sách của trung tâm chi phíĐã chọn nhà cung cấp không ưu tiênYêu cầu trùng lặp
Ngày cần hàng
RequiredByDate
Ngày người yêu cầu cần nhận hàng hóa hoặc dịch vụ.
Mô tả

Người yêu cầu chỉ định ngày này làm hạn nhận các mặt hàng đã yêu cầu. Đây là mục tiêu SLA nội bộ cho quy trình mua sắm.

Thuộc tính này là cơ sở cho bảng điều khiển 'Hiệu suất theo ngày cần hàng' và KPI 'Tỷ lệ đáp ứng ngày cần hàng'. Khi so sánh ngày này với ngày tạo đơn đặt hàng hoặc ngày nhận hàng thực tế, bạn có thể đánh giá quy trình mua sắm đáp ứng nhu cầu của khách hàng nội bộ đến đâu và xác định các chậm trễ mang tính hệ thống.

Vì sao điều này quan trọng

Rất quan trọng để đo lường hiệu suất quy trình so với thời hạn nội bộ và xác định quy trình mua sắm có đáp ứng nhu cầu kinh doanh đúng lúc hay không.

Lấy dữ liệu ở đâu

Thông tin thường được lưu ở cấp dòng hàng của yêu cầu, trong các bảng như POR_REQUISITION_LINES_ALL, tại trường như 'NEED_BY_DATE'.

Ví dụ
2023-11-012023-12-152024-01-31
Phòng ban
DepartmentName
Phòng ban nơi người yêu cầu làm việc.
Mô tả

Thuộc tính này cho biết đơn vị trong tổ chức của người tạo yêu cầu, chẳng hạn 'Tài chính', 'CNTT' hoặc 'Tiếp thị'. Thông tin thường được lấy từ hồ sơ người yêu cầu trong hệ thống nhân sự.

Phân tích theo phòng ban là cách phổ biến để chia nhóm dữ liệu quy trình. Cách này giúp phát hiện đặc điểm riêng của từng phòng ban, như tỷ lệ từ chối cao hơn hoặc thời gian chu kỳ dài hơn, từ đó định hướng cải tiến quy trình phù hợp. Đây cũng là chiều phân tích quan trọng trong bảng điều khiển 'Chỉ số hiệu suất người yêu cầu'.

Vì sao điều này quan trọng

Cho phép phân tích quy trình theo đơn vị kinh doanh, qua đó làm rõ các xu hướng, hiệu suất và vấn đề tuân thủ riêng của từng phòng ban.

Lấy dữ liệu ở đâu

Thông tin thường được lấy từ hồ sơ người yêu cầu, bằng cách nối bảng yêu cầu với bảng nhân sự hoặc danh bạ người dùng có thông tin phòng ban.

Ví dụ
Công nghệ thông tinTài chínhVận hànhTiếp thị
Tên người yêu cầu
RequesterName
Tên nhân viên đã tạo và gửi yêu cầu mua hàng.
Mô tả

Thuộc tính này xác định người khởi tạo yêu cầu hàng hóa hoặc dịch vụ. Thông tin thường được ghi nhận khi bắt đầu quy trình, lúc yêu cầu được tạo.

Phân tích hiệu suất quy trình theo người yêu cầu rất quan trọng đối với bảng điều khiển 'Chỉ số hiệu suất người yêu cầu'. Qua tỷ lệ yêu cầu bị sửa đổi, từ chối hoặc có thời gian chu kỳ dài, bạn có thể xác định người dùng hoặc nhóm cần được đào tạo thêm. Thuộc tính này giúp nhìn quy trình từ góc độ con người.

Vì sao điều này quan trọng

Cho phép phân tích hiệu suất theo người yêu cầu, giúp xác định nhu cầu đào tạo và tìm ra người dùng hoặc phòng ban xử lý hiệu quả.

Lấy dữ liệu ở đâu

Dữ liệu được lấy từ phần tiêu đề yêu cầu, thường bằng cách nối ID người yêu cầu với bảng dữ liệu nhân viên hoặc người dùng. Hãy tìm các trường liên quan đến 'PREPARER_ID' trong POR_REQUISITION_HEADERS_ALL và nối với PER_ALL_PEOPLE_F.

Ví dụ
John SmithJane DoeEmily Jones
Tổng giá trị yêu cầu mua hàng
RequisitionTotalAmount
Tổng giá trị tiền tệ của yêu cầu mua hàng.
Mô tả

Thuộc tính này thể hiện tổng giá trị của tất cả dòng hàng trong một yêu cầu mua hàng. Đây là dữ liệu quan trọng để hiểu mức độ ảnh hưởng tài chính của từng yêu cầu.

Trong process mining, tổng giá trị được dùng cho nhiều loại phân tích. Bạn có thể lọc các yêu cầu giá trị cao, vốn thường có luồng phê duyệt khác hoặc được xem xét kỹ hơn. Bảng điều khiển cũng có thể dùng thuộc tính này để phân tích mối liên hệ giữa giá trị yêu cầu với các chỉ số quy trình như thời gian chu kỳ hoặc tỷ lệ từ chối.

Vì sao điều này quan trọng

Bổ sung thông tin tài chính để phân tích theo giá trị, ưu tiên cải tiến quy trình và hiểu giá trị yêu cầu ảnh hưởng thế nào đến cách quy trình vận hành.

Lấy dữ liệu ở đâu

Thông tin nằm trong phần tiêu đề yêu cầu, thường ở trường như REQUISITION_TOTAL trong POR_REQUISITION_HEADERS_ALL. Bạn cũng có thể tính bằng cách cộng giá trị các dòng hàng trong POR_REQUISITION_LINES_ALL.

Ví dụ
550.0012500.7599.99
Trạng thái yêu cầu mua hàng
RequisitionStatus
Trạng thái hiện tại hoặc trạng thái cuối cùng của yêu cầu mua hàng.
Mô tả

Thuộc tính này cho biết trạng thái tổng thể của yêu cầu tại một thời điểm hoặc kết quả cuối cùng, chẳng hạn 'Đã phê duyệt', 'Đã từ chối', 'Đang xử lý' hoặc 'Đã đóng'. Đây thường là nguồn để xác định nhiều hoạt động trong nhật ký sự kiện.

Thuộc tính này là dữ liệu chính cho bảng điều khiển 'Tổng quan trạng thái yêu cầu', giúp bạn nắm được khối lượng công việc và lượng việc tồn. Thuộc tính cũng được dùng để tính KPI theo kết quả, chẳng hạn tỷ lệ từ chối yêu cầu, bằng cách lọc các case kết thúc ở một trạng thái cụ thể.

Vì sao điều này quan trọng

Cho biết trạng thái hiện tại của các yêu cầu và giúp xác định kết quả cuối cùng để tính KPI.

Lấy dữ liệu ở đâu

Thông tin có trong bảng tiêu đề yêu cầu, thường ở trường như 'DOCUMENT_STATUS' hoặc 'APPROVAL_STATUS' trong POR_REQUISITION_HEADERS_ALL.

Ví dụ
ĐÃ PHÊ DUYỆTĐANG XỬ LÝĐÃ TỪ CHỐIĐÃ RÚT
Đã sửa đổi
IsAmendedFlag
Giá trị đúng/sai cho biết yêu cầu đã được sửa đổi ít nhất một lần hay chưa.
Mô tả

Thuộc tính được tính toán này cho biết yêu cầu có thay đổi sau lần gửi đầu tiên hay không. Hệ thống xác định điều này bằng cách kiểm tra xem lịch sử case có hoạt động 'Đã sửa đổi yêu cầu' hay không.

Cờ này giúp đơn giản hóa việc phân tích và tính KPI. Cờ được dùng trực tiếp để tính KPI 'Tỷ lệ yêu cầu được sửa đổi' và xác định các case không được xử lý xuyên suốt. Bạn có thể dễ dàng lọc và so sánh chỉ số quy trình giữa các yêu cầu đã sửa đổi và chưa sửa đổi.

Vì sao điều này quan trọng

Giúp tính tỷ lệ yêu cầu được sửa đổi và dễ dàng so sánh yêu cầu đã sửa đổi với yêu cầu chưa sửa đổi.

Lấy dữ liệu ở đâu

Thuộc tính này không có trong hệ thống nguồn. Thuộc tính được tính trong quá trình chuyển đổi dữ liệu dựa trên các hoạt động liên quan đến sửa đổi trong nhật ký sự kiện.

Ví dụ
truefalse
Được tự động hóa
IsAutomated
Cờ cho biết một hoạt động có được hệ thống tự động thực hiện hay không.
Mô tả

Thuộc tính này xác định các sự kiện trong quy trình do người dùng hệ thống hoặc tác nhân tự động thực hiện thay vì con người. Ví dụ: hệ thống tự đổi trạng thái hoặc tự phê duyệt các mặt hàng giá trị thấp.

Phân tích thuộc tính này giúp đo lường mức độ tự động hóa của quy trình. Bạn có thể so sánh tốc độ và hiệu quả của các bước tự động với bước thủ công, đồng thời tìm cơ hội tự động hóa thêm.

Vì sao điều này quan trọng

Giúp đo lường mức độ tự động hóa trong quy trình và tìm cơ hội tự động hóa các tác vụ thủ công.

Lấy dữ liệu ở đâu

Được xác định bằng cách kiểm tra xem người dùng gắn với hoạt động có phải là tài khoản hệ thống hoặc tài khoản dịch vụ hay không. Cần có danh sách ID người dùng hệ thống đã biết.

Ví dụ
truefalse
Loại yêu cầu mua hàng
RequisitionType
Nhóm yêu cầu, chẳng hạn yêu cầu hàng hóa hoặc dịch vụ.
Mô tả

Thuộc tính này phân loại yêu cầu theo mặt hàng được yêu cầu. Các loại phổ biến gồm hàng hóa, dịch vụ hoặc chi phí đầu tư. Loại yêu cầu có thể ảnh hưởng đến workflow phê duyệt cần thiết và chiến lược mua sắm.

Trong phân tích, loại yêu cầu là một chiều dữ liệu hữu ích để lọc và so sánh. Ví dụ, bạn có thể xem yêu cầu dịch vụ có thời gian chu kỳ phê duyệt dài hơn yêu cầu hàng hóa hay không. Thuộc tính này giúp xác định các loại yêu cầu khác nhau có cách vận hành hoặc điểm nghẽn khác nhau không.

Vì sao điều này quan trọng

Cho phép chia nhóm phân tích để hiểu quy trình khác nhau thế nào giữa các loại mua sắm, chẳng hạn hàng hóa và dịch vụ.

Lấy dữ liệu ở đâu

Thông tin thường được xác định theo loại hoặc nhóm dòng hàng được chọn khi tạo yêu cầu. Có thể lưu trong bảng dòng yêu cầu POR_REQUISITION_LINES_ALL.

Ví dụ
Hàng hóaDịch vụChi phí đầu tư
Luồng phê duyệt
ApprovalWorkflowPath
Trình tự người phê duyệt hoặc nhóm phê duyệt được quy định cho yêu cầu.
Mô tả

Thuộc tính này xác định quy trình phê duyệt chuẩn dự kiến cho từng yêu cầu theo chính sách công ty, dựa trên các yếu tố như giá trị yêu cầu, loại yêu cầu và phòng ban. Đây là mô hình quy trình mục tiêu.

Luồng phê duyệt là cơ sở để phân tích tuân thủ và mức độ phù hợp. Thuộc tính này hỗ trợ trực tiếp bảng điều khiển 'Phân tích tuân thủ và sai lệch' cùng KPI 'Chỉ số phù hợp của yêu cầu', bằng cách so sánh các bước phê duyệt thực tế với luồng đã quy định. Sai lệch có thể cho thấy vi phạm chính sách hoặc quy trình kém hiệu quả.

Vì sao điều này quan trọng

Cho phép kiểm tra mức độ phù hợp bằng cách so sánh luồng quy trình thực tế với thứ tự phê duyệt bắt buộc, qua đó phát hiện các yêu cầu không tuân thủ.

Lấy dữ liệu ở đâu

Thông tin này được cấu hình trong Oracle Fusion BPM Worklist hoặc Approval Management Engine (AMX). Việc trích xuất luồng đã xác định cho từng yêu cầu có thể phức tạp và cần truy vấn các bảng cấu hình.

Ví dụ
Quản lý > Giám đốc > Phó chủ tịch tài chínhChủ sở hữu trung tâm chi phí > Bộ phận bảo mật CNTTQuản lý > Trưởng phòng ban
Mô tả mặt hàng
ItemDescription
Mô tả sản phẩm hoặc dịch vụ được yêu cầu trong một dòng hàng.
Mô tả

Thuộc tính này chứa mô tả bằng văn bản về mặt hàng cần mua, cung cấp thông tin cụ thể về hàng hóa hoặc dịch vụ được yêu cầu.

Dù thường không theo cấu trúc cố định, mô tả mặt hàng vẫn cung cấp ngữ cảnh hữu ích cho phân tích. Bạn có thể dùng thuộc tính này để lọc các yêu cầu mua một loại hàng cụ thể mà loại yêu cầu không thể hiện được. Ví dụ, nhà phân tích có thể tìm tất cả yêu cầu có cụm từ 'Giấy phép phần mềm' để xem luồng xử lý và thời gian chu kỳ riêng của nhóm yêu cầu đó.

Vì sao điều này quan trọng

Cung cấp thông tin cụ thể về mặt hàng được mua, giúp lọc và phân tích chi tiết hơn theo từng loại hàng hóa hoặc dịch vụ.

Lấy dữ liệu ở đâu

Thông tin nằm trong bảng dòng hàng của yêu cầu POR_REQUISITION_LINES_ALL, tại trường như ITEM_DESCRIPTION.

Ví dụ
Máy tính xách tay 15 inch, RAM 16GBDịch vụ tư vấn, dự án quý 4Gia hạn bảo trì phần mềm hằng năm
Số đơn đặt hàng
PurchaseOrderNumber
Mã định danh của đơn đặt hàng được tạo từ yêu cầu đã phê duyệt.
Mô tả

Thuộc tính này liên kết yêu cầu mua hàng với đơn đặt hàng được tạo sau đó. Khi yêu cầu được phê duyệt đầy đủ, yêu cầu thường được chuyển thành một hoặc nhiều đơn đặt hàng gửi cho nhà cung cấp.

Trong phân tích, ID này rất cần thiết để theo dõi các bước tiếp theo sau yêu cầu mua hàng. ID giúp tính KPI 'Thời gian từ yêu cầu đến đơn đặt hàng' và hỗ trợ bảng điều khiển 'Thời gian chu kỳ từ yêu cầu đến đơn đặt hàng'. Bạn cũng có thể kết hợp dữ liệu quy trình yêu cầu với dữ liệu đơn đặt hàng và hóa đơn tiếp theo để phân tích toàn bộ quy trình từ mua hàng đến thanh toán.

Vì sao điều này quan trọng

Liên kết yêu cầu với đơn đặt hàng tiếp theo, giúp đo thời gian chu kỳ từ yêu cầu đến đơn đặt hàng và phân tích quy trình từ đầu đến cuối.

Lấy dữ liệu ở đâu

Thông tin này được lưu sau khi tạo đơn đặt hàng. Thông thường, bạn có thể tìm thông tin bằng cách tra cứu tham chiếu đến yêu cầu trong các bảng phân phối đơn đặt hàng như PO_DISTRIBUTIONS_ALL, bảng này liên kết ngược đến dòng yêu cầu.

Ví dụ
PO-2023-5832PO-2023-5833PO-2023-5834
Tên người dùng
UserName
Tên người dùng thực hiện một hoạt động cụ thể, chẳng hạn người phê duyệt hoặc người chỉnh sửa.
Mô tả

Tên người yêu cầu cho biết ai khởi tạo yêu cầu, còn tên người dùng cho biết ai thực hiện một sự kiện cụ thể trong quy trình, chẳng hạn phê duyệt hoặc từ chối. Thuộc tính này đặc biệt quan trọng với workflow phê duyệt nhiều bước có sự tham gia của nhiều người.

Thuộc tính này giúp phân tích điểm nghẽn trong khâu phê duyệt và đo lường hiệu suất của từng người phê duyệt hoặc nhóm. Thuộc tính hỗ trợ trực tiếp bảng điều khiển 'Điểm nghẽn trong workflow phê duyệt', cho phép phân tích thời gian xử lý của từng người trong chuỗi phê duyệt.

Vì sao điều này quan trọng

Xác định người thực hiện từng sự kiện, rất cần thiết để phân tích thời gian bàn giao, hiệu suất của người phê duyệt và phân bổ tài nguyên.

Lấy dữ liệu ở đâu

Dữ liệu được lấy từ lịch sử workflow hoặc bảng nhật ký kiểm tra, chẳng hạn FA_FUSION_SOAINFRA.WFTASK, nơi ghi lại người dùng gắn với mỗi tác vụ đã hoàn tất.

Ví dụ
David LeeSusan ChenMichael Brown
Tên nhà cung cấp
SupplierName
Tên nhà cung cấp được đề xuất hoặc chọn trước cho hàng hóa hay dịch vụ.
Mô tả

Thuộc tính này xác định nhà cung cấp dự kiến bán hàng hóa hoặc dịch vụ. Người yêu cầu có thể đề xuất nhà cung cấp, hoặc hệ thống chọn dựa trên danh mục hay thỏa thuận trước đó.

Phân tích theo nhà cung cấp có thể làm rõ các xu hướng mua sắm quan trọng. Ví dụ, bạn có thể xác định yêu cầu từ một số nhà cung cấp mất nhiều thời gian phê duyệt hơn hoặc có tỷ lệ từ chối cao hơn. Thông tin này hữu ích cho việc quản lý quan hệ nhà cung cấp và xây dựng chiến lược mua sắm.

Vì sao điều này quan trọng

Cho phép phân tích hiệu suất quy trình theo nhà cung cấp, hỗ trợ xây dựng chiến lược tìm nguồn cung và quản lý quan hệ nhà cung cấp.

Lấy dữ liệu ở đâu

Thông tin nằm trong bảng dòng hàng của yêu cầu POR_REQUISITION_LINES_ALL, thường được liên kết qua VENDOR_ID với bảng dữ liệu nhà cung cấp như POZ_SUPPLIERS.

Ví dụ
Công ty văn phòng phẩm.Giải pháp công nghệ toàn cầuCông ty tiếp thị sáng tạo
Tiền tệ
CurrencyCode
Mã tiền tệ của giá trị yêu cầu, chẳng hạn USD hoặc EUR.
Mô tả

Thuộc tính này cho biết tổng giá trị yêu cầu mua hàng được tính bằng loại tiền tệ nào. Các tổ chức toàn cầu có thể tạo yêu cầu bằng nhiều loại tiền tệ khác nhau.

Thuộc tính này cần thiết để diễn giải và tổng hợp dữ liệu tài chính chính xác. Khi phân tích giá trị tiền tệ, bạn cần dùng mã tiền tệ để so sánh chính xác, bằng cách lọc một loại tiền tệ hoặc quy đổi tất cả giá trị sang cùng một loại.

Vì sao điều này quan trọng

Đảm bảo phân tích và báo cáo tài chính chính xác, đặc biệt tại các tổ chức đa quốc gia sử dụng nhiều loại tiền tệ.

Lấy dữ liệu ở đâu

Thông tin thường có trong bảng tiêu đề yêu cầu, cùng với các trường giá trị, chẳng hạn POR_REQUISITION_HEADERS_ALL.

Ví dụ
USDEURGBPJPY
Xử lý xuyên suốt
IsStraightThrough
Cờ cho biết yêu cầu được phê duyệt mà không bị sửa đổi hoặc từ chối.
Mô tả

Cờ được tính toán này xác định các yêu cầu đi từ lúc gửi đến khi được phê duyệt mà không phải làm lại, chẳng hạn sửa đổi hoặc bị từ chối. Điều này cho thấy một case được xử lý trọn vẹn ngay từ đầu.

Thuộc tính này là cơ sở cho KPI 'Tỷ lệ yêu cầu được xử lý xuyên suốt'. Phân tích đặc điểm của các yêu cầu được xử lý xuyên suốt, như phòng ban, người yêu cầu hoặc loại yêu cầu phổ biến, có thể giúp tìm ra cách làm hiệu quả và cơ hội tự động hóa. Ngược lại, phân tích các yêu cầu không được xử lý xuyên suốt giúp xác định nguyên nhân chính gây kém hiệu quả.

Vì sao điều này quan trọng

Đo lường trực tiếp hiệu quả quy trình và là cơ sở cho KPI Tỷ lệ yêu cầu được xử lý xuyên suốt, giúp xác định nguyên nhân phải làm lại.

Lấy dữ liệu ở đâu

Thuộc tính này được tính trong quá trình chuyển đổi dữ liệu. Một case được đánh dấu là đúng nếu không có hoạt động 'Đã sửa đổi yêu cầu' hoặc 'Đã từ chối bước phê duyệt'.

Ví dụ
truefalse
Bắt buộc Nên có Không bắt buộc

Các hoạt động trong quy trình yêu cầu mua hàng từ mua đến thanh toán

Đây là các bước và mốc quan trọng cần ghi lại trong nhật ký sự kiện để khám phá chính xác quy trình yêu cầu mua hàng từ mua đến thanh toán.
6 Nên có 6 Không bắt buộc
Hoạt động Mô tả
Đóng yêu cầu mua hàng
Đánh dấu kết thúc vòng đời yêu cầu mua hàng, nghĩa là tất cả các dòng hàng đã được đáp ứng, chẳng hạn chuyển thành PO, hoặc đã bị hủy. Có thể suy ra sự kiện này từ lần cập nhật trạng thái cuối cùng.
Vì sao điều này quan trọng

Đây là sự kiện kết thúc thành công chính của quy trình. Sự kiện xác nhận yêu cầu đã được xử lý đầy đủ và không cần thực hiện thêm.

Lấy dữ liệu ở đâu

Có thể suy ra sự kiện từ lúc trạng thái tiêu đề yêu cầu trong POR_REQUISITION_HEADERS_ALL chuyển thành 'CLOSED'.

Thu thập

Xác định dấu thời gian trạng thái tài liệu của yêu cầu chuyển thành 'Closed'.

Loại sự kiện inferred
Gửi yêu cầu mua hàng
Ghi nhận thao tác người dùng gửi yêu cầu đã hoàn tất vào quy trình phê duyệt. Sự kiện này được ghi nhận khi trạng thái yêu cầu chuyển từ 'Incomplete' hoặc 'Draft' sang trạng thái chờ phê duyệt.
Vì sao điều này quan trọng

Hoạt động này bắt đầu chu kỳ phê duyệt. Đây là mốc quan trọng để đo Thời gian chu kỳ phê duyệt yêu cầu và tổng thời gian xử lý.

Lấy dữ liệu ở đâu

Có thể suy ra sự kiện này từ thay đổi trạng thái trong bảng POR_REQUISITION_HEADERS_ALL, chẳng hạn trạng thái chuyển thành 'PENDING APPROVAL'. Ngày gửi yêu cầu thường cũng được lưu riêng.

Thu thập

Xác định dấu thời gian lần đầu trạng thái tài liệu chuyển thành 'Pending Approval'.

Loại sự kiện inferred
Phê duyệt yêu cầu mua hàng
Đánh dấu lần phê duyệt cuối cùng sau khi yêu cầu mua hàng hoàn tất mọi bước trong quy trình làm việc. Có thể suy ra sự kiện này khi trạng thái tổng thể của yêu cầu chuyển thành 'Approved'.
Vì sao điều này quan trọng

Đây là mốc quan trọng cho biết yêu cầu đã sẵn sàng để tiến hành mua sắm. Mốc này dùng để đo tổng thời gian chu kỳ phê duyệt yêu cầu.

Lấy dữ liệu ở đâu

Có thể suy ra sự kiện từ lúc trường trạng thái tài liệu trong bảng POR_REQUISITION_HEADERS_ALL chuyển thành 'APPROVED'. Ngày trạng thái thay đổi là thời điểm sự kiện.

Thu thập

Xác định dấu thời gian lần đầu trạng thái tài liệu được đặt thành 'Approved'.

Loại sự kiện inferred
Tạo đơn đặt hàng
Sự kiện xảy ra khi một dòng yêu cầu đã được phê duyệt được dùng để tạo đơn đặt hàng. Sự kiện này kết nối quy trình yêu cầu mua hàng với quy trình mua sắm tiếp theo.
Vì sao điều này quan trọng

Đây là mốc quan trọng để đo Thời gian từ yêu cầu đến PO. Chậm trễ ở đây cho thấy điểm nghẽn trong khâu chuyển từ phê duyệt sang mua hàng.

Lấy dữ liệu ở đâu

Đây là sự kiện được ghi nhận rõ. Liên kết giữa yêu cầu và đơn đặt hàng được lưu trong các bảng như PO_LINE_LOCATIONS_ALL, có tham chiếu đến mã dòng yêu cầu nguồn.

Thu thập

Tìm ngày tạo Purchase Order có tham chiếu đến Requisition ID tương ứng.

Loại sự kiện explicit
Tạo yêu cầu mua hàng
Đánh dấu thời điểm bắt đầu quy trình mua sắm, khi người dùng lưu yêu cầu mua hàng mới lần đầu. Sự kiện này thường được ghi nhận rõ trong hệ thống dưới dạng bản ghi mới cùng dấu thời gian tương ứng.
Vì sao điều này quan trọng

Đây là sự kiện bắt đầu chính của quy trình yêu cầu mua hàng. Phân tích thời gian từ lúc tạo đến khi gửi yêu cầu có thể giúp phát hiện chậm trễ trong khâu hoàn tất yêu cầu.

Lấy dữ liệu ở đâu

Sự kiện này được ghi trong bảng POR_REQUISITION_HEADERS_ALL, lấy từ cột creation_date khi hệ thống tạo mã Requisition ID mới.

Thu thập

Dùng dấu thời gian tạo bản ghi tiêu đề yêu cầu mua hàng.

Loại sự kiện explicit
Từ chối yêu cầu mua hàng
Ghi nhận việc từ chối cuối cùng, kết thúc quy trình xử lý yêu cầu này. Có thể suy ra sự kiện khi trạng thái tổng thể của yêu cầu chuyển thành 'Rejected'.
Vì sao điều này quan trọng

Hoạt động này là điểm kết thúc của các yêu cầu không thành công. Phân tích những trường hợp này rất cần thiết để hiểu KPI Tỷ lệ yêu cầu mua hàng bị từ chối và nguyên nhân thất bại.

Lấy dữ liệu ở đâu

Có thể suy ra sự kiện từ lúc trạng thái tài liệu trong bảng POR_REQUISITION_HEADERS_ALL chuyển thành 'REJECTED'.

Thu thập

Xác định dấu thời gian lần đầu trạng thái tài liệu được đặt thành 'Rejected'.

Loại sự kiện inferred
Bắt đầu bước phê duyệt
Đánh dấu thời điểm yêu cầu được giao cho một người phê duyệt hoặc nhóm phê duyệt cụ thể trong quy trình làm việc. Sự kiện này được lấy từ nhật ký giao dịch của workflow engine.
Vì sao điều này quan trọng

Hoạt động này rất quan trọng để tính thời gian chờ ở từng bước phê duyệt. Qua đó, bạn có thể xác định điểm nghẽn do người phê duyệt hoặc cấp phê duyệt cụ thể gây ra.

Lấy dữ liệu ở đâu

Lấy dữ liệu từ các bảng workflow của Oracle Fusion, nơi ghi lại các tác vụ được giao cho người dùng. Dùng dấu thời gian giao tác vụ phê duyệt.

Thu thập

Dùng dấu thời gian tạo tác vụ trong lịch sử workflow của yêu cầu tương ứng.

Loại sự kiện explicit
Chỉnh sửa yêu cầu mua hàng
Sự kiện này cho biết người dùng đã sửa yêu cầu sau lần gửi đầu tiên, thường khiến quy trình phê duyệt phải bắt đầu lại. Có thể suy ra sự kiện bằng cách phát hiện thay đổi ở các trường dữ liệu chính hoặc việc tạo phiên bản mới của yêu cầu.
Vì sao điều này quan trọng

Yêu cầu thường xuyên bị chỉnh sửa cho thấy dữ liệu có vấn đề hoặc yêu cầu thay đổi, dẫn đến việc làm lại và chậm trễ. Chỉ số này liên quan trực tiếp đến KPI 'Tỷ lệ yêu cầu mua hàng bị chỉnh sửa'.

Lấy dữ liệu ở đâu

Có thể suy ra sự kiện bằng cách theo dõi số phiên bản của yêu cầu hoặc phát hiện trạng thái chuyển lại thành 'Incomplete' sau khi gửi. Nhật ký thay đổi hoặc bảng dấu vết kiểm toán cũng có thể ghi lại các lần chỉnh sửa này.

Thu thập

Xác định dấu thời gian tạo phiên bản mới cho cùng một Requisition ID sau khi yêu cầu đã được gửi.

Loại sự kiện inferred
Phê duyệt bước
Ghi nhận thao tác của một người phê duyệt khi họ phê duyệt yêu cầu ở bước được giao trong quy trình làm việc. Sự kiện này được ghi rõ trong lịch sử phê duyệt.
Vì sao điều này quan trọng

Theo dõi từng bước phê duyệt giúp lập bản đồ luồng phê duyệt thực tế và đo thời gian xử lý ở mỗi cấp trong hệ thống phân cấp.

Lấy dữ liệu ở đâu

Lấy dữ liệu từ lịch sử hành động phê duyệt của yêu cầu, thường được lưu trong các bảng workflow (WF) hoặc Human Capital Management (HCM) quản lý cấp phê duyệt.

Thu thập

Dùng dấu thời gian của hành động 'APPROVE' trong nhật ký lịch sử hành động workflow.

Loại sự kiện explicit
Rút yêu cầu mua hàng
Sự kiện xảy ra khi người yêu cầu hủy hoặc rút yêu cầu đã gửi trước khi yêu cầu được phê duyệt đầy đủ. Thường đây là thao tác rõ ràng của người dùng khiến trạng thái thay đổi.
Vì sao điều này quan trọng

Theo dõi các yêu cầu bị rút giúp tìm hiểu lý do kết thúc sớm, chẳng hạn như nhu cầu kinh doanh thay đổi hoặc người dùng sửa lỗi sau khi gửi.

Lấy dữ liệu ở đâu

Có thể suy ra sự kiện này từ thay đổi trạng thái thành 'WITHDRAWN' trong bảng POR_REQUISITION_HEADERS_ALL. Thao tác được ghi lại trong lịch sử hành động của yêu cầu.

Thu thập

Phát hiện dấu thời gian trạng thái yêu cầu chuyển thành 'Withdrawn'.

Loại sự kiện inferred
Trả lại ở bước phê duyệt
Người phê duyệt gửi yêu cầu lại cho người lập để bổ sung thông tin hoặc sửa một số lỗi nhỏ mà không chính thức từ chối. Đây thường là thao tác được ghi rõ trong hệ thống workflow.
Vì sao điều này quan trọng

Sự kiện này cho thấy cần làm rõ thông tin và tạo vòng xử lý lại, kéo dài thời gian chu kỳ. Phân biệt yêu cầu được trả lại với yêu cầu bị từ chối giúp hiểu rõ hơn những vướng mắc trong quy trình.

Lấy dữ liệu ở đâu

Lấy dữ liệu từ lịch sử hành động phê duyệt của yêu cầu. Hệ thống workflow ghi lại hành động 'RETURN' hoặc hành động tương tự cùng dấu thời gian.

Thu thập

Dùng dấu thời gian của hành động 'RETURN' hoặc 'Request for Information' trong lịch sử workflow.

Loại sự kiện explicit
Từ chối bước phê duyệt
Người phê duyệt từ chối yêu cầu, thường gửi yêu cầu lại cho người lập để sửa hoặc kết thúc yêu cầu. Thao tác này được ghi rõ trong lịch sử workflow.
Vì sao điều này quan trọng

Hoạt động này là nguyên nhân chính dẫn đến việc làm lại và chậm trễ. Phân tích các trường hợp từ chối giúp phát hiện vấn đề về tuân thủ, ngân sách hoặc lý do yêu cầu chưa rõ.

Lấy dữ liệu ở đâu

Lấy dữ liệu từ lịch sử hành động phê duyệt của yêu cầu. Hệ thống workflow ghi lại hành động 'REJECT' cùng dấu thời gian.

Thu thập

Dùng dấu thời gian của hành động 'REJECT' trong nhật ký lịch sử hành động workflow.

Loại sự kiện explicit
Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ Oracle Fusion Financials

Sẵn sàng bắt đầu?

Dùng mẫu này để bắt đầu tối ưu hóa quy trình yêu cầu mua hàng từ mua đến thanh toán và nâng cao hiệu quả. Hãy sẵn sàng cải thiện hoạt động mua sắm của bạn.

Rút ngắn 30% thời gian xử lý yêu cầu mua hàng từ mua đến thanh toán

Đơn giản hóa quy trình yêu cầu mua hàng P2P trên Oracle và giảm 30% thời gian xử lý.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng, thiết lập chỉ trong vài phút.