> Cải tiến quy trình liên tục > Yêu cầu mua hàng đến thanh toán > Microsoft Dynamics 365 > Mẫu dữ liệu

Mẫu dữ liệu yêu cầu mua hàng trong Purchase to Pay

Microsoft Dynamics 365

Các thuộc tính của yêu cầu mua hàng trong Purchase to Pay(17) Các hoạt động của yêu cầu mua hàng trong Purchase to Pay(12) Hướng dẫn trích xuất dữ liệu(3)

Mẫu dữ liệu yêu cầu mua hàng trong Purchase to Pay

Mẫu này nêu các thuộc tính chính cần thu thập và hoạt động quan trọng cần theo dõi để bạn phân tích sâu quy trình yêu cầu mua hàng. Mẫu cũng hướng dẫn cách trích xuất dữ liệu, giúp bạn chuẩn bị nhật ký sự kiện nhanh chóng cho việc phân tích chi tiết.

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

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.

Tải mẫu xuống

Các thuộc tính của yêu cầu mua hàng trong Purchase to Pay

Đâ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 trong Purchase to Pay.

5 Bắt buộc 6 Nên có 6 Không bắt buộc

	Tên	Mô tả
	Purchase Requisition ID PurchaseRequisitionId	Mã định danh duy nhất của yêu cầu mua hàng, dùng làm mã hồ sơ chính.
Mô tả Purchase Requisition ID là khóa trung tâm liên kết mọi hoạt động của một yêu cầu mua hàng hóa hoặc dịch vụ. Mỗi quy trình yêu cầu mua hàng, từ lúc tạo đến khi được phê duyệt và đóng, đều được theo dõi bằng mã duy nhất này. Trong process mining, thuộc tính này là nền tảng để tái dựng toàn bộ hành trình của từng yêu cầu mua hàng. Thuộc tính cho phép phân tích các biến thể quy trình, thời gian xử lý và mức độ tuân thủ của từng hồ sơ, giúp bạn nắm được toàn bộ vòng đời yêu cầu. Vì sao điều này quan trọng Thuộc tính này cần thiết để nhóm mọi sự kiện liên quan vào cùng một phiên bản quy trình, nhờ đó có thể phân tích toàn bộ vòng đời của từng yêu cầu mua hàng từ đầu đến cuối. Lấy dữ liệu ở đâu Đây thường là khóa chính trong bảng tiêu đề yêu cầu mua hàng, chẳng hạn PurchReqTable trong Microsoft Dynamics 365. Ví dụ PR-001254PR-001255PR-001256
	Tên hoạt động ActivityName	Tên của sự kiện hoặc bước nghiệp vụ cụ thể đã diễn ra trong quy trình yêu cầu mua hàng.
Mô tả Thuộc tính này ghi lại tên từng hoạt động trong vòng đời yêu cầu mua hàng. Ví dụ gồm 'Tạo yêu cầu mua hàng', 'Phê duyệt bước' và 'Tạo đơn đặt hàng'. Các hoạt động này tạo thành những nút trong sơ đồ quy trình được khám phá. Phân tích trình tự, tần suất và thời gian giữa các hoạt động là trọng tâm của process mining. Việc này giúp tìm ra điểm nghẽn, vòng lặp làm lại và sai lệch so với luồng quy trình tiêu chuẩn, qua đó cho thấy những điểm kém hiệu quả trong vận hành. Vì sao điều này quan trọng Thuộc tính này xác định các bước trong sơ đồ quy trình, giúp bạn trực quan hóa, phân tích và hiểu rõ workflow yêu cầu mua hàng. Lấy dữ liệu ở đâu Thông tin này thường được lấy từ nhật ký thay đổi trạng thái, bảng lịch sử workflow hoặc bảng sự kiện cụ thể trong Microsoft Dynamics 365, chẳng hạn WorkflowTrackingStatusTable. Ví dụ Gửi yêu cầu mua hàng để phê duyệtPhê duyệt bướcSửa đổi yêu cầu mua hàng
	Thời gian sự kiện EventTime	Dấu thời gian chính xác khi một hoạt động hoặc sự kiện cụ thể diễn ra.
Mô tả Thời gian sự kiện, hay dấu thời gian, ghi lại ngày và giờ một sự kiện nghiệp vụ được lưu trong hệ thống. Đây là cơ sở thời gian cho mọi phân tích quy trình. Thuộc tính này rất quan trọng để tính thời gian xử lý, thời lượng và thời gian chờ giữa các hoạt động. Thuộc tính giúp phân tích hiệu suất quy trình, xác định điểm nghẽn và theo dõi việc tuân thủ SLA. Dấu thời gian chính xác là điều kiện cần để phân tích process mining đáng tin cậy. Vì sao điều này quan trọng Thuộc tính này xác định thứ tự thời gian của các sự kiện, cần thiết để tính thời lượng quy trình, tìm điểm nghẽn và phân tích hiệu suất theo thời gian. Lấy dữ liệu ở đâu Thông tin thường nằm trong bảng lịch sử workflow hoặc nhật ký tài liệu, dưới dạng trường 'CreatedDateTime' hoặc 'ModifiedDateTime' gắn với mỗi lần thay đổi trạng thái hoặc bản ghi sự kiện. Ví dụ 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	Hệ thống nguồn SourceSystemId	Hệ thống lưu trữ dữ liệu gốc, nơi dữ liệu được trích xuất.
Mô tả Thuộc tính này xác định hệ thống nguồn của dữ liệu sự kiện. Trong trường hợp này, đó là 'Microsoft Dynamics 365'. Nếu môi trường có nhiều hệ thống tích hợp, trường này rất quan trọng để theo dõi nguồn gốc và ngữ cảnh của dữ liệu. Khi phân tích, thuộc tính giúp phân biệt các quy trình có thể trải qua nhiều hệ thống hoặc xác nhận dữ liệu đến từ một nguồn duy nhất, có thẩm quyền. Điều này giúp kiểm tra dữ liệu và bảo đảm phân tích dựa trên đúng bộ dữ liệu. Vì sao điều này quan trọng Thuộc tính này cho biết nguồn gốc dữ liệu, rất quan trọng đối với quản trị và xác thực dữ liệu, cũng như trong môi trường tích hợp nhiều hệ thống. Lấy dữ liệu ở đâu Đây là giá trị cố định 'Microsoft Dynamics 365', được thêm trong quá trình trích xuất và chuyển đổi dữ liệu. Ví dụ Microsoft Dynamics 365 F&OD365MSD365
	Lần cập nhật dữ liệu gần nhất LastDataIngestionTimestamp	Dấu thời gian cho biết lần gần nhất dữ liệu được trích xuất và tải vào công cụ process mining.
Mô tả Thuộc tính này cho biết dữ liệu đang phân tích có mới hay không. Thuộc tính hiển thị ngày và giờ lần gần nhất dữ liệu được làm mới từ hệ thống nguồn. Đây không phải trường có sẵn trong Dynamics 365, mà là siêu dữ liệu được thêm khi nạp dữ liệu. Dấu thời gian này giúp người dùng biết thông tin phân tích được cập nhật đến thời điểm nào. Nhờ đó, họ có thể xác định mình đang xem dữ liệu thời gian thực hay ảnh chụp dữ liệu tại một thời điểm cụ thể, yếu tố ảnh hưởng đến mức độ phù hợp của kết luận. Vì sao điều này quan trọng Thuộc tính này cho người dùng biết dữ liệu được cập nhật đến thời điểm nào, giúp họ hiểu rõ khung thời gian phân tích và mức độ phù hợp của thông tin. Lấy dữ liệu ở đâu Giá trị này được tạo và thêm vào bộ dữ liệu trong quá trình nạp dữ liệu hoặc ETL. Ví dụ 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Bước phê duyệt ApprovalStep	Tên hoặc giai đoạn của một bước phê duyệt cụ thể trong quy trình làm việc.
Mô tả Thuộc tính này xác định giai đoạn cụ thể trong quy trình làm việc phê duyệt, chẳng hạn như 'Quản lý phê duyệt' hoặc 'Tài chính phê duyệt'. Thuộc tính cung cấp thông tin chi tiết hơn tên hoạt động chung. Thuộc tính này rất cần thiết cho 'Phân tích điểm nghẽn ở bước phê duyệt'. Khi theo dõi thời gian xử lý ở từng bước phê duyệt riêng biệt, bạn có thể xác định chính xác giai đoạn nào đang làm chậm toàn bộ quy trình. Từ đó, bạn có thể tập trung cải tiến để nâng cao hiệu quả quy trình làm việc. Vì sao điều này quan trọng Thuộc tính này cho phép phân tích chi tiết quy trình làm việc phê duyệt, giúp xác định chính xác các giai đoạn gây ra điểm nghẽn. Lấy dữ liệu ở đâu Thông tin này nằm trong các bảng lịch sử quy trình làm việc, chẳng hạn WorkflowTrackingStatusTable, nơi ghi lại từng bước của quy trình làm việc đã cấu hình. Ví dụ Quản lý phê duyệtTrưởng phòng phê duyệtTài chính xem xét
	Mức độ khẩn cấp UrgencyLevel	Phân loại mức độ khẩn cấp của yêu cầu, chẳng hạn 'Cao', 'Trung bình' hoặc 'Thấp'.
