> Cải tiến quy trình liên tục > Quy trình trả hàng và hoàn tiền > Microsoft Dynamics 365 > Mẫu dữ liệu

Mẫu dữ liệu cho quy trình trả hàng và hoàn tiền

Microsoft Dynamics 365

Thuộc tính của quy trình trả hàng và hoàn tiền(21) Hoạt động trong quy trình trả hàng và hoàn tiền(12) Hướng dẫn trích xuất dữ liệu(2)

Mẫu dữ liệu cho quy trình trả hàng và hoàn tiền

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để tối ưu quy trình trả hàng và hoàn tiền. Mẫu nêu rõ các trường dữ liệu quan trọng, những bước chính trong quy trình và cách trích xuất dữ liệu từ Microsoft Dynamics 365.

Các trường dữ liệu nên thu thập
Các bước 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

Thuộc tính của quy trình trả hàng và hoàn tiền

Đây là các trường dữ liệu nên có trong event log để phân tích quy trình trả hàng và hoàn tiền.

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

	Tên	Mô tả
	Mã hồ sơ trả hàng ReturnCaseId	Mã định danh duy nhất của hồ sơ trả hàng và hoàn tiền của khách, liên kết mọi hoạt động liên quan.
Mô tả Mã hồ sơ trả hàng là mã định danh chính của từng trường hợp trả hàng. Mã này liên kết mọi hoạt động gắn với một yêu cầu trả hàng hoặc hoàn tiền cụ thể của khách, từ lúc tạo đơn trả hàng đến khi đóng hồ sơ. Trong phân tích quy trình, mã này là yếu tố cốt lõi để dựng lại toàn bộ hành trình của từng trường hợp trả hàng. Mã giúp theo dõi toàn bộ vòng đời, đo tổng thời gian xử lý và phân tích khác biệt giữa các hồ sơ. Hệ thống tổng hợp và liên kết mọi sự kiện, dữ liệu và chỉ số theo mã này. Vì sao điều này quan trọng Đây là mã hồ sơ thiết yếu, liên kết mọi bước trong quy trình để bạn theo dõi và phân tích từng trường hợp trả hàng từ đầu đến cuối. Lấy dữ liệu ở đâu Thông thường, đây là số giấy phép trả hàng (RMA) hoặc số đơn bán hàng có loại 'Returned Order' trong mô-đun 'Sales and marketing'. Bạn có thể tìm thấy mã này trong các bảng như 'SalesTable', nơi 'SalesType' có giá trị 'Returned Order'. Ví dụ RMA-001234RMA-001235RMA-001236
	Thời điểm sự kiện EventTime	Dấu thời gian cho biết thời điểm 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 ngày giờ 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 tương ứng, cho biết thứ tự thời gian của các sự kiện. Thuộc tính này rất quan trọng đối với mọi phân tích process mining dựa trên thời gian. Dữ liệu được dùng để tính thời gian giữa các hoạt động, xác định thời gian chờ và điểm nghẽn, đo tổng thời lượng xử lý hồ sơ và kiểm tra việc tuân thủ thỏa thuận mức dịch vụ (SLA). Độ chính xác của dấu thời gian ảnh hưởng trực tiếp đến độ tin cậy của mọi phân tích hiệu quả. 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ố về thời lượng, chẳng hạn như thời gian xử lý và thời gian chờ, vốn là cơ sở để phân tích hiệu quả. Lấy dữ liệu ở đâu Tương ứng với các trường ngày tạo hoặc ngày chỉnh sửa trong nhiều bảng, chẳng hạn như 'SalesTable.createdDateTime' khi tạo đơn hàng hoặc 'WMSJournalTrans.createdDateTime' cho nhật ký kho. Ví dụ 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z
	Tên hoạt động ActivityName	Tên của sự kiện kinh doanh hoặc tác vụ cụ thể diễn ra trong quy trình trả hàng và hoàn tiền.
Mô tả Thuộc tính này mô tả một bước hoặc sự kiện cụ thể trong vòng đời trả hàng và hoàn tiền, chẳng hạn như 'Đã tạo đơn trả hàng', 'Đã nhận hàng trả lại' hoặc 'Đã ghi sổ giấy báo có'. Mỗi hoạt động là một thời điểm riêng trong quy trình được ghi lại trong hệ thống. Phân tích trình tự và tần suất củ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 điểm nghẽn giữa các bước và tìm ra những biến thể quy trình phổ biến hoặc ít gặp. Tập hợp các hoạt động xác định phạm vi quy trình được phân tích. Vì sao điều này quan trọng Thuộc tính này xác định các bước trong quy trình, giúp trực quan hóa luồng quy trình và tìm ra điểm nghẽn, công việc làm lại cũng như các trường hợp đi chệch quy trình. Lấy dữ liệu ở đâu Đây là thuộc tính khái niệm được suy ra từ các sự kiện hệ thống. Có thể tạo thuộc tính này bằng cách ánh xạ thay đổi trạng thái trong các bảng như 'SalesTable' và 'WMSJournalTable', hoặc từ nhật ký sự kiện cụ thể sang tên dễ hiểu với người dùng. Ví dụ Đã tạo đơn trả hàngĐã nhận hàng trả lạiĐã áp dụng mã xử lý hàng trả lạiĐã ghi sổ giấy báo có
	Kênh trả hàng ReturnChannel	Phương thức hoặc kênh khách hàng dùng để bắt đầu yêu cầu trả hàng.
Mô tả Thuộc tính này cho biết khách hàng bắt đầu quy trình trả hàng qua kênh nào, chẳng hạn như “Cổng trực tuyến”, “Tại cửa hàng”, “Gọi bộ phận chăm sóc khách hàng” hoặc “Gửi thư”. Phân tích quy trình theo kênh trả hàng giúp đánh giá hiệu quả hoạt động của từng kênh. Doanh nghiệp có thể so sánh thời gian xử lý, chi phí và mức độ hài lòng của khách hàng giữa các kênh để tìm ra cách làm hiệu quả cũng như những lĩnh vực cần đầu tư hoặc cải tiến. Đây là thông tin quan trọng cho dashboard “Hiệu quả sử dụng kênh trả hàng”. Vì sao điều này quan trọng Giúp so sánh hiệu quả giữa các kênh trả hàng để xác định kênh hoạt động hiệu quả và tiết kiệm chi phí nhất. Lấy dữ liệu ở đâu Thông tin này có thể được lưu ở phần đầu đơn hàng trả lại ('SalesTable') hoặc xác định dựa trên người tạo đơn hàng. Có thể cần thêm logic tùy chỉnh hoặc một trường riêng. Ví dụ Cổng trực tuyếnKiosk tại cửa hàngBộ phận hỗ trợ khách hàng
	Mã lý do trả hàng ReturnReasonCode	Lý do khách hàng đưa ra khi trả hàng.
