> Cải tiến quy trình liên tục > Quy trình xử lý đơn hàng bán trong Order to Cash > Microsoft Dynamics 365 > Mẫu dữ liệu

Mẫu dữ liệu cho quy trình xử lý đơn hàng đến thu tiền

Microsoft Dynamics 365

Thuộc tính của quy trình xử lý đơn hàng đến thu tiền(20) Các hoạt động trong quy trình xử lý đơn hàng đến thu tiền(13) Hướng dẫn trích xuất dữ liệu(2)

Mẫu dữ liệu cho quy trình xử lý đơn hàng đến thu tiền

Mẫu này cung cấp cấu trúc tổng quan về các dữ liệu cần thiết để phân tích quy trình xử lý đơn hàng đến thu tiền trong Microsoft Dynamics 365. Mẫu nêu rõ những thuộc tính quan trọng cần thu thập và các hoạt động chính cần theo dõi trong nhật ký sự kiện. Bạn cũng sẽ tìm thấy hướng dẫn thực tế để trích xuất dữ liệu hiệu quả từ hệ thống.

Các thuộc tính nên dùng để phân tích đầy đủ
Các hoạt động chính cần theo dõi trong quy trình
Hướng dẫn trích xuất dữ liệu từ Microsoft Dynamics 365

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

Thuộc tính của quy trình xử lý đơn hàng đến thu tiề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 xử lý đơn hàng đến thu tiền trong Microsoft Dynamics 365.

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

	Tên	Mô tả
	Đơn bán hàng SalesOrderNumber	Mã định danh duy nhất của từng đơn bán hàng, được dùng làm mã trường hợp chính của quy trình.
Mô tả Số đơn bán hàng là mã chữ và số duy nhất được gán cho mỗi đơn hàng của khách hàng trong Microsoft Dynamics 365. Đây là mã trường hợp chính, liên kết mọi hoạt động và sự kiện liên quan từ lúc tạo đơn đến khi đóng đơn. Trong process mining, thuộc tính này rất cần thiết để tái hiện hành trình từ đầu đến cuối của từng đơn bán hàng. Thuộc tính giúp chuyên viên phân tích theo dõi toàn bộ chuỗi hoạt động, đo thời lượng xử lý và phân tích khác biệt của từng đơn hàng, tạo nền tảng cho toàn bộ quá trình phân tích. Vì sao điều này quan trọng Mã định danh này rất quan trọng để liên kết mọi sự kiện liên quan, giúp phân tích đầy đủ vòng đời của từng đơn bán hàng từ đầu đến cuối. Lấy dữ liệu ở đâu Nằm trong bảng 'SalesTable', trường 'SalesId'. Ví dụ SO-00102345SO-00102346SO-00102347
	Hoạt động ActivityName	Tên sự kiện kinh doanh hoặc tác vụ cụ thể diễn ra tại một thời điểm trong quy trình xử lý đơn bán hàng.
Mô tả Thuộc tính này thể hiện một bước hoặc sự kiện riêng trong vòng đời đơn bán hàng, chẳng hạn 'Tạo đơn bán hàng', 'Gửi hàng' hoặc 'Nhận thanh toán'. Chuỗi hoạt động của một đơn bán hàng tạo thành luồng quy trình. Phân tích thứ tự, tần suất và sự chuyển tiếp giữa các hoạt động là trọng tâm của process mining. Việc này giúp trực quan hóa sơ đồ quy trình, xác định các biến thể phổ biến và hiếm gặp, phát hiện điểm nghẽn, đồng thời tìm ra những khâu phải làm lại hoặc không tuân thủ. Thuộc tính này là nền tảng để hiểu quy trình thực tế đang diễn ra như thế nào. Vì sao điều này quan trọng Thuộc tính này xác định các bước của quy trình, giúp tạo và trực quan hóa luồng quy trình, mục tiêu chính của process mining. Lấy dữ liệu ở đâu Về mặt khái niệm, thuộc tính này được tạo bằng cách ánh xạ các sự kiện hệ thống hoặc thay đổi trạng thái cụ thể trong những bảng như 'SalesTable' và các bảng logistics hoặc tài chính liên quan sang tên hoạt động chuẩn hóa. Ví dụ Tạo đơn bán hàngGửi hàngTạo hóa đơnNhận thanh toán
	Thời gian bắt đầu EventTime	Ngày và giờ chính xác khi một hoạt động hoặc sự kiện cụ thể diễn ra.
Mô tả Thời điểm sự kiện, hay dấu thời gian, ghi lại chính xác lúc một hoạt động diễn ra. Mỗi hoạt động trong nhật ký sự kiện đều có dấu thời gian đi kèm, tạo thành bản ghi theo trình tự thời gian của quy trình cho từng trường hợp. Thuộc tính này rất quan trọng đối với mọi phân tích thời gian trong process mining. Thuộc tính được dùng để tính thời gian xử lý giữa các hoạt động, đo tổng thời lượng của một trường hợp, phân tích thời gian chờ và xác định điểm nghẽn làm chậm quy trình. Thuộc tính cũng giúp theo dõi hiệu suất theo thời gian, chẳng hạn như thông lượng theo ngày, tuần hoặc tháng. Vì sao điều này quan trọng Dấu thời gian này rất cần thiết để tính mọi chỉ số dựa trên thời lượng, chẳng hạn như thời gian xử lý và điểm nghẽn, cũng như sắp xếp sự kiện theo trình tự thời gian. Lấy dữ liệu ở đâu Thuộc tính này được lấy từ nhiều trường ngày giờ gắn với các giao dịch cụ thể, chẳng hạn 'SalesTable.CreatedDateTime' khi tạo đơn hàng hoặc ngày hạch toán nhật ký thanh toán khi nhận thanh toán. Ví dụ 2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
	Hệ thống nguồn SourceSystem	Xác định hệ thống thông tin cung cấp dữ liệu.
Mô tả Thuộc tính này cho biết ứng dụng nguồn đã ghi lại dữ liệu sự kiện. Trong trường hợp này, ứng dụng thường là 'Microsoft Dynamics 365'. Khi chỉ phân tích dữ liệu từ một hệ thống, thuộc tính này có thể có vẻ thừa. Nhưng khi gộp dữ liệu từ nhiều hệ thống, chẳng hạn CRM riêng hoặc hệ thống quản lý kho, thuộc tính này rất quan trọng. Nó giúp theo dõi nguồn gốc dữ liệu và xử lý sự cố trích xuất bằng cách xác định bản ghi đến từ đâu. Vì sao điều này quan trọng Thuộc tính này cung cấp thông tin quan trọng về nguồn gốc dữ liệu, nhất là khi tích hợp dữ liệu từ nhiều hệ thống, đồng thời giúp theo dõi rõ nguồn gốc dữ liệu. Lấy dữ liệu ở đâu Đây là giá trị cố định, thường được thêm trong quá trình chuyển đổi dữ liệu để ghi nhãn nguồn gốc của tập dữ liệu. Ví dụ Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
	Thời điểm cập nhật dữ liệu gần nhất LastDataUpdate	Dấu thời gian cho biết lần gần nhất dữ liệu được làm mới hoặc trích xuất từ hệ thống nguồn.
Mô tả Thuộc tính này ghi lại ngày giờ lần gần nhất dữ liệu được lấy từ Microsoft Dynamics 365. Nhờ đó, bạn biết dữ liệu đang phân tích được cập nhật đến thời điểm nào. Khi phân tích quy trình, cần biết dữ liệu mới đến đâu để đưa ra quyết định phù hợp. Dấu thời gian này cho biết chính xác lần cập nhật gần nhất, giúp người dùng tin tưởng rằng kết luận dựa trên thông tin hiện hành. Vì sao điều này quan trọng Thuộc tính này giúp người dùng biết dữ liệu mới đến đâu, yếu tố quan trọng để kết quả process mining có ý nghĩa và chính xác. Lấy dữ liệu ở đâu Giá trị này được tạo khi trích xuất dữ liệu và thêm vào từng bản ghi trong quá trình nạp dữ liệu. Ví dụ 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Giá trị đơn hàng OrderValue	Tổng giá trị tiền tệ của đơn hàng bán.
Mô tả Thuộc tính này thể hiện tổng giá trị tài chính của đơn hàng bán, bao gồm tất cả mặt hàng, thuế và phí. Đây là chỉ số tài chính quan trọng gắn với từng trường hợp. Giá trị đơn hàng rất hữu ích khi phân tích quy trình theo giá trị. Bạn có thể phân nhóm để xem đơn hàng giá trị cao có được xử lý khác hoặc bị chậm nhiều hơn đơn hàng giá trị thấp hay không. Từ đó, bạn ưu tiên cải tiến những trường hợp có ảnh hưởng tài chính lớn nhất và xây dựng bảng điều khiển như 'Giá trị đơn hàng bán theo phân khúc'. Vì sao điều này quan trọng Cho phép phân nhóm quy trình theo giá trị tài chính, giúp ưu tiên cải tiến đơn hàng giá trị cao và hiểu rõ chi phí phát sinh khi quy trình đi lệch chuẩn. Lấy dữ liệu ở đâu Nằm trong dữ liệu phần đầu đơn hàng bán. Xem tài liệu Microsoft Dynamics 365 để biết chính xác bảng và trường, thường được tính từ số tiền trên các dòng đơn hàng. Ví dụ 5250.7512300.00899.50
	Kênh bán hàng SalesChannel	Kênh tiếp nhận đơn hàng bán, chẳng hạn Web, bán hàng trực tiếp hoặc đối tác.