Mô tả Mức độ khẩn cấp, hay mức ưu tiên, cho biết cần hàng hóa hoặc dịch vụ được yêu cầu nhanh đến đâu. Thuộc tính này thường được dùng để điều chỉnh luồng phê duyệt hoặc ưu tiên công việc cho người phê duyệt. Phân tích thuộc tính này giúp xác định hệ thống ưu tiên có hiệu quả hay không. Ví dụ, bạn có thể so sánh thời gian xử lý yêu cầu có mức khẩn cấp 'Cao' với yêu cầu ở mức 'Thấp'. Nếu không có khác biệt đáng kể, có thể trường ưu tiên đang bị bỏ qua hoặc sử dụng sai. Đây là thông tin quan trọng trên dashboard 'Phân tích tác động của mức độ khẩn cấp'. Vì sao điều này quan trọng Thuộc tính này giúp đánh giá liệu cài đặt mức ưu tiên có đẩy nhanh việc xử lý các yêu cầu cấp thiết hay không, đồng thời phát hiện khả năng phân loại mức độ khẩn cấp chưa đúng. Lấy dữ liệu ở đâu Đây có thể là trường tiêu chuẩn hoặc trường tùy chỉnh trong PurchReqTable. Trường có tồn tại hay không và tên trường có thể khác nhau tùy cấu hình hệ thống. Ví dụ CaoTrung bìnhThấp
	Người dùng User	ID hoặc tên người dùng đã thực hiện hoạt động.
Mô tả Thuộc tính này xác định nhân viên hoặc người dùng hệ thống chịu trách nhiệm thực hiện một bước cụ thể trong quy trình, chẳng hạn gửi yêu cầu mua hàng hoặc phê duyệt yêu cầu. Giá trị có thể là ID người dùng, họ tên hoặc địa chỉ email. Phân tích hoạt động theo người dùng giúp xác định nhu cầu đào tạo, cá nhân hoặc nhóm có hiệu suất cao và cách phân bổ khối lượng công việc. Thuộc tính này cũng cần thiết để phân tích tuân thủ, chẳng hạn phân tách nhiệm vụ, và tìm hiểu cách các vai trò người dùng khác nhau tương tác với quy trình. Vì sao điều này quan trọng Thuộc tính này cho phép phân tích hành vi, khối lượng công việc và hiệu suất của từng người dùng, rất quan trọng để quản lý tài nguyên và xác định nhu cầu đào tạo. Lấy dữ liệu ở đâu Thông tin thường nằm trong bảng lịch sử workflow, chẳng hạn WorkflowTrackingStatusTable, hoặc bảng giao dịch, chẳng hạn PurchReqTable, được liên kết với bảng người dùng, chẳng hạn UserInfo. Ví dụ j.smitha.joness.patel
	Phòng ban Department	Phòng ban của người yêu cầu hoặc trung tâm chi phí gắn với yêu cầu mua hàng.
Mô tả Thuộc tính này cho biết phòng ban hoặc trung tâm chi phí đã tạo yêu cầu mua hàng, chẳng hạn 'Marketing', 'IT' hoặc 'Vận hành'. Thông tin này thường nằm trong phần đầu yêu cầu mua hàng. Phân nhóm quy trình theo phòng ban rất quan trọng để so sánh. Bạn có thể xem phòng ban nào có thời gian xử lý dài nhất, tỷ lệ từ chối cao nhất hoặc thường xuyên sửa đổi yêu cầu nhất. Những thông tin này giúp điều chỉnh cải tiến quy trình theo nhu cầu cụ thể của từng phòng ban. Vì sao điều này quan trọng Thuộc tính này cho phép lọc và so sánh hiệu suất quy trình giữa các đơn vị kinh doanh, qua đó làm rõ những kiểu xử lý, điểm nghẽn hoặc điểm kém hiệu quả riêng của từng phòng ban. Lấy dữ liệu ở đâu Thông tin này thường được lưu trong phần đầu của yêu cầu mua hàng (PurchReqTable) và liên kết với cấu hình chiều tài chính trong Dynamics 365. Ví dụ Phòng CNTTTài chínhVận hành
	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 ghi nhận tổng giá trị của tất cả các dòng hàng trong một yêu cầu mua hàng. Giá trị thường ảnh hưởng đến độ phức tạp của quy trình làm việc phê duyệt. Yêu cầu có giá trị cao thường cần thêm bước phê duyệt. Trong phân tích quy trình, thuộc tính này rất cần thiết để lọc và phân tích theo giá trị. Thuộc tính giúp trả lời những câu hỏi như: 'Yêu cầu giá trị cao có mất nhiều thời gian phê duyệt hơn không?' hoặc 'Giá trị của các yêu cầu hiện đang bị tắc trong quy trình là bao nhiêu?'. Nhờ đó, bạn có thêm bối cảnh tài chính khi đánh giá hiệu suất quy trình. Vì sao điều này quan trọng Thuộc tính này bổ sung góc nhìn tài chính cho phân tích, giúp ưu tiên các hồ sơ giá trị cao và hiểu giá trị tiền tệ ảnh hưởng thế nào đến cách quy trình diễn ra. Lấy dữ liệu ở đâu Giá trị này thường nằm trong bảng phần đầu yêu cầu mua hàng hoặc được tính bằng cách cộng giá trị các dòng hàng trong bảng dòng yêu cầu mua hàng (PurchReqLine). Ví dụ 1500.0025000.50500.75
	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 mua hàng tại một thời điểm, chẳng hạn như 'Đang xem xét', 'Đã phê duyệt', 'Bị từ chối' hoặc 'Đã đóng'. Đây thường là thuộc tính ở cấp hồ sơ, thể hiện kết quả cuối cùng. Phân tích trạng thái cuối cùng giúp bạn hiểu kết quả chung của quy trình. Ví dụ, số lượng yêu cầu 'Bị từ chối' hoặc 'Đã rút' cao có thể cho thấy vấn đề ở giai đoạn gửi yêu cầu ban đầu hoặc quy trình phê duyệt quá rườm rà. Đây là chỉ số quan trọng để đo tỷ lệ thành công và hiệu quả quy trình. Vì sao điều này quan trọng Thuộc tính này cho biết rõ kết quả của từng hồ sơ, giúp phân tích tỷ lệ phê duyệt, từ chối và rút yêu cầu, vốn là các chỉ số hiệu suất chính. Lấy dữ liệu ở đâu Trường trạng thái thường nằm trong bảng phần đầu yêu cầu mua hàng PurchReqTable, thường có tên 'Status' hoặc 'PurchReqStatus'. Ví dụ Đã phê duyệtĐang xem xétBị từ chốiBản nháp
	Được phê duyệt ngay lần đầu IsFirstPass	Cờ cho biết yêu cầu mua hàng có được phê duyệt mà không cần chỉnh sửa hoặc bị từ chối trước đó hay không.