Mô tả Mã lý do trả hàng ghi nhận lý do khách hàng đưa ra, chẳng hạn như “Sản phẩm bị lỗi”, “Sai kích cỡ”, “Không đúng mô tả” hoặc “Không còn nhu cầu”. Thông tin này thường được thu thập khi khách bắt đầu yêu cầu trả hàng. Phân tích lý do trả hàng giúp tìm ra nguyên nhân gốc rễ. Qua đó, doanh nghiệp có thể phát hiện vấn đề về chất lượng sản phẩm, mô tả sản phẩm chưa chính xác hoặc sai sót trong khâu logistics. Những hiểu biết này giúp cải tiến thiết kế sản phẩm, hoạt động tiếp thị và chuỗi cung ứng để giảm số lượt trả hàng trong tương lai. Vì sao điều này quan trọng Cho biết nguyên nhân dẫn đến việc trả hàng, giúp tìm ra nguyên nhân gốc rễ để giảm tỷ lệ trả hàng và nâng cao mức độ hài lòng của khách hàng. Lấy dữ liệu ở đâu Thông tin này thường được lưu ở cấp dòng đơn hàng trả lại. Hãy tìm các trường mã lý do trong bảng 'SalesLine' của đơn hàng trả lại. Ví dụ LỖISAI_SẢN_PHẨMKHÔNG_CÒN_NHU_CẦUHƯ_HỎNG_TRONG_QUÁ_TRÌNH_VẬN_CHUYỂN
	Mã sản phẩm ProductId	Mã định danh duy nhất của sản phẩm được trả lại.
Mô tả Mã sản phẩm, thường là mã SKU (Stock Keeping Unit), xác định mặt hàng cụ thể mà khách hàng trả lại. Mỗi dòng đơn hàng trả lại đều gắn với một mã sản phẩm. Phân tích số lượt trả hàng theo sản phẩm giúp xác định những mặt hàng có tỷ lệ trả hàng cao. Đây có thể là dấu hiệu của vấn đề kiểm soát chất lượng, mô tả sản phẩm không chính xác hoặc lỗi sản xuất. Kết quả phân tích giúp ưu tiên điều tra và cải tiến các vấn đề liên quan đến sản phẩm. Vì sao điều này quan trọng Cho phép phân tích số lượt trả hàng theo từng sản phẩm, giúp xác định mặt hàng có vấn đề về chất lượng hoặc có lượng trả hàng cao. Lấy dữ liệu ở đâu Trường này tương ứng với 'ItemId' trong bảng 'SalesLine' của đơn hàng trả lại. Ví dụ SKU-A-123SKU-B-456SKU-C-789
	Mã xử lý hàng trả lại DispositionCode	Mã cho biết kết quả kiểm tra hàng và hành động cần thực hiện tiếp theo.
Mô tả Mã xử lý hàng trả lại được gán trong quá trình kiểm tra chất lượng hàng trả lại. Mã này quyết định bước tiếp theo, chẳng hạn như 'Credit', 'Replace', 'Scrap' hoặc 'Return to Customer'. Đây là điểm ra quyết định quan trọng trong quy trình trả hàng. Phân tích theo mã xử lý giúp doanh nghiệp hiểu kết quả trả hàng, theo dõi ảnh hưởng tài chính của việc loại bỏ hàng và đánh giá hiệu quả của các hướng xử lý khác nhau, chẳng hạn như đổi hàng hay hoàn tiền. Vì sao điều này quan trọng Mã này xác định hướng xử lý của yêu cầu trả hàng sau khi kiểm tra. Đây là thông tin quan trọng để phân tích các biến thể quy trình và kết quả kinh doanh tương ứng. Lấy dữ liệu ở đâu Đây là trường quan trọng trong phân hệ quản lý chất lượng, liên quan đến quy trình xử lý Quality Order hoặc Inspection Order. Ví dụ CRDTREPL-DSCRAPRTV
	Người dùng phụ trách ResponsibleUser	Người dùng hoặc nhân viên đã thực hiện hay chịu trách nhiệm cho một hoạt động cụ thể.
Mô tả Thuộc tính này xác định người chịu trách nhiệm thực hiện một bước trong quy trình. Đó có thể là nhân viên kho nhận hàng, nhân viên kiểm tra chất lượng hoặc nhân viên tài chính ghi sổ giấy báo có. Phân tích quy trình theo người dùng giúp hiểu cách phân bổ khối lượng công việc, xác định người có hiệu suất cao và tìm ra nhu cầu đào tạo. Bạn cũng có thể dùng thuộc tính này để kiểm tra các hồ sơ do một cá nhân hoặc nhóm cụ thể xử lý và đảm bảo phân chia nhiệm vụ phù hợp. Vì sao điều này quan trọng Thuộc tính này giúp phân tích cách phân bổ khối lượng công việc, hiệu quả của từng cá nhân hoặc nhóm, đồng thời xác định cơ hội đào tạo và phân bổ tài nguyên. Lấy dữ liệu ở đâu Có thể tìm thấy trong các trường 'created by' hoặc 'modified by' trên bản ghi giao dịch, chẳng hạn như 'SalesTable.createdBy' hoặc mã người dùng liên kết trong các bảng nhật ký. Ví dụ Alice.WBob.JChris.P
	Có tuân thủ chính sách không IsPolicyAdherent	Cờ cho biết việc phê duyệt trả hàng có tuân thủ chính sách trả hàng đã thiết lập hay không.
Mô tả Đây là thuộc tính boolean được tính toán, cho biết yêu cầu trả hàng có đáp ứng đầy đủ các tiêu chí trong chính sách trả hàng của công ty hay không. Các tiêu chí có thể gồm thời hạn trả hàng, tình trạng sản phẩm hoặc lý do trả hàng. Thuộc tính này hỗ trợ trực tiếp dashboard “Tổng quan tuân thủ trong phê duyệt trả hàng” và KPI “Tỷ lệ phê duyệt trả hàng tuân thủ chính sách”. Doanh nghiệp có thể dùng thuộc tính để đo lường mức độ tuân thủ chính sách, xác định các trường hợp được phê duyệt ngoại lệ và phân tích lý do cũng như tần suất của những ngoại lệ đó. Đây là thông tin cần thiết cho công tác quản trị và kiểm soát chi phí. Vì sao điều này quan trọng Đo trực tiếp mức độ tuân thủ quy tắc kinh doanh, giúp phát hiện và giảm các trường hợp phê duyệt trả hàng không tuân thủ có thể gây thất thu. Lấy dữ liệu ở đâu Đây là thuộc tính suy ra. Cần xây dựng logic bằng cách so sánh các thuộc tính của yêu cầu trả hàng, chẳng hạn ngày trả hàng so với ngày mua hoặc lý do trả hàng, với các quy tắc kinh doanh đã định trước. Ví dụ truefalse
	Hệ thống nguồn SourceSystem	Hệ thống thông tin dùng để trích xuất dữ liệu sự kiện.
