> Cải tiến quy trình liên tục > Quy trình xử lý trả hàng và hoàn tiền > NetSuite > Mẫu dữ liệu

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

NetSuite

Các thuộc tính của quy trình xử lý trả hàng và hoàn tiền(20) Các hoạt động trong quy trình xử lý 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 xử lý trả hàng và hoàn tiền

Mẫu này hướng dẫn bạn chuẩn bị các dữ liệu cần thiết để phân tích hiệu quả quy trình trả hàng và hoàn tiền. Mẫu nêu rõ những thuộc tính cốt lõi cần thu thập, các hoạt động quan trọng cần theo dõi và cách trích xuất thông tin. Dùng tài nguyên này để chuẩn bị dữ liệu NetSuite cho hoạt động process mining.

Các thuộc tính nên thu thập
Các hoạt động chính cần theo dõi
Hướng dẫn trích xuất dữ liệu từ NetSuite

Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Tải mẫu xuống

Các thuộc tính của quy trình xử lý trả hàng và hoàn tiền

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

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

	Tên	Mô tả
	Return Case ID ReturnCaseId	Mã định danh duy nhất cho một trường hợp khách hàng trả hàng hoặc yêu cầu hoàn tiền, liên kết mọi hoạt động liên quan từ lúc bắt đầu đến khi đóng hồ sơ.
Mô tả Return Case ID là mã định danh chính để theo dõi toàn bộ quá trình trả hàng. Mỗi mã duy nhất tương ứng với một yêu cầu cho phép trả hàng, giúp phân tích đầy đủ các sự kiện liên quan như nhận hàng, kiểm tra và xử lý hoàn tiền. Trong process mining, mã này cần thiết để dựng lại toàn bộ luồng quy trình cho từng trường hợp trả hàng, tính thời gian xử lý và xác định các sai lệch ở cấp hồ sơ. Vì sao điều này quan trọng Đây là thuộc tính nền tảng của process mining, vì nó kết nối từng sự kiện thành các trường hợp quy trình xuyên suốt, giúp phân tích luồng quy trình và hiệu suất. Lấy dữ liệu ở đâu Thông thường, đây là Internal ID hoặc Transaction ID của bản ghi Return Authorization trong NetSuite. Ví dụ RMA-0012345RMA-0012346RMA-0012347
	Tên hoạt động ActivityName	Tên của sự kiện hoặc bước nghiệp vụ cụ thể trong quy trình trả hàng, chẳng hạn 'Kiểm tra sản phẩm trả về' hoặc 'Hoàn tất hoàn tiền'.
Mô tả Tên hoạt động mô tả một bước hoặc cột mốc riêng trong vòng đời trả hàng và hoàn tiền. Các sự kiện được sắp xếp theo thời gian để dựng luồng quy trình. Phân tích thứ tự và tần suất hoạt động giúp xác định các luồng phổ biến nhất, điểm nghẽn giữa các bước và những công việc phải làm lại hoặc lặp lại. Ví dụ: 'Tạo yêu cầu cho phép trả hàng', 'Nhận hàng trả về' và 'Phê duyệt Credit Memo'. 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. Đây là yếu tố cần thiết để trực quan hóa sơ đồ quy trình, phân tích các biến thể trong luồng và tìm điểm nghẽn hoặc vòng lặp làm lại. Lấy dữ liệu ở đâu Thuộc tính này thường được xác định từ thay đổi trạng thái của các bản ghi giao dịch như Return Authorization và Credit Memo, hoặc từ hành động cụ thể của người dùng được ghi trong ghi chú hệ thống hay nhật ký sự kiện tùy chỉnh. Ví dụ Tạo yêu cầu cho phép trả hàngNhận hàng trả vềKiểm tra sản phẩm trả vềHoàn tất hoàn tiềnĐóng Return Authorization
	Thời điểm sự kiện EventTimestamp	Ngày và giờ chính xác khi hoạt động diễn ra, làm cơ sở sắp xếp trình tự thời gian của quy trình.
Mô tả Thời điểm sự kiện ghi lại chính xác lúc một hoạt động diễn ra. Dữ liệu này rất quan trọng để sắp xếp sự kiện đúng thứ tự và thực hiện mọi phân tích theo thời gian. Dữ liệu được dùng để tính thời lượng giữa các hoạt động, tổng thời gian xử lý hồ sơ và thời gian chờ. Đây là những chỉ số thiết yếu để theo dõi hiệu suất, phân tích điểm nghẽn và kiểm tra mức độ đáp ứng SLA. Thời điểm cần chính xác để đảm bảo kết quả process mining đáng tin cậy. Vì sao điều này quan trọng Thuộc tính này cho biết thứ tự thời gian của các sự kiện, cần thiết để khám phá luồng quy trình và tính các chỉ số hiệu suất như thời gian xử lý và thời gian chờ. Lấy dữ liệu ở đâu Thông tin này thường lấy từ các trường 'Date Created' hoặc 'Last Modified Date' trên bản ghi NetSuite, hoặc từ dấu thời gian trong danh sách System Notes gắn với giao dịch. Ví dụ 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:12:05Z
	Hệ thống nguồn SourceSystem	Hệ thống dùng để trích xuất dữ liệu, giúp theo dõi nguồn gốc dữ liệu.