Mô tả Đây là thuộc tính boolean được tính toán. Giá trị là 'true' nếu yêu cầu được phê duyệt mà không có hoạt động 'Đã chỉnh sửa yêu cầu mua hàng' hoặc 'Bước phê duyệt bị từ chối'. Nếu không, giá trị là 'false'. Thuộc tính này hỗ trợ trực tiếp KPI 'Tỷ lệ yêu cầu mua hàng được phê duyệt ngay lần đầu'. Thuộc tính giúp phân tích hiệu quả quy trình bằng cách chỉ rõ hồ sơ nào cần làm lại. Tỷ lệ được phê duyệt ngay lần đầu thấp cho thấy chất lượng dữ liệu ban đầu có vấn đề hoặc yêu cầu chưa rõ ràng, từ đó mở ra cơ hội cải tiến quy trình. Vì sao điều này quan trọng Thuộc tính này đo trực tiếp chất lượng và hiệu quả quy trình bằng cách xác định các hồ sơ cần làm lại, hỗ trợ những KPI tập trung vào tỷ lệ hoàn thành đúng ngay lần đầu. Lấy dữ liệu ở đâu Đây là thuộc tính được tính toán. Khi chuyển đổi dữ liệu, cần phân tích toàn bộ chuỗi hoạt động của từng hồ sơ để kiểm tra xem có hoạt động làm lại nào trước khi phê duyệt hay không. Ví dụ truefalse
	Luồng phê duyệt ApprovalWorkflowPath	Biểu diễn thứ tự các bước phê duyệt đã thực hiện.
Mô tả Đây là trường được tạo bằng cách nối các bước phê duyệt của một yêu cầu theo thứ tự, chẳng hạn 'Quản lý phê duyệt -> Trưởng phòng phê duyệt -> Tài chính phê duyệt'. Trường này tóm tắt biến thể quy trình của quy trình con phê duyệt. Thuộc tính này rất quan trọng đối với dashboard 'Theo dõi sai lệch tuân thủ'. Khi so sánh luồng thực tế với luồng chuẩn hoặc dự kiến, bạn có thể dễ dàng phát hiện các luồng quy trình không tuân thủ hoặc bất thường, có thể là dấu hiệu vi phạm chính sách hoặc rủi ro vận hành. Vì sao điều này quan trọng Thuộc tính này giúp đơn giản hóa việc phân tích tuân thủ bằng cách biểu diễn rõ biến thể quy trình dưới dạng chuỗi, nhờ đó dễ phát hiện sai lệch so với quy trình chuẩn. Lấy dữ liệu ở đâu Đây không phải trường tiêu chuẩn. Khi chuyển đổi dữ liệu, cần tạo trường này bằng cách nối các giá trị 'ApprovalStep' theo thứ tự thời gian cho từng hồ sơ. Ví dụ Quản lý -> Giám đốcQuản lý -> Giám đốc -> Phó chủ tịch phụ trách tài chínhQuản lý -> Tự động phê duyệt
	Nhóm phê duyệt ApproverGroup	Nhóm người dùng hoặc vai trò phụ trách một bước phê duyệt.
Mô tả Thuộc tính này xác định nhóm, vai trò hoặc hàng đợi được giao xử lý một tác vụ phê duyệt cụ thể, chẳng hạn 'Nhóm phê duyệt tài chính' hoặc 'Quản lý CNTT'. Phân tích hiệu suất quy trình theo nhóm phê duyệt giúp bạn hiểu cách phân bổ khối lượng công việc và xác định nhóm nào có thể thiếu tài nguyên hoặc cần được đào tạo thêm. Thuộc tính này hỗ trợ trực tiếp dashboard 'Phân tích điểm nghẽn ở bước phê duyệt', cho phép phân tích hiệu suất theo các nhóm phụ trách phê duyệt. Vì sao điều này quan trọng Thuộc tính này giúp phát hiện khác biệt về hiệu suất giữa các nhóm phê duyệt, qua đó làm rõ nhóm nào có thể thiếu tài nguyên hoặc cần được đào tạo thêm. Lấy dữ liệu ở đâu Thông tin này nằm trong lịch sử quy trình làm việc, chẳng hạn WorkflowTrackingStatusTable, nơi ghi lại người dùng hoặc nhóm người dùng được giao xử lý từng tác vụ. Ví dụ Nhóm phê duyệt tài chínhQuản lý CNTTBan lãnh đạo cấp cao
	Số đơn đặt hàng PurchaseOrderNumber	Mã định danh của đơn đặt hàng được tạo từ yêu cầu mua hàng.
Mô tả Thuộc tính này lưu mã định danh duy nhất của đơn đặt hàng được tạo từ một yêu cầu mua hàng đã phê duyệt. Đây là liên kết giữa quy trình yêu cầu mua hàng và quy trình mua sắm tiếp theo. Theo dõi số này rất cần thiết để phân tích 'Thời gian chuyển đổi từ yêu cầu mua hàng sang đơn đặt hàng'. Số này xác nhận yêu cầu đã chuyển thành công sang giai đoạn tiếp theo của chu trình Purchase-to-Pay, đồng thời cho phép phân tích xuyên suốt cả yêu cầu mua hàng và đơn đặt hàng. Vì sao điều này quan trọng Thuộc tính này liên kết yêu cầu mua hàng với đơn đặt hàng tiếp theo, giúp phân tích quá trình chuyển đổi từ yêu cầu sang đơn đặt hàng và kết nối các giai đoạn khác nhau của quy trình P2P. Lấy dữ liệu ở đâu Thông tin này thường có trong bảng dòng yêu cầu mua hàng (PurchReqLine) sau khi tạo đơn đặt hàng, liên kết ngược về PurchTable. Ví dụ PO-000987PO-000988PO-000989
	Số lần chỉnh sửa AmendmentCount	Tổng số lần yêu cầu mua hàng được chỉnh sửa.
Mô tả Đây là thuộc tính số được tính toán, đếm số lần hoạt động 'Đã chỉnh sửa yêu cầu mua hàng' xuất hiện trong từng hồ sơ yêu cầu mua hàng. Thuộc tính này rất cần thiết cho dashboard 'Tần suất chỉnh sửa yêu cầu mua hàng' và KPI 'Tỷ lệ yêu cầu mua hàng bị chỉnh sửa'. Thuộc tính định lượng số lần làm lại trong mỗi hồ sơ, giúp dễ xác định yêu cầu, phòng ban hoặc người dùng nào thường xuyên thay đổi và gây kém hiệu quả. Nhờ đó, bạn có thể tập trung cải thiện chất lượng yêu cầu ban đầu. Vì sao điều này quan trọng Thuộc tính này định lượng số lần làm lại trong một hồ sơ, giúp đo lường và phân tích tần suất chỉnh sửa cũng như ảnh hưởng của việc này đến hiệu quả quy trình. Lấy dữ liệu ở đâu Đây là thuộc tính được tính toán. Thuộc tính được tạo trong quá trình chuyển đổi dữ liệu bằng cách đếm số hoạt động 'Đã chỉnh sửa yêu cầu mua hàng' cho mỗi PurchaseRequisitionId duy nhất. Ví dụ 013
	Tiền tệ Currency	Mã tiền tệ của giá trị yêu cầu mua hàng.
Mô tả Thuộc tính này cho biết loại tiền tệ, chẳng hạn USD, EUR hoặc GBP, dùng để tính tổng giá trị yêu cầu mua hàng. Đây là thông tin thiết yếu khi phân tích tài chính, nhất là tại các tổ chức đa quốc gia sử dụng nhiều loại tiền tệ. Thuộc tính tiền tệ giúp xử lý và tổng hợp dữ liệu tài chính chính xác. Thuộc tính đảm bảo các giá trị tiền tệ được hiểu đúng, đồng thời cho phép quy đổi sang một loại tiền tệ chung để báo cáo và so sánh chính xác giữa các khu vực hoặc đơn vị kinh doanh. Vì sao điều này quan trọng Thuộc tính này cung cấp bối cảnh cần thiết cho các trường tài chính, giúp diễn giải và tổng hợp chính xác giá trị tiền tệ trong môi trường sử dụng nhiều loại tiền tệ. Lấy dữ liệu ở đâu Trường này thường nằm trong bảng phần đầu yêu cầu mua hàng PurchReqTable, cùng với các trường giá trị. Ví dụ USDEURGBP

Bắt buộc Nên có Không bắt buộc

Các hoạt động của yêu cầu mua hàng trong Purchase to Pay

Đâ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á và phân tích chính xác quy trình làm việc yêu cầu mua hàng.