Mô tả Thuộc tính này xác định hệ thống thông tin nguồn của dữ liệu. Trong trường hợp này, hệ thống chủ yếu là 'Microsoft Dynamics 365'. Ở các doanh nghiệp lớn, một quy trình có thể trải qua nhiều hệ thống. Ghi rõ hệ thống nguồn của từng sự kiện rất quan trọng để quản trị dữ liệu, xử lý sự cố trích xuất và hiểu rõ các hệ thống công nghệ tham gia vào quy trình. Thông tin này xác nhận nguồn gốc của dữ liệu được phân tích. 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, cần thiết cho việc quản trị, xác thực dữ liệu và hiểu các hệ thống tham gia vào quy trình. Lấy dữ liệu ở đâu Đây thường là giá trị tĩnh được thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL) để ghi nhãn nguồn gốc của tập dữ liệu. Ví dụ Microsoft Dynamics 365 F&OD365-PROD
	Lần 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ủa quy trình được làm mới.
Mô tả Thuộc tính này ghi lại ngày giờ dữ liệu được trích xuất lần gần nhất từ hệ thống nguồn và cập nhật trong công cụ process mining. Đây là mốc tham chiếu để biết dữ liệu đang phân tích mới đến đâu. Biết thời điểm cập nhật dữ liệu gần nhất giúp bạn đánh giá mức độ cập nhật của kết quả phân tích. Thông tin này giúp người dùng đọc dashboard và KPI chính xác hơn, đồng thời biết dữ liệu là dữ liệu thời gian thực hay ảnh chụp tại một thời điểm cụ thể. Đây là yếu tố quan trọng khi theo dõi vận hành. Vì sao điều này quan trọng Cho biết dữ liệu mới đến đâu, giúp chuyên viên phân tích biết thông tin về quy trình có còn cập nhật hay không. Lấy dữ liệu ở đâu Đây là thuộc tính siêu dữ liệu được tạo và lưu trong quy trình nhập dữ liệu, thường thể hiện dấu thời gian hoàn tất tác vụ ETL. Ví dụ 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Loại trả hàng ReturnType	Phân loại yêu cầu trả hàng theo kết quả dự kiến, chẳng hạn như hoàn tiền hoặc đổi sản phẩm.
Mô tả Thuộc tính này phân loại yêu cầu trả hàng theo cách xử lý khách hàng mong muốn hoặc doanh nghiệp đưa ra. Các loại phổ biến gồm hoàn tiền, đổi sang sản phẩm thay thế hoặc sửa chữa. Phân loại này giúp phân tích các hướng xử lý khác nhau. Quy trình hoàn tiền khác đáng kể so với quy trình gửi sản phẩm thay thế. Phân tích theo loại trả hàng giúp đánh giá chính xác hơn thời gian xử lý và điểm nghẽn của từng hướng giải quyết. Vì sao điều này quan trọng Cho phép phân nhóm phân tích theo kết quả dự kiến, vì quy trình hoàn tiền và đổi sản phẩm có các bước cũng như thời gian xử lý khác nhau. Lấy dữ liệu ở đâu Đây có thể là trường tùy chỉnh trong phần đầu đơn hàng trả lại, hoặc được xác định dựa trên mã xử lý hay các giao dịch tiếp theo, chẳng hạn như tạo đơn hàng bán sản phẩm thay thế. Ví dụ Hoàn tiềnĐổi sản phẩmTín dụng cửa hàng
	Mã chứng từ ghi có CreditNoteId	Mã định danh duy nhất của chứng từ ghi có được tạo cho khoản hoàn tiền.
Mô tả Khi xử lý khoản hoàn tiền, hệ thống tạo một chứng từ tài chính gọi là chứng từ ghi có hoặc credit memo. Thuộc tính này lưu mã định danh duy nhất của chứng từ đó. Mã này liên kết trực tiếp quy trình trả hàng trong hoạt động vận hành với hồ sơ tài chính trong hệ thống kế toán. Mã hữu ích cho việc kiểm toán và tìm hiểu sâu các chênh lệch tài chính, giúp nhà phân tích truy vết yêu cầu trả hàng đến đúng giao dịch tài chính đã tất toán. Vì sao điều này quan trọng Liên kết quy trình trả hàng trong hoạt động vận hành với giao dịch tài chính tương ứng, rất cần thiết cho việc kiểm toán và đối soát tài chính. Lấy dữ liệu ở đâu Số chứng từ ghi có thường nằm trong trường 'InvoiceId' của bảng 'CustInvoiceJour', với loại giao dịch là 'Credit note'. Có thể liên kết chứng từ này với đơn hàng trả lại. Ví dụ CN-10056CN-10057CN-10058
	Mã khách hàng CustomerId	Mã định danh duy nhất của khách hàng bắt đầu yêu cầu trả hàng.
Mô tả Mã khách hàng là mã định danh duy nhất của tài khoản khách hàng liên quan đến yêu cầu trả hàng. Mã này liên kết giao dịch trả hàng với một khách hàng cụ thể trong CRM hoặc cơ sở dữ liệu khách hàng. Phân tích số lượt trả hàng theo khách hàng giúp phát hiện những khách hàng có hoạt động trả hàng bất thường, có thể do gian lận hoặc thường xuyên không hài lòng. Doanh nghiệp cũng có thể dùng thông tin này để phân nhóm khách hàng, chẳng hạn cung cấp dịch vụ trả hàng ưu tiên cho khách hàng có giá trị cao. Vì sao điều này quan trọng Liên kết quy trình trả hàng với một khách hàng cụ thể, giúp phân tích theo khách hàng và nhận diện xu hướng trả hàng hoặc nguy cơ gian lận. Lấy dữ liệu ở đâu Đây là trường 'CustAccount' trong bảng 'SalesTable' của đơn hàng trả lại. Ví dụ CUST-00045CUST-00192CUST-00315
	Mã kho WarehouseId	Mã định danh của kho hoặc địa điểm tiếp nhận mặt hàng được trả lại.