Mô tả Kênh bán hàng cho biết khách hàng đã đặt hàng qua đâu. Đó có thể là trang thương mại điện tử, đội ngũ bán hàng trực tiếp, cửa hàng bán lẻ, tổng đài hoặc mạng lưới đối tác. Trong Dynamics 365, chiều dữ liệu này thường được cấu hình theo nhu cầu kinh doanh. Phân tích quy trình theo kênh bán hàng giúp phát hiện khác biệt về hiệu suất giữa các kênh. Chẳng hạn, đơn hàng qua web có thể được xử lý nhanh và tự động hơn đơn hàng qua điện thoại. Từ đó, bạn có thể tối ưu quy trình và phân bổ tài nguyên phù hợp cho từng kênh, đồng thời hỗ trợ các bảng điều khiển như 'Giá trị đơn hàng bán theo phân khúc'. Vì sao điều này quan trọng Cho phép so sánh hiệu suất giữa các kênh bán hàng, qua đó phát hiện điểm kém hiệu quả hoặc cách làm tốt tùy theo cách đơn hàng được tạo. Lấy dữ liệu ở đâu Thông tin này thường được lưu trong phần đầu đơn hàng bán. Xem tài liệu Microsoft Dynamics 365 để biết trường cụ thể. Ví dụ WebTrực tiếpĐối tácBán lẻ
	Ngày giao hàng đã xác nhận ConfirmedDeliveryDate	Ngày giao hàng công ty đã xác nhận và cam kết với khách hàng.
Mô tả Ngày giao hàng đã xác nhận là ngày công ty bán hàng cam kết giao hàng cho khách. Ngày này được thiết lập sau khi hoàn tất các bước kiểm tra nội bộ, chẳng hạn kiểm tra hàng tồn kho và lịch sản xuất. Thuộc tính này cần thiết để tính KPI 'Tỷ lệ đáp ứng ngày giao hàng' dựa trên cam kết vận hành. Đây là mốc nội bộ thực tế hơn yêu cầu ban đầu của khách hàng để đánh giá giao hàng đúng hạn. Phân tích chênh lệch so với ngày này giúp xác định vấn đề nội bộ trong logistics và xử lý đơn hàng. Vì sao điều này quan trọng Thể hiện cam kết của công ty với khách hàng, là mốc nội bộ quan trọng để đo độ tin cậy trong xử lý đơn hàng và hiệu suất vận hành. Lấy dữ liệu ở đâu Nằm trong dữ liệu dòng đơn hàng bán, thường ở bảng 'SalesLine' với tên trường như 'ConfirmedDlv'. Ví dụ 2023-05-122023-06-012023-05-28
	Ngày giao hàng khách yêu cầu RequestedDeliveryDate	Ngày khách hàng yêu cầu giao đơn hàng.
Mô tả Thuộc tính này lưu ngày khách hàng yêu cầu nhận hàng lần đầu. Ngày được ghi nhận khi tạo đơn hàng và là mốc cơ sở để đo hiệu suất giao hàng theo kỳ vọng của khách hàng. Đây là dữ liệu đầu vào quan trọng cho bảng điều khiển 'Mức độ đáp ứng ngày giao hàng'. So sánh 'RequestedDeliveryDate' với 'ConfirmedDeliveryDate' và ngày thực tế 'Goods Delivered' giúp bạn biết tổ chức đáp ứng kỳ vọng của khách hàng đến đâu. Chênh lệch lớn có thể cho thấy vấn đề trong khâu lập kế hoạch, tồn kho hoặc logistics. Vì sao điều này quan trọng Thể hiện kỳ vọng giao hàng của khách hàng, làm mốc cơ sở để đo sự hài lòng và hiệu suất giao hàng đúng hạn. Lấy dữ liệu ở đâu Nằm trong bảng 'SalesTable', thường có tên 'DeliveryDate' hoặc tên tương tự. Ví dụ 2023-05-102023-06-012023-05-25
	Tên khách hàng CustomerName	Tên khách hàng đã đặt đơn hàng bán.
Mô tả Thuộc tính này chứa tên pháp lý của khách hàng gắn với đơn hàng bán. Giá trị được lấy bằng cách liên kết số tài khoản khách hàng trên đơn hàng với dữ liệu khách hàng chính. Phân tích quy trình theo khách hàng là cách cơ bản để hiểu hành vi và mức độ dịch vụ của từng khách hàng. Bạn có thể xác định khách hàng nào thường bị chậm, có tỷ lệ làm lại cao hoặc đi theo luồng quy trình khác thông lệ. Thông tin này rất cần thiết để cải thiện sự hài lòng của khách hàng và quản lý hiệu quả các tài khoản trọng yếu. Vì sao điều này quan trọng Hỗ trợ phân tích theo từng khách hàng để tìm ra xu hướng, chậm trễ hoặc vấn đề riêng, từ đó cải thiện trực tiếp sự hài lòng của khách hàng. Lấy dữ liệu ở đâu Tra cứu trong 'CustTable' bằng trường 'CustAccount' của 'SalesTable'. Ví dụ Contoso LtdAdatum CorporationFabrikam Inc.
	Có làm lại IsRework	Giá trị đúng/sai cho biết đơn hàng bán có phải làm lại hay không, chẳng hạn có hoạt động được thực hiện lặp lại.
Mô tả Thuộc tính được tính toán này xác định các trường hợp đi lệch khỏi luồng quy trình trực tiếp, tức 'luồng chuẩn'. Hệ thống phát hiện việc làm lại bằng cách tìm chuỗi hoạt động cho thấy một bước đã được thực hiện lại, chẳng hạn đơn hàng bị hủy xác nhận rồi xác nhận lại, hoặc hàng đã được lấy ra rồi trả về kho. Đánh dấu các trường hợp phải làm lại là việc cần thiết để tính KPI 'Tỷ lệ làm lại đơn hàng bán'. Chuyên viên phân tích có thể nhanh chóng lọc và điều tra các luồng quy trình kém hiệu quả để tìm nguyên nhân gốc rễ, có thể là lỗi nhập liệu, vấn đề tín dụng hoặc sự cố tồn kho. Giảm việc làm lại là mục tiêu chính của nhiều dự án cải tiến quy trình. Vì sao điều này quan trọng Giúp đo mức độ kém hiệu quả của quy trình bằng cách đánh dấu các trường hợp phải lặp lại bước, từ đó phân tích có trọng tâm để giảm lãng phí và chậm trễ. Lấy dữ liệu ở đâu Công cụ process mining tính giá trị này bằng cách phân tích chuỗi hoạt động của từng trường hợp. Ví dụ, nếu phát hiện chuỗi như (A -> B -> C -> B), trường hợp đó sẽ được đánh dấu là phải làm lại. Ví dụ truefalse
	Giao hàng đúng hạn OnTimeDelivery	Giá trị đúng/sai cho biết hàng được giao vào hoặc trước ngày giao hàng đã xác nhận.