7 Nên có 5 Không bắt buộc

	Hoạt động	Mô tả
	Đóng yêu cầu mua hàng	Toàn bộ yêu cầu mua hàng được xem là hoàn tất khi tất cả các dòng hàng đã được chuyển thành đơn đặt hàng hoặc bị hủy. Đây là trạng thái kết thúc thành công.
Vì sao điều này quan trọng Hoạt động này đánh dấu vòng đời yêu cầu mua hàng đã hoàn tất thành công. Đây là điểm cuối để đo tổng thời gian xử lý từ đầu đến cuối. Lấy dữ liệu ở đâu Trạng thái này thường được tính toán hoặc suy ra. Trạng thái xuất hiện khi tất cả bản ghi 'PurchReqLine' liên quan đều đạt trạng thái kết thúc, chẳng hạn 'Closed' hoặc 'Cancelled'. Thu thập Xác định sự kiện này bằng cách kiểm tra xem tất cả bản ghi PurchReqLine con của một PurchReqTable đã có trạng thái cuối cùng hay chưa. Loại sự kiện calculated
	Gửi yêu cầu mua hàng để phê duyệt	Người dùng gửi yêu cầu mua hàng đã hoàn tất, bắt đầu workflow phê duyệt chính thức. Đây là thao tác rõ ràng được ghi lại bởi bộ máy workflow của hệ thống.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, đánh dấu thời điểm bắt đầu chu kỳ phê duyệt. Mốc này dùng để đo 'Thời gian phê duyệt yêu cầu mua hàng' và 'Tỷ lệ được duyệt ngay lần đầu'. Lấy dữ liệu ở đâu Dữ liệu được ghi trong 'WorkflowTrackingStatusTable' hoặc bảng lịch sử workflow tương tự, nơi sự kiện 'Submission' được ghi nhận cho yêu cầu mua hàng. Thu thập Lọc nhật ký lịch sử workflow để tìm sự kiện loại 'Submission' hoặc 'Start' gắn với yêu cầu mua hàng. Loại sự kiện explicit
	Phê duyệt bước	Người phê duyệt hoàn tất tác vụ được giao và duyệt yêu cầu mua hàng ở giai đoạn của mình. Sau đó, yêu cầu chuyển sang bước tiếp theo hoặc được phê duyệt cuối cùng.
Vì sao điều này quan trọng Hoạt động này đo thời gian xử lý ở từng giai đoạn phê duyệt và giúp xác định những phần hiệu quả trong workflow. Đây cũng là thành phần quan trọng để phân tích các biến thể quy trình. Lấy dữ liệu ở đâu Sự kiện được ghi rõ trong 'WorkflowTrackingStatusTable' khi người dùng hoàn tất một mục công việc với kết quả 'Approve'. Thu thập Tìm sự kiện 'WorkItemCompleted' có kết quả 'Approve' trong nhật ký lịch sử workflow. Loại sự kiện explicit
	Tạo đơn đặt hàng	Một dòng yêu cầu mua hàng đã được phê duyệt được chuyển thành dòng đơn đặt hàng, đánh dấu việc bàn giao cho đội ngũ mua sắm. Sự kiện này được ghi nhận bằng cách liên kết dòng yêu cầu mua hàng với dòng đơn đặt hàng.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, kết nối yêu cầu mua hàng với quy trình mua sắm tiếp theo. Mốc này cần thiết để đo KPI 'Thời gian chuyển đổi từ yêu cầu mua hàng sang PO'. Lấy dữ liệu ở đâu Có thể xác định sự kiện này bằng cách tìm bản ghi trong bảng 'PurchLine' tham chiếu đến ID của 'PurchReqLine' thuộc hồ sơ yêu cầu mua hàng. Thu thập Kết nối PurchReqLine với PurchLine qua trường tham chiếu liên kết, chẳng hạn PurchReqLineRefId. Loại sự kiện inferred
	Tạo yêu cầu mua hàng	Sự kiện này đánh dấu thời điểm tạo bản ghi yêu cầu mua hàng ở trạng thái nháp. Hệ thống ghi nhận sự kiện bằng dấu thời gian tạo phần đầu yêu cầu mua hàng.
Vì sao điều này quan trọng Là điểm bắt đầu quy trình, hoạt động này rất cần thiết để đo tổng thời gian xử lý yêu cầu mua hàng và phân tích số lượng yêu cầu được xử lý mỗi ngày. Lấy dữ liệu ở đâu Hoạt động này được xác định từ trường 'createdDateTime' trong 'PurchReqTable' của từng Purchase Requisition ID mới. Thu thập Dùng dấu thời gian tạo bản ghi trong PurchReqTable. Loại sự kiện inferred
	Yêu cầu mua hàng bị từ chối	Yêu cầu mua hàng bị từ chối trong workflow phê duyệt và sẽ không được xử lý tiếp. Đây là trạng thái kết thúc không thành công của yêu cầu.
Vì sao điều này quan trọng Sự kiện kết thúc này rất quan trọng để phân tích tỷ lệ từ chối tổng thể và hiểu tác động tài chính hoặc vận hành của các yêu cầu không được chấp thuận. Lấy dữ liệu ở đâu Sự kiện được ghi rõ trong 'WorkflowTrackingStatusTable' khi workflow kết thúc với trạng thái 'Rejected', đồng thời trường trạng thái trong 'PurchReqTable' được cập nhật. Thu thập Lọc sự kiện 'Completion' của workflow có trạng thái 'Rejected' hoặc theo dõi thay đổi trạng thái trong PurchReqTable. Loại sự kiện explicit
	Yêu cầu mua hàng được phê duyệt	Yêu cầu mua hàng đã hoàn tất tất cả các bước phê duyệt bắt buộc trong workflow. Hoạt động này được ghi nhận khi phiên bản workflow kết thúc với trạng thái đã phê duyệt.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, đánh dấu kết thúc chu kỳ phê duyệt và bắt đầu giai đoạn mua sắm. Đây là sự kiện kết thúc dùng để tính KPI 'Thời gian phê duyệt yêu cầu mua hàng'. Lấy dữ liệu ở đâu Sự kiện được ghi rõ trong 'WorkflowTrackingStatusTable' khi workflow kết thúc. Trường 'Status' trong 'PurchReqTable' cũng được cập nhật thành 'Approved'. Thu thập Lọc sự kiện 'Completion' của workflow có trạng thái 'Approved' hoặc theo dõi thay đổi trạng thái trong PurchReqTable. Loại sự kiện explicit
	Bắt đầu bước phê duyệt	Một tác vụ phê duyệt được giao cho người dùng hoặc nhóm trong workflow. Đây là thời điểm bắt đầu tính thời gian chờ hoặc xử lý của người phê duyệt cụ thể.
Vì sao điều này quan trọng Hoạt động này rất quan trọng để phân tích điểm nghẽn ở từng bước phê duyệt, giúp đo thời gian chờ tại từng giai đoạn. Lấy dữ liệu ở đâu Dữ liệu được ghi trong 'WorkflowTrackingStatusTable' khi một mục công việc mới được tạo và giao trong phiên bản workflow của yêu cầu mua hàng. Thu thập Tìm sự kiện 'WorkItemCreated' hoặc sự kiện tương tự trong nhật ký lịch sử workflow của yêu cầu mua hàng cụ thể. Loại sự kiện explicit
	Đóng dòng yêu cầu mua hàng	Một dòng hàng trong yêu cầu mua hàng được xem là đã xử lý xong. Việc này thường xảy ra sau khi dòng hàng được chuyển hoàn toàn thành đơn đặt hàng.
Vì sao điều này quan trọng Hoạt động này cung cấp thông tin chi tiết về việc đáp ứng yêu cầu mua hàng, giúp xác định yêu cầu được chuyển đổi một phần hay toàn bộ thành đơn đặt hàng. Lấy dữ liệu ở đâu Có thể xác định sự kiện này từ trường trạng thái trong bảng 'PurchReqLine' của từng dòng hàng. Trạng thái cho biết hàng đã được đặt hoặc nhận đồng nghĩa với việc dòng hàng đã đóng. Thu thập Theo dõi trường trạng thái trong bảng PurchReqLine để tìm giá trị kết thúc như 'Invoiced' hoặc 'Closed'. Loại sự kiện inferred
	Rút yêu cầu mua hàng	Người tạo hoặc người dùng được ủy quyền hủy yêu cầu sau khi gửi. Thao tác này kết thúc workflow và yêu cầu.