Mô tả Thuộc tính này xác định kho hàng hoặc trung tâm trả hàng cụ thể xử lý mặt hàng được trả lại. Mỗi địa điểm có thể có quy trình, tài nguyên hoặc mức hiệu quả khác nhau. Phân tích quy trình theo kho giúp so sánh hiệu quả giữa các địa điểm. Qua đó, doanh nghiệp có thể xác định cơ sở xử lý hàng trả lại hiệu quả nhất, phát hiện điểm nghẽn theo khu vực và đưa ra quyết định về phân bổ tài nguyên cũng như chuẩn hóa quy trình trong mạng lưới logistics. Vì sao điều này quan trọng Giúp so sánh hiệu quả giữa các kho hoặc trung tâm trả hàng, từ đó phát hiện điểm nghẽn theo khu vực và cách làm hiệu quả. Lấy dữ liệu ở đâu Thông tin này được lưu trong trường 'InventLocationId' trên các giao dịch liên quan đến hàng tồn kho, chẳng hạn như Arrival Journal ('WMSJournalTable') hoặc 'SalesLine'. Ví dụ WH-EASTWH-WESTCENTRAL-DC
	Ngày mục tiêu hoàn tất SLA hoàn tiền RefundSlaTargetDate	Ngày mục tiêu để hoàn tất xử lý yêu cầu trả hàng và hoàn tiền.
Mô tả Thuộc tính này xác định thời hạn SLA để xử lý yêu cầu trả hàng. Đây là ngày khách hàng dự kiến nhận được kết quả cuối cùng, chẳng hạn như khoản hoàn tiền đã hạch toán hoặc sản phẩm thay thế đã được gửi đi. Ngày mục tiêu này rất cần thiết để theo dõi hiệu quả so với cam kết dịch vụ. Thuộc tính được dùng để tính KPI “Tỷ lệ đáp ứng SLA xử lý yêu cầu” và cung cấp dữ liệu cho dashboard “Hiệu quả SLA xử lý hoàn tiền”. So sánh ngày này với ngày hoàn tất thực tế giúp doanh nghiệp phát hiện trường hợp vi phạm SLA và chủ động xử lý các yêu cầu tồn đọng lâu. Vì sao điều này quan trọng Là mốc để đo hiệu quả quy trình, theo dõi việc tuân thủ SLA và xác định các yêu cầu bị trễ. Lấy dữ liệu ở đâu Đây có thể không phải trường tiêu chuẩn. Thường thì ngày này được tính bằng ngày tạo yêu cầu trả hàng cộng với khoảng thời gian SLA đã định trước, chẳng hạn 14 ngày. Giá trị có thể được lưu trong trường tùy chỉnh. Ví dụ 2023-11-10T23:59:59Z2023-11-15T23:59:59Z
	Số tiền hoàn lại được yêu cầu RequestedRefundAmount	Tổng số tiền khách hàng yêu cầu hoàn lại.
Mô tả Thuộc tính này thể hiện số tiền hoàn lại ban đầu mà khách hàng yêu cầu hoặc dự kiến nhận được khi bắt đầu quy trình trả hàng. Số tiền thường dựa trên giá mua ban đầu của mặt hàng được trả lại. Giá trị này làm cơ sở cho “Phân tích chênh lệch số tiền hoàn lại”. Bằng cách so sánh số tiền yêu cầu với số tiền thực tế đã hoàn, doanh nghiệp có thể phát hiện chênh lệch do phí nhập kho lại, hoàn một phần tiền cho hàng bị hư hỏng hoặc các khoản điều chỉnh khác. Nhờ đó, doanh nghiệp có thể theo dõi độ chính xác tài chính và việc tuân thủ chính sách. Vì sao điều này quan trọng Làm cơ sở đánh giá độ chính xác tài chính bằng cách so sánh với số tiền hoàn lại thực tế. Lấy dữ liệu ở đâu Thông thường, đây là số tiền của dòng hàng hoặc tổng số tiền trên dòng đơn hàng bán ban đầu tương ứng với mặt hàng được trả lại, nằm trong 'SalesLine.LineAmount'. Ví dụ 99.99150.0024.50
	Số tiền hoàn lại thực tế ActualRefundAmount	Số tiền cuối cùng đã hoàn cho khách hàng.
Mô tả Thuộc tính này ghi nhận số tiền cuối cùng đã xác nhận hoàn cho khách hàng. Giá trị được ghi lại khi chứng từ ghi có được tạo và hạch toán. Đây là thuộc tính quan trọng trong phân tích tài chính, được dùng trực tiếp trong dashboard “Phân tích chênh lệch số tiền hoàn lại” và KPI “Tỷ lệ chính xác của số tiền hoàn lại”. Phân tích dữ liệu này giúp doanh nghiệp hiểu tác động tài chính của việc trả hàng và các khoản điều chỉnh trong quy trình. Vì sao điều này quan trọng Thể hiện tác động tài chính thực tế của việc trả hàng, rất cần thiết để tính độ chính xác của khoản hoàn và hiểu kết quả tài chính. Lấy dữ liệu ở đâu Có thể tìm giá trị này trong chi tiết giao dịch của chứng từ ghi có đã hạch toán. Giá trị liên quan đến các bảng 'CustTrans' và 'CustInvoiceJour' của chứng từ ghi có. Ví dụ 99.99135.000.00
	Thời điểm kết thúc EndTime	Dấu thời gian cho biết lúc một hoạt động cụ thể hoàn tất.
Mô tả Thời điểm kết thúc là dấu thời gian ghi nhận lúc một hoạt động hoàn tất. StartTime đánh dấu thời điểm bắt đầu, còn EndTime đánh dấu thời điểm kết thúc, giúp tính thời gian xử lý của tác vụ đó. Thuộc tính này rất quan trọng khi phân tích hiệu quả chi tiết, nhất là với các tác vụ có thời lượng đo được như 'Kiểm tra hàng'. Bằng cách so sánh StartTime và EndTime, chuyên viên phân tích có thể đo chính xác thời gian thực hiện tác vụ, tách biệt với thời gian chờ giữa các tác vụ. Nhờ đó, họ có thể tìm ra điểm chưa hiệu quả bên trong từng hoạt động, thay vì chỉ xem khoảng thời gian giữa các hoạt động. Vì sao điều này quan trọng Thuộc tính này giúp tính thời gian thực hiện thực tế của từng hoạt động, phân biệt thời gian chờ với thời gian làm việc. Lấy dữ liệu ở đâu Thông tin này thường cần được suy ra. Ví dụ, có thể dùng 'modifiedDateTime' của lần thay đổi trạng thái kết thúc hoạt động, hoặc dùng StartTime của hoạt động tiếp theo. Ví dụ 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z
	Trạng thái đơn hàng trả lại ReturnOrderStatus	Trạng thái tổng thể của đơn hàng trả lại tại thời điểm phát sinh sự kiện.