Mô tả Thuộc tính này xác định nguồn gốc của dữ liệu quy trình. Trong trường hợp này, giá trị thường là 'NetSuite'. Việc ghi rõ hệ thống nguồn rất quan trọng khi dữ liệu được kết hợp từ nhiều hệ thống, giúp theo dõi rõ nguồn gốc và luồng dữ liệu. Vì sao điều này quan trọng Xác định nguồn gốc dữ liệu, rất quan trọng cho việc quản trị dữ liệu, xử lý sự cố và các trường hợp kết hợp dữ liệu từ nhiều hệ thống để có cái nhìn đầy đủ về quy trình. Lấy dữ liệu ở đâu Đây là giá trị cố định ('NetSuite'), thường được thêm trong quá trình trích xuất và chuyển đổi dữ liệu. Ví dụ NetSuiteNetSuite ERP
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Thời điểm cho biết lần gần nhất dữ liệu của quy trình này được làm mới hoặc cập nhật.
Mô tả Thuộc tính này ghi lại lần gần nhất tập dữ liệu được cập nhật từ hệ thống nguồn. Đây là siêu dữ liệu quan trọng, cho người dùng biết dữ liệu phân tích còn mới đến mức nào. Hiển thị thông tin này trên bảng điều khiển giúp người dùng hiểu rõ giới hạn của dữ liệu và đưa ra quyết định dựa trên thời điểm dữ liệu được cập nhật. Vì sao điều này quan trọng Cho biết dữ liệu được cập nhật gần đây đến đâu, giúp người dùng tin tưởng kết quả phân tích và hiểu mức độ phù hợp với tình hình vận hành hiện tại. Lấy dữ liệu ở đâu Dấu thời gian này được tạo và thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL). Ví dụ 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Loại trả hàng ReturnType	Phân loại yêu cầu trả hàng dựa trên lý do khách hàng cung cấp.
Mô tả Loại trả hàng phân nhóm các trường hợp theo lý do, chẳng hạn 'Sản phẩm lỗi', 'Sai kích cỡ', 'Đổi ý' hoặc 'Không đúng mô tả'. Việc phân loại này rất quan trọng để tìm nguyên nhân gốc rễ. Phân tích chỉ số quy trình theo từng loại trả hàng giúp doanh nghiệp phát hiện vấn đề về chất lượng sản phẩm, mô tả chưa chính xác hoặc lỗi xử lý đơn hàng. Thuộc tính này là yếu tố chính của bảng điều khiển 'Hiệu suất trả hàng theo loại và kênh'. Vì sao điều này quan trọng Giúp tìm nguyên nhân gốc rễ của việc trả hàng để cải tiến sản phẩm, nội dung tiếp thị hoặc quy trình xử lý đơn hàng, qua đó giảm số lượng hàng trả lại. Lấy dữ liệu ở đâu Thông tin này thường nằm trong trường tùy chỉnh hoặc trường danh sách/bản ghi tiêu chuẩn trên biểu mẫu Return Authorization, nơi ghi nhận lý do trả hàng. Ví dụ Sản phẩm bị lỗiGửi sai sản phẩmKhách hàng không hài lòngSai kích cỡ/màu sắc
	Nhân viên xử lý ProcessingAgent	Nhân viên hoặc người dùng thực hiện một hoạt động cụ thể trong quy trình trả hàng.
Mô tả Nhân viên xử lý là người chịu trách nhiệm thực hiện một công việc cụ thể, chẳng hạn phê duyệt yêu cầu trả hàng hoặc kiểm tra sản phẩm. Thuộc tính này rất quan trọng để phân tích hiệu suất ở cấp người dùng. Thuộc tính giúp xác định nhân viên có hiệu suất cao, những lĩnh vực cần đào tạo thêm và sự mất cân đối trong phân bổ khối lượng công việc giữa các thành viên. Phân tích hoạt động theo nhân viên là yếu tố chính của bảng điều khiển 'Hiệu suất quy trình trả hàng theo phòng ban'. Vì sao điều này quan trọng Giúp phân tích hiệu suất cá nhân và nhóm, cân bằng khối lượng công việc và xác định nhu cầu đào tạo, từ đó tác động trực tiếp đến hiệu quả vận hành. Lấy dữ liệu ở đâu Có thể lấy dữ liệu từ các trường như 'Created By', 'Approved By' hoặc trường người dùng trong danh sách System Notes trên giao dịch NetSuite. Ví dụ Alice JohnsonBob WilliamsCharlie Brown
	Phòng ban Department	Phòng ban hoặc nhóm phụ trách xử lý hồ sơ trả hàng ở một giai đoạn cụ thể.
Mô tả Thuộc tính này gắn các hoạt động trong quy trình với một phòng ban cụ thể, chẳng hạn 'Dịch vụ khách hàng', 'Kho' hoặc 'Tài chính'. Đây là thông tin cần thiết để hiểu việc bàn giao giữa các nhóm và xác định điểm nghẽn ở từng phòng ban. Bằng cách phân tích thời gian hồ sơ được xử lý hoặc chờ tại một phòng ban, tổ chức có thể tìm ra nguyên nhân chậm trễ và phân bổ tài nguyên hợp lý hơn. Đây là chiều phân tích chính của bảng điều khiển 'Hiệu suất quy trình trả hàng theo phòng ban'. 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 bộ phận, làm rõ chậm trễ khi bàn giao giữa các phòng ban và điểm nghẽn trong từng phòng ban. Lấy dữ liệu ở đâu Có thể xác định từ thông tin người dùng hoặc nhân viên gắn với hoạt động, hoặc từ trường 'Department' trên giao dịch. Thông tin này thường được thiết lập trong hồ sơ nhân viên trên NetSuite. Ví dụ KhoHỗ trợ khách hàngTài chínhĐảm bảo chất lượng
	Số tiền hoàn thực tế ActualRefundAmount	Số tiền cuối cùng thực tế đã hoàn cho khách hàng.
Mô tả Thuộc tính này thể hiện số tiền thực tế được ghi có hoặc hoàn cho khách hàng, theo bản ghi Credit Memo hoặc giao dịch hoàn tiền. Số tiền này có thể khác với số tiền yêu cầu do các điều chỉnh như phí nhập kho, phí vận chuyển hoặc hoàn tiền một phần cho hàng bị hư hỏng. Đây là thông tin thiết yếu cho báo cáo tài chính và tính KPI 'Tỷ lệ chênh lệch số tiền hoàn trả'. 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, cần thiết cho đối soát tài chính và phân tích độ chính xác của khoản hoàn tiền. Lấy dữ liệu ở đâu Giá trị này lấy từ trường 'Total' trên giao dịch Credit Memo được tạo từ Return Authorization. Ví dụ 99.99140.000.00
	Trạng thái trả hàng ReturnAuthorizationStatus	Trạng thái hiện tại của yêu cầu cho phép trả hàng, chẳng hạn 'Pending Approval', 'Approved' hoặc 'Closed'.
Mô tả Thuộc tính này cho biết trạng thái hiện tại của hồ sơ trả hàng trong vòng đời xử lý. Đây là thông tin cơ bản để nắm tiến độ và phân nhóm hồ sơ. Ví dụ, phân tích thời gian ở trạng thái 'Pending Receipt' có thể làm lộ ra chậm trễ vận chuyển, còn thời gian dài ở trạng thái 'Pending Approval' có thể cho thấy điểm nghẽn nội bộ. Thuộc tính này cũng giúp xác định kết quả cuối cùng của yêu cầu trả hàng, chẳng hạn 'Closed' hoặc 'Rejected'. Vì sao điều này quan trọng Cho biết mỗi yêu cầu trả hàng đang ở bước nào, giúp phân tích số lượng hồ sơ theo trạng thái, thời gian ở từng trạng thái và kết quả quy trình. Lấy dữ liệu ở đâu Thuộc tính này tương ứng với trường 'Status' hoặc trường tương tự trên bản ghi Return Authorization trong NetSuite. Ví dụ Đang chờ phê duyệtĐang chờ nhận hàngĐã phê duyệtĐã từ chốiĐã đóng
	Chênh lệch số tiền hoàn trả RefundAmountDiscrepancy	Khoản chênh lệch được tính giữa số tiền hoàn trả yêu cầu và số tiền thực tế đã hoàn.