Mô tả Thuộc tính được tính toán này so sánh dấu thời gian của hoạt động 'Goods Delivered' với 'ConfirmedDeliveryDate' của từng đơn hàng bán. Giá trị là 'true' nếu hàng được giao đúng hạn hoặc sớm hơn, và 'false' nếu giao trễ. Cờ này là cơ sở để tính KPI 'Tỷ lệ đáp ứng ngày giao hàng'. Nó giúp đơn giản hóa việc phân tích bằng cách cho phép lọc và tổng hợp đơn hàng giao đúng hạn hoặc trễ. Nhờ đó, bạn nhanh chóng xác định các yếu tố liên quan đến giao hàng trễ, chẳng hạn sản phẩm, khách hàng, khu vực hoặc phương thức vận chuyển cụ thể. Vì sao điều này quan trọng Đo trực tiếp hiệu suất xử lý đơn hàng so với cam kết, yếu tố quan trọng để theo dõi sự hài lòng của khách hàng và độ tin cậy của chuỗi cung ứng. Lấy dữ liệu ở đâu Được tính bằng cách so sánh 'EventTime' của hoạt động 'Goods Delivered' với thuộc tính 'ConfirmedDeliveryDate'. Công thức: (Dấu thời gian 'Goods Delivered' <= ConfirmedDeliveryDate). Ví dụ truefalse
	Mã mặt hàng ItemNumber	Mã định danh duy nhất của sản phẩm hoặc dịch vụ trên đơn hàng bán.
Mô tả Mã mặt hàng xác định sản phẩm cụ thể được bán. Vì một đơn hàng bán có thể gồm nhiều sản phẩm, thuộc tính này thường gắn với dữ liệu sự kiện ở cấp dòng hàng. Phân tích quy trình theo sản phẩm giúp phát hiện vấn đề riêng của từng mặt hàng. Chẳng hạn, một số sản phẩm có thể mất nhiều thời gian xử lý hơn, có tỷ lệ làm lại cao hơn hoặc thường bị giữ tín dụng hơn. Nhờ đó, bạn có thể cải tiến có trọng tâm việc quản lý tồn kho, thiết lập dữ liệu sản phẩm hoặc xử lý đơn hàng cho từng mặt hàng. Vì sao điều này quan trọng Cho phép phân tích ở cấp sản phẩm, giúp phát hiện mặt hàng nào liên quan đến chậm trễ, làm lại hoặc các điểm kém hiệu quả khác trong quy trình. Lấy dữ liệu ở đâu Nằm trong bảng 'SalesLine', trường 'ItemId'. Ví dụ PROD-00123PROD-00548SVC-00045
	Ngày đến hạn thanh toán PaymentDueDate	Ngày khách hàng phải thanh toán hóa đơn.
Mô tả Ngày đến hạn thanh toán được tính dựa trên ngày lập hóa đơn và điều khoản thanh toán đã thỏa thuận với khách hàng. Ngày này được ghi trên hóa đơn khách hàng. Thuộc tính này là dữ liệu cơ sở cho phân tích 'Tuân thủ hạn thanh toán' và KPI 'Tỷ lệ thanh toán đúng hạn'. So sánh 'PaymentDueDate' với ngày thực tế 'Payment Received' giúp doanh nghiệp xác định khoản thanh toán trễ, phân tích hành vi thanh toán theo phân khúc khách hàng và chủ động cải thiện dòng tiền, giảm số ngày thu tiền bình quân (DSO). Vì sao điều này quan trọng Đây là mốc để đo hiệu suất thanh toán, rất quan trọng khi phân tích dòng tiền và quản lý hiệu quả các khoản phải thu. Lấy dữ liệu ở đâu Nằm trong bảng 'CustInvoiceJour', trường 'DueDate'. Ví dụ 2023-05-302023-06-152023-06-30
	Phương thức vận chuyển ShippingMethod	Phương thức hoặc đơn vị vận chuyển hàng đến khách hàng.
Mô tả Thuộc tính này cho biết dịch vụ vận chuyển được dùng để giao hàng, chẳng hạn 'Vận chuyển đường bộ', 'Vận tải hàng không' hoặc tên một đơn vị vận chuyển cụ thể. Phương thức được chọn khi xử lý đơn hàng, dựa trên lựa chọn của khách hàng, chi phí và tốc độ giao hàng. Chiều dữ liệu này rất cần thiết cho bảng điều khiển 'Hiệu suất phương thức vận chuyển'. Phân tích thời gian xử lý từ 'Goods Packed' đến 'Goods Delivered' theo phương thức vận chuyển giúp xác định đơn vị nào giao nhanh hơn, đáng tin cậy hơn hoặc thường bị chậm. Nhờ đó, bạn có thể lập kế hoạch logistics và chọn đơn vị vận chuyển phù hợp hơn. Vì sao điều này quan trọng Cho phép phân tích hiệu suất của các đơn vị và phương thức vận chuyển, giúp tối ưu logistics về chi phí, tốc độ và độ tin cậy. Lấy dữ liệu ở đâu Thông tin này thường được lưu trong phần đầu đơn hàng bán hoặc hồ sơ xử lý đơn hàng liên quan. Xem tài liệu Microsoft Dynamics 365. Ví dụ FedEx GroundUPS Next Day AirDHL Express
	Quốc gia CountryRegion	Quốc gia trong địa chỉ giao hàng của khách hàng.
Mô tả Thuộc tính này cho biết quốc gia nhận hàng của đơn hàng bán. Giá trị được lấy từ thông tin địa chỉ giao hàng của khách hàng lưu trong Dynamics 365. Phân tích hiệu suất quy trình theo quốc gia giúp phát hiện khác biệt giữa các khu vực. Đơn hàng quốc tế có thể cần thêm bước như thông quan, khiến thời gian xử lý kéo dài. Phân tích này giúp bạn hiểu và tối ưu logistics cho từng thị trường địa lý. Vì sao điều này quan trọng Hỗ trợ phân tích theo khu vực địa lý, giúp phát hiện điểm nghẽn, vấn đề tuân thủ hoặc khác biệt về hiệu suất trong chuỗi cung ứng. Lấy dữ liệu ở đâu Lấy từ địa chỉ giao hàng của khách hàng được liên kết với đơn hàng bán. Thông tin quốc gia thường nằm trong bảng 'LogisticsPostalAddress', được nối qua liên kết địa chỉ giao hàng trên 'SalesTable'. Ví dụ USADEUCANGBR
	Tên người dùng UserName	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 cụ thể chịu trách nhiệm thực hiện một tác vụ, chẳng hạn xác nhận đơn hàng hoặc tạo hóa đơn. Thuộc tính này thường liên kết với ID người dùng trong Microsoft Dynamics 365. Phân tích hiệu suất theo người dùng giúp xác định nhu cầu đào tạo, ghi nhận người làm tốt và phân bổ khối lượng công việc hợp lý. Đây cũng là thông tin cần thiết cho việc tuân thủ và kiểm toán, giúp xác định rõ trách nhiệm của từng hành động trong quy trình. Vì sao điều này quan trọng Cho phép phân tích hiệu suất quy trình theo từng người hoặc nhóm, qua đó xác định cơ hội đào tạo, tình trạng phân bổ công việc chưa cân đối và điểm nghẽn liên quan đến tài nguyên. Lấy dữ liệu ở đâu Lấy từ các trường ID người dùng như 'CreatedBy' hoặc 'ModifiedBy' trong nhiều bảng giao dịch, sau đó nối với bảng người dùng chính (ví dụ: 'UserInfo') để lấy họ tên đầy đủ. Ví dụ Alice JohnsonRobert BrownQuản trị viên hệ thống
	Thanh toán đúng hạn OnTimePayment	Giá trị đúng/sai cho biết khoản thanh toán được nhận vào hoặc trước ngày đến hạn.
Mô tả Thuộc tính được tính toán này so sánh dấu thời gian của hoạt động 'Payment Received' với 'PaymentDueDate'. Giá trị là 'true' nếu thanh toán đúng hạn và 'false' nếu thanh toán trễ. Cờ này là thành phần cốt lõi để tính KPI 'Tỷ lệ thanh toán đúng hạn'. Nó giúp nhanh chóng phân nhóm khách hàng thành nhóm thanh toán đúng hạn và nhóm thanh toán trễ. Phân tích này hỗ trợ xây dựng chính sách tín dụng, chiến lược thu hồi công nợ và quản lý quan hệ khách hàng bằng cách xác định những khách hàng thường xuyên trả chậm. Vì sao điều này quan trọng Đo hành vi thanh toán của khách hàng so với điều khoản đã thỏa thuận, yếu tố cơ bản để quản lý dòng tiền và đánh giá rủi ro tín dụng. Lấy dữ liệu ở đâu Được tính bằng cách so sánh 'EventTime' của hoạt động 'Payment Received' với thuộc tính 'PaymentDueDate'. Công thức: (Dấu thời gian 'Payment Received' <= PaymentDueDate). Ví dụ truefalse
	Thời điểm kết thúc EndTime	Ngày giờ chính xác khi một hoạt động hoàn tất.