Mô tả Thuộc tính này cho biết trạng thái hiện tại của phần đầu đơn hàng trả lại, chẳng hạn như “Đang mở”, “Đã lập hóa đơn” hoặc “Đã hủy”. Qua đó, bạn có thể biết khái quát yêu cầu đang ở giai đoạn nào. Các hoạt động cho biết từng bước cụ thể trong quy trình, còn trạng thái tổng thể hữu ích khi lọc và phân nhóm yêu cầu. Chẳng hạn, nhà phân tích có thể chỉ xem các yêu cầu “Đang mở” để nắm khối lượng công việc hiện tại, hoặc phân tích luồng quy trình của những yêu cầu cuối cùng bị “Đã hủy”. Vì sao điều này quan trọng Tóm tắt trạng thái của yêu cầu, giúp lọc yêu cầu và tìm hiểu kết quả như trường hợp bị hủy. Lấy dữ liệu ở đâu Thông tin này nằm trong trường 'SalesStatus' hoặc 'DocumentStatus' của bảng 'SalesTable'. Ví dụ Đơn hàng đang mởĐã giaoĐã lập hóa đơnĐã hủy
	Trạng thái SLA SlaStatus	Cho biết yêu cầu có được xử lý trong thời hạn SLA hay không.
Mô tả Thuộc tính được tính toán này cho biết trạng thái tuân thủ SLA, thường là “Đúng hạn” hoặc “Trễ hạn”. Trạng thái được xác định bằng cách so sánh dấu thời gian của hoạt động cuối cùng, chẳng hạn “Đóng đơn hàng trả lại”, với 'RefundSlaTargetDate'. Thuộc tính này giúp đơn giản hóa báo cáo hiệu quả trên các dashboard như “Hiệu quả SLA xử lý hoàn tiền”. Thay vì phải tự so sánh ngày, người dùng có thể xem trạng thái trực tiếp và dễ hiểu. Nhờ đó, họ có thể nhanh chóng lọc và tổng hợp dữ liệu để tính “Tỷ lệ đáp ứng SLA xử lý yêu cầu”. Vì sao điều này quan trọng Cung cấp chỉ báo rõ ràng về việc tuân thủ SLA, giúp dễ dàng lọc các yêu cầu trễ hạn và phân tích nguyên nhân gốc rễ của sự chậm trễ. Lấy dữ liệu ở đâu Đây là thuộc tính suy ra, được tính bằng cách so sánh dấu thời gian của hoạt động xử lý cuối cùng với thuộc tính 'RefundSlaTargetDate'. Ví dụ Đúng hạnTrễ hạn

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

Hoạt động trong quy trình trả hàng và hoàn tiền

Đây là các bước chính và mốc quan trọng cần ghi lại trong event log để khám phá quy trình chính xác.

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

	Hoạt động	Mô tả
	Đã áp dụng mã xử lý hàng trả lại	Hoạt động này thể hiện việc kiểm tra đã hoàn tất và quyết định cách xử lý hàng trả lại. Một mã xử lý, chẳng hạn như 'Credit', 'Scrap' hoặc 'Replace', được gán cho dòng hàng trả lại.
Vì sao điều này quan trọng Đây là điểm ra quyết định quan trọng, xác định bước tiếp theo là hoàn tiền, đổi hàng hay từ chối. Chậm trễ ở đây có thể kéo dài đáng kể thời gian xử lý tổng thể. Lấy dữ liệu ở đâu Hệ thống ghi nhận sự kiện này khi điền trường DispositionCode trên giao dịch tồn kho của dòng đơn trả hàng hoặc trên nhật ký liên quan. Thu thập Sự kiện cập nhật khi DispositionCode được thiết lập cho dòng đơn trả hàng. Loại sự kiện explicit
	Đã đóng đơn trả hàng	Đơn trả hàng đã đến trạng thái cuối, nghĩa là mọi giao dịch hàng hóa và tài chính đã hoàn tất. Việc này thường diễn ra sau khi ghi sổ giấy báo có hoặc gửi hàng thay thế.
Vì sao điều này quan trọng Đây là sự kiện kết thúc chính khi quy trình trả hàng hoàn tất thành công. Khoảng thời gian từ lúc tạo đơn đến mốc này là tổng thời gian xử lý hồ sơ. Lấy dữ liệu ở đâu Có thể suy ra từ việc trường trạng thái ReturnOrder chuyển sang giá trị cuối, chẳng hạn như 'Invoiced' hoặc 'Closed'. Điều này cho biết không còn bước xử lý nào tiếp theo. Thu thập Trường SalesTable.Status hoặc SalesTable.DocumentStatus chuyển sang trạng thái cuối. Loại sự kiện inferred
	Đã ghi sổ giấy báo có	Giấy báo có được ghi sổ chính thức vào sổ kế toán, để khách hàng có thể sử dụng khoản tín dụng. Đây là dấu mốc cho biết công ty đã hoàn tất thao tác hoàn tiền.
Vì sao điều này quan trọng Đây là mốc tài chính quan trọng, xác nhận khoản hoàn tiền đã được xử lý trong hệ thống. Hoạt động này thường được dùng để đo lường việc tuân thủ SLA hoàn tiền. Lấy dữ liệu ở đâu Dấu thời gian đăng nhật ký hóa đơn của đơn trả hàng, hoàn tất giấy báo có. Trạng thái đơn trả hàng chuyển thành 'Invoiced'. Thu thập Đăng nhật ký hóa đơn của đơn trả hàng. Loại sự kiện explicit
	Đã nhận hàng trả lại	Đánh dấu lúc kho hoặc trung tâm nhận hàng trả lại được chỉ định nhận hàng thực tế. Hệ thống ghi nhận sự kiện này khi đăng nhật ký hàng đến liên kết với đơn trả hàng.
Vì sao điều này quan trọng Đây là mốc quan trọng, đánh dấu chuyển từ hành động của khách hàng sang khâu xử lý nội bộ. Đây cũng là thời điểm bắt đầu tính thời gian xử lý nội bộ, chẳng hạn như kiểm tra và quyết định cách xử lý hàng. Lấy dữ liệu ở đâu Dấu thời gian đăng WMS Journal hoặc Item Arrival Journal liên kết với dòng ReturnOrder. Thao tác này cập nhật giao dịch tồn kho sang trạng thái 'Registered' hoặc 'Received'. Thu thập Sự kiện đăng Item Arrival Journal liên kết với dòng đơn trả hàng. Loại sự kiện explicit
	Đã tạo đơn trả hàng	Hoạt động này đánh dấu lúc bắt đầu quy trình trả hàng, khi hệ thống tạo giấy phép trả hàng (RMA) hoặc đơn trả hàng. Đây là sự kiện được ghi nhận rõ ràng khi tạo bản ghi ReturnOrder mới trong Dynamics 365.
Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của toàn bộ quy trình trả hàng. Phân tích khoảng thời gian từ hoạt động này đến các hoạt động khác giúp xác định tổng thời gian xử lý và tìm điểm nghẽn ở giai đoạn đầu. Lấy dữ liệu ở đâu Sự kiện này được ghi nhận từ dấu thời gian tạo phần đầu của ReturnOrder. Thông tin này thường nằm trong SalesTable, nơi SalesType có giá trị 'Returned Order'. Thu thập Sự kiện tạo bản ghi SalesTable có SalesType = 'Returned Order'. Loại sự kiện explicit
	Đã gửi hàng thay thế	Phiếu đóng gói của hàng thay thế được đăng, cho biết hàng đã được gửi cho khách. Đây là dấu mốc hoàn tất việc giao hàng trong quy trình đổi hàng.