Mô tả Chỉ số này được tính bằng cách lấy 'Số tiền hoàn trả yêu cầu' trừ 'Số tiền hoàn thực tế'. Giá trị khác 0 cho thấy khoản tiền đã được điều chỉnh trong quy trình, chẳng hạn do phí nhập kho hoặc hàng bị hư hỏng. Thuộc tính này hỗ trợ phân tích KPI 'Tỷ lệ chênh lệch số tiền hoàn trả' và giúp đánh dấu các trường hợp có điều chỉnh tài chính đáng kể để xem xét thêm. Vì sao điều này quan trọng Làm rõ các khoản điều chỉnh tài chính trong quy trình trả hàng, giúp phân tích nguyên nhân chênh lệch và xác định việc điều chỉnh có nhất quán, hợp lý hay không. Lấy dữ liệu ở đâu Đây là thuộc tính được tính toán. Công thức: `RequestedRefundAmount` - `ActualRefundAmount`. Ví dụ 0.0010.00-5.00
	Customer ID 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ả Customer ID liên kết giao dịch trả hàng với một khách hàng cụ thể. Nhờ đó, bạn có thể phân tích theo từng khách hàng, chẳng hạn xác định những khách thường xuyên trả hàng, dấu hiệu có thể cho thấy họ không hài lòng hoặc có hành vi gian lận. Bạn cũng có thể phân nhóm hiệu quả quy trình theo loại khách hàng hoặc giá trị khách hàng để ưu tiên phục vụ các khách hàng quan trọng. Vì sao điều này quan trọng Giúp phân tích hành vi trả hàng theo từng khách hàng và phân nhóm quy trình dựa trên các thuộc tính như phân khúc hoặc giá trị vòng đời của khách hàng. Lấy dữ liệu ở đâu Đây là trường 'Customer' hoặc 'Entity' trên phần đầu của bản ghi Return Authorization trong NetSuite. Ví dụ CUST-001CUST-002CUST-003
	Đáp ứng SLA IsSlaCompliant	Cờ được tính toán để cho biết khoản hoàn tiền có được xử lý trong thời hạn SLA đã đặt hay không.
Mô tả Thuộc tính đúng/sai này được tính bằng cách so sánh mốc thời gian 'Đã xử lý hoàn tiền' với 'Ngày mục tiêu hoàn tiền theo SLA'. Nếu khoản hoàn tiền được xử lý vào hoặc trước ngày mục tiêu, giá trị là đúng; nếu không, giá trị là sai. Cờ này giúp tạo báo cáo và dashboard tuân thủ, chẳng hạn dashboard 'Theo dõi tuân thủ SLA hoàn tiền', đồng thời được dùng để tính KPI 'Tỷ lệ đạt SLA hoàn tiền'. Vì sao điều này quan trọng Cho biết rõ từng trường hợp có đạt SLA hay không, giúp bạn dễ theo dõi, báo cáo và phân tích tỷ lệ tuân thủ theo thời gian. Lấy dữ liệu ở đâu Thuộc tính này được tính trong quá trình chuyển đổi dữ liệu hoặc ngay trong công cụ process mining. Logic: `EventTimestamp` của 'Đã xử lý hoàn tiền' <= `RefundSlaTargetDate`. Ví dụ truefalse
	Được tự động hóa IsAutomated	Cờ đúng/sai cho biết hoạt động có được hệ thống tự động thực hiện hay không.
Mô tả Thuộc tính này cho biết hoạt động do người dùng hay hệ thống tự động, tập lệnh hoặc workflow thực hiện. Ví dụ, sự kiện 'Đã tạo yêu cầu trả hàng' ban đầu có thể được tự động hóa qua cổng thông tin khách hàng, trong khi 'Đã kiểm tra hàng' là hoạt động thủ công. Theo dõi mức độ tự động hóa giúp xác định cơ hội tự động hóa các bước thủ công và đo lường hiệu quả đạt được từ những phần đã tự động hóa. Vì sao điều này quan trọng Giúp phân biệt tác vụ thủ công với tác vụ tự động, từ đó xác định cơ hội tự động hóa và đo lường tác động của các sáng kiến chuyển đổi số. Lấy dữ liệu ở đâu Có thể suy ra từ người dùng gắn với sự kiện. Trong NetSuite, các sự kiện do hệ thống tạo thường gắn với một người dùng hệ thống cụ thể hoặc ID tập lệnh. Ví dụ truefalse
	Kênh trả hàng ReturnChannel	Kênh khách hàng dùng để mua hàng ban đầu hoặc bắt đầu yêu cầu trả hàng.
Mô tả Kênh trả hàng cho biết nguồn phát sinh yêu cầu, chẳng hạn 'Trực tuyến', 'Tại cửa hàng' hoặc 'Sàn thương mại điện tử'. Mỗi kênh có thể có quy trình trả hàng, chi phí và kỳ vọng của khách hàng khác nhau. Phân tích hiệu suất theo kênh giúp doanh nghiệp cải tiến từng quy trình, phân bổ tài nguyên hiệu quả và hiểu các vấn đề riêng của từng kênh. Đây là thuộc tính chính của bảng điều khiển 'Hiệu suất trả hàng theo loại và kênh'. 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 kinh doanh, qua đó phát hiện điểm kém hiệu quả hoặc cách làm tốt riêng trong việc tiếp nhận và xử lý hàng trả lại. Lấy dữ liệu ở đâu Thông tin này thường lấy từ bản ghi Sales Order ban đầu liên quan đến yêu cầu trả hàng. Dữ liệu có thể nằm trong trường 'Channel' hoặc 'Location'. Ví dụ Cửa hàng trực tuyếnCửa hàng bán lẻSàn AmazonĐơn hàng qua điện thoại
	Mã sản phẩm ProductIdentifier	Mã định danh duy nhất của sản phẩm được trả lại, chẳng hạn SKU hoặc Item Number.
Mô tả Thuộc tính này xác định sản phẩm cụ thể trong yêu cầu trả hàng. Phân tích hàng trả lại theo sản phẩm rất quan trọng để tìm các mặt hàng có tỷ lệ trả hàng cao, có thể do lỗi chất lượng, mô tả chưa rõ hoặc vấn đề khác. Dữ liệu này cho phép phân tích sâu hiệu suất sản phẩm và hỗ trợ quyết định về phát triển sản phẩm, tìm nguồn cung ứng và tiếp thị. Vì sao điều này quan trọng Liên kết dữ liệu quy trình trả hàng với từng sản phẩm cụ thể, giúp tìm nguyên nhân gốc rễ của vấn đề liên quan đến sản phẩm và giảm tỷ lệ trả hàng nói chung. Lấy dữ liệu ở đâu Thông tin này nằm trong danh sách phụ 'Items' của bản ghi Return Authorization, tương ứng với trường 'Item'. Ví dụ SKU-TEE-BL-LPROD-00543ITEM-987123
	Ngày mục tiêu hoàn tiền theo SLA RefundSlaTargetDate	Ngày dự kiến hoàn tất xử lý khoản hoàn tiền theo cam kết mức dịch vụ.