Mô tả Dấu thời gian End Time ghi lại thời điểm một hoạt động kết thúc. Nếu có dữ liệu này, bạn có thể đo thời lượng hoạt động chính xác hơn so với cách suy ra từ thời điểm bắt đầu hoạt động tiếp theo. Khi phân tích, có cả thời điểm bắt đầu và kết thúc giúp tính chính xác 'Thời gian xử lý' của từng hoạt động, đồng thời phân biệt với 'Thời gian chờ' giữa các hoạt động. Nhờ đó, bạn xác định được tác vụ nào tốn nhiều thời gian và bước nào có thời gian chờ kéo dài. Vì sao điều này quan trọng Giúp tính chính xác thời gian xử lý của từng hoạt động, phân biệt thời gian làm việc thực tế với thời gian chờ. Lấy dữ liệu ở đâu Tương tự Start Time, giá trị này được lấy từ nhiều trường ngày giờ khác nhau. Đó có thể là trường 'ModifiedDateTime' hoặc dấu thời gian cập nhật trạng thái cụ thể trong các bảng như 'SalesTable' hay 'WHSLoadTable'. Ví dụ 2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
	Trạng thái đơn hàng bán SalesOrderStatus	Trạng thái hiện tại của đơn hàng bán tại thời điểm trích xuất dữ liệu.
Mô tả Thuộc tính này thể hiện trạng thái tổng thể của đơn hàng bán, chẳng hạn 'Đơn hàng đang mở', 'Đã lập hóa đơn', 'Đã hủy' hoặc 'Đã giao'. Đây là trạng thái tổng hợp được lưu trong phần đầu đơn hàng bán. Nhật ký hoạt động cho thấy quy trình diễn ra như thế nào, còn trạng thái cuối cùng hữu ích khi lọc và phân nhóm dữ liệu. Chuyên viên phân tích có thể dễ dàng lọc tất cả đơn hàng đang mở để xem khối lượng công việc hiện tại, hoặc tách đơn hàng đã hoàn tất thành công khỏi đơn hàng bị hủy để tìm hiểu nguyên nhân. Vì sao điều này quan trọng Cho biết trạng thái đơn hàng tại một thời điểm, giúp lọc đơn đang mở, đã đóng hoặc đã hủy. Thông tin này hữu ích cho việc quản lý khối lượng công việc và phân tích kết quả. Lấy dữ liệu ở đâu Nằm trong bảng 'SalesTable', trường 'SalesStatus'. Ví dụ Đơn hàng còn thiếu hàngĐã giaoĐã lập hóa đơnĐã hủy

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

Các hoạt động trong quy trình xử lý đơn hàng đến thu tiền

Đây là các bước chính 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 xử lý đơn hàng bán.

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

	Hoạt động	Mô tả
	Đóng đơn hàng	Trạng thái cuối cùng của đơn bán hàng đã xử lý thành công, cho biết đơn đã được giao đầy đủ, lập hóa đơn và không còn giao dịch nào khác dự kiến phát sinh. Đây là dấu mốc hoàn tất quy trình thành công.
Vì sao điều này quan trọng Hoạt động này là điểm kết thúc chính của các trường hợp đã hoàn tất thành công. Đây là dữ liệu cần thiết để tính thời gian xử lý từ đầu đến cuối và thông lượng. Lấy dữ liệu ở đâu Suy ra từ các trường trạng thái trên SalesTable. Đơn hàng được xem là đã đóng khi 'Sales status' là 'Invoiced' và trạng thái các dòng hàng cũng là 'Invoiced'. Thu thập Suy ra từ các trường trạng thái trên SalesTable khi chuyển thành 'Invoiced'. Dấu thời gian thường là ngày giao dịch liên quan cuối cùng, chẳng hạn ngày lập hóa đơn hoặc nhận thanh toán. Loại sự kiện inferred
	Gửi hàng	Sự kiện này cho biết hàng đã đóng gói được gửi đi và rời khỏi kho. Trong Dynamics 365, bước này được xác nhận chính thức khi hạch toán phiếu đóng gói.
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 quá trình hoàn tất đơn hàng nội bộ và bắt đầu giai đoạn giao hàng. Dấu thời gian này rất cần thiết để tính hiệu suất giao hàng đúng hạn. Lấy dữ liệu ở đâu Đây là sự kiện rõ ràng, được ghi nhận trực tiếp từ ngày và giờ hạch toán của nhật ký phiếu đóng gói (CustPackingSlipJour). Thu thập Ghi nhận dấu thời gian hạch toán của nhật ký phiếu đóng gói. Loại sự kiện explicit
	Nhận thanh toán	Hoạt động này cho biết khoản thanh toán của khách hàng cho hóa đơn đã được nhận và ghi nhận. Sự kiện diễn ra trong mô-đun Accounts Receivable và được liên kết với hóa đơn ban đầu.
Vì sao điều này quan trọng Đây là cột mốc quan trọng để phân tích chu kỳ chuyển đổi tiền mặt. Sự kiện này cần thiết để đo KPI 'Tỷ lệ thanh toán đúng hạn' và xác định chậm trễ trong quá trình thu tiền. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận trực tiếp từ mô-đun Accounts Receivable. Hệ thống lấy sự kiện từ ngày giao dịch thanh toán của khách hàng (CustSettlement), giao dịch này tất toán giao dịch hóa đơn (CustTrans). Thu thập Lấy ngày tất toán từ bảng CustSettlement, rồi liên kết lại với hóa đơn và đơn bán hàng. Loại sự kiện explicit
	Tạo đơn bán hàng	Sự kiện này đánh dấu thời điểm nhân viên bán hàng hoặc kênh tự động tạo đơn bán hàng trong hệ thống. Hệ thống ghi nhận sự kiện khi một bản ghi mới được tạo và lưu vào bảng đơn bán hàng chính.
Vì sao điều này quan trọng Đây là điểm bắt đầu chung cho mọi trường hợp xử lý đơn bán hàng. Dấu thời gian ban đầu này cần thiết để tính tổng thời gian xử lý đơn và phân tích thông lượng. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận trực tiếp từ trường 'Created date and time' trên bản ghi tiêu đề SalesTable trong Microsoft Dynamics 365. Thu thập Đọc dấu thời gian tạo từ thực thể SalesTable. Loại sự kiện explicit
	Tạo hóa đơn	Cho biết hóa đơn bán hàng cho hàng hóa hoặc dịch vụ đã giao được tạo và hạch toán. Đây là giao dịch tài chính cốt lõi, chính thức ghi nhận khoản nợ của khách hàng.
Vì sao điều này quan trọng Hoạt động này đánh dấu thời điểm bắt đầu giai đoạn thanh toán tài chính của quy trình. Thời gian từ lúc gửi hàng đến lúc tạo hóa đơn rất quan trọng đối với KPI 'Thời gian lập hóa đơn' và ảnh hưởng đến dòng tiền. Lấy dữ liệu ở đâu Đây là giao dịch tài chính được ghi nhận trực tiếp. Sự kiện được lấy từ ngày và giờ hạch toán của nhật ký hóa đơn bán hàng (CustInvoiceJour). Thu thập Ghi nhận dấu thời gian hạch toán của nhật ký hóa đơn bán hàng. Loại sự kiện explicit
	Xác nhận đơn hàng	Hoạt động này đánh dấu việc xác nhận chính thức đơn bán hàng, cam kết giao hàng hóa hoặc dịch vụ đã nêu. Trong Dynamics 365, người dùng thực hiện thao tác này và hệ thống tạo nhật ký xác nhận.
Vì sao điều này quan trọng Xác nhận là cột mốc quan trọng, chính thức bắt đầu quá trình hoàn tất đơn hàng. Đo thời gian từ lúc tạo đến lúc xác nhận giúp đánh giá hiệu quả xử lý của bộ phận bán hàng. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận trực tiếp từ ngày hạch toán của nhật ký xác nhận đơn bán hàng (SalesConfirmJour). Có thể liên kết dấu thời gian này với SalesTable. Thu thập Ghi nhận dấu thời gian hạch toán của nhật ký xác nhận đơn bán hàng. Loại sự kiện explicit
	Chuyển đơn đến kho	Đánh dấu thời điểm đơn bán hàng được chuyển chính thức đến kho để lấy hàng và vận chuyển. Đây là bước riêng trong các môi trường sử dụng mô-đun Warehouse Management (WMS).