Vì sao điều này quan trọng Đây là mốc quan trọng trong nhánh đổi hàng, cho biết công ty đã thực hiện xong cam kết với khách hàng. Theo dõi mốc này rất cần thiết để tính thời gian xử lý đổi hàng. Lấy dữ liệu ở đâu Ngày đăng nhật ký phiếu đóng gói của đơn bán hàng thay thế. Thao tác này cập nhật trạng thái đơn thành 'Delivered'. Thu thập Đăng phiếu đóng gói của đơn bán hàng thay thế. Loại sự kiện explicit
	Đã hủy đơn trả hàng	Đơn trả hàng bị hủy trước khi hoàn tất. Khách hàng có thể yêu cầu hủy hoặc hàng có thể chưa từng được gửi trả.
Vì sao điều này quan trọng Đây là một kết thúc khác, không thành công, của quy trình. Phân tích lý do hủy trả hàng có thể giúp hiểu hành vi khách hàng hoặc tìm ra vấn đề trong quy trình. Lấy dữ liệu ở đâu Có thể suy ra từ việc trường trạng thái ReturnOrder chuyển thành 'Cancelled'. Đây là trạng thái kết thúc riêng, khác với đơn hàng đã đóng thành công. Thu thập Trường SalesTable.Status chuyển thành 'Cancelled'. Loại sự kiện inferred
	Đã tạo đơn hàng thay thế	Hệ thống tạo đơn bán hàng mới để gửi hàng thay thế cho khách. Hoạt động này diễn ra khi hành động xử lý là 'Replace and Credit' hoặc 'Replace and Scrap'.
Vì sao điều này quan trọng Hoạt động này bắt đầu nhánh đổi hàng. Theo dõi riêng luồng này với luồng hoàn tiền là điều cần thiết để hiểu độ phức tạp và chi phí của việc đổi hàng. Lấy dữ liệu ở đâu Tạo bản ghi SalesTable mới cho hàng thay thế. Bản ghi này thường được tạo tự động và liên kết với đơn trả hàng ban đầu. Thu thập Tạo đơn bán hàng mới liên kết với đơn trả hàng thông qua hành động xử lý. Loại sự kiện explicit
	Đã tạo giấy báo có	Hệ thống tạo giấy báo có khi mã xử lý là 'Credit', cho phép hoàn tiền cho khách hàng. Đây là bước chính thức bắt đầu phần quyết toán tài chính của quy trình.
Vì sao điều này quan trọng Hoạt động này đánh dấu việc phê duyệt khoản hoàn tiền. Khoảng thời gian từ lúc quyết định cách xử lý đến khi tạo giấy báo có cho thấy mức độ chậm trễ hành chính khi bắt đầu hoàn tiền. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ việc tạo bản ghi SalesTable mới có giá trị âm và liên kết với đơn trả hàng ban đầu, hoặc từ việc chạy tác vụ hàng loạt 'Create credit note'. Thu thập Tạo giấy báo có, thường bằng cách đăng hóa đơn của đơn trả hàng. Loại sự kiện explicit
	Đã tạo lệnh kiểm tra chất lượng	Hệ thống tạo lệnh kiểm tra chất lượng chính thức, cho biết hàng trả lại cần được kiểm tra theo quy trình cụ thể. Bước này thường áp dụng khi hàng cần được thử nghiệm chi tiết hoặc đối chiếu với tiêu chuẩn chất lượng.
Vì sao điều này quan trọng Hoạt động này đánh dấu lúc bắt đầu quy trình kiểm tra chính thức. Theo dõi thời gian từ đây giúp đo lường hiệu quả và thời lượng của quy trình đảm bảo chất lượng. Lấy dữ liệu ở đâu Dấu thời gian tạo bản ghi trong InventQualityOrderTable liên kết với đơn trả hàng. Thu thập Tạo bản ghi InventQualityOrderTable. Loại sự kiện explicit
	Đã tạo nhật ký hàng đến	Hoạt động này cho biết kho đang chờ hàng trả về. Hệ thống tạo nhật ký hàng đến để chuẩn bị ghi nhận hàng hóa khi hàng thực sự được nhận.
Vì sao điều này quan trọng Bước này phân biệt khâu chuẩn bị logistics với lúc hàng thực sự được nhận. Nhờ đó, bạn có thể phân tích mức độ sẵn sàng của kho và lập kế hoạch tiếp nhận hàng trả. Lấy dữ liệu ở đâu Tạo bản ghi trong WMSJournalTable với JournalType 'Arrival'. Nhật ký được liên kết với dòng đơn trả hàng. Thu thập Dấu thời gian tạo bản ghi WMSJournalTable cho hàng trả lại. Loại sự kiện explicit
	Đã xác nhận đơn trả hàng	Hoạt động này thể hiện đơn trả hàng đã được xác nhận chính thức trong hệ thống, thường kích hoạt các xử lý tiếp theo. Hệ thống thường ghi nhận đây là một hành động cụ thể hoặc thay đổi trạng thái trên phần đầu của ReturnOrder.
Vì sao điều này quan trọng Xác nhận là bước quan trọng trước khi bắt đầu xử lý logistics. Nếu đơn bị chậm xác nhận, có thể đang tồn đọng công việc hành chính hoặc phát sinh vấn đề hệ thống. Lấy dữ liệu ở đâu Có thể nhận biết bước này qua bút toán nhật ký 'Confirmation' của đơn trả hàng hoặc thay đổi trong trường DocumentStatus của SalesTable. Thu thập Thực hiện chức năng 'Confirm sales order' cho đơn trả hàng. 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