Mô tả Ngày mục tiêu hoàn tiền theo SLA là mốc thời gian được tính để thể hiện cam kết xử lý khoản hoàn tiền với khách hàng. Thông thường, ngày này được tính bằng cách cộng một khoảng thời gian định trước, chẳng hạn 5 ngày làm việc, vào một sự kiện quan trọng như 'Đã nhận hàng' hoặc 'Đã duyệt hoàn tiền'. Thuộc tính này cần thiết cho dashboard 'Theo dõi tuân thủ SLA hoàn tiền' và KPI 'Tỷ lệ đạt SLA hoàn tiền', giúp doanh nghiệp đo lường kết quả so với cam kết. Vì sao điều này quan trọng Giúp đo lường định lượng kết quả thực hiện cam kết với khách hàng, yếu tố quan trọng để duy trì sự hài lòng và niềm tin của khách hàng. Lấy dữ liệu ở đâu Ngày này thường không có sẵn dưới dạng trường tiêu chuẩn. Bạn cần tính bằng cách cộng khoảng thời gian SLA đã định trước, chẳng hạn 5 ngày, vào một mốc thời gian quan trọng như ngày 'Đã nhận hàng'. Ví dụ 2023-11-01T23:59:59Z2023-11-05T23:59:59Z2023-11-10T23:59:59Z
	Số tiền hoàn trả yêu cầu RequestedRefundAmount	Số tiền hoàn trả ban đầu được yêu cầu hoặc dự kiến cho đơn trả hàng.
Mô tả Thuộc tính này lưu số tiền hoàn dự kiến khi quy trình bắt đầu, thường dựa trên giá mua ban đầu của các mặt hàng được trả lại. Đây là mức cơ sở để so sánh với số tiền hoàn thực tế. KPI 'Tỷ lệ chênh lệch số tiền hoàn trả' so sánh trực tiếp giá trị này với Số tiền hoàn thực tế để xác định chênh lệch do phí nhập kho, hoàn tiền một phần hoặc các điều chỉnh khác. Vì sao điều này quan trọng Cung cấp mức cơ sở cho phân tích tài chính, giúp theo dõi chênh lệch giữa số tiền hoàn dự kiến và thực tế, đồng thời xác định lý do điều chỉnh. Lấy dữ liệu ở đâu Giá trị này được tính từ các trường 'Amount' hoặc 'Rate' trên từng dòng hàng của giao dịch Return Authorization. Ví dụ 99.99150.0025.50
	Tình trạng hàng trả lại ReturnCondition	Tình trạng được xác định khi kiểm tra hàng trả lại, chẳng hạn 'Mới', 'Hư hỏng' hoặc 'Đã qua sử dụng'.
Mô tả Thuộc tính này ghi nhận kết quả kiểm tra thực tế hàng trả lại. Tình trạng hàng quyết định các bước tiếp theo, chẳng hạn hoàn tiền toàn bộ, nhập lại kho hay loại bỏ sản phẩm. Dashboard 'Chất lượng đánh giá tình trạng hàng trả lại' tập trung phân tích tính nhất quán và thời gian xử lý khâu đánh giá này. Đây cũng là thông tin thiết yếu để đối soát tài chính và quản lý hàng tồn kho. Vì sao điều này quan trọng Ảnh hưởng trực tiếp đến kết quả tài chính của việc trả hàng và các bước xử lý hàng tồn kho tiếp theo. Đánh giá không nhất quán có thể gây thất thoát tài chính và phát sinh công việc làm lại. Lấy dữ liệu ở đâu Đây có thể là trường tùy chỉnh trên bản ghi Item Receipt hoặc Return Authorization, do nhân viên kho điền khi kiểm tra hàng. Ví dụ Có thể bán lạiHư hỏng, còn nguyên hộpĐã qua sử dụng, tình trạng tốtThiếu bộ phận
	Tuân thủ chính sách ReturnPolicyAdherence	Cho biết việc trả hàng có tuân thủ chính sách trả hàng đã được công ty ban hành hay không.
Mô tả Thuộc tính dạng đúng/sai hoặc phân loại này cho biết yêu cầu trả hàng có đáp ứng các tiêu chí đã định trước hay không, chẳng hạn thời hạn trả hàng, tình trạng sản phẩm và bằng chứng mua hàng. Thuộc tính này giúp theo dõi việc tuân thủ và xử lý các trường hợp ngoại lệ. Dashboard 'Các trường hợp ngoại lệ về tuân thủ chính sách trả hàng' sử dụng thông tin này để làm nổi bật những trường hợp cần xử lý hoặc xem xét riêng, giúp giảm rủi ro và áp dụng quy định nhất quán. Vì sao điều này quan trọng Giúp theo dõi và thực thi chính sách trả hàng, giảm rủi ro tài chính từ các trường hợp không tuân thủ, đồng thời bảo đảm quy định được áp dụng công bằng và nhất quán. Lấy dữ liệu ở đâu Gần như chắc chắn đây là trường tùy chỉnh, có thể là hộp kiểm hoặc danh sách, trên bản ghi Return Authorization và được quản lý qua workflow. Ví dụ Tuân thủKhông tuân thủ, quá thời hạnĐã duyệt ngoại lệ

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

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

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

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

	Hoạt động	Mô tả
	Đóng Return Authorization	Đây là hoạt động cuối cùng, đánh dấu việc hoàn tất các thủ tục và đóng hồ sơ trả hàng sau khi xử lý xong. Có thể xác định hoạt động này qua lần thay đổi trạng thái cuối cùng trên bản ghi Return Authorization sang 'Closed'.
Vì sao điều này quan trọng Là điểm kết thúc chính thức của quy trình, hoạt động này cần thiết để tính tổng thời gian xử lý từ đầu đến cuối và tìm các trường hợp vẫn mở dù đã hoàn tiền từ lâu. Lấy dữ liệu ở đâu Có thể xác định từ ghi chú hệ thống hoặc lịch sử workflow của bản ghi ReturnAuthorization khi trường 'Status' được cập nhật sang trạng thái kết thúc cuối cùng, chẳng hạn 'Closed'. Thu thập Phát hiện khi trạng thái của bản ghi ReturnAuthorization chuyển sang 'Closed'. Loại sự kiện inferred
	Hoàn tất hoàn tiền	Đây là bước quyết toán tài chính cuối cùng, khi tiền được trả lại cho khách hàng. Sự kiện được ghi nhận rõ ràng bằng cách tạo giao dịch Customer Refund từ Credit Memo.