Vì sao điều này quan trọng Hoạt động này đánh dấu ranh giới giữa xử lý đơn hàng và hoàn tất đơn hàng tại kho. Phân tích thời gian chờ chuyển đơn đến kho có thể giúp phát hiện vấn đề về lập kế hoạch nguồn lực hoặc tích hợp hệ thống. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận trực tiếp từ các bản ghi chuyển hàng đến kho (WHSLoadTable, WHSShipmentTable) liên kết với đơn bán hàng. Thu thập Ghi nhận dấu thời gian tạo của chuyến hàng hoặc lô hàng tương ứng trong kho. Loại sự kiện explicit
	Đóng gói hàng hóa	Hoạt động này đánh dấu việc hoàn tất đóng gói, khi các mặt hàng đã lấy được gom lại và chuẩn bị để vận chuyển. Trong D365, bước này có thể diễn ra cùng lúc với việc tạo phiếu đóng gói.
Vì sao điều này quan trọng Thời gian từ lúc lấy hàng đến lúc đóng gói có thể cho thấy điểm nghẽn tại các khu vực đóng gói. Đây là một quy trình con quan trọng trong tổng thời gian hoàn tất đơn hàng. Lấy dữ liệu ở đâu Có thể ghi nhận trực tiếp sự kiện này khi hoàn tất đóng gói kiện hàng trong mô-đun WMS, hoặc suy ra từ lúc tạo nhật ký phiếu đóng gói (CustPackingSlipJour), thường là dấu mốc kết thúc đóng gói. Thu thập Suy ra từ thời điểm hoàn tất công việc đóng gói hoặc ngày tạo nhật ký phiếu đóng gói. Loại sự kiện inferred
	Giao hàng thành công	Cho biết lô hàng đã được giao thành công đến địa chỉ khách hàng chỉ định. Thông tin này thường được cập nhật từ hệ thống của đơn vị vận chuyển bên ngoài hoặc xác nhận thủ công.
Vì sao điều này quan trọng Hoạt động này rất quan trọng để đo KPI 'Tỷ lệ giao hàng đúng hẹn' và hiểu thời gian xử lý thực tế mà khách hàng trải qua. Hoạt động này cũng giúp đánh giá hiệu suất của đơn vị vận chuyển. Lấy dữ liệu ở đâu D365 tiêu chuẩn không ghi nhận bước này dưới dạng sự kiện riêng. Thông thường, sự kiện được suy ra từ bản cập nhật của hệ thống tích hợp với đơn vị vận chuyển hoặc từ cập nhật trạng thái thủ công trên đơn bán hàng hay bản ghi lô hàng. Thu thập Suy ra từ dữ liệu do hệ thống tích hợp với đơn vị vận chuyển cung cấp hoặc từ trường trạng thái được cập nhật thủ công. Loại sự kiện inferred
	Giữ hàng tồn kho	Sự kiện này cho biết hàng tồn kho cần cho các dòng đơn bán hàng đã được giữ trong hệ thống, theo cách thủ công hoặc tự động. Nhờ đó, hàng hóa sẵn sàng để lấy và hoàn tất đơn.
Vì sao điều này quan trọng Theo dõi thời điểm giữ hàng giúp phân tích độ trễ giữa lúc xác nhận đơn và lúc bắt đầu hoạt động kho. Đây là chỉ số quan trọng để tính KPI 'Thời gian phân bổ hàng tồn kho'. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ lúc tạo hoặc cập nhật bản ghi giao dịch hàng tồn kho (InventTrans) liên kết với các dòng đơn bán hàng, khi trạng thái cho biết hàng đã được giữ, chẳng hạn 'On order' hoặc 'Reserved physical'. Thu thập Suy ra từ dấu thời gian các giao dịch hàng tồn kho (InventTrans) của đơn hàng được đánh dấu là đã giữ. Loại sự kiện inferred
	Hoàn tất kiểm tra tín dụng	Cho biết việc kiểm tra tín dụng của khách hàng gắn với đơn bán hàng đã hoàn tất. Đây có thể là bước kiểm tra tự động của hệ thống hoặc kiểm tra thủ công, thường dẫn đến thay đổi trạng thái tín dụng của đơn hàng.
Vì sao điều này quan trọng Phân tích thời lượng và kết quả kiểm tra tín dụng giúp xác định điểm nghẽn trong quy trình phê duyệt đơn hàng. Đơn hàng thường xuyên bị giữ lại hoặc mất nhiều thời gian phê duyệt có thể làm chậm đáng kể việc hoàn tất đơn. Lấy dữ liệu ở đâu Thông tin này thường được suy ra từ các thay đổi trạng thái liên quan đến quản lý tín dụng trên SalesTable, chẳng hạn như chuyển từ 'On hold' kèm lý do tín dụng sang 'Open'. Nếu sử dụng mô-đun nâng cao, thông tin cũng có thể được ghi trong các bảng quản lý tín dụng. Thu thập Suy ra từ lịch sử thay đổi trạng thái trên SalesTable hoặc các bảng liên quan đến giữ đơn vì tín dụng. Loại sự kiện inferred
	Hủy đơn hàng	Sự kiện này cho biết đơn bán hàng bị hủy trước khi được giao đầy đủ và lập hóa đơn. Đây là một điểm kết thúc khác, không thành công, của quy trình.
Vì sao điều này quan trọng Theo dõi đơn bị hủy giúp xác định nguyên nhân mất doanh số hoặc lỗi quy trình. Phân tích thời điểm và lý do hủy đơn có thể giúp cải thiện quy trình. Lấy dữ liệu ở đâu Suy ra từ trường 'Sales status' trên SalesTable khi chuyển thành 'Canceled'. Dấu thời gian là lúc hệ thống ghi nhận thay đổi trạng thái này. Thu thập Suy ra từ trường trạng thái trên SalesTable khi chuyển thành 'Canceled'. Loại sự kiện inferred
	Lấy hàng	Cho biết việc lấy tất cả mặt hàng trong đơn từ vị trí lưu kho đã hoàn tất. Thông thường, hệ thống ghi nhận sự kiện này khi nhân viên kho hoàn tất danh sách lấy hàng hoặc lệnh công việc trong mô-đun WMS.
Vì sao điều này quan trọng Theo dõi thời điểm hoàn tất lấy hàng là việc cần thiết để phân tích hiệu quả hoạt động kho. Chậm trễ ở bước này ảnh hưởng trực tiếp đến tổng thời gian giao hàng. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận trực tiếp trong mô-đun Warehouse Management. Hệ thống lấy dấu thời gian hoàn tất công việc kho (WHSWorkTable) liên quan đến việc lấy hàng cho đơn bán hàng. Thu thập Ghi nhận dấu thời gian khi trạng thái 'Work' của công việc lấy hàng chuyển thành 'Closed'. 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