Điều kiện tiên quyết: Đăng ký ứng dụng trong Azure Active Directory. Trước khi kết nối với API Dynamics 365, bạn cần đăng ký ứng dụng trong tenant Azure AD. Cấp cho ứng dụng quyền được ủy quyền để truy cập Dynamics 365 Finance & Operations, chẳng hạn như Financials.ReadWrite.All hoặc một quyền tùy chỉnh.
Cấu hình Application ID trong Dynamics 365. Trong Dynamics 365, vào System administration > Setup > Azure Active Directory applications. Thêm Application (client) ID từ ứng dụng đã đăng ký trong Azure AD và liên kết ứng dụng với tài khoản người dùng có vai trò bảo mật cần thiết để đọc các thực thể dữ liệu.
Lấy OAuth 2.0 Access Token. Viết tập lệnh, chẳng hạn bằng PowerShell hoặc Python, để xác thực với endpoint của Microsoft identity platform. Dùng thông tin xác thực của ứng dụng (client ID và secret) để yêu cầu access token cho URL tài nguyên Dynamics 365.
Tìm URL môi trường Dynamics 365. Xác định URL cơ sở của môi trường Dynamics 365. Web API endpoint thường có dạng: https://[YourD365FinanceAndOpsURL].dynamics.com/data.
Tạo và gửi yêu cầu OData API. Với mỗi hoạt động trong số 12 hoạt động bắt buộc, tạo một URL yêu cầu OData GET riêng. Dùng $select để chỉ lấy các cột cần thiết và $filter để chỉ định khoảng ngày cùng các điều kiện trạng thái. Thêm token xác thực lấy ở bước 3 vào authorization header của từng yêu cầu dưới dạng Bearer token.
Viết tập lệnh trích xuất. Tạo tập lệnh chạy lần lượt các yêu cầu OData. Tập lệnh cần xử lý xác thực, gửi từng yêu cầu GET và lưu dữ liệu JSON trả về. Lưu ý giới hạn API và thêm thời gian chờ nếu cần.
Xử lý phân trang API. Dynamics 365 chia kết quả lớn thành nhiều trang. Tập lệnh cần kiểm tra thuộc tính @odata.nextLink trong phản hồi. Nếu có, hãy gửi yêu cầu tiếp theo đến URL đó để lấy trang dữ liệu kế tiếp. Tiếp tục cho đến khi không còn nextLink.
Chuyển đổi và hợp nhất dữ liệu. Xử lý phản hồi JSON từ từng API trong số 12 API. Với mỗi hoạt động, tạo bản ghi theo cấu trúc thống nhất gồm ReturnCaseId, ActivityName, EventTime và các thuộc tính khác. Ví dụ, với sự kiện 'Return Order Created', ánh xạ ReturnOrderNumber vào ReturnCaseId, đặt ActivityName là 'Return Order Created' và ánh xạ createdDateTime vào EventTime. Gộp các bản ghi đã chuyển đổi từ tất cả yêu cầu thành một danh sách hoặc bảng.
Chuẩn hóa dấu thời gian. Đảm bảo mọi giá trị EventTime dùng cùng định dạng, tốt nhất là UTC theo dạng YYYY-MM-DDTHH:MM:SSZ. Xử lý các bản ghi thiếu dấu thời gian hoặc có dấu thời gian không hợp lệ khi cần.
Xuất event log hoàn chỉnh. Sau khi thu thập và chuyển đổi toàn bộ dữ liệu thành một tập dữ liệu thống nhất, hãy xuất ra tệp CSV. Đảm bảo tiêu đề cột đúng với yêu cầu của ProcessMind: ReturnCaseId, ActivityName, EventTime, ResponsibleUser, DispositionCode, v.v. Tệp đã sẵn sàng để tải lên.

Cấu hình

URL API Endpoint: URL cơ sở của phiên bản Dynamics 365 Finance & Operations. URL có dạng https://[YourEnvironmentName].dynamics.com/data.
Ứng dụng Azure AD: Cần đăng ký ứng dụng trong Azure AD, có client ID và secret. Ứng dụng cần quyền API để truy cập các thực thể dữ liệu Dynamics 365.
Lọc theo khoảng ngày: Cần áp dụng bộ lọc ngày trong mọi lệnh gọi API bằng tham số OData $filter trên trường ngày phù hợp, chẳng hạn createdDateTime hoặc modifiedDateTime. Thông thường, nên bắt đầu với dữ liệu trong 3 đến 6 tháng gần nhất để việc trích xuất dễ quản lý.
Bộ lọc công ty: Để trích xuất dữ liệu cho một pháp nhân cụ thể, hãy thêm tham số truy vấn cross-company=true, sau đó dùng $filter trên trường dataAreaId. Ví dụ: ?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'.
Thiết lập phân trang: Dùng header Prefer: odata.maxpagesize=[value] trong yêu cầu để kiểm soát số bản ghi trả về mỗi trang. Giá trị thường dùng là 1000 đến 5000. Cách này giúp tránh API hết thời gian chờ khi xử lý các thực thể lớn.
Giới hạn tần suất API: Lưu ý giới hạn bảo vệ dịch vụ API của Dynamics 365. Tập lệnh trích xuất cần xử lý phản hồi 429 (Too Many Requests), thường bằng cách tăng dần thời gian chờ hoặc tạm dừng rồi thử lại.

Truy vấn mẫu graphql