Vì sao điều này quan trọng Hoạt động này rất quan trọng để đo mức độ đáp ứng SLA và sự hài lòng của khách hàng. Thời gian từ 'Credit Memo Approved' đến 'Refund Processed' phản ánh trực tiếp tốc độ xử lý của bộ phận ngân quỹ hoặc tài chính. Lấy dữ liệu ở đâu Sự kiện này là thời điểm tạo giao dịch CustomerRefund. Trường 'Created From' trên giao dịch liên kết giao dịch này với CreditMemo. Thu thập Ngày tạo giao dịch CustomerRefund trong NetSuite. Loại sự kiện explicit
	Nhận hàng trả về	Hoạt động này đánh dấu thời điểm kho hoặc trung tâm xử lý nhận được sản phẩm trả về. Trong NetSuite, việc này được ghi nhận rõ ràng bằng cách tạo giao dịch Item Receipt liên kết với Return Authorization ban đầu.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, đánh dấu chuyển tiếp từ hành động của khách hàng sang khâu xử lý nội bộ. Thời gian từ 'Return Approved' đến 'Item Received' cho biết tốc độ gửi trả của khách hàng. Thời gian sau sự kiện này phản ánh hiệu quả xử lý nội bộ. Lấy dữ liệu ở đâu Sự kiện này là thời điểm tạo giao dịch ItemReceipt. Bản ghi này được liên kết trực tiếp với ReturnAuthorization ban đầu. Thu thập Ngày tạo giao dịch ItemReceipt trong NetSuite, được liên kết với RA. Loại sự kiện explicit
	Phê duyệt yêu cầu cho phép trả hàng	Hoạt động này thể hiện việc nhân viên chính thức phê duyệt yêu cầu trả hàng của khách hàng để quy trình tiếp tục. Thông thường, có thể xác định hoạt động này qua thay đổi trạng thái trên bản ghi Return Authorization, chẳng hạn từ 'Pending Approval' sang 'Pending Receipt'.
Vì sao điều này quan trọng Theo dõi bước phê duyệt này rất quan trọng để xác định điểm nghẽn trong giai đoạn xem xét ban đầu. Chậm trễ ở đây ảnh hưởng trực tiếp đến thời gian thông báo cho khách hàng và nhận lại sản phẩm. Lấy dữ liệu ở đâu Có thể xác định từ ghi chú hệ thống hoặc lịch sử workflow của bản ghi ReturnAuthorization, cụ thể là khi trường 'Status' được cập nhật sang trạng thái đã phê duyệt, chẳng hạn 'Pending Receipt'. Thu thập Phát hiện khi trạng thái của bản ghi ReturnAuthorization chuyển sang 'Approved'. Loại sự kiện inferred
	Tạo Credit Memo	Hoạt động này đánh dấu thời điểm bắt đầu xử lý phần tài chính của việc trả hàng bằng cách tạo Credit Memo. Chứng từ này ghi rõ số tiền cần hoàn cho khách hàng và được tạo từ Return Authorization sau khi sản phẩm được nhận và phê duyệt.
Vì sao điều này quan trọng Tạo Credit Memo là một cột mốc tài chính quan trọng. Thời gian từ lúc nhận sản phẩm đến khi tạo Credit Memo cho biết hiệu quả của quy trình từ kiểm tra đến ghi có. Lấy dữ liệu ở đâu Sự kiện này là thời điểm tạo giao dịch CreditMemo. Trường 'Created From' trên Credit Memo liên kết giao dịch này với ReturnAuthorization. Thu thập Ngày tạo giao dịch CreditMemo trong NetSuite. Loại sự kiện explicit
	Tạo yêu cầu cho phép trả hàng	Hoạt động này đánh dấu thời điểm bắt đầu quy trình trả hàng, khi khách hàng yêu cầu trả sản phẩm. Trong NetSuite, hoạt động được ghi nhận rõ ràng bằng cách tạo một bản ghi Return Authorization (RA) mới. Bản ghi này là mã định danh chính của trường hợp trả hàng.
Vì sao điều này quan trọng Đây là bước khởi đầu của quy trình, cần thiết để đo tổng thời gian xử lý trả hàng và phân tích số lượng yêu cầu trả hàng theo thời gian. Lấy dữ liệu ở đâu Sự kiện này là thời điểm tạo bản ghi ReturnAuthorization trong NetSuite. Bản ghi thường lưu người tạo, ngày tạo và trạng thái ban đầu, chẳng hạn như 'Pending Approval'. Thu thập Ngày tạo giao dịch ReturnAuthorization trong NetSuite. Loại sự kiện explicit
	Áp dụng Credit Memo	Hoạt động này thể hiện phương án thay cho hoàn tiền mặt: áp dụng Credit Memo vào hóa đơn chưa thanh toán của khách hàng. Có thể xác định hoạt động này qua liên kết 'Applied To' trên Credit Memo, cho biết khoản ghi có đã được sử dụng.
Vì sao điều này quan trọng Việc phân biệt hoàn tiền mặt với áp dụng khoản ghi có rất quan trọng khi phân tích tài chính. Đây là một hướng xử lý khác với hoàn tiền trực tiếp. Lấy dữ liệu ở đâu Có thể xác định từ ghi chú hệ thống hoặc bản ghi liên quan của CreditMemo, cụ thể là khi giao dịch này được liên kết với giao dịch Invoice để bù trừ số dư của khách hàng. Thu thập Phát hiện khi CreditMemo được áp dụng vào giao dịch Invoice. Loại sự kiện inferred
	Kiểm tra sản phẩm trả về	Hoạt động này thể hiện việc hoàn tất kiểm tra thực tế để đánh giá tình trạng sản phẩm trả về. NetSuite không có đối tượng 'Inspection' tiêu chuẩn, nên thường có thể xác định hoạt động này qua trường tùy chỉnh hoặc thay đổi trạng thái trên Return Authorization hay Item Receipt.
Vì sao điều này quan trọng Khâu kiểm tra thường là một điểm nghẽn lớn. Theo dõi thời gian hoàn tất rất quan trọng để phân tích hiệu suất của nhân viên, tính nhất quán trong quyết định và ảnh hưởng đến bước phê duyệt hoàn tiền tiếp theo. Lấy dữ liệu ở đâu Cần phân tích hệ thống để xác định. Có thể dựa vào thay đổi của trường tùy chỉnh 'Inspection Status' trên bản ghi ReturnAuthorization. Ngoài ra, đây có thể là quy trình ngoại tuyến không được ghi lại. Thu thập Có thể xác định qua thay đổi của trường trạng thái tùy chỉnh trên Return Authorization hoặc Item Receipt. Loại sự kiện inferred
	Phê duyệt Credit Memo	Hoạt động này thể hiện việc chính thức phê duyệt Credit Memo, thường cần thiết với khoản hoàn tiền lớn hoặc theo quy trình kiểm soát tài chính. Có thể xác định hoạt động này qua thay đổi trạng thái trên bản ghi Credit Memo, cho biết khoản ghi có đã sẵn sàng để áp dụng hoặc thanh toán.