Thiết lập xuất dữ liệu sang Azure Data Lake: Trong môi trường Dynamics 365 Finance and Operations, hãy đảm bảo đã cài đặt và cấu hình tiện ích 'Export to Azure Data Lake'. Việc này bao gồm liên kết D365 với gói đăng ký Azure và tài khoản Azure Data Lake Storage Gen2 đích.
Chọn bảng cần xuất: Mở workspace 'Export to Data Lake' trong Dynamics 365. Tìm và thêm các bảng sau vào cấu hình xuất: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable và CustTable. Bật xuất cho tất cả bảng đã chọn.
Thiết lập Azure Synapse Analytics: Trong cổng Azure, triển khai workspace Azure Synapse Analytics. Cấp cho workspace các quyền cần thiết, chẳng hạn 'Storage Blob Data Contributor', trên tài khoản Data Lake lưu dữ liệu D365.
Tạo cơ sở dữ liệu SQL không máy chủ: Trong Synapse Studio, mở trung tâm 'Data'. Tạo cơ sở dữ liệu SQL không máy chủ để truy vấn dữ liệu trong Data Lake bằng T-SQL.
Tạo view cho các bảng D365: Để truy vấn dễ hơn, hãy tạo SQL view trong cơ sở dữ liệu không máy chủ, trỏ đến dữ liệu bảng D365 đã sao chép trong Data Lake. Cách này giúp ẩn đường dẫn và định dạng tệp bên dưới. Ví dụ: CREATE VIEW dbo.SalesTable AS SELECT * FROM OPENROWSET(BULK 'path/to/salestable', FORMAT='CSV', ...).
Chuẩn bị truy vấn SQL: Mở tập lệnh SQL mới trong Synapse Studio và kết nối với cơ sở dữ liệu không máy chủ. Sao chép toàn bộ truy vấn SQL trong tài liệu này vào trình soạn thảo tập lệnh.
Điều chỉnh tham số truy vấn: Tìm các chỗ giữ chỗ ở đầu truy vấn. Thay '{YourDataAreaId}' bằng mã công ty bạn muốn phân tích. Điều chỉnh '{StartDate}' và '{EndDate}' để xác định khoảng thời gian trích xuất.
Chạy truy vấn: Chạy toàn bộ tập lệnh SQL. Truy vấn sẽ lấy sự kiện từ nhiều bảng và hợp nhất thành một nhật ký sự kiện có định dạng thống nhất.
Kiểm tra và xuất kết quả: Khi truy vấn chạy xong, kiểm tra kết quả trong khung kết quả của Synapse Studio để đảm bảo dữ liệu đầy đủ và đúng định dạng. Dùng chức năng xuất có sẵn để lưu kết quả thành tệp CSV.
Chuẩn bị tải lên: Mở tệp CSV đã xuất và xác nhận tệp dùng mã hóa UTF-8. Kiểm tra tiêu đề cột khớp chính xác với các thuộc tính bắt buộc, chẳng hạn SalesOrderNumber, ActivityName, EventTime, v.v.
Tải lên ProcessMind: Tải tệp CSV cuối cùng đã kiểm tra lên dự án ProcessMind để phân tích và trực quan hóa.

Cấu hình

Điều kiện cần: Cách này yêu cầu gói đăng ký Azure đang hoạt động và tiện ích 'Export to Azure Data Lake' đã được cấu hình cho phiên bản Dynamics 365 F&O của bạn. Bạn cần có quyền phù hợp trong Azure (để quản lý Synapse và Storage) và D365 (để cấu hình xuất dữ liệu).
Các mô-đun D365 cần có: Để ghi nhận đầy đủ sự kiện, đặc biệt là hoạt động kho, cần dùng mô-đun Warehouse Management (WMS). Các sự kiện cốt lõi dựa vào mô-đun Sales and Marketing và Accounts Receivable.
Chọn bảng: Bạn cần bật xuất cho tất cả bảng được tham chiếu trong truy vấn, gồm SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable và CustTable. Thiếu bảng sẽ khiến một số hoạt động không được ghi nhận.
Lọc khoảng thời gian: Truy vấn được thiết kế để lọc theo khoảng thời gian bằng tham số {StartDate} và {EndDate}. Với lần trích xuất đầu tiên, nên chọn khoảng thời gian ngắn, chẳng hạn 3-6 tháng, để thời gian chạy truy vấn ở mức phù hợp.
Lọc theo công ty (DataAreaId): Bạn phải thay chỗ giữ chỗ '{YourDataAreaId}' bằng pháp nhân cụ thể trong môi trường D365. Truy vấn không hỗ trợ phân tích nhiều công ty trong một lần chạy.
Lưu ý về hiệu suất: Với tập dữ liệu rất lớn, hiệu suất truy vấn trên nhóm SQL không máy chủ có thể thay đổi. Hãy cân nhắc lên lịch trích xuất vào giờ thấp điểm. Nếu cần trích xuất thường xuyên, bạn có thể lưu nhật ký sự kiện cuối cùng thành bảng mới trong Data Lake để cải thiện hiệu suất xử lý tiếp theo.

Truy vấn mẫu sql

WITH SalesOrderBase AS (
    SELECT
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME AS CustomerName,
        ST.SHIPPINGDATECONFIRMED AS ConfirmedDeliveryDate,
        ST.DELIVERYDATE AS RequestedDeliveryDate,
        ST.PURCHORDERFORMNUM AS SalesChannel, -- Example mapping, adjust if you use a different field for Sales Channel
        SUM(SL.LINEAMOUNT) AS OrderValue
    FROM dbo.SALESTABLE ST
    LEFT JOIN dbo.SALESLINE SL ON ST.SALESID = SL.SALESID AND ST.DATAREAID = SL.DATAREAID
    LEFT JOIN dbo.CUSTTABLE CT ON ST.CUSTACCOUNT = CT.ACCOUNTNUM AND ST.DATAREAID = CT.DATAREAID
    WHERE ST.DATAREAID = '{YourDataAreaId}'
      AND ST.CREATEDDATETIME >= '{StartDate}' AND ST.CREATEDDATETIME < '{EndDate}'
    GROUP BY
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME,
        ST.SHIPPINGDATECONFIRMED,
        ST.DELIVERYDATE,
        ST.PURCHORDERFORMNUM
)
-- 1. Sales Order Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Sales Order Created' AS ActivityName,
    ST.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID

UNION ALL

-- 2. Credit Check Performed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Credit Check Performed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime, -- This assumes a status change date reflects the credit check time
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.CREDITLIMITTYPE > 0 -- Example condition for a credit check being done. Adjust based on your configuration.

UNION ALL

-- 3. Order Confirmed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Confirmed' AS ActivityName,
    CJ.CONFIRMDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTCONFIRMJOUR CJ ON SO.SALESID = CJ.SALESID AND SO.DATAREAID = CJ.DATAAREAID

UNION ALL