/*
This is a conceptual guide representing multiple, distinct OData API calls. 
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially, 
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/

// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";

// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode

// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser

// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser

// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser

// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId

// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId

// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser

// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser

// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser

// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser

// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser

// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser

Các bước

Bật TDS Endpoint: Đảm bảo TDS (Tabular Data Stream) endpoint được bật cho môi trường Dynamics 365 Dataverse. Quản trị viên hệ thống có thể bật endpoint này trong Power Platform admin center, tại Environment > Settings > Features.
Tìm URL môi trường: Tìm URL môi trường của bạn. URL thường có dạng yourorg.crm.dynamics.com. Tên máy chủ TDS endpoint là URL này kèm cổng 5558, ví dụ yourorg.crm.dynamics.com,5558.
Kết nối bằng ứng dụng SQL: Dùng ứng dụng SQL hỗ trợ TDS, chẳng hạn SQL Server Management Studio (SSMS) hoặc Azure Data Studio.
Xác thực: Kết nối với máy chủ bằng tài khoản Azure Active Directory có quyền phù hợp trong môi trường Dataverse, thường là System Administrator hoặc System Customizer.
Chuẩn bị truy vấn: Sao chép toàn bộ truy vấn SQL trong phần query của tài liệu này vào cửa sổ truy vấn mới trong ứng dụng SQL.
Đặt tham số: Tìm các chỗ giữ chỗ trong truy vấn. Thay '{StartDate}' và '{EndDate}' bằng khoảng ngày cần trích xuất, chẳng hạn '2023-01-01' và '2023-12-31'. Đồng thời cập nhật các giá trị giữ chỗ cho mã trạng thái hoặc mã lý do để khớp với cấu hình Dynamics 365 của bạn.
Chạy truy vấn: Chạy truy vấn đã chỉnh sửa trên cơ sở dữ liệu Dataverse. Thời gian chạy tùy thuộc vào lượng dữ liệu và khoảng ngày đã chọn.
Kiểm tra kết quả: Khi truy vấn chạy xong, kiểm tra tập dữ liệu trả về để đảm bảo có các cột cần thiết: ReturnCaseId, ActivityName, EventTime và các thuộc tính được đề xuất.
Xuất event log: Xuất kết quả truy vấn thành tệp CSV. Hầu hết ứng dụng SQL đều có chức năng lưu kết quả trực tiếp vào tệp. Đảm bảo tệp được lưu với mã hóa UTF-8.
Tải lên ProcessMind: Tệp CSV đã xuất sẵn sàng để tải lên ProcessMind dưới dạng event log mới phục vụ phân tích process mining.

Cấu hình

Điều kiện tiên quyết: Bạn cần có tài khoản người dùng với ít nhất quyền đọc các bảng Dataverse liên quan, chẳng hạn SalesTable, SalesLine, CustInvoiceJour. Quyền thường được quản lý qua vai trò bảo mật như System Administrator hoặc vai trò tùy chỉnh có đủ quyền trên bảng.
TDS Endpoint: TDS endpoint của Dataverse phải được bật cho môi trường. Tính năng này cho phép chạy truy vấn SQL chỉ đọc trực tiếp trên cơ sở dữ liệu Dataverse.
Khoảng ngày: Truy vấn có các chỗ giữ chỗ '{StartDate}' và '{EndDate}'. Để phân tích ban đầu, nên chọn khoảng từ 3 đến 6 tháng. Khoảng này tạo ra tập dữ liệu đại diện mà không gây ảnh hưởng đến hiệu năng.
Bộ lọc công ty: Truy vấn hiện tại chạy trên tất cả pháp nhân mà người dùng có quyền truy cập. Để phân tích một công ty, hãy bỏ chú thích và thêm mệnh đề WHERE lọc theo trường DATAAREAID trong từng phần của câu lệnh UNION ALL, chẳng hạn AND st.DATAAREAID = '[YourCompanyID]'.
Chỗ giữ chỗ cho logic tùy chỉnh: Truy vấn có các chỗ giữ chỗ như [YourReplaceCode1] cho mã lý do và ghi chú về cách liên kết đơn hàng thay thế. Bạn cần cấu hình các giá trị này theo quy trình kinh doanh và thiết lập Dynamics 365 của mình.
Hiệu năng: Truy vấn trực tiếp trên TDS endpoint có thể chậm khi xử lý tập dữ liệu lớn. Kết nối được tối ưu cho truy vấn phân tích, nhưng các phép nối phức tạp trên hàng triệu dòng có thể hết thời gian chờ. Nên áp dụng bộ lọc ngày chặt chẽ.

Truy vấn mẫu sql

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Return Order Created' AS ActivityName,
    st.CREATEDDATETIME AS EventTime,
    st.CREATEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Return Order Confirmed' AS ActivityName,
    st.MODIFIEDDATETIME AS EventTime,
    st.MODIFIEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Arrival Journal Created' AS ActivityName,
    wjt.CREATEDDATETIME AS EventTime,
    wjt.CREATEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Item Received' AS ActivityName,
    wjt.POSTEDDATETIME AS EventTime,
    wjt.POSTEDUSERID AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Quality Order Generated' AS ActivityName,
    iqot.CREATEDDATETIME AS EventTime,
    iqot.CREATEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Disposition Code Applied' AS ActivityName,
    iqot.VALIDATEDDATETIME AS EventTime,
    iqot.VALIDATEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Credit Note Created' AS ActivityName,
    st.MODIFIEDDATETIME AS EventTime,
    st.MODIFIEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Credit Note Posted' AS ActivityName,
    cij.CREATEDDATETIME AS EventTime,
    cij.CREATEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    ro.RETURNITEMNUM AS ReturnCaseId,
    'Replacement Order Created' AS ActivityName,
    replacement_so.CREATEDDATETIME AS EventTime,
    replacement_so.CREATEDBY AS ResponsibleUser,
    NULL AS DispositionCode,
    NULL AS ReturnReasonCode,
    replacement_so.SALESORIGINID AS ReturnChannel,
    replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    ro.RETURNITEMNUM AS ReturnCaseId,
    'Replacement Item Shipped' AS ActivityName,
    cpsj.CREATEDDATETIME AS EventTime,
    cpsj.CREATEDBY AS ResponsibleUser,
    NULL AS DispositionCode,
    NULL AS ReturnReasonCode,
    replacement_so.SALESORIGINID AS ReturnChannel,
    cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Return Order Closed' AS ActivityName,
    st.MODIFIEDDATETIME AS EventTime,
    st.MODIFIEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'

UNION ALL

SELECT
    st.RETURNITEMNUM AS ReturnCaseId,
    'Return Order Cancelled' AS ActivityName,
    st.MODIFIEDDATETIME AS EventTime,
    st.MODIFIEDBY AS ResponsibleUser,
    sl.RETURNDISPOSITIONCODEID AS DispositionCode,
    sl.RETURNREASONCODEID AS ReturnReasonCode,
    st.SALESORIGINID AS ReturnChannel,
    sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}';

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

Dùng mẫu này để thu thập dữ liệu dễ dàng hơn và bắt đầu tìm hiểu cách cải thiện quy trình trả hàng, hoàn tiền. Bắt đầu ngay hôm nay để xử lý nhanh hơn và nâng cao sự hài lòng của khách hàng.

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

Tải mẫu xuống

Chấm dứt tình trạng chậm trễ khi trả hàng, hoàn tiền. Tối ưu quy trình ngay hôm nay

Rút ngắn 30% thời gian xử lý và nâng cao sự hài lòng của khách hàng.

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

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

Mẫu dữ liệu cho quy trình trả hàng và hoàn tiền

Mẫu dữ liệu cho quy trình trả hàng và hoàn tiền

Thuộc tính của quy trình trả hàng và hoàn tiền

Hoạt động trong quy trình trả hàng và hoàn tiền

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

Trích xuất dữ liệu qua OData Endpoint của Web API Dynamics 365

Các bước

Cấu hình

Truy vấn mẫu graphql

Truy vấn SQL trực tiếp qua Dataverse TDS Endpoint

Các bước

Cấu hình

Truy vấn mẫu sql

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

Chấm dứt tình trạng chậm trễ khi trả hàng, hoàn tiền. Tối ưu quy trình ngay hôm nay