Vì sao điều này quan trọng Nếu cần phê duyệt tài chính, bước này có thể trở thành điểm nghẽn đáng kể. Phân tích thời gian xử lý giúp tinh gọn quy trình kiểm soát tài chính mà không làm chậm việc hoàn tiền cho khách hàng. Lấy dữ liệu ở đâu Có thể xác định từ ghi chú hệ thống của bản ghi CreditMemo, cụ thể là khi trường trạng thái phê duyệt được cập nhật từ 'Pending Approval' sang 'Approved' hoặc 'Open'. Thu thập Phát hiện khi trạng thái của giao dịch CreditMemo chuyển sang 'Approved'. Loại sự kiện inferred
	Tạo đơn hàng đổi sản phẩm	Hoạt động này thể hiện trường hợp đổi sản phẩm, khi tạo đơn bán hàng mới cho khách thay vì hoàn tiền. Sự kiện thường được ghi nhận khi tạo Sales Order liên kết với Return Authorization ban đầu.
Vì sao điều này quan trọng Theo dõi việc đổi sản phẩm như một hướng xử lý riêng giúp phân tích lựa chọn của khách hàng và so sánh hiệu quả quy trình đổi hàng với quy trình hoàn tiền. Đây là một biến thể phổ biến và quan trọng. Lấy dữ liệu ở đâu Sự kiện này là thời điểm tạo giao dịch SalesOrder mới. Liên kết với ReturnAuthorization có thể nằm trong trường tiêu chuẩn hoặc trường tùy chỉnh, cần phân tích hệ thống để xác định. Thu thập Ngày tạo SalesOrder liên kết với ReturnAuthorization. Loại sự kiện explicit
	Thông báo cho khách hàng	Hoạt động này thể hiện việc gửi thông báo cho khách hàng về một cập nhật trạng thái quan trọng, chẳng hạn như yêu cầu được phê duyệt, đã nhận sản phẩm hoặc đã hoàn tiền. Thông thường, có thể xác định hoạt động này qua thời điểm gửi email tự động của hệ thống được ghi trong thẻ liên lạc của bản ghi.
Vì sao điều này quan trọng Thông báo kịp thời rất quan trọng để khách hàng hài lòng. Đo khoảng thời gian từ một cột mốc đến lúc thông báo cho khách hàng giúp phát hiện những điểm còn thiếu trong trải nghiệm khách hàng. Lấy dữ liệu ở đâu Cần phân tích hệ thống để xác định. Dữ liệu có thể lấy từ thời điểm gửi email hoặc ghi chú của người dùng trong thẻ phụ Communication của ReturnAuthorization hoặc CreditMemo. Thu thập Thời điểm của email hoặc mục ghi trong nhật ký liên lạc được liên kết với trường hợp trả hàng. Loại sự kiện inferred
	Từ chối yêu cầu cho phép trả hàng	Hoạt động này thể hiện quyết định từ chối yêu cầu trả hàng của khách hàng, thường do không đáp ứng chính sách. Có thể xác định sự kiện này khi trạng thái trên bản ghi Return Authorization chuyển sang 'Rejected' hoặc 'Closed' mà không có bước xử lý tiếp theo.
Vì sao điều này quan trọng Phân tích các trường hợp bị từ chối giúp tìm ra lý do phổ biến khiến yêu cầu trả hàng không tuân thủ chính sách. Từ đó, bạn có thể cải thiện cách trao đổi với khách hàng và làm rõ chính sách. Đây là một sai lệch quan trọng so với quy trình thông thường. Lấy dữ liệu ở đâu Có thể xác định từ ghi chú hệ thống hoặc lịch sử workflow của bản ghi ReturnAuthorization khi trường 'Status' được cập nhật sang trạng thái kết thúc 'Rejected'. Thu thập Phát hiện khi trạng thái của bản ghi ReturnAuthorization chuyển sang 'Rejected'. Loại sự kiện inferred

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ừ NetSuite

Các bước

Mở phần tạo Saved Search: Đăng nhập NetSuite. Chọn Reports > New Search. Trên trang New Saved Search, nhấp vào 'Transaction'.
Đặt tiêu chí chính: Trên trang thiết lập Saved Search, trong thẻ 'Criteria' và thẻ phụ 'Standard', đặt các bộ lọc sau để chỉ lấy bản ghi Return Authorization:
- Type là Return Authorization
- Main Line là Yes
- Thêm bộ lọc Date Created và chọn khoảng ngày mong muốn, chẳng hạn 'trong 3 tháng gần nhất'. Bước này rất quan trọng để kiểm soát khối lượng dữ liệu.
Thiết lập các cột kết quả cho thuộc tính: Mở thẻ 'Results'. Thêm các trường sau để dùng làm thuộc tính trong event log. Dùng 'Custom Label' để đổi tên cho dễ hiểu khi cần.
- Case ID: Document Number hoặc TranID (Custom Label: ReturnCaseId)
- Trạng thái trả hàng: Status (Custom Label: ReturnAuthorizationStatus)
- Nhân viên xử lý: Created By hoặc trường tùy chỉnh nếu có (Custom Label: ProcessingAgent)
- Phòng ban: Department (Custom Label: Department)
- Loại trả hàng: Trường tùy chỉnh như [Your Return Reason Field] (Custom Label: ReturnType)
- Số tiền hoàn: Amount (Custom Label: ActualRefundAmount)
Thêm cột công thức cho mốc thời gian sự kiện: Đây là bước quan trọng nhất. Với mỗi hoạt động trong số 12 hoạt động, thêm một cột 'Formula (Date/Time)'. Mỗi công thức dùng câu lệnh CASE để chỉ trả về mốc thời gian khi sự kiện tương ứng xảy ra. Xem phần 'query' để biết công thức chính xác cho từng hoạt động.
Thêm cột tĩnh: Thêm hai cột 'Formula (Text)' vào kết quả:
- Với SourceSystem, dùng công thức: 'NetSuite'.
- Với LastDataUpdate, dùng công thức thể hiện ngày chạy, chẳng hạn {today}. Nếu cần mốc thời gian chính xác, đây sẽ là thời điểm xuất dữ liệu.
Lưu và xuất Saved Search: Đặt tên dễ nhận biết cho Saved Search, chẳng hạn 'ProcessMind Returns Extraction'. Nhấp 'Save & Run'. Khi kết quả hiển thị, nhấp biểu tượng Export và chọn 'CSV'.
Chuyển đổi dữ liệu thành event log: Tệp CSV xuất ra có định dạng 'rộng', mỗi dòng là một trường hợp trả hàng và có nhiều cột chứa mốc thời gian của các sự kiện. Bạn cần chuyển dữ liệu sang định dạng event log 'dài'. Dùng Microsoft Excel Power Query (Unpivot Columns), Python hoặc công cụ lập trình khác để chuyển đổi.
- Với mỗi dòng trong CSV, tạo nhiều dòng mới, mỗi dòng ứng với một cột mốc thời gian sự kiện có dữ liệu.
- Bảng sau chuyển đổi cần có các cột như ReturnCaseId, ActivityName và EventTimestamp. ActivityName lấy từ tiêu đề cột mốc thời gian ban đầu, chẳng hạn 'Return Authorization Created'; EventTimestamp là giá trị trong cột đó.
Hoàn tất để tải lên: Đảm bảo tệp CSV cuối cùng có các tiêu đề bắt buộc: ReturnCaseId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate cùng các thuộc tính được đề xuất. Tệp đã sẵn sàng để tải lên ProcessMind.