Vì sao điều này quan trọng Theo dõi các yêu cầu bị rút giúp phát hiện vấn đề trong việc lập kế hoạch nhu cầu hoặc quy trình quá phức tạp. Dữ liệu này phục vụ dashboard 'Thông tin về yêu cầu mua hàng bị rút'. Lấy dữ liệu ở đâu Có thể xác định sự kiện này qua thay đổi trạng thái trong 'PurchReqTable' thành 'Cancelled' hoặc sự kiện 'Cancel' trong 'WorkflowTrackingStatusTable'. Thu thập Tìm thay đổi trạng thái thành 'Cancelled' trong PurchReqTable hoặc sự kiện hủy workflow. Loại sự kiện inferred
	Sửa đổi yêu cầu mua hàng	Sự kiện này xảy ra khi người dùng thu hồi yêu cầu đã gửi khỏi workflow để chỉnh sửa. Thông thường, có thể xác định hoạt động này bằng cách tìm thao tác thu hồi, sau đó là lần gửi lại.
Vì sao điều này quan trọng Theo dõi các lần sửa đổi giúp xác định công việc làm lại, yêu cầu ban đầu chưa rõ ràng và những điểm kém hiệu quả trong quy trình. Đây là dữ liệu trực tiếp phục vụ dashboard 'Tần suất sửa đổi yêu cầu mua hàng'. Lấy dữ liệu ở đâu Có thể xác định sự kiện này từ lịch sử workflow ('WorkflowTrackingStatusTable') bằng cách tìm thao tác 'Recall' hoặc 'RequestChange'. Ngoài ra, có thể dựa vào thay đổi trong trường 'modifiedDateTime' của 'PurchReqTable' sau khi gửi yêu cầu. Thu thập Tìm sự kiện thu hồi trong workflow hoặc thay đổi phiên bản bản ghi giữa các lần gửi. Loại sự kiện inferred
	Từ chối bước phê duyệt	Người phê duyệt từ chối tác vụ được giao, thường gửi yêu cầu mua hàng lại cho người tạo để chỉnh sửa. Bộ máy workflow ghi lại rõ thao tác này.
Vì sao điều này quan trọng Hoạt động này rất cần thiết để tính 'Tỷ lệ yêu cầu mua hàng bị từ chối' và xác định những giai đoạn thường xảy ra từ chối nhất, qua đó tìm ra cơ hội cải tiến quy trình. Lấy dữ liệu ở đâu Sự kiện được ghi rõ trong 'WorkflowTrackingStatusTable' khi người dùng hoàn tất một mục công việc với kết quả 'Reject'. Thu thập Tìm sự kiện 'WorkItemCompleted' có kết quả 'Reject' trong nhật ký lịch sử 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ừ Microsoft Dynamics 365

Các bước

Mở không gian làm việc Data Management: Đăng nhập Microsoft Dynamics 365 rồi mở menu Workspaces. Chọn Data management để vào trung tâm quản lý nhập và xuất dữ liệu.
Tạo dự án xuất mới: Trong không gian làm việc Data Management, nhấp ô Export. Nhập Tên nhóm riêng biệt, điền Mô tả và đặt Project category là Project. Cách này giúp sắp xếp các tác vụ trích xuất dữ liệu.
Thêm thực thể dữ liệu: Thêm các thực thể dữ liệu tiêu chuẩn cần thiết vào dự án. Nhấp Add entity, tìm từng thực thể sau rồi thêm lần lượt:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Chọn định dạng xuất: Với mỗi thực thể đã thêm, chọn Target data format, chẳng hạn CSV hoặc Excel. CSV thường phù hợp hơn về tốc độ và khả năng tương thích với các công cụ chuyển đổi dữ liệu.
Lọc dữ liệu: Chọn một thực thể rồi nhấp nút Lọc. Trong thẻ Phạm vi, chỉ định Legal entity (mã công ty) để đảm bảo bạn trích xuất dữ liệu từ đúng đơn vị kinh doanh. Bạn cũng cần lọc theo ngày ở trường Created date and time của thực thể Purchase requisition headers để giới hạn lượng dữ liệu. Nên bắt đầu với khoảng thời gian từ 3 đến 6 tháng.
Chạy tác vụ xuất: Sau khi cấu hình xong các thực thể và bộ lọc, nhấp Export trên ngăn thao tác. Hệ thống sẽ tạo gói tác vụ và bắt đầu xử lý. Bạn có thể theo dõi tiến độ trong mục Job history.
Tải gói dữ liệu: Khi tác vụ xuất chạy thành công, mở chi tiết trong Job history rồi nhấp Download package. Tệp ZIP tải xuống chứa các tệp dữ liệu riêng cho từng thực thể.
Chuyển dữ liệu thô thành nhật ký sự kiện: Các tệp đã xuất chứa dữ liệu thô từ bảng hệ thống, chưa phải nhật ký sự kiện hoàn chỉnh. Bạn cần dùng công cụ bên ngoài như Python, Power Query hoặc nền tảng ETL để kết hợp và định dạng lại dữ liệu. Các bước gồm:
- Kết hợp tệp tiêu đề và tệp dòng.
- Kết hợp dữ liệu quy trình làm việc với yêu cầu mua hàng bằng CorrelationId và RecId của tiêu đề yêu cầu mua hàng.
- Xoay các thay đổi trạng thái và sự kiện quy trình làm việc từ các bảng quy trình làm việc thành các dòng hoạt động riêng (Requisition Submitted, Approval Step Approved...).
- Tạo một dòng mới cho mỗi hoạt động, điền đúng ActivityName, EventTime và PurchaseRequisitionId.
Tính toán và ánh xạ thuộc tính: Trong quá trình chuyển đổi, ánh xạ các cột nguồn sang thuộc tính cần thiết như Người dùng và Phòng ban. Tính các thuộc tính suy ra như RequisitionTotalAmount bằng cách cộng các khoản tiền trong từng dòng. Đặt giá trị cố định cho SourceSystemId (chẳng hạn 'D365_F&O') và dùng thời điểm chạy tập lệnh làm LastDataIngestionTimestamp.
Hoàn thiện và định dạng tệp đầu ra: Đảm bảo tệp đầu ra là một tệp CSV duy nhất, trong đó mỗi dòng biểu thị một sự kiện trong quy trình. Các cột phải khớp với cấu trúc nhật ký sự kiện bắt buộc, bao gồm PurchaseRequisitionId, ActivityName và EventTime.

Cấu hình

Quyền cần thiết: Người dùng cần có vai trò bảo mật được cấp quyền truy cập không gian làm việc Data management và các thực thể dữ liệu cụ thể cần xuất. Ví dụ: vai trò Data management administrator hoặc vai trò tùy chỉnh tương đương.
Các thực thể dữ liệu chính:
- Purchase requisition headers: Cung cấp mã định danh hồ sơ chính, thời điểm tạo và trạng thái tổng thể.
- Purchase requisition lines: Chứa thông tin từng mặt hàng được yêu cầu, bao gồm số tiền và liên kết đến đơn đặt hàng.
- Workflow tracking status table: Nguồn chính ghi nhận các sự kiện workflow như gửi, phê duyệt, từ chối và thu hồi.
- Workflow work items: Cung cấp chi tiết các tác vụ được giao cho người dùng trong quá trình phê duyệt.
- Purchase order lines V2: Dùng để tìm thời điểm tạo đơn đặt hàng liên kết với một dòng yêu cầu mua hàng.
Lọc theo khoảng thời gian: Bạn cần lọc trường Created date and time trong thực thể Purchase requisition headers. Khi bắt đầu phân tích, nên chọn khoảng 3 đến 6 tháng để cân bằng giữa lượng dữ liệu và mức độ hữu ích của kết quả.
Lọc theo mã công ty: Luôn lọc theo Legal entity để tránh trích xuất dữ liệu từ công ty ngoài phạm vi hoặc công ty thử nghiệm. Cách này giúp giảm đáng kể dung lượng dữ liệu và cải thiện hiệu suất tác vụ.
Chuyển đổi dữ liệu: Phương pháp này cần một bước xử lý đáng kể bên ngoài Dynamics 365 để chuyển dữ liệu thực thể thô thành nhật ký sự kiện có cấu trúc. Hãy chuẩn bị sử dụng công cụ viết tập lệnh hoặc ETL.