-- 4. Inventory Reserved (approximated by first line item reservation)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Inventory Reserved' AS ActivityName,
    MIN(SL.CREATEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESLINE SL ON SO.SALESID = SL.SALESID AND SO.DATAREAID = SL.DATAREAID
WHERE SL.RESERVATION > 0 -- Identifies lines with a reservation status
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 5. Released To Warehouse
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Released To Warehouse' AS ActivityName,
    WLT.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSLOADTABLE WLT ON SO.SALESID = WLT.SALESID AND SO.DATAREAID = WLT.DATAAREAID

UNION ALL

-- 6. Goods Picked (approximated by last pick work closure)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Picked' AS ActivityName,
    MAX(WWT.MODIFIEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSWORKTABLE WWT ON SO.SALESID = WWT.ORDERNUM AND SO.DATAREAID = WWT.DATAAREAID
WHERE WWT.WORKTYPE = 'Pick' AND WWT.WORKSTATUS = 'Closed'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 7. Goods Packed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Packed' AS ActivityName,
    PSJ.CREATEDDATETIME AS EventTime, -- Using creation time of packing slip as proxy
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 8. Goods Shipped
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Shipped' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 9. Goods Delivered (placeholder, often requires custom fields)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Delivered' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime, -- Placeholder, using shipment date. True delivery requires external data.
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID
WHERE 1 = 2 -- This will return no rows unless logic is added to read from a custom field with actual delivery dates

UNION ALL

-- 10. Invoice Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Invoice Created' AS ActivityName,
    CIJ.INVOICEDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID

UNION ALL

-- 11. Payment Received (approximated by last settlement date)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Payment Received' AS ActivityName,
    MAX(CT.SETTLEMENTDATE) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID
JOIN dbo.CUSTTRANS CT ON CIJ.INVOICEID = CT.INVOICE AND CIJ.DATAAREAID = CT.DATAAREAID
WHERE CT.TRANSTYPE = 'Payment'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 12. Order Closed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Closed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 4 -- Status for 'Invoiced'

UNION ALL

-- 13. Order Cancelled
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Cancelled' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 3; -- Status for 'Canceled'

Các bước

Điều kiện cần và thiết lập: Đảm bảo đã cài Python 3.6 trở lên. Cài các thư viện Python cần thiết bằng lệnh sau trong terminal: pip install pandas requests msal.
Đăng ký ứng dụng trong Azure AD: Mở cổng Azure và đăng ký ứng dụng mới trong Azure Active Directory. Ứng dụng này sẽ dùng để xác thực với Dynamics 365 API. Ghi lại Application (client) ID và Directory (tenant) ID.
Tạo client secret: Trong ứng dụng Azure AD vừa đăng ký, tạo client secret mới tại mục 'Certificates & secrets'. Sao chép ngay giá trị secret vì sau đó bạn sẽ không xem lại được. Đây là CLIENT_SECRET.
Cấp quyền API: Trong cài đặt ứng dụng Azure AD, mở 'API permissions'. Thêm quyền cho 'Dynamics ERP' hoặc 'Dynamics 365 for Finance and Operations'. Chọn 'Delegated permissions' và cấp user_impersonation. Sau đó thêm lại quyền tương tự, nhưng chọn 'Application permissions' và cấp Financials.ReadWrite.All hoặc quyền chỉ đọc hạn chế hơn nếu có và đáp ứng nhu cầu. Cấp quyền quản trị cho các quyền này.
Tạo người dùng ứng dụng trong Dynamics 365: Trong môi trường Dynamics 365, mở 'System administration' > 'Users' > 'Users'. Tạo người dùng mới và liên kết với Application ID từ đăng ký ứng dụng Azure AD. Gán vai trò bảo mật, chẳng hạn 'System administrator' (toàn quyền) hoặc vai trò tùy chỉnh có quyền đọc các thực thể dữ liệu cần thiết (SalesOrderHeadersV2, SalesOrderLines, SalesPackingSlipHeaders, SalesInvoiceHeadersV2, v.v.).
Cấu hình tập lệnh Python: Mở tập lệnh Python được cung cấp trong trình soạn thảo. Tìm phần cấu hình ở đầu tệp và thay các giá trị giữ chỗ cho D365_URL, TENANT_ID, CLIENT_ID, CLIENT_SECRET, COMPANY_FILTER, START_DATE và END_DATE bằng thông tin môi trường của bạn.
Khai báo ánh xạ thực thể (không bắt buộc): Kiểm tra tên thực thể và trường được dùng trong tập lệnh. Nếu tổ chức dùng thực thể hoặc trường tùy chỉnh để theo dõi một số hoạt động, bạn có thể cần điều chỉnh truy vấn OData trong tập lệnh.
Chạy tập lệnh trích xuất: Chạy tập lệnh từ dòng lệnh bằng lệnh python your_script_name.py. Tập lệnh sẽ xác thực, truy vấn Dynamics 365 OData API cho từng hoạt động và xử lý dữ liệu. Tiến độ sẽ hiển thị trong cửa sổ dòng lệnh.
Kiểm tra tệp đầu ra: Khi chạy thành công, tập lệnh sẽ tạo tệp CSV có tên d365_order_to_cash_event_log.csv trong cùng thư mục. Mở tệp để kiểm tra nhật ký sự kiện đã trích xuất có chính xác và đầy đủ không.
Tải lên ProcessMind: Tệp CSV được tạo đã có cấu trúc theo lược đồ yêu cầu và sẵn sàng tải trực tiếp lên ProcessMind để phân tích quy trình.

Cấu hình

D365_URL: URL cơ sở của môi trường Dynamics 365 Finance and Operations. URL có dạng https://[your-d365-environment-name].operations.dynamics.com.
TENANT_ID: Directory (tenant) ID của Azure Active Directory, có trên trang tổng quan đăng ký ứng dụng Azure AD.
CLIENT_ID: Application (client) ID của ứng dụng bạn đã đăng ký trong Azure AD.
CLIENT_SECRET: Giá trị client secret bạn đã tạo cho ứng dụng Azure AD.
COMPANY_FILTER: Chỉ định pháp nhân Dynamics 365 (chẳng hạn 'USMF') cần trích xuất dữ liệu. Đây là bộ lọc bắt buộc để đảm bảo bạn truy vấn đúng dữ liệu công ty.
START_DATE / END_DATE: Xác định khoảng thời gian trích xuất theo định dạng 'YYYY-MM-DD'. Với lần phân tích đầu tiên, nên chọn khoảng 3 đến 6 tháng để cân bằng giữa lượng dữ liệu và thông tin thu được. Lưu ý, khoảng thời gian dài có thể làm tăng đáng kể thời gian trích xuất.
Điều kiện cần: Bạn cần quyền truy cập Azure AD để đăng ký ứng dụng và cấp quyền. Bạn cũng cần tài khoản Dynamics 365 có quyền tạo người dùng ứng dụng và gán vai trò bảo mật. Vai trò được gán phải có quyền đọc tất cả thực thể mà tập lệnh truy vấn.

Truy vấn mẫu python

import requests
import pandas as pd
import msal
import json
import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your D365 environment and Azure AD App details
D365_URL = class="hl-string">"https://[your-d365-environment-name].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your-Azure-AD-Tenant-ID]"
CLIENT_ID = class="hl-string">"[Your-Azure-AD-Client-ID]"
CLIENT_SECRET = class="hl-string">"[Your-Azure-AD-Client-Secret]"

class=class="hl-string">"hl-comment"># --- EXTRACTION PARAMETERS ---
COMPANY_FILTER = class="hl-string">"[Your-Company-Code]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SCRIPT --- 

AUTHORITY_URL = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
RESOURCE = fclass="hl-string">"{D365_URL}/"
API_ENDPOINT = fclass="hl-string">"{D365_URL}/data"

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD and returns an access token."""
    app = msal.ConfidentialClientApplication(
        client_id=CLIENT_ID,
        client_credential=CLIENT_SECRET,
        authority=AUTHORITY_URL
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        raise Exception(class="hl-string">"Could not authenticate.")

def execute_odata_query(access_token, entity, select_fields, filter_query, expand_fields=None):
    class="hl-string">"""Executes an OData query against a D365 entity and handles pagination."""
    all_results = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.maxpagesize=1000' class=class="hl-string">"hl-comment"># Request pagination
    }
    
    query_url = fclass="hl-string">"{API_ENDPOINT}/{entity}?$select={select_fields}&$filter={filter_query}&cross-company=true"
    if expand_fields:
        query_url += fclass="hl-string">"&$expand={expand_fields}"
    
    print(fclass="hl-string">"Querying {entity}...")
    while query_url:
        try:
            response = requests.get(query_url, headers=headers)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_results.extend(data.get(class="hl-string">'value', []))
            query_url = data.get(class="hl-string">'@odata.nextLink') class=class="hl-string">"hl-comment"># Get URL for the next page
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error for {entity}: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            return [] class=class="hl-string">"hl-comment"># Return empty list on error
        except json.JSONDecodeError:
            print(fclass="hl-string">"JSON Decode Error for {entity}. Response was not valid JSON.")
            print(fclass="hl-string">"Response text: {response.text}")
            return []

    print(fclass="hl-string">"...found {len(all_results)} records for {entity}.")
    return all_results

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    try:
        token = get_access_token()
    except Exception as e:
        print(e)
        return

    all_events = []
    now_utc = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># Shared attributes for most queries
    base_select_fields = class="hl-string">"SalesOrderNumber,TotalInvoiceAmount,SalesOrderOriginCode,RequestedShippingDate,ConfirmedShippingDate,CustomerAccount"
    base_expand_fields = class="hl-string">"CustomerV3(CustomerName)"

    class=class="hl-string">"hl-comment"># Common date filter for creation/modification timestamps
    date_filter = fclass="hl-string">"(CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z)"

    class=class="hl-string">"hl-comment"># 1. Sales Order Created
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},CreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {date_filter}", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Created',
            class="hl-string">'EventTime': record.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 2. Credit Check Performed (based on status change)
    class=class="hl-string">"hl-comment"># This assumes a credit check is reflected by the CreditLimitApprovalStatus. This logic may need adjustment.
    class=class="hl-string">"hl-comment"># We look for orders modified in the period, then check the status.
    modified_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},ModifiedDateTime,CreditLimitApprovalStatus", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {modified_date_filter} and CreditLimitApprovalStatus ne 'NoCheck'", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Credit Check Performed',
            class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime'), class=class="hl-string">"hl-comment"># Using ModifiedDateTime as a proxy
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 3. Order Confirmed
    confirmation_date_filter = fclass="hl-string">"(ConfirmationDate ge {START_DATE} and ConfirmationDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesConfirmationHeaders', class="hl-string">"SalesOrderNumber,ConfirmationDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {confirmation_date_filter}")
    class=class="hl-string">"hl-comment"># We need to get details from the SalesOrderHeader
    order_numbers = class="hl-string">"'" + class="hl-string">"','".join([rec[class="hl-string">'SalesOrderNumber'] for rec in data if rec.get(class="hl-string">'SalesOrderNumber')]) + class="hl-string">"'"
    if order_numbers != class="hl-string">"''":
        header_data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', base_select_fields, fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({order_numbers})", base_expand_fields)
        header_map = {h[class="hl-string">'SalesOrderNumber']: h for h in header_data}
        for record in data:
            header = header_map.get(record.get(class="hl-string">'SalesOrderNumber'))
            if header:
                all_events.append({
                    class="hl-string">'SalesOrderNumber': header.get(class="hl-string">'SalesOrderNumber'),
                    class="hl-string">'ActivityName': class="hl-string">'Order Confirmed',
                    class="hl-string">'EventTime': str(record.get(class="hl-string">'ConfirmationDate')) + class="hl-string">'T12:00:00Z', class=class="hl-string">"hl-comment"># Date only field, adding midday time
                    class="hl-string">'OrderValue': header.get(class="hl-string">'TotalInvoiceAmount'),
                    class="hl-string">'CustomerName': header.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
                    class="hl-string">'SalesChannel': header.get(class="hl-string">'SalesOrderOriginCode'),
                    class="hl-string">'RequestedDeliveryDate': header.get(class="hl-string">'RequestedShippingDate'),
                    class="hl-string">'ConfirmedDeliveryDate': header.get(class="hl-string">'ConfirmedShippingDate')
                })
    
    class=class="hl-string">"hl-comment"># 4 & 5. Inventory Reserved & Released To Warehouse (WMS)
    class=class="hl-string">"hl-comment"># These are complex. This is a proxy based on Warehouse Work creation time.
    work_date_filter = fclass="hl-string">"(WorkCreatedDateTime ge {START_DATE}T00:00:00Z and WorkCreatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WarehouseWorkHeaders', class="hl-string">"OrderNumber,WorkCreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {work_date_filter} and WorkType eq 'SalesOrders'")
    for record in data:
        class=class="hl-string">"hl-comment"># Assuming reservation happens just before release to warehouse
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Inventory Reserved', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Released To Warehouse', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})

    class=class="hl-string">"hl-comment"># 6 & 7. Goods Picked & Goods Packed (WMS)
    class=class="hl-string">"hl-comment"># Proxy using Shipment status updates. This logic may need refinement based on specific WMS setup.
    shipment_date_filter = fclass="hl-string">"(ShipmentStatusLastUpdatedDateTime ge {START_DATE}T00:00:00Z and ShipmentStatusLastUpdatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WHSShipmentTables', class="hl-string">"SalesOrderNumber,ShipmentStatus,ShipmentStatusLastUpdatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {shipment_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Picked', class="hl-string">'Loaded', class="hl-string">'Shipped']:
             all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Picked', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Loaded', class="hl-string">'Shipped']:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Packed', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})

    class=class="hl-string">"hl-comment"># 8. Goods Shipped (Posting Packing Slip)
    packslip_date_filter = fclass="hl-string">"(ShippingDate ge {START_DATE} and ShippingDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ShippingDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Shipped', class="hl-string">'EventTime': str(record.get(class="hl-string">'ShippingDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 9. Goods Delivered
    class=class="hl-string">"hl-comment"># This is often not a standard field. We use ModifiedDateTime on Packing Slip as a placeholder.
    packslip_mod_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ModifiedDateTime,DeliveryMode", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_mod_date_filter} and DeliveryMode eq '[Your-Delivered-Status-Code]'")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Delivered', class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})

    class=class="hl-string">"hl-comment"># 10. Invoice Created
    invoice_date_filter = fclass="hl-string">"(InvoiceDate ge {START_DATE} and InvoiceDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesInvoiceHeadersV2', class="hl-string">"SalesOrderNumber,InvoiceDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTime': str(record.get(class="hl-string">'InvoiceDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 11. Payment Received
    class=class="hl-string">"hl-comment"># This requires looking at customer payments and settling them to invoices, then to sales orders.
    class=class="hl-string">"hl-comment"># This is a simplified proxy using the ClosedDate of the invoice.
    invoice_closed_date_filter = fclass="hl-string">"(ClosedDate ge {START_DATE} and ClosedDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'CustomerInvoices', class="hl-string">"SalesOrderNumber,ClosedDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_closed_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ClosedDate') and record.get(class="hl-string">'SalesOrderNumber'):
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Received', class="hl-string">'EventTime': str(record.get(class="hl-string">'ClosedDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 12 & 13. Order Closed & Order Cancelled
    class=class="hl-string">"hl-comment"># These are statuses on the Sales Order Header.
    status_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', class="hl-string">"SalesOrderNumber,SalesOrderStatus,ModifiedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {status_date_filter} and (SalesOrderStatus eq 'Invoiced' or SalesOrderStatus eq 'Canceled')")
    for record in data:
        activity = class="hl-string">''
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Invoiced': activity = class="hl-string">'Order Closed'
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Canceled': activity = class="hl-string">'Order Cancelled'
        if activity:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})


    class=class="hl-string">"hl-comment"># --- Final Processing ---
    if not all_events:
        print(class="hl-string">"No events found. Exiting.")
        return

    df = pd.DataFrame(all_events)
    print(fclass="hl-string">"Total events created: {len(df)}")

    class=class="hl-string">"hl-comment"># Drop events without a case ID or timestamp
    df.dropna(subset=[class="hl-string">'SalesOrderNumber', class="hl-string">'EventTime'], inplace=True)
    print(fclass="hl-string">"Events after dropping nulls: {len(df)}")

    class=class="hl-string">"hl-comment"># Fill in missing recommended attributes by merging back header details
    print(class="hl-string">"Enriching data with header attributes...")
    unique_orders = class="hl-string">"'" + class="hl-string">"','".join(df[class="hl-string">'SalesOrderNumber'].unique()) + class="hl-string">"'"
    if unique_orders != class="hl-string">"''":
        header_data_final = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields}", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({unique_orders})", base_expand_fields)
        header_df = pd.DataFrame(header_data_final)
        if not header_df.empty:
            header_df = header_df.rename(columns={
                class="hl-string">'TotalInvoiceAmount': class="hl-string">'OrderValue',
                class="hl-string">'SalesOrderOriginCode': class="hl-string">'SalesChannel',
                class="hl-string">'RequestedShippingDate': class="hl-string">'RequestedDeliveryDate',
                class="hl-string">'ConfirmedShippingDate': class="hl-string">'ConfirmedDeliveryDate'
            })
            class=class="hl-string">"hl-comment"># Extract nested customer name
            header_df[class="hl-string">'CustomerName'] = header_df[class="hl-string">'CustomerV3'].apply(lambda x: x.get(class="hl-string">'CustomerName') if isinstance(x, dict) else None)
            df = df.merge(header_df[[class="hl-string">'SalesOrderNumber', class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']], on=class="hl-string">'SalesOrderNumber', how=class="hl-string">'left', suffixes=(class="hl-string">'', class="hl-string">'_y'))
            class=class="hl-string">"hl-comment"># Fill NaNs from merge
            for col in [class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']:
                if col + class="hl-string">'_y' in df.columns:
                    df[col] = df[col].fillna(df[col + class="hl-string">'_y'])
                    df.drop(columns=[col + class="hl-string">'_y'], inplace=True)

    class=class="hl-string">"hl-comment"># Add required static columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataUpdate'] = now_utc

    class=class="hl-string">"hl-comment"># Ensure required columns exist
    final_cols = [class="hl-string">'SalesOrderNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
                  class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']
    for col in final_cols:
        if col not in df.columns:
            df[col] = None
    
    class=class="hl-string">"hl-comment"># Reorder and save
    df = df[final_cols]
    df.to_csv(class="hl-string">'d365_order_to_cash_event_log.csv', index=False)
    print(class="hl-string">"Successfully created d365_order_to_cash_event_log.csv")

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

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

Dùng mẫu này để chuẩn bị dữ liệu, sau đó tải lên nền tảng để tìm ra thông tin hữu ích và nâng cao hiệu quả xử lý đơn hàng bán. Bắt đầu tối ưu ngay hôm nay!

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

Tải mẫu xuống

Tối ưu quy trình xử lý đơn hàng đến thu tiền ngay hôm nay

Tìm điểm chưa hiệu quả và giảm 30% thời gian xử lý để hoàn tất đơn nhanh hơn.

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 cho quy trình xử lý đơn hàng đến thu tiền

Mẫu dữ liệu cho quy trình xử lý đơn hàng đến thu tiền

Thuộc tính của quy trình xử lý đơn hàng đến thu tiền

Các hoạt động trong quy trình xử lý đơn hàng đến thu tiền

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

Truy vấn SQL trên Azure Data Lake bằng Synapse Analytics

Các bước

Cấu hình

Truy vấn mẫu sql

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

Các bước

Cấu hình

Truy vấn mẫu python

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

Tối ưu quy trình xử lý đơn hàng đến thu tiền ngay hôm nay