Cấu hình

Loại tìm kiếm: Saved Search phải là tìm kiếm Giao dịch.
Khoảng thời gian: Cần lọc theo trường Date Created của Return Authorization. Nên chọn khoảng 3 đến 6 tháng để cân bằng giữa độ đầy đủ của dữ liệu và hiệu suất.
Bộ lọc chính: Tìm kiếm phải lọc Loại là Return Authorization và Main Line là Có để đảm bảo mỗi trường hợp trả hàng chỉ có một bản ghi ban đầu.
Trường tùy chỉnh: Độ chính xác của dữ liệu trích xuất, đặc biệt với các sự kiện khái niệm như 'Đã kiểm tra mặt hàng' hoặc thuộc tính như 'Loại trả hàng', phụ thuộc nhiều vào cách tổ chức của bạn sử dụng trường tùy chỉnh trên bản ghi giao dịch. Các công thức được cung cấp có chỗ giữ giá trị như {custbody_...}; bạn cần điều chỉnh cho khớp với cấu hình NetSuite.
Quyền người dùng: Người chạy tìm kiếm cần có quyền xem tất cả loại giao dịch liên quan: Return Authorization, Item Receipt, Credit Memo, Customer Refund và Sales Order.
Hiệu suất: Với tài khoản có số lượng lớn trường hợp trả hàng, tìm kiếm này có thể chạy chậm. Hãy cân nhắc chạy ngoài giờ cao điểm hoặc lên lịch tự động xuất tệp vào file cabinet.

Truy vấn mẫu config

This configuration represents the settings in the NetSuite Saved Search UI. The 'Results' tab should be configured with the following columns and formulas.

**Criteria Tab:**
*   `Type` = `Return Authorization`
*   `Main Line` = `true`
*   `Date Created` = `[Specify Desired Date Range]`

**Results Tab (Columns):**