Truy vấn mẫu sql

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

Các bước

Đăng ký ứng dụng Azure Active Directory: Mở cổng Azure và đăng ký ứng dụng mới. Ứng dụng này dùng để xác thực với API Dynamics 365. Ghi lại Application (client) ID và Directory (tenant) ID.
Tạo Client Secret: Trong ứng dụng vừa đăng ký trên Azure, tạo client secret mới tại mục 'Certificates & secrets'. Sao chép và lưu an toàn giá trị secret vì bạn sẽ không thể xem lại.
Cấp quyền API: Trong mục 'API permissions' của ứng dụng, thêm quyền 'Dynamics ERP'. Chọn 'Delegated permissions' và cấp Financials.ReadWrite.All hoặc quyền chỉ đọc hạn chế hơn. Sau đó, cấp quyền chấp thuận của quản trị viên.
Cài thư viện Python: Đảm bảo Python đã được cài đặt. Sau đó, cài các thư viện cần thiết bằng pip: pip install requests pandas.
Thiết lập tập lệnh Python: Sao chép tập lệnh Python được cung cấp vào một tệp, chẳng hạn extract_d365_requisitions.py. Điền các biến giữ chỗ ở đầu tập lệnh: URL Dynamics 365, Tenant ID, Client ID, Client Secret, khoảng thời gian cần lấy dữ liệu và mã công ty.
Tìm hiểu các thực thể OData: Tập lệnh truy vấn ba thực thể dữ liệu chính: PurchaseRequisitionHeaders để lấy thông tin yêu cầu mua hàng chính, PurchaseRequisitionLines để lấy chi tiết từng dòng hàng, bao gồm việc chuyển thành đơn đặt hàng, và WorkflowTrackingStatusTable để lấy các sự kiện liên quan đến workflow như gửi và phê duyệt.
Chạy tập lệnh: Chạy tập lệnh từ dòng lệnh: python extract_d365_requisitions.py. Tập lệnh sẽ xác thực, lấy dữ liệu cho từng hoạt động và tự xử lý phân trang API.
Chuyển đổi dữ liệu: Tập lệnh xử lý dữ liệu JSON thô từ các lệnh gọi API. Tập lệnh duyệt qua các bản ghi và tạo một dòng riêng cho mỗi hoạt động trong số 12 hoạt động kinh doanh, đồng thời ánh xạ các trường nguồn sang cột nhật ký sự kiện tiêu chuẩn như PurchaseRequisitionId, ActivityName và EventTime.
Kết hợp và chuẩn hóa sự kiện: Tập lệnh tập hợp tất cả sự kiện được tạo vào một danh sách, rồi chuyển thành pandas DataFrame. Tập lệnh thêm các cột có giá trị cố định như SourceSystemId và LastDataIngestionTimestamp.
Xuất sang CSV: DataFrame cuối cùng được xuất thành tệp CSV có tên d365_purchase_requisition_log.csv. Tệp này đã được định dạng để tải trực tiếp lên công cụ process mining. Kiểm tra để đảm bảo tệp dùng mã hóa UTF-8.

Cấu hình

Điều kiện tiên quyết: Bạn cần quyền truy cập gói đăng ký Azure để đăng ký ứng dụng, cùng Application (client) ID, Client Secret và Tenant ID từ Azure Active Directory. Người chạy tập lệnh cần có thông tin đăng nhập cho phép truy cập các điểm cuối OData API của Dynamics 365 Finance and Operations.
Cấu hình điểm cuối API: Tập lệnh cần URL cơ sở của môi trường Dynamics 365, thường có định dạng https://[your-environment-name].operations.dynamics.com.
Khoảng thời gian: Đặt biến START_DATE và END_DATE trong tập lệnh để xác định khoảng thời gian trích xuất. Khi bắt đầu phân tích, nên chọn khoảng từ 3 đến 6 tháng để cân bằng giữa lượng dữ liệu và giá trị thu được.
Bộ lọc công ty: Tập lệnh được thiết lập để lọc một pháp nhân cụ thể bằng biến COMPANY_ID. Để trích xuất dữ liệu của tất cả công ty, bạn có thể cần sửa bộ lọc OData và thêm cross-company=true vào tiêu đề yêu cầu.
Lưu ý về hiệu suất: Tập lệnh chỉ lấy các cột cần thiết cho nhật ký sự kiện bằng $select trong truy vấn OData, giúp cải thiện hiệu suất. Tập lệnh cũng xử lý phân trang để quản lý tập dữ liệu lớn mà không gây quá tải cho API. Với lượng dữ liệu lịch sử rất lớn, hãy chạy tập lệnh theo từng đợt với khoảng thời gian ngắn hơn.

Truy vấn mẫu python

import requests
import pandas as pd
from datetime import datetime, timezone
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Dynamics 365 environment details
D365_URL = class="hl-string">"https://[your-d365-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the data extraction window
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
COMPANY_ID = class="hl-string">"[YourCompanyLegalEntity]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">"USMF"
OUTPUT_FILENAME = class="hl-string">"d365_purchase_requisition_log.csv"


def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    auth_url = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'resource': D365_URL
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