| Custom Label | Field / Formula Type | Formula / Field ID |
|---|---|---|
| `ReturnCaseId` | Formula (Text) | `{tranid}` |
| `SourceSystem` | Formula (Text) | `'NetSuite'` |
| `LastDataUpdate` | Formula (Date/Time) | `{today}` |
| `ReturnAuthorizationStatus` | Field | `Status` |
| `ProcessingAgent` | Field | `Created By` |
| `Department` | Field | `Department` |
| `ReturnType` | Field | `{custbody_return_reason}` |
| `ActualRefundAmount` | Field | `Amount` |
| `CycleTime` | Formula (Numeric) | `CASE WHEN {status} = 'Closed' THEN {lastmodifieddate} - {datecreated} ELSE NULL END` |
| `Activity_ReturnAuthorizationCreated` | Field | `Date Created` |
| `Activity_ReturnAuthorizationApproved` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Pending Receipt' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ReturnAuthorizationRejected` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Rejected' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ItemReceived` | Formula (Date/Time) | `{applyingtransaction.trandate}` |
| `Activity_ItemInspected` | Formula (Date/Time) | `CASE WHEN {custbody_inspection_status} = 'Complete' THEN {custbody_inspection_date} ELSE NULL END` |
| `Activity_CreditMemoCreated` | Formula (Date/Time) | `{createdfrom.trandate}` |
| `Activity_CreditMemoApproved` | Formula (Date/Time) | `MIN(CASE WHEN {createdfrom.systemnotes.newvalue} = 'Open' AND {createdfrom.systemnotes.field} = 'Status' THEN {createdfrom.systemnotes.date} ELSE NULL END)` |
| `Activity_RefundProcessed` | Formula (Date/Time) | `{createdfrom.appliedtotransaction.trandate}` |
| `Activity_CreditMemoApplied` | Formula (Date/Time) | `CASE WHEN {createdfrom.status} = 'Fully Applied' AND {createdfrom.appliedtotransaction.type} = 'Invoice' THEN {createdfrom.appliedtotransaction.date} ELSE NULL END` |
| `Activity_ExchangeOrderCreated` | Formula (Date/Time) | `{custbody_exchange_order.trandate}` |
| `Activity_CustomerNotified` | Formula (Date/Time) | `MAX({messages.messagedate})` |
| `Activity_ReturnAuthorizationClosed` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Closed' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |

Các bước

Bật SuiteAnalytics Connect: Đảm bảo tài khoản NetSuite của bạn có giấy phép SuiteAnalytics Connect. Quản trị viên cần bật tính năng này tại Setup > Company > Enable Features > Analytics.
Cấp quyền người dùng: Cấp quyền 'SuiteAnalytics Connect' cho vai trò của người dùng kết nối. Người dùng này cũng cần quyền xem tất cả bản ghi được truy vấn, chẳng hạn Transactions, Employees và Customers.
Cài đặt trình điều khiển ODBC: Tải và cài đặt trình điều khiển NetSuite ODBC phù hợp với hệ điều hành của bạn từ trang tải xuống SuiteAnalytics Connect trong NetSuite.
Cấu hình DSN: Thiết lập Data Source Name (DSN) trên máy sẽ chạy truy vấn. Nhập Service Data Source, Server Hostname, Port, Role ID, Account ID và thông tin đăng nhập.
Kết nối ứng dụng SQL: Dùng ứng dụng SQL như DBeaver hoặc Microsoft SQL Server Management Studio để kết nối NetSuite qua DSN đã cấu hình.
Chuẩn bị truy vấn SQL: Sao chép truy vấn SQL được cung cấp vào ứng dụng. Truy vấn này được thiết kế để trích xuất tất cả sự kiện chính trong quy trình trả hàng và hoàn tiền.
Tùy chỉnh truy vấn: Sửa các giá trị giữ chỗ trong truy vấn. Ít nhất, bạn cần cập nhật khoảng ngày trong Common Table Expression (CTE) ReturnAuthorizations để lọc đúng giai đoạn mong muốn. Bạn cũng có thể cần điều chỉnh tên trường tùy chỉnh như CUSTBODY_RETURN_TYPE hoặc giá trị trạng thái cụ thể cho khớp với cấu hình NetSuite.
Chạy truy vấn: Chạy truy vấn SQL đã tùy chỉnh trên bản sao cơ sở dữ liệu NetSuite. Thời gian chạy có thể thay đổi tùy theo khoảng ngày và khối lượng dữ liệu.
Kiểm tra và xuất dữ liệu: Khi truy vấn chạy xong, kiểm tra kết quả để bảo đảm dữ liệu chính xác. Xuất toàn bộ kết quả sang tệp CSV.
Hoàn tất để tải lên: Đảm bảo tiêu đề cột trong CSV khớp với các thuộc tính bắt buộc: ReturnCaseId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, v.v. Kiểm tra để cột EventTimestamp dùng định dạng ngày giờ nhất quán. Tệp đã sẵn sàng để tải lên ProcessMind.

Cấu hình

Điều kiện tiên quyết: Bạn cần giấy phép NetSuite có mô-đun bổ sung SuiteAnalytics Connect. Vai trò của người dùng chạy kết nối phải có quyền 'SuiteAnalytics Connect' và quyền đọc bản ghi giao dịch, thực thể và nhân viên.
Cấu hình nguồn dữ liệu: Bạn cần cấu hình DSN (Data Source Name) bằng trình điều khiển NetSuite ODBC. Việc này cần Account ID, Role ID và thông tin đăng nhập. Với môi trường sản xuất, máy chủ dịch vụ thường là odbcserver.netsuite.com.
Lọc khoảng ngày: Cần áp dụng bộ lọc khoảng ngày cho CTE ban đầu dùng để chọn Return Authorization. Nếu không có bộ lọc, truy vấn sẽ cố lấy dữ liệu của tất cả trường hợp trả hàng và có thể chạy rất chậm hoặc hết thời gian chờ. Nên bắt đầu phân tích với khoảng 3 đến 6 tháng.
Các loại giao dịch chính: Truy vấn nhắm đến một số loại giao dịch cốt lõi: ReturnAuthorization, ItemReceipt, CreditMemo, CustomerRefund và SalesOrd (đối với hàng đổi). Hãy bảo đảm quy trình của bạn sử dụng các đối tượng tiêu chuẩn này.
Phụ thuộc vào trường tùy chỉnh: Các hoạt động như 'Đã kiểm tra hàng' và thuộc tính như 'Loại trả hàng' thường được ghi nhận trong trường tùy chỉnh. Truy vấn được cung cấp dùng các chỗ giữ chỗ như CUSTBODY_INSPECTION_STATUS và CUSTBODY_RETURN_TYPE. Bạn cần xác định đúng ID trường tùy chỉnh trong hệ thống và cập nhật truy vấn cho phù hợp.
Lưu ý về hiệu suất: Đây là truy vấn phức tạp, có nhiều phép nối và cấu trúc UNION ALL lớn. Hãy chạy vào giờ thấp điểm để giảm ảnh hưởng đến hiệu suất hệ thống. Với tập dữ liệu rất lớn, hãy cân nhắc chạy truy vấn theo từng khoảng thời gian ngắn rồi nối kết quả.

Truy vấn mẫu sql

WITH ReturnAuthorizations AS (
    SELECT
        T.TRANSACTION_ID AS ReturnCaseId,
        T.TRANDATE
    FROM
        TRANSACTION T
    WHERE
        T.TYPE = 'ReturnAuthorization'
        AND T.TRANDATE BETWEEN TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD') AND TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD')
)
SELECT
    RA.ReturnCaseId AS "ReturnCaseId",
    'Return Authorization Created' AS "ActivityName",
    T.CREATED_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    T.STATUS AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM TRANSACTION T
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON T.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Return Authorization Approved' AS "ActivityName",
    SN.NOTE_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    SN.NEW_VALUE AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Pending Receipt'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Return Authorization Rejected' AS "ActivityName",
    SN.NOTE_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    SN.NEW_VALUE AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE IN ('Rejected', 'Closed')

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Item Received' AS "ActivityName",
    IR.CREATED_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    T_RA.STATUS AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM TRANSACTION IR
INNER JOIN TRANSACTION T_RA ON IR.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON IR.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE IR.TYPE = 'ItemReceipt'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Item Inspected' AS "ActivityName",
    SN.NOTE_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    T.STATUS AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.CUSTBODY_INSPECTION_STATUS' AND SN.NEW_VALUE = 'Completed'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Credit Memo Created' AS "ActivityName",
    CM.CREATED_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    T_RA.STATUS AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM TRANSACTION CM
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON CM.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Credit Memo Approved' AS "ActivityName",
    SN.NOTE_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    SN.NEW_VALUE AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.APPROVAL_STATUS' AND SN.NEW_VALUE = 'Approved'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Refund Processed' AS "ActivityName",
    REF.CREATED_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    T_RA.STATUS AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
    ABS(REF.TOTAL) AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM TRANSACTION REF
INNER JOIN TRANSACTION CM ON REF.APPLIED_TO_TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON REF.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE REF.TYPE = 'CustomerRefund'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Credit Memo Applied' AS "ActivityName",
    SN.NOTE_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    SN.NEW_VALUE AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Fully Applied'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Exchange Order Created' AS "ActivityName",
    SO.CREATED_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    T_RA.STATUS AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM TRANSACTION SO
INNER JOIN TRANSACTION T_RA ON SO.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SO.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SO.TYPE = 'SalesOrd'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Customer Notified' AS "ActivityName",
    MSG.MESSAGE_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    T.STATUS AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM MESSAGES MSG
INNER JOIN TRANSACTION T ON MSG.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON MSG.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE MSG.INCOMING = 'F'

UNION ALL

SELECT
    RA.ReturnCaseId,
    'Return Authorization Closed' AS "ActivityName",
    SN.NOTE_DATE AS "EventTimestamp",
    'NetSuite' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    SN.NEW_VALUE AS "ReturnAuthorizationStatus",
    E.full_name AS "ProcessingAgent",
    D.full_name AS "Department",
    T.CUSTBODY_RETURN_TYPE AS "ReturnType",
    NULL AS "ActualRefundAmount",
    NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE T.TYPE = 'ReturnAuthorization' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE LIKE '%Closed%';

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

Bắt đầu cải thiện quy trình xử lý trả hàng và hoàn tiền bằng mẫu dữ liệu này. Tối ưu workflow NetSuite ngay hôm nay để nâng cao hiệu quả và 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

Tối ưu quy trình trả hàng và hoàn tiền, nâng cao hiệu quả NetSuite

Giảm 30% thời gian xử lý trả hàng trên NetSuite. Bắt đầu cải thiện hoạt động ngay hôm nay.

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

Không cần thẻ tín dụng • Thiết lập trong vài phút

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

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

Các thuộc tính của quy trình xử lý trả hàng và hoàn tiền

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

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

Xuất Return Authorization bằng Saved Search trong NetSuite

Các bước

Cấu hình

Truy vấn mẫu config

Truy vấn SQL qua NetSuite SuiteAnalytics Connect ODBC

Các bước

Cấu hình

Truy vấn mẫu sql

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

Tối ưu quy trình trả hàng và hoàn tiền, nâng cao hiệu quả NetSuite