def fetch_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_records = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }
    while entity_url:
        response = requests.get(entity_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        entity_url = data.get(class="hl-string">'@odata.nextLink')
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Acquiring access token...")
    access_token = get_access_token()
    events = []
    last_ingestion_ts = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Purchase Requisition Headers for class="hl-string">'Created' and class="hl-string">'Closed' events
    print(class="hl-string">"Fetching Purchase Requisition Headers...")
    pr_headers_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionHeaders?" 
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}" 
        fclass="hl-string">"&$select=RequisitionNumber,RequisitionStatus,CreatedDateTime,CreatedBy,RequestingDepartmentName,RequisitionTotalAmount,RequisitionUrgencyLevel"
    )
    pr_headers = fetch_data(access_token, pr_headers_url)

    for prh in pr_headers:
        case_id = prh.get(class="hl-string">'RequisitionNumber')
        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        events.append({
            class="hl-string">'PurchaseRequisitionId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'),
            class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
            class="hl-string">'RequisitionStatus': prh.get(class="hl-string">'RequisitionStatus'),
            class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
            class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
            class="hl-string">'ApprovalStep': None,
            class="hl-string">'ProcessingTime': None
        })
        class=class="hl-string">"hl-comment"># Activity: Requisition Closed
        if prh.get(class="hl-string">'RequisitionStatus') == class="hl-string">'Closed':
            class=class="hl-string">"hl-comment"># Note: We need a reliable timestamp for closure. Using CreatedDateTime as a placeholder.
            class=class="hl-string">"hl-comment"># A better source might be the last workflow approval or line closure date.
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Closed',
                class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'), class=class="hl-string">"hl-comment"># Placeholder timestamp
                class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'), class=class="hl-string">"hl-comment"># Placeholder user
                class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
                class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Workflow History for workflow-related events
    print(class="hl-string">"Fetching Workflow Tracking Status Table...")
    workflow_url = (
        fclass="hl-string">"{D365_URL}/data/WorkflowTrackingStatusTable?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE} and startswith(Context,'PurchReq')"
        fclass="hl-string">"&$select=Context,CreatedDateTime,TrackingType,User,WorkItemSubject"
    )
    workflow_items = fetch_data(access_token, workflow_url)

    for item in workflow_items:
        context_parts = item.get(class="hl-string">'Context', class="hl-string">'').split(class="hl-string">':')
        if len(context_parts) < 2:
            continue
        case_id = context_parts[1].strip()
        tracking_type = item.get(class="hl-string">'TrackingType')
        activity_map = {
            class="hl-string">'Submission': class="hl-string">'Requisition Submitted for Approval',
            class="hl-string">'Started': class="hl-string">'Approval Step Started',
            class="hl-string">'Completion': class="hl-string">'Approval Step Approved',
            class="hl-string">'Rejection': class="hl-string">'Approval Step Rejected',
            class="hl-string">'Cancellation': class="hl-string">'Requisition Withdrawn',
            class="hl-string">'Recall': class="hl-string">'Requisition Amended',
            class="hl-string">'Approved': class="hl-string">'Requisition Approved',
            class="hl-string">'Fault': class="hl-string">'Requisition Rejected'
        }
        activity_name = activity_map.get(tracking_type)
        if activity_name:
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
                class="hl-string">'User': item.get(class="hl-string">'User'),
                class="hl-string">'Department': None, class=class="hl-string">"hl-comment"># Department info is not in this entity
                class="hl-string">'RequisitionStatus': None, class=class="hl-string">"hl-comment"># Status info is not in this entity
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': item.get(class="hl-string">'WorkItemSubject'),
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Purchase Requisition Lines for PO Creation and Line Closure
    print(class="hl-string">"Fetching Purchase Requisition Lines...")
    pr_lines_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionLines?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"
        fclass="hl-string">"&$select=RequisitionNumber,PurchaseOrderNumber,IsPrepaymentRequired,LineStatus,ModifiedDateTime,ModifiedBy"
    )
    pr_lines = fetch_data(access_token, pr_lines_url)

    for prl in pr_lines:
        case_id = prl.get(class="hl-string">'RequisitionNumber')
        po_number = prl.get(class="hl-string">'PurchaseOrderNumber')
        line_status = prl.get(class="hl-string">'LineStatus')
        
        class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
        if po_number:
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': None,
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': fclass="hl-string">"PO: {po_number}",
                class="hl-string">'ProcessingTime': None
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Line Closed
        if line_status == class="hl-string">'Closed':
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Line Closed',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    if not events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    class=class="hl-string">"hl-comment"># 4. Create and format the DataFrame
    print(class="hl-string">"Formatting data...")
    df = pd.DataFrame(events)
    df[class="hl-string">'SourceSystemId'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataIngestionTimestamp'] = last_ingestion_ts

    class=class="hl-string">"hl-comment"># Fill forward missing data within each case
    df = df.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])
    df[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']] = \
        df.groupby(class="hl-string">'PurchaseRequisitionId')[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']].ffill().bfill()

    class=class="hl-string">"hl-comment"># Ensure required columns exist and are in order
    final_columns = [
        class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystemId',
        class="hl-string">'LastDataIngestionTimestamp',
        class="hl-string">'User',
        class="hl-string">'Department',
        class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionTotalAmount',
        class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalStep',
        class="hl-string">'ProcessingTime'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    class=class="hl-string">"hl-comment"># 5. Save to CSV
    df.to_csv(OUTPUT_FILENAME, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {OUTPUT_FILENAME}")

if __name__ == class="hl-string">"__main__":
    main()

Các bước

Xác nhận trình kết nối gốc Microsoft Dynamics 365 Finance có trong Power BI Desktop và người dùng được phép truy cập các thực thể dữ liệu cần thiết, lịch sử workflow, dữ liệu yêu cầu mua hàng và dữ liệu đơn đặt hàng liên quan.
Trong Power BI Desktop, chọn Get data, chọn trình kết nối Microsoft Dynamics 365 Finance rồi nhập URL phiên bản Dynamics 365 Finance. Đăng nhập bằng tài khoản được phép đọc các thực thể cần thiết. Thay [Your Dynamics 365 Finance instance URL] bằng URL phiên bản trong môi trường của bạn.
Trong Navigator, chọn các thực thể tiêu đề và dòng yêu cầu mua hàng, lịch sử workflow hoặc theo dõi workflow, người dùng và tổ chức, cùng các thực thể đơn đặt hàng cần thiết cho hệ thống của bạn. Tên thực thể và trường có thể khác nhau tùy môi trường. Xem metadata của thực thể và thay từng phần giữ chỗ trong truy vấn bằng thực thể và trường tương ứng mà hệ thống của bạn cung cấp.
Tải các thực thể đã chọn vào Power Query. Lọc dữ liệu theo pháp nhân hoặc công ty, loại chứng từ và khoảng thời gian trích xuất cần thiết. Dùng tham số [Start date] và [End date], đồng thời giữ lại các bản ghi có dấu thời gian sự kiện nằm trong khoảng đã chọn. Bao gồm cả các bản ghi được tạo trước ngày bắt đầu nếu chúng có sự kiện workflow hoặc đóng hồ sơ trong khoảng thời gian đó, để giữ đầy đủ lịch sử hồ sơ.
Chuẩn hóa mã định danh và dấu thời gian. Chuyển mã định danh yêu cầu mua hàng thành văn bản, đưa mọi dấu thời gian về cùng múi giờ UTC hoặc múi giờ kinh doanh, đồng thời giữ nguyên độ chính xác của dấu thời gian nguồn. Đảm bảo mã định danh tiêu đề yêu cầu mua hàng có mặt trên mọi dòng sự kiện. Nếu bản ghi workflow chỉ có mã định danh tương quan workflow, hãy kết hợp với tiêu đề yêu cầu mua hàng theo mối liên kết được tài liệu hóa trong môi trường của bạn.
Tạo một truy vấn sự kiện cho mỗi hoạt động cần thiết. Các truy vấn phải trả về rõ ràng các dòng cho Requisition Created, Requisition Submitted for Approval, Requisition Amended, Approval Step Started, Approval Step Approved, Approval Step Rejected, Requisition Approved, Requisition Rejected, Requisition Withdrawn, Purchase Order Created, Requisition Line Closed và Requisition Closed. Không dựa vào ProcessMind để suy ra hoạt động từ thay đổi trạng thái hoặc thứ tự sự kiện.
Với Requisition Amended, áp dụng logic thu hồi và gửi lại đã được ghi nhận trong lịch sử workflow. Nếu một thao tác thu hồi được theo sau bởi lần gửi mới, hãy tạo sự kiện sửa đổi tại thời điểm thu hồi hoặc tại thời điểm sửa đổi do thực thể nguồn cung cấp. Không tạo dòng sửa đổi chỉ dựa trên thay đổi trạng thái yêu cầu mua hàng, trừ khi hệ thống nguồn ghi nhận rõ thay đổi đó là một lần sửa đổi.
Với các sự kiện dòng hàng và đơn đặt hàng, kết hợp dòng yêu cầu mua hàng với dòng đơn đặt hàng theo mối liên kết nguồn đã được ghi nhận. Nếu nhật ký sự kiện lấy PurchaseRequisitionId làm mã hồ sơ, hãy tổng hợp các sự kiện cấp dòng hoặc giữ chúng thành các dòng riêng có cùng mã hồ sơ. Khi có, hãy giữ mã định danh dòng hàng trong các cột bổ sung, dù đây không phải thuộc tính bắt buộc.
Thêm các cột đầu ra bắt buộc: PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId và LastDataIngestionTimestamp. Thêm các cột được đề xuất: User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel và ApprovalStep. Nếu không có giá trị, hãy điền null thay vì tự tạo dữ liệu. Dùng giá trị nguồn nhất quán như Dynamics 365 Finance cho SourceSystemId.
Nối tất cả truy vấn hoạt động bằng UNION ALL, loại bỏ các dòng thiếu mã hồ sơ hoặc dấu thời gian sự kiện, rồi sắp xếp theo PurchaseRequisitionId và EventTime. Giữ các sự kiện trùng nhau nếu chúng đại diện cho các tác vụ workflow riêng hoặc các dòng yêu cầu mua hàng riêng. Chỉ loại bỏ bản ghi trùng khi xác định được chúng thực sự là dữ liệu trích xuất trùng lặp.
Kiểm tra nhật ký sự kiện tạo ra bằng các bước kiểm tra bên dưới. Xác nhận mỗi hoạt động bắt buộc đều có dòng sự kiện riêng, dấu thời gian nằm trong khoảng đã chọn và các phép kết hợp không làm nhân số sự kiện ngoài dự kiến.
Tải hoặc xuất bảng cuối cùng dưới dạng CSV hoặc định dạng nhật ký sự kiện khác được ProcessMind hỗ trợ. Ánh xạ PurchaseRequisitionId làm mã hồ sơ, ActivityName làm hoạt động và EventTime làm dấu thời gian sự kiện. Giữ SourceSystemId và LastDataIngestionTimestamp làm thuộc tính sự kiện, đồng thời giữ lại mọi thuộc tính được đề xuất nếu có.

Cấu hình

Trình kết nối và nguồn dữ liệu: Dùng trình kết nối gốc Microsoft Dynamics 365 Finance trong Power BI Desktop. Thay [Your Dynamics 365 Finance instance URL] bằng URL môi trường. Xác nhận tên thực thể và trường trong metadata của Navigator cho hệ thống cụ thể.
Thực thể cần thiết: Chọn các thực thể tiêu đề và dòng yêu cầu mua hàng, theo dõi workflow hoặc lịch sử workflow, tiêu đề và dòng đơn đặt hàng, cùng các thực thể người dùng hoặc tổ chức cần để bổ sung thông tin. Dùng phần giữ chỗ [Your entity name] cho đến khi xác nhận được tên thực thể chính xác.
Khoảng thời gian: Bắt đầu với dữ liệu từ 3 đến 6 tháng. Bao gồm tiêu đề yêu cầu mua hàng cũ hơn nếu hồ sơ có sự kiện workflow, đơn đặt hàng, đóng dòng hàng hoặc đóng yêu cầu mua hàng trong khoảng thời gian đã chọn.
Bộ lọc công ty và chứng từ: Khi phù hợp, lọc theo [Your company or legal entity filter] và [Your document type filter]. Xác nhận mã định danh yêu cầu mua hàng là duy nhất trên toàn hệ thống hay chỉ duy nhất trong từng công ty.
Phạm vi workflow: Bao gồm các thao tác gửi, thu hồi, gửi lại, giao tác vụ, phê duyệt, từ chối, rút lại, hoàn tất và hủy. Thiết lập ánh xạ thao tác và trạng thái workflow theo các giá trị được dùng trong môi trường của bạn.
Ý nghĩa sự kiện: Mỗi hoạt động phải được xuất thành một dòng sự kiện riêng. ProcessMind không suy ra sự kiện phê duyệt, sửa đổi, đóng hồ sơ hoặc chuyển đổi từ các dòng khác.
Xử lý dấu thời gian: Chuẩn hóa mọi dấu thời gian về cùng một múi giờ. Ghi rõ dấu thời gian nguồn được lưu theo UTC hay giờ địa phương của doanh nghiệp. Dùng dấu thời gian nguồn có độ chính xác cao nhất.
Làm mới tăng dần: Với các lần trích xuất định kỳ, dùng mốc thời gian dựa trên thời điểm sửa đổi hoặc sự kiện mới nhất từ nguồn, kèm một khoảng chồng lấn để lấy các bản ghi workflow đến muộn. Đối chiếu dữ liệu trong khoảng chồng lấn trước khi tải nhật ký sự kiện cuối cùng.
Hiệu suất: Lọc các thực thể nguồn trước khi kết hợp, chỉ chọn cột cần thiết, tránh tải lịch sử workflow không cần thiết và dùng query folding nếu được hỗ trợ. Trích xuất riêng tiêu đề, dòng hàng, sự kiện workflow và mối liên kết đơn đặt hàng trước khi kết hợp.
Quyền truy cập và điều kiện tiên quyết: Tài khoản cần có quyền đọc các thực thể dữ liệu Dynamics 365 Finance và dữ liệu workflow đã chọn. Xác nhận các tính năng mua sắm và workflow liên quan đã được bật, đồng thời Power BI Desktop, trình kết nối, cấu hình gateway nếu cần và chính sách bảo mật của tổ chức cho phép trích xuất.
Tiền tệ và số tiền: Xác nhận đơn vị tiền tệ của RequisitionTotalAmount. Nếu yêu cầu mua hàng có thể dùng nhiều loại tiền tệ, hãy thêm tiền tệ nguồn thành thuộc tính riêng và không tự ý quy đổi số tiền.
Xử lý giá trị null: Thuộc tính được đề xuất có thể là null nếu nguồn không lưu giá trị, quyền bảo mật hạn chế truy cập hoặc không xác định được mối liên kết. Trước khi xuất, cần kiểm tra các giá trị bắt buộc về hồ sơ, hoạt động và dấu thời gian sự kiện.

Truy vấn mẫu sql

WITH
RequisitionHeader AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [CreatedDateTimeField] AS CreatedDateTime,
        [RequisitionStatusField] AS RequisitionStatus,
        [RequisitionTotalAmountField] AS RequisitionTotalAmount,
        [UrgencyLevelField] AS UrgencyLevel,
        [RequesterUserField] AS RequesterUser,
        [DepartmentField] AS Department
    FROM [Your requisition header entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [DocumentTypeField] = '[Your document type filter]'
),
WorkflowEvents AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [WorkflowEventTimestampField] AS EventTime,
        [WorkflowActionField] AS WorkflowAction,
        [WorkflowStatusField] AS WorkflowStatus,
        [ApprovalStepField] AS ApprovalStep,
        [WorkflowUserField] AS EventUser,
        [WorkflowCorrelationField] AS WorkflowCorrelation
    FROM [Your workflow history or workflow tracking entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [WorkflowEventTimestampField] >= CAST('[Start date]' AS datetime2)
      AND [WorkflowEventTimestampField] < CAST('[End date]' AS datetime2)
),
PurchaseOrderLinks AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [PurchaseRequisitionLineIdField] AS PurchaseRequisitionLineId,
        [PurchaseOrderIdField] AS PurchaseOrderId,
        [PurchaseOrderLineIdField] AS PurchaseOrderLineId,
        [PurchaseOrderCreatedDateTimeField] AS PurchaseOrderCreatedDateTime,
        [RequisitionLineClosedDateTimeField] AS RequisitionLineClosedDateTime
    FROM [Your requisition to purchase order relationship entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
RequisitionClosure AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [RequisitionClosedDateTimeField] AS RequisitionClosedDateTime
    FROM [Your requisition closure entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
Events AS (
    SELECT
        h.PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        h.CreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionHeader h
    WHERE h.CreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Submitted for Approval' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your submission action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your recall action value]')
      AND EXISTS (
          SELECT 1
          FROM WorkflowEvents w2
          WHERE w2.PurchaseRequisitionId = w.PurchaseRequisitionId
            AND w2.WorkflowAction IN ('[Your resubmission action value]')
            AND w2.EventTime > w.EventTime
      )

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval task assigned action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval action value]')
      AND w.WorkflowStatus IN ('[Your approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]')
      AND w.WorkflowStatus IN ('[Your final approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]', '[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your final rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your withdrawal or cancellation action value]')

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        p.PurchaseOrderCreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.PurchaseOrderCreatedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.PurchaseOrderCreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Requisition Line Closed' AS ActivityName,
        p.RequisitionLineClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.RequisitionLineClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.RequisitionLineClosedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        c.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        c.RequisitionClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionClosure c
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = c.PurchaseRequisitionId
    WHERE c.RequisitionClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND c.RequisitionClosedDateTime < CAST('[End date]' AS datetime2)
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    SourceSystemId,
    LastDataIngestionTimestamp,
    [User],
    Department,
    RequisitionStatus,
    RequisitionTotalAmount,
    UrgencyLevel,
    ApprovalStep
FROM Events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

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

Mẫu này cung cấp những gì bạn cần để bắt đầu tối ưu quy trình yêu cầu mua hàng trong Purchase to Pay. Bắt đầu khám phá thông tin hữu ích ngay hôm nay.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Cải tiến quy trình yêu cầu mua hàng từ mua hàng đến thanh toán, phê duyệt nhanh hơn ngay hôm nay

Loại bỏ chậm trễ và rút ngắn 30% thời gian xử lý trên Dynamics 365.

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.

Mẫu dữ liệu yêu cầu mua hàng trong Purchase to Pay

Mẫu dữ liệu yêu cầu mua hàng trong Purchase to Pay

Các thuộc tính của yêu cầu mua hàng trong Purchase to Pay

Các hoạt động của yêu cầu mua hàng trong Purchase to Pay

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

Xuất dữ liệu bằng Data Management Framework của Dynamics 365

Các bước

Cấu hình

Truy vấn mẫu sql

Tập lệnh Python dùng Dynamics 365 OData REST API

Các bước

Cấu hình

Truy vấn mẫu python

Trích xuất bằng trình kết nối gốc Microsoft Power BI

Các bước

Cấu hình

Truy vấn mẫu sql

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

Cải tiến quy trình yêu cầu mua hàng từ mua hàng đến thanh toán, phê duyệt nhanh hơn ngay hôm nay